Finding the motivation can be extremely difficult with any open source or projects that don’t make money. There are real life situations that require attention and building a browser game can take quite a long time. If you can only put a few hours a day or a few hours a week, then it will be a year before anything can be shown to the players.

A game project never dies, unless you consider it dead and you’re never going to work on the project again. If you walk away from a project, then walk away from it. If you eventually want to work on it again, then forget about it and come back to it when you are ready.

I consider one of the projects I worked on to be dead, because I was only motivated by another to work on it and they stopped. I’ve stopped working on another project, but I picked up on it again after about two years. I didn’t consider myself ready to really put my all into it and I sought out to find my inner developer. After two years, I’ve grown as a developer and experience and I am ready to develop the library with greater motivation. Thinking back, I’ve never considered it a dead project, I’ve always wanted to go back to it when I had the time and motivation to start working on PBBG projects again.

I’ve seen many dead projects that haven’t had any updates for a few years. If that is going to the case, then leave an update for those who are visiting saying whether you are continuing the project or letting it die. If you are unsure, then say so. The worse messages are ones that state that they will pick up in a few months, a few years ago.

I believe the feelings are mixed with killing game projects, because a following might have picked up, even if a small one and you don’t want to disappoint them. If you have a well established project, then you can see if someone else wants to pick it up instead of letting it die. What matters the most is how you feel about the project. If you have a bad taste in your mouth about leaving it, then will that motivate you to go back to it or will it keep you away? If it is the latter, then you know, so inform those who don’t know you of your intentions.

What are your thoughts on dead or dieing projects that you’ve seen or worked on?

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.

You can see this in action on virtually any website you visit, whether it’s a browsergame or not. You type some text into a box, hit the ’submit’ button, and then when the new page has loaded, if that input area is still there, it will still have the values that you entered earlier. This is a really nice feature, that’s really easy to implement.

All you need to do is set the value attribute of your inputs to the variable that stores the information sent to your page.

Let’s say, for example, that in your PHP page $_POST['username'] has the value that the user typed into the ‘username’ box. To set the value to that, all we’d need to do is put value=’$_POST['username']‘ inside our HTML code that we are outputting, and make sure that it’s in a location where the value of the variable will be interpolated into our output.

If you’re using a templating system, this (usually) becomes even easier – under Smarty for PHP, you can use something like this:

<input type='text' name='username' value='{$smarty.post.username}' />

If you’re using Perl’s HTML::Template, you can use the associate argument in your constructor, with a CGI object:

my $query = new CGI;
my $template = HTML::Template->new(
		associate	=>	$query,
	);

And because the CGI object has a param() method, HTML::Template will just automagically store the values into any area where you’ve defined that they should be displayed, like so:

<input type='text' name='username' value="<!--tmpl_var name='username'-->" />

And that’s all there is to making your forms remember their values – a simple change that will help keep your users from getting frustrated with using any of the forms in your game.

While most developers have been eager to adopt Ajax and build it into any(and sometimes all) of their projects, the core of the matter is that you don’t really need it, and you shouldn’t worry about it until later.

There are a few reasons for this:

Users with Javascript turned off

According to browser stats from the W3C, as of January 2008 95% of their visitors had Javascript enabled – but what about the other 5%? If you don’t make sure to build the parts of your game that are Javascript-driven in such a way that they will also be available to users who don’t have Javascript turned on, you’ve effectively killed your game in their eyes – users with Javascript disabled will think that it’s broken.

And don’t think that you can just have a boilerplate disclaimer that says “you need to be using Javascript to use this site” – some users might be accessing your game in a situation where a network or systems administrator has told them to absolutely under no condition enable Javascript. It sounds strange, but it happens.

Browser Incompatabilities

While this can be solved with extensive debugging, if you don’t use Javascript, you’ll never encounter a problem with how your game behaves from browser-to-browser – and there will never be strange Javascript errors that you need to debug. It will all just work!

Javascript for Javascript’s sake

Some developers tend to go overboard when they first learn about Ajax, and start adding it to everything – instead of having a link to a page in a situation where a link to a page would be ideal, they write complicated Ajax wrappers to load the page and display it. This is a clear case of too much Javascript, and it will frustrate your users.

At the end of the day, whether you use Javascript/Ajax in your game or not is completely up to you – but carefully consider any decision that results in adding Javascript – will it improve the user’s experience? Will the feature still work as intended for users with Javascript disabled? Both are important questions you need to ask and answer before you write one line of Javascript for your game. Doesn’t matter how cool your game is.

It’s happened to all of us. You visit a website and try to get somewhere that looks interesting, and suddenly you see a “Whoops, you need to be logged in to see this!”. So you click on the register button, and you get the standard registration form: username, password, password confirm, and e-mail address.

As someone building a game, you will eventually have to answer the question: do you really need their e-mail address?

A lot of people justify needing a unique e-mail address by using the logic of “everyone else does it, so I will too” – but that’s wrong. Requiring a user’s e-mail address so that they can register is a bad idea unless you actually need it.

When do you need a user’s e-mail address? When having multiple characters for the same player would seriously distort the game – and that’s about the only time. In virtually all other cases, you do not actually need a user’s e-mail address.

Will it hurt you to ask a user for their e-mail address? Not really – but it tends to aggravate users if their e-mail isn’t actually needed to play the game – and in a lot of cases, the more tech-savvy users(and therefore more likely to try and register multiple accounts) will just use a temporary e-mail service like mintemail to provide you with a temporary e-mail address and make sure they don’t get spammed.

Even in the case of multiple accounts distorting play, you don’t really users to have unique e-mail addresses – you just need to do a bit more checking to make sure that two characters aren’t cooperating too much. How you define that is up to you – but as long as you have something in place to allow you to track which players interact with which other players and how much cooperation is going on between two specific characters, you’re fine without e-mail addresses.

There are sure to be some false positives using the above system. But no matter what you do, you cannot prevent someone from cheating if their mind is set firmly enough on it. That’s it. They’ll make temporary e-mails, they’ll create multitudes of characters, and they’ll find creative ways around everything you throw at them.

So do you really need users to give you their e-mail addresses? Think long and hard about it – because chances are, you don’t.