The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Creating a simple computer game?

I'm just curious how a game is created. e.g. in Turbo/Freepascal. Be it in graphics or in text mode. My question is how to let the background or the enemy (e.g. similar to mario bros. or pcman) move in programmed speed
while you (the one controlling the character - mario) can also move in a desired speed? What I did, was to update the background/enemy movement while a key is not pressed and to update the character when a key is pressed. Pascal code looks like: while not keypressed blah. The outcome was not pretty.
Do you know any better/simple way?
Tuesday, December 06, 2005
You need a central loop which runs the various game tasks. Looks something like this;

while player not dead


  Work out how much time passed this frame.

  Go move the monsters that much

  Go move the player that much

Katie Lucas
Tuesday, December 06, 2005
Then you need a routine for the player which says something like;

10 Are we currently moving? If so, move us SPEED x ELAPSED_TIME in that direction, but stop at a grid boundary.

20 Did that move finish off a movement (are we at a grid boundary)[1]. If not, exit.

30 Look at the keys and if one is pressed set our current move direction appropriately and then exit.

[1] some games require that you end up aligned with some sort of grid, what you're doing here is asking if the player icon is lined up with the grid. For example, pacman finishes each "step" on a dot, and the dots mean he's lined up to turn down corridors. Making the player line him up is frustrating, so you ease it a bit..
Katie Lucas
Tuesday, December 06, 2005
Once you're going round each "task" doing a bit at a time, on-screen it'll look like it's all happening at once.

Have a look at "Game Coding Complete", which is a book about games development.

Also, it's worth having a look around at websites -- if you can find some games written in something like Python[1] they'll be easier to find the structure in (c++/pascal ones tend to lose the structure in the details).

Once upon a time, games were simple and you could find this stuff out by looking at the games that you typed in out of magazines and things, and there were books about writing your own video games in BASIC which included stuff like this. I've no idea how you learn these structural things these days.

[1] Yes, they do exist.
Katie Lucas
Tuesday, December 06, 2005
Check out pyGame at

you can easily read the sample code and apply the same techniques to pascal
Tuesday, December 06, 2005
If your options are open about which technology to use, I'd recommend to use Pygame or GameMaker to get started creating your own games.
cbmc64 Send private email
Tuesday, December 06, 2005
Tuesday, December 06, 2005
I believe game programmers using bit blits and double buffering to move the background and sprites around efficiently. You definately don't want to be re-drawing the whole screen from scratch each frame.

Have you thought about using a games library/framework?
Andy Brice Send private email
Tuesday, December 06, 2005
If I construe your post correctly, you can either move the first person or the scenery, but never both at the same time.

Use techniques from discrete event simulation. That will allow you to make changes to many objects between one tick of the simulation clock and the other. This is the modelling part.

At every advancement of the clock you re-render the parts that have changed. Here you use double or even triple buffering for better graphics. That is the visualisation part.
Karel Thönissen Send private email
Tuesday, December 06, 2005
Actually nowadays you do want to draw everything from scratch because double or triple buffering means you can't use dirty rectangles (since you'd be a frame or two behind). Plus textures/bitmaps are typically stored on the graphic card anyway so the blit doesn't take any time. But I think the OP's problem is as Katie alluded to, the amount to move everything each step through the loop is the velocity of the object times the amount of time elapsed since the last time through the loop -- the OP is probably just adding some fixed amount to the position each time, which doesn't work.
Game Programmer Lou
Tuesday, December 06, 2005
Here's the principle I used in the olden days when I wrote graphics games.

1. I set a timer-based process (thread) to kick off every 15th of a second - chosen because frame updates generally need to be done no less than 12 times a second to retain fluidity and so 15 gives a little leeway. This process works in one of two ways depending upon your methodology. Either it waits for the frameflyback, clears the screen and redraws everything (the classic method), or in the modern method it instantly begins updating a back buffer from scratch then switches the buffer into view when completed.
It's vital that at the start of each cycle of this thread you copy the state of all objects as fast as possible. This is because the other threads (below) should be kept running no matter what, so if you use the original positional data you risk it being updated whilst you are drawing.

2. Start a timer process going that moves the baddies in their pre-defined (or intelligent) pattern at a regular interval (every quarter second is usually fine). No attempt is made to update the presentation layer.

3. Another timer process is set that checks for and handles user input (never wait for input during the gameplay) and positions the hero accordingly. Again no presentation layer.

By doing it this way you get several advantages.

Firstly, the screen refresh is consistent. If performance drops in the other processes it doesn't stop the refresh happening so things may move slower on screen but they still look okay.

Secondly by simply varying the timing of processes 1 and 2 you can easily fine-tune the relationship between hero and baddy reactions. This means also that an increase in difficulty is achieved easily by a reduced period for timer 2.

Thirdly the presentation logic is totally seperated allowing relatively easy support cross-platform.
Fourthly the game logic becomes much easier to implement because there is absolutely no distraction with presentational aspects.

Fourthly this only tends to work well using object orientation. When you are coding games you often aim for speed so it's easy to hard-code little bits which can cause problems down the line, so this enforced oops methodology is very useful.

Fifthly if the machine cannot handle the redraw fast enough then the screen updates less frequently but the actual gameplay, being in a seperate thread, continues at normal speed. This means that the game remains the same speed on all target machines, whatever their power (within reason).

There's other benefits but those are the main ones.
Karl Cartlidge Send private email
Wednesday, December 14, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz