Tuesday, October 11, 2011

Technical issues in vRPGs.

There are several technical aspects that frustrate me when playing video game RPGs. I'll separate them into three categories: poor quality, needless limitations and poor usability engineering.

Poor quality. 

I'm a software and ASIC engineer. Believe me, I know that bugs happen.  They're almost unavoidable in some philosophical sense. But when you release an enterprise level product--and App Store games are precisely that--your customers are correct to assume a certain level of quality. I'm seeing fewer bugs and crashes over time, which says a lot about the power of the Xcode development suite and the stability of various platforms like Unity. But it's still frustrating to see a good game concept get ruined by glaring bugs.

Module and feature testing are probably the most boring process in engineering. The code base is largely done, and now you're just trying to break it in various ways. There is a huge temptation to see this step as a big inconvenience, and just release the product as-is. This is a huge mistake. Any app with bugs is going to get beaten down in the App Store ratings. In fact, because users who delete the product tend to rate it first, your first batch of feedback might be overwhelmingly negative. Take the time to do it right!  Testing iterations will take up to 50% of your entire development budget, but you should be testing all the time. I am a huge believer in smoke tests prior to check-ins (I can't tell you how much I hate broken builds), and I admire Test Before Code as a design technique. Even if you only write the test descriptions prior to designing the module, it helps to keep you focused on scenarios other than Sunny Day (a.k.a. Nothing Goes Wrong). Negative testing with bad inputs is a great way to locate code that isn't handling exceptions well.  And face it, sooner or later you're going to throw an object on the trash heap before its time, and send something a bad pointer. It's way better to see "Failure: ActiveEffect "Hammer Smash" undefined in target "Thor", than to have your app crash and burn. Even if you release bugs, at least your users will be able to provide meaningful field failure data, especially on infrequently occurring bugs that are a pain to reproduce in the lab. 

Needless limitations & poor usability engineering. 

A lot of needless limitations come from clunky game ports, but not all. Why do I only get two save slots in some games?  Why do I need to push menu buttons twice to confirm?  Why is my inventory only eight items? Why are there arrow keys to scroll up and down on my touchscreen? Why are the text fields in this game positively microscopic? Why is the selection area so tiny and sensitive?  Why is there no Cancel button?

Why, oh why, OH WHY is there a bolt-on directional pad in your menu driven game?!?

Look, if you're going to the expense of porting and marketing a mobile video game, please take advantage of each system's control scheme and toolkits. The iOS SDK provides a ton of iPhone optimized controls. I get that some toolkits are cross-platform, but even so, you can properly architect a separation in your Model View Controller to accept different input types on different platforms. There is no reason to make Nintendo DS gamers endure a mismatched control scheme because you released on Android first. 

TL;DR:  If you're going to release an app, please test it as if hundreds of people will try it and immediately uncover all the bugs. And design the UI, menus and persistence mechanisms to match the target platform. Don't create pointless limitations.

No comments:

Post a Comment