Elysian Shadows

Hey guys,

I'm breaking my head on a flexible, reusable, comfortable entity (base) class for game objects. My first thought was, that making members for health, etc. is not a flexible design. So I made a more generic system for that but it's current implementation seems messy to me.

Furthermore, I'm thinking of how action-callbakcs can be implemented in the best way. Signals and slots came to my mind. Any ideas on implementation would be great.

Please, just throw in your implementations and interfaces Here is mine so far:

Entity.hpp:
http://pastebin.org/91506
Entity.cpp:
http://pastebin.org/91507

Ciao,
Marius

My entity class contains everything that my other classes had in common: a rectangle for holding position, height, and width, a unique ID int, etc. It should really just contain what all the classes that would inherit it already share.

GR33B wrote:My entity class contains everything that my other classes had in common: a rectangle for holding position, height, and width, a unique ID int, etc. It should really just contain what all the classes that would inherit it already share.

That is the exact thing that I did not want to do Imagine you want to reuse this class for a game where positions of objects are not measured in floats but in ints and they have no width and height. I'm trying to find a generic allround solution.

K-Bal wrote:

GR33B wrote:My entity class contains everything that my other classes had in common: a rectangle for holding position, height, and width, a unique ID int, etc. It should really just contain what all the classes that would inherit it already share.

That is the exact thing that I did not want to do Imagine you want to reuse this class for a game where positions of objects are not measured in floats but in ints and they have no width and height. I'm trying to find a generic allround solution.

Well a floating point rectangle would solve that issue, as you could use the x and y coordinates for the position and disregard the width and height.

But if your game was to vary that much, I would just alter the entity class to fit that game's needs. It's not that realistic to want an entity class that will be ideal for any type of game, because there's so many different kinds of games and ways to create them. The entity class will be almost always game specific.

Dude I'm having the same issue aswell! I want my engine to be reusable as possible, but I'm not sure what to do with the Entity Class to keep it generic
However from looking at your code, I can see your on the money

GR33B wrote: Well a floating point rectangle would solve that issue, as you could use the x and y coordinates for the position and disregard the width and height.

But if your game was to vary that much, I would just alter the entity class to fit that game's needs. It's not that realistic to want an entity class that will be ideal for any type of game, because there's so many different kinds of games and ways to create them. The entity class will be almost always game specific.

It's not just about variation from game to game. I constantly encounter the situation of adding a new attribute for something in the game. That means: define a member, write getter and setter functions. I hate it. So with a generic attribute system and maybe script defined and signal/slot controlled action callbacks, I would not even have to inherit from Entity for specialization.

GroundUpEngine wrote:Dude I'm having the same issue aswell! I want my engine to be reusable as possible, but I'm not sure what to do with the Entity Class to keep it generic
However from looking at your code, I can see your on the money

Thanks. Don't you think that this way of handling attributes is kind of messy/bug prone/pure gayness?

Ciao,
Marius

This is just a thought, but what if every part of the game had its own interface. Like the render system would have a RenderAble interface, that classes that want to be rendered(Most entities, but maybe not all) would have to implement.
The implementations might still vary from game to game though, but might in many cases also be reusealbe.
I havent really thought this through, and i havent implemented it. Just a quick thought.

GroundUpEngine wrote:Dude I'm having the same issue aswell! I want my engine to be reusable as possible, but I'm not sure what to do with the Entity Class to keep it generic
However from looking at your code, I can see your kinda on the money

Fixed =)

ismetteren wrote:This is just a thought, but what if every part of the game had its own interface. Like the render system would have a RenderAble interface, that classes that want to be rendered(Most entities, but maybe not all) would have to implement.
The implementations might still vary from game to game though, but might in many cases also be reusealbe.
I havent really thought this through, and i havent implemented it. Just a quick thought.

Sounds good, but I would make another class for this that inherits from Entity and from Renderable. Thus you have Logic encapsulated in Entity and Graphic in Renderable.

K-Bal wrote:

ismetteren wrote:This is just a thought, but what if every part of the game had its own interface. Like the render system would have a RenderAble interface, that classes that want to be rendered(Most entities, but maybe not all) would have to implement.
The implementations might still vary from game to game though, but might in many cases also be reusealbe.
I havent really thought this through, and i havent implemented it. Just a quick thought.

Sounds good, but I would make another class for this that inherits from Entity and from Renderable. Thus you have Logic encapsulated in Entity and Graphic in Renderable.

That a pretty neat idea! It's kinda similar to SFML's sf::Drawable

ummm...

how about just having one SetValue function, passing it a void*, and then just using some logic inside to cast it properly.

avansc wrote:ummm...

how about just having one SetValue function, passing it a void*, and then just using some logic inside to cast it properly.

Yep, I already thought of this. Would require the user to remember the types of all attributes. Don't if that is a good thing but I guess the generalization just has it's costs. I also thought about having an attribute base class and derived specializations but I could not think of a useful interface.

take a look at boost::any or cast_any something like that.

Thanks, that boost::any looks like it was especially made for my situation

Just integrated boost::any in about one minute. Here is the most generic entity class I've seen so far

http://pastebin.org/94537

I would not derive from it unless you need additional functionality. Just rewrite the Update/Draw/Constructor functions to suit your needs.

Also consider using a (std::/boost::)unordered_map instead of std::map if you are saving a lot of attributes.

Marius