views:

635

answers:

7

I cannot fathom how modern games perform in anything near real-time..

For example, to allow the player to fire a bullet, you have to handle the user-input, check if they have any bullets left, then play a sound, and an animation, then calculate the bullets trajectory, then check if it impacts with anything constantly, drawing a particle effect after it. All that for every single bullet (of which there could be thousands at once..)

A more complicated example could be colliding an AI controller played, with animations and such, with a physics-engine controlled box: How does everything interact with each other? How does the AI engine tell the character to move forward, but the collision detection stop it walking through the box controlled by the physics engine?

This might be a slightly broad question, but - how do all the various systems required for a game interact? How do they run concurrently (treads?). Is the attribute of every single thing (character, bullet, barrel) stored in memory?

+11  A: 

This is a bit like asking "how is the space shuttle built?" :-)

Have you ever checked out GameDev.net? They have a lot of good information under For Beginners.

unforgiven3
+1  A: 

Also please see CrystalSpace

It's fanstastic and you'll learn a ton just looking through their code.

Rob Elsner
+3  A: 

Aside from Gamedev.net, I'd also recommend GameSutra.com, as well as any of the several books on overall game design and development available for your technology of choice.

That said, for raw architecture, a great starting point is this Master's Thesis proposing a reusable architecture for a system-of-systems controlling a game. It uses a components-off-the-shelf approach to simplify the overall architecture. It's not viable in and of itself, but coupled correctly with appropriate drawing and sound layers, you'll see the possibilities for engine design.

The topic itself, as unforgiven3 mentioned, is overly broad. But studying papers like that, as well as the literature available, will help considerably. Also understand that most games now are in fact built with COTS approach -- often combining multiple commercially-available engines with custom game logic code to simplify the development pipeline. (Look at the opening credits of any of your favorite games -- that series of splash screens usually correspond to contributors of various bits and pieces. You'll notice engine listings in the main splash for GTA IV, as well.)

John Rudy
I've never seen that Master's Thesis before - it's very interesting! Great answer.
unforgiven3
I picked it up a few years ago when it was making some tech headlines and I was very interested in game development. It was then that I realized the days of the one-man shop are long gone ... Except for "casual gaming," where I have no good ideas. :)
John Rudy
+2  A: 

Many developers use tricks to get what they need, a great example is John Carmack's use of the Magical Square Root. (this is a great read btw)

Btw the computer can calculate and process A LOT while active, a lot of delay is wasted on initialization of something.

Ólafur Waage
John Carmack didnt come up with the fast InvSqrt()http://www.beyond3d.com/content/articles/8/
bwknight877
Updated the post after reading that, nice link
Ólafur Waage
+1  A: 

I've been researching game development for a while now, yet still feel that I'm just getting started. To your question in particluar- how does all this stuff happen in "real-time"?

My research indicates that game development is one of the most challenging because it requires the greatest degree of optimization. The code need not be pretty, just blazingly fast. Concurrency is also critical- you must be able to manage many threads at once to squeeze that last little bit of performance from multi-core processors. Finally, be not afraid of your rendering engine. If it's not performing up to snuff, you'll have to dig in and code as close to the metal as possible.

Dave Swersky
+14  A: 

