Video Game Architecture

Member
Posts: 254
Joined: 2005.10
Post: #1
I was wondering what different kinds of architectures you have seen for video games (from a programming perspective). I looked online for ideas and pretty much the only thing I found was a main loop which updates the game entitities, detects and handles collisions (or physics) and draws to the screen, etc.

In my programming class last semester we wrote a couple of games, and I ended up using a class heirarchy to represent the different game entities (players, enemies, weapons, etc.), a level class to track the entities and tell them when to update and draw, and a screen manager class to control windowed/fullscreen mode.

(I don't know if I was very clear there... but oh well.)
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
This is a question I'm also interested in. I mean, if you're writing pong, you can get away with a poor design, but as your games get larger it really begins to count. I feel I've been learning everything the hard way.

Is anyone aware of anything out there which discusses how to structure things like physics, AI, rendering, networking, etc. in such a way that the different components are nicely separated and modular?
Quote this message in a reply
Member
Posts: 185
Joined: 2005.02
Post: #3
This is what a game "engine" is supossed to do. It is supose to be separate from the game-specific code and assets. this: http://www.extremetech.com/article2/0,3973,594,00.asp appears to try to explain the concept, but the author gets of focus and starts talking about the specifics of culling and shading and inverse kinetics, etc.
Pretty much all I know is that it takes the game-specific code figures out where every thing is and what color it is, etc. then the game engine takes all of that and gets rid of all the excess data by culling, removing hidden surfaces, etc. so that the graphics card can render everything without causing the frame rate to suffer. That is the 'renderer' section and is supose to be able to be taken out and put into a different engine with no or very little rewriting of code. With some games you would need to add a physics component to the engine. That is about all I know. I have tried to find some more information on the topic but with little avail( even Wiki failed me Sad ). I'm not even sure all of that is correct, so take it with a grain of salt. (am I using that expression right?)

I hope that helps alittle. Smile
Quote this message in a reply
Member
Posts: 70
Joined: 2002.07
Post: #4
Code is a weird thing, and game coding is even weirder. Code isn't like building a house, using bad wood and the house will eventually collapse. You can code messy and spagetti like and have a wonderful game that never crashes.

dim3's code is all open and free, so I had to be more careful.

Some of the more well known pieces of code have some of the worst conventions, styles, etc in them. Duke3D (never actually looked) had a rep for being convulted code, and the Linux kernel, too (not to start a flame way, this is I *others* HO, I've never actually looked myself.) Both are/were great products. You can have crappy structured code but still working and solid code. You can spagetti things together, have stuff in no modules, have very little reuse, etc.

Must times, games were disposable, you coded for a game, got it done, and archived the code. Getting it DONE and DONE on TIME were more important then done right. Especially in the days of single coders. It is, of course, quite a bit different now-a-days.

Note that how you modulize can also be forced by game requirements instead of good coding knowledge. For instance, if you have a pure client/server network game, you'll need to complete unwire the server code (server) from the display code (client). dim3 is this way, even though it's heavy-client to light-server code and not necessary (that's only a sign of me going one way and discovering the other way is better.)

Worse, threading in games is a black art because games don't lend themselves well to separate tasks. For my real job, I code back end server software, and threading is just natural, you wouldn't even considering doing it any other way. In games, what can you do? A sound thread. A input thread? Are you going to run the server/display on different threads? Each will be blocked wiating for the other. Are you going to run different object physics on different threads? They might pass each other silently.

Then there's the object-oriented non-object-oriented fight. For games, I write all in C. For work it's all C++/Java. C++/Java at work is the only thing to do *because* it's not just me. For a game? That's flame-war material.

I'm off topic, aren't I? Smile

[>] Brian
Quote this message in a reply
Member
Posts: 70
Joined: 2002.07
Post: #5
OneSadCookie Wrote:This is a question I'm also interested in. I mean, if you're writing pong, you can get away with a poor design, but as your games get larger it really begins to count. I feel I've been learning everything the hard way.

That's the only way to learn. Notice no smiley, I'm not kidding. This is a problem that crops up for new programmers all the time; start SMALL. Learn your mistakes on pong. Learn to modulize code in pong. Don't learn to do it while you are writting "The Legend of Kelda: The Saxophone of Time", your single-person-developed MMORPG.

[>] Brian
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
I'm just really surprised that nobody seems willing to talk about this. There are hundreds of people out there with experience developing all different sizes and kinds of game. Why does nobody talk about it?

There are vast communities dedicated to sharing knowledge about how to structure non-game applications, why has nobody even attempted to give games the same treatment?

Perhaps it's up to me to start... writing out what I've figured out the hard way, for others to add their own views, opinions and experiences... hmm, sounds like a wiki.

I can't believe I'm really the best person to begin this though... my actual finished game experience is rather small, and I was rather unsatisfied with the design of most when I was done...
Quote this message in a reply
Member
Posts: 70
Joined: 2002.07
Post: #7
OneSadCookie Wrote:I'm just really surprised that nobody seems willing to talk about this. There are hundreds of people out there with experience developing all different sizes and kinds of game. Why does nobody talk about it?

There are vast communities dedicated to sharing knowledge about how to structure non-game applications, why has nobody even attempted to give games the same treatment?

I think they are very different beasts ... here's why.

Go to work, develop a large back-end server application. You sign contracts. You have legal repercussions if you server fails and drops 10 million bank transactions. 60-80% of your staff are involved in programming, all our replacable. Code that others can understand is a must. Modulization is a must. The rest of the staff are in marketting, administration, manuals, etc.

Develop a game. 90-95% is content creation, advertising, etc. Out of the 10%, there's usually one head programmer (Carmak is a good example), others do utility work (AI for a this monster, etc.) They are usally follow *his* vision and *his* styles. If the game crashes. Who cares (this seems to be the attitude.) Getting it done for Christmas is a must.

Also, this board is full of loan wolves. I did Scruffy, Scruffy ][, Tanks of Terror, etc, all by myself. The vast bulk of people here are the sole coders of their projects.

That said, negativity aside, it's certainly a worthwhile endeavor, and it's something I wouldn't mind adding my (negative Smile ) 2 cents too.

I still don't think I have a good idea of what you are going for, though. How much do you plan to encompass? Modulizing? Getting Started? Finishing (that, right there, is a big deal, probably the biggest.) Teams? Tools? Current game programs have a wealth of tools that makes modulization easier then you'd think (OpenAL, OpenGL, any of the physics engines, etc.) Of course, this also ends up being a trap in it's own ...

[>] Brian
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #8
I've been trying to find resources concerning game engine architecture for years now, and there just isn't a whole lot out there. There's one book that I know of, 3D Game Engine Architecture, that deals with a high-level view of game engines, but I've been wary of buying it because it mostly focuses on one engine which I've never even heard of. There's another one, Game Architecture and Design, which seems to spend a small amount of time on high-level design.

As for web-sites and tutorials and what not, I've seen none that aren't complete crap. GameDev.net tried with its Enginuity articles (scroll down to general), but it's far too specific and isn't high-level enough. And it hasn't been updated in 2.5 years. And the vast majority of high-level design articles for programming have almost no applicability to game programming.

Sometimes when I'm feeling masochistic, I look through id's code for the Quake games, but that's not exactly the picture of good code design.

The people who know anything about good game architecture aren't talking, and I'm starting to get the impression that very, very few people actually know anything at all.

Maybe everyone should just post about how their current project does things, and we'll all contrast and compare.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #9
I'll post more in a little while, but the 3D Game Architecture book up there is... well. It's a good read, but in a way, it's just the code documentation to WildMagic. The book is really un-even: at times there are really interesting design discussions and a clear tutorialist voice - other times, the text is little more than call-and-parameter listings. My recommendation is to list for yourself what things you're unsure about, go to a book store and see how that particular section fares.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
Part II of Enginuity is interesting, but far too much a skim over the surface of the larger detail. The rest of the series seems to get bogged down in the nasty C++ implementation detail... looks like it's probably nice stuff if you're in C++, but it's ultimately just detail.
Quote this message in a reply
Member
Posts: 185
Joined: 2005.02
Post: #11
well, I found this diagram but i haven't a clue what it means.
Also, I found that Epic has a document on their developer website that goes over the architecture of their Unreal engine, but it is only acessible to licensees. Sad
Quote this message in a reply
Moderator
Posts: 529
Joined: 2003.03
Post: #12
http://www.devmaster.net/articles/oo-game-design/

This is a pretty generic overview.

"Yes, well, that's the sort of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage."
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #13
I've settled down to this:

I start with the main loop and I group all objects I use in a "game" class. Then I make the game routines either as method of "game" or as functions (if I want to keep them "modular"). Then I zoom out and I put the "game" class in a "program" class along with the options, different game modes, titles screen...

works enough

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #14
Warning: I am going off on several incompletely explained tangents here, please bear with me Smile

I guess I kinda qualify saying something about this, having written a largely functional, yet incomplete, game engine for my BSc thesis.

I think why people don't talk much about general game engine design is because
1) there isn't a single right way to do things, generally
2) the complexity of a commercial grade game engine is daunting for a beginner
3) designs arise out of trial and error rather than a grand plan most of the time
4) good design is worth money is a secret

