One of the most classic types of games is a space invader style game. Cow Defense System is just that: aliens are coming down from the top of the screen to kidnap your livestock.

The game uses a lot of components which can be re-used for other games. The engine also allows modifications for different games in the same genre.

Model View Controller

There’s a clear distinction between the visual representation and the data of the game. The Game class is the core of the game logic. This is the place where all models and views are hooked up. The WorldView contains all views of the game mainly in the form of ViewPool instances.

View Pools

This game uses the ViewPool system: all views necessary are created at the start of the game in a hidden state and are obtained when something has to be displayed.

There are a couple of reasons for using view pools. The first is that we try to create as little garbage as possible. The second might be a little less obvious. When running the game on a mobile device the views are actually implemented in native code. When a view is created it is registered in a data structure. This takes some time when it’s done a lot. To make everything run as smoothly as possible the view pool does this once and then keeps re-using the data which was initially created.

There are a number of view pools used and they are structured in layers.

Model Pools

This game also uses model pools. A model pool is a class which contains a list of models. The model pool calls the tick function on the active part of the list. In a shooter type game a lot of items have a short lifetime. For example, bullets or enemies are on screen only a limited amount of time. To prevent a lot of creating and destroying of objects the objects are grouped into pools which allows the objects to be recycled. The code in this library also handles the linking and unlinking of views and models.

The type value

A model pool can contain different types of models. The facilitate this, the ModelPool constructor takes an optional type parameter.

So why use a type when the type is already implicitly provided in the ctor (constructor) parameter?

Let’s create a class which we could put in a model pool:

And another one which we base on the first one:

Ok, we have two models. Let’s subclass the ModelPool. In this subclass the _allocItem function will be called:

Well that looks fine but after running it a couple of times weird stuff is happening. What’s going on? Unfortunately it turns out that using the instanceof keyword to figure out if an item can be used gives us correct values which are wrong…!?

The following code shows how the model pool breaks when using instanceof instead of a type value:

test2 is an instance of Test1 but we only want instances of Test1 object which are not subclassed!

The model pool introduces a public property type to all models in the pool which allows the model to identify which type of model it is.

Optimizations

After making sure the game produces as little garbage as possible – through the use of ViewPool and ModelPool- there is another step taken which makes this game perform very well: the structure of the layers and sprite sheets.

How does the DevKit render stuff?

All visible instances of ImageView are stored in a queue. The only thing which influences the order of the items in the queue is the zIndex.

When the scene is rendered the application executes a number of render calls. To get the best performance the number of render calls should be as few as possible.

How can we reduce the number of render calls? For a series of ImageViews to be grouped into a single render call, these properties have to be the same:

• Sprite sheet
• Opacity
• Filter

If all ImageView instances are siblings and the listed properties are the same then they can be rendered with a single render call.

Events

Whenever a touch event is handled the view tree is traversed to find the actual view in which the coordinates of the touch fall. Usually there are a lot of views which are completely irrelevant for touch events, for example the views in a particle system.

To make sure that the system does not do a lot of redundant checking there’s a distinction made between display views and input views. The display views have the value blockEvents as true passed to the constructor. These views and all their children will not be checked when a touch event occurs.

The Engine

The Cow Defense demo game uses a number of classes which are based on the principles described above. But when you want to build your own game like this it’s not very convenient to start with a completely implemented game.

The shooter library on which this code is based contains a sample Application.js file. This file is a barebones engine demonstrating views dropping, a player which can be moved, projectiles and basic collision detection, all this in less than 250 lines of code!

All classes in the shooter library are documented. The documentation can be found here:

• Model classes
• View classes
• ParticleSystem class

Since pretty much any game needs some kind of menu system this project will feature just that: a generic menu system which you can style as you please.

The code of this menu system can be found here: https://github.com/gameclosure/menus. We’ve made this demo part of the default installation of the DevKit. If you’ve already installed the DevKit then you can just run ./install.sh again to update and get the new application.

All dialogs in this demo use the same images in a consistent way which makes it easy to customize them. There are also settings to select the font family, stroke color and stroke style. Another option which you can change is the way the dialogs appear like sliding and fading in and out.

There’s a single file in this package which controls the default behaviour and style for all views. That file is called menuConstants and has the option to accept a custom configuration through a set method.

