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 completely different 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]

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.

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).