The general design of any recent game engine can be said to be object-oriented. Often games are even implemented in an object-oriented programming language, such as C++. However, this only true to a certain extent, as OO has its downsides, and most of the time, to achieve all requirements, the rules have to be broken.

What requirements? Again, generally, this is what most game engines shoot for:
- performance
- stability
- extensibility
- maintanability
- reusability
- modularity
- performance

Most of these requirements can be achieved by proper use of OO, however, OO is a chief enemy of performance. OO is a strong abstraction, and when it comes to push and shove, it goes through all kinds of hoops to get things done.

The prime example is 3D graphics. OpenGL works best with large chunks of flat data, streamed vertices, triangles, textures, and whatnot. It just doesn't work to treat each of your triangles as an object. This is quite obvious, but often you have to forget about all your objects' triangle meshes as separate entities, and throw them in a pot and mix and match based on the rendering states, and pass that to OpenGL.

In my opinion, striking the right balance of proper design/coding style and brute force optimisation is the single hardest thing to do. At the end of the day, it will hardly matter how exactly your objects interact with each other, whether you swear by managers or controllers, it will only matter that the code does what it's supposed to do. And that you can still decypher it the next day.

Of course, there are other difficulties, too. For example, I have written my game engine with C++ and Lua for scripting. I didn't have a clue what to script and what to hard code. I went through at least 3 versions of different ways of glueing the script to the code, and I still don't feel like I got it right. Things work, mostly, but it's icky.

