Archived

This topic is now archived and is closed to further replies.

Promit

Frustration with game programming

Recommended Posts

Promit    13246
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]

Share this post


Link to post
Share on other sites
technic    139
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.

Share this post


Link to post
Share on other sites
TsukasaZero    122
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.

Share this post


Link to post
Share on other sites
Promit    13246
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
misterX    144
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 menu
thisOrThatSubMenu.setVisible(true);


and to go back:
this.setVisible(false); //where this is the current (sub)menu
parentMenu.setVisible(true);


and when click to start a new game:
this.setVisible(false); //where this is the current menu
GameSession 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]

Share this post


Link to post
Share on other sites
Promit    13246
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).

Share this post


Link to post
Share on other sites
haro    502
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.

Share this post


Link to post
Share on other sites
Haytil    525
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

Share this post


Link to post
Share on other sites
Promit    13246
I know you don''t mean this in a negative way, but I also feel obligated to counter this.

quote:
Original post by haro
I have no doubt that a good part of the code you are using for your engine, was not written by you.


I''ve definitely taken other people''s algorithms and methods of doing things. I have made a point, however, of writing it myself, even if it meant turning on transparency and copying it off a webpage. More importantly, I''ve made a point of understanding what is going on so that I could rewrite it by myself, maybe with difficulty, but I could do it.

quote:

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?


I''ve been doing this for a long time (engine building, that is). This engine sports my second MD2 loader, second Q3 map renderer, etc. It''s not the first time I''ve written any of it. I''ve had various resources around while I did it, but again I did it myself, and I can rattle off the Q3 BSP and MD2 file formats if I need to.

quote:

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.


Probably true.

quote:

Your "slick input layer" should have a way of easily changing its state, ie- key maps.


...which it does.

quote:

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.


The problem is how to organize those states. Like I pointed out earlier, these states were quickly turning into a forest of global variables.


I''ve been thinking, would be be a decent idea to try and emulate Half-Life? I don''t have the full source to the game, of course, but I do have the SDK for modding, which gives me significant insight, as well as the Q2 source. Things like the cvars (essentially their state machine) and all...just an idea.



Obviously I haven''t put a huge amount of thought into this. I do find that this sort of conversation helps solidify somewhat nebulous concepts though, so thanks to all of you.

Share this post


Link to post
Share on other sites
turbotony    134
I think that fustration is part of the process of building a game, actualy i haven''t make a whole game, but for my degree tesis i''m making a collision detection library (fully object oriented). At the begining i fell so frustrated because the complexity of library design, at the point i almost quit, but i didn''t. Now it''s almost done and the frustration is gone (i hope forever).

My advice to you is that keep working, one small step at time, at the end you will be proud of yourself.

Share this post


Link to post
Share on other sites
haro    502
quote:
Original post by Promit
I''ve definitely taken other people''s algorithms and methods of doing things. I have made a point, however, of writing it myself, even if it meant turning on transparency and copying it off a webpage. More importantly, I''ve made a point of understanding what is going on so that I could rewrite it by myself, maybe with difficulty, but I could do it.



That is actually exactly what I meant. Even though you may understand the code you are using, writing it entirely by yourself is a completely different matter. By writing I don''t mean just typing in somebody else''s code and I don''t mean memorizing their way of implementing it and the writing that. You must make consious design decisions when you write code from scratch, and then deal with the consequences of those decisions. This is probably the most informative aspect in development.

quote:

I can rattle off the Q3 BSP and MD2 file formats if I need to.



The specific file formats are probably the most irrelevant part of the engine. You should be having to use references for the file formats, not the code to load the file formats!

quote:

The problem is how to organize those states. Like I pointed out earlier, these states were quickly turning into a forest of global variables.



Do you not have a concept of render targets in your engine? A height map type or a model type might be render targets. Then a scene would be made up of nothing more than render targets ( as far as the graphics go ). You could create a Scene object which contains nothing more than a list of a render targets and any specific code/scripts to associate with those render targets.

