New Website

I have set up a personal website that will replace this blog!

I will be writing on the new site more frequently, linking to my free games and filling the place with lots of WebGL side projects. Here it is: http://samcodes.co.uk/

A lot of my open source code is going up on GitHub too: https://github.com/Tw1ddle

So long blogger!

Localization and Games

Without localization I would never have played games like Final Fantasy, Pokemon or Touhou. Localization was very important for bringing games to me. Mobile game markets around the world keep growing, and it just keeps getting easier to distribute games. So I start from the supposition that one of the biggest mistakes that developers can make is to ignore the importance of being ready to localize their games.

The scenario I think of is this - what if one of your games gets a popularity boost when a foreign YouTube celebrity reviews it? You may want to localize quickly to appeal to your new fans, but you might be presented with a lot of technical problems if you have not already prepared for this.

Here are some technical issues with replacing just the textual elements:

1. Support for extended or foreign character sets.

2. Some strings being longer than others and overflowing UI bounds.

3. Having a UI that can actually accommodate more text.

4. Different units for currency, speed, time, date, and so on.

5. Different order of string replacement needed for variables you insert into strings.
6. Being able to accurately detect the locale across all platforms in the first place.

7. Being able to QA test the different localization and UI configurations effectively.

The list goes on and on. Point 7 is a killer - if you do not implement runtime localization and UI reconfiguration, you (or somebody) is going to have to spend way longer testing this stuff. Furthermore, if your game has cultural references in art or music, you'll probably have to change those. I don't necessarily mean the Castlevania-style making your statues less naked changes, but good reasons like swapping voice acting tracks about. For that you need an asset lookup and replacement system that is aware of the system locale.

You also need this stuff automated away at a level below your game and tested using an automated suite. In the long run this saves money and time, which can be valuable whether you're a large business of a lone developer.

The creator of Papers, Please! wrote a lengthy article about the work that was put into localizing the game, which shows just how much work goes into this. I'm convinced that some of it would have been easier if he had used a mature localization framework at his disposal from the start. I looked at the available Haxe libraries out there for localization and found firetongue and thx.culture, which look like useful tools. But on the technical side, I think it is going to be a long time before Haxe has a library like ICU.

I'll look into this in more depth when localizing some of my own games in the future.

TypeScript 1.0 RC

Excited to note that TypeScript is nearing a 1.0 release. A lot of stuff has happened since I last looked at where the language was going, and I was pleased to see that three.js TypeScript definitions made it into DefinitelyTyped. There are about 300 TypeScript type definitions for popular libraries in there now.

TypeScript is a great springboard for getting into web development and is a massive improvement over using straight up JavaScript. The tools support is magical and a definite improvement, and as already demonstrated by groups like the Turbulenz people, it's good for games.

A potentially sticky point I wonder about is tools support maybe never becoming comprehensive enough to match the built-in Visual Studio offerings, and this in turn maybe limiting uptake by developers on other platforms.

Virtual Economies and Goldfarming

Back in the day I played RuneScape. It had unusual PvP mechanics and a great community.

The combat system was overhauled last year, which put me off the game. But eventually, owing partly to negative feedback about the new combat system, an official old version of the game was released called RuneScape 2007. I had a look at the RuneScape 2007 servers. All characters started off fresh. It would have taken forever to level up again, so I never really got back into it.

Now, Runescape has black market that deals in virtual goods exchanges for real-world cash. At the time it didn't occur to me, but with a little forward planning and a lot of bot script preparation it would have been possible to have a bot farm ready and waiting for the release.

Here is an example of what a gold farmer could have done using bots that did pickpocketing to collect gold at the start of RuneScape 2007:

1. On occasion pickpockets get caught and take damage from NPCs. The first step would have been to get health restoring food - the cake stall at Ardougne would have been a good bet.
2. After getting set up and in position, collecting 12,000 cakes per bot would take perhaps a couple of days.
3. With the experience gained from cake thieving, the bots could be put straight onto pickpocketing the Knights of Ardougne that patrol around that area for 50 gold per success, running to the nearby banks for cakes when health dropped.

Given 25 bots, each successfully thieving from an NPC around once every 5 seconds and going non-stop, a gold farmer would bring in about 20 million gold per day that they could pass on to resellers. In the first weeks prices were around $20-100 real world dollars per million RuneScape gold, as borne out by historic quotes on forums like Sythe.

Based on these figures, an efficient and dedicated botter could have made tens of thousands of dollars worth of gold in just a few months. Now that is partly speculation and a best-case scenario, but it's clearly a tempting offer for many, which is why gold farming is so widespread.

There's a good case study about RuneScape 2007 goldfarming here:

TypeScript for Games