The simple answer to your question, how can these run at real time is that a processor can execute millions of instructions per second (technically billions per second with many of today's processors). While it waits for user input from us slow users it can be executing millions of instructions that we won't even notice. Still you can tell how games have grown in sophistication as computers have gotten more powerful. The graphics, AI, and physics are more realistic today then in 1990.

Also your question did not mention if you were interested in single player computer games like DOOM/Quake (ignore deathmatch for now) or multi user games like Everquest/World of Warcraft/etc.. I would assume "thousands of bullets" implies a multi player game, since for an individual game it would be a bit much for a single player.

Anyway as an example, if you try to play DOOM on a 386 SX 25, it will run super slow. Take that same game on a Pentium PRO 220 with similar ram and a faster processor and it runs very quickly. Now, it is typical for computers to run at clock speeds of 1500 MHZ. Consider that 25 MHZ is enough to run doom (although everything is ultra slow) and now a typical person has 60 times the computing power (in reality a lot more than just the processor clock speed changed so the speedup is even more dramatic).

Even on the Nintendo Entertainment System (NES), get too many enemies on the screen at once and it slows to a crawl. But in the Super Nintendo you could often get a whole screen full of enemies at once (see white ghosts in super mario world). Still compared to even the Super Nintendo the Playstation/XBOX/GameCube/WII are all super computers. And basically as hardware gets better you can do more.

Also, physics equations are just simple algebra but the computer is just substituting numbers in which is a relatively fast operation (in the past I read that games often used Newtonian physics equations which tended to be much simpler than the full relativistic equations). But basically evaluating equations doesn't take much time at all. Still if there were thousands of bullets at once on a 386 SX 25 it would have some calculation problems. Still, many of the earlier games did not have anything resembling real physics at all. If you were hit, you just blinked or were thrown back a certain amount no matter how the other character went.

Graphics slow things down as well. But in that department now graphic cards do some of the graphic processing in the hardware freeing up more of the processor. Also for the stuff the processor does compute, it is now much quicker. Memory and bus speeds have greatly increased as well making it much quicker to transfer the graphic representations from memory to the card to the screen. You can also store a lot more intermediate stuff in memory to speed things up.

AI slows things down as well. Early games like the NES often had bad guys who moved in a set pattern, or maybe moved and had a few attacks that were switched based on a random number or in some cases special rules based on the player. But they were simple. Now on some pc games, depending upon how you fight an enemy, it may seem completely different from the last fight. There is still a long way to go with AI, but compare Bowser in Super Mario Bros 1 to Metroid Prime in Metroid Prime and there is a huge difference in reactivity to the player.

Multi player games often have multiple servers doing the processing. Basically throwing more hardware at the problem. Also, in many of the modern graphical games you download a client which does most of the graphics for you using your computer. The game server needs to keep track of your health/ammo/positions/etc but as for all the graphic work, your client does most of it. And even your client only needs do animate things that happen in your more immediate area. If someone on the other side of the mountain is in a life or death struggle with a dragon, your client doesn't need to animate that.

Also the server may not have to handle the physics entirely either. It may just have to see if an attack hits you or not, and the client may be free to animate the path of the bullet. I suspect the exact division of labor in multi-player games vary based on the game. Even without multiple servers, it wasn't unusual for text based MUDs (Multi User Dungeons) with 40 or 50 players online to be running on Pentium 200 servers and not fully taxing the machine. True this takes graphics and even physics out of the equation, but you still have to keep track of player positions in the world, ammo, magic, items, health and a lot of MUDs had sophisticated enemies who would react to players depending upon how they were attacked. When you think about it, many multi player games are basically MUDs with graphics. This is even more true when you consider that most of the graphics are often handled by the client.

When the graphics are mostly done by the client, the server doesn't do that much more than a MUD except now it has to keep track of more than a "ROOM" and it probably has to do some physics in determining how hits effect you. It may not have to compute the path of a bullet or the path of a fall, but it probably has to calculate the final position or at least whether something hits you or not. Still in many multi player games I can't see the bullet hit me. I just know I was hit. I can't tell if the hit was in an arm or a leg. With that kind of latitude even less calculations need to be done, the computer could simplify players as cubes or something similarly easy to calculate.

Anyway, a basic one player game (or even a few players like a doom deathmatch) runs fine on one processor. As processors improved so did physics, graphics, and game AI and this isn't a coincidence. Many single player games are not multi-threaded at all and even on a multi-core computer they still only use one core. Even in multi-player games, that client often is not multi-threaded and sticks to a single core on a multi player computer.

On multi player games, the game server itself may be one server, but for bigger games it may be a server farm. Still for other games you may get one server per area where the server handles all the calculations for players in an area it covers and once you leave the area you transfer to a different server. Basically the "techniques" for handling the server side and client side of a multi player game will vary based upon the game.

As far as specific techniques, there are books and courses on them. But as for how the computer can do everything at once, it is that fast!! And as it gets faster (and developers learn how to do multi core stuff better) games will get even more sophisticated!! Basically early games had to take shortcuts in AI/Physics and even had weaker graphics to be real time, but now some games have graphics that compare to movies. And basically this all comes from hardware improvements, especially the processor!!!

Cervo
+1  A: 

One interesting aspect of modern game development is that, in addition to all of the processing mentioned (collision, games rules, etc.), most games also expose a layer of functionality to a script engine which together with design tools are given to the level editors to create all of the interactive events we expect in modern video games. Obviously script languages are slow so often scripts are parsed only when events occur (observer pattern).

What you end up with is actually tiers of processing where high intensity calculations may be written all the way down to ASM, game engine framework written in C/C++ and finally a top level which is easy to manipulate (does not require a recompile) but slower to process in run time. This top level is essential because to actually move from game engine to game requires a whole lot of trial and error and recompiling every time you want to change the damage of your rocket launcher or the maximum speed of your lunar rover is far too time consuming.

Working with these scripting languages can also be a great way to introduce yourself to game development.

Nick