Patterns. Seems to be all you hear these days, right? What is this pattern? Should i use it? Is this code an example of pattern A or pattern B?
It appears that "Patterns" came about due to the discovery of recurring themes in the organization of objects in OO languages for specific tasks.
Sounds like just the thing an OO developer could use right?
Only thing is, i have yet to hear of a pattern that comes from games. Granted, i hear of many patterns that are applicable to the implementation of some subsystem of a game. And where such cases occur, i see no reason not to use traditional non-game software development patterns.
But when you start applying patterns for the overall design of non-realtime business apps to realtime games, you're heading into round peg square hole territory. The fit may not be that great.
So, everyone else has their patterns, business app development, enterprise development, etc. Why not game development?
after all, games are modeling and simulation software, which, if you've ever taken software engineering, you know is a rather different sort of a beast from all other types of apps.
so if games are a fundamentally different type of software, why use patterns from software that's fundamentally different from games?
for sub systems that are similar - sure. but for games, which are fundamentally different than the software the pattern comes from?
So what is a pattern anyway?
Well, apparently its a recurring theme of object organization for a given task.
All fine and good, but not all games are OO. And non-OO design alternatives such a component-entity systems are popular.
So can we make a more general statement about game design patterns?
an object is a hunk of data, and the functions that use it. technically, its a specific type of implementation of an ADT, an Abstract Data Type.
in fact, " a hunk of data, and the functions that use it " IS the definition of an abstract data type.
so patterns are a recurring theme of how to organize data and code for a given task.
Well, hey, there's LOTS of recurring themes of how to organize code and data for a given task in games! Sounds like games have their OWN patterns!
What might some of these patterns be?
Well, to the experienced gamedev, they'll be so patently obvious as to not even be considered a "pattern".
The very first pattern one sees in games is the "init - run - uninit" pattern.
its a common recurring theme of a way to startup, use, and shut something down, such as the game program, an individual game, or a mission.
ok, super simple and pretty lame eh? well, hey, i didn't say games had COMPLEX patterns!
second pattern that comes to mind is the "main game loop" pattern.
you see this pattern in just about every game. its a recurring theme of a way to repeatedly process input, update the game world, and render the scene.
i know, still pretty lame, but hey- its a pattern!
so what are some other recurring "patterns" in games?
entity lists
entity type definitions
a world or level map
a sound library
a graphics library
graphics specific things like render queues, scene graphics, trees, etc. now we're getting into the game parts that are more like non-game "patterns". IE its all about the TASK. a tree won't work when you need a state manager, and vica versa.
now there's an area that someone should do an article on, when to use such "game patterns".
but for each of these things one can go through and describe it as a pattern:
the entities list pattern:
entities are stored in a list. functions like render and update operate on the list.
one could also get into implementation, although that's technically beyond patterns:
entity lists are typically implemented as a vector, std list, array of structs, or component entity system.
but note that a component entity system is also a "game design pattern" -. perhaps one of the few "real" ones we have. its a recurring theme of how to organize code and data for one of two possible tasks: soft coded entity type definitions -or- last ditch optimization of update once render can go no faster and you still aren't fast enough. C-E for optimization is not a common pattern. C-E for soft-coded entity type definitions is the normal reason for C-E. And C-E has no hard defined implementation method, just like a "pattern".
So odds are there are many things like a "C-E system pattern" in games.
As i think of more, i'll add them here.
If anyone else thinks of some, please leave a comment!
already i have a bunch popping into my head:
pickray
mouse-aimed camera
heightmap
"move all, check all" collision algorithm
"move and check each in turn" collision algorithm
stepped movement
ray casting
A*
the list goes on....
maybe i should write a book! Naw, screw that! i'm too busy building games!
Funny you mention init/run/deinit, although I use init/run/draw/deinit (the reason for a separate draw function being frameskip). In my game I have different "game modes" (e.g. in-game, title screen, a menu, etc.), and each mode is literally described as a list of the four functions filling those roles (then the main loop just calls the relevant functions as needed).
Even funnier is the fact that this pattern can also be applied to entities themselves (init and deinit happening when they're created and destroyed, respectively). Again, entities in my game are described pretty much as a list of functions filling those roles, and the entity manager takes care of calling them where relevant.
For the record: the game mode pattern is one you seemed to have not mentioned. If you have a main loop then chances are you'll be using game modes.