Lost Decade Games

Lostcast Episode 7: HTML5, The Bad Parts

2012-02-03T00:00:00-08:00

(That’s Matt on the left, Geoff on the right… and Mojito below!)

Lostcast is our podcast about HTML5 games. In episode 7, we hate HTML5! … Ok, maybe we actually love it a little too hard, but in this episode we go over all the stuff that developers (via Twitter and live conversations) told us that they hate about working with HTML5.

Download Lostcast episode 7 (1:10:57, 81MB)

HTML5 Game of the Week: Faerie Alchemy

We’re going to start spotlighting one HTML5 game each week, starting things off with Faerie Alchemy by Subsoap. We discuss the game in more detail in the ‘cast, but the gist is that it’s a solid HTML5 game, very appropriate for the platform and quite polished. Check it out!

Show notes

Impact article on Audio
Mozilla’s Audio Data API
W3C Web Audio API spec
We should really embed our podcasts using the audio tag…
Audia, a simple Web Audio API wrapper
SoundManager 2
Adobe Edge Preview, HTML5 IDE
Modernizr
Chrome Web Store launch
Gamepad API
BBGCOMP #2
Space Dolphin
You were played out by: Madd Forest by video game composer Joshua Morse

Thanks for listening! If you have any HTML5 game development questions, please send them and we’ll answer what we can.

Lostcast Episode 6: A Wild Tom Appears

2012-01-27T00:00:00-08:00

Lostcast is our podcast about HTML5 games. In episode 6, we interview Tom Fairfield of Game Closure, the company that helped us launch Onslaught! on iPad and Android tablets.

Download Lostcast episode 6 (27:47, 32MB)

Show notes

Thanks for listening! If you have any HTML5 game development questions, please send them and we’ll answer what we can.

Lostcast Episode 5: Left 4 Questions

2011-12-31T00:00:00-08:00

Lostcast is our podcast about HTML5 games. In episode 5, we answer a list of questions sent in by Jarrod Oberto, one of our listeners. Here are the questions he sent us:

1) Setting your frame rate: So in the attached code I use setInterval(main, 20); Now I have an idea what this means but have not fully wrapped my head around it. I see in your tutorial you set this value to 1 (so it runs as fast as possible) and then control the speed with your “modifier” value? I tried your method and it killed my performance in Firefox. Could you explain the pros/cons in the two different techniques?

2) HTML5 code Setup: As you can see, I have spilled all my code in to one file! Is this good? bad? Should each object go into a separate file? All tutorials I see have the code jammed in the same file.

3) Menu/Opening screen: Here I’m talking the screen where you select the number of players or choose your car. Specifically how is the code organised? Is this code even in the “game” loop? it’s own loop? no loop? Again, tutorials skip this and throw you straight in the game.

4) Lastly, everything in the code attached is what I believe is correct. Therefore it may be completely wrong and I’ll never know until someone better than me points out mistakes. If you do decide to have a post cast/blog about bringing your code to the next level, I’m sure you will find plenty of fodder from my code!

Also, I used Logic Pro 9 (yay shiny new Xmas toy!) to edit this episode, and I’m brand new to it, so please do let me know about any issues, like editing or volume woes.

Download Lostcast episode 5 (41:11, 47MB)

Show notes

Racing game source code by Jarrod Oberto
Our HTML5 Rocks article, including a section on time-based modeling
requestAnimationFrame
Impact
Spacius! – (source code)

Thanks for listening! If you have your own HTML5 game development questions, please send them and we’ll answer what we can.

Lostcast Episode 4: Native Coffee

2011-12-16T00:00:00-08:00

Lostcast is our podcast about HTML5 games. In episode 4, we talk about Native Client and other cool HTML5-related stuff. We also answer our first listener email! Check out the show notes for links.

Note: our apologies for the poorer-than-usual recording quality. You can hear a dude blowing leaves outside… We’ll find a quieter location.

Download Lostcast episode 4 (46:22, 41MB)

Show notes

Thanks for listening! Don’t forget to subscribe and feedback is super awesome.

Lostcast Episode 3: Ramble On

2011-12-09T00:00:00-08:00

Lostcast is our podcast about HTML5 games. In episode 3, we ramble incoherently about ways to help lock down your HTML5 game’s source code. You may notice that this episode is significantly shorter than the previous two: this is based on popular feedback from Twitter. Also based on feedback, we did not include background music this time around.

Download Lostcast episode 3 (24:39, 20MB)

Show notes

Code obfuscation
Flash Game License
Daniel Cook and Steambirds
Seth Ladd of Google, Chrome Web Store
Capcom Mobile rips off ‘Splosion Man for MaXplosion
Got topic ideas? hello@lostdecadegames.com

Thanks for listening! Pretty soon we plan to play some HTML5 games and do some realtime reviews of them. If you have made or know about a game we should review, contact us!

Lostcast Episode 2: Code Like a Fox

2011-11-25T00:00:00-08:00

Lostcast is our podcast about HTML5 games. In episode 2, we talk with Louis Stowasser about his game engine, Crafty, among many other things HTML5-game related. Have a listen!

Download Lostcast episode 2 (55:03, 55MB)

Mentioned in the show

We are new to this, so feedback is especially helpful. Thanks for listening!

Lostcast Episode 1: Hello World

2011-11-18T00:00:00-08:00

Lostcast is the name of our new podcast! In this first episode we introduce ourselves, chat a little bit about Lost Decade Games, talk about the history of Onslaught!, and discuss HTML5 games in general. We’re not sure yet if it will be weekly, or monthly, or what. We’ll figure that stuff out eventually.

Download Lostcast episode 1 (46:11, 45MB)

(or subscribe via iTunes)

Links mentioned in the show

Thanks for listening! Next week we’ll hopefully be interviewing Louis Stowasser of Crafty fame. Tune in!

Free-to-use graphics made by my brother in 1996

2011-10-24T00:00:00-07:00

I’ve wanted to make an epic oldschool RPG for as long as I can remember. The first language I ever learned was QBASIC, which was about the worst environment for a huge RPG as I can imagine. But that didn’t deter me, and I set to work on what I called DRAGON (pretty creative title, right?).

Earlier this year I found some of my old QBASIC source code and began “translating” it to JavaScript. An unfinished version (of the unfinished game) is playable in your browser.

During this process I was admiring my brother’s artwork, which got me thinking that some game developers out there might like to have access to some fun little medieval fantasy sprites. So here they are, free to use in any project, commercial or otherwise:

Also: It’s not necessary of course, but if you do use them, I’d love to see them in action. So send me your project and I’ll check it out!

Bootstrap your artistic abilities with pixels

2011-10-17T00:00:00-07:00

So you want to make a game, but maybe there are hurdles blocking you. If you’re a programmer like me, you can do everything yourself (to a point) but your game must at least have graphics! This is a problem.

I submit that you can do it yourself, whether you’re artistically challenged or not. You just need to bolster your artistic skills with the help of our little friends, pixels. Let’s get started!

Start small

First, start with just two pixels. Open your favorite image editing program (or just grab a sheet of graph paper). Let’s make this image 1x2, meaning two pixels tall and 1 pixel wide. (Yes, we are starting extremely basic.)

Now try to draw a person. A man, a woman, or another little character for a game. My guess would be that most people will come up with something like this:

Almost everyone will draw the same thing because the limitations are so severe. Some people might make a completely clothed character or a completely naked character, like one of these:

But either way, they’re very similar. Even the worst artist will make an image that will be strikingly similar to what the best artist would make under these limitations. This is an interestingly level playing field.

Kick it up a knotch

Now let’s make the canvas a bit bigger and use a reference. For the sake of familiarty and clarity, let’s look at an image of Link from The Legend of Zelda.

Try to draw Link in a 4x4 grid. Your image might look something like this:

Some shape is starting to take form and now we’re diverging a little from what other artists might make given the same limitations. But we’re still close to the best of what can be done under these restrictions.

Let’s double up. Here’s my attempt at the previous Link image on an 8x8 canvas:

My guess is that this might be the sweet spot for many beginning artists to maximize what they can do under a given restriction. But even though you might be happy with your output at this resolution, you may be thinking that the limitation is too extreme to be creative and generate diverse graphics.

Not so! Take a gander at these heavily-used Creative Commons sprites that can be found in little games all over the web:

There is such a rich variety that the artist has exposed even with these extreme limitations. If we double up once more to 16x16, then truly the sky is the limit, as you can see in this amazing screenshot from Final Fantasy VI, which employs 16x16 tiles:

Here I’ve added a 16x16 grid and enlarged a single tile to demonstrate where the boundaries are:

Working even with 16x16 tiles (that’s 256 pixels!) may be beyond the skill level of many developers looking to boostrap their own art. What I’m trying to suggest is that there may be a comfort zone where you can produce decent pixel art – at 8x8 or 12x12, or whatever feels good and you find acceptable.

Many games feature amazing art that requires the skill and dedication that only natural talent and thousands of hours of practice can produce. But if you’re an indie game developer, a hobbyist or if you just want to bang something out quickly, your art doesn’t necessarily need to be that fancy. Maybe for now you can make do with what you’ve got, empowered by the limitations of big, beautiful, blocky pixels.

Additional resources

Got any additional tips? Please let me know in the comments!

Lost Links: 10/14/2011

2011-10-14T00:00:00-07:00

Enjoy this Friday’s roundup of HTML5 gaming links!

That’s all for this week. Feel free to point us at interesting HTML5 gaming content via Twitter (@lostdecadegames) or by emailing us at hello@lostdecadegames.com.

Onslaught! -- a history of violence (in images)

2011-10-10T00:00:00-07:00

Onslaught! is a medieval fantasy arcade shoot ‘em up. It was one of the very first commercial HTML5 games available to the world, launching on December 7, 2010 with the Chrome Webstore and has since launched on iPad and Android tablets.

HTML5 is taking off, the web is evolving, the Chrome Web Store is available in more countries than ever and one of these days we’ll be announcing our next game, so I thought this would be as good a time as any to walk through Onslaught! and its near-successes. Here’s a history of Onslaught!, in images:

1. First whiteboard

Geoff and I spend a ton of time talking, scribbling, debating and planning before we write even a single line of code. This is the first of many whiteboards we scratched out while developing Onslaught!.

2. Early environment test

We needed graphics but we didn’t have any dedicated artist friends or extra money to spend. So I rolled up my sleeves, bought a Cintiq tablet and drew out some tests to see if I could bang out the graphics myself.

3. Whiteboard: game flow

This was another early whiteboard, showing the flow of the menus and interface of the game.

4. Objects test

Here’s another graphics test, this time for basic game objects. I think the mantra was “good enough.”

5. Couch development

This is a very typical setup for how we worked on Onslaught!. Some days we’d leave work and head to Geoff’s for some game design, other days (like in this photo) we’d head to my place for gameplay tweaking on the big screen.

6. Whiteboard: enemy statistics

We spent ridiculous amounts of time tweaking the damage, health, behavior and interaction of the enemies in Onslaught!, hoping to provide retro gamers with an experience that would feel polished, and familiar yet new.

7. Dragon tests

I think at some point I found my stride with graphics, and to me the dragon turned out really well (unlike the minotaur). Dragons of all colors are interesting and nostalgic to us, but in the end you can’t beat the classic “green dragon.”

8. Google internal contest poster

I’m not sure that we ever publicly talked about this! As part of Google’s internal promotion for the Chrome Webstore, they held a contest to see who could get the highest score in Onslaught!. The winner received an Amazon gift card. We later met with the best players to discuss issues with the game and how we could improve it for our players. Google intended to print these posters I made and put them around their campus. That never happened, but the experience was still invaluble.

9. Chrome Web Store launch

As early adopters of the platform, we were invited to Google’s big media event where they announced the Chrome Web Store and talked about Chrome OS. It was really exciting, as screenshots of Onslaught! could be found around the extravagant event, including this one (Onslaught! can be seen below the word “Chrome”).

10. New environments test

We were planning on bringing Onslaught! to iPad, and to help make the jump to a new platform successful, we wanted to add more content for gamers to enjoy. This was an early sketch of some ideas we had.

11. Sunken City

And this is the final version of the beach scene that shipped with the updated game.

12. Demo party

As part of working with Game Closure’s SDK, they graciously threw a release party for Onslaught!. Many players showed up from StartX for catered food and a brand new gaming challenge. Much useful feedback was had, as well as some shouts of victory that was a real pleasure for us to experience firsthand.

13. New and Noteworthy

We were stoked to see Onslaught! in the “New and Noteworthy” section in the iPad App Store. We only saw a slight boost in sales, but it was still exciting.

14. Game Developer Magazine screenshot

One of the biggest thrills of my life was reading through Game Developer Magazine and seeing a screenshot of our game. Sure it’s just a little mention, but you gotta start somewhere. I’m so proud I framed it and put it on my wall.

15. Onslaught! on iPad

And here’s the latest version of Onslaught!, at the Stage Select screen. It’s been a long journey, and we’re very proud of our little game.

So what’s next?

We’re not totally sure just yet, but we’ll be announcing something soon. Stay tuned, and thanks for reading.

Lost Links: 10/7/2011

2011-10-07T00:00:00-07:00

Happy Friday! Check out our HTML5 gaming links for this week:

That’s all for this week. Feel free to point us at interesting HTML5 gaming content via Twitter (@lostdecadegames) or by emailing us at hello@lostdecadegames.com.

Audia is a library for simplifying the Web Audio API

2011-10-05T00:00:00-07:00

After receiving numerous requests on Twitter, I started working on a tutorial for playing sound in HTML5. You may have read about previous frustrations with Audio from the HTML5 developer community, and when I dug in recently, the situation was all-too familiar.

Wrong tool for the job

In the latest version of Chrome, sound playback was unreliable, bits and pieces were missing from the API, and things just did not work as expected. Safari faired better, but it still felt like Audio was not ready for prime time. However, I think the problem was more of using the wrong tool for the job. Games need responsive, reliable, sometimes even dynamic sound playback, and because of this, Audio is not the best choice for game development.

A good way to think about it is by comparing the Image and Audio tags. Both are simple HTML elements that really just want src attributes, from which they’ll fetch the media and display it in the document. For advanced image manipulation, Canvas is used, and for advanced audio manipulation, AudioContext can be used.

Enter the Web Audio API

It turns out, the Web Audio API is here today and it is pretty badass. (By “here today” I really just mean Chrome, but it exists and works great even in the stable channel.)

Just about the only documentation I could find was the W3C Working Draft, but this was enough to meet feature parity with Audio. Fair warning to developers looking to toy around with it: the API is extremely low-level and cumbersome to use (but quite fun if that floats your boat!).

Here’s what it takes to simply load up a sound file and play it:

if (typeof AudioContext == "function") {
	var audioContext = new AudioContext();
} else if (typeof webkitAudioContext == "function") {
	var audioContext = new webkitAudioContext();
}

var source = audioContext.createBufferSource();
source.connect(audioContext.destination);

var xhr = new XMLHttpRequest();
xhr.open("GET", "your_sound_file.mp3", true);
xhr.responseType = "arraybuffer";
xhr.onload = function() {
	var buffer = audioContext.createBuffer(xhr.response, false);
	source.buffer = buffer;
	source.noteOn(0);
};
xhr.send();

That’s a lot of code! Let’s walk through it.

1. Create an instance of AudioContext

if (typeof AudioContext == "function") {
	var audioContext = new AudioContext();
} else if (typeof webkitAudioContext == "function") {
	var audioContext = new webkitAudioContext();
}

Since this is bleeding-edge technology, we can’t guarantee that AudioContext exists. Indeed, Chrome currently has the webkitAudioContext object (an experimental implementation). So before we can create a new instance we first have to check to see what we have available.

2. Create a buffer source and connect it to the audio output

var source = audioContext.createBufferSource();
source.connect(audioContext.destination);

We request to create a buffer source and store it in the source variable. Then we connect the source to the audio context’s destination property, which will hopefully be our computer’s speakers!

3. Fetch the mp3 file

var xhr = new XMLHttpRequest();
xhr.open("GET", "your_sound_file.mp3", true);
xhr.responseType = "arraybuffer";
xhr.onload = function() {
	// See step 4
};
xhr.send();

This might be a tad unexpected for JavaScript programmers who are accustomed to simply setting a property on an HTML node (for example. myAudio.src = "my_sound.mp3";), but to fetch our sound file we need to do it via an XMLHttpRequest object. This is basic AJAXy stuff, aside from needing to set responseType to “arraybuffer”.

4. Create the sound buffer and play the sound

var buffer = audioContext.createBuffer(xhr.response, false);
source.buffer = buffer;
source.noteOn(0);

This code makes up the contents of the above XMLHttpRequest object’s onload method. First we create a buffer, passing in the XHR response and false. (That second parameter is “mixToMono”, and we don’t necessarily want our sound in mono, so we pass in false.) This buffer gets passed to the source by setting its buffer property.

Next, there’s a call to the odd method noteOn. In simpler English, this would be play, but what is going on behind the scenes is much more complicated. The argument represents the time (in seconds) to begin playback. To make our playback begin immediately, we pass 0.

Pretty involved just to play a sound, right? But the reward is well worth it, because now we have low-level access to our computer’s sound and can implement all kinds of goodies like panning, filters and other neat effects.

Introducing Audia

Jump straight to the demo?

While experimenting with this new API, I quickly discovered that a library to abstract away all this complication would be nice to have, so I wrote one. Here is what I call Audia, which implements a very straightforward API while still providing some of the power of the Web Audio API. Here’s an example of how it can be used:

if (!Audia.supported) {
	alert("Oops, no AudioContext object found ...");
}

var attackSound = new Audia();
attackSound.onload = function () {
	attackSound.play();
};
attackSound.src = "audio/demoblin_attacks.mp3";

Or alternatively:

var backgroundMusic = new Audia({
	src: "sewers.mp3",
	loop: true,
	volume: 0.5
});

Audio (especially as pertains to video games) is a little hobby of mine, so you can bet I’ll be exposing more of the power behind the Web Audio API to Audia’s simple interface. So do check out the demo and let me know in the comments about any issues, feature requests, etc.

Lost Links: 9/30/2011

2011-09-30T00:00:00-07:00

HTML5 gaming links for this week! Also, if you’re interested in chatting about HTML5 game dev, Matt and I are hanging out in #bbg on Freenode IRC. Drop in and say hello to zylo (Geoff) and richtaur (Matt)!

That’s all for this week. Feel free to point us at interesting HTML5 gaming content via Twitter (@lostdecadegames) or by emailing us at hello@lostdecadegames.com.

Blog author attribution using Jekyll

2011-09-26T00:00:00-07:00

Since converting our website/blog to use Jekyll we’ve had a chance to dig a bit deeper into the usage of the framework. One of the first features we tackled was author attribution in blog posts. In this post I’ll cover our approach in detail.

Our goal was to display, at the very least, the author’s name and Gravatar on each blog post. Originally, we hard-coded these values in the YAML Front Matter. For example:

---
layout: post
title: Catchy blog post title
post_author: Geoff Blair
post_gravatar: 76dbcc74021b8039f14c7b583978b56d
---
This is the post content.

Rendering this data was very straightforward:

<div class="post">
	<div class="meta">
		<img src="http://www.gravatar.com/avatar/{{ page.post_gravatar }}?s=40">
		<span class="author">{{ page.post_author }}</span>
	</div>
	{{ content }}
</div>

This approach worked decently but has some obvious drawbacks. We found ourselves opening previous blog posts by the desired author and copy/pasting the author data into a new file. While this doesn’t take up an extraordinary amount of time, there certainly had to be a more elegant solution.

Ideally, specifying an author would be as simple as adding a key author: geoff or author: matt to a blog post and looking up the rest of the info defined elsewhere.

After some reading the Jekyll wiki page on Template Data I found that Jekyll exposes anything in _config.yml through the site variable:

As of 0.5.2, all data inside of your _config.yml is now available through the site variable. So for example, if you have url: http://mysite.com in your configuration file, then in your posts and pages it can be used like so: {{ site.url }}.

With that in mind, I created a data structure in _config.yml to represent post authors:

authors:
  matt:
    display_name: Matt Hackett
    gravatar: 60fd5218fff6927c0ed376cce01c5460
    email: matt@lostdecadegames.com
    web: http://www.richtaur.com/
    twitter: richtaur
    github: richtaur
  geoff:
    display_name: Geoff Blair
    gravatar: 76dbcc74021b8039f14c7b583978b56d
    email: geoff@lostdecadegames.com
    web: http://www.geoffblair.com/
    twitter: geoffblair
    github: geoffb

Rendering author information is almost as easy as before, we just need to grab a reference to the current author’s data in our post template:

{% assign author = site.authors[page.author] %}
<div class="post">
	<div class="meta">
		<img src="http://www.gravatar.com/avatar/{{ author.gravatar }}?s=40">
		<span class="author">{{ author.display_name }}</span>
	</div>
	{{ content }}
</div>

Nice and clean!

Another benefit of this setup is that we can use the author data elsewhere, too. Take a look at the source for our “Contact Us” page for an example.

We’re pretty happy with this approach. Let us know on Twitter or by email if you know of a better way!

Lost Links: 9/23/2011

2011-09-23T00:00:00-07:00

Welcome to the first installment of Lost Links, a weekly round-up of HTML5 gaming related links.

That’s all for this week. Feel free to point us at interesting HTML5 gaming content via Twitter (@lostdecadegames) or by emailing us at hello@lostdecadegames.com.

Our new blog is running on Jekyll

2011-09-12T00:00:00-07:00

Welcome to our new website! As web developers, we’ve been aware that our site has been a bit … sad? For entirely too long now. So we rolled up our sleeves, made a brand new design and moved our blog off of Posterous.

What’s different?

Our new site is hosted via GitHub Pages and is powered by Jekyll – a “blog-aware, static site generator.” There are several benefits to this setup:

Jekyll compiles the site once and then only static html files are served making page load times very fast.
We can deploy changes or make new posts just by committing to the GitHub repo.
Better Markdown support which makes Geoff especially happy.

In addition to the above changes we’re using LESS to write cleaner and more easily maintained CSS.

It looks like we’re not the only ones migrating our site to GitHub Pages, either. Check out this article from Development Seed for some great tips on using Jeykll.

More organized GitHub repos

Our demos and code samples used to all be thrown into our public lostdecade.github.com repo, but this made for awkward forking and wasn’t very clean. Now we’ve made separate repos for our demos including:

So fork, fork away!

So long, comments!

We mourn the loss of our comments. Thank you to all who contributed to discussions on our blog, but we hope that moving forward, relying on social networks for interaction with our fans and readers will be adequate. As always, please feel free to email us.

More stuff coming soon

We’ll be making a more substantial page for Onslaught!, designing an actual title, and fixing any issues that may arise. What do you think? Do you have a setup for your website that’s similar to ours? Let us know on Twitter!

How to make a simple HTML5 Canvas game

2011-08-29T00:00:00-07:00

Since releasing Onslaught! Arena, I've had many requests for a very basic tutorial on how to make a simple game in canvas. After pondering for some time how to best approach this complex subject, I decided just to put together the very simplest game I can imagine and walk through it practically line-by-line.

So here it is! Let's jump right in by walking through game.js. You can also play the game right here.

1. Create the canvas

// Create the canvas
var canvas = document.createElement("canvas");
var ctx = canvas.getContext("2d");
canvas.width = 512;
canvas.height = 480;
document.body.appendChild(canvas);

The first thing we need to do is create a canvas element. I did this in JavaScript instead of HTML to demonstrate how easily it is accomplished. Once we have the element we get a reference to its context, set its dimensions and append it to the document's body.

2. Include images

// Background image
var bgReady = false;
var bgImage = new Image();
bgImage.onload = function () {
	bgReady = true;
};
bgImage.src = "images/background.png";

A game needs graphics! So let's load up some images. I wanted to do this as simply as possible so it's just an Image instead of being wrapped up in a nice Class or something. bgReady is used to let the canvas know when it's safe to draw it, as trying to render it before it's loaded will throw a DOM error.

We do this for each of the three graphics we need: background, hero and monster.

3. Game objects

// Game objects
var hero = {
	speed: 256, // movement in pixels per second
	x: 0,
	y: 0
};
var monster = {
	x: 0,
	y: 0
};
var monstersCaught = 0;

Now we define some variables we'll need to use later. hero gets setup with speed which is how fast it'll move in pixels per second. monster won't move so it just has coordinates. Lastly, monstersCaught stores the number of monsters the player has caught.

4. Player input

// Handle keyboard controls
var keysDown = {};

addEventListener("keydown", function (e) {
	keysDown[e.keyCode] = true;
}, false);

addEventListener("keyup", function (e) {
	delete keysDown[e.keyCode];
}, false);

Now for input handling. This is probably the first part that will trip up developers who come from a web development background. The important thing to remember is that we don't necessarily want to react to an input event right when it happens. In the web stack, it may be appropriate to begin animating or requesting data right when the user initiates input. But in this flow, we want our game's logic to live solely in once place to retain tight control over when and if things happen. For that reason we just want to store the user input for later.

To accomplish this we simply have a variable keysDown which stores any event's keyCode. If a key code is in the object, the user is currently depressing that key. Simple!

5. New game

// Reset the game when the player catches a monster
var reset = function () {
	hero.x = canvas.width / 2;
	hero.y = canvas.height / 2;

	// Throw the monster somewhere on the screen randomly
	monster.x = 32 + (Math.random() * (canvas.width - 64));
	monster.y = 32 + (Math.random() * (canvas.height - 64));
};

The reset function is called to begin a new game, or level, or whatever you'd like to call it. It places the hero (the player) in the center of the screen and the monster somewhere randomly.

6. Update objects

// Update game objects
var update = function (modifier) {
	if (38 in keysDown) { // Player holding up
		hero.y -= hero.speed * modifier;
	}
	if (40 in keysDown) { // Player holding down
		hero.y += hero.speed * modifier;
	}
	if (37 in keysDown) { // Player holding left
		hero.x -= hero.speed * modifier;
	}
	if (39 in keysDown) { // Player holding right
		hero.x += hero.speed * modifier;
	}

	// Are they touching?
	if (
		hero.x <= (monster.x + 32)
		&& monster.x <= (hero.x + 32)
		&& hero.y <= (monster.y + 32)
		&& monster.y <= (hero.y + 32)
	) {
		++monstersCaught;
		reset();
	}
};

This is the update function and is called every single interval execution. The first thing it does is checks the up, down, left and right arrow keys to see if the user has pressed them. If so, the hero is moved in the corresponding direction.

What may seem odd is the modifier argument passed into update. You'll see how this is referenced in the main function, but let me first explain it here. modifier is a time-based number based on 1. If exactly one second has passed, the value will be 1 and the hero's speed will be multiplied by 1, meaning he will have moved 256 pixels in that second. If one half of a second has passed, the value will be 0.5 and the hero will have moved half of his speed in that amount of time. And so forth. This function gets called so rapidly that the modifier value will typically be very low, but using this pattern will ensure that the hero will move the same speed no matter how fast (or slowly) the script is running.

Now that we've moved the hero according to the player's input, we can check to see what happened with that movement. If there was a collision with the hero and monster, that's it! That's pretty much the game. We tally the score (+1 to monstersCaught) and reset the game.

7. Render objects

