Anyone know of good articles on design patterns for modern first person shooter games? I'm looking for a high-level engine architecture breakdown, like a description of modules (scene management, resource management, networking, rendering, etc.) and details on how they communicate with eachother. The more theoretical the better, I'm not interested in specific implementations but in engineering approaches to this type of software.

im not really qualified to answer this but usually the theoretical questions are easier to answer than you would believe, such as how antialiasing works and so on

I'm not interested in solutions to specific features, such as how to do bump mapping or how to read commands from the keyboard. Most of my experience to date has been with large-scale, distributed, multi-tier information systems, and I can map out the software components and layers that are needed for these types of systems. But I know relatively little about game engine architecture (game engine = robust platform for running 3D, multi-user interactive content) and I would like to gain some knowledge in the field.

go to college

no thanks i'd rather just sit aound and get high

I love you

10 update all objects in game with Δt
20 render all objects in game
30 goto 10

Seriously it's just a loop that just repeatedly acts on a big array. There are no standards for the architecture or meaningful design patterns other than the huge loop with a bunch of tight inner loops design pattern.

There are some patterns. Game state has accepted methods of management that could be considered patterns. I like the use of state hierarchies for game state, as outlined in this article.

Thanks, Emon, that's exactly the kind of stuff I'm looking for. Jon, I'm sure there's a little more knowledge than that accumulated in the field, no?

You should head over to beyond3d. Its a whole other level there.

Fardreamer i am doing a Games design course and one of the classes is theory.

Look up: Semiotics (visual) , Visual structuralism and mise en scene.

:eng101::eng101:

if(getThingFlags(source) & 0x8){
  do her}
elseif(getThingFlags(source) & 0x4){
  do other babe}
else{
  do a dude}

Ruthven, he's asking about engine design, not artistic.

im personally interested in seeing what fardreamer finds, I wouldn't mind reding it too

'Accepted' implies there is anything approaching a standard. There isn't, and the PDF you linked takes an awfully narrow view of what a gamestate is.

Tons!

Some guys from Gas Powered Games gave a lecture about how they did gamestate management in Dungeon Siege a few years back.

The Dark Engine (Looking Glass Studios) team talked about how they shifted entity properties management from the traditional database-inspired model to a richer, metadata-backed structure.

Tim Sweeney is always quite forthcoming with technical notes and inspirations for Unreal Engine. For example, gamestate serialization is handled through UnrealScript.

Some guy on Gamedev.net started (and never finished) a series of articles called Enginuity, which went into details on how the author prefers to design an engine. The article spends most of its time covering C++ implementations of common design patterns.

Doom, Quake, Quake 2 and Quake 3 are all open sores now, but I should probably warn you that they follow the outer loop anti-pattern that I mentioned above.




The thing is, you can spend years studying how other teams did it and you'll never find an approach that works best for you and for your application.

engines? bah!

if(getThingFlags(source) & 0x8){
  do her}
elseif(getThingFlags(source) & 0x4){
  do other babe}
else{
  do a dude}

Actually, Jon, thanks for that info, despite the sarcastic tone you did make a good point. Not in that there isn't knowledge out there, but in the fact that designing an architecture from the ground up without consulting published material doesn't mean reinventing the wheel several times over (which is what I want to avoid if I ever approach such a project).


my artistic nourishment is coming from the 4 years of film & animation I'm taking I decided against going for a game design program because I feel that I want to approach interactivity from the artistic side rather than the industry-oriented side.

Just remember to write games not engines.

This series is pretty good. The guy who wrote it (SuperPig) is the lead developer on gamedev.net itself now, I can confirm that he at least has some idea of what he's talking about when it comes to game programming.

I meant ways that have been demonstrated to work reasonable well.


It does. I don't like how they seem to have the gamestate be the entire game loop. I used state hierarchies for a project and found them to work very well. Unlike in the article, gamestate is only one part of the system, instead of all of it.

A good graphics solution for most any type of game, is TrueVision 3D. Its very effective for its simplicity. Can be used with almost any language.

Regarding patterns? There really isn't a pattern of any sort. Like Jon'C said, it is a big loop. All I can tell you is to plan your features and game aspects and then think them through. Eventually you will build your own specific architecture that will suite you.

What makes you think I want to design a game. I'm interested in game engine technology. So there's no existing solution out there that I'm just going to 'use'.

Please listen to what JM and I are saying. There is no such thing as engine technology. A game engine is just a library for writing a game faster.

Yes, I understand that there are no 'standards' but what I don't understand is why you insist that there is nothing worthwhile to read on the subject. Design patterns, no matter how 'standard' and in widespread use, should never be blindly followed and should always require careful consideration before being used. So the fact that I research patterns that others have used in the past doesn't mean I will implement them as-is. I just think it is helpful (and important) to be familiar with things that have been done before and be able to recognize their positive and negative aspects, their shortcomings and their successes.

Here is an article I read (part of a series) that I found educational.

At what point did I state that there is nothing worthwhile to read on the subject?