I love writing video games for fun, and often do that.

I noticed, anyway, that most of the times implementing the gameplay itself doesn't take too much time to me (maybe because I already did that plenty times and know what and how to do for most of the things), but when I try to implement off-game stuff I get lost.

By off-game I mean what is not gameplay: menus, cutscenes between levels, world map to choose levels, saving and loading status, managing replays ... Only tried to write a few of these a few times, but always failed; that's why I never really completed and distributed a game.

Are these common problems? And where should I start to do this? Where could I find some books/guides about such stuff?

  • \$\begingroup\$ -1, If you have a problem with writing things like "menus, cutscenes..., world map..., replays", those should be separate questions. This question right now is too vague and I can't see how it could possibly accomplish anything. \$\endgroup\$ – Tetrad Nov 15 '10 at 12:23
  • \$\begingroup\$ In general I get stuck on anything that doesn't regard the game itself, while you're playing it. With "world map" I meant the "cutscene" where you select the level (think of SuperMario...). I always get stuck with all of these stuff. Guess it's because of lack of experience, so I'm asking if this is a common thing, and if there's some reference to look at when implementing the stuff needed to a game BUT the game play. \$\endgroup\$ – peoro Nov 15 '10 at 12:52

I think I can rephrase the question to something answerable: "My specialty is gameplay programming, i.e. implementing the actual game mechanics. But I haven't learned any of the other parts. How can I finish a game project?"

My answer: it depends, but the good news is there are a LOT of options.

You can team up with another programmer who knows how to do that stuff.

You can teach it to yourself, perhaps finding some open-source projects and looking through their code, or just finding some good game programming books, or just experimenting with small systems on your own until you get the hang of it.

You can download one of the many cheap or free game engines / libraries / frameworks / authoring tools that handles all that stuff for you. If all the back-end stuff is taken care of, then you're free to concentrate on the gameplay programming that you obviously prefer.

You can design games that don't require a lot of infrastructure. Don't know how to save or load games? Then design a game that doesn't need save/load functionality, such as a retro-style arcade game. Don't know how to do graphics? Challenge yourself to see what you can do with text only. Don't know computer networking? Then I guess you'd better make your game single-player (or multi-player hotseat). For every limitation, there's a design workaround, if you fancy yourself a stronger designer than programmer.


I'm not sure I understand. You've implemented gameplay but not menus and levels? Like you've had a sprite jump but you've never created a tiled level or world map and such?

Try to think about creative solutions to problems. Try not to think, "How do professional game programmers do it? I want to do it exactly like they do." Try to think, "What are several ways I can do this? What is the best way of the choices I have?"

For example, for a world map to choose a level, you can blit an overview map image to the screen. Then blit a dot image or some other object which can represent the level. When the player moves the mouse over the dot and clicks it, you enter that level.

Menu buttons. Just render a text surface or an image of words. When mouse is over the button or the down key is pressed, highlight the button. When enter or left mouse-click is pressed, execute some function.

And so on. Just try to think about how they COULD be done. Not how they are specifically done by a specific person.

  • \$\begingroup\$ Nope, I didn't mean that. Levels are OK, the game is playable, but when you run it, you're immediately playing, there's no menus and when you win/lose you only get a string on stdout and/or the next level is loaded - most of the simple games I wrote are like this. What I'm not able to do is writing menus and stuff which are non-in-game... Of course very simple menu (only 1 menuscreen with few static entries) aren't hard to do, but when I want something a little more sophisticated, I get lost. \$\endgroup\$ – peoro Nov 15 '10 at 8:10

Regarding the menu at start, what you need is a variable that tracks "Game State". In your main game loop you will then have something like:

switch (GameState) {
    case Menu: ...
    case MainGame: ...
    case EndScreen: ...

This way, the block of code that is actually executed is completely different depending on the "Game State". You can then develop the Menu part as if it was a whole application on its own which exits by changing the value of GameState. The main game code that you already have would only execute in the MainGame case. And you can even add other states, like "Worldmap", or "Cutscene". This can be used every time you need to manage the input differently or halt the regular update of the game (for example, "Paused").

Of course, this "switch" statement might also be needed inside the "keyPressed", "mouseDown", or other functions.


Think of a large open field with a single tree in the middle. The tree comprises the things you said you get lost on, and the bedrock is the actual game world. You've handled the tough bit already, so think about the architecture when designing the links between menus etc as being like a tree's branches, or if you prefer, its roots.


Not the answer you're looking for? Browse other questions tagged or ask your own question.