// Draw everything
var render = function () {
	if (bgReady) {
		ctx.drawImage(bgImage, 0, 0);
	}

	if (heroReady) {
		ctx.drawImage(heroImage, hero.x, hero.y);
	}

	if (monsterReady) {
		ctx.drawImage(monsterImage, monster.x, monster.y);
	}

	// Score
	ctx.fillStyle = "rgb(250, 250, 250)";
	ctx.font = "24px Helvetica";
	ctx.textAlign = "left";
	ctx.textBaseline = "top";
	ctx.fillText("Goblins caught: " + monstersCaught, 32, 32);
};

Games are more fun when you get to see the action going down, so let's draw everything to the screen. First we take the background image and draw it to the canvas. Repeat for the hero and monster. Note that the order is important, as any image drawn to the surface will be drawn over the pixels under it.

Next we change some properties on the context related to how to draw the font, and we make a call to fillText to display the player's score. As we don't have any complicated animations or movement, we're done drawing.

8. The main game loop

// The main game loop
var main = function () {
	var now = Date.now();
	var delta = now - then;

	update(delta / 1000);
	render();

	then = now;
};

The main game loop is what controls the flow of the game. First we want to get the current timestamp so we can calculate the delta (how many milliseconds have passed since the last interval). We get the modifier to send to update by dividing by 1000 (the number of milliseconds in one second). Then we call render and record the timestamp.

See also the Onslaught! Arena Case Study for more on game loops.

9. Start the game!

// Let's play this game!
reset();
var then = Date.now();
setInterval(main, 1); // Execute as fast as possible

Almost there, this is the last code snippet! First we call reset to start a new game/level. (Remember that this centers the hero and places the monster randomly for the player to find.) Then we seed our timestemp (with the variable then) and start the interval.

Congraulations! You now (hopefully!) understand the basic fundamentals of game development using the canvas element in JavaScript. Try it out on your own! Play the game or fork the code on GitHub and get started hacking.

Got feedback?

What did you think of this tutorial? Was it helpful? Too slow, too fast, too technical, not technical enough? Please let me know and I'll try to improve the next tutorial! Be sure to follow us on Twitter to know right when the next tutorial is available.

Analog thumb sticks for iOS using HTML5

2011-08-05T00:00:00-07:00

From mouse and keyboard to analog thumb sticks

You may have read before about some of the difficulties of porting Onslaught! to iOS. The first major hurdle we had to jump was getting a decent framerate. This and many other technical issues (including audio) were solved by Game Closure's SDK, but there were other critical issues to address, including a fundamental difference in user input.

Versions of Onslaught! Arena for Chrome and OSX rely on mouse and keyboard controls. Players can use the WASD keys (or arrow keys) to navigate, as well as the mouse for aiming and attacking. Obviously these input mechanisms are not compatible with touch devices. To make the jump to mobile as smooth as possible, we experimented with many different control schemes, and ended up providing players with two options:

Touch to move. We labeled this as the "Beginner" option, informing players to "Use one finger." This is a streamlined, AI-assisted control scheme. Players touch the device where they want their character to move, and the character automatically attacks the nearest enemy or projectile.
Analog thumb sticks. This is the (comparatively) "Advanced" scheme, asking players to "Use two thumbs." This mechanism provides players with complete control over where their character is moving, where he is facing, when to attack, and fine granular control over the angle of the thrown projectiles.

None of the decisions we made regarding user input were decided on lightly. First, we understood that analog thumb sticks have issues of their own, so we read up on best practices and studied the approach used by other popular games in the shoot 'em up genre (including Minigore and Geometry Wars). Based on this research, there seemed to be two very different approaches to the positioning of digital thumb sticks: dynamic and static.

Dynamic thumb sticks (like those used in Geometry Wars) appear on the screen only after the player touches the device, creating anchor points. Movement is then recorded as relative to those points. This has advantages such as user comfort; if one player likes to have his or her thumbs near the edge of the screen, that's fine. Likewise this method supports players who would prefer to reach farther into the device for stability or other reasons. One potential downside is that without prior visual indication, it may not be easily understood how to interact with the game or where to touch the device to begin input.

Static thumb sticks are typically always visible and in fixed positions on the screen. We decided to go with this option for a few reasons, including what we believe to be a more robust first-time experience; players new to the game could see at a glance where to put their thumbs. Additionally, it removed issues with monsters or traps being hidden beneath players' thumbs!

Technical approach

We strongly believe in code reuse so we wanted something that could easily be dropped into just about any project. This led to the creation of a Stick class that can be used like so:

var stick = new Stick(40); // 40 is the size of the input
document.addEventListener("mousemove", function (e) {
	e.preventDefault();
	stick.setInputXY(e.pageX, e.pageY);
});

This is easily rendered to the canvas element with code like:

context.beginPath();
context.arc(stick.limit.x, stick.limit.y, limitSize, 0, (Math.PI * 2), true);
context.stroke();

Examples

Below I've embedded an example that uses this class as a dynamic thumbstick that should work in most browsers. The thumb stick does not appear until input begins and controls the velocity of the green circle:

Using the same class, I've embedded another example, this time as a static thumbstick. This demo also controls the velocity of the green circle but it's been augumented with base and pivot graphics (the same graphics used in Onslaught!):

For readers who would also like to see how this is accomplished on an actual iPad, load up this page on your device.

Dear Lost Decade...

2011-07-18T00:00:00-07:00

About a week ago we launched Onslaught! on iPad, and during the weekend we were surprised and delighted to discover a few things. First, Onslaught! is in the "New & Noteworthy" section of the iPad App Store. We're thrilled to see Apple helping to bring exposure to our game, and have been excited to see a significant boost in sales. We think this speaks loudly that HTML5 is here, today, and there can be no more doubt that it's a viable development choice.

Second, and no less impactful to us, was a well-written and thoughtful review from a loving fan of the game. The subject of the review is "Dear Lost Decade..." and you should be able to read it on the review page. Here it is verbatim:

Onslaught! is a love letter to a certain subset of gamers; those that grew up playing white-box Dungeons & Dragons and video games in equal measure, i.e. - me. If you are a fellow member of that elite but dorky minority, buy this game immediately. If you are not, wait five minutes, then buy it anyway.

It feels like this game has been marinating in awesome since the day it was conceived, lovingly nurtured through the development process, and then birthed into the app store, kicking and screaming. This game is truly original. Not oh-em-gee, I've never seen anything like this and it's going to change the world; that's innovation. This is originality; taking tried and true game mechanics and themes and melding them in a way that feels new. In some ways, this is superior to innovation, because it deftly tiptoes ninja-style over the pitfall of creating something that is new, but not necessarily better. An original title safely co-opts proven content in a way that feels startlingly fresh.

But enough philosophizing. This game has Owlbears. Do want. The sewer level boss is a Gelatinous Cube. Yes, money, give it. This game has an icon in the front end that looks strikingly similar to the silhouette of a Beholder. That's right, take it baby, you know you want it. That's how freakin' kewl this game is, that's the way that it's retro, and that's why the devs had me at hello.

Add that to the fact that the controls are perfect, the weapons are diverse, and the enemies are brilliantly differentiated in the most elegant of ways. Yes, this is dual-stick, but it's not Geometry Wars, where you are pouring out bullets at light speed, across the length of the screen. While I do love that, it would not have been on theme for this game, and the decision to steer clear of it was a smart one.

Instead, some of the weapons have noticeably short ranges, both to match the fantasy theme and to distinguish between other weapons with different properties: double dagger with a wide arc-of-fire, high rate-of-fire spears, burning fireballs, freezing ice shards, and axes that ricochet. Enemies have vulnerabilities and invulnerabilities to some of these weapons too. Ever tried to fight a Gelatinous Cube with a dagger? Tried and died...

The diversity of the enemies is just as important. When the Minotaur enters the first arena, then charges at you blindingly fast, you realize that fact. Some enemies multiply, some have ranged attacks, some teleport, and some just mob you till you suffocate.

