My last post discussed in the abstract the various benefits of a substantial MMO Beta, and I now have a very concrete example from my own experience. Our game is at the point in development where all the major features are in, but there is still a lot of work left to make the game fun and polished. 2 months ago one of the areas that needed the most help was the combat controls. It’s something I care a lot of about personally and enjoy doing, so I volunteered to jump on that particular grenade.  It’s a tough job because controls are subjective, involve the interaction of multiple software systems, and critically affect the final game experience. No one can agree when controls (which include targeting, ability use, and camera) are good enough, but everyone knows when they suck. After spending 5 weeks on them, I can confidently say that the controls Don’t Suck. I’m not claiming to be an expert, but there’s not much documentation on the subject so I thought I would share some thoughts on the process.

Gather Intelligence

Because Controls interact with many different gameplay and design systems, I knew I had to do some research before starting to code. The first part of this was to see what we already HAD. I had been playing the beta for months and was aware of previous attempts to design the controls, and after looking around I saw there were remnants of  multiple control schemes implemented over multiple years. There was a lot of good code and many good ideas, but only one actually working control scheme, that had some issues. Additionally, there was a 90% complete back end for switching control options per-character, which wouldn’t require much modification. There were a lot of useful bits and pieces, but nothing resembling a controls system.

The second part of research was to figure out the goals of our controls system. There were 3 major sources of input here: what I wanted, what other developers wanted, and what the end users wanted. I’d been thinking about combat controls a fair bit so that part was easy. To represent the desires of other developers, I tracked down design docs and email threads about the older prototype designs and broke down what the goals of each were. It turns out everyone was trying to make the perfect default control scheme, but no one had quite gotten there. It’s normally fairly difficult to get direct feedback on controls from end users, but the game was in a beta so I just asked them. I collected the existing bug reports about combat controls and read through a few hundred complaints on the beta forums. The primary user complaints were the fact that they often accidentally attacked non-threatening objects while they were being killed by enemies, that it was hard to predict what the targeting would do, and that combat on the mouse/keyboard took more hands then they actually had. These were serious issues that had to be addressed, but for the time being they went in the back of my mind.

Prepare for the Unknown

After my week of research I now had a clear idea of what my resources and requirements were. I could have immediately started coding up the perfect targeting system that would magically satisfy all end users and fellow developers, but I didn’t.  First, I’m smart enough to know I won’t be able to come up with the perfect solution to any problem as complicated as combat controls. Second, several talented developers had already tried and failed to Solve the Puzzle. I knew that I had to redesign our code to deal with the fact that there was no perfect solution. It had to be designed for flexibility.

My first step was just to remove all of the broken stuff that obviously didn’t work. There was a fair amount of this left over from previous prototypes and removing cruft makes modifying the rest much easier. Then, I hooked up the previously-written control options back end to an in-game UI. This way it would be extremely easy to tweak individual settings without having to modify code or a data file. Finally, I moved all of the existing control options into the unified options back end. Previously they were modified by changing data files or running specific in-game commands, but now they were all modified in the exact same place. Making these changes took another week and didn’t add any new functionality, but all of the existing functionality was hooked up and ready for iteration.

Try Stuff, See What Sticks

At this point in time, I had a long list of suggestions and complaints and a system that allowed me to easily try different combinations of options at run time. I prioritized the list of suggestions (the ones I hadn’t already fixed), and just started implementing them. It only takes an hour or so to add your average control feature, which is less time then you’d spend arguing over rather it’s a good idea or not. I put in the ideas that I thought were good, the ones I wasn’t sure about, and the ones that might lead somewhere new. Important additions were the ability to specify the order of tab targeting, to change the priority of different types of targets, to automatically select or deselect on various conditions, and to modify the camera based on various actions. In between adding new features, I was constantly trying them out and seeing how they felt.

After playing around with a few odd combinations I stumbled on some pretty cool ideas. If you enable the option to show your automatic target, disable the conversion from auto to selected target on attack, set the target priority to be whatever is closest to the center of the screen, and set right click to mouselook toggle, you end up with a playable hybrid MMO/FPS control scheme. Likewise, if you enable the ability for melee attacks to ignore out of range selected targets and set the target priority to nearest, you end up with a hybrid MMO/Brawler targeting scheme that ends up being really fun for melee classes.

Publishing your First Draft

After a week of iterating personally, the control scheme options were coalescing into 3 clusters: the traditional MMO cluster that focused on precision and predictability, the Action cluster that focused on smart automatic targeting, and the Shooter cluster that used mouselook-based targeting. These would be the initial presets that players would have access to, so I made a best guess at initial settings for the two new schemes. I set the default scheme to be the same as the old settings so I would be able to compare the feedback from people who modified their controls to the control group of people using the old settings. I posted to the boards explaining the design goals and let the options loose on the Beta community. The feedback was illuminating.

That week the feedback fell into two groups. Players who had discovered the options posted generally nice feedback, but that was overwhelemed by the feedback from people who had heard there was control changes but hadn’t found the options menu. These players complained bitterly about the lack of something that was now available. There was literally no one who preferred that option to be off, so I enabled it by default and removed the option from the menu to avoid confusing people. Several other options I had added ended up being confusing and useless, so I removed those. Others fit into a middle ground where some people liked them and some didn’t, so I left them disabled but kept the ability for end users to override them. Using the feedback from that week’s beta testing, I made a bunch of modifications to the defaults for next week’s test.

Polish and Iteration

The feedback after I updated the defaults was significantly improved. There were significantly fewer negative comments on targeting than before. There was still a lot of specific feedback about missing options and confusing text, so I knew my job wasn’t done. By having week-long iteration cycles with direct player feedback, I was able to very quickly focus on what else needed to be done to make the controls system as good as it could be. After two more weeks of changes and feedback, the iteration cycle was over and I was happy.

6 weeks ago, the combat controls were one of the most commonly argued about features on the beta message boards and were a source of significant player rage. After last week’s playtest I took a look at the feedback threads and there was not a single negative comment about the combat controls, which shocked me. There were also very few positive comments. This could be because players don’t really like them, but lack of discussion is really the ultimate goal of controls: if no one notices the controls, they’re perfect. I’m sure the combination of rising player expectations and bugs will cause future complaints about controls, but it’s very satisfying to dramatically improve the experience of thousands of players over such a short period of time. That’s why MMOs need Betas, and that’s why I like working on them in the first place. It’s not about solving puzzles, it’s about making (virtual) life better for real people.