Just recently I coded my first "real" C program - one that has actual use. It was very simple - forked to background and waited for connections on a TCP port, and would convert music files for an application on the networking site Facebook. It wasn't that complicated but it was the first useful program I have ever coded in C. It was exciting. I've also messed around with OpenGL some. I used Glut to draw the trajectory of a projectile, just single points with some math calculation functions. It was pretty simple. So now I'm looking at the sortof thing I've always wanted to do - game programming. I just can't seem to get my head around a game engine - I was reading in another thread about multi-threaded game engines being something new. How exactly do current game engines work, 2D or 3D? It seems to me as if it'd be very difficult with only one process. I am not looking for sample code or a link to a working game engine - just a general view of how a game engine manages to do everything it has to at once - sound, input, video, physics, AI, etc, all at the same time without forking. (I may have misread that other thread wrong - maybe they do fork.) Regardless, just a general idea would be very helpful. Thanks in advance.

It depends on the frequency you want things to run. The most simple game engine will have every component run at the same frequency, so that everything is calculated once per frame. (A frame being a fresh image that is output by your graphics card, as in framerate) In code, that would mean a loop like this: [code] while(running) { handleInput(); doAI(); doPhysics(); doNetworking(); drawObjects(); } [/code] But some things, like the accuracy of the physics simulation, depend on the frequency ( = framerate) a lot. So there it would be useful to have the physics simulation run more often than the rest of the code. So you could have one thread doing input, AI, networking and drawing, and another doing physics only. If you give the two threads equal chance to run, the physics thread will in general have a higher frequency because it does a lot less work. That means your physics simulation becomes more accurate. There are of course other things that aren't worth splitting into a seperate thread. Something like networking, which gets its data to send from the other components (like physics and user input), can never send new data faster than the other components run. Therefore there is no use in having it run as fast as possible on a seperate thread. (Of course in practice it can't even keep up with the other components because internet usually isn't quick enough, so there really is no point in having it on its own thread)

game engine, generally, draw w/e you want to the screen, and manage everything. AI is done not in the "Engine", but in other code, as with lots of other stuff.* Think of an "engine" as w/e you must do in the background repeatedly. The engine is usually a loop. It covers everything in general, but nothing specifically. I would recommend getting a book if you really want to learn to program games. (i have a good one for C++, cant remember the title) EDIT:* AI can be done in the engine, but it's not really specific. If you build a huge clunky engine to cover AI and everything, it'll get boggy.

---

I see the engine as everything that makes the game run but is not replaceable like levels, textures, sound files, AI scripts, character models, etc. So I do consider the code that handles AI part of it. Just not the actual AI scripts. (The difference between what tells something to move and what makes it move.)

Yeah, Ravek is right. What you can think of as an engine is w/e doesn't actually affect the game in progression, but makes it run. Anything that must be done every frame is under the engine. If it isn't needed in every frame, don't include it in the engine. So each individual AI should be run seperatly, but you can call the engine for general code, but not decisions. I don't know about input (keyboard) though. I'm still new to it too, so i'm not an expert.

---

 Quoting: zoological

I don't know about input (keyboard) though. I'm still new to it too, so i'm not an expert.

Don't mistake me for one either.

I thought the engine covered things that needed to be done in the background globally, and contained things that would be called upon very (meaning more than half the time the game is running) often. Other than that, i would leave it out. put it in another file.

---

hi. Well, an engine is really a complex thing, and isnt so simple to explain it with just some short sentences. There r a lot of different engines: Game engines, Physic engines, Graphic engines, AI engines and so on. A game engine has all functions which do u need included in a really huge library. On this way, the developer has the chance just to concentrate about his game and all the other stuff like loading of an 3D object or something makes the engine for him. Then there r some other special engines which does just a specific part of a game. AI engines r just library for AI calculations, physic just for physic stuff and so on. On of the best engines on the current market r the CryEngine 2 by Crytek and the Unreal 3 Engine by Epic. Both r Game Engines and have a lot of tools included to make a game on a really simple way. The process of an engine is simple: Init all stuff, example: Check your hardware and OS, create window, init your input devices, init the graphic API like Direct3D or OpenGL, init MemoryManager and a lot of stuff more. After that a main loop will start and in this loop runs some of these actions: - check input - calculate AI - calculate Physics - calculate environment - render environemt these r just some of the processes which run in this main loop. If the user will quite the game, then he goes out of this main loop and after the this loop just happen something like that: - clear the memory of the objects - shutting down the memory manager - shutting down the Graphic API and so on. That's a really simple and general overview of an engine anatomy. If I wrote something wrong right here, then plz tell it to me...I'm not perfect . I hope I could help a little. See ya Best regards Andy

