Help understanding chapter 5

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

    • Help understanding chapter 5

      Let me preface this with letting you know that I am very new to c++ and programming in general, so my whole thought process may be completely wrong. I have been going through chapter 5, and I have to be honest, I am a bit lost. It seems to go through examples very fast, and I am struggling going over the source code, and linking them to what I see in the book. Here are my questions, please be gentle:

      1. There are 3 files in the source code. There is GameCode.h, GameCode.cpp and GameCode4.cpp. GameCode.cpp is quite long, and has a lot of functions in it. I see it is where the members for the GameCodeApp is set up, however, I am a bit confused. Why does it not include GameCode.h? And how does it have access to those definitions without the includes? In fact, I can't seem to find anything that includes the GameCode.cpp either, it seems everything is running from the GameCode4.cpp, but I feel like I am just missing a key something.

      2. I see that there are a lot of includes files that the book has not gone over yet. I am looking at this book as kind of a straight up tutorial, and would like to be able to compile my code to check if I have syntax errors and typo's as I go. Typing out the code helping reinforce the concepts, and helps me understand how it all comes together, then I have my own projects where I try out the ideas in other ways. However, in order to get it to compile, do I have to go through all the included files? For example:

      GameCode.h has:


      #include "../Mainloop/Initialization.h"
      #include "../GameCode4/BaseGameLogic.h"
      #include "../Graphics3D/SceneNodes.h"
      #include "../UserInterface/UserInterface.h"


      And GameCode.cpp has:

      #include "GameCodeStd.h"

      #include "Dbt.h" // required for DBT_DEVICEREMOVECOMPLETE

      #include "../MainLoop/Initialization.h"
      #include "../Debugging/MiniDump.h"
      #include "../GameCode4/BaseGameLogic.h"
      #include "../Graphics3D/D3DRenderer.h"
      #include "../EventManager/EventManagerImpl.h"
      #include "../Network/Network.h"
      #include "../LUAScripting/LuaStateManager.h"
      #include "../LUAScripting/ScriptExports.h"
      #include "../LUAScripting/ScriptProcess.h"
      #include "../ResourceCache/ResCache.h"
      #include "../ResourceCache/XmlResource.h"
      #include "../UserInterface/UserInterface.h"
      #include "../UserInterface/MessageBox.h"
      #include "../UserInterface/HumanView.h"
      #include "../Utilities/Math.h"
      #include "../Utilities/String.h"
      #include "../Actors/BaseScriptComponent.h"

      Now, I have tried to just power through chapter 5, just skimming the book code examples, hoping that it will all come together, but I still feel a bit lost, as if I am again, missing some key thought process.

      3. One last question: In GameCode.h I see this near the start of the file:


      class FontHandler;
      class BaseUI;
      class EventManager;
      class LuaStateManager;
      class BaseSocketManager;
      class NetworkEventForwarder;
      class HumanView;


      I understand that these classes are being declared, but not defined. However, some of these classes are never mentioned again, such as
      class FontHandler; in this file, or in the GameCode4.cpp. Is this a class that other files created will rely on? And where exactly are they defined? I can't seem to find anything that defines them, and references this file.

      Thank you for your help and patience, a lot of my questions may just show my total lack of understanding, but I appreciate the help as I work through this.
      Birdemic

    • 1) GameCode.cpp provides the implementation for GameCodeApp, who's declaration is found in GameCode.h. GameCode.cpp has access to GameCode.h through GameCodeStd.h (line 209 includes GameCode.h in that file). Everything is running from GameCode4.cpp. It's the main file (or at least provides the entry point for the program). You don't have to include GameCode.cpp as you only need the declarations which are in GameCode.h to use them.

      2) This book is not really a tutorial, but more of a presentation of separate concepts that have a unified theme (game engines). For the engine to fully run, it needs all the includes. You could probably take out some features and it would still run, but it can be difficult to tell how some files will affect others unless you know how it all interrelates.

      3) I'm not sure about FontHandler (couldn't find any other mentions of it other than in GameCode.h and UserInterface.h), but the others are all defined elsewhere (for example, BaseUI is only line 75 in UserInterface.h).


      I don't know where you are at in your learning/understanding, but powering through this book will not help much. A lot is covered and discussed in each chapter. It takes time and practice to absorb it all. If you are really new you may want to start with a general intro to C++ book (others can probably recommend some good ones, I can't find my list of books right now). If you feel you are far along enough then perhaps just take it slower and feel free to keep asking questions on here.

    • Thank you for the help. I literally just spent 3 hours going over different things, and totally missed that. I guess I just assumed that all the includes for the GameCodeStd.h were at the top of the file.

      I am currently reading The C++ Programming Language by Bjarne Stroustrup, as well as many many online articles. I think sometimes I get so focused in on a problem I am having that I forget to look at the bigger picture. I have a list of book I want to buy as well, my amazon wish list has 35 books on it at this time. I'll post other questions that I have, and try to think things through before I post something that doesn't make sense, but thanks for pointing out that line.

      In this book specifically, do you think it is advantageous to go through chapter by chapter? Or do you think its better to skip around? And when it comes to the source code, do you have any tips for tracking down dependencies? Other than just going through all the header files one by one? And then reading the book, and asking questions as they come up?

      Also, do you have any book that have helped you wrap your brain around not only game programming, but even just programming in general? I feel like for ever hour I spend learning, I have enough questions to fill up 4 more.

      Thanks again
      Birdemic

    • Originally posted by birdemic
      In this book specifically, do you think it is advantageous to go through chapter by chapter? Or do you think its better to skip around?

      The book is generally designed to go through chapter by chapter, especially in the beginning. There's some point where we say "now you have enough to make something simple". I think it's around chapter 9 but I don't recall exactly. I would suggest reading through to that point. By then, we've discussed all the components of the core game engine architecture. Everything after that adds more to that same architecture. You can probably safely skip around at that point.


      And when it comes to the source code, do you have any tips for tracking down dependencies? Other than just going through all the header files one by one? And then reading the book, and asking questions as they come up?

      The search tools in Visual Studio are your best friend. When you work as a professional engineer, you sometimes end up spending more time reading code than you do writing it. If you see a function or class and you're not sure what it's for, you can search the codebase for it and find other places that it's used. You can also look up the function/class definition.


      Also, do you have any book that have helped you wrap your brain around not only game programming, but even just programming in general? I feel like for ever hour I spend learning, I have enough questions to fill up 4 more.

      The source code may seem massive (it's 38,356 lines of code at last count, not including any 3rd party libs) but it's actually extremely small by most game standards. By comparison, The Sims Medieval had somewhere around 2 million lines of code. The only way to really understand something this massive is to break it down into components. First, try to grasp the high-level architecture. Don't worry about FontHandler or anything else, just understand how the application, logic and views all fit together. Understand the role of each one and how they play with each other. Then you can dig deeper into one of those systems and understand the components that make it up. Then you rinse and repeat.

      One more piece of advice, and this one is really important. Stop reading. This is especially critical if you're new to programming. A really common mistake new programmers make is that they buy a whole stack of books on programming and video game development. The logic is that if they can just get through those books, they'll be good enough to start making games. That's completely incorrect. You need to actually make stuff. For every hour or so you spend reading a chapter in a programming book (especially ours), you should spend TEN hours writing code. There is absolutely no other way to get better at programming. You have to practice your craft.

      Artists have a thing they call pencil mileage. It represents how many miles they've drawn with their pencil and it directly determines how good they are. You CAN'T read art books and expect to get better, you have to actually practice drawing outside of your comfort zone. I have a friend who's really good at drawing women, but she can't draw men very well. She got that feedback at GDC this year. Guess what she's going to spend the next few months doing?

      Programming (and any real skill for that matter) is the same. Make stuff. If you don't, you'll never ever get better. Once you're comfortable with the stuff you've learned, then you can go back read another chapter and apply the new thing you've learned. Then it's back to the compiler for another 10 hour sprint of making sure you understand how that concept works.

      -Rez

    • RE: Help understanding chapter 5

      Thanks for the feed back. I have been drafting up some other projects to work on. I think I have been operating under the thought that if I can build a sort of default initialization, and some default D3D stuff, then i can spend more time programming in that, and grasp things as they come up. Do you think that its better to just practice what I know about starting a game, even if its not the best practice for initialization? I am having a hard time with all the steps in the book, and getting them all to work, but I can write some simple stuff, that I enjoy doing, I just don't know how well the code is written. My project right now is Pong, and I just finished a console based tic tac toe... But I will take your advice and spend a lot more time just making things. thanks again for the insight.
      Birdemic

    • RE: Help understanding chapter 5

      Originally posted by birdemic
      Do you think that its better to just practice what I know about starting a game, even if its not the best practice for initialization?

      Here's the thing, your first 20 games will probably be awful. You really have to do it and be burned by the wrong architecture before it really starts time click. I say just go for it.

      Now, that doesn't mean to stay in your comfort zone and just do what you know either. You always want to be challenging yourself and that's where books like this one can really help. But at the same time, you can't let the fear of failure or doing something wrong scare you. How else are you going to learn?

      Also remember that there's a big difference between "practice" and "play". Practice is when you're out of your comfort zone and really challenging yourself, often with something you might not enjoy. Play doing what you know and are comfortable with. Play does NOT make you better, only practice will make you better. Play is good for keeping it fun, but make sure you're always challenging yourself. When ever I start a new project, I always design a feature that will challenge me and push me out of my comfort zone. I also design features that will let me get in there and play so that I have something fun and interesting for when I get frustrated.

      -Rez

    • I've been using the book as more of a "solutions manual" rather than a step by step guide, and I think it's a pretty good way to go about it.

      For example, the first things I started with was a text based game so I made a class to handle text strings. I said, OK, I need an identifier for the programmer so I'll use an enum. Then I said it should map to an output string, but I might want an error code if the string is an error.

      typedef std::pair<std::string , UInt> StringCodePair;
      std::map< enum OutputStrings, StringCodePair> m_stringMap;

      It was OK for a while, but eventually problems started happening. I made entries directly in the constructor which just got sloppy. If I accidentally forgot to update the enum I would overwrite strings! I would always have to enter an error code even if the string wasn't an error. It was pretty hard to make sure I had a unique error code, and if I did it was hard to give different strings the same error code when it made sense. I would have to recompile the whole program if I made a new string, etc.

      Meanwhile, GCC parses an XML file for strings. It still uses the same kind of map I have but it basically eliminates every problem I had with entering strings and using enums. I could check for duplicates or give default error codes pretty painlessly and I didn't have to recompile every time.

      So, I think it's one of those things where its more important to know what NOT to do, rather than know what to do. Without the book I probably would have never thought of parsing an XML file, and now I wouldn't do it any other way.

      I say just try to have fun with it and make a game however you want. Then use GCC to see how you could improve stuff and give it a shot on your next game, or the next revision of the same game.

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

    • Thanks for the pointers. I have been thinking of a text based game that would be really good practice for, and then rendering out a gui for in opengl and directx, just for practice in those api's. I also am thinking of just starting at the beginning, making pong, then tetris, and so on, just for practice.

      I think you are right Rez... I need to just break some stuff for a while. Thanks for very much for the reassurance. There is this stigma about developers in the IT world that they always know what they are doing, and I think that it comes from the interviews they give. Its pretty intimidating, but it would make sense if they were only questioning you on the problems they were facing, or just faced to see how you would think about it, not to see if you know everything. I'll keep all of this in mind as I go forward, thanks again.
      Birdemic