Polishing a Game

Luck of the Draw - A Wide-Open Time Line

I'm now a contestant for the Mozilla Game On 2010 competition. It's odd that most people I've heard from were hard-pressed to prepare a game for release. You see, I started this game for fun, and it just happened to coincide with a contest for exactly the kind of game I was writing.

Runestone Wisp was feature-complete roughly by the start of November, after over a month of hard-driven development. That felt like victory, I was done writing my game! I started asking people to test it out at that point, and I thought was done. For a lot of the people now entered in Game On, they were done in that amount of time, because they hit the submission deadline.

So why have I been so busy working on my game for the last two months? While the core game has not changed, the quality of the user experience is far, far more advanced than it was. I have learned more about support during the last two months than I have in 13 years of programming professionally.

The Introduction

My first feedback showed that people were confused about the objectives of the game, overlooking the map and wisp entirely and focusing on the runes and how they interact. To combat that, I added the Introduction. It's just a simple little animation with captions to show you the "heartbeat" of the game. It's done using the same map animation engine the game itself uses. For those who can see the intro, it's a solid start that teaches the motivation for the game.

It's not really enough. It should run in IE to get those users motivated to switch. And I would still like to expand the introduction to a larger video showing how the runes drive the Wisp to do what he does, but I have to stop for now. Before I can do the Introduction justice, I will need to learn more about making internet videos, and it's not in my schedule (yet!)

The Goldilocks Tutorial - Too Much or Too Little

I never knew how delicate it was to create a tutorial for a game until I tried. Runestone Wisp is a HARD game. I don't expect everyone to be able to read a tutorial and jump into any given level and be able to finish it. There are a lot of rune types, each with its own rules to internalize. So in a sense, most of the built-in levels are PART of the tutorial process, adding complexity level by level. There is going to be some work to get into it.

That does not mean it's acceptable to have people asking, "I see a blank grid at the left. Is there supposed to be something there?" (One of my early Opera testers asked me that.)

So I built a tutorial. The original version was very static and told you exactly what to do, in what order and made sure you did nothing else. It was much TOO helpful and took too much of the design and creativity out of the levels covered. While the users ended up knowing exactly how to do the levels in the tutorial, they never got a chance to THINK about it, which ruined the game for them.

I was so disheartened by the user-response to the tutorial, I almost gave up on the whole project. Maybe they were right? Maybe the game just wasn't fun. Instead, I hid most of the tutorial and added warnings to what was left to tell people the tutorial was a spoiler and they shouldn't use it.

Then I moved to improving parts of the game I understood. (Copy-and-Paste for example.) As a lone developer on a project, it's important to be flexible and not let one setback stop you from making forward progress. In fact, when I got the other issues fixed, it gave me the courage to go back and work on the tutorial. It was much harder to build a flexible tutorial than it was to build the simple, static one. I am glad I took the break before diving into it.

The current generation of the tutorial dynamically examines what you've done and advises you, from where you are, how to move forward. And it doesn't try to help you through all the rough spots. Those are important! It just gives you a little shove over the hardest part of the learning curve and then gets out of your way. It's smaller, better, and more sophisticated.

Hotkeys, Copy-And-Paste, Palette

I got high-praise from one fan for the highly polished interface, which never would have happened if not for the immense amount of feedback I've gotten from gamers. I knew going in that I wasn't going to compromise on hotkeys and usability the way other engineering game developers have done. JavaScript makes it too easy to implement a hotkey for every major operation. And with the security holes patched around the system clipboard, JavaScript is now at least as good as Flash at implementing copy-paste that works across tabs, windows and even applications.

I resisted the idea of adding a palette of runes for a very long time because it seemed so redundant, when all the runes are available right there in the menu... just click where you want a rune. So when I finally implemented the palette, I was amazed how much it improved the game. Now it's one of the features I'm most proud of, but in the process of putting it in, I broke a bunch of things, which would have been ok if I'd started it sooner. But late in the process, it was unfortunate that suddenly Moons and Corks stopped working.

The palette also gave me a place to post the available count for limited-quantity rune types. This is a huge boon for copy-paste, because it lets me flag runes which aren't allowed in the level in a very visible and understandable way. It also aids greatly in the next topic.

Implementing Challenge Modes was Worthy of a Gold Star

The same fan who told me I have a polished interface also told me that I have a shallow game. (Not in so many words. And he said it after playing for at least 16 hours straight.)

See, when you put a game out in front of an audience, something odd happens. They play it wrong. In my case, the problem is users aren't trying to engineer a solution. They just hack out something that works. In some cases, it works 1 time in 8 runs, and they call that good enough. That was NOT what I expected! Because it's not what I, as a software engineer, would do.

The fan who was complaining should have known better. He had played engineering games and knew he should have optimized and refined his solutions, but there was no incentive, in Runestone Wisp, to spend time once you completed a level. So he felt let down that the game gave him full credit.

I had to provide him the challenge of doing real optimization and testing. I had to enforce Murphy's Law. But at the same time, my SISTER plays this game, and I didn't want to make all her solutions that barely work obsolete. So that's when I came up with the Gold Star bonuses. Most of these are based on my Murphy's Law implementation (discussed earlier), but I also threw in some Gold Stars based on limiting yourself to very few runes or threads for variety.

You can still finished a level and move on with your flaky, hacked together, unoptimized solution. But, if you're able to go above and beyond the bare minimum, you will see a simple Gold Star on the level select screen. It's all about providing the maximum entertainment hours for the user, and part of that is replayability. You would be surprised how much time a gamer will spend repeating the same levels over and over to get the perfect score, provided you tell them what constitutes a perfect score.

Browser Combatibiilty and Bugs, Bugs, Bugs

Of course the expected outcome of any long testing cycle is the opportunity to track down and fix as many bugs as you possibly can. Since I do the majority of my development in Chromium for the awesome debugger, my first list of browser compatibility bugs always comes from Firefox. (And at least half of them are the lack of a built-in "console" object.) But I've also had the opportunity to work through the issues with Opera and learned some things about a browser I'd never used before.

In the end, the result is a better game, more likely to please the user and less likely to frustrate, and that makes me very happy. Having fans is great. (Money would be nice too.)