Simple User Registration

One of the usability flaws that I’ve seen is the registration process. I have to sign up to even play the game, and often I have to fill out more information than I want to. There are ways to improve this, at the least, if you aren’t going to be implementing the live game demo idea, then create a simple registration, if you don’t already. Most usability experts are making the recommendation to use an email address for the username, much like Amazon and Google is saying so too.

That removes the requirement for a username, you’ll still probably want to have a nick name to remove the display of the email address, but you can always sanitize the email to allow for safely displaying it ask well. If you are going to request a nickname and it would be a good idea to do so, then ask for it after they are registered.

After the email address, you have the password with two fields. I would append this with a checkbox to allow for a random password to be created instead. It is also recommended to not send a password to the user. They will in most cases have to change it or if they don’t, they are liable to be venerable to a security risk of having their password sent in plaintext over the Internet in an email, which any server and computer that the computer passes through can be picked up and used by some curious person. It is recommended to let the user set their password, even if it would be easier to send them their password. An extra 30 seconds to a minute never hurt anyone.

Don’t use CAPTCHA! They are annoying and could prevent the majority of your users from signing up, because no one is going to try more than twice to play your game. It is prohibitive. You can prevent most bots by requiring email notification and activation. It won’t stop the bots that will capture the link in the email and send the request afterward. Most games will never be popular enough for intelligent bots and those sites that are will employ techniques to pass the CAPTCHA. Therefore harder ones will be needed, which will increase the false positives and irritate users even more.

Asking for an age or birthdate, might be required in some cases to meet COPPA requirements. However, if you aren’t asking for anything personal then you don’t need to get parents permission. I think asking for an email is personal according to the COPPA, but I could be wrong, because I’m not a lawyer. I would just basically have a checkbox that says that the register agrees to that they are over 13 years of age and if they below that age, then they’ll have a parent fill out the form for them.

I am 13 years of age or over or the parent or guardian filling out the form for my child that is under 13.

That should work. Probably want a checkbox for agreeing to the terms of use and site policy. However, you could do that after after they sign up and before they activate.

Additional protection of the account is overkill, because it isn’t a bank site and extra protection will just hinder the usability. A visitor expects a bank to have extra protection and will bite the annoyance. Your site won’t be so lucky. While asking secret questions for retrieving forgotten passwords is a good idea, if you are going to implement it, so do optionally and after the user registers. Secret questions and answers work well to recover passwords when the email address has changed.

Game Demo

I like the idea of allowing the user to play the game before they even register and take a peek at what the game offers. I wouldn’t allow them to play to often and would restrict their interactions with other players. They wouldn’t be able to join any groups, send materials to any other player or attack. If they wanted to do those things, then I think they are ready to register and start playing the game for real.

The best part of this, is that most visitors have no idea if they will like your game, and even with screenshots, it is still difficult to tell whether the game is up to their standards. Screenshots are static and even if you have a flash movie or screencast of the game, it is still nothing like the visitor actually touching the game controls and seeing for theirself.

The implementation will be slightly more involved, because you are required to store the state of the player in either the session or the actually game and if the player doesn’t register, then you need to delete that information. It is more efficient to store the players details in the session, because this will automatically prohibit sending resources to other players. If the resources don’t exist in the database, then you can’t retrieve the resources for which to give to the player in the first place. If the user doesn’t have a username or user ID, then there can be no relationship between private messages, groups, etc in the game.

You will need to build the game to allow for guest access, so it isn’t a completely simple task to achieve. The game controls also have to be programmed to allow for storing the contents in the session. You will also be required to import the player’s contents into the database after the user has signed up. The data will need to be inserted into the database before the user is even activated. This could cause problems, because the player will need to be protected while their account is still in its inactive status.

There is nothing better than trying before you buy, so to speak. I believe it should improve the user experience, unless you have a terrible game, then good riddance. You just saved the visitor from wasting their time and yours by creating an account.

I want to focus on 2 things that I think need talking about (and one of them is not web page layout). One is something games in general suffer from. The other is something my game uniquely suffers from.

Thing 1: Scope, scope, scope, scope, scope.
Something I have difficulty with is wrapping my brain around just how big something is going to be. While being big is not necessarily a bad thing, being big and empty is a horrible thing. When you create a space, that space needs to be filled out completely. The first game I made (Atlas: The Gift of Aramai) suffered from this. The driving principal of the game was “we want to make it big”. The fallout of this was 5 years creating content to still have the game seem desolate and empty as you character walked for 7 minuets to the next town.

It is amazing how the power of squares can effect the amount of content you have to generate. Filling area is literally X times more time consuming than filling a linear map where X is the length of that map.

