Hello everyone, I was thinking quite a while on this problem, but could not figure it out!
It is all about entities in a game: monsters, pickup items, static objects, etc., how to realize them in C++? I really hesitated about using inheritance, so i created a
CEntityData class, which contained position, move vector, entity ID, and instead of using inheritance, i instanced it in every other class that would use it: CNPC, CPlayer, CItem...
And, for the game editor's saving-to-file purposes, a lightweight class was created, weirdly named entity_t, which contatined the only properties that are static and not generated, no IDs, FSM and so on. One of my university techers proposed that inhertiance should be used, in order to absract the monsters from the engine, or as he said: "The engine should not know what monster has called some method". I am in a hole right now, and any help is appreciated. The game I intend to create is an FPS.

There are many ways of doing what you want, but here's one suggestion.

What's common with all the entities? Position, orientation, collision volume.

- A mine is an entity which explodes and causes damage when collided with.
- A pickup is an entity which gives the player something (health, ammo, etc) when a player collides with it. It ignores collisions with non-players.
- A grenade is an entity which moves based on physics in the game world, and, upon timeout, blows up, causing damage to entities within range.
- A monster is an entity which knows how to move, is affected by physics, and can shoot and spawn grenades and mines.
- A player is an entity which is controlled by the player's input, is affected by physics and can shoot and spawn grenades and mines.

So,
entity
->collisionTriggerEntity
->->mine
->->pickup
->character
->->monster
->->player

On the other hand, a pickup might be a monster which simply decides not to move, etc..

I think your teacher is basically trying to make you understand the difference between a *game* and an *engine*.

Typically an engine can be reused for *any* (unlikely) type of game, so it should not contain any game-specific features - e.g. monsters, weapons etc.

These objects should be added as an extra layer on top of your engine, each one inheriting from its base functionality, in much the way that Jari has explained above.

The important point to keep in mind is that while your game can communicate and *see* your engine (through its inherited parents), your engine should not really have any knowledge of the game-specific layer above.

Hmmm... not sure if I explained that very well, but I did my best...
-Scoot

I am indeed happy to understand one very simple, in fact straightforward concept: "What is"! What is a grenade, a mine, a door, etc... :) You opened my eyes, thank you!!! Another question is if the messages, or events that are happening are also two categories: game-specific and engine-specific. And I obviously have a difficulty separating game from engine. I can tell why: for example player pressed '2' key, which changes from current weapon to the second one. The change of skins should happen when the animation of "holster current weapon" is over. Here I stuck in the mud. Animation shoud be part of the "engine" and weapons part of the "game", should they? How will the engine send a message to something it doesn't "know" about? Most of all, changing of skins is not a common functionality of all entities, or am i wrong?
Hope you can give me some enlightment.

One more thing I doubt about: For example, when some explosion(visual) has to happen, the engine must be able to render it. So, I suppose that engine should support it, and render through the basic funcionality data, no matter how deep in the entity hierarchy is the caller???

OK, I see an example is in order - you asked that if the engine needs to control game-specific elements, how can it accomplish this if it has no knowledge of the game built upon its foundation functionality?

Inheritance solves this problem for you, using virtual function calls and polymorphism.

e.g:
You may have a base class in your *engine* called, say engineInputObject. This object is added to some list held in your engine. Whenever an input event occurs, the event is routed through to all engineInputObjects with, say a handleInputEvent() function (passed an object describing the event). Inside this function the object will react to the input event (be it key press or mouse movement, etc).

Thats all well and good. Now in your game-specific code, whenever you want to make an object react to an input event, you simply inherit from engineInputObject, and overload the handleInputEvent() function. Now when an input event occurs, the messages will be routed to the *overloaded* function, and your game-specific object can react to an input event.

Woefully inadequate example:

Scoot answered part of your question, about event handling, but not the part about skin changes. So you're basically wondering: playing an animation is the engine's business, but how will the engine know that it has to do something (change the skin) after the animation has finished?

The answer is interfaces. Your engine will provide an interface to the game - that is just a set of fuctions that the game can call to make the engine do things. For instance, you might have a function in the engine called PlayAnimation() that the game calls to start the holster anim, and another function, let's say SetSkin(), that the game calls to change the skin of the weapon model. So now the engine doesn't need to know that it has to do something after the animation has finished. Only the game needs to be able to know when the animation is finished, so that the game can then call SetSkin() at that point. You could do this in several different ways, for example having an event routing system and let the finishing of the animation be an event, or the engine could provide a function IsAnimationFinished() that the game layer would call every frame.

Your engine will probably have to know that entities exist - but it won't know the specifics of any particular entity, and it won't ever know what a given entity wants to do, except through that entity calls a function in the engine's interface, either to tell the engine to do something or ask the engine for information about something.

