   Engine/Game Interface Discussion
  I'd like to get a discussion going on how others achieve a good interface between the engine core and the game code. I keep thinking of different ways to go about doing it but each time something comes up making me disregard the idea. So I want to see what other have done to hopefully help point me in the right direction.I'll start off with a few question that everyone might like to respond to and see how we go.1. Do you use a Scene Graph? And if so what do you use it for exactly? Hierarchical organization of objects? Culling? 2. How do you interface the scene nodes from the engine to the game code to allow the user to create user defined game objects?3. Are your game objects/entities the same as a scene node or are they treated differently? eg. INode for SG in engine, IEntity for game objects4. In terms of scene management and rendering, how do you keep the rendering specifics away from the user game code but still allow the user to create an entity that uses various "renderables"?5. In terms of networking, how do you split up the server and client code for game objects? Do you have separate lists for each and each object derives from eg. IClientEntity or IServerEntity? These lists are then managed internally by the engine?Cheers.   
  Hi,Here is my take on your questions:1. Do you use a Scene Graph? And if so what do you use it for exactly? Hierarchical organization of objects? Culling?In a graphics engine, I use a scene graph. I use it for culling, display and user interaction (especially ray-model intersection). Note that in my case I have an engine for card and hex based wargames. I could also use the scene graph for advanced interactions (model-map collision, model-model collision).2. How do you interface the scene nodes from the engine to the game code to allow the user to create user defined game objects?In fact, the scene node is just a representation of your game object. I encapsulate the representation into the game object. A game object is just a structure holding the object data and a reference to the object representation. Below is a pseudo C++ code example to illustrate.class MyGameObject: public IGameObject //basic game object from your game engine{protected:ISceneNode* _ObjectRepresentation;public:MyGameObject():IGameObject(), _ObjectRepresentation(0){};~MyGameObject{};void SetObjectRepresentation(ISceneNode& pSceneNode);//override IGameObject base methodsvoid SetPosition(int32 pX, int32 pY){IGameObject::SetPosition(pX, pY);if (_ObjectRepresentation)_ObjectRepresentation-&gt;SetPosition(pX, pY, [Z deducted from a game map])};3. Are your game objects/entities the same as a scene node or are they treated differently? eg. INode for SG in engine, IEntity for game objectsScene nodes and game objects do not cover the same concept: - scene nodes are used for display only.- game objects hold the objects datas for game rule interaction.In an OO engine, they should be two separate interfaces.4. In terms of scene management and rendering, how do you keep the rendering specifics away from the user game code but still allow the user to create an entity that uses various "renderables"?To me it is hidden in the game engine interface. The game developper should only know about game resources. His only concern is to be able to load a game resource and put it on a map. Again a simple example of a scenario editor with an object interface.//main Game object interfaceclass IGameObject {protected:uint32 _ID;public:IGameObject(uint32 pID):_ID(pID){};virtual ~IGameObject(){};uint32 GetID(){return _ID;};virtual void SetPosition(int32 pX, int32 pY) = 0;virtual void SetOrientation(int32 pOrientation) = 0;virtual void SetAnimation(std::string& pAnimationName) = 0;virtual void PlayAnimation(bool pPlay = true) = 0;}//main scenario editor interface//is a factory of game objects and graphics associationclass IScenarioEditor {protected:std::map&lt;uint32, IGameObject*&gt; _Objects;public:IScenarioEditor(){};virtual ~IScenarioEditor(){};//creates an object with a unique ID and a graphics representation.//it is the editor which will internally create the scene node and associate//to the specialized game objectvirtual bool CreateObject(const OBJECTTYPE pType, uint32 pID, std::string& pGfxFilename) = 0;//retrieve the game object interface from the editor arrayvirtual IGameObject& GetGameObject(uint32 pID) = 0;}5. In terms of networking, how do you split up the server and client code for game objects? Do you have separate lists for each and each object derives from eg. IClientEntity or IServerEntity? These lists are then managed internally by the engine?Could you precise your idea of networking ? In my games, game object have a single interface. The client is on the user computer and is responsible for rendering the game, managing the user interaction. The server is responsible for handling game rules interaction, and AI.The simplified flow is:- the client loads up the scenario data.- the client requests to the server the creation of a scenario (map loading and object creation).- the server loads up the scenario data.- the server evaluate in a separate thread the object interactions and the rules.- the client at each step queries the server about game object updates and game state machine update.- the client once it has received answers from the server updates its own copy of game objects and modifies the game display in consequence.Side noteMy own experience is based on turn based games (this shows in the examples I have given). I have realized a simple Gfx engine (for educational purpose) and am finishing a simple card and hex based wargame engine (one game already realized with this engine so far). My side note concerns your aim. If you are a lone programmer (like me), trying to develop a game and a graphics engine (with networking) is a huge consuming task (even on one platform). In this kind of project, developping the graphics engine is the first task: this means you won't start the game engine part until you are confident enough in your graphics engine (evaluate this to a few months if you are looking for a *very* simple graphics engine - no lighting, no advanced gfx features, basic sprite/model loading, ray-sprite/model intersection).In my own experience, my simple graphics engine was sufficient for a few games. Still, it was never up to date with the Graphics libraries interfaces (DirectX, OpenGL) and hardware (from 32bits to 64bits). Maintaining a graphics engine and a game engine was too much for me. I decided to use a free existing graphics engine and concentrate on my wargame engine.From your questions, I seem to understand you try to develop both engines. If this is the case, my word of advice is to focus only on your game engine and use existing freeware libraries to for the other parts (I personnally chose Irrlicht for Gfx and SFML for networking). The advantages are:- no maintenance of Gfx and networking interfaces,- better focus on the game engine,- easier to get independance of the game engine interface from the rendering and networking interfacesGhostly yours,Red.   ;  Thanks a lot for the thorough response!Quote:In a graphics engine, I use a scene graph. I use it for culling, display and user interaction (especially ray-model intersection). Note that in my case I have an engine for card and hex based wargames. I could also use the scene graph for advanced interactions (model-map collision, model-model collision).I've read in a lot of places that a scene graph shouldn't be used for culling but rather some other spatial tree like octree/quadtree should be used and could be a node in the graph. Is this what you have done or is does your scene graph do everything?Quote:Questions 2, 3, 4This has actually helped clarify a lot. In that the scene graph is just used as a graphical sort of representation of objects and they only contain a pointer to a node and the GFX engine handles all the nodes internally.Quote:Could you precise your idea of networking ? In my games, game object have a single interface. The client is on the user computer and is responsible for rendering the game, managing the user interaction. The server is responsible for handling game rules interaction, and AI.My idea of networking was to split the game code into a server and client DLL. The server DLL would manage a list of all the server side game objects and only really handles all the physics etc. The client DLL handles the client side game objects and mainly handles the displaying of things specific to the client. This idea is taken from how Half-Life's SDK is setup. It allows the user to simply mod two DLLs to create a game. The DLLs interface with the engine.It would be far simpler if there was only one game object list that both client and server used but I'm not sure if that is possible as I wouldn't want display specific things to be on the server side, nor would I want physics based stuff on the client.With your IGameObject interface would you only contain functions relevant to both client and server? Then in each DLL you would have a client or server side implementation of the same game object which would implement specifics?I understand your side notes but this is a hobby project for my own learning so I want to use the least amount of libraries. On that note though I will be using libraries for physics and networking, just the engine core and GFX I will be writing myself because that the areas I'm interested in learning.;  Hi,Regarding the use of scene graphs, it all depends on your game display. I used a simple scene graph and did not use a quad- or octree because I wanted a simple Gfx engine rendering tiled terrain. However, all nodes of my scene graph have a bounding box enclosing the node and its children after transformation.My rendering loop was:1- compute all node positions2- update all nodes AABB3- recursively compare each node AABB with the frustum: if inside frustum and has a rendering object, add the rendering object to the rendering queue.4- sort the rendering queue by texture, material, rendering state (Solid, transparent, lit solid, lit transparent) and effect (light, fog, skybox).5- display the rendering queue.I have low poly count objects with very few holes and the map was tiled (each tile corresponded to a node). Thus the engine was completely adapted to my needs. However, it would not be able to handle quake terrain (a single terrain node with high poly count). This case definitely calls for an octree.All in all, it depends on what kind of game you are doing and what kind of object you want to render. For your information, I wrote an article at GameDev on my own hobbyist game engine (look up my profile): it might be of interest to you.Regarding networking, it is a huge can of worms of its own. If you have never programmed a networked game, it is quite an undertaking of its own. Moreover, you will need to understand basic multithreading (with its hard to identify bugs). However, it is good you chose to use a library for networking: using OS networking APIs is a real pain for a hobbyist.Consider that the client and the server are two different programs on their own. Thus your game object list will *never* be common to the client and the server. The server will hold one copy of the game object list and the client another. The role of the client is to check at regular intervals the game object states in the server.My own way of handling game objects would be to create two interfaces: a server game object interface and a client game object interface. The actual game objet will inherit from both interfaces: this keeps all development in one file but let you choose the interface you need according to which program use the game object.class IClientGameObject; //virtual interfaceclass IServerGameObject; //virtual interface//actual implementation of a game objectclass SpecializedGameObject: public IClientGameObject, public IServerGameObject;This kind of architecture is nice but has a drawback: you cannot have common methods between IClientGameObject and IServerGameObject. You will need to differentiate the method signature and store data in the actual Game Object class. Here is an example below:class IClientGameObject{public:virtual uint32 GetClientID() = 0;};class IServerGameObject{public:virtual uint32 GetServerID() = 0;};//actual implementation of a game objectclass SpecializedGameObject: public IClientGameObject, public IServerGameObject{protected:uint32 _ID;public:uint32 GetClientID(){return _ID;};uint32 GetServerID(){return _ID;};};I wish you good luck for your developments.Ghostly yours,Red.   ;  Thanks again for such a thorough reply :D I think you've actually answered my questions and helped me with the design dilemmas I was having. In a previous game I actually had two interfaces for client and server objects and separate lists for each like you mentioned. This worked quite well. The only difference was to save some confusion I didn't inherit my objects from both interfaces. Instead I had a .h/cpp pair in the Client DLL, and another in the Server DLL. They used separate interfaces IClientEntity and IServerEntity. I was thinking of using the same approach in the next revision of my engine but I wasn't really sure if it was a good way to go and if other people have done it that way before.By the way, I had actually read that article before and found it useful. I didn't realise you were the one that wrote it though till now. Thanks for your insight :)   