quote:

I''ve been thinking, would be be a decent idea to try and emulate Half-Life? I don''t have the full source to the game, of course, but I do have the SDK for modding, which gives me significant insight, as well as the Q2 source. Things like the cvars (essentially their state machine) and all...just an idea.



I find basing code directly off of other peoples'' designs an absolutely horrible idea. Any code monkey can throw together a program from a proven and sound design. The educational factor is probably near zero. As I mentioned earlier the true education and experience comes from designing and then implementing these ideas by yourself. If you want to just write something to show off to people then by all means just copy somebody elses'' design, it will probably be better than your''s, mine or any other hobbyists'' anyhow. However if you actually want to learn and eventually innovate then emulation is a terrible idea.

And again I realize this comes off extremely sharply, but I feel very strong on this particular subject. Step by step tutorials are creating an increasingly large number of individuals with next to no actual ability but impressive portfolios. I have been forced to work with a number of them. I am largely against the open source movement because of this exact reason. People do not use others'' source for educational puropses -- they glance over a few pages on the topic, jack the code, squeeze it into their engine and claim they know it.

Share this post


Link to post
Share on other sites
technic    139
quote:
Original post by Promit
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.)



That is definitely one way to do it (and better from the OO perspective), another simpler way for a small game would be to just have an enum where the state is a byte. Then state transitions are just assignments to that state variable and the logic loop is just a switch on that byte.

quote:

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



No, typically they don''t run at the same rate. Logic will update at a fixed rate, say 30 times per second, and rendering will occur as many times as possible depending on performance, say 70 times per second (70 fps). The idea is to make the logic happen at fixed intervals so gameplay is deterministic whereas you want to render as often as possible in most cases. There is a lot of information out there regarding this in this forum and elsewhere.

And no I would not run them in seperate threads, the intra-thread communication would add a layer of complexity that I don''t believe is necessary in this case.

technic

Share this post


Link to post
Share on other sites
anubisX    122
"they glance over a few pages on the topic, jack the code, squeeze it into their engine and claim they know it"

worse than that. they can reproduce that specific effect or algorithm at any time. they might even have understood it but because they spent no time inventing something for themselfs they gain no experience in solving problems of this kind in general. as a result they have to look up a tutorial or someone elses code everytime they encounter a new problem.

a good example : i had an universtiy assignment that was giving me some headaches and i talked with a friend about it. all he had to say was : "what the worry, i bet there's been plenty of stuff written on that topic on web"

sometimes it seems that this is getting a general attitude
of course you can't reinvent the wheel. you read about things like spacial partitioning, etc. but there is a difference in learning techniques and then going out to implement them and just following step by step instructions someone gave you

sorry... totally off topic

[edited by - anubisX on March 22, 2004 7:36:36 PM]

Share this post


Link to post
Share on other sites
oliii    2196
state machines can be fairly complicated. Requested states can be piled up in a stack, and processed one by one, states can be made OO, so each would have it''s own render / update and sub state machines, ...

however, they are quite essential to remove all the clutter, like the global variables you speak of.

if you imagine how the game starts, it starts with a couple of videos, that would be one state, then jump into the menu, second state. the menu runs it''s own render loop, ect... and the state exits and enter the loading stage. Loading updates the progress bar, handles quite requests, ect... then you enter the game itself, which it''s render function and so on. In the game, you can have a cutscene state, the pause state of the game, the auto load / save, the player finished the current level, so you exit the game state, enter loading, ect...

players can also have state machines, for when they spawn, play, pause, die, wait for respawn authorisation (like in spawning in waves), wait for cutscene to finish, ect...

this is particularly useful for network games, where the synchronisation between machines is critical. having states really helps, so you can request to enter the game, and wait in a state for the reply from the server, ect... you can synchronise machines as well, and obviously, the game flow is very much like a state machine (say, like the onslaught mode for UT2004, load level, wait for players, warm up, play, objective one succeeded, then objective two succeeded, ..., objectives completed, final scores, next round, ...., load next level...).

