Building Browsergames

Game Demo and Simple User Registration

One of the concepts I have been playing around with is allowing visitors to play the game, live, before signing up. Allow them to play for several rounds before forcing them to sign up to continue. There are advantages and problems associated with this, but ultimately it might prove a better user experience.

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.