Well, an engine is really a complex thing, and isnt so simple to explain it with just some short sentences.

That sums it up. Get a book. one thing we didn't say that mod did was that it is mostly libraries, and not essential code. i'm not sure if i would call that the engine, but it should be put out there.

---

 Quoting: RAVEK

There are of course other things that aren't worth splitting into a seperate thread. Something like networking, which gets its data to send from the other components (like physics and user input), can never send new data faster than the other components run. Therefore there is no use in having it run as fast as possible on a seperate thread. (Of course in practice it can't even keep up with the other components because internet usually isn't quick enough, so there really is no point in having it on its own thread)

thats my exact explaination as to why it SHOULD BE in its own thread... You don't want your network code wasting cycles for that packet that will never come when your cpu it could be redrawing or getting user input or loading the map etc... Waiting on hardware sucks, just load up a windows xp's add-remove programs to see how much you'll be waiting on it to caclulate file sizes. If the filesizese were loaded on a background thread, and filled in on the fly, you wouldn't have this gruleing wait of 40 seconds just to remove a program whose size is insignifcant. add-remove would have been reasoned by this similar line: "in practice harddrives can't even keep up with the other components because they dont spin and get data quick enough, so there really is no point in having it on its own thread"

You got me wrong. Obviously you're going to be handling your hardware access asynchronously. Otherwise you'll indeed have to wait eons. But there is no reason to have a networking thread spinning all the time – just start one when there's something to do and stop it afterwards.

I'm getting a little excited, over the next two terms (10 weeks each) I have classes on game engines. The first is Fundamentals of Game Engine Development and the other is 3D Game Engine Architecture. I feel like I'm finally going to be able to make something that isn't a text adventure, yay!

Congrats Don't hesitate to download a few existing game engines to tinker with. Gives you a good view on how stuff works, why some things are just as they are. It might seem a little tricky at first, since you usually have next to no documentation and you're looking at someone else's coded. But then again, that sometimes goes for reallife as well (in fact, you won't be building game engines from scratch on your own unless you're the lead coder and the team is still very small, otherwise it's a team effort).

---

Programmer at Triumph Studios

RAVEK:

(A frame being a fresh image that is output by your graphics card, as in framerate)

In code, that would mean a loop like this: 

 while(running) { handleInput(); doAI(); doPhysics(); doNetworking(); drawObjects(); }

Of all the replies, I think this one best sums it up. You pretty much have a loop. Multithreading depends on what you want to do with a game, but you have to realize that forcing multiple threads to always be synchronized can cause alot of slow down that you would otherwise not recieve in a single thread.

An example of how an engine might use multithreading is pathfinding. You will notice that game when you click in an RTS give a feedback right away like a blip that shows up on the screen, etc. What you can do is pass the starting point and ending point to another thread and let it do the calculations. Until it finishes the "Unit" does not move. However, the feedback from this action is instantaneous so the person doesn't really feel the weight of the multithreading.

Multithreading, however, is hard for alot of beginner coders to wrap their heads around. Especially with little understanding on how it actually works in the hardware level. On a single CPU, for example, multiple threads are just task switches in the processor based on priorities and sleep states of other threads. Just to give you an idea, if you have a thread with:

while(1) { };

It'd take 100% cpu usage. However:

while(1) { Sleep(1000); }

You will see 0% cpu usage most the time. Since you've done socket programming you probably noticed that your "Task" doesn't take 100% cpu (If you did it right) because of the calling thread being put to sleep by functions such as "select" and blocking IO calls to "recv" and "send" depending on how you implemented it.

When dealing with multiple CPUs or multicore CPUs you get the benefit of being able to spawn off another thread and have it possibly running on another CPU. Basically the advantages depend on you the coder. What can you make another thread do that doesn't rely too heavily on the "Main" thread? If they rely too much upon each other you will gain no speed increase as you spend alot of time synchronizing.

Just thought i'd say something about multithreading too, i don't really have the time to read through all of this thread's contents, currently rather busy, so if what i say has already been said before, i apologise.

It may be a idea to deal with certain tasks as threads, so you wont get performance hits on rendering, for instance.

One such examples would be my 3D Terrain Editor. It has a simple Streaming method that loads and unloads terrain pieces (Chunks) dynamically, when they appear and disappear from view.

It would be a idea to assign loading/unloading itself as a thread, and then inform the Renderer to update the Terrain's Geometry from the new data, since all Terrain Geometry is a big Vertex Buffer, space in memory that stores the Terrain's Geometry.

What i'm meant to say is this, mostly: If your application/game relies a lot on Data Load/Unload, make data loading/unloading become a thread, more than one if really needed (like for the terrain, i'd probably want to load my models on a separate thread if i noticed it gets too slow while handling everything).