This demo provides the most common menus which keep popping up again and again. The first one is a basic menu with a number of items. Usually this type of menu is used as a main menu.

The background of this demo is a blue gradient which is just there to add some contrast when you use these menus. You can choose any background you like or just show the menu on top of the game screen.

Styling

The paths to the resources used by the menu system are defined in the file menus/constants/menuConstants.js. The default location for all graphics is resources/images/ui/. It is recomended that you use the same location. However, if you do want to change the paths you can use the menuConstants.set method to change the configuration of the menus which includes the image locations.

MenuView: A basic item menu

First let’s import the MenuView. Note that the demoMenu resources have been copied into this local demo project.

After importing this class we can create an instance. This is usually done in the initUI function in Application.js.

This MenuView instance has a show function that causes the menu to appear. In this case, it uses the default slide transition.

Calling the show function results in the following screen:

When the first option in the menu is clicked, the onOption function in the Application is called.

When the second option is clicked, the instance emits a Second event which can be used as follows:

One advantage of the event emission approach is that a single event can trigger multiple functions.

TextDialogView: A dialog view

The TextDialogView satisfies another common use case: the alert or confirm dialog. The following example shows how to use the TextDialogView class as an alert dialog.

First let’s import the class:

After importing the class we can create an instance:

One of the constructor parameters is a button array which must contain one or more button definitions. The modal option is used to darken the background behind the dialog.

When the show method on the instance is called the dialog appears which should look like this:

DocumentView: A dialog to display simple documents.

To display one or more pages of text you can use the DocumentView. The JSON format allows you to select the color, size and font family of the font. Other options to create nice looking pages are: images, background colors and background images.

A demo game which we are working on will use this window to show information about pickup items:

The style options are basic but sufficient to create great looking dialogs. You can read the api documentation for more information on how to use this dialog.

TutorialView: A tutorial dialog view

You can use the TutorialView to teach users about your game. This is a dialog which contains an animation. Usually this dialog is only shown once for each option in the game. After showing it, simply set a value in localStorage to indicate that it should not be shown again.

To create a tutorial dialog, first import the class:

Then create an instance:

The animation displayed on the dialog is implemented using the SpriteView class.

When show is called the dialog should look like this:

Building your own dialogs

The easiest way to build your own dialog is to subclass the TextDialogView and clear the text option. The TextDialogView has a content area which can be used for custom content.

Since the TextDialogView can show buttons these have to be passed to the constructor.

After calling the show method on this menu a dialog like this screenshot should appear:

The GC DevKit provides a solid, performant foundation for many different types of games. You can already build cross-platform games of any genre incredibly quickly using DevKit. At Game Closure, we regularly build new games in a day or less.

We wanted to see if we could take it even further: What if we narrowed our constraints a bit and built a framework on top of DevKit, designed for a specific game genre? Could we reduce the cycle from idea to implementation even more, so that developers can not only prototype a game in the span of a few hours, but build a fully-polished, shippable game in an afternoon?

We wanted to choose a genre that includes a couple interesting technical challenges for game developers. For this first experiment, we decided to build a framework for side-scrolling games. This is a classic genre, filled with greats like the original Mario and Sonic franchises, as well as modern variants like Doodle Jump, Wind Runner, and Tiny Wings. I can’t begin to count the number of hours I spent ignoring my coworkers and responsibilities because I was engrossed in Tiny Wings.

How can we abstract away some of the hard work in building those games? All of them have a few constraints in common:

• The game scrolls in one direction, always forward.
• They employ parallax scrolling to provide a sense of depth.
• The level is potentially infinitely long, computed on the fly.
• They have a simple physics engine.

Let’s build a framework that makes it easy to build games with those constraints. We’ll build a platform game to test the framework too.

Infinite Levels

To build a game with a never-ending level, we can’t just compute the level at the beginning. We’ll need to generate it as we go.

For now, assume we have a LevelLayer class of some sort which we expect developers to subclass.

At the very beginning of the level, we need to generate a chunk at least as long as the screen width. But as the level scrolls forward, we don’t want to build new sections of the level at every frame; instead, let’s generate the level in chunks.

Since we’re building a framework, we should think about this problem from the viewpoint of the framework. If we need data about the game, we need to ask the game developer. We could ask the developer to fill out a specific area of the level, perhaps one screen width at a time:

That seems reasonable at first glance, but what happens if we’re building a platform game that has platforms wider than one screen? A fixed-width chunk wouldn’t be flexible enough.

Instead, let’s just give the game developer the x coordinate where we need to start populating the level, and we’ll keep asking them for more data if they don’t provide enough. We need to know how far ahead they’ve prepopulated the level, so let’s have them return the width of the chunk they populated:

Cool! Now we have a generic way for the developer to specify chunks of the level as we scroll forward. As the screen scrolls forward, we’ll just call their populate() function and prepopulate enough level to ensure the screen is always filled.

But wait, we’re not quite done! As the screen scrolls forward, old level data falls off the left of the screen. If we leave it there, we’ll eventually run out of memory. One of the constraints we chose when selecting this genre was that we only scroll forward, so we know we don’t need the old level data once it leaves the screen. We don’t want the game developer to have to manually remove old level chunks, so let’s make that part of our framework too:

Performance Optimization

While we have avoided running out of memory, we need to address a couple common causes of performance problems in scrolling games.

If we’re going to generate the level on the fly, the populate() function needs to run quickly, otherwise we’ll notice hiccups in our game every time we generate a new chunk of a level. Additionally, when we allocate and destroy new views, they need to be garbage collected by the JavaScript runtime, which can cause noticeable lag spikes at arbitrary times. To write a performant game, we need to avoid allocating new memory whenever possible, so that we can reduce the need for garbage collection.

The GC DevKit provides a ui.ViewPool class, which we use in our games to preallocate a pool of views. When we need a new view, we obtain one from the pool; when we’re done with it, we release it. This pattern comes up often in game development, but it’s especially important in scrolling games where we’re constantly generating new views.

It needs to be drop-dead simple and intuitive for developers to use a ViewPool, and it should be as unobtrusive as possible. In our framework, the only place developers will be creating new views is within the LevelLayer.populate() function. They already create views like so:

Assuming we have a ViewPool in our LevelLayer, let’s create a function on the LevelLayer to make it easy to fetch a pooled view. We have a few requirements, though: we need to be able to instantiate any class for the view pool (like an ImageView or EnemyView), and we may want to be able to generate different types of the same object (like an ImageView representing a coin, and another ImageView representing a heart). A ui.ViewPool can only hold one class of object. In other words, our level may need several different pools, depending on the class and group of the given object.

Putting that all together:

If you’re confused, the ui.ViewPool docs may help.

Now we obtain our views from a pool, but we need to release them. Otherwise we’re right back where we started, running out of memory and all that.

Again, views might disappear for a couple reasons:

• The developer removed them from the screen
• The view fell off the left of the screen

Fortunately, the DevKit provides an event that we can handle to detect when a view gets removed from the screen, and we can release the view there:

Now, the developer simply needs to use obtainView(ViewClass) rather than new ViewClass(). Views automatically come from a pool, and they are released back into the pool when the view gets removed from the screen. This avoids excess garbage collection and makes the game perform more smoothly.

Parallax Scrolling

All sorts of games use parallax scrolling to provide a sense of depth. Fortunately, most of the hard work has already been included in our framework through the view recycling code above. A parallax game is really just a bunch of infinitely-scrolling views stacked on top of each other, with each one scrolling proportionally to the others. Layers designed to seem far away will scroll more slowly; layers close to the camera will scroll faster.

At this point, it’s just a bit of math and API design to end up with something like this:

Using that view becomes pretty simple:

And with that, we have a view that supports many layers of an infinitely-scrolling level!

Physics

The DevKit doesn’t yet ship with a dedicated physics engine, but we’ve created games using JavaScript ports of Box2D. In this case, though, Box2D would be overkill. We just need some simple collision detection and movement. Something simple and flexible. Just enough physics to make game development easy without burdening the developer with the harsh mechanics of physical reality.

I won’t go into great detail about the implementation of the physics engine I built for this framework (the source is well-commented), but I’ll describe its API. I built this engine in one day, so if you think you can contribute improvements, let’s join forces!

To be intuitive, our physics needs to hook directly into the existing view system. So we should be able to either subclass a Physics component, or add physics to an existing view like a mixin. This framework allows both options, for convenience.

In a nutshell:

DevKit’s ui.View contains a number of useful properties, but as I was developing this framework, I found that resulting game code was clearer with a few helper accessors: .getBottom(), .getRight(), .getCenter(), and the like. In other words, any view that has Physics added automatically becomes enriched with these methods.

Bonus Goodies

There are a couple other pain points I found while developing this test game:

Displaying a Score Efficiently

The DevKit’s TextView isn’t optimal for displaying a high score counter. Internally, it buffers strings of text for display, and a score counter changes constantly, perhaps every frame. Additionally, most score counters display the score in a monospace font for a cleaner look, and most fonts are variable-width.

I’ve included a ScoreView class that we’ve used internally, which takes in a set of bitmaps representing individual digits in a score. At runtime, ScoreView will render a bitmap of each character, a fixed-width apart, and cache each digit individually. This allows the engine to render a new score every frame without degrading performance. Other than performance, a ScoreView is used just like a regular TextView: call .setText(score).

Aspect Ratios

Every day, a new Android phone appears with a different screen resolution. By default, DevKit renders your game in a one-to-one mapping, with your main view sized equal to the screen resolution. In most games, you don’t want that kind of pixel-precision: you want to be able to write your game with a specific size in mind, and have it automatically scale to fit the screen size. Included in the platformer.util module in this framework is a function called scaleRootView(app, width, height); it resizes your main view to fit within the screen, letterboxing it if necessary. Then you can write your game layout logic with a fixed size in mind, without making changes for different screen sizes.

Results & Demo

Working in JavaScript, and with the DevKit, game development is already incredibly quick. I wrote both this framework and the sample game in only a couple days. Now that we’ve taken the time to abstract away some of the core concepts from a platformer-style game, we can all create a game like this even more quickly, with less code.

This is nothing magic. Looking at the platformer framework, you’ll see that it isn’t a massive, all-encompassing project: It’s pretty simple and easy to follow. But it’s powerful enough that it makes developing platform games incredibly easy. Designing a framework is always a balancing act: If you abstract away too much, you end up with an inflexible monstrosity that’s hard to understand and maintain. But if you abstract away too little, you have a lot of extra code for little gain.

Take a look at this framework, fork it on GitHub, and see if you can improve it.

There’s been a lot of talk about building real-time multiplayer games on the DevKit. This makes sense, because everyone knows that multiplayer games are way more fun. Even these kids from the 50s have figured it out:

Multiplayer games have a natural edge over single player games. Would you rather play solitaire or poker? It’s a matter of taste, but your buddies will never ask you to play solitaire with them. All other things being equal, we tend to do what our friends are doing. Thanks to peer pressure, multiplayer games have the potential to spread faster and retain better than single player games.

They’re also a lot of fun to make. Here’s an example of a simple client for a fast-paced real-time multiplayer word game.

The Original

Wordrace is an extremely minimal multiplayer word game I made about five years ago. The backend is a dead-simple Python server written atop dez and rel.

Basically, you’re competing against everyone else who happens to be playing. Everyone shares a pool of seven letters. The point is to use those letters to make words. When someone makes a word, the word’s letters are replaced in the shared letter pool, which is a little jarring. So if you make smaller words, you mix up the shared letter pool more often, thus screwing with your opponents. On the other hand, bigger words get you more points. What a dilemma! Does any of this make sense? Play for a second to get the idea. Here’s what the original browser version looks like:

The protocol is a little silly. The server sends down 2-element arrays that look like this: [MESSAGE_TYPE, MESSAGE_DATA]. MESSAGE_TYPE is a string and MESSAGE_DATA varies, depending on MESSAGE_TYPE.

The client sends up frames delimited by :. For example, when a player tries to submit the word dog, the client sends dog: to the server. Besides sending a word, the user can also reset the current letters (if they’re bad) by sending !.

This reminds me of stories I’ve heard about Mexican sports writers interviewing Brazilian soccer players, with one side speaking Spanish and the other side speaking Portuguese, and both sides more or less understanding each other. Or this cat talking to a robot.

That’s pretty much it. There’s a bit more built into the protocol for scoring, but we’re about to implement a client so minimal that it mostly ignores scores, which would take us too far off topic, anyway, unlike cat videos.