Add to this laundry list that you can purchase gear for your adventure from Ye Olde Shop, with a heaping pile of golden doubloons from your previous trek. Also add three levels of difficulty, each with its own arena (watch out for the traps amongst the piles of glistening treasure in the dragon's lair). Also add that this game will receive continued love and support from the devs, because anyone who cares enough to share their baby with the world will make certain that it fairs well in its strange and wonderful new surroundings.

Some people will not like game as much as me. That's okay, I don't mind. I happen to gravitate toward beauty in simplicity. I am not of the opinion that Gameloft's latest flavor-of-the-week clone is what makes the app store special, no matter how polished they are. What makes the app store special is that a guy can have a simple idea, release it into the wild, have it sit toe-to-toe with those games, and come out on top in gamers' minds. I have to think that would be his proudest moment.

To the developers of this game,

Thank you so much for the letter. It means the world to me; it really does. Love you too.

xoxo,

.djflippy

The player known as djflippy took the time to write this eloquent review, so we wanted to spotlight it. As Geoff and I are oldschool hardcore gamers ourselves, our intention was very much to appeal to this audience. Since it seems that we have accomplished that with at the very least this supportive fan, we are beyond satisfied. Here's a huge digital hug for djflippy, and thank you for making our weekend delightful!

To help spread the love, we are making Onslaught! 50% off for the rest of the week. If you haven't yet, pick it up now for $0.99!

Onslaught! now available on Android tablets

2011-07-16T00:00:00-07:00

Hot on the heels of our announcement of Onslaught! for iPad, we're now equally as thrilled to announce Onslaught! for Android. This is again without any additional code on our part, thanks to Game Closure's awesome technology. Read all about it in our previous article, "The road to a production-quality HTML5 game on iOS".

Unfortunately it's currently only compatible with Android tablets, but we are working on a version that will work with Android phones too. Follow us on Twitter to know be notified as soon as it's available!

The road to a production-quality HTML5 game on iOS

2011-07-11T00:00:00-07:00

As seen today on TechCrunch!

About a year ago, Geoff and I were both senior frontend engineers working for Raptr. As software programmers by trade and hardcore gamers at heart, we were anxious to test out this new "HTML5" buzzword to see how well it could handle game development. BoingBoing happened to be running a Games Inspired by Music contest, to which we submitted our first HTML5 game, an early version of Onslaught! Arena.

The game that we entered to the contest was a quick two-week hack put together in our spare time, written in JavaScript and Canvas and designed to run reasonably well in "modern browsers." Making the game was extremely fast and easy, using Google Chrome and its great developer tools. As expected, the primary issues we ran into were largely performance-related. About mid-way through development, however, Chrome "unleashed" GPU acceleration on the web, which shot our FPS (frames per second) from ~30 to something more like ~200 on tested desktop computers and laptops. (Basically the game ran about an order of magnitude faster, as browsers were improving by leaps and bounds.) Like other developers, we also had a cavalcade of nasty audio issues, ranging from latency, to format incompatiblity and stuttering playback. We ended up shipping with SoundManager 2 (a JavaScript-to-flash audio API), though we eventually did utilize HTML5's Audio tag.

Around this time, Google was coincidentally preparing for the launch of its new Chrome Web Store, which was a potentially exciting new platform championing HTML5 and open web standards. After scrambling to polish Onslaught! Arena and wrapping a Chrome-colored bow around it, Onslaught! Arena launched in Google's web store. We were invited to the press release, had a screenshot of our game up on a big wall, and were very excited to see our HTML5 creation getting industry attention.

Despite being a featured game to launch with a brand new offering from a heavyweight like Google, sales were lackluster (as pointed out by TechCrunch). Given that part of HTML5's intended appeal is its portability, we thought it was time to give it a real-world test. This includes some successes, such as a release in the Mac App Store, but we found that our primary problem was still slow performance, particularly on iOS (I believe that our best benchmark was ~10 FPS, the target for any game being at least 30 FPS). The answer to our speed woes came from Game Closure, a small group of wickedly smart guys who put together a multi-platform HTML5 game framework.

Leveraging Game Closure's tech, we had a playable version of Onslaught! Arena on iPad after just a day of hacking, running at an impressive 60 FPS (5x that of a simple embedded WebView). Their approach is very similar to that of ImpactJS -- that is, they have a custom JavaScript environment, accelerated with direct access to native graphics and sound. The best part is that our development environment never changed; we were still using Google Chrome, working in pure HTML5 and enjoying Chrome's fine developer tools.

We didn't just want to port the game over, however. We wanted this release to be something special, so we spent a few weeks stuffing it full of brand new content, including:

Completely redone, full soundtrack by Joshua Morse
Revamped arena, much bigger playing area
Four new environments (Sewers, Dragon Lair, Sunken City and Volcano)
New Stage Select screen to improve the game's pacing and replayability
New weapon: frostbolt (stops enemies cold!)
New monsters: skeleton, merman and Naga
Shop (featuring an HTML5 Shield, Speed Boots, Gold Armor, Whet Stone and even a Dragon Familiar to help you fight)
Two types of controls (touch-to-move, dual sticks)

Development take-aways

We've learned dozens of lessons and have what we hope are insightful and helpful take-aways about the process of bringing an HTML5 game to production-quality on iOS. We'll be writing about them all in due time (subscribe here), but here are a quick handful of pointers:

Browsers are great for prototyping and fast development. If you're used to compiling your game before being able to test out some code, you'll love moving over to an environment where you can simply reload the game with a single keystroke.
Don't worry about framerate/performance until you absolutely must. On more than one occasion, we dirtied up our game's logic with slight optimization tweaks, only to later get huge speed increases later from external sources (that didn't require code updates).
Developer tools in the browser are really great. Firebug paved the way for Web Inspector, and current versions of Chrome are a developer's dream. I have only some experience debugging in Objective-C or the Android SDK, but they feel heavy-handed in comparison.

We'd like to point out that even with all of this new content, Onslaught! is still a pure HTML5 game. It was developed in Google Chrome, and leveraging Game Closure's SDK, required no additional iOS-specific work on our part.

Onslaught! is available now in the iPad App Store. We put a lot of love in this game; we hope you'll check it out and let us know what you think in the comments or on Twitter. Game on!

Side note: this space is blowing up

HTML5 and games built on HTML5 are really hot right now. If you're not convinced by our little game's story, you should know about other huge companies becoming invested in the technology, including Apple, Google, Electronics Arts, and Facebook among other major players. We are actively hiring across the development board, from experts in JavaScript and game programming to interns looking to learn. If you find this space interesting, please do contact us.

Lava background sprite creation (timelapse)

2011-05-25T00:00:00-07:00

If you follow us on Twitter you may already know this, but we've been busy working on a new version of Onslaught. We're really excited to be preparing the game for iPad, and instead of just delivering a straight-up port we'll be adding a ton of new content.

The new content ranges all over from weapons, monsters and a new boss, but one the most signifcant updates will be four brand new environments. This should be fun: the last stage takes place inside a damn volcano! I've been working really hard to make interesting environments for players to enjoy and thought a timelapse video of their creation might be fun to watch:

Hope you like it; it was a blast to make! And what is that background music? Why, it's a brand new soundtrack by Joshua Morse! Players will be treated to at least 5 brand new nuggets of music goodness. If you're a fan of Onslaught, retro games or the iPad, keep you eye on this space! We'll be blogging about our new iPad game hopefully in the next few weeks.

And (though the timelapse doesn't cover everything), here's the final product:

Completing your native Mac OSX App built in HTML5

2011-04-17T00:00:00-07:00

Note: this is a continuation of How to embed HTML5 into a native Mac OSX app. This tutorial uses Xcode Version 4.0.1.

So having gone through the first tutorial, you should now have a bare-bones native OSX application running your HTML5 program. Let's open that same project in Xcode (example on GitHub) and finish it up! I'll use WebViewExample as the name of this tutorial project, but just like last time, yours can be whatever you like.

Adding an icon to your app

To set the icon that appears in the dock, Finder and other views, follow these steps:

First you need an Apple Icon Image file. To make one yourself, open up the Icon Composer application (mine is located in /Developer/Applications/Utilities/Icon Composer.app). For the sake of speed you can use OnslaughtArena.icns.
In Xcode's left sidebar, drill down into WebViewExample / Resources.
Drag your .icns file into the Resources folder.
Still in the Resources folder, open the WebViewExample-Info.plist file.
In the "Key" column, find the row with the value "Icon file".
Set the value of this row to the name of your .icns file (eg, OnslaughtArena.icns).

Closing the window should close the application

For those unfamiliar with OSX, I'll quickly describe what this means. In OSX, you can have an application open without any windows. This is very different from Microsoft's Windows operating system where if all the windows are closed, the application is no longer running. This can create an awkward user experience, so there must be a way to bring windows back. This flow doesn't really make much sense for games, so a good workaround is to close the application when all windows are closed.

Be sure to do this; we got rejected the first time we submitted because we did not enable this feature! Here's the reason from Apple:

We have found that if the user closes the app window, there is no way for the user to reopen the app without having to quit and relaunch the app.

Fortunately the fix is easy.

In Xcode's left sidebar, drill down into WebViewExample / Classes / WebViewExampleAppDelegate.m.
In the awakeFromNib method, add this line just above the closing bracket: [window setDelegate:self];.
Add this method after the awakeFromNib method:


- (void)windowWillClose:(NSNotification *)aNotification {
	[NSApp terminate:self];
}

That's it! Now when you close your application's main window, the application should quit. Note: this works great but it generates the warnings "notice: Semantic Issue: Passing argument to parameter 'anObject' here" as well as "Class 'WebViewExampleAppDelegate' does not implement the 'NSWindowDelegate' protocol".

Logging errors

Xcode can be a bit daunting to newcomers, but fortunately it's very easy to send messages to the log. It can be done with code like this:

NSLog(@"example message");

(These messages should appear in the main Xcode window, in the very bottom.)

Enabling localStorage

It seems that, by default, localStorage will not persist data in an embedded WebView as expected. Here's how to enable it:

In Xcode's left sidebar, drill down into WebViewExample / Classes / WebViewExampleAppDelegate.m.
Add this code to the top of the awakeFromNib method: WebPreferences *prefs = [webView preferences];.
Then add this line just below that: [prefs _setLocalStorageDatabasePath:@"~/Library/YourProjectName/LocalStorage"];. (Be sure to use the name of your project intead of "YourProjectName".)

It's important to name the folder that localStorage saves to with the same name as your application (eg, Onslaught! Arena saves to "~/Library/OnslaughtArena/LocalStorage")! Apple will reject your app if it puts data somewhere unexpected.

Note: this may generate the warning "'WebPreferences' may not respond to '-_setLocalStorageDatabasePath:'".

Summary

Your application should now meet the bare essentials for submission to the Mac App Store, and you could be reaching a wider audience with your HTML5 app in no time (pending Apple's approval …). Did I miss anything you were hoping to know about? Any steps not work for you? Please let me know.

Bonus: if you want to see what kind of quality you can get out of a native OSX HTML5 app, we just dropped the price of Onslaught! Arena in the Mac App Store to $1.99! See HTML5 in action for yourself.

No more foolin' around

2011-04-02T00:00:00-07:00

We've reverted our April Fool's version of Onslaught! Arena back to the game we all know and love. Chrome Web Store users should see the game update in the next day or so.

We enjoyed the Super Meat Boy mode so much that we've left it in game, accessible via a keyboard code. Simply type MEAT anytime during the game to play as Super Meat Boy!

Additionally, the game still saves every wave now. We realize the game is extremely difficult so now attempting the Dragon or Beholder over and over until you get it right won't be quite as punishing! :)

We gave away Onslaught! Arena on Mac App store for free yesterday as well and 646 lucky users snagged a copy! If you liked it please leave a review!

Thanks everyone!

Onslaught! Arena v1.2.25 is FREE (today only)

2011-04-01T00:00:00-07:00

Good news, everyone! We just launched a big update to Onslaught! Arena, and to celebrate we're making it FREE for today only in the Chrome Webstore!

Based on market research findings, this update includes the following changes:

Graphics update to make main character more likable.
Title change to something more recognizable.
You die in only one hit (but your game is saved after each wave).

It's normally $1.99, so get it while it's hot! I mean, free and stuff!

Get Onslaught! Arena FREE

What we need to get our HTML5 game on iPad (Speed)

2011-03-17T00:00:00-07:00

One of our attractions to HTML5 is its portability. Our game Onslaught! Arena began as a browser-based app but has since moved into native land by embedding a WebKit Web View into our OSX app.

Given how easy it was to get our game onto the Mac App Store, the next obvious question is, "What about iPad?" We've been exploring it and are sad to report that we've hit a brick wall of sorts.

HTML5 Audio is a disaster on iPad; only one sound file can play at a time, in addition to latency and other issues. Not to pick on iPad or Apple -- HTML5 Audio sucks all around. The good news is that it was pretty easy to hack in a fix on iPad and make audio work beautifully.

The trick to getting responsive audio on iPad via HTML5 was to create a bridge from JavaScript to Objective-C. I'll post a more detailed tutorial in the future (here's our RSS feed to get updates), but it looks something like this:

- (BOOL) webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
	
	NSString *requestString = [[request URL] absoluteString];
	NSArray *components = [requestString componentsSeparatedByString:@"://"];
	
	if (([components count] > 1)
		&& [(NSString *)[components objectAtIndex:0] isEqualToString:@"jsbridge"]) {

		if ([(NSString *)[components objectAtIndex:1] isEqualToString:@"battle_music"]) {
			// Play battle music here
		}
		return NO;
	}
	
	// Let any other request through
	return YES;
}

Then in your JavaScript you'd send a request to "jsbridge://battle_music";. The device detects this request, parses it, plays an audio file and cancels the request.

So there's a workaround; audio is not the bottleneck. The problem with getting our game onto iOS is speed. As you can see in some of these screenshots of our game running in the iPad simulator, the frames per second (FPS) is severely lacking.

Movies play at 24 FPS, TV plays at about 30 FPS. Modern video games probably run at 60 FPS or more. While taking screenshots of Onslaught! Arena, I did notice it can run as high as 59 FPS, but it's bursty and doesn't last. Most of the screenshots are more depressing, showing the game running at about 7 FPS, which is completely unplayable for an arcade game like ours. Plus, as you can see I've removed the extra pixel drawing of the arena itself: the screen is just plain black and it's still unacceptably slow.

This speed problem is the only thing keeping us from having a playable game on any iOS device. So Apple, Google, all of you WebKit supporters and browser makers: please make things run faster. Lotta love for ya, we just want more speed!

How to embed HTML5 into a native Mac OSX app

2011-03-15T00:00:00-07:00

Our game Onslaught! Arena was only available on the Chrome Webstore when we first launched it. We recently announced that we had also launched the game on the Mac App Store, using the exact same source code. Isn't HTML5 awesome?

Many of you expressed interest in how to embed a WebView into a Mac app, and as promised, here's a detailed tutorial.

Download Xcode onto your Mac. I was able to download it from Apple but it's also in the Mac App Store for $4.99, so your mileage may vary.
Run Xcode. Mine is located in /Developer/Applications/Xcode.app.
Make a new project. This can be done by using the menubar: choose File / New Project... / Mac OS X / Application / Cocoa Application / Choose ... then select the folder to save your project into. I'll use WebViewExample as the project name in this tutorial (but you can use whatever you want).
In your Xcode window, under Overview / Groups & Files, expand WebViewExample / Frameworks by clicking the arrow icon.
Right-click Other Frameworks and select Add / Existing Frameworks... / Webkit.framework / Add.
On the same level as Frameworks, expand Resources by clicking the arrow icon.
In a Finder window, locate your HTML5 folder (the folder containing your .html files, etc.) and drag it into this Resources folder in Xcode. Make sure to choose Create Folder References for any added folders.
On the same level as Resources, expand Classes by clicking the arrow icon.
Select WebViewExampleAppDelegate.h which will open it for editing in the right column.

Edit the file to look like this:


#import <Cocoa/Cocoa.h>
#import <WebKit/WebKit.h>

@interface WebViewExampleAppDelegate : NSObject  {
	NSWindow *window;
	IBOutlet WebView *webView;
}

@property (assign) IBOutlet NSWindow *window;
@property (nonatomic, retain) IBOutlet WebView *webView;

@end

Now select WebViewExampleAppDelegate.m for editing. Edit the file to look like this:


#import "WebViewExampleAppDelegate.h"

@implementation WebViewExampleAppDelegate

@synthesize window;
@synthesize webView;

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
}

- (void)awakeFromNib {
	NSString *resourcesPath = [[NSBundle mainBundle] resourcePath];
	NSString *htmlPath = [resourcesPath stringByAppendingString:@"/htdocs/index.html"];
	[[webView mainFrame] loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:htmlPath]]];
}

@end

Note: in the line NSString *htmlPath = [resourcesPath stringByAppendingString:@"/htdocs/index.html"];, change the string "/htdocs/index.html" to your game's .html file.