Last year I attended a talk by graduate recruiter Mark Hope and Microsoft evangelist Lee Stott, talking about jobs in the games industry. I asked Lee about possible future use of TypeScript for browser games. At the time he said that TypeScript had it's place firmly in little 2D games and web applications.

That view was understandable - the problem I've ran into recently is that canvas rendering on mobile can be quite slow. I found this when I started porting The Crate Flood from ActionScript over to TypeScript and tried it out as a PhoneGap app. The canvas rendering times seemed poor (using a Sony Xperia P with stock browser):

The Crate Flood on HTML5 Canvas

The stats bars show the time spent in a rendering loop versus the update loop. Clearly something is going horribly wrong and I think it was down to a lack of hardware accelerated rendering. The code, both TypeScript and generated JavaScript, are available on github: https://github.com/Tw1ddle/The-Crate-Flood - it should run on most browsers. The JavaScript code is included.

The Crate Flood with a debug GUI, debug console and performance stats

A really nice thing I've noticed about TypeScript is how effortless the debugging is. There is good tools support in Visual Studio, and then at runtime it is dead easy to quickly add in libraries for use as debug terminals and GUIs for investigating problems or inspecting game objects.

It looks like in the past few years things have changed with regard to rendering performance. The Turbulenz engine and other trailblazers utilize a WebGL renderer for high performance rendering. They also use TypeScript to create a more maintainable and reliable games engine. Furthermore, Microsoft have delivered a build of Internet Explorer 11 in the Windows 8.1 preview that implements a good chunk of WebGL functionality.

However the main reason for me being attracted to TypeScript is that the optional type annotation provides a lot of the information that most JavaScript projects lack. It seems to me that projects such as three.js have struggled to make for up that in their documentation (though they do make up for it another way - with a huge set of examples).

Another great thing about TypeScript is that interfaces can be defined to existing JavaScript code, with many popular interfaces kept on github. Given time I intend to look at the three.js TypeScript interfaces and add more comments to improve the documentation that can be generated from them.

Search for a Star Again

I took part in Aardvark Swift's Search for a Star. Like last year the second round fixing broken code and making a fun game out of it over the course of a week. It was coded in C++ with no middleware besides permitted use of the DirectX SDK and standard Windows system libraries.

Simple Polygon Wars

I used XAudio2 for music, SAPI for text-to-speech and basic DirectX for graphics. The game was a simple shoot 'em up. With a lot more work it would end up like a Polygon Wars clone. Rather than attempt to add advanced graphics I concentrated on events and getting audio working.

Enemies came onscreen timed to the music and voicing. The aim of the game was to keep your blue square alive as long as possible while shooting at enemies. Here's a video of the gameplay:

On the technical side C++11 features were used and an event handling system that bound lambda functions for execution later was implemented. I used a combination of Perlin noise and interpolation to move the enemies about in an interesting way.

I think a good addition would have been to use audio analysis features such as beat detection to influence the gameplay, maybe affecting movement of some enemies or the rate at which enemies came onscreen. Adding custom shaders and particle effects as well as a better HUD would be the best additions on the graphics side.

Here is a git repository with source code and binaries thrown in. The program is tested working with Windows 8 using Visual Studio 2012 and the DirectX SDK installed: https://github.com/Tw1ddle/SFAS-2012-2013

Damselfly Catcher

For my final university project I made a game to investigate an effect called motion dazzle. This effect is hypothesized to make tropical "helicopter" damselflies harder to capture while on the wing. The idea was to test whether the whirling of the markings on the damselfly wingtips could make it harder for predators to estimate the speed and trajectory of these damselflies.

Megaloprepus caerulatus damselfly (Steven Johnson).

The principle behind the effect can be compared to ship "camouflage" schemes in the World Wars that were designed to make the actual size and velocity of a vessel difficult for hostile submarines to determine, rather than aiming to make the ships harder to spot at a distance.

Dazzle-painted warship.

A similar principle may apply that could help large, conspicuous and slow Neotropical damselflies avoid predators. Ambush predators like perching birds might swoop in on a damselfly but be confused out of a kill due to the motion of the damselfly wing markings.

The cross-discipline aspect had me presenting these ideas to biologists, psychologists, physicists and artists in order to source assets and provide a solid basis for investigating the hypothesized effect for the first time in this context.

Rufous-tailed Jacamar (Magnus Manske).

The game is available free on iPad and was written in C++ with the Cinder framework. The game is called Damselfly Catcher. Crowdsourcing the creation of experimental results was done, with about five thousand crushed-damselflies worth of data voluntarily collected over the first few days.

Unfortunately the results of the experiment were not conclusive due to limitations of the experimental design, however research into the effect is going to carry on. Human applications of the effect could include the use of specialized paint schemes to protect moving vehicles in low tech warzones.