So let’s make a mobile version of this game. First let’s slap together some views.

How It Looks

Make a fresh game with basil init and open up your shiny new Application.js. Delete launchUI and empty out initUI. Your imports at the top should look like this:

Now to build our game screen. Here’s your new initUI:

This creates a start button and a game screen with a row of letters at the top, a TextView for displaying game events in the middle, and a row of buttons at the bottom.

What It Does

So now we’ve got a bunch of views bound to nonexistent input handlers. Here are the handlers:

These handlers invoke a couple utility functions, this.log and this.send. They look like this:

The last handler, this.connect, binds several network events to callbacks. Here are those callbacks:

And here are the individual read events triggered by this.onRead:

And it works!

Woohoo!

The Whole Shebang

That’s the whole game. Done.

The project lives at this github repo. If you feel so inclined, install this APK on your phone and play against your friends and others on the site. Trust me, it’s somewhat fun.

The Point

What I’m trying to get across here is that multiplayer games aren’t rocket science. All you have to do is come up with a protocol — even a dumb, asymmetrical protocol — and stick to it. The vast majority of your code doesn’t even have to know about it.

Upstream

No one on the client side has any idea what upstream communication looks like, except for one magical function. Check out this.send:

There it is: this.sock.send(data + “:”);. That’s all it takes to define a colon-delimited upstream protocol. Here’s the matching line in the Python server code:

DELIM is a colon, and self.__parse_input is the input handler. Thus, the server knows that incoming frames are separated by colons. Simple, right?

Downstream

Jumping back to our Application.js, behold this.connect:

Every DevKit socket comes with a reader. It has three read modes:

• stream: pass all data along to onRead handler (default)
• json: buffer until you see a JSON object and forward to onRead handler
• delimiter: read until you see some string and forward to onRead handler

The reader essentially eats a stream of characters and expels frames consistent with the read mode. It sits between the native socket’s read stream and the JavaScript socket’s onRead callback. By default, it forwards every new chunk of data immediately. This is called stream mode.

Here, we want json mode. Thanks to reader.js, a mere this.sock.reader.setMode(‘json’); clearly instructs the client-side socket to deliver you JSON objects as they arrive. All the server needs to do is write stringified JSON.

Final Words

Our socket works great on phones, but not at all in the browser, because browsers and real-deal sockets don’t mix. If this makes you sad, simply use a WebSocket in the browser and a real socket on the phone. You can either write a server that speaks WebSocket and regular stream-speak, or point your browser version at a WebSocket proxy (examples: 1, 2).

If you don’t feel like doing that, build your game using the GC Test App (Android, iOS), which is pretty much just as fast as developing in the browser. Now go forth and craft the finest multiplayer games the world has ever seen!

I recently discovered a sort of unbelievable game development platform by Scirra called Construct 2. Using this tool you can basically create an entire game without any programming whatsoever. It’s pretty darn neat.

Space Blaster is one of their demo games. You can find it on the Chrome Web Store, as well as Facebook. After playing a few rounds, I wanted to try it out on my Nexus 4. I downloaded Construct 2, opened up Space Blaster (which ships with Construct 2 as an example), and exported an HTML5 app. It looked like this:

I ran:

This is where my troubles began.

Mobile Browsers are for Reading Email

I opened Space Blaster in a browser on my phone and almost immediately started crying. The first thing I noticed was how laggy it was. The frame rate was so low that my bullets were passing right through enemy ships. The second thing I noticed was the absence of sound. Then it crashed.

This bummed me out a little bit because the actual game is super fun. It’s got great sound effects, and the animations are very impressive when they actually play smoothly. Then I got a little mad, because I should know better. Playing a game in a modern mobile browser is like reading the news on a flip phone or sending an email with a beeper.

Any of these can be attempted, but why? The basic reason, I suppose, is that folks insist on doing everything on the go, which means working with the materials at hand, no matter how terrible they are. I find myself in a similar situation, the bearer of an HTML5 canvas game that I yearn to play on my phone. Luckily, I work at a company that makes a native-accelerated OpenGL canvas for running HTML5 games on mobile.

Why Would Anyone Do This?

Let’s step back for a second and really appreciate what Construct 2 has to offer. It enables someone with zero coding experience to create a complete HTML5 game. Is your mind blown yet? It really should be. Think of all the sweet game ideas that at this very moment are bouncing around in people’s heads, and how many of those people aren’t programmers. Five years ago, these ideas would never see the light of day. Nowadays, thanks to frameworks like Construct 2, they really can become games. That’s truly awesome.

So where does Game Closure fit in? It’s quite simple. Essentially, lots of people (including Construct 2 users) are creating HTML5 games that run awesomely in real browsers and terribly in mobile browsers. We’ve already solved this problem with a custom native implementation of the HTML5 canvas. If we can leverage our technology to help bridge this gap, we can bring these games to a much wider audience. If we can streamline the process, folks will be able to make HTML5 games using any framework out there and deploy them to smart phones with ease. This degree of compatibility, after all, is the point of HTML5 and open standards in general.

Step one is porting Space Blaster.

Getting Something on the Screen

Basic Setup

I made a fresh game with basil in devkit/projects, and pulled in the JavaScript and images I figured we’d need from Space Blaster:

My src folder now contained 3 files: the Application.js generated by basil init; c2runtime.js, where the Space Blaster game lived; and jquery-1.7.1.min.js, which Space Blaster seemed to require (and which I renamed to jq.js for ease of importing). I opened up Application.js and manifest.json and started tinkering.

Step one was to get something running in the browser. First I changed the game’s orientation from landscape to portrait. This simply entailed replacing the string landscape with portrait in the supportedOrientations array in manifest.json. Easy peasy.

Next I turned to Application.js, which looked like this:

Great. I deleted initUI and replaced the TextView import at the top with a couple imports of our own:

At this point it ran with no errors and transitioned from a GC splash to a black screen. What fun! Now we just need the actual game.

Digging, Lying, and Cheating

So how do you start this thing? A quick scan of the index.html generated by Construct 2 reveals the magic line to get the show on the road:

A search for this function in c2runtime.js takes us to this code:

Seems straightforward enough. They’ve got this cr.createRuntime thing, and they attach it to the window object as cr_createRuntime. Fantastic. The only problem is that they expect to pull a canvas out of the DOM using an ID. There’s no DOM on the phone, so this approach won’t work. But wait! There’s that other function, createDCRuntime (attached to window as cr_createDCRuntime), which just takes a width and height. Worth a shot! I added

to my previously-empty launchUI, leaving width and height undefined because the constructor resizes the canvas to the max dimensions available, which is what we want. I ran it again and immediately got an error:

Fair enough. Construct 2 barfed while trying to route input events to their handlers. You guys didn’t expect this to work right off the bat, did you? Anyhow, it seemed that the undefined variable was being set a few lines up, in this code chunk:

So what’s this.runtime.isDirectCanvas? It gets set in the Runtime constructor, like so:

And what’s canvas? That’s just the object that gets passed in by cr_createDCRuntime (see above), and all it has on it are width, height, and dc (which equals true). So since we’re using cr_createDCRuntime, isDirectCanvas is definitely true, which means that elem and elem2 get set to window["Canvas"], which, according to the Chrome debugger, isn’t anything. So let’s make it something, and while we’re at it we can map our input events to Construct 2′s handlers.

Construct 2 will now add its event listeners directly to what it thinks is a “direct canvas” (which we know to be our shim object). Our shim in turn will create input callbacks that modify our input events (Construct 2 expects a “changedTouches” array) and pass them along to Construct 2′s handlers. Simple dimple!

Run it again and we get a different error, which means we’re making progress. This time, AppMobi is not defined, which makes sense because we’re not AppMobi. The error happens here:

Construct 2 is trying to get a canvas from AppMobi. Time to lie:

We’ve given them our canvas instead. The guilt will fade with time.

Refresh for the next error. Now that Space Blaster has successfully gotten its hooks into our Context2D, it expects to find a function called present. Here’s where the game tries to call it:

At this point I’m pretty happy that we’ve made it to the draw function. This just might work! So what’s present? Turns out it’s an AppMobi/DirectCanvas thing that gets called every tick to trigger a render. Our canvas knows how to render without this. Let’s cheat!

Great! Refresh, next error here:

Oh man, this direct canvas is so demanding! Let’s just cheat again:

This is fun.

I Still Can’t See Anything

Ok, now we’re getting an error in ctx.drawImage. This is because we haven’t told Construct 2 where the graphics are hiding. Let’s do it!

As it turns out, the whole game is defined in a JSON object at the bottom of c2runtime.js. In this case, the object is over ten thousand lines long. Anywho, the most recent error indicates that it’s trying to find an image at images/background3-default-000.jpg. The DevKit serves image assets in resources/images, so this is an easy fix. We just have to override cr.getProjectModel, which generates the game definition object. I added this to launchUI:

That jsio line at the top is some black magic for grabbing a local variable out of a JavaScript file. Since we’re importing c2runtime here, we can remove the import from the top of our Application.js. The rest basically remaps Space Blaster’s image sources to their new home in resources/images. When I run it again I get the same error:

This basically means it still can’t find the image it’s looking for. Let’s tell the DevKit not to build spritesheets for these assets, as they’ve already been sprited. Create a new file in resources/images/ called metadata.json, and paste in this:

And it works!

I Still Can’t Hear Anything

Right, the original had sound, and lots of it. Let’s grab the audio assets we need.

Now we just need the game to look in the proper place. We’ll solve this the same way we handled image asset paths, by overwriting the project model.

Refresh, and we’ve got sound!

Wait, What About the Phone?

Remember a million years ago when the whole point of this was to run Space Blaster on a phone? Let’s give it a shot. Plug an android phone into your computer and start typing in a terminal:

Great!

A Few More Fibs

You just installed the game on your phone. If you try to run it, you’ll get a gross jQuery error:

Man, I’ve heard enough out of you, jQuery. You worked fine in the browser, but now you expect a full DOM on the phone, and that’s just not going to happen. What exactly is this game doing with jQuery? I removed the jq import at the top of Application.js to find out.

It turns out that everything runs fine without jQuery, for the most part. The only thing missing is window size detection, which only happens if jQuery is present:

So let’s fake it. Add this to launchUI:

Looks good in the browser. After rebuilding and reinstalling on the phone, you’ll see this:

Yup, there’s no DOM, so there’s no document.getElementById. Time for more lies!

Don’t worry, no one ever has to know. Rebuild, reinstall, and see the next error:

Looks like we’ve got more shimming to do. Update window.AppMobi to look like this:

That’ll do it. Our loadSound doesn’t actually need to do anything, because our AudioManager can load everything we need up front. You’ll see.

But Where’s the Game?

Rebuild, reinstall, and run. The first and last thing you’ll notice after the GC splash is a black screen. This is because alwaysRepaint defaults to true on the GC engine. When alwaysRepaint is true, the engine draws every tick. Since we’re not doing any of the drawing, this just clears the canvas every tick, obliterating whatever Space Blaster just tried to draw. Let’s turn that off:

Next thing you know you’re looking at the Space Blaster main menu on your phone. Yay! Before you pop the champaign, tap for the next error.

Creating createPattern

The problem:

This example demonstrates the basic usage of createPattern:

It’s basically an image tiler with a funny API. Very doable. Here’s our 2D Context’s implementation of fillRect:

Great, all we need is a createPattern that returns some kind of object, and a this.fillStyle test of some sort in fillRect, and we’re good to go. This createPattern should do the trick:

Now let’s just handle this case in fillRect:

That’s all it takes! Now the DevKit supports createPattern invocations of various kinds: ‘repeat’, ‘repeat-x’, ‘repeat-y’, and the pointless ‘no-repeat’. Here’s a before and after. The createPattern on the left returns the string “red”. The createPattern on the right returns the object discussed above. Just look at all those missiles! Nice work, createPattern.

And now we’ve got a game! Wooo! Unfortunately, our game has the following problems:

• the screen goes black when you touch it
• there’s no sound
• some of the images are having transparency issues

These are hard core dealbreakers. Luckily, they’re easy to fix.

Black Screen on Touch?

This is due to another flag on the GC engine. Remember alwaysRepaint? There’s another engine flag that defaults to true called repaintOnEvent. The idea with this flag is that in cases when you’re not repainting every tick (alwaysRepaint == false), you’ll probably want to repaint when the user taps the screen (which generally results in some visual difference). Since we’re not doing any of the drawing, this behavior will simply result in a black screen whenever the user taps. So let’s turn it off. Add

