Game programming stackSubmitted by Earok on Thu, 05/28/2009 - 20:23
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.
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.