For example, a generic system for game projectiles where variables include: speed, image file, sound effect, shoot delay, etc.
Another system for particle effects.
Another system for zombies.
Another system for weapons.
ExposureMy first exposure to this approach was way back in 1999, when I explored the Kingpin: Life of Crime game source out of curiosity. I considered sprinkled code like this to be relatively welcoming:
|G_Items.c from Kingpin: Life of Crime|
Data driven in Zombie GuardFast forward to 2015. Such a seemingly minor experience had a drastic impact on me. Most of my game projects are data driven - partly out of habit and partly out of simplicity. For example, here is the data for the blunderbuss that can be upgraded five times in Zombie Guard:
Additionally, here is one of the five sets of data for the blunderbuss at rank 1, referenced in the wtypes table inside g.wg_blunderbuss:
Data like this is passed into the function for shooting the weapon, and the generic system for projectiles uses this data as well. It is easy to compare and contrast various weapons.
One of the greatest benefits of this approach is that it scales well as content is added to a game project. For example, I could easily create a new weapon by duplicating just the data for this blunderbuss and modifying some of the variables.
Any fancy special case behavior can be controlled through a new value.
Sometimes hard coding is betterSometimes a data driven approach is not always better. I was fortunate to have forgone the approach in Defend Your Nuts for the weapons, instead, opting for a hard coded approach.
Defend Your Nuts features a bow with variable number of arrow projectiles, an instant single-target rifle, a bazooka with baby rockets, and a shotgun with variable instant damaging pellets. How could I generalize this? It would have been over engineering, since I knew firmly I was never going to append additional weapon content.
In other words, data driven approaches can be suitable for large volumes of features that share similar functionality, specified through a set of data. It depends on the situation. Otherwise, other approaches can offer more flexibility.
Room for growthI'll probably continue to make use of data driven programming. In the future I want to utilize Excel spreadsheets as a means of authoring my data. That way, data variable names are only written once for each column, useful graphs can be generated off to the side, computations can be utilized to help me balance the game.
In the first example above from Kingpin, written in C, you would have to consider the layout of the structure and maintain the correct order of value types. It was just the nature of the language. In my examples using Lua, equating the variable names gets rather tedious too.
I see spreadsheets as being very useful in my future projects...