Game Design Theory Level 4 – Advanced Game Mechanics and HUD / GUI Elements

Usability Testing

 

By using the keys of usability checklist, we can avoid many usability issues – on a theoretical basis. The concepts make sense and should help us minimize problems. The lingering problem is, we just don’t know for sure. That is where usability testing comes into play. Usability testing lets us evaluate the game’s effectiveness in engaging an audience, its efficiency in delivering its concepts, and players’ satisfaction in playing it. It mitigates glitches, player frustration, and any other problems in the game’s design and implementation. Mostly it pinpoints the true user experience and allows time and a process to correct any problems that create a negative user experience. For video games, this is an extremely important process, as user satisfaction is really the difference between success and failure. Remember, gamers are only going to put up with usability issues so much before they simply move on to another, less frustrating game.

 

Expert Review

 expert review

So usability testing is important, now, how do we do it? One way is through expert review. Developers and game experts take a red pen to the GDD and mark out known and unknown issues and then rank those issues according to severity. The review teams then meet and discuss possible solutions. The value of this method is that it is quick and can be done multiple times throughout the development process. It is also a very flexible process that can be scaled according to issues of greatest importance. Expert review often involves rapid prototyping, which is a sort of pen and paper testing of concepts, UI design, and other instant evaluation techniques (we will expand on rapid prototyping in a later Module).  The end results are well worth the effort as this kind of scrutiny can reveal many usability problems with good use of time and personnel. As a small indie developer you can hire programmers to check your work and correct any errors. 

 

Playtesting

demeanor_sprite_1 demeanor_sprite_2 demeanor_sprite_3

Playtesting is another form of usability testing. Usually this involves allowing an early version of the game to a limited group of gamers to try out and find usability issues. This type of usability testing goes straight to the audience that may purchase the game and gets their opinions on what works and what doesn’t. Generally, players testing a game give honest, yet sometimes harsh, evaluations on whether or not they would want to play the game and detailed descriptions on why or why not. This is a group that genuinely wants good games on the market and has familiarity in evaluating their own user experiences. Remember, this is not QA testing, this is much more limited in scope. Test groups are usually less than ten people who are drawn from the game’s target demographic and often testing is done in a “lab”, in a controlled environment, as opposed to loosely tested at home.

 

Be Creative – Spice It Up

box

 

When designing your game try not to resort to simple crates and “whack-a-mole” gameplay. Think about the “whack-a-mole” game where little moles pop up and the player simply bops the moles with a mallet as they come up and knock them back down. That’s about as simplistic as it gets so don’t make your game that bland unless you’re doing it on purpose. One trick is to have gameplay that takes advantage of some kind of special trait or ability, like extra speed, strength, flying, etc. When you give your player character new abilities, use them to the fullest in a variety of gameplay settings. Things like a crate or box that cracks open to reveal a power-up or money is old and tired. Use something dynamic or themed to fit your game to deliver or present special items. Imagine a space game where loot appears in capsules and hidden compartments in ships. Imagine a game about a speedy main character with power-ups and items that require quick reflexes and great timing to acquire. Sometimes it may even be necessary to build some of your in-game content (story, environment, gameplay, graphics) around a really cool game mechanic that you want to show off which fits the game. 


Troubleshooting and Trimming the Fat (Keeping Things Neat and Clean)

troubleshooting_cleaning_code

 

When you run into errors (and you will, several times during development) the important thing to realize is that you can troubleshoot and find problems much easier when all of your code is clean and trim. If your code is clean then the most important thing you can do is to save and backup frequently. Making even a small change in a game can crash the game entirely or cause some unknown error to occur that you could not have foreseen. The best way to avoid problems is to use comments, which are “developer” blocks of code that the computer skips over. These comments leave a map for others to follow and gives them the guide they need to navigate the code behind the game. Always leave comments to explain things throughout your designs and your technical documents – even throughout the code itself. That is a common practice in the gaming industry and it’s something that can really save you a lot of time both now and later on.

 

When you simplify or trim code that means you look at all of the steps it took to perform an action and see if there is a way to do it with less steps or less code / resources used. If you can think of a better way and it works just as well you update it and save. If not you move on because you have a working system with the desired effects and you see if there are other things you can trim. Sometimes you come up with things later on in development which could make things better or more lean in a previous level. Take  time to upgrade the previous level(s) and save it.

 

In the short term, when you save often, leave necessary comments, and follow basic simplification rules you will be better able to troubleshoot errors that occur and fix them without a ton of digging and headache. First of all if you don’t save often you can’t remember all of the things you changed and how they might have caused the problem or crash. Going in armed with comments help you narrow down blocks of code to find specific issues when troubleshooting.

 

For instance if the comment at the top of a big block of code says “this code handles doors and doors only”. You’re only looking for code related to an enemy action that caused an error. You know not to look for errors related to the enemy code in the door section so you skip it. You’re mainly looking for comments related to enemies and specifically the enemy actions you were working on when the error came about. Then you read the code itself and see if there is anything wrong. This is a simple example of how keeping things clean can save you a ton of headache early on.

 

In the long term, these rules help you when you come back to this massive amount of content that you’ve designed and you’re trying to manage it and remember what’s what you’ll also have an excellent guide that’s been recently updated and relatively bug-free to begin working on again. Imagine having to read over you own work again to try to recall what you were thinking when you put together a complex mechanism that handled something important in the game. You don’t want to have to go through all of that when some simple comments can get you right back in the game. Simplification as you go along helps out later to build a more efficient game at every level so that fluff code and bloated mechanisms don’t have to be solved closer to the end of the game when they can have unintended consequences.

 

So remember – save often, leave comments and look for ways to simplify your game code to achieve a neat and clean game that is easy for you and others to work on.