Proper way to create entities? (Derive from base or 1 generic class?)

I would recommend starting with the first option. It keeps things simpler in the beginning. Should the need arise later you could create a class that extends your base entity and reads in creature information from a file (or modify your existing one to do so). For now its more important to get a functional implementation.

I have an entity (PlayerEntity)

I dont use inheritance much, i give the playerentity the following members:
-Player (represents the game logic side player, has position)
*Handles its physics in the game world (has a physicsbody member)
*Handles player specific logic

-PlayerView (represents the graphical player, also has position)
*Draws a player based on its positions and state

The playerentity class syncs the 2 every frame (sets playerviews position to that of player), for example i could implement interpolation of the players position here to get smooth graphics at high FPS

The playerentity would also notify the playerview about changes to the state of player (like, player is jumping, player died, player now wears hat) so appropriate animations etc can be applied.

Im still working on it though, but this will be the general structure. You can get more flexibility by automatizing the sync part using a common interface for the components and a messaging system (playerview listens for pkayerdied message, which can be broadcasted by player for example) but that IMO is unnecessary for anything but the largest games and just adds performance overhead and complexity. (that is what most people call component entity system or something)

Okay, i guess i will just stick with the first option and then later on when my projects begin to get a bit too out of hand (or i just feel like having more flexibility) i will implement file reading and whatnot. Thanks for the replies!

Perhaps a middle ground would be the popular Component Entity Model (/System) which favours composition over inheritance.

Basically you instantiate an entity class and then attach other classes onto it to perform its specific functionality. Such as PositionComponent, ModelComponent, BoxCollisionComponent.

Personally I really like this architecture, it feels more flexible than a typical OOP inheritance system. It also works great for bog standard C.

hello there.

I'm trying out this type of formt for my new game.

class base

{

};//do stuff

for units I have this class

class Uint : public base

{

public:

//this public class will define each different unit type it gets saved to file and loaded

class Unitdeff

{

public:(whats with the tab button)

DWORD UnitType;//defines what this unit is Eg. flamebot or rifleman

//othere members to define different unit types

};//end class Uintdeff

//members all units need same things

bool Master;//if true this object holds the data only

Unitdeff *defineddata;//only the master object loads and deletes this all other cloned type units just point to this member for that type

bool LoadDeffData(string filename);

base *CreateCloneUnit(void)

{ if(Master == false)

return NULL;

base *newobj = new Unit;

newobj->defineddata = defineddata;

//other members set here

return newobj;

}

then in your assetmanager app you set all members of the defineddata and save it to file for each unit type.

then in your game app you load each file and create the defined object once(where all the mesh data is loaded)

when you need a unit type you call the units createcloneUnit function for what type of unit you needed;

Its working well I have many different unit types all with one class I'll make one for vehicle and air.