Another tough point is threading. In an ideal world, your AI, physics, graphics, sound, networking, and user input would run in parallel . In the real world, you'd just slap it all in a big loop and pretend they are sequential processes, simply because creating multiple parallel threads that share some of the data and must communicate with each other, in real time, too, is a delicate and difficult subject. You have to make sure things stay consistent, there are no race conditions, and that performance is actually better than the plain loop.

Apropos, the AI, physics, graphics, sound, etc, are all different aspects of the same game entities, most of the time (think a grunting zombie with chainsaw, has AI, needs physics, graphics, and so on). Unfortunately, the AI needs the data organised in a different way, than physics simulation or the renderer, to work efficiently. This is another major hurdle, to create a clean interface between each module that is fast, too. Your AI-physics sim interface can be ever so elegant if it takes longer to synchronise than getting your tax returns.

I will stop the rambling here. In conclusion, I think that by applying decent software engineering methodology, such as OO, patterns (eg MVC), incremental development, and so on, and by paying attention to the technical and general requirements, any decent developer can come up with a high-level architecture that will work just fine. The low level details, however, are a different story. The multitude of computer hardware and software configurations make for rather unpredictable twists, as does user behavior. If you do something very similar to something you have done before, you can take a good guess. Unfortunately, the first time you do something, you're SOL.

Reading a game programming book will show you one of a zillion ways of doing things. It's a place to start, but not the only place, and the book will show a way of doing things, but it's not the only way, and most likely not the best way. Keep that in mind.

PS: I am not sure any of the above makes any sense, but I have a lot more where that came from Wink (I could write a book full of rambling...)
Quote this message in a reply
Member
Posts: 185
Joined: 2005.02
Post: #15
DoG Wrote:(I could write a book full of rambling...)

please do! I learned alot! Smile
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Video Game Design Philosophy Carlos Camacho 1 2,880 Nov 1, 2004 08:28 PM
Last Post: JustinFic