Under Groups & Files, select WebViewExample. Then, in the list to the right under "File Name", double-click MainMenu.xib (English). This will open Interface Builder (which should be located in /Developer/Applications/Interface Builder.app).
In Interface Builder, find the Library window and select the Objects tab.
Scroll down to find a row labeled "Web View - A Coca WebView" (hint: you can type "webview" into the text box at the bottom of this window to filter the results) and drag it into the WebViewExample window. (another hint: you can resize it and its containing window to whatever sizes you want. More info on this in future tutorials.)
Find the "MainMenu.xib - English" window and double-click Web View Example App Delegate.
Find the tools window (the one with six icons at the very top, it should be labeled "Web View Example App Delegate Identity"). Switch to the "Connections" tab (by pressing the second icon from the right -- it's a blue circle with a white arrow inside). Look under "Outlets". There should be only one row labeled "window". You'll come back to this in a moment.
Go back to Xcode and press the Build and Run button (or press command+return on your keyboard).
Go back to Interface Builder. In the "Outlets" section from before, you should now see a row labeled "webView" with an empty circle to the right of it. Press and hold your mouse down inside this empty circle. A blue line should begin to follow your mouse. Drag this blue line into the WebView object that you dropped into the WebViewExample window earlier. (When you hover over it, it should highlight in blue.) Release the mouse button and a connection should be established (this enables communication with your WebView).
Save the file (File / Save or command+s).
Return to Xode and Build and Run. You should see your app running inside the window that opens.

This example project is available on our GitHub page (I've included my old game Spacius! as an example). You can also download the generated WebViewExample app directly.

I'll post another tutorial soon on how to make a more complete app (EDIT : now available here!), including adding icons, enabling localStorage and building a bridge from JavaScript to Objective-C. Follow us on Twitter to get notified when we publish that tutorial.

Could you get it to work? Any steps I could change to make things easier to understand? Please let me know in the comments.

An HTML5 game in the Mac App Store

2011-03-13T00:00:00-08:00

HTML5 is the development buzzword of the moment. It's the "ajax ninja" of the last few years, so naturally it comes with its fair share of skepticism. Indeed, many have been writing about its seemingly never-ending spec, inconsistent implementations by browser makers, and even its inferiority to native apps. All are valid arguments against betting a real business on HTML5.

However, here's a hard example of why you absolutely should consider serious development in HTML5. In December of last year, we launched our little pure-HTML5 game Onslaught! Arena in the Google Chrome Webstore. Sales could be better, sure, but we also just launched the exact same game in the Mac App Store. The code is identical with negligible development time required to port it over to a completely different platform.

Think about the business case for that. Normally it would take considerable resources to port a game to such a different platform. We know our game isn't exactly a AAA title, but if programmed from the ground up in Objective-C, our best guess is it would take a few months to develop. That's time that we can now spend on content updates or even a sequel.

How was it done? We just embedded a WebView in a native Cocoa app using Xcode. Is it inferior? Not noticeably so. On my MacBook Pro, the Chrome Web Store version ranges from about 50-250 FPS (frames per second) depending on how many monsters are on the screen. On the same computer, the Mac App Store version ranges from 30-100 FPS. (You can see this for yourself: type "lddebug" while in-game to see debug information.) And despite nasty HTML5 audio issues, sound plays great in both versions.

Surprisingly, the Chrome version runs faster than the native Mac version. While Safari and Chrome are both using WebKit as their rendering engines, Chrome is likely faster because V8 has wicked speed and its canvas rendering is hardware-accelerated.

Either way, it runs great on both platforms and required almost no dedicated development time to port. If you're a developer, you should find this exciting. We certainly do!

Since you made it this far, you might like to read "Our first week in the Chrome Webstore: the numbers" if you're into graphs and sales numbers (and who isn't!). If you'd like to learn more about our HTML5 development, including a tutorial on how to embed a WebView into a native Mac app, follow us on Twitter; we'll be writing about that soon.

See Onslaught! Arena in the Mac App Store.

Onslaught! Arena is free on Valentine's Day

2011-02-13T00:00:00-08:00

Love it or hate it, Valentine's Day is a day about expressing love ... and giving gifts! To celebrate and to show our love for the indie gamers out there, we're making Onslaught! Arena FREE on the Chrome Webstore for today only.

Normally $1.99, this is a great chance to save some cash for your sweetheart (or hey, for yourself!) while still getting to have some retro fun. So please help spread the word on Twitter and Facebook and happy monster slaying!

Get Onslaught! Arena FREE

Happy Valentine's Day!

Onslaught! Arena v1.2.8

2011-02-12T00:00:00-08:00

We just pushed a minor update to Onslaught! Arena on the Chrome Webstore. This quick update includes:

Removing the broken High Score table.
Supporting the "k" key to switch WASD and arrow keys for controls (for lefties!).
Supporting the "html5" keycode to unlock a (visual only) HTML5 shield. Help spread HTML5!
Various bug fixes and tweaks.

While this is just a small release, we've got new content in the works, including new weapons, new monsters, and a special promotion for Valentine's Day (this upcoming Monday). So stay tuned for more updates!

Details about our next game Burn Tactics

2011-01-16T00:00:00-08:00

Update: we had to change plans, so Burn Tactics is no longer under development.

We recently started developing our next game, tentatively called Burn Tactics. The concept is a turn-based medieval fantasy strategy game where players control a vengeful dragon who's intent on burning down villages and seeking havoc on the kingdom.

While we're still very early in development, we've already made wireframes for every screen in the game and have figured out how the interface will flow in its entirety. As you can see from the included images, we'll be periodically uploading (really rough and ugly!) screenshots of our progress. We even have some game code written; we're using the impact HTML5 game engine and are so far really liking it.

Why we chose to work on this game

We've had probably a dozen ideas for what to work on next including puzzle games, RTS games, or even a sequel to Onslaught! Arena. Among all these directions we could go, we decided to work on Burn Tactics for the following reasons:

Accessibility

Though many players are enjoying Onslaught! Arena, we've also heard that some of them are turned off by certain features, including:

Retro look and feel: the 8-bit graphics and sound are very appealing to some players (including us!) but many aren't familiar with and/or nostalgic about NES-era games or just think it's overplayed as an art direction.
Difficulty: very difficult, requires quick reflexes and excellent dexterity. (Even our girlfriends don't want to play it because it requires twitch skills they don't enjoy learning and so never acquired!)
Controls: we've heard many complaints about all kinds of problems with the controls. They're too complicated (with mouse and keyboard options), too buried (not exposing all keyboard shortcuts in the UI) and not customizable (giving non-QWERTY users a headache). Burn Tactics will have a simple click/touch-only interface.
Sluggish performance: Chrome users currently have hardware-accelerated graphics in Onslaught! Arena, which certainly helps, but tons of monsters and weapons on-screen can be very taxing on older computers and browsers (making it easy to die and very frustrating).

Burn Tactics is a concept that shouldn't have these problems, so hopefully it'll appeal to a larger audience of gamers.

Small in scope

As you may have read before, we both have bad habits of letting our game concepts explode into unclimbable mountains. Given that, our mantra for Burn Tactics is:

Ridiculously simple turn-based strategy game.
Keep it simple.
Polish, polish, polish.

Mobile-friendly

While we would love to get Onslaught! Arena onto mobile platforms such as Android and iPad, there are many hurdles and in some cases, brick walls. Conversely, Burn Tactics is being designed from the ground up to make it feasible to get onto mobile/touch devices. This is great because releasing Onslaught! Arena onto these devices has been one of our most common requests.

We're still working on Onslaught! Arena

We've got some issues we're looking into fixing and we're also trying to get Onslaught! Arena into the new Mac OSX App Store.

Onslaught! Arena now on sale for $1.99

2011-01-07T00:00:00-08:00

Happy new year! Our first game Onslaught! Arena launched exactly one month ago today, so we're pretty excited about this year. To welcome 2011, we're having a 60% off sale! You can buy Onslaught! Arena now from the Chrome Webstore for just $1.99.

We've started early production on our next game (to be announced soon!) but we are also still listening to your feedback and fixing any issues that come up on our support forum. And as always, please feel free to contact us with any comments or questions.

Thanks for your support!

Reviews of 6 Screen Recording Apps for OSX

2010-12-31T00:00:00-08:00

I've been wanting to make some more videos of Onslaught! Arena (and other prototypes we've got cooking) so I wanted to get a really good screen video recording app for Mac OSX. But before buying utility software I like to do a little research to make sure I get the one best taylored to my needs.

Desired features

Since I'll primarily be recording gameplay from our games, I have particular needs in screen recording software, including:

Easily capture video -- with a really simple and noninvasive interface.
No noticeable CPU hit -- I had issues with Snapz Pro slowing down my computer when I was recording the How to beat the Green Dragon video, so I didn't include it in this research.
Ability to record audio as well as video -- ideally from the built-in computer's microphone and what's coming out of the speakers.

Which applications did I review?

These are just some quick reviews (one of them very quick!), but in most of them I've included screenshots and actual video recorded with the application. Here they are in the order I reviewed them:

Camtasia ($99)
CaptureIt! ($29.95)
iShowU HD Pro ($59.95)
Screen Mimic ($65)
Screenium ($29)
ScreenFlow ($99)

Camtasia

First I looked at the free trial of Camtasia (full version: $99.00 USD) and had the following thoughts:

Nice that it's available for PC and Mac.
Had to install something called Soundflower to record audio from the built-in microphone. That's irritating; I'd much rather it be bundled with the software I already had to install. (Note: looks like most of these apps also require SoundFlower, so not a huge ding against Camtasia.)
Confusing interface. Had to start recording to tell how to set the recording region.
I don't dig the interface. I'd rather see native OSX checkboxes and other widgets than a bunch of custom graphics.

Here's a quick video I recorded with Camtasia. You can hear both the game's audio and my voice clearly:

Overall seems pretty solid and I was happy with the video I recorded. I couldn't find a good way to switch between the microphone VS. speaker audio recordings in the editing software it came with. But I guess that would mostly be done in something else like iMovie anyway. I'm not sure that Camtasia is the best bang for the buck considering that its price is up to three times that of some of its competitors.

CaptureIt!

Next I tried CaptureIt! (full version: $29.95 USD) and I was immediately confused. The moment I ran the application my entire screen faded a bit and a toolbar appeared in the bottom-left corner of my desktop. (You can see what I mean on the product page.)

I quit, then reopened the application to give it another shot. This time I figured out how to record video (which took some digging), but I couldn't for the life of me find where it put the movie file. Since it clearly wasn't as intuitive and easy to learn as I wanted, I wrote it off as a failure and moved on to the next application.

iShowU HD Pro

iShowU HD Pro's full version is $59.95 USD with a fewer-features version available for $29.95 USD. I downloaded the demo, gave it a go, and had the following thoughts:

An update was required the moment I started the application. While it's nice that it has an automated update flow, I'd rather they had included the update in the file I had just downloaded!
I liked the option to show or hide the mouse icon during recording. (Turns out this is a pretty common feature.)
Would be nice to see meta data when selecting the region to record (such as width/height and X/Y coordinates). This is epecially important since my most common use-case will be wanting to record the exact gameplay region (eg, 1024x768 pixels).
The interface (see screenshot above) felt too large and clunky for my needs. I don't really want to spend much time with whatever screen-capturing software I end up purchasing; I want it to be largely invisible and just quickly/easily record videos then disappear.

It was really easy to record a test video:

iShowU HD Pro is not bad but I think the choice in price might hurt its ability to sell copies. I definitely knew I'd need the "Pro" version since (if I understood correctly) the limited version for 50% less doesn't record audio. So that kind of made me feel like I wouldn't be getting as good a deal (it's funny how pricing works, isn't it?)

Screen Mimic

Screen Mimic ($65 USD) was next on my list and I had the following thoughts when using it:

Simple and noninvasive interface.
I like how it displays the selection resolution (eg, 640x480 pixels).
Very useful that you can export as .swf! Last time I checked I couldn't find anything to easily convert a movie file to flash on a Mac, so I found this feature extra appealing.

The recording quality is pretty good too, as you can see in this video I made using the demo:

My favorite feature of Screen Mimic is that it does a great job of staying out of your face. At first it's just an icon in your menu bar. Click it, and the only options displayed are "New Recording" and "Pause Recording" (disabled). Very minimal and definitely appreciated. On the downside, its has fewer options than the competitors in its price range. Based on the other software with similar features I'd say it should be priced about half of what it is.

Screenium

Next up I tried Screenium ($29 USD) and immediately liked it. The demo is fully-featured except it limits recordings to 30 seconds. Other software in its category might remove features and/or add watermarks to exported videos. Giving me full access to all normal features allowed me to see exactly what I'd be paying for without any uncertainty. Good stuff.

Recording and exporting this video was a breeze:

I have almost nothing but good things to say about Screenium:

Really nice interface.
Love the ability to select which audio to record (system audio and/or built-in microphone).
Really cool that you can include your built-in camera to the screen capture (see lower-left-hand corner in the video)!
Tons of options regarding Hotkeys.
Love the simplicity of the export feature; you can just press "OK" to export immediately, or dig in and get pretty advanced.
So cool that you can type in exact width/height and X/Y coordinates! As an anal programmer this optional granular control is wonderful.

It's difficult to say why, but I also felt that Screenium had excellent usability. All the options were easy to find and in the right place. No task was a chore.

ScreenFlow

After trying ScreenFlow ($99 USD), I had the following thoughts:

Immediately got a translucent window with some recording options. Didn't see any opacity settings; wasn't digging the pre-recording window.
Upon clicking "Record Computer Audio," was disappointed to be prompted to "Install Audio Driver."
The first test video I recorded only captured video from my laptop screen and I couldn't find a way to record from the external monitor instead.
Can also include built-in camera recording in your capture, with many more features like sizing, rotation and position. Very cool, but realistically would probably never get used.
Has tons of advanced post-capture editing features such as screen stretching and rotating (but I'd rather handle these effects in a different application like iMovie).

Videos (from both the screen and built-in camera) are easy to record:

I found ScreenFlow's pre-recording interface to be too minimal and its post-recording interface way too involved. The quality feels pretty good, and even at almost $100 the value might be there for some users. But I'm in the market for a simple screen recording app, so as long as it does what I need, the fewer options the better.

Bonus: QuickTime

Edit 1/2/2011: I gave QuickTime (v10.0) a try after reading that it was available for OSX10.6+. While the price tag (free!) is obviously great, I noticed a CPU hit making my gameplay recording sluggish. I also saw no options for recording only a selected region of the screen. These reasons made it a dealbreaker, but it might be a great free solution for you!

Summary

Overall I was the most impressed with Screenium. It has a wonderful interface, is easy to use and powerful enough for my purposes (and being the least expensive is a nice coincidence!). If Screenium wasn't on the plate, I guess my second choice would have been Screen Mimic. It does very little but has pleasant controls and is also simple to use.

Do you have your own experiences with screen recording software on Mac OSX? Is there any great software out there that I missed?

Results of our PR outreach

2010-12-26T00:00:00-08:00

New games are released every single day, often from big publishers or known developers with long track records of successful titles. So getting the attention of potential gamers who might like to play our little indie game is difficult to say the least.

Given a small to nonexistent marketing budget, we think the key is to release the best product you can, be really noisy about it, and attempt to enlist the help of popular gaming news outlets to reach gamers. So we put together an official press kit with a press release, images, screenshots, etc., and tried contacting about three dozen different gaming news organizations. Here we've compiled the responses (or lack of responses) we received.

Note: Many of these video game news organizations are constantly inundated with information and requests for reviews and we understand that they couldn't possibly respond to everyone (especially small potatoes like us). Either way we thought the data might be useful to other indie developers or interested parties.

Responded and posted

These are the fantastic, extremely helpful people that not only responded to us but were good enough to help in our attempt to reach gamers who might enjoy Onslaught! Arena.

BoingBoing - We got the idea for the first iteration of Onslaught! from BoingBoing's Games Inspired by Music contest. So we thought it was particularly awesome of them to post about our game and tweet it to their impressive 65,000+ followers.
GamesRadar - My long-time friend Brett wrote about the Chrome Webstore, complete with an awesomely huge sceenshot from Onslaught!. He also mentioned the game on his popular TalkRadar podcast. Very cool!
Indie Game News - We were really happy to see two stories posted about Onslaught! -- both a our press release and quick review of the game.
One Video Game a Day - Dusan was awesome enough to find and tweet about our earlier demo of Onslaught!, and that didn't stop him from doing it again about the full version of our game. Very cool and much appreciated!

Responded, nothing posted yet

These kind folks have responded but we haven't yet seen anything posted about our game. We have no complaints or anything -- the holidays are especially busy and we were grateful just to hear back. (And we'll be sure to update this list once the posts are up.)

