Gamasutra: The Art & Business of Making Gamesspacer
Content explosions of exploding content
Printer-Friendly VersionPrinter-Friendly Version
arrowPress Releases
April 20, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Content explosions of exploding content
by Wesley Paugh on 06/14/11 07:02:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

I once saw a children's video wherein a kindly matriarch Fay (really a dog in disguise) prepared Christmas decorations. She popped dozens of batches of popcorn to string, but would only select the very best. '7 perfect kernels per batch!' was Fay's rule. What a lunatic, amirite?

This is what's happening in this iOS game I've been working on for the last 2.5 years. It's called 100 Rogues.  As principle (read "sole") software developer, I've done my very best to anticipate every possible, fever-dream induced, last minute, so awesome the game just can't live without it feature anyone on the team could dream up. Monsters that turn into other monsters, items that can, individually, be wielded as weapons, thrown as grenades, and eaten like candy. Switches that can open a door, teleport you through it, telefrag a rat when you get there, and automatically reanimate the corpse as a frankenstein's monster of the enemies you face elsewhere in the game, that fights for you. Totally possible.

One year after our anniversary, most of these capabilities have been used. Once. 

Take, for example, energy potions. When time (finally) came to implement items, the requirement came down to have a few items have really weird effects, like energy potions, which should explode when thrown, or health potions, which heal whatever you throw them at, rather than deal damage. How far do you abstract something like this? More abstraction means cleaner code that allows other things explode similarly in the future, but the code has to be spread out over more files and classes and content development time grows because there's so much more to choose to do (or not).

In the end I chose to make an enumeration in the XML data format that defines items, with members Heal and Explode, with hooks to add more effects if needed later on. So far, out of well over 50 unique items and hundreds of possible variations, any of which could create an AoE explosion in response to different events, only 3 items in the game have an effect that uses those hooks, and there are only 2 unique effects between them.

But that's all the game has needed! An occasional opportunity to throw an item and deal massive damage as an area of effect, something few proper player skills allow you to do across all player classes. So, is it worth it to spend so much time on coding in a clean, abstract manner for every conceivable reuse of all combination of effects and features? Should only the perfect kernels be kept? Is it at all fair to then, after release, turn around and SELL new items that make full use of an engine's potential, but weren't deemed the most essential part of the first release? To accept money for items that might actually HURT the game's overall balance (whether or not we're aware of it), in order to keep ourselves afloat? 

I, of course, say yes! I did the work, my job depends on it, me me me. So I'm going to make the flaming sword of some awe that shoots rainbows and lightning and magically teleports you when it crits if you're wearing +2 Ominous Pants of Binding. And you will LOVE paying $1 for it, even if I slapped it together in 10 minutes!

Of course, more care needs taken than that, and I have no intention of willfully taking advantage of players. I grow more and more impressed with the minecraft and dwarf fortress developers, though, for doing the continuous updates thing and NOT going crazy with these kinds of decisions, when the choice that's best for the game could mean LESS content and so much wasted potential for their carefully-designed systems.


Related Jobs

Activision Publishing
Activision Publishing — Vancouver, British Columbia, Canada
[04.19.14]

Principal Graphics Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States
[04.18.14]

Associate Engine Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States
[04.18.14]

iOS Programmer
Insomniac Games
Insomniac Games — Burbank , California, United States
[04.18.14]

Senior Engine Programmer






Comments


Enrique Hernandez
profile image
The general consensus I've seen around the internet, mostly in relation to indie developers, is to not do what you are doing.

"don't make engines, make a games" (here's an article to show you what I mean: http://scientificninja.com/blog/write-games-not-engines)

With the idea that you only program something when you need it, and not before. Because in the end you end up with a lot of unused code and time wasted.



Although I can see your point about adding new items later.

How about making the game you want it to be, and then expanding it to add more items (after the game is finished and shipped) then you can see what works and what doesn't, and then you can expand that engine and add all you want, and then be able to quickly dispatch new items for the game.



Just my 2 cents.

Jean-Michel Vilain
profile image
Like you're the first to come up with the idea to combine pieces of abstractions? :-)

Have a look at magic the gathering. It combines effects, abilities, triggers and so on to provide 10.000+ unique cards. And it's now been almost 10 years magic online is out. I bet they have set up some kind of compiler not to have to write a new class every time they create a new card.

[mode irony off]

Such game systems can only be thought by programmers or mathematicians, who share the ability to build blocks and then use them to build more complex blocks. I'm working on such a game right now :-)

Wesley Paugh
profile image
Hardly the first, I realize, of course!



Symphony of the Night sticks out in memory for its exemplary ability to have churned out the arsenal of weapons available, with completely different visual and mechanical effects, animations, sometimes even physics! Other examples surely exist.



But! SotN and other examples also have larger teams, some making engine assets and others making content, and still others balancing (or at least verifying its balance). Little old me still has tunnel vision from one role when trying to take care of the others. It still leaves me wondering if I've done The Right Thing, or not.



On the one hand, my game has been thoroughly over-engineered, since it will be a miracle if it survives anywhere near as long as Magic has and grow along the way to make all the fancy new content possible.



On the other hand, should 'it only needs to work for the first release' be justification for not taking the time to write better, more modular code?

Soroush Khodaii
profile image
I've seen 100 Rogues and it's quite impressive and I can tell that you did a great job there.



However I would say that I agree with Enrique, you should study up on Agile methodologies (example XP, or SRUM which is somewhat popular in the industry).



This isn't only about 'better, cleaner, modular' this is about MORE CODE --> MORE TIME --> MORE COST.

Part of being a good software engineer (and not just a 'coder') is being able to balance time, cost, quality and requirements.



About charging for extra items... hey this is exactly what the 'micropayment' model is all about... you've got to take advantage of that.

Wesley Paugh
profile image
I should do some more research into agile methods on a team of 1 programmer. I'm sure there's tons of blogs / features on it here. At the moment, I'm flying pretty much 100% solo, which has its own pitfalls and processes, but can't usefully fit into a Scrum paradigm, for example.



When the team was working on it, the problem became that we just couldn't commit to just the initially planned features. Early on, scope exploded from a basic ranged and a basic melee monster type into requiring rewrites to make each monster feel as unique as possible, including different visual effects, myriad buffs and debuffs, AI requirements that made most sense to implement some basic utility algorithms, things like knockback, associated skill tree rewrites for the player classes... the list just kept going.



By the time we got to items, no way was I going to believe that just because it was 'decided' we'd only need a Dagger of Poison, that there wouldn't be another must-have requirement that swords, potions, and armors also apply poisons under different conditions. Which, of course, we did, but instead of poison it was burning, which worked similarly but with different visuals. Etc., etc.



The abstractions were necessary for our requirements, and generally were applied as-needed, in the simplest way possible in an effort to stay agile. The problem is constraining requirements as much as possible / reasonable, and sticking to our commitments once we laid down our goals.



But! Deciding which features to implement based on which are the least likely to change and incur the least risk is very much opposed to the indie mindset our team had. Of course, trying to make money is also very much opposed to the indie mindset, so there you have it.

Megan Fox
profile image
You would solve this by planning what you're doing ahead of time, and sticking to that plan. Trying to account for infinite design explosion by writing an infinitely complicated solution for everything is... ill-advised, generally, as compared to just sitting everyone down and making it clear that design isn't allowed to about-face weekly after prototype is complete and implementation has begun.


none
 
Comment: