WorldEntity

A place to discuss everything about the Orxonox framework.

Moderator: PPS-Leaders

Post Reply
User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

WorldEntity

Post by beni » Mon Jun 25, 2007 5:39 pm

Hi guys

To some of you I already talked about it: WorldEntity is growing big and to me it's not really logical.
There are several classes inheriting from WorldEntity, which need not more than one function/method of WorldEntity and besides have nothing to do with that class.
Then there is the huge amount of variables and methods in WorldEntity which are not used by most of the inheriting classes.

Example: Every WorldEntity has several widgets for it's stats. Widgets are GUI elements used by the HUD. While it makes perfectly sense, that a playable has those widgets or a NPC, I don't really see, why particles need to care about their gui-elements which are never used anyway. Also the skybox: It should never be killed in the first place, right? Even the value "Health" may not be used by all the WorldEntities out there.

I'd like to discuss with you what a WorldEntity is and what it should contain. Redefine WorldEntity in some kind that this mother-class makes more sense again.
After that, I'll create a ticket or I'll strip the WorldEntity off its unusable parts myself.

I think this is necessary, not only because of huge overhead an instance of WorldEntity creates, but also for reasons of readability of our code.

Same problem has the Spaceship class
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Mon Jun 25, 2007 9:16 pm

You're absolutely right. The class hierarchy is way too flat. In fact, there's only the WE as mother class and hundreds of derived classes.

We should reduce the WE to his basics:
- XML-loadable
- drawable
- maybe a state like active/inactive (triggerable?)


And then we need several subclasses:

creatures (intelligence (see below), team, ...)
- fps creatures (health, bsp-collision, item pickup, fps-weapons, falldamage, ...)
--- player
--- turret
--- bots?
- space creatures (health, shield, ship-weapons, ...)
--- spaceship
--- npcs
- specator/ghost/camera?

intelligence
- players input
- AI
- track

items (can be picked up, spawnrate, ...)
- fps-weapons
- health/shield
- quest-items?

projectiles
- instant-hit
- ballistic

gui
- hud
- quest

particles
- effects


Maybe something like that. We should create a complete class-tree before changing anything. And possibly we have to change some basic implementations (like the intelligence or the whole creatures~fps~ship thing).

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Tue Jun 26, 2007 8:46 am

Maybe something like that. We should create a complete class-tree before changing anything. And possibly we have to change some basic implementations (like the intelligence or the whole creatures~fps~ship thing).
A definite maybe... ;)
But unfortunately I think we do not only need an inheritance chart for the WE, but for the entire game. Some parts seem to be (at least) initialized in a very strange order.[just look for if(init) checks in the tick routine] (But this might be a job for later on)

I am basically willing to do something, but I have also to learn.... :cry:

cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Tue Jun 26, 2007 12:29 pm

We don't want to make this job too big. Both of you stated very valuable points and it's inevitably that we need to work on this. That's out of question. I'm really happy that you answered so quickly and that the answers are that useful.
The problem is our limited time over the holidays. And as much as I like to see Orxonox in a perfect state at the beginning of next semester I think we should rather start with small things.
Nico is right. We have to think about the order of initializing. Somehow the starting Orxonox and the running Orxonox somehow lose some information, so that we have to double implement certain stuff.

But let's for now focus on the WorldEntity, since most our classes we work on inherit from WE. Let's find a way to strip the class without too much changes in the framework. A complete renewal of the class hierarchy can cause more work than one can think.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Tue Jun 26, 2007 2:56 pm

I also see the need for more structure in our code. Since a WE is very generic in nature, the code should also reflect this property by not being specialized :D T

I think your suggestions get very close to what we will need. The problems you mentioned are actually four:
1. WE has properties it shouldn't have
2. derivation hierarchy is weird especially NPCs
3. the folder structure src/world_entities should either reflect derivation hierarchy or a more systematical categorization.
4. initialization order, who calls which init functions....

Problem 1:
Another more iterative approach would be:

Code: Select all

 1. Look at world_eneity.{cc, h}, for each line
 2. if property/function is not WE specific, move it to a subclass of WE where it belongs (if no such class, create new subclass)
Problem 2:
this is a typical clean-up task. Get through the classes and look if derivation tree makes sense. This is perhaps not that urgent as beni already mentioned

Problem 3:
Suggestions?

Problem 4:
The init process could really need a rework and especially a documentation afterwards. But this is a small closed project on its own. Worth to try out some new things.

cheers,
patrick

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests