Development build 0.1.17 of Akari

Here is a short video run through of our game Akari. Akari was only ever a working title but we’ve since warmed to it a great deal. So it’s stuck! All game elements are in place. Much of the remainder of the work is in artwork, level design and exploring indexedDB for saving progress and scores.


Akari – short play demo video

Akari is a game that we’re currently thrilled to be developing here at Space Monster Games. It takes its lead from classic early 1990s shoot em ups such as Raiden and Outzone. Though the visual style is developing nicely we’re still hard at work creating some cool graphics and effects to keep you entertained for many, many levels.

More about the young hero of the game, Akari, and her backstory will follow in future posts. We hope you enjoy the video.

Friday mobile game concepts

Friday is a cool day. We put Sublime Text to one side and break out the pen and paper to craft some concepts.

Here’s a couple.

Underwater Blob Thing – in search of food our plucky bubble fish type thing must avoid spikes and other sharp things.

Affectionately referred to as PacMaze – the flappy blob thing must swing left and right to avoid the maze walls and collect power pills whilst avoiding spitting ghost things.

Building a level editor for a shoot em up – JSON issue

We have a number of in-house tools written through a combination of Javascript and PHP. The data from the editors is written to a MySQL database and much of the workflow is handled within a single page – i.e. AJAX requests firing off to the back end to retrieve and update data.

Something that we hurl around a fair bit is JSON.

Currently the focus is on building an interface for designing levels for our forthcoming shoot ’em up; Akari: Battle Star.

What we’re after is precision. That is, we want to place entities within the game to be triggered at specific times during the game’s progress.

We call this tool Neo.

The Neo data is stored in a database table that is pretty straight forward in its design.

Within the editor we select the game and level to work on and an AJAX request pulls the data from the database. The result of which is a PHP array.

We then encode the array into a JSON format via PHP’s json_encode() method. This presents us with the Javascript that we can then use to write the front end.

Manipulating the JSON within the Neo front end is straight forward and we use jQuery for much of this.

Once we’re happy with the data we then fire off another AJAX call to post the data to the back end. This is were we ran into problems.

In short we were struggling to decode the JSON into a PHP array.

The JSON format we pass in looks something like this:

    {"gameid":1,"level":1,"trigger":100,"entityType":"formation",alienRow:1}

There’s much more to the data than that but essentially this is the format. The trigger value is the stage of the game (in ticks) at which point the entity data is triggered.

When we attempt to decode this JSON string and form the PHP array it’s successful.

But when we add another object to the string, it fails.

Something like this:

    {"gameid":1,"level":1,"trigger":100,"entityType":"formation",alienRow:1},
    {"gameid":1,"level":1,"trigger":150,"entityType":"island",alienRow:0}

We couldn’t for the life of us figure out why this wouldn’t work. So we employed PHP’s json_last_error() method which captures the last attempt at decoding JSON.

    json_decode($string);

    switch (json_last_error()) {
        case JSON_ERROR_NONE:
            echo ' - No errors';
        break;
        case JSON_ERROR_DEPTH:
            echo ' - Maximum stack depth exceeded';
        break;
        case JSON_ERROR_STATE_MISMATCH:
            echo ' - Underflow or the modes mismatch';
        break;
        case JSON_ERROR_CTRL_CHAR:
            echo ' - Unexpected control character found';
        break;
        case JSON_ERROR_SYNTAX:
            echo ' - Syntax error, malformed JSON';
        break;
        case JSON_ERROR_UTF8:
            echo ' - Malformed UTF-8 characters, possibly incorrectly encoded';
        break;
        default:
            echo ' - Unknown error';
        break;
    }

We received the error

 - Syntax error, malformed JSON

Some of you seasoned eagle-eyed Javascript gurus will have already noticed the problem.

We were trying to construct a Javascript array by formatting it badly.

The JSON we should have been passing looks something like this:

    {"data":[{"gameid":1,"level":1,"trigger":100,"entityType":"formation",alienRow:1},
    {"gameid":1,"level":1,"trigger":150,"entityType":"island",alienRow:0}]}

Once we’d defined the Javascript properly in an array format the decoding worked.

Neo development is now moving forward at pace and we’re having a huge amount of fun designing the levels and graphics.

 

 

Defining alien attack formations in a retro shoot em up

In our last game, Thundergun, we adopted a purely randomised approach to generating the levels. That is, the alien formations were predefined prior to the game loading but their formations for completely random.

For our next game, Akari: Battlestar (working title), we’re looking to plan the action with far more precision.

Our inspiration for this game is from the early 1990’s and games like Raiden.

Raiden was a tough game. Very tough. Our game will hopefully be a little more forgiving in the style of what were once referred to as manic shootersDo Don Pachi epitomised this style in which you pitched your fighter against hordes of formation-based adversaries who sprayed bombs (with some elegance) around the screen. Under normal circumstances avoiding the bombs would be nigh on impossible. But this genre used much tighter collision detection; often using just a single pixel in the centre of the player’s ship for collision reference.

We’ve already adopted a similar approach.

But it’s the fighter formations we’re keen to establish up front by way of an in-house level design system. The placement of aliens, cannons, collectables, mini bosses, tanks; you name it, will be handled by this system. Each entity will have all attributes defined and the resulting output stored in a JSON format to be read by the game.

The attack formations for Thundergun were based largely on Capcom’s 1943.

Fighters swooped in, curled around and then flew off. If you took the entire formation down you were presented with a bonus item.

For Akari we want to have a lot more variation.

Fighters will adopt one of several attack formations.
e.g.

  • Drift down from the top of the screen, pause, fire, drift off to the side
  • Drift in from the side, fire bursts, drift off to the side
  • (Tanks) trundle in from the side and follow a set path
  • Squadron formations from the bottom of the screen that fly off screen and return in slow formation

For Thundergun we introduced the concept of a game progress ticker. In code this was defined as part of the global namespace g{} and referred to as g.progress

g.progress bumps with every tick of the game’s main loop. This is consistent and in tune with everything else that the game loop handles (movement, animation, collision etc) so it’s a good base for defining the introduction of alien formations.

As g.progress counts its way through to several thousands for each level it passes what we refer to as waypoints. As each waypoint is triggered a new randomly but predefined alien formation is spawned.

The difference with Akari is that there will be no randomisation. Everything will be delivered from a level data file.

At set intervals in Thundergun the action was interspersed with a mini boss; a larger fighter that drifted into view and bullied the player. Formations continued to spawn around it.

For Akari we’ll suppress the formations and halt the bumping of g.progress while the mini boss action plays out.

With the mechanics for the mini boss developed we have pretty much 90% of the code written to handle a proper end-of-level boss. The main difference will be in defining the scale of the boss and any sub-elements such as wing-mounted cannons.

Level structuring isn’t a new thing for us. We’ve employed it for our platform games and the C64 style shooter Crossfire.

Hopefully we can get a demo up and running in the near future. Exciting times in arcade game development!

Further adventures in marketing arcade games on the App Store

It’s always easier to make decisions when you’re armed with data.
This morning we pulled down some stats from Apple’s reporting site to pore over the numbers.
(We don’t currently publish to Google Play, though that will come soon)

To Charge or Not to Charge

We released an arcade game (Chaos Grid) to the App Store two weeks ago and initially offered it for free.
In a short space of time we’d had just over 800 installs. 95% of those came from Japan.

It’s easy to assume that this is an indication that the game would be successful if we charged for it.
So we did and opted for the lowest tier of pricing – 99p.

7 days later and we’ve had an additional 12 installs.
Less Apple’s cut that comes in at $8.06 (£6.40)

Our assumption was wrong.
There’s work to be done before we  can consider charging for the game.

There are other ways to monetise the game.
In-app Purchasing and advertising being the obvious choices. But we reject these as they aren’t true to our ‘promise’ to the customer.

We’re doing this to ‘relive the thrills of the video game arcade’.
It’s our ‘Why?’, if you like.

So we gave it about 4 seconds worth of thought and switched it back to free of charge.
Overnight the installs are back into double figures.

I guess it’s far better to have the game installed on numerous iPhones and iPads than sat there on the app store gathering dust.
A number of things happen when the game is installed:

  • It gets played
  • Our brand is all over the game’s splash screen
  • It (potentially) gets talked about and shared

But there was something else that occurred to us; the Japanese market was up for these games.
When we uploaded the game to the store we selected to have it available in every territory but we have no control over the exposure in each territory. So that came as a pleasant surprise.

Localisation and Culture

The screenshots that we provided for the game’s entry on the app store contain text. English text (above).
Words such as ‘RETRO ACTION’ and ‘ARCADE THRILLS’.
I’d guess that these ‘calls to action’ are wasted on the Japanese audience. They are probably far more interested in the screenshots than any blurb we wrap around it.
iTunes Connect (the developer’s gateway to the app store) offers the ability to provide localised content. We could go to the trouble of translating any words into multiple languages. But is it worth it? Would those words significantly influence the viewer to become a buyer?
I doubt it.

Far better to offer something more culturally relevant.
In the west we appear to use the screenshot as the key persuader in the buying process for an unknown title.
It’s a lot like picking up an X-Box game in the store and immediately flipping it over to see a screenshot of the game on the back cover.
But in Japan consumers warm to specific imagery. Anime style imagery. It’s relevant to them and makes the game feel less ‘alien’. The Japanese are proud of their culture and appear to warm to any attempts to embrace it.

Here’s a useful link that forms part of our on-going research into marketing on the app stores: https://moz.com/blog/app-store-rankings-formula-deconstructed-in-5-mad-science-experiments

Evoking retro memories with box art

We’re huge fans of the golden days of Atari. The box art was a huge inspiration and that wonderful feeling of being transported away from real life is something that we’re keen to evoke with our own games.

Take a look at this concept piece for some promotional artwork for our forthcoming arcade game Thundergun.

The art department are nerds for Atari box art and artists such as Steve Hendricks.

What do you think?

WKWebView, WebAudio and PhoneGap for iOS games

Here’s a handy little tip for anyone wanting to load files via AJAX in their PhoneGap apps that run on iOS courtesy of PhoneGap.

Our first attempts at creating games with PhoneGap were satisfactory but not brilliant. The frame rates were awful though the music and sound effects seemed to work fine. So we did a little digging and found that by default PhoneGap will use UIWebView, the default web view, on iOS.

You can change this to use the far more advanced and polished WKWebView (Web Kit Web View) which makes great use of such things as requestAnimationFrame. Something that is hopefully familiar to HTML5 game developers.
With WKWebView you also get to run against the superior JavaScript Nitro Engine which will massively increase the performance of your games.

Here’s how to implement WKWebView via your config.xml.

Add the following just beneath your <widget> declaration:

 <feature name="CDVWKWebViewEngine">
 <param name="ios-package" value="CDVWKWebViewEngine" />
 </feature>
 <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />

 

But we found that our audio now failed to load.

We use AJAX (XMLHttpRequest) to load our audio. To date it’s worked a treat. The reason we use it is because it’s a neat way to asynchronously load and capture the onload event and act upon it as we configure each audio file (volume, for example).

This works using a relative path.

Here’s some code:

 var request = new XMLHttpRequest();
 var url = "sfx/" + o.soundname + "." + AUDIOFORMAT;
 request.open('GET', url, true);
 request.responseType = 'arraybuffer';

You can see that our mp3 files are sat in a sub-directory called /sfx.

But WKWebView doesn’t like this. It wants its AJAX calls to be fully qualified from the http://

The change to the config.xml file is simple.

Add the following amongst your plugin declarations:

<plugin name="cordova-plugin-wkwebview-engine-localhost" spec="https://github.com/apache/cordova-plugins.git#wkwebview-engine-localhost" />

And change your content definition from

<content src="index.html" />

to

<content src="http://localhost" />

Hope that helps somebody!