so, firt off, I''d start off with a basic state machine, have a single menu where you press start, which loads a level, ect... and a pause in the game (game could be just a fly through the level), which either continues of exits back to the main menu. That would be a start.

Share this post


Link to post
Share on other sites
oliii    2196
if you look at Farcry for example, all the core components are in their own little DLL (Physics, 3Dengine, OpenGL rendering, DX9 rendering, NULL rendering for dedicated servers, entity system, AI, animation, font system, game flow, inputs, networking, scripting, ...). The exe is only 32kb (with all the copy protection removes, which brings it up to 1.17 megs ). So the exe does nothing, but give an entry point to the game, and the game flow and states, I assume, are run through scripts, and that game DLL. It''s quite clever, and looks very tidy. It''s a bit extreme, but good design makes you look smarter

Share this post


Link to post
Share on other sites
Maxfreilich    127
Hey Promit! I see that you are from PA, as I am too! Where are you from in PA? If you don''t wanna say here, just email me at vbmaniac343@netscape.net . I would love to join a team that is somewhat local or talk to someone in my area. Note: I am 14.

Share this post


Link to post
Share on other sites
psamty10    148
quote:
Original post by haro

That is actually exactly what I meant. Even though you may understand the code you are using, writing it entirely by yourself is a completely different matter. By writing I don''t mean just typing in somebody else''s code and I don''t mean memorizing their way of implementing it and the writing that. You must make consious design decisions when you write code from scratch, and then deal with the consequences of those decisions. This is probably the most informative aspect in development.

I find basing code directly off of other peoples'' designs an absolutely horrible idea. Any code monkey can throw together a program from a proven and sound design. The educational factor is probably near zero. As I mentioned earlier the true education and experience comes from designing and then implementing these ideas by yourself. If you want to just write something to show off to people then by all means just copy somebody elses'' design, it will probably be better than your''s, mine or any other hobbyists'' anyhow. However if you actually want to learn and eventually innovate then emulation is a terrible idea.

And again I realize this comes off extremely sharply, but I feel very strong on this particular subject. Step by step tutorials are creating an increasingly large number of individuals with next to no actual ability but impressive portfolios. I have been forced to work with a number of them. I am largely against the open source movement because of this exact reason. People do not use others'' source for educational puropses -- they glance over a few pages on the topic, jack the code, squeeze it into their engine and claim they know it.



I find this accusation against open-source largely unfounded. A large number of people in these forums, including myself have learnt through open-source. It is simply not possible to do it all yourself. Open-source is a great boon to the field of computer science; looking at code really helps you understand. Of course, you could just as easily just copy code for your own benefit, but whats wrong with that. This just strengthens the argument for open source, its not just educational, its also practical.
Leveraging off someone else''s code allows you to focus on exactly what you want to do. If I dont want to write an engine, but just want to write a game, whats wrong with that? It takes a fair amount of effort to understand someone else''s engine, and were not just ''jacking code''.
You just dont have to reinvent the wheel every time...

Share this post


Link to post
Share on other sites
Oluseyi    2103
quote:
Original post by psamty10
I find this accusation against open-source largely unfounded.
Way to miss the point.

Share this post


Link to post
Share on other sites
M3d10n    170
Maybe the problem is that the OP forgot a detail:

A GAME engine is not only loading models, Quake3 levels, play sounds and handle collisions. You need that little part that actually allows you to put a game together without hacking everything into the source code: some kind of scripting capability.

You could have your engine rely on external files that describe what it''s gonna do. That includes loading a level, loading entities, placing them, playing a series of animations (cutscene), displaying a menu, unloading everything, etc. That way your game could switch content without the need of everything going to globals.

For menus, if your game is gonna have plenty of them, it''s wise to create a menu file format that can be edited externally, either by using a small tool, or even a text editor. As example, you could have a file that describes the placement of all menu items, their graphics, and what they do when clicked (load another menu, start the game, etc.).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by Gauvir_Mucca
2. In-Game action. This is just a combination of input/AI/rendering. Make functions for each, and slap them together.

