Subscribe to:

The Kiwi's TaleWitchBlasterDerelict Blow Stuff Up

  • Warning: Creating default object from empty value in advanced_forum_preprocess_comment() (line 492 of /home2/earok/public_html/sites/all/modules/advanced_forum/advanced_forum.module).
  • Warning: Creating default object from empty value in advanced_forum_preprocess_comment() (line 492 of /home2/earok/public_html/sites/all/modules/advanced_forum/advanced_forum.module).
  • Warning: Creating default object from empty value in advanced_forum_preprocess_comment() (line 492 of /home2/earok/public_html/sites/all/modules/advanced_forum/advanced_forum.module).

Game programming stack

I have been having some thoughts about what I feel is the ideal structure for developing a game. I'm not sure if what I have to say is helpful, interesting, true or even coherent, but I thought I would publish it anyway in the hope of getting some discussion on the topic going.

I think games should ideally have a Design team and a Technical team. This doesn't mean that each person involved with a game should only be in one team (some great games are made by only one person!) but that they should recognise their roles as being separate and distinct.

I believe the role of the Technical team is not to bring the vision of the Design team to life, but give the Design team the appropriate tools for them to bring their own vision to life.

Currently, I see game development as being a stack of five major areas of focus which are divided between the realms of Design and Technology. From bottom to top:

Bottom layer: Language (Technical team)

Simply whatever language the game is written in.

C++ is practically the only option when working on a console game or big budget production, however Indie developers have a bit more choice. Cactus continues to wow people with his Game Maker creations, and BlitzMax is a perfectly suitable environment for creating 2D puzzle games.

Obviously, creating your own language from scratch for a game will almost always be a complete waste of time, unless you are intending to commercialise the language itself.

Second layer: General Game Code (Technical team)

I define this as being code general enough to be used in more then one game. This includes Graphics Engines (Renderware, OGRE etc), Physics and Sound libraries etc. I also include scripting languages, map making utilities etc in this layer.

Off the shelf is preferable for most components at this layer, but it's perfectly acceptable to write your own engines, utilities or general libraries if:

  • The existing ones won't do everything you want them to do.
  • The existing ones are too expensive.
  • You're more comfortable using code that you wrote yourself.
  • You want to sell your own engine, perhaps using the game as advertising for it.

Etc etc

Third layer: Specific Game Code (Technical and Design team)

This layer is simply any code that would only be useful in the specific game project.

While this is impractical and may be impossible in some projects, I feel that, ideally, this layer either shouldn't exist at all or should be as small as possible. Any code that could be re-used for a future game (such as a pathfinding algorithm) should be written by the Technical team into a more general purpose engine (Layer 2), and any code that is very specific to the game (such as interactions between AI characters) should be written by the Design team in a scripting language (Layer 4).

These three bottom layers all compile together to become the Program Executable. However, the layers above it can also be embedded into the Executable as well with utilities such as Molebox.

In a very limited number of utilities, such as Multimedia Fusion and Adventure Game Studio, the entire bottom three layers are already provided, allowing designers to make games with no technical expertise at all. However, the downside of these utilities is that they are very limited in scope.

Fourth layer: Design (Design Team)

The design determines things such as:

  • Variables ("The name of the main character is Mario, he can jump X tiles high and has X lives")
  • Events ("Mario colliding with flagpole triggers end of level cutscene)
  • AI ("Goombas walk in the same direction unless they hit a wall")
  • The design of levels etc etc

This layer should not overlap with layer three at all, this is achieved by having everything created with tools outside of the codebase. For instance, the number of hitpoints an enemy has should be stored in scripts, databases or configuration files - if it is in the executable, the game needs to be recompiled from scratch every time a value is changed. Ideally, designers should be able to change variables such as this without even restarting the game!

A game that has no graphics or sound (Interactive Fiction, Rogue-likes etc) is fully complete at this layer.

Top layer: Media (Design Team)

The look and sound of the game - all of the Art and Audio files.

This layer usually overlaps with the lower layers; For instance, a level created in a 3D program changes both how the game looks and how it plays. Also, Art and Sound in games is often procedurally generated from code or design. But there's nothing wrong with these layers overlapping at all.

 

Well, hope it wasn't too long and boring! Might revise this as I think about it more.

Tags:

Comments

Joshua Smyth (not verified)

I think you're mostly on the right track...

But I think you need more layers.

If you look at each layer, there exist layers within layers and layers that bridge layers. And layers that spread across multiple layers. And layers that are parallel to other layers.

Eg a scripting layer will often have a Interpreter/Parser, Common Libraries, Game Specific API and then the actual scripts. Thats four layers just for scripting.

And don't forget about Input and Output. There's a player involved in this process after all.

Earok
Earok's picture
Offline
Joined: 02/06/2009

Well, I think each layer definitely has lots of sub-layers, and game development is a lot more complicated then my model, but most things can fit.

For instance, Interpreter/Parser and Common Libraries may fit into layer 2, Game Specific API into layer 3 and the actual scripts into layer 4.

Input/Output could fit anywhere from layers 2 to 4, depending on whether or not the I/O is handled by common libraries, game specific libraries or scripts.

Certainly very complicated, maybe I should write a book to try and flesh the whole thing out!

The Earok Guide to Game Design, the book... sounds interesting

avengingwatcher (not verified)

I was actually going to ask you about this. This is very useful to me thank you. I am planning a game out right now and have gotten the graphics engine and the language I want to use but I am unsure as to whether or not physics or sound are included. Are there any books or sites you can reccomend that have an in depth tutorial on building out a roadmap for game development?

Earok
Earok's picture
Offline
Joined: 02/06/2009

Physics and Sound probably aren't included (Depending on what you've chosen) but Open Dynamics Engine and OpenAL might be useful for you. Given that I only ever program in Blitz3D or BlitzMax, Joshua probably knows far more about this then I do, there is an email link on his site.

"Andrew Rollings and Ernest Adams on Game Design" might be very useful to you, it doesn't cover specifics about languages or engines but has lots of information on things that need to be considered to make a successful game (for general game design as well as specific genres). As far as websites go, you should be able to find lots of info on Gamasutra.

Also have you made any games before? If you haven't then I would seriously consider making a few simple games to get to grips with game programming before tackling your current idea (which sounds complex, I've never needed a Physics engine in any game I've ever made!)