I still think you should try to completely divorce your engine from game code. The animation and skinning part can all be accomplished using inheritance in much the same way as the input-handling mechanism i explained earlier...

Your engine could define - for instance - an engineAnimationObject class. This class will contain functions for setting the current skin, the current animation, and define functions for signalling when an animation has completed.

Another crap example:

I read "Game entity factory" in GPG3, where a gameCharacter can own a State and Media manager, while you suggest that the character 'is a' animation object... Well, I certainly cannot immediately decide which is more suitable :)
Let's say we have a total of 20 different characters in a game, and only 5 are in the current map/level. Their skins are indexed from 0 to 5 ofcourse,
So you say, that for each entity I load from the map, the engine calls:
pEntity->setSkin( 0 );
pEntity->setAnimation( IDLE );
Hm, your idea is cool :) I was wondering how to let the engine load and bind only the needed skins to characters, and I leaned towards using a hastable for index correction... blah!
Isn't it better if object composition is used instead? An entity 'snapshot' passed as a parameter to the (state and media manager)->Update()?

Well i don't really understand your reply - because I would need to know a lot more about your engine construction.

A couple of points though:

The classes I explained above are of course totally incomplete examples.

Character definitions could be loaded into gameCharacterType classes from description files (.txt or your own format) which tell the game/engine which skin resource(s) to use, and maps the correct animation resources to the correct animation states.

Then your map editor simply tells the game which description files to load, and all needed resources are loaded from that. You can then create a gameCharacter object by passing in a gameCharacterType object (and other needed parameters, e.g. position) which will define all of the character's behaviour - animation and otherwise.

While inheritance is an absolutely valid way to construct your object system, it can make it brittle. I don't have a good concrete example, so here are a few ugly ones:

* What if you want to have a character made out of two models? Sure, one can be the 'character', and the other an attached model, but that feels less unified than if both models were homogenous.

* What if you want to change an object from a model to a sprite/billboard? If billboard and model are different base classes in your hierarchy, this may not be trivial.

Another possibility would be something more like this (shamelessly stealing Scoots example):

In reality it is very difficlut to COMPLETELY separate the engine from the game. So you must decide on general things vs. specific things.

ENGINE: ANY weapon that "shoots"

GAME: rifle, machine gun, laser gun, etc.

ENGINE: ANY weapon you "throw"

GAME: gas grenade, fire grenade, knife, rock, etc.

ENGINE: ANY entity that can move and animate

GAME: player model, monster model, etc.

The engine should provide generic handling of types of things, without needing specifics about what the thing is. The game should provide the specifics: media (meshes, textures, animation, sounds) and behavior (projectile, ray, bouncing object, etc.).

This is why scripting has become such a big deal, to separate the game-specific stuff out of the engine. The engine knows how to use the script, and operate based on what the script tells it. But the engine doesn't care what model is used, what sound is used, or what animation is used - it just uses them.

But you don't HAVE to use scripting. You can just design your system with two layers of classes. The "bottom" layer is the engine code, and the "top" layer that drives it is the game code. Design in such a way that you could completely strip out the game layer and put another in its place. The way to do that is to expose interfaces to the engine layer in the game layer. So your game code will create and use instances of engine classes, passing pointers of game-specific objects into them.

I was off the discussion so I could read and exeriment, and I got to some ideas.
1. A game session should be clearly declared
2. There must be lists of necessary visual elements like sprites and skins
3. These lists must be maintained by a media manager, initialized each time a gamesession is started.
4. Each entity is best to have a "snapshot", which is also based on the abstract interface + inheritance scheme. This way an entity may use sprites skins or billboards without much trouble. A snapshot contains the info needed to make the sprite in a unique visual state (current frame, some fT, current animation)
5. Each sprite/skin/billboard/etc. visual element must be named uniquely, and for this naming I currently use strings.
6. Each entity must have a 'visual item index', which is to be used only by the media manager
7. Engine, MediaManager and GameSessoin must be global variables/singletons to ease usage, and probably ease 'loose-coupling'
8. (I have no timlemented this yet) The logical behavior should be controlled by a LogcalStateManager, or the GameSession itself. That is, each entity should override parts of this logical behavior, some method Think(...) or Decide(...) or HandleInput(...), which the LogicalStateManager calls with the required parameters.
9. Since this all makes the game a layer on top of the engine, the LogicalStateManager and the MediaManager may communicate, providing a way to make a visual change when logical state changes and vice versa.

In case someone understands what I wrote, please give some feedback. I read your posts time by time, and possibly a new idea will come. Just about a day ago I pinced into the part of the LithTech engine, distributed with the "ContractJack" game. Well, I think what I wrote here is used by Monolith, but if I got it wrong, please inform me!

Here is a class I am currently making in c# that addresses the gameentity/gameobject issue.