to launchUI, and you’re in business! Now take a break to play a few rounds. Yes, this is JavaScript, and yes, it actually works. Let that sink in before moving on to the next issue.

Sound?

Ok, so we copied over the Space Blaster audio assets to our new project. They’re running fine in the browser, but we’ll have to roll our own sound support to get a peep out of the phone. Luckily, the DevKit already did this for us.

We’ve got two copies of each sound: an m4a, which is played in the browser; and an ogg, which is played on the phone. We want file names without any spaces or weird punctuation, because this simplifies our AudioManager configuration. So I made a simple Python script that looks like this:

And ran it like this:

Great! Now we can just drop in our AudioManager, which looks like this:

Remember when we shimmed loadSound with a function that didn’t do anything? That’s ok because of the preload: true here, which loads up all the sound effects for us. Also, I flagged the music files (epicarpg and mattoglseby___3) with background: true. This guarantees two things:

• these songs won’t preload (this would take up memory and time, and is unnecessary, as music files are streamed)
• these songs won’t play at the same time (playing one stops the other)

Don’t forget to import AudioManager at the top of Application.js:

Cool. Now let’s hook up our AudioManager to the AppMobi shim:

And it’s a game! With sound! Woohoo!

What’s with the Black Boxes?

Here’s a funny one. As it turns out, some of Space Blaster’s graphic assets use regular transparency, and others just have a black background. Silly game developers! Here are two explosion spritesheets from the game:

exlosion1-sheet0.png, exlosion2-sheet0.png:

See what I mean? The quickest fix here is an ImageMagick batch conversion, a la this script:

It finds all the graphics with names that start with “explosion1″, “explosion3″, and “playerthrust” (the other images use regular transparency), and uses convert (ImageMagick‘s command-line utility) to replace black with transparency. Run it:

Great!

Spit and Polish

What’s left?

Icon

I used the GIMP to steal this image from one of the enemy spritesheets and resize as necessary:

Setting the icon in manifest.json is easy:

Splash Screen

This game asset seems sufficiently spaceish:

We can make this the splash screen with a few simple lines in manifest.json:

Retrospective

We did it!

What We Accomplished

Here’s the Application.js we ended up with:

And here’s the APK we ended up with: Space Blaster APK.

The project lives at this github repo. As it stands, you should be able to run any Construct 2 game on a phone by simply:

• 1) exporting your Construct 2 game as an HTML5 app
• 2) cloning this github repo
• 3) replacing src/c2runtime.js with the c2runtime.js generated by Construct 2 for your game
• 4) replacing everything in resources/images/ with the image assets from your game
• 5) replacing everything in resources/media/ with the audio assets from your game
  • update the AudioManager in Application.js accordingly
• 6) running fixAudio.py and/or fixImages.py if necessary
  • if you have to run fixImages.py, replace the target prefix array on line 12 with whatever prefixes correspond to images with a black background that should actually be transparent

I know that’s six whole steps. I want to simplify this process and probably turn this into some sort of plugin. I’ll keep you guys posted.

Why It Matters

To put this in perspective, consider the general case of porting a game from one platform to another. In fact, look at what this guy has to say about it:

You don’t need to be a 1970s stand-up comedian to know that there’s a large lexicon of monosyllabic, four-letter words for describing something you don’t like – but only PC gamers use the word “port” with such a fervent degree of repulsion.

Basically, he hates it, and so does everyone else, because it’s hard and it usually involves a rewrite. Now, we just took a game that only runs in a desktop browser, wrote about 100 lines of JavaScript, and came out the other end with a game that runs smoothly on Android and iOS. Did we rewrite the entire thing in Java and Objective-C? Did we hire a team of developers and set aside months of dev time? No dude, not even close. It took one developer a couple days to figure this one out, and the next Construct 2 port will take a matter of minutes.

The big takeaway here is that when we use open standards, we get to pool resources. I didn’t write Space Blaster, and Scirra didn’t write the DevKit, but they play nice together because we both bought in to the “HTML5″ idea. And so have lots of other game engines. This means that you should continue to develop your HTML5 games using any framework that tickles your fancy, because when the time comes, you can easily deploy to mobile using our native canvas. Isn’t that great? I think so.