When starting a game, think small. When you think of most browser games they occur on one screen. Depth is so much more valuable than breadth. Depth displays the designer’s creativity. Depth in a small game means that you can actually release your game in a time span that doesn’t drive you crazy.

Far be it from me to follow my own advice. TerraTanks is a very large game. I believe it is also a very deep game. It certainly is a complicated game that evaluates actions in a sophisticated way. It took me 2 months to finish the breadth of the game and an additional 8 months to add depth to a state where I am satisfied with my work. (2 months of that was under the public beta). I have a very long list of things to do to add more depth to the game. It is playable and fun as it is, but the oportunity to add depth seems to be expanding and not getting smaller as I create features.

Thing 2: I created an odd way of displaying the map.
This can be prefaced by saying that compared to many of my peers, I think sideways. It is fun to be unique in my problem solving but it is sometimes difficult for me to relate my ideas to the general audience.

This is what I mean. Most people when they want to create a map they will go about creating a cartesian coordinate system grid. People understand the incrementing value and it is easy to calculate distance using the pythagorian theorem. When I went about creating the map I originally thought of how space looked in my head. You have a universe with nested galaxies. Each galaxy had nested stars. Most stars are solar systems with nested planets. The idea of nesting is what stuck with me. What I did from that was to create a system of nested areas which defined my space. My galaxy was a square divided into 4 square quadrants like this:

0 | 1
----
2 | 3

Please note how like any good programmer I start with 0. Each square quadrant was divided into 16 square sectors so in quadrant 0 it would look like:

00 | 01 | 02 | 03
-------------
04 | 05 | 06 | 07
-------------
08 | 09 | 0a | 0b
-------------
0c | 0d | 0e | 0f

Now note that since I have 16 squares I am using hexidecimal notation.

What I end up with is planets that have identifiers that look like 0b23c5 which accurately descirbes the location of the planet in a nested notation. While it makes complete sense, this is really difficult to explain. Most people don’t have a computer science background and even if you do, people don’t view maps as a series of nested grids. While this way of making maps simplified programming in many respects, but it is not good to make your end users learn something like that to understand your game. The other problem is the effort to convert the game to a cartesian map is difficult and pretty much impossible now that people are already playing the game.

Game makers often fall for the old trap of either trying to show how smart they are or treating their audience with contempt for not knowing the minutea of their own passion. Really smart game makers can present difficult concepts in a way that everyone can pick up and understand. You don’t need to spell things out for your audience at every moment, but don’t make them figure you out either.

Most of the remaining issues with my game involve how to efficiently display large amounts of information. This is something I work on every day so I don’t think of it as something that I did wrong in hindsight, but something that is still in progress.

If you’ve ever listened to music with multiple instruments, you know how each instrument doesn’t play the same melody. How boring would that be?! Instead, each instrument has its own part. Sometimes groups of the same instrument are even split up into different parts. But its not the instruments I want to focus on, its the parts.

Each part is different, sometimes it may merge with another part for a time, but it will soon break off into it’s own sound. If you listened to each part by itself it would almost be like a little song by itself, but when you put all the parts together, they work in unison to create melodies and harmonies that are far more complex than any one part could be. If you have ever been to a middle or even high school band recital, you know what it sounds like when one of those parts gets off track and doesn’t mix with everyone else. It sounds terrible!

What I would like you to consider is that each feature in your game is one of those musical parts. Each one needs to harmonize and move with the others. If just one doesn’t continue to mix with the others, it can make the whole game “sound” bad!

When considering adding any new feature to your game, perhaps you can think of it in these terms and ask a few important questions:

• How does it harmonize with the rest of the game? Is it completely independent or does it somehow integrate into the game as a whole? When I use this feature, what else is affected?
• Does it cause anything else in the game to become obsolete or irrelevant, or perhaps overly important and powerful?

Even if you aren’t into music, I hope you can use this concept to focus and guide your thinking to create useful and fun new features that work together to improve overall gameplay.

It’s actually a very simple feature to add – all you need is three lines of Javascript:

1
2
3

window.onload = function() {
	document.getElementById('username').focus();	
}

The HTML you need to use looks like this:

<input type='text' id='username' />

And as long as you have both of those pieces, whenever a user visits the page the username input box will automatically get focused into. It’s a small and easy change to implement, and it makes a huge difference to how easy it is to use your game’s forms. For example, visit Urban Dead and Kingdom of Loathing and start typing the moment the page loads up – as you can see, on Kingdom of Loathing you’ve been focused into the text box, and can therefore just start typing to log in. On Urban Dead, you need to find the textbox, and then move your mouse over to it and click on it. It’s just not quite as nice and easy as having the field auto-selected for you.