Talk about an oversimplification! You could say a 3D engine is just a combination of math and rendering and data manipulation, too. But that doesn''t help!

I think most "game programmers" spend way too much time on engine details, OOP, etc., and very little on higher-level game code. There''s an art to the latter, and a lot to learn. Your best bet is to focus on writing games, not engines, just for the experience.

Share this post


Link to post
Share on other sites
Guimo    463
Hi all,

There is always a confusion about the word ''Engine''.

Many people think that loading a bitmap, a model, an effect, setting the object factories and rendering all into screen is an engine. FALSE. At most these can be called ''Utilites'' or ''Toolbox'', but are too low level to be called ''Engine''.

An engine is an specific solution to a specific problem. That is why you have terms like RTS Engine or FPS Engine or RPG Engine or MMORPG engine. Its because the internal logic of the engine varies with each problem.

The resource loading and animation sets, dinamic shadows... all those fancy terms are just a base where the real engine stands. The engine starts when you begin joining these objects and consider the interactions between those objects. Do I need portal rendering? Do I need BSP trees? Which colision detection method? Do I need to pick objects on screen? Which AI must be implemented for my game? Do I need Client/Server or Peer-to-Peer?

Those questions have different answers for each game type. You won''t use a portal rendering for a RTS game. You wont use detailed collision detection or real physics for a RTS game but a FPS will look better with them (just see HalfLife2 trailers). On a FPS game the path finding algorithm is differrent than a RTS game. A RPG must take care about the inventory the user carries and the effects on ''encumbrance'', the more objects you carry, the slower you move... you dont need that in a RTS. But in a RTS you need to program formations, etc.

Each engine combines those elements in different ways. Because each problem is different. In a FPS you can render detailed models because you will see them closer and wont have more than 20 creature in a single frame. So you apply Bump Mapping in order to have a better detail. In a FPS you can have a battle with 5 armies in a complete pandemonium all in the same screen if you add shadows and bump to that you will get a 1 frame per second animation and your players wll leave.

Its like cooking... more of this, less than that. At the end you have a specific engine than you can use to make specific games. You got a RTS engine? Then modify the graphics and you have other RTS!!! Or you can enhance your engine and add a little more physics and perfect collision detection, or add dinamic shadows. Maybe the video cards got better and you can bump all the objects in a a RTS withouth losing framerate. But just dont try to make a FPS game using that RTS engine... it is not optimized for that.

Why do you thing game companies stick into a game mode? Diablo/DiabloII is basically the same engine on the base. Warcraft I, Warcraft II, Starcraft, Warcraft III. Better graphics, same base logic. That means... change the ''Toolbox'', keep the engine logic.

Most people have ''Toolboxes'' not engines. Engine is harder to implement. Engine is logic and experience. The most common error for a programmer is that they stop in the ''Toolbox'' and think they can program the next Quake.

If you have your toolbox, why dont you start and program those simple games you just rejected? Tetris... pong... pacman. They are simple but each one has a difficulty. Begin with a menu with a Start and Exit buttons and the game. Then add an intro with your logo. Then animate your intro in a simple way (i.e. fade). Then you will notice that the textures used for the intro are no longer required when you are loading the menu so drop them before loading the game menu resources. Then add the credits, the high score, then the initials and so...

But the most important. FINISH IT! If you cant finish a simple game... how do you expect to program a big game!

Only when you have gained the experience, you will know what went wrong and you can move into a more complicated game... multiplayer maybe... something like Gunbound... but keep it simple... and keep moving... and you will notice that the objects you made for these simple games work just fine with little modifications.

Luck!

Guimo
Spritekin Entertainment

P.D. My current game, still alpha...
http://www.spritekin.com/warscale/screen1.jpg





Share this post


Link to post
Share on other sites