Start testing, already!

With any creative project, you’ll need someone to take a fresh look at it and provide some qualified feedback at some point. This applies to game design, architecture, movie making and any complex creative undertaking. Even small-scale testing will help bring issues to the surface, which when addressed will increase the quality of the final product.

Unfortunately, it’s incredibly easy to put off testing. After all it requires recruitment and wrangling of testers, maybe even some material, test cases and documentation for them to follow. Then comes recording the feedback in a way that allows you to track what comes of it, your progress. If you are new to the process, it may be a tough lesson to learn that your baby isn’t perfect. You will need to get over that and start seeing the value in constructive criticism. Still, testing is a daunting task and often procrastinated or postponed.

With Torgar’s Quest, I waited until late in the alpha phase before starting to actively recruit testers. My early approach was to contact a few select friends directly, asking them to take a look. I got some decent feedback this way, but not a lot of it. I also made a few public calls for testers, but got nothing worthwhile from there. I don’t have a huge fan base to pull from, but if you do, that’s probably a good place to start.

My friend Kristian helped test the game and submitted this screenshot taken one turn before winning the game.

My friend Kristian helped test Torgar’s Quest and submitted this screenshot, taken one turn before winning the game.

What you do not want is a team of yes-men, whose approach to testing is pointing out all the things that are cool about your game. It’s great to get compliments, but testing is about finding flaws and making suggestions, not boosting your ego.

It was when I added a global leaderboard and posted a “friends only” link to a build on Facebook (of all places), that something magical happened. A few friends, who all know something about both gaming and software development, started competing with each other for the highest score on the leaderboard – feeding me their observations and bug reports as they went. Suddenly, I had a long list of things I needed to fix, tweak or add. Awesome!

Takeaway: it’s easier to get a lot of testing done, if you can tie it to any kind of event. Even if that event is a pseudo-exclusive friendly competition for early leaderboard spots.

What they found

Here is what the leaderboard looked like, right after Kristian won the game.

Here is what the leaderboard looked like, right after Kristian (Fenton) won the game.

When savvy people start poking at your game, they will find things. By savvy, I mean people who know what to look for. You may need to provide a little guidance up front, if testing is new to them.

They will find improvements that are right there in front of you. Simple changes that will elevate the overall experience, but you just never thought of them. For Torgar’s Quest, they suggested a limit to the amount of food Torgar can carry. This introduced a new layer of resource management to the game, and upped the fun.

They also pointed out that if Torgar is already holding a potion, new ones should remain where found. This way, they become a resource you can return to later, if you run into trouble (you can only carry one potion at a time).

They will force you to clean up your code. They found a memory leak of the worst kind. If the game ran on long enough, the whole thing would crash and you’d lose all progress. Which sucks. With a bit of investigation and help to reproduce it, the testers helped narrow down where it came from, and it could be fixed with a single line of code.

They will show you that not everything is as obvious and intuitive as you thought. For example, they may suggest you fix a bug that was meant as a feature.

This feedback can offer great insight for adding tutorials or for changing things that don’t work. In testing, it was not obvious to everyone that eating food gave Torgar health back. Not knowing this obviously makes the game much harder to play.

It’s important that the testers know how to report their findings. Mine were great at sharing screenshots and steps to reproduce what they found, though the actual feedback was mainly reported as comments in a Facebook post. I then copied the feedback I wanted to incorporate from the comments to Trello, my project management tool of choice for Torgar’s Quest. Obviously this approach only works for smaller projects. For a bigger test pass, I would have testers log bugs and suggestions directly to a database.

If you are working on a game (or other applicable project), do yourself a favor and start testing now. Do it in sprints of a week or two, gather intel, and you’ll have a ton of improvements to your already beautiful baby. Time to squash some bugs.

You can download Torgar’s Quest alpha via IndieDB (free,PC/Windows).

6 Tips for Game Localization

Torgar’s Quest is my first title to be published in other languages than English. I am stoked and nervous at the same time, because seeing my game in other languages is just awesome, but in my day job I work as test lead in localization testing, so I also know how many things can go wrong.

To help myself and other game developers, who are considering getting their games localized, I have put this list of Dos and Don’ts together.

1. Separate the content from the code

The first thing you need to do, if you want to localize your game, is to replace all hardcoded strings with a script that pulls it from a data source. When a string is needed, that script is called using a reference to pull the right bit of text.

For Torgar’s Quest, I have a script that takes 2 arguments; a filename and a number. The filename refers to which file the string is in (see below for more on that), and the number indicates which line the string is on in that file. The game loads the language setting into a variable at the beginning, and this variable is used in the script, to pull the right translation.

2. Get organized

To stay organized, consider splitting the text assets into multiple files, divided by area in the game (or in some other logical way). For instance, you can keep all menu strings in one file, and the in-game story strings in another. Splitting content into categories like this, makes it easier to find specific strings and to reference them in the code and when communicating with translators/testers. Staying organized is key once you start asking others to work on the localized content.

