Game Engine Structure for Specific Requirement

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Game Engine Structure for Specific Requirement

      Hi! I'm Marc. I've been making game engine/game framework/graphics engine or whatever anyone may call it and I think my engines are very immature as of the moment though it can provide 2d games. Well anyways, I've been doing 2D games as my personal projects/demo. As time goes by, I recreated my 2d game engine from scratch several times and make a structure that will suit me very well. I have read the 3rd edition of this book and attempted to copy the structure of the engine but failed early on. I didn't hesitate to buy this book(considering I can't get a physical copy, so it's just ebook for 59.99$) just to give it a shot again and hopefully to nail my new game engine for 2D games. Now, my requirements/given scenarios are:

      - First, I'm just the programmer
      - I prefer to not use any scripting language. Though I think there's a way to make a tool that acts like it but not flexible at all, that's fine with me, since I still can't get the very sole reason of doing the gameplay on scripts. I do know it theoretically but I still don't know the feel of it.
      - The game I will be making using this engine is 2D only
      - Given in the book, Application layer, Game logic and View layer, Where do I put my Sprite class, Rectangle class, etc. In my previous engine, I use those classes like this:

      Sprite* mBall = mLibrary.GenerateSprite("INGAME", "BALL");

      // render
      mBall->Render();

      Is that the way you render things in the engine structure in the book? I mean, if I use it for 2D game development.

      - I haven't use Smart Pointers in my engine before. I only have SAFE_DELETE macro that does this:

      if(ptr != NULL) { delete ptr; ptr = NULL; }

      Something like that. Will that suffice in my new game engine that will base on the structure taught in the book?


      My goals are:
      - Make an engine for 2d game development.
      - Have a tool for data driven gameplay? or what? I still don't know what to be pulled out of C++ and put somewhere else for the sake of faster prototyping and for designers.
      - And of course, implement the application, logic, view structure from the book "IF" it would benefit it.


      Sorry for my bad english, I mean no disrespect for anyone here. I would very much like to hear your thoughts on my problem.

      The post was edited 1 time, last by marcjoel ().

    • RE: Game Engine Structure for Specific Requirement

      Originally posted by marcjoel
      - I prefer to not use any scripting language. Though I think there's a way to make a tool that acts like it but not flexible at all, that's fine with me, since I still can't get the very sole reason of doing the gameplay on scripts. I do know it theoretically but I still don't know the feel of it.

      It depends on the game, but it's certainly possible to get away from writing your gameplay in a scripting language. At PlayFirst, we mostly used Lua as a UI definition language. All the game logic was in C++ with a bit of Objective-C (these were iPhone/iPad games).

      It's really about faster iteration. When you're making a large game, iteration time can be a killer. It's hard to explain; you usually have to experience it for yourself. As an example, I'm the lead AI programmer at Maxis working on a new Sims title. I've built the concept of opportunity cost into the AI scoring, which means that a Sim takes into account what they'll lose for canceling an action to perform another one. If I'm sitting on the couch and want to make some food, I subtract the cost of my desire to sit from the my desire to get food.

      Now, if I had to reload the game every time I made a small tweak to the code, it would take me hours. I would spend over half my time just loading the game, not to mention compiling the 100+ projects that make up our C++ solution (yes, we have over 100 vcxproj files). Since all of this lives in script, all I have to do is enter a console cheat and it magically reloads all the scripts I changed.

      As another example, which I think I talk about in the book, is that some algorithms are just easier and faster to implement in a scripting language. Even simple for loops:

      Source Code

      1. // C++
      2. std::list<GameObject*> visibleGameObjects;
      3. for (auto it = m_allGameObjects.begin(); it != m_allGameObjects.end(); ++it)
      4. {
      5. GameObject* pGameObj = *it;
      6. if (pGameObj->IsVisible())
      7. visibleGameObjects.push_back(pGameObj);
      8. }
      9. # python
      10. visibleGameObjects = [gameObj for gameObj in self._allGameObjects if gameObj.IsVisible()]
      Display All


      Those seven lines of C++ became one line of Python. It gets even crazier if you need to deal with multiple object types.

      When using a scripting language, you're trading a slower run-time for a faster development time. If you're making a hardcore 3D game, that becomes really important. If you're making a simple 2D game, you could probably make it a lot faster by leaning heavily on a scripting language. In fact, you could write the whole thing in a scripting language and your development time would probably cut in half (at least).


      - Given in the book, Application layer, Game logic and View layer, Where do I put my Sprite class, Rectangle class, etc. In my previous engine, I use those classes like this:

      Sprite* mBall = mLibrary.GenerateSprite("INGAME", "BALL");

      // render
      mBall->Render();

      Is that the way you render things in the engine structure in the book? I mean, if I use it for 2D game development.

      It depends on what you mean by "sprite". All game objects go through the component system and each actor is really just a composite of different components. These components are configured through the level editor, which generates the necessary XML.

      The rendering side of it is just another component, the Renderable component in this case. The renderable component creates a scene node which is sent to the scene. The scene is owned by the human view.


      - I haven't use Smart Pointers in my engine before. I only have SAFE_DELETE macro that does this:

      if(ptr != NULL) { delete ptr; ptr = NULL; }

      Something like that. Will that suffice in my new game engine that will base on the structure taught in the book?

      Well, the SAFE_DELETE macro isn't a smart pointer, it's just a way to NULL-out pointers after they've been destroyed. (By the way, you don't need the if statement in the macro, C++ guarantees that it's safe to call delete on a NULL pointer.)

      A smart pointer basically ref counts the pointer for you, so that when no more references exist, it automatically destroys the pointer. The advantage of a smart pointer is that you can have one or two authoritative owners of the pointer, each which have strong references (in C++ 11 it's called a shared_ptr) to the object. Any system that needs to maintain a pointer but not ownership of the object has a weak reference (weak_ptr in C++ 11). When all strong references go away, the object is destroyed and all weak references are marked as invalid. Every system that uses a weak reference tests to see if it's still valid before using it.

      In GCC4, we use smart pointers for actors. We can pass around weak references to actors or components and when the actor (or component) is destroyed, we can clean up the weak references.

      interfaces.h is where I define the various typedef's used for the actor/component system, including all the smart pointers. Search in the code base for some of these typedefs (like WeakActorPtr) to see how they're used.


      - Have a tool for data driven gameplay? or what? I still don't know what to be pulled out of C++ and put somewhere else for the sake of faster prototyping and for designers.

      Anything and everything that can change. Locations, hit points, item definitions, AI configurations, etc. Beginning programmers tend to hard-code everything. Then you generally get to a stage where a bunch of stuff is defined in const's. After a while, those get pulled out into XML or another data file. Eventually, you get to the point to where EVERYTHING is defined in data.

      For example, on the Sims, we have absolutely no object-specific code. There's no class for the toilet or the treadmill or the TV, it's all defined 100% in data. A toilet is just a collection of interactions that be run (use, clean, repair) which are pushed based on object state (also defined in data). Even things like making sure women always sit down to use the toilet is done completely in data. Designers are in total control of how objects work and can make completely new objects with totally unique behavior and animations without touching a single line of code.

      -Rez
    • This is very informative for me :)

      What I meant by Sprite is the image that you will display in the screen. Where would I implement it? In my previous engine my Sprite::Render() is simply submitting the 4 vertices, 6 indices, Texture ID of a specific sprite.
      Then after right before the DrawIndexedPrimitive, I make vertex and index buffer for those sprites who submitted for the current frame. So where will I put these?

      Regarding the scripts, I'm not planning on using Script Engines so I'm left with making my own right? but, is there a way that I don't have to deal with compiler design? Like just a list of available actions, put parameters on it, etc. I remember reading a book with it. I just forgot what book/article/website that was. What I mean is, can i build a tool that is easier to make than a scripting language. It's okay for me if it's not that flexible even though it can only just support 1 genre or even smaller than that. Can you enlighten me how to go about it? I don't know if I know already that I'm only confused or I'm just missing something that I haven't realized yet.

      Lastly, let's say I want to make a 2d Hidden Object game or a 2d puzzle/adventure game like Stray Souls without the Hidden object scenes or like Evony Online without the internet stuffs. Consider these not having any multiplayer capabilities. How would be the engine design look like and how am I going to make the scripting-like thingy?

      By the way, I'm using VS2008 and DirectX 9. Regarding the pointer that is NULL can be deleted. I remember my program crashes whenever I try to delete a NULL pointer.. ?

      The post was edited 1 time, last by marcjoel ().

    • Originally posted by marcjoel
      What I meant by Sprite is the image that you will display in the screen. Where would I implement it? In my previous engine my Sprite::Render() is simply submitting the 4 vertices, 6 indices, Texture ID of a specific sprite.
      Then after right before the DrawIndexedPrimitive, I make vertex and index buffer for those sprites who submitted for the current frame. So where will I put these?

      The component itself probably shouldn't know anything about indexes, since those are specific to DirectX. You generally want to abstract all that away. I would definitely look at how the render component is implemented and how it interfaces with the scene and human view. You can see this behavior in RenderComponent.cpp with the various sub-types of render component.


      Regarding the scripts, I'm not planning on using Script Engines so I'm left with making my own right? but, is there a way that I don't have to deal with compiler design? Like just a list of available actions, put parameters on it, etc. I remember reading a book with it. I just forgot what book/article/website that was. What I mean is, can i build a tool that is easier to make than a scripting language. It's okay for me if it's not that flexible even though it can only just support 1 genre or even smaller than that. Can you enlighten me how to go about it? I don't know if I know already that I'm only confused or I'm just missing something that I haven't realized yet.

      You should absolutely not write your own scripting language. You could certainly build a very simple system like a list of actions, but you still have to write something that parses it into usable constructs. As your game progresses, you'll want to add new features until eventually you'll have an actual scripting system, only it's much less featured than a real scripting system, more buggy, and took you 1000 times as long to write.

      I'm curious why you're so against adding a system like Lua into your engine. It sounds like you want the flexibility of a scripting system but don't want to add an existing one, which doesn't make sense to me. I integrated LuaPlus into Game Coding Complete 4 in less than a day. If I were to build the bare minimum of what you're proposing as a light scripting system, it would probably take me a week.

      I would either integrate a real scripting language into your game, or skip it altogether. Building a crippled half-language into your engine is not worth the effort.


      Lastly, let's say I want to make a 2d Hidden Object game or a 2d puzzle/adventure game like Stray Souls without the Hidden object scenes or like Evony Online without the internet stuffs. Consider these not having any multiplayer capabilities. How would be the engine design look like and how am I going to make the scripting-like thingy?

      I don't understand the question.


      By the way, I'm using VS2008 and DirectX 9. Regarding the pointer that is NULL can be deleted. I remember my program crashes whenever I try to delete a NULL pointer.. ?


      Your program shouldn't crash when calling delete on a NULL pointer. If it does, your pointer probably wasn't NULL (maybe you just tried a double delete?) According to the C++ standard, if the pointer is set to NULL, calling delete will have no effect. This definitely works in Visual Studio 2008. I just tried it out with the following program:

      Source Code

      1. #include <iostream>
      2. int main(void)
      3. {
      4. char* pTemp = NULL;
      5. delete pTemp;
      6. }


      This program will do nothing.

      -Rez