HTML5 Audio Pains

HTML5 audio is a bit of a minefield when you’re trying to get sound working on all platforms. The internet is rife with outdated information, and libraries that claim to work everywhere but don’t really. By “all platforms”, I mean:

  • Modern, Popular Desktop Browsers: Chrome, Firefox, Internet Explorer 10+, and arguably Safari
  • Common Mobile Browsers: Safari Mobile, Chrome Mobile, Android Mobile (ignoring the fact that there is no singular “Android Browser”)
  • PhoneGap or CocoonJS: I’m making HTML5 games & apps, and I need a tool to generate binaries from my JavaScript. These are two viable options.

Took me an entire week to navigate this minefield, and I emerged on the other end with a Tuning Fork to help me figure out which audio solutions were working where. I have a hosted version of Tuning Fork so that you can try this out for yourself. Here are my findings:

Chrome (35.0) Firefox (v30) IE 11 Safari (v7.0.5) Safari Mobile (7) Chrome Mobile Android Mobile PhoneGap Build PhoneGap CLI CocoonJS (Webview+)
HTML5 audio tag Yes Yes Yes Yes Yes No ? No No No
Crafty.Audio (v0.6.2) Yes Yes No No No No ? No No No
SoundJS (v0.5.2) Yes Yes Yes Yes Yes Yes ? No No Yes
howler.js (v1.1.23) Yes Yes Yes Yes Yes Yes ? No No Yes

After much effort, I finally got audio working on PhoneGap using the Media object, but it was no easy task. If you’re in that boat, the Tuning Fork project, when compiled using PhoneGap CLI, will produce audio, at least it did for me on my Android. To get it working in your own project, I wrote a detailed answer on Stack Overflow.

Undoubtedly, the table above will become obsolete in a few months, so please run your own Tuning Fork tests against your target platform(s).

Skippy Fish

I just finished my adorable jam entry for the 2014 GDSE Summer Game Jam.

Skippy Fish

Play Now

The theme of the jam was to take a mechanic from another game and either change it or make it better. I chose Flappy Bird’s “tap to fly” and “Punishing but Quick” concepts and made them my own. You are a fish trying to escape death by skipping on the surface of the water. Press or release the left mouse button when Skippy is close to the surface of the water to skip.

All art and sound assets were created by me, specifically for this project. I used Inkscape for the graphics, and a glass of water, a straw, some popsicle sticks, my own voice, and Audacity for the audio. I have uploaded all of these assets to under more permissive licenses than the game.

The game is open source and can be forked on Bitbucket, Licensed under CC-BY-NC-4.0

Known issue: Sound may not function properly in IE11, use Chrome or Firefox.

Asteroid Outpost is Dead

It saddens me to declare that Asteroid Outpost is over. I knew it was a very ambitious project when I started back in 2009, but at the time, I needed an interesting challenge. Along the way, I rose the bar again and again. I set my bar too high. Asteroid Outpost is in a playable state, and I will be releasing not only an executable, but I will be reopening the source. It has been an wonderful journey with lots of ups and downs, but it’s time to move on. I have never experienced an emotional roller-coaster quite like it. In time, I will write up a postmortem, but for now I just want to write something short.

Hello WordPress

My web-host was hacked, and my website was among 4 that were deleted. It sucks, but I didn’t lose a lot, and there’s some good coming out of it: I’m starting over with WordPress. Most everything is back up and running, and I think most links should work. Let me know if you find any issues.

Six Scenarios and a Story

I need to create a small number of scenarios, get them linked together in a campaign, implement saving, add some sounds, and tie it all together with a story. Asteroid Outpost needs to make it to a cohesive state. I’ve built my vertical slice of gameplay, now it’s time to build horizontally. Five or six scenarios sounds about right to lay down my horizontal framework, and it will be long enough to have some fun. I’m aiming for ~10-20 minutes per scenario, which will result in 1-1.5 hours of gameplay awesomeness!

Scenarios and Explosions

It feels like relief to finally make some decent progress in Asteroid Outpost. I have been trying to focus on some of the larger and more visible items, starting with those ugly yellow power lines. This was followed up with improving the laser miner beam and making it extend from source to destination:


I was getting sick of the single style of AI in the game: “move forward until you’re within laser range, stop and shoot”, so I designed some new AI that uses a mix of missiles and lasers, and attempts to strafe. Each unit has 6 missiles and will only use laser beams as a last resort. Here’s a quick video example:

Scenarios are an important part of my game, so I sunk some time into the “Science Station” mission. In this scenario, scientists require more and more power to conduct an experiment. Without access to power, they will be unable to keep their experiment under control and the entire station will erupt spectacularly.


The explosion could look better, but I do like the fires. It’ll do for now. The scenario isn’t quite done yet, but the power requirements ramp up, and if they are not met, the science station explodes.

I have started to seriously think about how many scenarios I want the game to have, and how to link them together with a bit of a story. It would be great if I could create skeletons of these scenarios and connect everything for the first time. No, it would be incredible.

Recent Activities

Been a while since I’ve provided an update, so this will be a big one.

I won the first, and second ever GDSE Game Jams! For the theme “There can only be one”, I created Like Clockwork, a web-based bot programming game where you program your archer to navigate the battlefield, seek out, and destroy your enemies. The second jam had the theme “Time is Broken”, and I made (In &) Out of Time (works noticeably better in Chrome), a web-based adventure game. Both are open source and available on BitBucket here and here.

Asteroid Outpost could be coming along better. I created a nice dialog screen that shows who’s talking, added a new enemy spaceship that’s practically the same as the first, and started to make a new scenario. The new scenario demanded a giant super-structure, but since my game is 2D, I needed to split the new entity into 2 sprites so that it would properly draw over and under other entities in the scene. My entire engine is capable of handling two sprites for a single entity, except the current JSON format I’m using to load entity templates and send entity data to Awesomium. Now I either find a shortcut and move on, or take the time to fix my JSON. Shouldn’t be too bad, but it’s still one more thing I need to do. On the plus side, I was really happy with how quickly I was able to get a new bad guy int he game.

There have been a couple bugs in TeeVee that have been annoying me recently, and I’ve been thinking about completely redoing the UI for a few years, but haven’t made the time. This weekend, however, I finally took the plunge and created a brand new web-UI that replaces the UI portion of TeeVee. The scanning and updating from is still handled by TeeVee 1, but I plan to write two stand-alone apps that will do each of those tasks. I must say, TeeVee II is already looking way better. Not only is it significantly faster, but it’s also way sexier.

When I’m done with TeeVee II, I’m not sure if I want to release it open source or what. It’s valuable to the right audience, but my gut is telling me that the audience is too small, and none of my audience will be actively seeking out an XBMC replacement because they don’t know that it could be better. Let me be clear here, it may be better than XBMC for heavy TV viewers like myself. I tried XBMC for a few weeks, and my main annoyances with XBMC were: It’s very folder-based, lack of “favourite” shows, and it didn’t handle sleeping very well. TeeVee is file-based, so you can just download your TV to wherever you want, and TeeVee just picks it up and runs with it. It can save a lot of time if your library is large. You can select favourite shows in TeeVee, and those shows will appear above all of the other shows. I have 157 series in my database. How fun do you think it is to watch Vikings with XBMC? And the last point: if my laptop would go to sleep with XBMC running full-screen on my second “Monitor” (the TV), when I woke up the laptop, XBMC would be full-screen on the primary monitor (the laptop). Anyway, look for TeeVee II hitting the shelves near you!

Like Clockwork

I participated in the GDSE Game Jam over the weekend and ended up making a pretty cool game in a very short period of time. For those who are unfamiliar with game jams, you are given a theme at the start of the competition, and you have to make a game from scratch before Sunday at Midnight, using only freely available tools and art. Once the games are submitted, there is a voting period, and the one with the most votes wins.

The theme for this jam was “There can only be one”. It took a lot of thinking, but I finally thought of, and settled on programmable bots that would fight each other in a 2D arena. I didn’t want the bots to be futuristic, and so the medieval archer game Like Clockwork was born.

Like Clockwork’s documentation and source are available on bitbucket, and you can play it on my App Spot

Note that the battle field will only work in Firefox due to technical limitations. I hope to have a working version in Chrome soon. After this fix is made, Chrome users will have to enable the Experimental JavaScript flag in the browser because Chrome does not support the future JavaScript function yield out of the box.

For this game, I am using a technology stack that is completely new to me: CraftyJS, Blockly, Google App Engine, and the future JavaScript function yield. From a high-level, users stack blocks together in Blockly, then publish the generated JavaScript to Google App Engine’s cloud storage where they (and others) can select bots for battle, which then sends the JavaScript bots to the CraftyJS “battle engine” where you get to watch the bots move around and shoot arrows at each other.

The game took me almost exactly 30 hours of work from start to finish, and a lot of this time was spent reading documentation for the new technologies that I am using in this project. Here’s a rough timeline:

  • Friday, Night Started to use CraftyJS, setting up a grid and going through tutorials
  • Saturday, Mid-day 2D playing field with red squares shooting brown squares using hard-coded “scripts” with only movement and shooting
  • Saturday, Evening Archers shooting arrows with sounds and animation
  • Saturday, Night More scripting functionality: Scanning, stabbing, etc.
  • Sunday, Mid-day Blockly was installed on a new Google App Engine and I could run the battle engine through it. Starting to play with the App Engine cloud storage tutorials. Decided to test in Chrome, whops, yield doesn’t work
  • Sunday, Evening Added a couple custom blocks to Blockly. Listed scripts from App Engine on a web page
  • Sunday, Night Oh boy, I really need to tie the ends together. Managed to get scripts going from end to end, then had a moment or two to add a new block or two, and the last crucial step: Names need to be displayed above the bots. Publish, document, submit.

The end was a bit tight. If I didn’t connect Blockly to the Battle Engine, I would have had nothing. Luckily, I came across very few roadblocks and was able to pull everything together in the last hours of the jam, :)

Here are some screenshots of programming and fighting:



Wish me luck in the polls!

Changing Hats

Gears are changing! Engine and tool design is phasing out (with a few major exceptions), and game design is in. It feels weird to say it, but during the last 4 years, I’ve had a very nebulous, hand-wavy idea of what I wanted in the end. Now that I’m at the point where I’m adding end-game content, I’m scrambling to figure out what I actually want in the game. What sorts of structures do I want, what kinds of weapons will be used, what kinds of upgrades do I want, what will the scenarios look like, do I want a story line, do I want voice acting, etc. So many questions. For now, I’ll add content bit by bit while finishing off the engine and tools. The content is going to take some play testing to see what works and what doesn’t, so it’s a good thing that it’s easy to add stuff and play around with it.

And for a quick status update: single-unit upgrades are physically working but not pretty, the solar station can now be upgraded to level 2, added auto-healing to all structures, constructing and upgrading units can now be cancelled, and worked some more on the context menus.

1 2 3 8