Entity factories

[kmh]

Considering some of the basic design decisions for my overly ambitious game project, this is one of the things I can't really seem to make my mind up about: For the entity factory (i.e. the module where objects, creatures and players are stored and characterised), is it better to hard code them or to use some XML parser?
Hard coding seems easier and to some extend cleaner, where as XML probably has the advantage of adding new objects without the need to recompile. Any suggestions?
I'll need XML parsing of some sort anyways, to implement some of the more complicated processes in the game, so it wouldn't be that much of an extra effort.... discuss.

[Robomaniac]

You should make a basic entity class, from which you do some more defining.

Code: Select all

          Entity
             |
    |-------------|
   Player        Weapon

From there, you should build some more basic types, such as enemy, local player, weapon_projectile, weapon_raycast.

From those, you shouldn't really define other classes, you should create an settings file, which you define settings in.

Code: Select all

raycast_weapon Shotgun
{
    rays_per_shot 5
    max_dispersion_angle 50
    rounds_per_second 10
    magazine_capacity 30
    maximum_magazines 5
    start_ammo 30

    reload_time 2000
    
    mesh m14.mesh

    sound_shoot m14_shoot.wav
    sound_reload m14_reload.wav
}

From those, you should be able to load your weapon from a basic class, and set the settings creating different weapon types. You need to handle parsing and loading yourself, but its not too hard. The weapons classes should be abstract enough that there is no need to create different classes for each weapon. Abstraction is king.

Hope that helps you make up your mind!

[Electron]

Yeah, I totally agree with Robo. Of course weapons are one of the easiest to abstract because you have many different types but they are all quite similar. Enemies I find are good to abstract too. Other game items can become a pain because a single class will often serve for less different things. One or two weapon classes can serve for 20+ different weapons, but you'll probably have ot create a medpack class while there's only a couple different medpacks. Of course, I suppose you could create a single item class that could deal with medpacks, ammopacks, etc, but you still end up with more hard coding and less xml config reading for that sort of thing.

[kmh]

Thanks,

that seems to be a reasonable approach. I'll probably have to have a slightly over-engineered class for default objects, though. Thinking about using an array of booleans to give possible options to an object. This would look like this:

class StaticObject : public BaseObject

bool eat ; void do_eat();
bool take; void do_take();
bool burn; void do_burn();
...

where each XML file could be something like this:

Apple:
eat true
take true
burn false

Tree
eat false
take false
burn true

Money
eat false
take true
burn false

... doesn't seem like a very elegant solution to me, but the best I can come up with. Well, the example is slightly exaggarated, as for food I'd probably have a subclass, and trees and money (static and movable objects) should probably have classes for themselves, too, but that's the general idea.
Any better solutions to this? (I.e. having not quite the same object types but very similar ones in the same class).

[Robomaniac]

The way i'm doing it is as such.

Code: Select all

class StatModifierItem : public Item_Entity
{
public:
    ...
    void HandleEvent(Item_Event evt)
    {
        if (evt.m_Recipient == m_Name)
        {
             if (evt.m_Collide == true)
             {
                  m_Core->GetPlayerFactory()->GetPlayer(evt.m_Sender)->Set(m_Stat, 40);
              }
        }
    }
};

Hope that helps