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:
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.
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?
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
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.
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
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.
Here is mine so far:
