Can you ever have too many games? We don’t think so. Check out what we’ve been up to recently. Hint: there are a lot of games.

For starters, we’ve got some technical talk about running multiple games on the same page. Then we’ll talk about GameDash2D and how we made a runaway hit in 2 days with KiwiJS, GameFroot, and a little help from Poland.

Running Multiple KiwiJS Games

User jdrorrer over on GitHub asked about garbage collection on entire games. We took a look and came up with some advice on how to run multiple games at once.

Why use multiple games? Well, sometimes you don’t need an entire screen full of moving graphics. Sometimes you might not even want a “game” as we know it. You can use KiwiJS to add programmatic detail to a website, like an animated helper in a corner, or glimpses through a window into a busy world behind your page. Or perhaps you only want the game to pop up at certain points, and otherwise use other HTML5 technologies better suited to the current task.

In these cases, it’s not a good idea to make a single huge game canvas and spread it across the page, or keep a game running when it’s not needed. That’s a good way to bring a browser crashing to a halt. If you need several little regions, make several little games. If you need a game to run only on demand, create it when needed, then destroy it to free up system resources.

We’ll discuss some things to bear in mind when using KiwiJS games in this way.

Best Practice

We recommend that you use an iframe to contain each game. With a little DOM manipulation, you can add and remove iframes quickly and reliably.

This is the technique that we use on this very website.

Pitfalls

You may run into some dangers if you try to use multiple games at once. Here’s what to look out for.

First and foremost, browsers can’t provide a large number of contexts per document. We use an audio context and a graphics context per game. There is a limit on each type – in the case of our tests, it was 6.

Fortunately, if you put each game inside an iframe, it has its own document and never has to share contexts. We recommend that you always keep multiple games partitioned in their own iframes.

Second, don’t reuse states between games. You might find this happening if you’re creating, abandoning, and recreating a game using the same states. We don’t support the reuse of states in this way, because KiwiJS is set up to create and run a single game instance. States and filestores contain references to a single game. If they are then fed into a second game, they’ll try to access data on both games, and very likely crash the game immediately.

You should always treat different games as different games, whether they are separated in space or in time. Feel free to pass information between them using JavaScript, but we recommend that you keep all your actual game objects safe in their own little code area.

GameDash2D

Did you know that KiwiJS has a sister project called Gamefroot? It’s a fast, easy, and fun way to create and publish games. Using the Gamefroot site, you can lay out whole levels, create code with drag-and-drop logic, and test your game online.

And it’s all done with KiwiJS.

When you’re done with Gamefroot, you can export your games as KiwiJS files. Gamefroot logic is powerful and corresponds closely to JavaScript, so you can start to code in Gamefroot and polish it by hand in your text editor of choice.

But don’t take our word for it. The proof of the pudding is in the eating, and the proof of the game maker is in the games.

So we sat down and made a whole bunch of games in just 2 days each. And we mean we made games – from planning to publishing on Google Play and iTunes, all within 48 hours per title. We even found time to sleep!

Check out our achievements at GameDash2D.

Favourites

Some personal favourites include:

Absolution Velocity

This is an intense game of skill and split-second timing. Move your paddle by tilting your device, and try to slam the ball past the opponent. Eagle-eyed readers will note that we made a version of Absolution Velocity last year, but we’ve rebuilt it to use new controls, support online leaderboards, and give better visual feedback. It’s a whole new experience on mobile devices.

Freeway Fury

Two players face off across the same device, struggling to pull ahead in a post-apocalyptic drag race. We love the aesthetic on this game, and it’s a blast to play. We used Gamefroot to prototype the design, and coded the rest of it in KiwiJS. It’s super useful to have an interactive, logic-powered preview system at your fingertips!

Celebrity Breakout

Pop pimples on famous people. It’s as simple – and deliciously disgusting – as that. And we’ve had over a hundred thousand downloads, mostly in Poland.

We’d like to thank Poland for putting their faith in us, and we hope you enjoy the updates we’ve made to the game after discovering its popularity. We love the ability to build and adapt games so quickly. It means we can test and share ideas rapidly, and build on those games that people just can’t stop playing!

I’ll Hold ‘Em Off

Blow away zombies. Make quips. Meet a glorious death in battle. It’s the zombie apocalypse and you’re shooting as fast as you can, reducing wave after wave of monsters to a fine green mist. How long can you hold out?

I’ll Hold ‘Em Off features a “virtual joystick” system coded entirely in Gamefroot. Touch and drag anywhere to move; tap anywhere to shoot. Gamefroot gives you deep control over input and logic, with an interface that’s simple for beginners and powerful for pros.

Working with Gamefroot and Collaboration

Gamefroot is great for prototyping, but what happens when you want to have several people building game systems at once? Two people can’t edit the same document at once.

The solution is to think with objects. When you create game code in Gamefroot, it’s done with Google Blockly. This code can be exported and imported into other projects, using buttons at the top right of the code editor interface.

We found it productive to design self-contained game logic objects in our own documents, then share the exported code and import it into the master game. For example, one person would design the input system, while another would design bullet physics.

When it comes time to combine the systems together, we take advantage of the Gamefroot messaging system – and a whiteboard in the office. Once we’ve agreed on the name of a message, we can code our systems around that interface. For example, the input and bullet systems designed above would interface when the input object broadcasts a message of “BANG”, and the bullet is coded to fire when it receives the message “BANG”.

You can even call return functions on other game objects with what we call a “Request/Provide pair”. This uses the ability to send a value with a message. For example, I might send a message “REQUEST_PLAYER_HEALTH” with the value myself (meaning the object sending the message). The player object has a receiver for the “REQUEST_PLAYER_HEALTH” message and a value. This sends a message to the value (which is the original object) reading “PROVIDE_PLAYER_HEALTH”, plus a new value. Then the original object receives this message and the new value. It’s a bit more involved than a standard function call, but it’s very modular, and like all Blockly code, it’s very hard to cause errors.

Coming Up

We’ve got more on the horizon, so make sure you keep an eye on us. KiwiJS version 1.4.0 is now in the planning stages, and it’s going to reflect months of game production and community feedback. Look forward to it!