Jump to content
  • Advertisement
Sign in to follow this  
Norman Barrows

OO where do entity type definitions go?

This topic is 1230 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

in OO-ish code organization (non-CES), where do entity type definitions go?

 

IE i have say 3 types of entities: orcs, elves, and goblins.  all entities of the same type have the same base hit points, armor class, drawing info etc.

 

where should these constants / data driven variables be stored?

 

would i have a base class called entity, and derived classes for elf, orc, and goblin? the base class would declare the variables, and the derived class contructors would initialize them? but then each instance of an entity type has duplicate type info. 

 

inheritance - B is an A with extra variables and/or methods - doesn't do it.

 

polymorphism - B is an A with some/all methods redefined -  doesn't do it.

 

relational databases does it...   that's how i've been doing with non-OO code.

 

do the same thing (relational databases), but with OO code?

 

 

Share this post


Link to post
Share on other sites
Advertisement

If you want to make something that's pure OOP and want classes for Orc, Elf and Goblin then they should be classes that inherit all from the same base class.

 

Inheritance and polymorfism doesn't force you to add or redefine extra variables of methods, you can make something like:

class A {
    int value;

    A(int value){
        this.value = value
    }
}

class B {
    B():A(2){}
}

and it's completelly valid, but kind of unnecesary.

 

Anyway, if those type of entities have all exactly the same behaviour you really don't need more clases. If you want to make the diferent entities explicit in code you can have a factory class with methods that returns an "Orc", "Elf" or "Goblin". Not an instance of Orc, Elf or Goblin classes, just an instance of the entity class with all the values that represent the correct entity. This way you can do something like:

class Factory {
    static Entity newOrc(){
        return new Entity(/* set the type to orc */);
    }
    static Entity newElf(){
        return new Entity(/* set the type to elf */);
    }
    static Entity newGoblin(){
        return new Entity(/* set the type to globin */);
    }
}

void main () {
    Entity orc = Factory.newOrc();
    Entity elf = Factory.newElf();
    Entity goblin = Factory.newGoblin();
}
Edited by DiegoSLTS

Share this post


Link to post
Share on other sites


Entity orc = Factory.newOrc();

 

but that would still put the armor class of an orc in every instance of an orc wouldn't it?  IE my entity instances contain entity type data which is constant between entities of that type (duplicate data).

 

what would be desirable would be to put entity variables in entity instances, and entity type constants in just one place, and have entity instances refer to them. unless the overhead of duplicate entity type data in every entity instance is considered acceptable these days.

Share this post


Link to post
Share on other sites
If you're data-driving things, then the variables should be coming from your data.

As for where you put the data when you want it in memory... where ever you want. Edited by Washu

Share this post


Link to post
Share on other sites

As for where you put the data when you want it in memory... where ever you want.

 
so there is no best method then?

In software development, "best" is relative. Edited by Washu

Share this post


Link to post
Share on other sites


In software development, "best" is relative.

 

all too true!

 

 

well good old fashioned software engineering says you should not duplicate the entity type data in every instance of an entity, so i guess i'm going to go with the "relational database pattern". <g>

Share this post


Link to post
Share on other sites


well good old fashioned software engineering says you should not duplicate the entity type data in every instance of an entity, so i guess i'm going to go with the "relational database pattern".
In some situations that can be a great pattern.

 

Perhaps not using SQL to do it, but relational database absolutely.  In data-driven games using relational tables of data is a popular and efficient choice.

 

Relational data is rows and columns with a unique key for each row. Hence you have a data table of objects and one entry in the row is the key to the type of monster.

 

Maybe eight of them share the key to "goblin" (data calls it 37), one has a key to "goblin boss" (data calls it 38).  To look up the attributes of the monster follow the relationship, look up in table MonsterData[37] or MonsterData[38], and you're following a relational database pattern.

Share this post


Link to post
Share on other sites

If you want to make something that's pure OOP and want classes for Orc, Elf and Goblin then they should be classes that inherit all from the same base class.

An important rule of OO is to prefer composition over inheritance.
So an OO solution would probably have:
- a Monster class for instances of monster entities in the world, with a pointer to:
- A MonsterDescriptor class containing values that are common to one 'class' of monsters.
- 3 instances of MonsterDescriptor, containing values for Orcs, Elves and Goblins.
- A utility for loading these descriptors from disc, DB, etc.
- Many instances of Monster, which must be passed a MonsterDescriptor in their constructors.

Share this post


Link to post
Share on other sites

what would be desirable would be to put entity variables in entity instances, and entity type constants in just one place, and have entity instances refer to them. unless the overhead of duplicate entity type data in every entity instance is considered acceptable these days.


That depends on what you are going for; best performance or saving a trivial amount of memory.

With the type data if you need it while processing some attribute of a single instance then having it in the same block of memory close to the attribute you are processing could well be a net win as, when doing the processing the 'amour class' is likely to be next to, or near, the rest of the data you are manipulating (health = health - max((damage - AC),0); for example) which means the process is likely to have it kicking about in the cache for you to use.

With a 'central database' solution; yes you might save a few bytes but there is a good chance that every time you go to do our example (health = health - max((damage - AC),0); ) you'll crash into a cache miss and the CPU will spin its wheels for a bit while it goes to fetch the data (and unrelated data at that) from somewhere else in memory.

This, of course, might be fine for you, I'm not saying the top method is the absolute total best for all situations; you could have enough type data that your entity definition gets bulked out and it starts causing other performance issues, without knowing the structure of the game, data types or how you act upon them it is hard to say (this is where the joys of hot-cold analysis come into play to work out what data should be together when).

All things being equal I would tend towards solutions which package related data together, by operation, so that on each memory fetch the CPU is pulling in everything I need as together as it can, as it's the latency to memory which hurts most these days given that we are swimming in ALU cycles and memory space.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!