usability
Post Mortem: TerraTanks: Dominion (Part 2) Need to improve
Really this section could go on forever. I fell into a despair about the game 2 months ago where every week I would make a large update to fix what I thought was the game not being fun and by the end of the week the game was not fun again. This has since dissipated and I have been having a blast with the game.
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.
Gameplay Symphony
There is an analogy that I’ve found useful in putting into perspective any new features I want to add to my game. We’ll call it the Symphony. You don’t need to be into classical music to understand it.
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.
Making your forms auto-focus
One of the small, hard to notice features that I’ve encountered on a few games and grown to love is that of the auto-focusing form field. When you go to login or register, as long as your web browser has Javascript enabled, you’ll automatically be able to type into the first textbox that you need to - which makes signing up or logging in much easier.
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.
About
Write for us!
Recent Posts
Categories
- advertising
- askthereaders
- balancing
- buildingbrowsergames
- code
- combat
- cron
- database
- design
- diaryofabrowsergame
- DRY
- frustrations
- games
- gettingstarted
- help
- hosting
- interface
- interview
- javascript
- marketing
- medieval
- monetization
- motivation
- optimization
- perl
- php
- postmortem
- productivity
- publicrelations
- review
- rubyonrails
- security
- setup
- SQL
- strategy
- templates
- terratanks
- tutorial
- Uncategorized
- usability
- workingtitle