Good games can rarely be created in a vacuum, which is why many designers advocate an iterative design process, during which a simple prototype of the game is built very early and then iterated on repeatedly until the game becomes a shippable product.
Sid called this process “finding the fun,” and the probability of success is often directly related to the number of times a team can turn the crank on the loop of developing an idea, play-testing the results, and then adjusting based on feedback.
As the number of times a team can go through this cycle is finite, developers should not waste time with small changes. Instead, when making gameplay adjustments, developers should aim for significant changes that will provoke a tangible response.
If a unit seems too weak, don’t lower its cost by 5%; instead, double its strength. If players feel overwhelmed by too many upgrades, try removing half of them. In the original Civilization, the gameplay kept slowing down to a painful crawl, which Sid solved by shrinking the map in half. The point is not that the new values are likely to be correct – the goal is to stake out more design territory with each successive iteration.
Imagine the design space of a new game to be an undiscovered world. The designers may have a vague notion of what exists beyond the horizon, but without experimentation and testing, these assumptions remain purely theoretically. Thus, each radical change opens up a new piece of land for the team to consider before settling down for the final product.
I’m trying to figure out how to adapt this to my work and to the work developers do at Xero. We don’t make games but that doesn’t mean we shouldn’t be trying to inject some joy into the experiences we create for our customers. Iterating to make stuff that people genuinely like using has always been my motivation, be it websites for bands or tax returns for builders in the UK. Helping people find the fun in that is just as rewarding.
…rules are code; they change the behavior of the system. Rules interact in ways that are hard to anticipate. It’s harder to write rules than to write code.
It seems like we make business decisions in terms of rules, because we talk about them that way.
People make uncomplicated decisions by rule. We make complicated decisions by aesthetic (from expertise), and these are difficult or impossible to express in rules.
If you think “Rules are declarative, they’re easier to reason about than imperative code” then go format a complicated web site with CSS. Make changes in the hundreds of lines of CSS, and see if you can predict the results. Now see if you can predict the results of changing someone else’s CSS.
This post really resonated with me, not because I’m a programmer who deals with CSS (thank goodness) but because maybe the only thing about managing people that seams easier is that you learn pretty much right away that there’s no generic thing that works for everyone. There’s no rules engine you can follow. Few decisions are simple and all decision making comes from expertise.
Development on SPADE continues! The orange and yellow area is the start. The green and orange area is the exit. The green and brown is the path and the parts that are clearly, I say clearly, rocks are the bits you can’t walk on.
Here’s my todo list. I can get rid of the first and third lines.
I’ve been playing more with level generation in SPADE. I dug up a link to Darius Kazemi’s excellent explanation of how the levels are made in Spelunky and have got the path generation replicated in some rough and tumble pico-8 code.
This took me longer than I would have liked. To be fair on myself I did most of the implementation at my daughter’s dance classes over the weekend, without internet, without a debugger, and with the distractions of a dance studio. Still, my logic muscles are somewhat atrophied.
Last night I finally googled ‘pico-8 debugger’ and found out about the printh() function and how to view the output in DebugView. Thirty minutes of reading my game’s output tonight and things are looking much better.