Jump to content
  • Advertisement
Sign in to follow this  
sarthakz99

The basic structure of game programming

This topic is 1338 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

the most basic question..... ahh,...
what's the basic things of game prog. process??

what i learned, from diffrent blogs & forums was...

a loop that runs again and again...
{
a function that updates visual.

a function that updates variable.

and a function that determine...
how long the loop continues...
}

so, am i right. or is there a more basic outlay for prog. ??

Share this post


Link to post
Share on other sites
Advertisement
Basically, a game goes through an initialization phase setting up everything it needs, then enters the game loop, which repeats until an exit condition is satisfied (such as the player choosing a Quit option from a menu).

Several things can happen in a game loop. Typically there's a means to keep track how how much time has passed since the start of the previous loop. Input can be polled from the player (also any AI routines for enemies or input from the network if your game is multiplayer).

The game updates based on this input and what state the game may be in (menu, ingame, paused, win/loss. . .). Game objects may be moved, stats may be altered, physics may be simulated, the game may enter a new state. A lot of things can happen here.

Graphics and/or audio is updated and rendered based on whatever logic has been updated.

Rinse and repeat.

Share this post


Link to post
Share on other sites
That is true for a subset of games. Most of the interactive console style games follow it on a broad spectrum.

Many of the popular games follow the model.

However, it is not true for most games on the market. Many are event driven, turn driven, input driven, or compute driven, rather than a tight loop of render/simulate.

For a few....

Text adventures are not render/simulate.

Chess and checkers and forms-based games are not.

At the extreme, Deep Blue, a massive chess simulator, is not based on a render/simulate loop.

A large percentage of mobile games are turn based where they take some action and wait for input, are not tight render/simulate loops since that rapidly drains batteries.

Many online games may present a client that does its own graphical things but under the hood are REST-based turn oriented games where the data tells the database to run a small update, and the client happens to be visual but is unnecessary; the client may present lots of graphical and visually interesting effects but they are completely irrelevant to the actual game component.

The loop adds a lot of difficulty because you are suddenly in the realm of soft realtime requirements. You must update regularly or it is a defect. That means you need to restructure all your algorithms to run within the time frame, or structure them to span frames somehow.

So while the tight render/simulate loop is one of many possible options, it is also one of the more compute-expensive and annoying routes to implement.

Share this post


Link to post
Share on other sites

Games are really one big complex loop.

 

The actual model is.

 

Initialize Executable

-Reserve a Memory Pool = The game can actually outrun the Operating systems Memory allocater. So having a knowledge of how much you need ahead of time helps a lot.

-Initialize Objects = Usually what ever the game needs either at the moment or in the future.

- normally a Do While Loop = Faster close outs, rather than looping for one more frame and then exiting.

  Event Functions

- End of loop

 

And then for Consoles on exit, a common method of a lot of older games is simply to force the system to reboot.

PC games... is a little more complicated on exit, as memory isn't freed automatically for older systems, and Vista. Newer systems "should" free memory on program's shutdown.

 

 

What language the game is built on greatly depends. You can make games with any langauge, but performance is something that usually matters a lot.

Edited by Tangletail

Share this post


Link to post
Share on other sites

this is the basic form for realtime games:

 

initialize stuff

while (! quitgame)

    {

    draw the screen

    get input

    move everything

    }

shutdown stuff

 

turn based is more like:

 

initialize stuff

while (! quitgame)

    {

    while (! end turn)

         {

        draw the screen

        get input

         }

    move everything  // perhaps drawing the screen as you go, to show each unit's movement

    }

shutdown stuff

 

there are almost as many variations of these as there are games. but almost all game "loops" evolve from these (or similar) basic forms.

 

 

 

 

 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!