   Frustration with game programming
  I don't mean programming in general, or even game-related programming. I mean the process of actually writing a game. I'm incredibly frustrated with it. For the last couple months I've been working, with others, on a game. We have a great engine, with fairly decent OO architecture. It renders MD2 models animated, Quake 3 maps, there's a slick input layer, etc. Not the biggest feature set, but all in all a decent engine to work with.Engine != Game.Actually writing a game is a completelydifferent matter, and what's worse, there aren't any tutorials. Of course you can't write tutorials; what you do is way too case dependent and generally nebulous. But I don't know how to build a lot of the internal infrastructure, I don't know how to set up simple things like going from a game's menu to the actual game, etc. The whole "main loop" concept seems to fall apart with more complicated setups like menus with actual submenus, the various things you could be rendering on screen at once.There are plenty of resources on writing Tetris or Pong or whatever; they don't count. How do you get to writing an actual game, with all the trimmings? Is it just that I don't have the sheer software engineering knowledge I need to do this? Last time I tried, the whole thing's global variable count went through the roof. There was bool g_Server, bool g_InMenu, enum g_MenuState, bool g_Running, bool g_AppActive, string g_PlayerName, CTimer g_Time, etc. That doesn't even include all the engine class declarations; the list just goes on and on and on. And then I was trying to extern those all over the place...everything was falling apart at the shoddily sewn seams. Then I go back to the engine, writing design changes and kidding myself that the engine is the problem, when it isn't. The problem is that I have no idea how the hell to move from an engine to a real game.Advice?[edited by - Promit on March 22, 2004 5:39:19 PM]
  I''d wager that most games, at the highest level, are state machines. So the main "global" (or just in your main singleton game class, this is ignoring file managers, engine, etc.) is a single variable that keeps track of which state you are in. These are high level states such as STATE_INITIALIZE, STATE_MENU, STATE_PLAYING, etc. There could be sub states within those states but just let subclasses of the main game handle those so they are hidden from the main structure. Externing globals is DEFINITELY not something you want to do here as you will find that even if you get your code to work it will be a nightmare to debug and maintain. If you have designed your object hierarchy well then adding new types of objects, such as a menu or a new particle effect shouldn''t really be high on the list of difficult things to do. Then, for the final piece of puzzle you will have basically two loops - one that renders and one that runs the game logic and controls the states. Rendering may or may not care about what state it is in (the better designed the OO the more it wont care, in my opinion) and then the only piece of code handling state transitions is the game logic loop which at the simlpest level is just a switch statement based on the game state.If you haven''t read "Design Patterns" by Gamma et. al. then I highly recommend it. It may not seem that the OO design patterns they describe can be applied to games but if you really think about it many of the patterns listed can be used to design robust game (as well as engine) architectures. ;  Might want to check out Doom, or any other famous game''s source, to see how they handled this. I forget if Doom was written in C++ or ASM...In general, find some game that is fairly decent and examine the source from that. ;  The problem with the sources I''ve looked at (Doom, Quake, Quake 2, etc.) are that they''re in C and really archaic at times. I can''t get a sense for the overall architecture of them, at all.I''m going to buy some book in 8 days for bday, if you guys have any recommendations. ;  There are books out there like "Programming Role Playing Games for DirectX" by Jim Adams which will give you ideas on what to do for role playing games such as items, inventory, character attributes, etc. I liked that book for it''s DirectX information more than the role playing information because I''m not making an RPG, and the only RTS type books have had really poor ratings...Game Dev''s Game Programming Books section has ratings for various books and comments from users to help you choose which book to get. ;  just some idiotic idea, why not something like (sorry that the code is java-like):myMenu.setVisible(bool state);  and in it, you handle sub menus like:this.setVisible(false); //where this is the current menuthisOrThatSubMenu.setVisible(true);  and to go back:this.setVisible(false); //where this is the current (sub)menuparentMenu.setVisible(true);  and when click to start a new game:this.setVisible(false); //where this is the current menuGameSession gameSession = new GameSession(Data requiredData);  Or to resume an ongoing one:gameSession.setRunning(false);gameSession.setVisible(false);myMenu.setVisible(true);  maybe i'm just a bit dumb, but it looks to me to be very simple, nicely OO and well working way. [edited by - misterx on March 22, 2004 6:19:25 PM];  The menu was just a minor example. I mean real menus and GUI, like in MechWarrior 4 or something. Although to be honest, this problem is practically solved for me.Mostly I can''t seem to get a coherent design model for the game as whole.quote:So the main "global" (or just in your main singleton game class, this is ignoring file managers, engine, etc.) is a single variable that keeps track of which state you are in. These are high level states such as STATE_INITIALIZE, STATE_MENU, STATE_PLAYING, etc. There could be sub states within those states but just let subclasses of the main game handle those so they are hidden from the main structure.So how do I express the state machine? Should I construct a state base class and derive state types from them? (Using a pluggable class factory model, I guess.)quote:Then, for the final piece of puzzle you will have basically two loops - one that renders and one that runs the game logic and controls the states.Do these run at the same rate, or in the same thread? So far my physics, input, etc. has all been tied to the same time cycle as rendering, and it''s been starting to cause problems, especially with networking (60 data sends a second is bad).;  Please do not take this as negative criticism. Now days it is very easy to throw together a relatively sophisticated engine and actually believe that you did it all. There are tutorials and even entire game sources available for assimilation. I have little doubt that you understand exactly what each part of your engine does. I have no doubt that a good part of the code you are using for your engine, was not written by you. An extremely relevant part of programming is understanding what the final goal will be, and then designing your program from the ground-up to accommodate this goal. Did you begin by just following a tutorial to program a MD2 Loader, or perhaps the Quake 3 map? And then you expected to build a game off of this? The first thing you should have done is to have clearly written out your goals. Whether you do this in a design document or just a chronologically ordered list is irrelevant. You then should have followed this list precisely. One of the first things you would have noticed is that your game WILL be a state machine. Your "slick input layer" should have a way of easily changing its state, ie- key maps. Your engine should render based on a specific state. Everything will be a state. This becomes very clear when you actually write out what you want the engine to do.To cut to the chase, you need to program bottom up, not top down. ;  When I program, I find 2 things in a game.1.  Menus.  The main menu, the save/load functions, the options menu, etc.  These are easily created, and can be made pretty much on-the-fly.2.  In-Game action.  This is just a combination of input/AI/rendering.  Make functions for each, and slap them together.Really, its not very glamorous.  Just think about what you need to do at each stage of the game and implement it.  There''s not much you can learn about putting the game together:  You just have to do it yourself and realize that its just slapping together menus, finite states, and input/AI/rendering functions.By the way, I felt the same as you when I started.-Gauvir_Mucca ;  ...i was also talking about real menus or GUI or whatever else. 