2girls1game -- Edit: 1/8/11 -- Review here: check out onslaught! arena.
Casual Girl Gamer (extra bonus points for finding and posting about a very early version of Onslaught!)
Crudepixel -- Edit: 1/8/11 -- Review is here.
DIYgamer -- Edit: 12/28/10 -- Review is here: Bring on the Onslaught!.
Mana Pool
Play This Thing!
Save Point

No response

Again, we don't have any delusions -- we know we're a tiny, unknown developer and some organizations are too busy to respond to us or spend their time on our little game. So it's cool and all that, but for data's sake here's the list of who we contacted and never heard a peep from:

About: Game Center
ApertureGames
Casual Gamer Chick
Destructoid
Gamasutra
Game Rant
GameSetWatch
Gamezebo
Gaming Bits
Joystiq
Kotaku
Rock, Paper, Shotgun
tsumea
Worlds in Motion

No response, disappointed

Now, I stand by what I said earlier about understanding that folks are busy and we're aware of our minimal place in the industry. But for one reason or another we were really hoping on hearing back from the following list of organizations and were disappointed not to:

gametunnel
Gamer Limit
IndieGames -- Edit: 12/28/10 -- Heard back in the comments. Thanks Mike!
indienerds
IndieReview
Mozilla (they're not a gaming news site but they've got an HTML5 games contest going on right now and have been tweeting about other games so we were hoping for at least a quick tweet about ours)

So in some cases kind of a bummer, but no hard feelings and we still love you guys!

Summary

For a brand-new developer, I'd say our expectations were about met (save for the prior list). It looks like a little more than 8% of those we contacted have posted about our game, and we heard back from about one third, which is a good start. Here's to hoping that next time around we'll have a bigger, better game and will be fortunate enough to reach a bigger audience!

Our extra special hats off to Google for being a huge help and an amazingly supportive contact. They even featured us on the Webstore homepage! So awesome.

Did we miss anyone? This data is really hard to keep track of! If we messed up anywhere above, please do let us know and we'll be happy to amend the details (and thanks for your support!).

Update

Edit: 12/27/10 -- After having seen this article we've heard from a few awesome organizations such as IndieGames, Indie Game Reviewer and Nukezilla. Thanks for the support!

Edit: 2/15/11 -- Overlooked a retweet by OverClocked ReMix. Thanks Andrew!

Our first week in the Chrome Webstore (the numbers)

2010-12-14T00:00:00-08:00

Our new game Onslaught! Arena launched mid-afternoon a week ago today in the new Google Chrome Webstore. This is a brand-new platform from Google and many people are curious (if not excited) about it, so we thought we'd share our numbers from the first week. Note: We got this data from a combination of Google Analytics, Google Checkout, and our own Licensing API caching system.

First up is the number of unique visitors to our Chrome Webstore page:

Our strongest day was easily Wednesday with 7,750 uniques and our weakest day was just yesterday (Monday) with only 1,059. These numbers do seem a bit low for a new product launched by Google, but we are just one game featured in a big store full of apps.

Next up is the number of new players of Onslaught! Arena. These are unique users who visited the play Onslaught! Arena page and logged in with their Google accounts.

So these numbers range pretty wildly, from 863 players down to just 96. Lastly, and I'm sure most interestingly, are the number of game sales.

So our best days have seen only 5 sales, but we've had at least one purchase every day. And you may be wondering what our take is out of the $4.99 price tag. After Google's transaction fees, we get $4.46 per transaction. So given our 21 sales so far, that makes for a grand total of $93.66 in the first week. These comparatively low numbers make some of the press we've seen kind of humorous:

Onslaught Arena has almost 1,300 users, which means its developer has earned about $7,000 in the first week.

That article is inaccurate by a large margin. What that says to us is that the "users" and "installs" numbers of the Webstore pages are confusing. On our app's page, the numbers displayed are currently 2,337 users - 3,200 weekly installs. We're not sure exactly what those numbers mean or where they came from, since they don't easily mesh well with the numbers we have.

So we won't exactly be buying yachts anytime soon. But I'll tell you, after failing for so long to publish a "real" game, it feels good to finally be able to call ourselves professional game developers, even if on a tiny scale. (And the game is at least paying its own hosting bills at the moment.)

What do you think? Surprised? Not surprised? Do you have your own numbers from the Chrome Webstore that you'd like to share?

App Engine and Chrome Webstore Issues

2010-12-12T00:00:00-08:00

Quick background

We recently launched Onslaught! Arena in the Chrome Webstore. We're using App Engine (Python) as our backend and we are integrated with Google Checkout's Webstore Licensing API.

So first off, we messed up: right when we launched, there was a bug in our app that was causing the game demo to serve even to users who had successfully paid for the game. Firstly we'd like to apologize to those users who were affected. We're happy to say that this bug got fixed the night of release.

The troubles we were (and are) having

When we first launched, the Licensing API calls were failing. We fixed this, which caused the next two issues:
Some users are getting served error pages instead of the game itself.
Our app is asking for access to users' email addresses, which understandably makes them uncomfortable. (This is particularly frustrating to us because we neither need or want email addresses.)

Licensing API calls failing

So on the night of the day we launched, we noticed that users who had purchased the game were still getting served the demo. That's awful! Nobody spotted it because we obviously had access to the game ourselves, and we were also allowing Google internal beta testers access (so they couldn't have found this bug either). We put the fire out quickly (by about 1am PST) and it looks like only 2-3 users even noticed, which is good. Our apologies to any users who were affected.

Here's why it was happening. Our Python calls to user.federated_identity() were returning None on production, invalidating our Licensing API calls (since the API requires OpenID URLs). We feel that this was really easy to miss for the following reasons:

Dev/local instances of App Engine do not support OpenID URLs at all (this used to be a documented exception, which I can't find anymore on the Google docs page). This makes debugging a serious time sink because we must push to production to test any fixes!
The example code (this must have also been removed because I can no longer find it) suggested the use of user_id = user.federated_identity() or user.user_id() which can be tricky to debug.
Enabling OpenID support is experimental.

Once we enabled the "Administration / Application Settings / Authentication Options / (Experimental) Federated Login" option from our App Engine dashboard, user.federated_identity() was returning the OpenID URL as expected and the Licensing API calls started working again.

Server Error pages

Enabling Federated Login has caused some other pretty nasty issues. One is that some users are getting stuck into redirect loops, ultimately resulting in error pages. We've spent a ton of time debugging, researching and otherwise trying to figure out a solution to this, with no real solid solution. There are pretty good examples of work-arounds, but they're all kind of hack jobs and still have edge cases that result in the same error. While I freely admit I'm new to both Python and App Engine, I do not currently see a bulletproof solution to this without Google fixing their OpenID implementation.

This is a serious problem and if you have experienced this error in our game yourself, we've very sorry. We're trying really hard to find a fix.

Asking for email addresses

The other issue that came up after enabling Federated Login is that the application now asks for users' email addresses when they authenticate with the app. We've seen a bunch of complaints about this in the reviews and aren't entirely sure what to do about it yet. We do not want, need or use email addresses so we'd ideally like to skip this step altogether.

Conclusion

Many of these platforms and APIs are brand-spanking-new, so problems can be expected. But some of these issues are serious showstoppers and are causing awful user experiences and seriously depleting our already limited development resources. If you have any thoughts or ideas on solutions, we're all ears! And again, if you've been affected by any of our issues, we're sincerely sorry.

Announcing Onslaught! Arena for sale in the Google Chrome Webstore!

2010-12-07T00:00:00-08:00

Lost Decade Games is proud to announce its first release: Onslaught! Arena, a medieval fantasy arcade shoot 'em up. Built using HTML5 technologies, Onslaught! Arena is now available for sale in the Chrome Webstore via Google Checkout.

About Onslaught! Arena

Originally created for the Games Inspired by Music contest from Boing Boing, Onslaught! Arena began as a quick two-week project with programming by Geoff Blair, art by Matt Hackett and music/sound effects by Joshua Morse. Over the next few months, Geoff and Matt continued to tweak and improve the game and stuff it full of content, including:

50 waves of combat
Over a dozen ferocious monsters
More than 6 types of weapons
Ability to continue from a saved game
Online high score table

About Lost Decade Games

Lost Decade Games was founded by Geoff Blair and Matt Hackett in September of 2010. Combined, Geoff and Matt have over 20 years of programming and design experience. Our goal is to create engaging, fun HTML5 games with a focus on gameplay and strategy.

About the Chrome Webstore

The Chrome Webstore is "an open market for apps." Released by Google in December of 2010, the webstore enables users to easily discover and install applications built for the web, with the option to pay for premium software via Google Checkout.

Obfuscating JavaScript with Closure Compiler Advanced Optimizations

2010-11-17T00:00:00-08:00

While working on our upcoming game, Onslaught! Arena, we wanted to obfuscate the JavaScript code as much as possible. Using tools like YUICompressor and Google Closure Compiler (with Standard Optimizations) just weren’t enough. Luckily, Closure Complier has an ”Advanced Optimizations” mode. This mode will really make your JavaScript gross and unreadable!

Here are some cases to watch out for along with some tips for those trying to make their JavaScript as unreadable as possible:

Don’t access object properties as string literals

Using Advanced Optimizations has its pitfalls. Because of it’s super aggressive renaming, Closure Compiler will break your code if you access object properties using string literals. For example:

var thing.stuff = {
	foo: 10,
	bar: 20
};

// This will break after Advanced Optimization :(
var foo = thing["stuff"].foo;

Closure will rewrite thing.stuff as something like a.b and accessing a["stuff"] isn’t going to work.

Don’t use string literals

Closure Compiler won’t obfuscate string literals for obvious reasons so just stay away from them as much as you can! Here’s an example:

// Bad. Can't obfuscate well.
myObject.state = "wounded";

// Good!
var States = {
	Wounded: 0,
	Stunned: 1,
	Attacking: 2
};
myObject.state = States.Wounded;

Instead of seeing a.b = "wounded"; in your compiled code, you’ll get something like a.b = c.d;.

Stay away from built-in JavaScript object property names

If you want to achieve maximum obfuscation, don’t use built-in JavaScript object properties such as .position, .left or .width in your custom objects. Here’s an example:

// Bad; "type" and "position" won't be obfuscated.
myObject.type = 1;
myObject.position = {x: 0, y: 1};

// Better; "thing" and "coords" will be obfuscated.
myObject.thing = 1;
myObject.coords = {x: 0, y: 1};

The list of properties such as in this example is pretty long and many of them are common, sensible names for properties. I’m certainly not recommending that you stop using all of them. Find the balance that makes sense to you but keep in mind the more you can refrain from using these properties, the more obfuscated your code will be.

Here’s an (incomplete!) list of properties that won’t be obfuscated:

add, canvas, create, data, direction, display, execute, height, history, images, layers, left, load, loop, map, normalize, now, paused, play, position, reset, scale, setInterval, setTimeout, size, start, stop, style, top, type, update, view, width, x, y

These are the lessons we’ve learned while obfuscating our code as much as possible to help protect our work. Can you think of any additional best practices to assist in this process?

Onslaught! Arena 1.0 Gameplay Teaser

2010-10-16T00:00:00-07:00

Onslaught! Arena 1.0 is nearly complete! The latest version of the game is chock full of new enemies, weapons and traps! Take a look at the video below for a sneak peek at the challenges which await you in the arena!

Onslaught! Arena will be launching with the Google Chrome Web Store later this year. The full version of the game will be purchasable from the Chrome Web Store via Google Checkout and of course we'll have a free trial version available so you can get a taste of the fast paced action!

What to do when your game is too easy and too hard

2010-08-29T00:00:00-07:00

We've been preparing to release version 1.0 of our game Onslaught! and part of that process has included looking wherever we can for feedback on how to improve the game.

Luckily for us, Onslaught! has been talked about a little bit on the 'net (especially on /r/WebGames; thanks Reddit!) so we've been able to dig through some players' comments. And we've noticed two recurring themes:

It's too easy

It's too hard

So, it's too easy AND too hard?

If the feedback was consistently that Onslaught! was too easy, here are some easy tweaks we could have made to help make the game more difficult:

Increase the number of enemies.
Increase enemy speed.
Increase enemy damage.
Decrease the hero's damage.
Decrease the hero's health.
Decrease weapon drops.

Likewise, we could have reversed any of those rules to make the game easier. But what is a game designer supposed to do with conflicting requirements?

The difficulty curve

The current version of Onslaught! has a very simple algorithm for increasing difficulty. There are seven waves, the final wave consisting primarily of the dragon boss. After defeating this wave, the player is thrown back to the beginning of the loop with the number of enemies increased steadily by 50% of the first wave (so it would go: 10 bats, 15 bats, 20 bats, 25 bats, etc.).

According to Google Analytics, Onslaught!'s 10,000+ players have played the game for an average of 32 seconds each. We mentioned previously how we had failed to make a 30 second game, and for the final release of Onslaught! we decided it would be good to expand on that idea.

What we were wanting instead of a steady climb in difficulty like this was an easy beginning with a sharp increase in difficulty. So after the first couple of wave cycles, the game should rapidly increase in difficulty, providing a challenge for hardcore gamers.

The below graph shows the previous difficulty curve (v0.2, in blue), and the difficulty curve we are shooting for in v1.0 (in red):

What we're going to do and why

This is going to be a difficult (but fun!) problem to solve. Here's what we have in mind:

We're adding four new enemies: flaming skull, flying imps, wizards and sandworms (each with new behavior). These enemies will increase the length of gameplay (giving us room to play with difficulty) as well as mixing up the player's strategy with varying enemy behaviors.
Players will battle two new classic D&D-style bosses (guess what they are!). The first will be relatively easy and the second will be extremely difficult.
After completing a cycle of waves, traps will begin to appear in the arena! The number of traps will steadily increase as the player completes cycles. They do damage to the player when touched, so this will limit the area the player can navigate.
Complete weapon overhaul: this includes balancing current weapons as well as adding new weapons (such as a bouncing battle axe and flaming sword that leaves a trail of fire in its wake)!
For the Freeplay awards, we did two things to improve the 30 second experience: we replaced the default weapon (rocks, which are boring) with swords (which are more fun!) and we provided the player with two starting weapons. These weapons were randomly generated, so players were able to reload the game in order to get whatever weapons they wanted (for instance, the overpowered trident). For v1.0, we're going to provide set weapons to balance this out (probably knives and fireballs).

We've got these improvements and many others in mind as well! Our hope is that these gameplay tweaks and content additions will make the game more enjoyable for both casual and hardcore players alike. What do you think? Is Onslaught! currently too easy or too hard?

Puzzle Punk -- a Postmortem on a Failed Puzzle Quest Clone

2010-08-14T00:00:00-07:00

My vicious cycle

Something had to give. I'd been trying and failing to make my game idea a reality for years and years. The vision was simple: an online, multiplayer retro RPG. I guess the term would have been MMORPG but I'd been working on various implementations of this project long before the days of World of Warcraft.

I remember being a kid and longing to play games in the time of Shining Force and Secret of Mana. I had that same longing, but this time it was to make my own game.

Eventually I started referring to my game project as Valadria. Sure, I'd go off on tangents and I'd sometimes work on other little crappy games, but I'd always come back to this core retro RPG concept.

My last iteration of Valadria is up on App Engine. It's a very early prototype, but it's playable. I've also put the source on GitHub (something I wish I'd been able to do with each of my iterations over the years).

So I had a pretty good idea about the game I wanted to build, but I'd been working on it for years with very little to show for it. Here was my vicious cycle:

For some unexplainable reason, my dream game would pop into my head, and I'd get motivated.
I'd scrounge up freetime between work, school, social life and gaming, and I'd put whatever knowledge I had together towards making the game.
Eventually (and this was inevitable), I'd hit a hurdle and stop working. Graphics, music, networking code, whatever. Something would kill my motivation, most often the hopeless feeling of knowing I'd never finish what I'd started. This step felt like getting fired or dumped; it was heartbreaking.
Rinse, repeat.

And it should be noted that every time I went through the first step, I'd start from scratch. It had been months or years since the last iteration, so the code was gross and the ideas were stale. I had been repeating this process for over 10 years.

It can take time to learn, especially when you're so close to something that you become blind to it. I didn't notice this cycle. I just thought I liked making games in my free time. What's wrong with that? But it wasn't that simple and it wasn't that harmless. I was suffering from a repeated, defeating, soul-crushing feeling of hopelessness every few years when I'd get fed up without getting anywhere and shelve my dream game. It was making me depressed and negatively affecting other areas of my life. And when I finally realized this, I took action to prevent it.

My prevention plan

How was I going to stop this vicious cycle? I had recently read Switch: How to Change Things When Change Is Hard which inspired me to fix areas of my life that felt broken. And so the next time I was motivated to work on Valadria, I instead focused my attention on examining why the project always failed and what to do about it.

After much internal debating, whiteboarding and sleepless nights, here was my plan:

Create a JavaScript game engine and use it to build a simple match-3 game.
Extend this same engine and create a Puzzle Quest clone.
Extend this new engine to build my dream game, an online retro RPG.

This list probably looks really unexpected for an amateur indie developer who wants to work on retro RPGs. So let me explain my line of thinking …

Why a match-3 game in JavaScript?

Over the years, I had tried to build Valadria in everything from QBASIC to C++ to Turbo Pascal. When I was 23, I started working as a PHP programmer, which got me looking more seriously at Flash and JavaScript.

Flash was pretty cool (ActionScript 3 is particularly wonderful) but I was learning the most about JavaScript and I felt the most comfortable with it. So after a few more failures and still feeling pulled to JavaScript, I just said "fuck it" and decided to use it, even though it had never really been tested as a true gaming language.

And I know what you may have thought: "Just what the world needs: another match-3 game." I feel the same way, I do; I'll explain in the next section.

What? A Puzzle Quest clone?!

You may notice I used the term clone here, though I am embarrassed to admit it. As an amateur indie game developer, I feel that clones are wrong in so many ways. They lack innovation, they are sleazy and unethical, and they are at their core lazy game design. Borrowing design elements is just another part of making great software, but one should not borrow too heavily.

So how did I arrive at the conclusion that I should work on a Puzzle Quest clone?

My desire was to make a pretty massive retro RPG. I had to, for some reason. But I thought about it, and I had never even made "real" game of any kind. Not even a Tetris clone or a side-scrolling platformer. I was untested as a game developer and so my aspirations were unreachable.

Enter Puzzle Quest. I was a huge fan of the original and, like many others, was very disappointed with the next Puzzle Quest game.

I really wanted to play an online version of PQ with my friends, but the developer of the original did not choose to go that route. Plus, I knew I couldn't get motivated to work on something like ZooKeeper; I'm just too much of a medieval fantasy geek to get excited about much else. But I could get behind something like Puzzle Quest, so I came up with what I called Puzzle Punk: a game similar to Puzzle Quest in a steampunk world with online multiplayer capabilities.

But even this game was far too complicated. I was an untested game developer, after all, and had never shipped a single finished game. So the plan was to first make a match-3 game. That would be my baby step. I'd make a solid, stable match-3 game and then use that core framework to build Puzzle Punk.

Connecting the pieces

My end goal was not to make Puzzle Punk. That was not the desire that was keeping me up all night and defeating me every year or so. Indeed, I beat myself up a lot over the last few months for having such a stupid idea as a clone in the first place. I'd second guess my plan and consider scratching it, but then I'd remember how I arrived at this plan, and the soul-crushing defeat was pending again, so I just got back on track for finishing Bombada. I wasn't really happy with my plan but at least I finally had one.

So what happened?

This plan failed. But that's ok. I actually did finish the match-3 game; it's called Bombada. It's playable in your browser right now and I put the source code up on GitHub. So I finished one step out of three.

And as you can see from the many images of the game's development sprinkled about, I did make some progress on Puzzle Punk (step 2).

The reason I shelved development on Puzzle Punk is because I started working with Geoff. We had met some time before and had mutual friends but never seriously talked about collaborating. He had some of his own ideas and his own engine he was working on, and all that stuff sounded way more fun than what I was doing. I guess if we had not decided to work together (or never met), it's conceivable that I could still be working on Puzzle Punk, but I doubt it.

I guess the reason I think that is because I didn't even attempt to try to get Geoff on board for my Puzzle Punk idea. I wanted to be working on something else.

What was good

It wasn't all bad: I learned some extremely valuable lessons from all this.

Having a plan at all made me feel in control and empowered me, adding to my motivation at a time when I otherwise felt powerless. Plans can go to shit over time but it's important to have one anyway.
Having a small project to work on first (Bombada, the match-3 game) also helped to remove my feeling of hopelessness. When thinking about how far I had to go in the long run, it was overwhelming. But it was easy to make progress on Bombada, and it was very rewarding.
Keeping really great records of my progress helped drive development. If I would ever feel like I wasn't gaining enough ground, I could dig through my git history and be reminded of what I had accomplished.

What was bad

I think I was on the right track using a language I know and love like JavaScript, but I should have used a technology like canvas that makes more sense for game development (as opposed to DOM). Hearing Geoff talk about cool canvas stuff (which is so much better suited for games) got me really excited; I could have used some of that motivation.
Instead of a match-3 game, I should have been working on a ridiculously simple medieval fantasy game. This would have held my attention better and kept me motivated. Cliffski of Positech Games has written about this kind of thing.
Instead of building Puzzle Punk, I should have been building a slightly more complicated version of the previously mentioned simple game. Then I should have iterated on that, and continued the process.

Overall, I guess this plan was as good as any other. Clearly something needed to change because what I was trying was just not working. It's hard to say if the plan would have worked overall, but my single biggest takeaway from all of this is: if you find you can't do it alone, it can really help to collaborate.

Case in point: after working just a few months together, Geoff and I have put together what we think is a cool little game. And this is a great building block towards building bigger games.

Google Docs

I have no idea if this will be interesting to anyone or not, but in addition to uploading the mocks and wireframes to Flickr, I've also opened up the game documentation I was working on. You can view the files below on Google Docs:

Do you have any failed game projects? I can't be the only one! I'd love to read about someone else's failed project as well.

A Simple Guide to Game Development Contests

2010-07-30T00:00:00-07:00

How do you find out about these things?

I hear about game development contests relatively often, but it's almost always too late to enter. I end up just being frustrated and wonder: "Where do people find out about these contests?"

We've recently been more fortunate and have been able to successfully enter two contests. And here's how we finally were able to find out about them in time: by subscribing to insane amount of gaming news. Below is a list of game development related news sites, feeds and other resources.

News sites:

Indie-related Twitter profiles:

Andrew Wooldridge - random game news and web development links from a professional web developer.
IndieDB - News, insight and media direct from the developers.
IndieGames.com - The latest independent games news, interviews, and features, from the makers of Gamasutra.
Jacob Seidelin - Ridiculously good JavaScript hacker and creator of javascriptgaming.com.
Make Games - A collection of interesting games and game design related links. High content, no noise. (From a current Twitter employee and previous co-worker of mine, Kevin Cheng)
Wolfire - An independent game company (they blog almost every single day, yowza).
Of course there's also our Twitter profile where we tweet about our own doings and game-related news.

Do you know of any additional resources for game development contest news? Please let me know in the comments and I'll happily add them to the list.

So now that you know about these contests coming up …

How do you know if you should enter?

So you found out about an upcoming contest and you're interested. Should you try to put a game together to enter into the contest? This is a difficult question. First: is it a good fit?

If the contest requires that your game is built on Unity but all of your experience is with pygame, that's probably a good sign to forget about the contest and get back to whatever else you were doing.

It could be that the contest is so amazing that it's worth derailing your current project, starting a new one, or learning a new language, but I'd seriously advise against that. I think it's a good adage to finish what you've started and play to your strengths. You might be able to enter a contest outside of your skill set, but you'd probably make a better game just for yourself for fun. So I guess what you should ask yourself is:

Will you benefit from entering?

On the surface, this is another way of asking, Could you win? The benefit of winning many of these contests is clear: for example, with the recently-announced Activision contest, the grand prize is something like $100k and a publishing deal. That's pretty major! But keep in mind that with a prize like that, you're going to get some very polished entries by some veteran game developers. The competition will be intense.

So, maybe you can win and maybe you can't; other benefits can arise from entering. For example, if you read our postmortem on the Boing Boing contest, you saw that we were driven by the hard, unchangeable deadline, which was great because we often can't find motivation. We also made a bunch of mistakes and learned from them, which is another beneficial side effect.

Merely being involved in a contest can also get some much desired attention to your game. According to Google Analytics, Boing Boing has referred over 1,500 people to our game Onslaught!. That's not much from a big business perspective, but for a tiny and unknown team like ours, it's great!

Determining if a contest or promotion is shady

So you found a contest, you figured it's worth your time for one reason or another, and now you're in! You want to enter. Just please do one more quick thing first: make sure the contest isn't shady. You can do that by reading the fine print and getting a second opinion.

If you're seriously considering entering, it's probably worth your time to read the fine print. It's certainly not fun reading, but you could get into a bind otherwise: a single sentence could disqualify your game or remove your rights to your intellectual property. Fortunately, there are resources out there to help you.

The guys over at Wolfire often write about the bigger contests (like they recently did). For that particular contest, you can also get insight from Tom Buscaglia: The Game Attorney (a real attorney!).

Now, if you can't find the fine print, that's a bad sign right there. A legitimate company running a "real" contest is going to have documentation to cover their asses. If you're just entering into a quick weekend contest like the fine folks over at Game Jolt regularly hold, that's fine. But if there's supposedly a cash prize, and you're going to expend hard-earned time and/or money on your project, it had damned well better be legit.

When in doubt, why not ask your indie game development peers? Late last year I bumped into an interesting thread with the subject Indie Game Competition - $15k and possible publishing deals!. What was interesting to me was a post that said:

And you still owe me over $250,000. I also found out I am not the only developer being scammed by Zoo Games, so this should be a warning to everyone here.

I'm not going to pretend to know what's going on there, but it doesn't smell right, know what I mean? For that reason, I'd have passed on that contest.

Decide quickly and move on with your development

The most important thing is not to be affected by decision paralysis. In the past I've spent an embarassing amount of time just thinking about these sort of contests. And in the end I never entered, so all I had to show for it was a ton of lost time. Think about it this way: you're probably going to keep making games either way, aren't you? So set aside a little time to determine if it's worth your while, then move on and get back to making games!

Have I missed any important steps? Have you had any luck (good or bad) with these contests? Hope to hear from you in the comments.

Fun With Logos

2010-07-25T00:00:00-07:00

Whenever I have free time to work on game development, I always struggle to concentrate on the game development itself. Sometimes I lose this struggle and I work on something peripheral like logo design. That happened recently, and here's what came out of it:

For some reason I kept picturing the name engraved in gold. And I was thinking it would be cool for the logo to look like a ye olde tavern sign, like an "INN" sign in classic RPGs.

I didn't spend much time on this beore I realized I was going in the wrong direction. It looks more like a piece of ugly jewelry glued to a sign hanging by thick string.

And here's a different approach: an abandoned playground. I definitely dig the style (I swear some movie company had an animated logo that had a similar look and it was really cool. Anybody know what that is?) and I like how it plays on the company name. But overall it made me more sad than motivated. Maybe … maybe I am just too sensitive …

I was actually really pleased with how this concept turned out. The hourglass represents the idea from the company name about lost time, and the sand falling on the dragon represents the medieval fantasy game we've been wanting to make. The main problem is: how do you make a logo out of that? If a logo is rectangular, it's usually horizontal. We could cut out the top portion but then it looks odd, with the glass stopping at the edge of the image.