3. Prepare your game

Many things you take for granted in English might be completely different in other languages. English uses a lot of short words, for example, but this is not true everywhere. For instance, German has lots of really long words that may not fit on tight buttons. Japanese is different again, with its own rules for text wrapping. These are things to research and keep in mind when designing menus and UI elements.

Quick tip: Use W to see how many characters fit in a text box, as it is the widest character in the Latin character set.

Besides making room in the UI, you will also want to make sure that the fonts you are using contain all special characters and diacritics used by the languages you intend to include. Obviously, trying to display characters not included in the font set, will not work out in your favor.

4. Standardized formats are not standard

Metric system vs. Imperial? If your game uses distance, weight or other measurements, you better make sure the right format is supported. Don’t assume that a Swedish gamer is familiar with how far a mile is (and just to make things even more complicated, try looking up how long a Swedish mile is). The same goes for time. You might be used to a 12-hour clock (am/pm), but in many countries the 24-hour clock is standard.

Date formats and decimal separators also differ from region to region. For example, in the US people are used to seeing MM/DD/YYYY as the standard date format, whereas in Europe it is typically DD/MM/YYYY. When displaying a date like 1/10/2015, this distinction becomes important. Decimals and thousand separators are a similar difference. In the US, people use a format like 1,234.5 but in other countries it might be 1.234,5.

5. Provide context

Never rely on translation without context. If you can’t provide a copy of the game itself, at the very least provide some screenshots and a design document, describing the game. This is important, because words can often be translated in many different ways, some of which will certainly not match the context of your game. These issues will not be caught by a spellcheck, or someone looking at a list of strings, and could end up making your translation nonsensical or even involuntarily hilarious when seen in the game.

On that note, do not ever rely on auto translation. Google translate does not understand what your game is about, nor can it look at a screenshot, and it’s just not good. Don’t do it. Ever.

Context is also helpful in cases where you are using puns, pop-culture references or other linguistic finesse in your content. Such strings may need a complete retranslation to work in the intended market, which a good translator should be able to do – but only if they are aware of when it is needed.

6. Allow time for testing

Once you begin separating the content, you will probably realize that there is a lot more written content that you thought. These take time to translate, and after you’ve integrated the localized content, you are still only halfway done. Next up is the localization testing.

In a perfect world, you will have someone who is a native speaker, but not the same person who translated the content, testing the game with its localized assets implemented. This person will need to cover every area of your game, and see every single string in place, to check for things like consistency (did you translate XP the same way everywhere?), grammar and typos, things out of context or strings you missed, when you were separating the content.

Each issue needs to be described, logged, evaluated and fixed. Then the fix needs be put in, so a new build can be sent back to the tester for verification. This process takes even more time. Make sure you plan for it.

These are some tips that will hopefully put you on the right path. As for which tools to use, that depends on the size of your team and your project. I use a combination of spreadsheets, text documents and Trello, which I may cover in a later post.

Designing Procedural Dungeons for Torgar’s Quest

Torgar's Quest
There are many ways to approach procedural level design. For Torgar’s Quest, I wanted randomly generated mine-like dungeons, so I went with the carving approach: starting with a map filled with “walls” from which you cut out the level.

The key to this approach is designing the carver object, the thing that cuts out rooms and corridors. You need to make sure, you don’t get too close to the map edge, or you will have a hole in your level. You’ll also want to decide when to turn in a new direction, and to do so at a good rate, thus avoiding long, unbroken corridors on one end of the spectrum and huge caverns on the other end. I spent a lot of time changing parameters to find an algorithm that generated the kind of map I wanted.

Torgar's Quest

I realized, I would need more than one carver object in order to spawn off side corridors. At first I spawned these at different pre-determined coordinates and let them do their thing. However, this approach proved imperfect, because half the time one or more carvers would fail to connect with the others, so there was no path there, which in turn caused problems when spawning in things like the player and the level exit.

To fix this, I ended up creating a master carver, which would then spawn other sub-carvers from within its own path. These new carvers thereby start from somewhere along the main path and create forks in the map. The trickiest part then, was balancing when and where to spawn in the sub-carvers, in order to get a dungeon that felt right. Again, this came down to trial and error.

Torgar's Quest

How I did it was based on time. The master carver runs for X seconds, and after a quarter of the time has elapsed, it spawns the first sub-carver, then again at half time, and finally again at three quarters. At full time, the master carver destroys all carvers and moves on to spawning in monsters, etc.

One challenge with this approach is time. The carvers need to crawl around and generate the map, but I did not want long load times for the player. A few seconds was fine, because it gave me a chance to display a new bit of the game story, but it had to be balanced. Initially it took too long for the maps to generate, so to fix this, I sped up the frame rate of the game while the map generated, thereby speeding up time in a way.

Once the carvers are done, the loading screen goes away and the action begins.

For more about Torgar’s Quest, check out the website (where you can play the browser version, too).