How does a game work?

[oriel]

Hi,



I'm asking a general question I've been really curious about.  I want to know what happens behind the curtains.  From what I've read, a game such as a first person shooter works as such:

-The user inputs commands from the keyboard and mouse.

-The engine interprets these commands and calculates where the user is trying to go or look.  It also considers commands for jumping, firing, etc at this stage.  Bullets, for example, are integer variables that change according the its movement along an X-Y-Z axis following equations of kinematics.

-Then it outputs the appropriate sounds, as well as update any other player movement through the LAN or internet.  

-The computer finally draws a new frame based on all these calculations, to simulate movement.  These commands all are organized into a loop, which doesn't end until the player dies.  The rate at which the computer does this are the frames per second.


I'm sure this is a broad generalization of what goes on in an FPS engine today.  But what about QFG2?  How will that work?  How is data organized?

[Gronagor]

It's a never ending cycle of "if's". Can't explain it like this, but it's basicly

ie.
IF you're at the inn, {
   'display inn background'
   IF hero = east and action=walking {
      IF it is still in the walkable area {
        IF the hero isn't carrying too much {
           IF the hero isn't under attack {
             display hero sprite - frame I
           else {
             goto combat sequence
           }
         'display You are carrying WAY too much'
         display hero standstill to east
         }
    }
}
etc etc etc etc. Not really like this, but that's the point. Every action is basicly a variable which is compared to each other.

This is the basic script idea. It's a lot more complicated, but an engin like AGS makes it a lot easier.

I sometimes wonder what programmers see when they look at a game. I bet they keep seeing variables flying by, where we see neat art.

[1eyedParrot]

Most game engines(not AGS) work on an event driven system. A parameter within a certain context is passed to a handler which then interprets it and then acts on the interpretation within the context that the parameter is capable of.

[deltamatrix]

1eyedparrot: Well put. You took the words right outta my mouth

[oriel]

Yeah lol that really handles it case closed.



=)

[Gronagor]

Most game engines(not AGS) work on an event driven system. A parameter within a certain context is passed to a handler which then interprets it and then acts on the interpretation within the context that the parameter is capable of.

Ok. But how does it not work within the 'system' I've explained above? In fact... it's the same idea.

[dynamic1]

Gronager, your system isn't quite the best example of the process, in my opinion, though generally the idea is correct.

A game, any game, really, involves a loop that repeats (until the ESC key is hit or Exit menu button, whatever). One of these loops is a "game cycle" and during this cycle the game needs to do basically draw a frame onto your screen. This is more true for FPS's than, say, adventure games, but it's all the same thing, really. The loops needs to poll input devices... it needs to check what keys have been pressed, where the mouse has moved, mouse buttons, joystick buttons/axis, and so on. Based on this information, the game then adjusts the game environment accordingly. If you pressed mouse button 0, the game engine begins executing that action by referencing the "character walking" animation from memory (loaded earlier, before the cycle started), then it calculates where on the screen the first frame of this animation will appear, then calculates things like alpha. The game figures out what needs to be drawn and what doesn't, and instructions are given to the graphics adapter on exactly what is going onto the screen during this frame. Finally, the game might want to examine the game world to see if any other events need to occur... should the main character's HP drop another 2 pointins becuase he's poisoned, and so  on. Then I suppose some cleanup actions need to be taken, to clear whatever memory needs to eb cleared and so on. Then the cycle repeats.

The amazing part of this is that say you're getting 60 frames per second... that means that every single second, your computer does ALL THAT (and it's far more complicated than that inaccurate summary) sixty times in a single second. I'm constantly in awe of the power of computers, depsite the fact I sue them every day.

[BeerNutts]

The amazing part of this is that say you're getting 60 frames per second... that means that every single second, your computer does ALL THAT (and it's far more complicated than that inaccurate summary) sixty times in a single second. I'm constantly in awe of the power of computers, depsite the fact I sue them every day.

The most intense part of the game loop is drawing the frames.  That's what really determines how many FPS you can have in a certain game.  The other calulations that go on from parsing the input, to the AI of the computer opponents (and there's tons) really have very little effect on the game speed itself, unless it's very, very poorly written (ie, going to the HD every loop would be considering very poor programming).

Having written a side-scrolling shump, here's the 2 main functions that get called every game loop (this is in C, but you can get the idea even if you don't know C).

Code: Select all

/**********************************************************
*
*	Game_Main()
*
*  Main game handling code	
*
***********************************************************/
int Game_Main(void *parms)
{
	ULONG ulTime;

	// OK, check the state, do what you're supposed to do.
	switch (CurrentState.GameState)
	{
	case GAME_INIT: // Nothing for now
		break;

	case GAME_INTRO:
		// Play the intro demo (fading? I dunno, we'll see!)
		GameIntro();
		break;


	case GAME_MENU:
		// put up the menu screen
		GameMenu();
		break;

	case GAME_START:
		// do what it takes to start the game
		GameStart();
		break;

	case GAME_RUNNING:
	case GAME_RUNNING_RECORDING:
		// Get a going
		GameRunning();
		break;	

	case GAME_DEMO_PLAYING:
		// Just keep going to Demo playing
		if (!DemoPlaying())
		{
			CurrentState.GameState = GAME_DEINIT;
		}
		break;

	case GAME_PAUSE:
		// bleep, blep,blep,blep, bleep!
		GamePaused();
		break;
	
	case GAME_DEAD:
	case GAME_DEAD_RECORDING:
		// dude, you suck
		ulTime = timeGetTime();
		Dead();

		/* check for recording */
		if (CurrentState.GameState == GAME_DEAD_RECORDING)
		{
			DemoSavePosition();
		}
		UpdateScreen(ulTime);
		break;

	case GAME_OVER:
		// Do game over thingy
		GameOver();
		break;

	case GAME_DEINIT:
		// Let go all (well, most) resources
		GameDeinit();
		break;

	case GAME_END:
		EndGame();
		break;

	case GAME_WON:
		GameWon();
		//CurrentState.GameState = GAME_DEINIT; // temp
		break;
	}

	return 1;
}

and, the main game loop while the game is being played:

Code: Select all

/**********************************************************
*
*	GameRunning()
*
*  Main Game loop while game is running	
*
***********************************************************/
void GameRunning(void)
{

	// OK, this stuff is ported from the Original Alpha too
	// It's very Ugly (see CheckUserInput() for another Port) - Will

	// perform game logic...

	// move each bullet on the screen if needed
	UpdateBullets();

	// check if the user is pressing a button
	CheckUserInput();

	// check how far we've moved in the stage and add objects if needed
	CheckStageProgress();

	// Check each enemy, and move if needed
	CheckEnemyAction();

	// update each bullet's frame
	UpdateBulletFrames();

	// update Each Enemy's frame
	UpdateEnemyFrames();
	
	// Update each options frame
	UpdateOptionFrames();

	// Check if an enemy has been hit
	CheckEnemyHit();

	// check if our ship has been hit
	CheckShipHit();

#ifndef DEBUG
	// and update the screen 
	UpdateScreen();

#endif
	// check if we should update Demo if playing or change state
	if (CurrentState.GameState == GAME_RUNNING_RECORDING)
	{
		DemoSavePosition();
	}

	// finally, check for cheat buttons
	if (gbDebug && GetInput(PLUS_BUTTON))
	{
		//Speed Up the game by a factor
		gulTimeFactor=1;
	}
	if (gbDebug && GetInput(MINUS_BUTTON))
	{
		//Slow down the game by a factor
		if(gulTimeFactor != 0)
		{
			gulTimeFactor=0;
		}
	}

	// if we're in debug mode, check for God key
	if (gbDebug && GetInput(GOD_BUTTON))
	{
		gbGod = TRUE;
		MainShip.ulArmor = INVINCIBLE;
		MainShip.ulInvicTime = 0xFFFFFFFF;
		PlaySnd(SQUEAK_SOUND, FALSE);
	}

}

[Fribbi]

Did anybody understand what this codes does?????

BTW I missed those days when people gave some valuable codes  so newbies like me in game creation could use it.