Plus, the idea of a sundial came up, and that sounded really cool for some reason …

This was my first shot at the sundial concept. I modeled it after an actual sundial we had in our yard while growing up. It looks very similar except there was a character where the title is (I think it was the Grim Reaper). The idea of making the center piece (the part that casts a shadow to tell the time) a sword came late in the design, which I felt made the whole thing come together.

This is a deeper dive into the initial sundial concept. Copper replaced iron because it strikes me as a very medieval-fantasy type of metal (probably because it was the first decent weapon to buy in Dragon Warrior). Then some texture was added to the face, the hilt of the sword got more design attention, and the title was enlarged.

Overall I think we were pretty happy with it, but we collaborated on an idea to have a stone sundial, where the center piece is actually an axe that was just slammed into the sundial whoooaaaaaa! We thought this was awesomely metal so …

Here it is! We're really happy with it and we hope it conveys "young company that makes medieval fantasy games for you to enjoy," because that was our goal.

The "Lost Decade Games" text itself hasn't seen much design attention yet; I think that's something that we'll iterate on. But in the meantime, now we have an image to attach to our various online accounts, which should satisfy our OCD for now.

Oh boy bonus! I admit there are some designs we're not showing here because they're embarrassingly bad. Here's an example: I was exploring the idea of using the name of the company in the design itself, and I formed the words into the shape of a sword.

It was a decent idea in my head, but in Photoshop it looked so bad I thought it deserved a turd for a handle.

Oh, we also recently added a developer page on Mod DB (and Indie DB, though I don't understand the difference) which had ridiculous logo requirements like image resolutions at: 940x360, 950x150 and 1024x768. Isn't that odd? Anyway you can see more (huge!) versions of the final logo there.

Have you worked on a logo before? What problems did you have and what worked well? Or better yet, have you blogged about it like the Wolfire guys?

Boing Boing Contest Post Mortem -- Onslaught!

2010-07-20T00:00:00-07:00

There are a lot of game development contests out there, and for the longest time it's felt like we kept missing them. So when we heard about Boing Boing's Music Inspired by Games contest, we decided to derail our current game project a bit and dive in. Here's our postmortem on how that went.

The Game We Built

First things first, we built a game called Onslaught! which can be played in a canvas-enabled browser.

What Worked Well

We are ambitious people but we did a surprisingly good job of finishing the damn thing by pushing back on features. There were excellent ideas such as 4 playable classes and multiple stages with different music, but none of it seemed feasible in the 2-3 weeks of time that we had. So that feels like the one thing that we did really well.
GitHub and Dropbox worked out very well for organization and collaboration. These are such fantastic sharing services that you can use right now for free.
We had a good, concrete definition of our game that we could refer to often when wondering which features to include. Our mantra was "a medieval fantasy Smash-TV", which helped the direction we went immensely.

What Didn't Work So Well

Our Google App Engine account wasn't billing-enabled, so our game page went down almost immediately after the contest began. And that's a mistake that Matt should have learned from having "launched" Bombada just recently. Lesson learned now, twice!
We also did not include Google Analytics. We figured App Engine had some kind of analytics-like service for free, but nope. Google Analytics is easy to setup and can provide invaluable feedback, and we hadn't installed it until recently, so we fucked up.
We didn't make it clear that flash was required for audio. We received many comments about audio not working. Blocking flash is common, especially for savvy Internet users. And for this contest especially, music was integral. Not letting the players know that was a mistake.
Should have made the keyboard controls easier to discover. We did include some text on the title page of how to play, but it wasn't enough; many people said they couldn't figure out how to move or fire.
We should have been more clear in our email to Boing Boing that this was a game by Lost Decade Games. On the arcade page, it says "Matt Hackett's Onslaught!" which isn't fair because Geoff did the lion's share of the code. We were pleased to see a direct link to Joshua Morse's personal website, which we think everyone should check out because his music is so incredible.
We did not build a game that would thrive in the 30 second experience domain. Here's what we mean: with 9 entries, people only have a minute or two at max of patience for each game. Our game was challenging immediately: you're fighting off goblins and bats with rocks. That's not fun. We feel that our game can get pretty compelling for fans of the genre eventually, but only after 2-3 minutes, once you've collected better weapons and are fighting cooler enemies like cyclops or a dragon.
The 30 second experience is especially important in a contest which is based on users votes rather than of a panel of judges. Random visitors aren't going to give your game a fair shot if you don't hook them within the first 30 seconds.

For those interested, we believe we have created a better 30 second experience by removing rocks in favor of swords, providing two weapons to start with, and getting into the action quicker (goblins instead of bats in the first wave). It's now more fun to play immediately, which is great for anyone who plays.

Don't take our word for it, though. Play it yourself and leave your feedback here on the blog or in our forums.
The URL is forever. We submitted our entry at http://lostdecadegamesapp.appspot.com/, which we intended to use for other things as well. But the game itself is in the root directory, and we've noticed that some good folks out there have embedded Onslaught! as an iframe, which is great, but now if we ever change that page we're going to be providing broken experiences for potential players and pissing some people off. That won't do! So the URL is permanent and we can never have anything there but a playable version of Onslaught!. Lesson learned.

Conclusion

We made some mistakes and learned some valuable lessons. And now we have something that we can (and have!) submitted to other contests. And the great thing is that, for the Free Play contest, we were able to spend most of our time tweaking gameplay for fun factor instead of building from scratch.

Also, having a hard deadline that you cannot push back can be very good for productivity. All in all, it was a great experience and we highly recommending entering a contest if you happen to come across one.

Links!

Play the version of Onslaught! that we entered in the Boing Boing contest.
Play the latest version of Onslaught!.
Play all 9 contest entries.

Onslaught! v0.2 & Freeplay Awards

2010-07-19T00:00:00-07:00

We've been hard at work the last several weeks improving Onslaught! after entering in the Boing Boing contest (Post-mortem coming soon!).

Now we're entering Onslaught! in the Freeplay Awards with bunches of bug fixes and gameplay enhancements such as:

Brief invincibility when you get hit
Improved the "30 second experience" by giving the player two weapons to start
You can now cycle through your weapons with Z and X
Cyclops now throw rocks or energy balls
Improved the "waves" flow with gates opening/close
You can now pause the game by pressing P
Various behind-the-curtains improvements and bug fixes
Pain and death animations
Demoblin now gets near you and throws tridents
New title
Tweaked the hell out of gameplay
Added dragon boss!
Hit point bars for dragon and superclops
Got rid of rocks in favor of swords
How to play screen

Sounds great, right?

Play Onslaught! v0.2!

As always, we love feedback so leave us some comments here on the blog or in our forums.

(Matt scored around 500k the other night during testing, please take him down a notch and post screenshots of your higher scores!)

Our Boing Boing "Games Inspired by Music" entry - Onslaught!

2010-07-09T00:00:00-07:00

Our game, Onslaught!, has been selected as a finalist in Boing Boing's "Games Inspired by Music" competition!

Check out our entry along with the others and please vote for Onslaught! (Voting is handled at the bottom of this page.)

If you don't care for all this contest nonsense you can just play the game! We'd love to hear your feedback on the game so don't hesitate to leave comments on this post!

Diggy, an open source JavaScript game engine (with example game)

2010-07-05T00:00:00-07:00

Today I'm happy to announce Diggy, an open source game engine written in JavaScript. Embedded below is Bombada, a game made with Diggy:

(Works best in Chrome or Safari.)

More about Diggy

The name "Diggy" came from DGE, which stands for DHTML Game Engine. It's a relatively full-featured game engine meant to empower developers to rapidly produce browser-based games.

You've already seen what Diggy can do, so here's what it is not:

A DOM selector.
An event manager.
A canvas or SVG library.
Useful for standard web apps.
Meant to do anything but make DOM games.
Very stable or ready to make enterprise games.
Still in development (at least by me).

(There are also known issues to be aware of.)

More about Bombada

As you may have read previously, I'm an amateur game developer. I've never shipped a "real" game and Bombada is a baby step towards fixing that. Here's more about the project:

Bombada was orginally intended as an iPhone game (hence the 480x320 resolution).
Bombada was also intended to work with node (hence match3.js being a separate file and attaching to the exports object).
99% of the code was written from scratch by me, with some exceptions being the easing library (borrowed from the YUI2 library) and the JSON parser.
I also made the graphics, which are free to use but have some Creative Commons restrictions.
The music and sound effects were made by Joshua Morse, a freelance music composer. Hire him, he's fantastic.

Bombada ended up taking about 7 months of part-time development. But it's not that complex, so why did it take so long? Partly because as a fulltime web developer, I don't have a lot of free time. But also partly because I was building Diggy along with it, so in theory any future games could be built much more rapidly.

I love postmortems, so I may write one up eventually comprised of what worked, what failed, and any valuable lessons learned. If that's something that would interest you, please let me know in the comments.

Those links again please?

Diggy game engine source code on GitHub.
Bombada puzzle game source code on GitHub.
Play Bombada in its own window.

Edit 7/6/2010: Bombada composer Joshua Morse has put his excellent original soundtrack on sale over at Bandcamp. It's a steal at just $3 (or more if you're feeling generous).

Why You Can't Play Matt's Dream Game (Yet)

2010-05-31T00:00:00-07:00

I grew up playing games like the original Dragon Warrior (NES). And from the moment a friend taught me PRINT "hello world" in QBASIC, I've been trying to develop my own RPG.

It started out as just a hobby, one that for whatever reason would often consume my entire life weeks at a time. Fast forward about 17 years and the passion is as strong as ever. The sad thing is I've just never been able to make it happen. Why haven't I ever shipped my beloved RPG?

I've been writing software and shipping products professionally for almost 7 years now, so I know I'm capable of finishing a basic game. After much pondering, I think I've figured out the two main reasons I've failed for so long:

The pie in the sky

When you think about your dream game, your head's in the clouds. You think about all the cool features you would make and all the problems other games have that yours wouldn't. You want it to be spectacular because, after all, it's your dream game! But the problem is it's just too much. As an amateur developer, I'd have been better off thinking up the next Tetris or Bejeweled, because a one-man-army could make the next one of those, but not the next WoW. The good news is that the solution is easy: build a small, concise game.

Loss of motivation

The passion persists, but the motivation is fleeting. I would get into these little boosts of energy where I'd remember "Oh yeah! I should make that RPG I've always wanted to! I'm pretty good with JavaScript now, I could do it!" And I get revved up and spend the next month rewriting the crappy engine I had from last time around, then like clockwork, the spark dies. What causes the loss of motivation? A few things:

Working in a vacuum makes it feel like nobody cares about your project, and as humans, it's easy to think "well then why should I care?" and quit. The key here is to collaborate and spread the word about your project.
Missing assets like graphics and music can really kill your spirit. You're thinking about all the different problems you have to solve like tilemaps, scrolling, inventory management ... then you remember you need an entire game's worth of graphics, music and sound effects to boot. Game over! (Luckily these days a clever Googler can find free graphics and amazing musicians. But most importantly, it's not that big of a problem, so figure it out and move on.
Distracting side projects come up. I've been hacking on various things like fancy new versions of my website since I was about 12. But the only project that I really feel like I let slip through my fingers over the years is my own RPG. So clearly, I've been spending my time on the wrong things.

That said, it hasn't been all bad. I made a crappy little retro shooter called Spacius!, and before Geoff and I started working on our game together, I was working on a medieval fantasy RPG I call Valadria. It was going well, probably better than it had in years. I put up a playable demo on Google's App Engine (which I really recommend trying out). So some progress is there, it just hasn't been enough.

Summary: how to avoid these problems

I'm only going to spend my time on tasks that will get me closer to achieving my goal, which is to ship a professional RPG. There are tons of other cool projects out there, but this is the one for me. I'm also going to collaborate and try to get the attention of people who like playing (or building) the kind of games I want to make.

Do you have a project you've always wanted to complete your whole life? If so, what are you going to do to make it a reality?

Why Geoff Failed and the Road to Redemption

2010-05-31T00:00:00-07:00

I blame my father for my obsession with making video games. It was he that introduced me to the wonderful world of BASIC on his Commodore 64. Dad was a gamer at heart and, just like me, has a passion for tinkering with computers. The very first reason I had for learning to code was to make a game.

Fast forward quite a few years and I’ve yet to fulfill that initial dream of making a game. Now, when I say “making a game” I don’t mean prototypes and incomplete demos. I’m talking about actual, complete and polished games. The kind that people would be willing fork over cash to play.

Why have I failed to produce a completed game?

Good question. There are quite a few reasons. None of them are unsurmountable obstacles. It is my hope, however, to overcome these previous barricades by acknowledging (and documenting) their existence and plotting their demise. Let’s walk through a few of my stumbling blocks.

Will code for food

Although I’ve not shipped any games, I have spent the last decade writing lots and lots of code. Coding for a living really limits the amount of time I can seriously dedicate to making games. However, I don’t regret this for even a second. Instead of spending my time developing prototypes and little RPG demos in the hot language of the week I need to double down on a specific game.

Solution: I will focus my game development energy on the game I actually want to make.

Creepy features

Feature creep isn’t just a problem for game programmers; it’s one that I struggle with on a regular basis. I’ve found that feature creep is especially nasty for a lone developer working on a game in their spare time. There are so many cool things that can go into games that it can be overwhelming at times.

Solution: I will endeavor to keep it simple, release early and iterate often.

The one man army

Trying to wear every hat in the game development cycle can be daunting. In addition, developing in a vacuum robs you of the valuable feedback from others. Sometimes, just the mere fact that someone will be reading my code forces me to avoid shortcuts and bad design. I’ve also found that I really need teammates to help motivate me and to excel in areas where I am weak.

Solution: I will surround myself with passionate developers who share my vision for games.