Lost Decade Games

Why Geoff Failed and the Road to Redemption

2010-05-31T00:00:00Z

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.

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

2010-05-31T00:00:00Z

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?

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

2010-07-05T00:00:00Z

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).

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

2010-07-09T00:00:00Z

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!

Onslaught! v0.2 & Freeplay Awards

2010-07-19T00:00:00Z

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!)

Boing Boing Contest Post Mortem -- Onslaught!

2010-07-20T00:00:00Z

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.

Fun With Logos

2010-07-25T00:00:00Z

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?

A Simple Guide to Game Development Contests

2010-07-30T00:00:00Z

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 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.

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

2010-08-14T00:00:00Z

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.

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

2010-08-29T00:00:00Z

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?

Onslaught! Arena 1.0 Gameplay Teaser

2010-10-16T00:00:00Z

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!

Obfuscating JavaScript with Closure Compiler Advanced Optimizations

2010-11-17T00:00:00Z

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?

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

2010-12-07T00:00:00Z

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.

App Engine and Chrome Webstore Issues

2010-12-12T00:00:00Z

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.

Our first week in the Chrome Webstore (the numbers)

2010-12-14T00:00:00Z

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?

Reviews of 6 Screen Recording Apps for OSX

2010-12-31T00:00:00Z

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?

Onslaught! Arena now on sale for $1.99

2011-01-07T00:00:00Z

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!

Details about our next game Burn Tactics

2011-01-16T00:00:00Z

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 v1.2.8

2011-02-12T00:00:00Z

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!

Onslaught! Arena is free on Valentine's Day

2011-02-13T00:00:00Z

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!

An HTML5 game in the Mac App Store

2011-03-13T00:00:00Z

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.

How to embed HTML5 into a native Mac OSX app

2011-03-15T00:00:00Z

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.

What we need to get our HTML5 game on iPad

2011-03-17T00:00:00Z

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:

```objc - (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!

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

2011-04-01T00:00:00Z

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

No more foolin' around

2011-04-02T00:00:00Z

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!

Completing your native Mac OSX App built in HTML5

2011-04-17T00:00:00Z

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.

Lava background sprite creation (timelapse)

2011-05-25T00:00:00Z

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:

The road to a production-quality HTML5 game on iOS

2011-07-11T00:00:00Z

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.

Onslaught! now available on Android tablets

2011-07-16T00:00:00Z

Update: we've taken the Android version down, as the Game Closure SDK is both not currently supporting Android and we do not have access to it. Our sincere apologies for any inconvenience.

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!

Dear Lost Decade...

2011-07-18T00:00:00Z

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!

Analog thumb sticks for iOS using HTML5

2011-08-05T00:00:00Z

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 augmented 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.

How to make a simple HTML5 Canvas game

2011-08-29T00:00:00Z

You want a quick tutorial for making a SIMPLE game in HTML5? Let's walk through a SIMPLE game practically line-by-line! (If you're curious about my credentials, I made half of A Wizard's Lizard.)

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

Screenshot

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, which we use to issue drawing commands. Then we set its dimensions, and add it to document so it'll appear in the page.

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 us know when it's safe to draw the image, as trying to draw 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.) 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 instead of acting on it immediately.

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 pressing 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 if it caused anything to happen. 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("Monsterrs 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 canvas will draw 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;

	// Request to do this again ASAP
	requestAnimationFrame(main);
};

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. A note about looping

// Cross-browser support for requestAnimationFrame
var w = window;
requestAnimationFrame = w.requestAnimationFrame || w.webkitRequestAnimationFrame || w.msRequestAnimationFrame || w.mozRequestAnimationFrame;

Don't worry, it's not necessary to fully understand this part, but I thought an explanation of the looping code would be beneficial.

To continuously call the main game loop function, this tutorial used to execute the setInterval method. These days there's a better way, via the requestAnimationFrame method. However, as with most new web technologies, some code is needed to ensure cross-browser support. The polyfill I've included is a simplified version of the one on Paul Irish's article.

10. Start the game!

// Let's play this game!
var then = Date.now();
reset();
main();

Almost there, this is the last code snippet! First we we set our timestamp (with the variable then) to seed it. Then 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.)

Congraulations! You now understand the basic fundamentals of game development (I hope!) 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.

What's Next?

Dive into game development with Game Dev Medkit, a free pack of game development goodies.

Our new blog is running on Jekyll

2011-09-12T00:00:00Z

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 manor 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!

Update Feb 7, 2022

Nope, it's now running on Eleventy.

(Yes, I did this over a decade later.)

Lost Links: 9/23/2011

2011-09-23T00:00:00Z

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.

Blog author attribution using Jekyll

2011-09-26T00:00:00Z

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: article
title: Catchy blog post title
post_author_index: 1 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_index: 1 or author_index: 0 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 about 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/30/2011

2011-09-30T00:00:00Z

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.

Audia is a library for simplifying the Web Audio API

2011-10-05T00:00:00Z

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: 10/7/2011

2011-10-07T00:00:00Z

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.

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

2011-10-10T00:00:00Z

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][5] 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][6] 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][7], 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][8], 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][9], they graciously threw a release party for Onslaught!. Many players showed up from [StartX][10] 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][11] 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/14/2011

2011-10-14T00:00:00Z

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.

Bootstrap your artistic abilities with pixels

2011-10-17T00:00:00Z

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/21/2011

2011-10-21T00:00:00Z

It's Friday, which means more HTML5 gaming links for your perusal:

Facebook HTML5 Showcase (includes our game Onslaught!)
Duck Hunt HTML5
j3d: Javascript/WebGL engine
HTML 5 Canvas Deep Dive

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.

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

2011-10-24T00:00:00Z

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!

Lava Sword Dev Diary

2012-02-24T00:00:00Z

So I'm working on a new game tentatively titled Lava Sword. The goals of the game are pretty specific: we want an arcade-style action game optimized for mobile browsers. I've been thinking about Jeff Vogel's recent blog about how indie game devs should be looking at some of their favorite games for inspiration, so I decided to revisit some of mine.

Influence

A few of my favorite arcade-style games when growing up include Golden Axe, Altered Beast and Magic Sword. (As one of the few gamers into Turbo Duo back in the day, there's also some Legendary Axe influence, but that's pretty obscure!) These are mostly story-based fighting games with tight controls and complex battles. That's really not good for mobile!

Is there another approach I could take? Essentially I want to capture the spirit of these games on a mobile device. Beyond the advanced controller input, I thought about what else makes these games what they are. Big sprites is one. Vibrant, open, scrolling environments is another. Really, the simplest version of these games would consist of just moving around the environment and attacking. Hell, mobile can do that. So I got to work.

Prototyping

That's's the first screenshot, taken as early as there was anything to to take a screenshot of. As you can see, the game starts very simple. On a plain green background, I represent the player with a blue rectangle and monsters with red rectangles. Gold and other treasures are represented by yellow rectangles. This is the prototyping stage of game development where your game should begin to be fun. If you can't find something entertaining at this stage, you shouldn't move on to the next stage. You should focus on making it fun.

Spriting

After finding the fun, I started working on some basic graphics. Nothing too complicated like animations and stuff; I'm not ready for that yet. For the time being, I mostly wanted to see about getting parralax scrolling into the mix, because if I run into some brick wall along the way, the game's basically a no-go. (…though mostly I just love parralax scrolling and couldn't resist.) I also wanted to make sure I wouldn't hit an inspirational brick wall, and graphics really help with that.

It would be cool if eventually there were many environments, but this is adequate for now. And that's all I've got so far! So what's next for Lava Sword? Let's take a look at the ol' TODO list:

Implement player/monster health
Item/weapon drops
Difficulty progression
Game flow (title screen/gameplay/paused/game over)
Player/monster animations
Polish polish polish

Lots more graphics are in the works too! None of them has been "final" so far (especially the warrior, he needs a new approach). Here's where I'm currently at:

More to come

If you find this kind of stuff interesting, you should subscribe to our blog and/or follow us on Twitter, because I'll be posting another Lava Sword dev diary again soon (maybe with video). Thanks for reading!

An onslaught of Onslaught! news

2012-02-27T00:00:00Z

Big things going on with Onslaught! and Onslaught! Arena today:

Both games are now free (previously $1.99)
The Onslaught! OST has been released
Onslaught! Arena is now open source

Not familiar with the Onslaught! games? Check out our post Onslaught! -- a history of violence (in images).

1. Play for free!

So, first things first: if you haven't already, you should go slay monsters for free on one of these fine platforms right now: Android tablets, iPad, Chrome Web Store, Mac App Store or…

Play Onslaught! Arena in your browser

2. Onslaught! OST

Onslaught!'s music composer Joshua Morse has released the Onslaught! OST and it's really awesome. You should absolutely go pick it up on Bandcamp right now. Need more evidence? Check out the promo video below:

Watch this awesome promo video

3. Onslaught! Arena source code

Onslaught! Arena is now also open source on the Lost Decade Games GitHub page. Warning! The code is pretty old at this point and we're both embarrassed by the bad quality of it. But there's still tons of great object and math code in there to read and learn from if you're new to JavaScript or game dev.

We've chosen a GPL (General Public License) for Onslaught! Arena. This means you can fork it and make whatever you want, but it must also be open source. We also retain the rights to all game assets. tl;dr: make whatever you want with it but you can't sell it.

Note that only Onslaught! Arena (and not Onslaught!) is open source. While the games are just slightly different, Onslaught! was built using the Game Closure SDK and cannot be shared just yet.

Put your eyeballs on this source code

More exciting stuff coming soon

If you dig HTML5 and open source software, you should subscribe to our blog and/or follow us on Twitter, because I'll be posting about this stuff often. Thanks for reading!

One final note: if you are one of the fine human beings who purchased the game while it was for sale, we'd like to thank you from the bottom of our nerdy hearts. You've kept us going and have given us hope for chasing the indie dream. Thanks for your support!

Onslaught! Arena takes 3rd place in the Pokki 1up Game Developer Contest

2012-03-10T00:00:00Z

Onslaught! Arena up on the big screen at GDC

Less than a week after Onslaught! Arena went open source, it took home 3rd place in the Pokki 1up Game Developer Contest. This got us tickets to GDC, a day of awesome fun with the Pokki team, and (last but not least), a cool $7,000. (If you listen to our podcast you know that we're indie now so this is a real stress-reliever for us!)

Developing with Pokki

Gotta say, it was really easy to work with Pokki's tech (though granted, we already had a full working game, so all we had to do was stick it into their stack). It only took about an hour to integrate! Their platform is basically Chromium stripped of its user interface, which means it's very similar to developing within Google Chrome. This is great; familiar tools like the Web Inspector are at your fingertips.

Onslaught! Arena takes 3rd place

We had to switch from mp3 to ogg for audio to work with Pokki. Can't really blame them here, as who wants to worry about the crazy mp3 licenses? I've got a handy VLC-based CLI script I use that made the conversion easier. Audio performance is also buggy and inconsistent (but we all know this is a problem with Chromium and will go away eventually).

We also had to include a minimize button in order to be accepted into their gallery. This was a straight-forward process and only took a few minutes.

The other winners

Nicklaus Liow sportin' a horse head

What about those other games, hm? First place went to Nicklaus Liow for his delightful game Four Horsemen. It's a simple puzzle game with a quirky theme and a ton of polish. He really knocked this one out of the park, and that song-and-dance tutorial really takes the edge off of teaching the player to play. Really well executed.

Second place went to Evgeni Gordejev and his wacky alien-physics game Tupsu. Evgeni was a particularly interesting developer to chat with, as this was the first game he'd developed. He also has a C++ background but chose to program in Java using Google's cross-platform game library playn.

Thanks Pokki!

Anybody else dying to see the rest of those graphics?

We spent most of Tuesday chatting with the Pokki team. They're a really smart, impressive group of developers who have a history of making impactful technology (some of them having founded DivX). They're extremely developer-friendly, which obviously we are thrilled about. Their plans for Pokki are numerous and ambitious, and I believe that they have the skill and experience do accomplish whatever they put their resources toward. Looking forward to seeing what's next!

How to polish your game: flickering hearts

2012-03-13T00:00:00Z

If you follow our blog you've probably read some of our tutorials by now. One common request is how to polish your game. Since this is such an amorphous thing, and varies from project to project, we'll probably be doing several tutorials on how to polish various games.

Video speaks louder than words

So here's our first of an eventual series of polish tutorials: adding flickering hearts to our mobile browser game Onslaught! Defense.

Need the YouTube URL?

When developing a feature for a game, it's important to first get the core functionality in place, and then to add polish later. For example, let's say we want monsters to spawn heart containers. The implementation steps might look something like this:

A heart container may now appear randomly after killing a monster
If the player shoots a heart container, the player "collects" it and regains lost health
Heart containers will now disappear after 3 seconds
Heart containers will now fade out instead of instantly disappearing
Heart containers will now flicker out instead of fading out

Here's what the code in our game looks like:

// Have the heart container "pop" in
polish.popIn(this, bind(this, function () {
	// Wait a moment, then start to flicker away… then disappear
	var numFlashes = 20;
	this.numFlashes = 1;

	// Wait 1 second
	this.delayTween(1000);

	// Add flashes to the queue
	for (var i = 0; i < numFlashes; ++i) {
		this.delayTween((30 - i) * 6, bind(this, function () {
			// Toggle opacity
			this.opacity = this.opacity == 1 ? 0 : 1;

			// Gone through all the flashes? Then remove it
			if (++this.numFlashes == numFlashes) {
				this.remove();
			}
		}));
	}
}));

Might be easier to read in this gist…

Basically it adds visibilty toggling to a tweening queue, decreasing the time between toggles as it goes through the queue. Then it removes itself when it's gone through them all. (Sorry, no, it's not open source yet.)

If you've got a really polished game, you might not stop there. You might have the most polished damn heart containers you've ever seen! That explode into tiny red birds that fly away while singing a synchronized song. While on fire.

But that's for future tutorials…

Goodbye GitHub, Hello AWS

2012-03-26T00:00:00Z

The Honeymoon

If you follow this blog at all you probably know that we love GitHub. It's a great service with outstanding UI. GitHub is the reason that I now use git for all my source control needs.

When Matt and I redesigned the Lost Decade Games website we wanted to have a setup with easy deployment and scaling. GitHub Pages was a service that fit this bill nicely. Pages hosts your static site (generated via Jekyll) by simply pushing some code to GitHub.

Given that we were already paying customers, we got custom domain name support as well. Life was good for a time.

The Breakup

Before long we started hitting some walls with GitHub & Pages.

For starters, GitHub's pricing model is ruthless. $25 a month gets you 10 private repos, which I feel is a complete ripoff. Want more repos? The next plan is $50/month for 20 private repos! Even as a two-person indie shop we hit the 10 private repo limit quite quickly.

In response, we started moving our inactive private repos to BitBucket which boasts unlimited private repos and monetizes on collaborator count. BitBucket is basically a bad clone of GitHub, which is fine, but we ended up having to deal with two separate repository hosts, and that was too painful to put up with.

Pages is semi-unreliable, as well. This isn't a direct criticism of GitHub; we're aware that keeping services up while under DDoS attacks is tough. But the fact of the matter is that too often we couldn't update our website because Pages was down.

One day pushes to our website repo stopped working. No error notifications. No push. Nothing. Turns out that if your build doesn't complete within 5 minutes, it fails silently. Bugs happen of course, but I'd much rather be able to jump on the server and figure things out than fire off emails to support and hope for a prompt response.

There are a few other nit-picky issues, but by this time we had decided that we were in dire need of a new solution for our git repo and website hosting.

The Rebound

After falling out of love with GitHub I made a list of important requirements for our hosting needs:

Easily scalable! I don't want to worry about spinning up new boxes to handle load for a static website.
Unlimited (or a large number of) private repos
Single command deployment with git push
Cost effective!
Control! Jekyll extensions, etc.

I had heard about Amazon Web Services (AWS) before, but for some reason I never thought it a practical solution for a company as small as ours.

Thankfully, AWS offers a Free Usage Tier which lets you get your feet wet with some generous limits. Taking advantage of this free tier I began messing around with various hosting solutions using EC2 and S3.

Straight away I spun up an EC2 micro instance which acted as our git/web server. In the post-receive hook for our website's repo I created a simple shell script which builds the site via Jekyll and pushes the result to the Apache document root. The Jekyll wiki has a nice section on deployment with similar scripts.

Not bad! We had git-push-to-deploy working as well as unlimited repos. However, I felt that the web server and git server shouldn't be combined. Running an EC2 instance for both servers isn't very cost efficient, either. Luckily, I stumbled upon the fact that static websites can be hosted on S3!

Hosting the website on S3 is great for a couple big reasons:

No need to run Apache on an EC2 instance. Less complication and less expensive!
Scaling is taken care of by S3, no messing around with EC2 load balancers, etc.

Looking Ahead

Our website is now hosted out of S3 and if you're reading this post things are holding together pretty well!

GitHub is a great product but it's not geared towards a small business like ours. We'll still be hosting our public code there, but I'm much happier with our new stack.

All that said, there are bound to be issues with AWS which I'll likely blog about in the future as we encounter them.

Do you have a preferred setup for hosting static websites? Let us know in the comments!

Your wish for a wishlist has been granted

2012-03-29T00:00:00Z

Update: amazing listener Joseph Huckaby has cleared out the wishlist! Thank you so much Joe!

Some of you fine, wonderful people have reached out to us via email, blog comments and Twitterwebs about supporting us via PayPal or similar services. First off, you're awesome and that's really appreciated!

While I feel a little weird accepting straight-up donations, we have created an Amazon Wishlist for Lostcast hardware (at the suggestion of our awesome listener Joseph Huckaby).

Making Lostcast sound better

So we hit a brick wall in how good our in-person interviews can sound. Since we only have two microphones, some participants must share a microphone. I think this is really clear in our recent interview with Arno van der Vegt. To me the quality of Arno's voice is great, and ours is terrible (since we were sharing a mic).

Anyway we haven't fixed this ourselves because we've already spent upwards of $1k on gear and the upgrades would be about that much more (and we're indie now so we gotta be frugal!). So that's what our wishlist is all about:

Shure SM58 ($99.00)

Awww yeah we've got two of these already and they're soo goood! I used to record guitar with them too, they're very diverse.

15" XLR cable ($8.74)

Did you know all brands of cables produce the same quality audio? We recently went to Fry's to purchase video cables and a sales person tried to upsell us to Monster cables (which are like 5x the price!). Myth busted!

Another tip: buy much longer cables than you think you'll need! Future self will thank you.

Microphone stand ($29.51)

You want the speaker to be comfortable and relaxed when doing a podcast like Lostcast. So the way we do it is we relax in chairs and have microphone stands stick mics in our faces. This is another reason why Arno sounded great and we sounded like we were in tin cans… we didn't have our own stands!

We bought one of these already and like it more than my old one, which was one of those round heavy ones that sucks because you can only barely stretch the stand's neck out. This one's way better!

Pop filter ($12.99)

This attaches to the microphone stand and rests between the mic and the source to capture air bursts. Saying words like "pop" with heavy "p" sounds can mangle the audio! This prevents that.

M-Audio Fast Track Ultra Audio Interface ($359.00)

What the hell is that?! So in a nutshell this (expensive) device lets us record with more microphones. With our current M-Audio Fast Track Pro, we can only record two (and that's not enough for an interview!).

Obviously this thing is extremely expensive and we'd be ecstatic to receive it. We'd be shocked (and very grateful!) honestly. The problem is that even if we had all of the above gear, we couldn't use it without this, so I think we'd likely spring for it ourselves if amazing people bought us the rest of the gear!

Side note: we actually don't need Avid Pro Tools MP that comes packaged with it, but this one is cheaper than the device by itself for some reason. Weird huh?

Thank you

Man, I can really geek out about audio hardware. Anyway thank you very much in advance! Anything we get we'll do our best to use to increase the quality of our show.

Announcing OnslaughtVille!

2012-04-01T00:00:00Z

It's no secret that we at Lost Decade Games love playing social games on Facebook. In fact, our dream for this company was to one day build an amazing, innovative game experience woven with social fabric.

Friends, that day has come.

Announcing OnslaughtVille!

Have you ever wondered what it would be like to manage your own medieval fantasy village? Wonder no more!

OnslaughtVille offers hours of engaging gameplay:

Build shacks, horse stables, outhouses and more as you expand your village!
Clean chamber pots before your village becomes overwhelmed by the plague!
Throw goblins at your friend's village!

OnslaughtVille will be built from the ground up on next generation browser technology -- Java Applets. Everyone knows that HTML5 is just a fad.

Lostcast production timelapse

2012-04-05T00:00:00Z

Lostcast is our podcast about HTML5 games! In this post, I'll walk you through this crazy timelapse that shows how I edit the 'cast:

1. Compress and limit

First I apply compressors to both audio channels (usually it's just mine and Geoff's) and limit the master output to 0 dB. At first I just throw these modules in and don't tweak the settings just yet.

2. Trim and polish

This is the time-consuming part. I basically go through the audio with a fine-toothed comb. This consists of listening to the entire podcast, trimming out silence and "uh" and "mm" and all that mumbly crap.

I also cut out parts where we messed up or if something was just not remotely interesting. Geoff and I are both really rambly, so sometimes I cut out entire conversations!

Basically my goal with this step is to get the podcast sounding lean and compact with almost no silence.

3. Balance

Next I'll go back and tweak the compressors. I'm not an audio engineer, just a hobbyist, so I'm going for a "good enough" approach here. I want to ensure that everyone on the podcast sounds loud enough to be heard clearly at normal volumes, at all times.

4. Sound effects

I don't do this step for every podcast, but sometimes I like to go in and add some additional polish in the form of sound effects. Sometimes I'll add reverb to someone's voice just for fun (like when an announcement is made), or I'll add some sound effects from Onslaught! Arena between conversation topics to give the listener a quick breather.

5. Put a bow on it

The last step is to include the music. I like to start the podcast off with a song, but fade it out quickly. I used to include quiet music behind the whole 'cast, but people seemed to hate that!

Lastly I really enjoy playing the show out with a song from Joshua Morse because I think he's an amazing artist and want to spread his music around.

Upcoming interviews

The next episode of Lostcast features an interview with Dominic Szablewski of Impact -- be sure to subscribe so you don't miss it!

Play around with the Lunch Bug animation preview tool

2012-04-11T00:00:00Z

Update: added frame rate controls!

I've been heads-down on art for our upcoming free-to-play game Lunch Bug and I thought I'd take a break to show you a little tool I just put together to improve my process. Have a look:

Please note that this is just the first draft of animations. Improvements are on the way!

Interact with it

In the center of the canvas is a game piece from Lunch Bug. The text in the upper-left can be pressed to play animations:

Put: this is the animation that will play when the user puts a new piece on the board.
Idle: "idle" is what we're calling animations that will play randomly when no user interaction has happened for a while. Think Sonic the Hedgehog tapping his foot!
Grow: seedlings and bulbs can grow into berries, which are worth the most points in the game.
Shrink: berries and bulbs can be shrunk (shrank? shrenk?) into pieces worth fewer points if players aren't careful!

In Lunch Bug, pieces can be "captured" by being surrounded, which changes their appearance. Normally I could just have had a giant sprite sheet with all the images for the various types of plants, but we can't have any images larger than 1024x1024 pixels due to mobile memory restraints, which meant breaking them up into multiple files.

The complication of switching the image file part-way through the animations made using traditional animation tools difficult. That's why I built this tool! Now that I've got it, I'll be going back and iterating a few more times before the final version, so at this point feedback is especially valuable.

Where's the code?

Normally I'd be open sourcing this on the Lost Decade Games GitHub account but it's tightly coupled to our internal game engine. We may open source the engine and its tools eventually but it's getting bulldozed too often to even consider it at the moment. What I can do is copypasta the code so you can get a general idea:

define([
	"djinn/Game",
	"djinn/assets",
	"djinn/Sprite",
	"djinn/TextView",
	"djinn/utils/viewEffects"
], function (Game, assets, Sprite, TextView, effects) {

	return Game.extend({

		init: function (conf) {
			// Conf
			this._super(conf);
			this.view.backgroundColor = "white";

			// Pull in the assets we need
			assets.load([
				"media/images/seedling.png",
				"media/images/bulb.png",
				"media/images/berry.png"
			]);

			// Create the sprite subject
			var state = "seedling";
			var w = 100;
			var h = 100;
			this.sprite = new Sprite({
				parent: this.view,
				image: "media/images/seedling.png",
				x: 0,
				y: 0,
				width: w,
				height: h,
				animations: {
					"default": {
						frames: [
							[0, 0]
						]
					},
					"put": {
						frameRate: 5,
						frames: [
							[w * 4, 0],
							[w * 3, 0],
							[w * 2, 0],
							[w, 0],
							[0, 0]
						],
						loop: false
					},
					"idle": {
						frameRate: 12,
						frames: [
							[0, h],
							[w, h],
							[w * 2, h],
							[w * 3, h],
							[w * 4, h]
						],
						loop: false
					},
					"grow": {
						frameRate: 8,
						frames: [
							[0, h * 2],
							[w, h * 2],
							[w * 2, h * 2],
							[w * 3, h * 2],
							[w * 4, h * 2]
						],
						loop: false
					},
					"shrink": {
						frameRate: 8,
						frames: [
							[w * 4, h * 2],
							[w * 3, h * 2],
							[w * 2, h * 2],
							[w, h * 2],
							[0, h * 2]
						],
						loop: false
					}
				}
			}).align("center", "center");

			var x = 10;
			var height = TextView.defaults.fontSize = 32;

			// Put
			var putView = new TextView({
				parent: this.view,
				text: "Put",
				x: x,
			}).align("center").on("inputStart", this, function () {
				// Setup
				this.sprite.completeTween();
				this.sprite.opacity = 0;

				// Execute
				this.sprite.playAnimation("put");
				effects.fadeIn(this.sprite, {
					duration: 500
				});
			});

			// Idle
			var idleView = new TextView({
				parent: this.view,
				text: "Idle",
				x: x,
				y: height
			}).align("center").on("inputStart", this, function () {
				this.sprite.playAnimation("idle");
			});

			// Grow
			var growView = new TextView({
				parent: this.view,
				text: "Grow",
				x: x,
				y: height * 2
			}).align("center").on("inputStart", this, function () {
				if (state == "berry") { return; }

				var onAnimationEnd = function () {
					this.sprite.off("animationEnd", this, onAnimationEnd);

					if (state == "seedling") {
						state = "bulb";
						this.sprite.image = "media/images/bulb.png";
					} else {
						state = "berry";
						this.sprite.image = "media/images/berry.png";
					}
					this.sprite.playAnimation("default");
				};

				this.sprite.on("animationEnd", this, onAnimationEnd);
				this.sprite.playAnimation("grow");
			});

			// Shrink
			var shrinkView = new TextView({
				parent: this.view,
				text: "Shrink",
				x: x,
				y: height * 3
			}).align("center").on("inputStart", this, function () {
				if (state == "seedling") { return; }

				if (state == "berry") {
					state = "bulb";
					this.sprite.image = "media/images/bulb.png";
				} else {
					state = "seedling";
					this.sprite.image = "media/images/seedling.png";
				}

				var onAnimationEnd = function () {
					this.sprite.off("animationEnd", this, onAnimationEnd);

					this.sprite.playAnimation("default");
				};

				this.sprite.on("animationEnd", this, onAnimationEnd);
				this.sprite.playAnimation("shrink");
			});
		}

	});

});

Might be easier to read in this gist. Note that the tool is not very robust as I didn't want to spend too much time on it…

More Lunch Bug news is just around the corner (can you say playable prototype?!) so be sure to subscribe to get it when it's hot. Thanks for reading!

Submitting Lunch Bug to IndieCade

2012-04-15T00:00:00Z

If you follow us on Twitter, you've already seen some screenshots of our upcoming puzzle game Lunch Bug. Last night I submitted it to IndieCade (an international festival of independent games) and I thought sharing my experience might help other devs out there.

Be prepared to write

The first thing I noticed is that they've got a huge form to fill out. I expected to be writing some information and maybe a description or something, but I wasn't prepared for this much. Their examples were helpful so I included ours:

Game description

I thought this was pretty straightforward so I just went with what we'd probably put up on the Chrome Web Store or similar places…

Lunch Bug is a unique puzzle game with gameplay similar to Othello, but with many new, distinct mechanics. Players engage in a deeply strategic puzzle game, aiming to feed the most fruit to the lunch bugs to get the highest score!

Artistic statement

You know, this one put me off a little at first because I hadn't put any thought into it. We've been in such a frenzy to get new games out, we haven't really thought about trying to make a statement.

Our first game was a very niche, extremely challenging design that only appealed to a small number of hardcore players. With Lunch Bug, we wanted to design a game that wouldn't alienate players as much, but still had something new to offer to pull them in. So we began with a design we knew and loved and added our own distinctive mechanics to the game.

Installation

IndieCade is interesting because it accepts games of any kind, including board games and paper designs. With so many differences and edge-cases, it's no wonder that terminology like "installation" gets used, even when largely irrelevant to games like Lunch Bug.

Lunch Bug can be played in any modern web browser. Please play Lunch Bug in the latest version of Google Chrome (currently 18.x) on Mac or Windows computers. Android, iPhone and iPad browsers are also supported, though some features may not be available and the experience is not ideal.

Gameplay

At first I approached this with step-by-step directions on how to play the game, but I defenestrated that idea and instead leaned heavily on our tutorial. The tutorial should be what teaches players how to play.

Since Lunch Bug is a new game design, we recommend players to follow the tutorial from the title screen to learn how to play. To get the full breadth of the game, players should play through the game until the board is full and the game is over. (New games typically only last ~5 minutes.) Lunch Bug was designed as a "slow burn" game, where players get dramatically higher scores as they improve at the game.

What's your story?

This step was unexpected too. Based on the examples, it sounded like more of a company/team culture aspect than about this particular game, so that's what I wrote:

We named our company Lost Decade because, as two web developers with ~10 years experience each, we felt like we'd somehow let a decade pass by without pursuing our dreams of making games. This is where HTML5 comes in. We're game lovers and designers at heart, but all we knew was JavaScript. With the emergence of HTML5, we could program games quickly and easily and make them instantly, widely available through the web. Lunch Bug is our first real game after quitting our jobs and jumping into the deep end to follow our dreams!

Team description

This was easy to write, especially since we've podcasted about it!

After meeting at a web job, Geoff and I quickly realized that we both were passionate about the very specific blend of games and JavaScript. We work from home M-W-F. Geoff comes to my place on Tuesdays, when we talk about goals for the coming week. Thursday I head to his place for gameplay testing and more conversation. Throughout the week we often Skype and IM.

Level of polish

This was somewhat difficult to say, as we have so many open tickets and big plans for the polish, and I had to express all of this in just a few sentences:

Lunch Bug is in active development and will be receiving weekly(ish) updates. We're redoing the title screen and user interface art and adding a new "store" feature.

Back up your data!

About halfway through taking extra care in writing decent stuff for this huge form, I somehow had the good sense to save what I was doing. I copy/pasted each of the seven text boxes into our Lost Decade Dropbox account and BOY am I glad I did, because they took so long to write that the website logged me out. I think the data actually saved into a draft, but having a backup saved me from a minor heart attack. Be wary!

Video required

I've written a guide to game development contests before, but it certainly needs updating now. My new piece of crucial advice is to go through the submission process early! If we had waited until the deadline for this step, we'd suddenly realize we have to produce a video, and may have been out of time!

This step actually wasn't too bad since I've randomly gotten some practice with iMovie recently. I started adding Lostcast to our YouTube page as well as some random time-lapse movies (because I really love those!). Anyway I've learned a lot recently so I was able to produce a video in less than an hour. And here it is:

Summary

Aside from the gigantic form and some bewildering usability problems (phone number is really buried!), the process of submitting to IndieCade wasn't too bad. The competition is stiff, but we're at the very least excited about getting some industry veterans playing our game. Why not submit your game?

Our simple new business cards

2012-04-19T00:00:00Z

Need moar cards

At GDC, I ran out of business cards and started using Geoff's. This lead to some confusing emails and a lot of forwards, which is far from ideal. After some struggling, we finally learned from this lesson, so we decided to make only one business card for Lost Decade Games when ordering new ones.

This put us on a path of simplicity. When there's only one card, there are no names. When there are no names, there are no addresses or titles (or Twitter handles, and so forth). After removing so much, we decided to take everything away and start from scratch.

At this point all we were left with was Lost Decade Games. This was the least we could have; for the cards to function, nothing else could be taken away. This seemed very clean to us, but it didn't direct people to our website. In a way, it was saying, "Just Google it," and that's not cool. That led us to introduce the full URL of our website, which seemed like enough.

But how do people know who you are?

Our thinking is that people will hit our homepage, where we have prominent navigation and a welcome module:

For more information or to get in touch, please see our contact page.

On our contact page, we have pictures of us, as well as Twitter handles and email addresses. We could definitely have an easier-to-use website (who couldn't?), but we feel that any smart people out there who know our website and want to get in touch with us should have no problem doing so.

The back

The business card industry is a strange one in that it's extremely popular with the tech world, where change happens rapidly, and yet it itself very rarely changes at all.

To me, it had this sort of feeling that you wanted your business card to match the standard measurements and all that because you knew it would be living in a stack, and people may get annoyed with the straggler that ruins the perfect edges! (Or maybe I'm just obsessive…)

But recently my wonderful girlfriend bought some adorable tiny business cards, and I noticed that I was impressed with them. They were different and apparently I was eagerly awaiting something like that for our business cards.

Pick a theme

The company we were printing with allowed for an assortment of designs with no extra charge, so I started designing the cards, and (of course!) I quickly began putting in owlbears and dragons and beholders and all kinds of designs based on creatures or objects from our games. I was about an hour in and I kind of had a random mess of designs that didn't look like they belonged together.

Then I remembered that Geoff and I used to name our projects based on medieval fantasy weapons. Our old (sadly) abandoned game Burn Tactics had a project name of flamberge, for example. We stopped using that theme a while ago because it's just not scalable. Plus, we feel that project names sometimes should be a bit more contextual than random. For instance, we were working on a proposal for a game with a modern warfare theme, which we called gasmask. It really helped to visualize the project when we talked about it!

Anyway, "medieval fantasy weapons" is a perfect theme for a box of business cards! So I began cutting all the designs that didn't match the new criteria, and the rest came out quickly and easily. And I really feel like the cohesion helps the business cards feel special.

As you can see I also made some Lava Sword cards that we'll be using after we launch the game. If you're curious, we used Moo to print our cards. If you use our referral link, we both get discounts!

permalink: "our-simple-new-business-cards/index.html" tags: [post]

Play the Onslaught! 2 prototype from late 2010

2012-04-27T00:00:00Z

During our recent interview with Dominic Szablewski, we remembered that at one point we were using his game engine ImpactJS to build our games.

A lot's happened since then… we had to abandon some projects, pivot a few times, and these days we're using our own in-house game engine called djinn.

But some prototypes have survived from our earlier days that we thought ImpactJS users might find helpful to play with. Here's an early prototype of a tenative sequel to Onslaught! Arena that we were calling Onslaught! 2:

You'll have to purchase a license to use ImpactJS, but once you do, you can fork the Onslaught! 2 source and go to town (literally)!

Play the demo

and

View the source code

The code is MIT-licensed and the graphics are "use-for-whatever-but-not-commercially". Boy I need to read more about licenses someday… Enjoy!

Free Art Friday: Lemcraft

2012-05-04T00:00:00Z

Free Art Friday is a monthly graphics giveaway I'm experimenting with. We've got a bunch of unused art sitting around, collecting digital dust. So why not give it to the community? If there's enough interest, I'll be doing more of these…

So while working with Game Closure I had some downtime to learn their SDK, so I built an entire game from scratch in about a week. It's a casual puzzle side-scrolling game I called Lemcraft (since it's essentially Lemmings meets Minecraft).

In Lemcraft, players tap the terrain to destroy it, then they can place gathered material in other areas to help the lemmings get to the end of the level.

Anyway it's gone now, lost in the abyss of stealth mode, API breakage and other stuff I won't get into. But the graphics remain! So here they are for your enjoyment and usage.

Get the art

It's up on OpenGameArt.org or you can click the ridiculously large button below to download the whole package as a zip:

Download lemcraft_art.zip (714k, 22 files)

Want more?

What do you think of Free Art Friday? If the response is positive, I'll be doing one of these on the first Friday of every month!

Choc-Onslaught!

2012-05-18T00:00:00Z

My girlfriend, Melissa, is studying to be a Pastry Chef. One of her recent projects was to create a chocolate box (A box made of chocolate which contains chocolate truffles).

Since she's a big fan of our game Onslaught! Arena, she decorated her chocolate box with characters from the game alongside an awesome looking chocolate LDG axe!

Everything you see pictured is created in chocolate of various kinds. Some parts are modeled by hand while others are molded or tempered.

The moss is made by pouring tempered chocolate over green disco sugar. I think it looks amazing!

We hope you enjoy the game in chocolate as much as we do!

The box was filled (past-tense, because I ate most of them!) with the delicious truffles you see below!

Free Art Friday 2: Bomb Party

2012-06-01T00:00:00Z

We've got a lot of unused art laying around here at Lost Decade Games. So last month I asked on Reddit if there was any interest in monthly free game art, and there was! The first Friday of each month seemed like as good a time as any to upload it, and it's that time again.

This month I'm offering up some quick pixelwork I did for a game concept we were playing with that we were calling Bomb Party. Here's the sprite sheet that you're free to use:

Download the 1:1 pixel sheet here. Use the graphics however you want, but please do credit Lost Decade Games somewhere!

If you missed last month's free art, have a look!

How to Make a Video Game on Laser Time Podcast

2012-06-04T00:00:00Z

Were you sad that there was no Lostcast yesterday? Us too, but this might help: I was recently on an episode of Laser Time, a podcast run by games journalogist Chris Antista. The episode's called Make a Video Game and we talk about things that might be familiar to Lostcast listeners, like HTML5 and independent game development.

Listen to How to Make a Video Game

If you missed it, I also co-hosted a recent episode of VGMPire, a video game music podcast ran by my friend Brett Elston. The episode's called Shining the Blues and we talk about a franchise that really influences Lost Decade -- the Shining series! It even has an exclusive Shining remix from master of funk Joshua Morse!

Listen to Shining the Blues

Tomorrow we're interviewing a Google developer for the next episode of Lostcast. We'll post that episode this upcoming Sunday!

Our mobile-optimized HTML5 game Lava Sword is looking for sponsors

2012-06-06T00:00:00Z

We recently finished our mobile-optimized HTML5 game called Lava Sword. It's a side-scrolling action game designed to be very simple, and it runs great on Android browers and Mobile Safari.

Players progress through a wooded area, wielding a big sword to fight off monsters, all while avoiding spikes and other hazards!

At the end of the game, the player's score (which is based on the number of killed monsters) is displayed. This would be a perfect time to tap into a High Score API to give the player bragging rights!

So if you're involved with a games portal who's looking for an HTML5 arcade-style game that runs great on Android/iOS browsers, please do get in touch.

P.S. Thanks to our friend Rich for the blog idea!

Polishing a Level Select screen: process and implementation

2012-06-26T00:00:00Z

We're just about ready to launch Lunch Bug, which means I've been polishing every rough edge until it shines. One of the roughest edges until just recently was the "level select" screen, where players progress through the game.

The level select screen was simple and worked fine, but it wasn't much to look at and certainly wasn't fun to interact with. Also the number of rows in each column were uneven in portrait mode. We can do better!

The plan

After some brainstorming, I came up with this plan of attack:

Break up this single screen into multiple pages to enhance the feeling of progression.
Improve the user interface regarding current goal and level unlocking.
Polish up the screens with unique graphics and animations.

1. Break it up

The first step was to split the level select screen into separate pages. Since Lunch Bug has 20 levels, 4 screens displaying 5 levels each felt like a good separation. Once the buttons were positioned correctly, I converted them into simple images instead of buttons.

In this first iteration, I also threw in "back" and "next" buttons to allow users to navigate through the pages. The steps I take are deliberately small, in an attempt to isolate potential issues early on and avoid tripping on bugs as I get deeper into the implementation.

Once I removed the large majority of buttons from the design, I noticed that the screen looked especially bare. Always on the lookout for ways to give our graphics longer legs, it occurred to me that the overhanging leaves from the title screen would work here too.

2. Better user interface

The previous level select screen wasn't just unpolished, it also had a clunky user interface. When players unlocked a new level, the button representing the next level would simply become enabled (changing its color from grey to black). Pretty lame, not very rewarding, and worst of all, not a very clear message to the player.

To fix this, I highlighted the current level button with what I ended up calling "guide bugs." I positioned these little guys in a circle around the highlighted button. This clearly messages to the player which level is next, and since they dance around, it makes the screen more entertaining to look at too.

I also added tweening animations when players unlock levels. The guide bugs swarm in on the button of the level the player just beat, then tween to the next level's button. It's a little reward to the player for finishing a level and reinforces what the player's next goal is.

3. Graphics and animation

The final step was graphical work. In place of the buttons which were only ever enabled or disabled, I wanted images with three states (locked, unlocked and current) that fit the game's theme. To solve this I opted for picnic baskets. Since they already have "closed" and "opened" states, they're easily visually mapped to "locked" and "unlocked." To represent the "current" state, I filled it with a berry and made it glow.

I also rendered the paths between levels in the same style as the background tiles in the game. This draws a visual path between the levels and helps fill the design out.

Lastly, nothing says polish like parallax scrolling! With a little Photoshop work, I made the leaves image into a repeating pattern. I then added a second leaves image stacked to the right, and after some easy tweening math, had them slowly scrolling along with the background. Parallax scrolling can be one of the simplest and most impactful visual effects to add when polishing your game.

Take it further

Polish is one of those deep holes that you can spend tons of time on, but you'll always want to add more! Once I had the paginated level select screen in place, it created the perfect situation to introduce new graphics and music to the game.

The first step was to add new repeating tile graphics to the mix. This rewards the player for progressing through the game with interesting new graphics to enjoy. Since Lunch Bug's composer Joshua Morse had already made four songs for the gameplay, it was easy to load those on the fly too.

As a strategic puzzle game, Lunch Bug can take a long time to master. The hope is that these new pages of levels will enhance the feeling of progression. Changing up the look and feel should also reinvigorate players to keep enjoying the game.

Summary

Polish can be hard work but it is absolutely mandatory if you want your game to shine. This process took about one entire week of development, but I think it was well worth it. When a part of your game isn't polished shiny, the overall experience of playing it can suffer.

Lunch Bug is the next HTML5 game from Lost Decade Games, soon to be released on Facebook, Pokki, the Chrome Web Store, Mac App Store, iOS, Android and the open web. Follow us on Twitter and we'll let you know when it's ready to play!

Firefox Audio canplay bugs

2012-07-13T00:00:00Z

We're getting geared up to launch our new game Lunch Bug, so we've (finally) been testing the game more thoroughly in browsers other than Google Chrome. In the process, it looks like I may have found a few audio bugs in Firefox.

There seem to be two bugs. The first bug is that Firefox throws the canplay and canplaythrough events twice when an audio file loads (they should only be thrown once). I could only reproduce this on Mac OS X.

Second, Firefox appears to fire the canplay and canplaythrough events when an audio instance's currentTime property is set. This is unexpected behavior and doesn't happen in other browsers. When talking with Geoff, it came up that there could be a case where this behavior might make sense: for example if currentTime was set to a value past what has loaded so far, perhaps currentTime could tell listeners that it cannot play.

However this behavior doesn't seem intentional, as it doesn't happen in other browsers and isn't mentioned (at least to my knowledge) in the W3C specification.

Show me the demonstration!

The ridiculously large button above links to the demo where you can try out the bugs for yourself, and I put the source code on GitHub.

By taking the time to create a concise demonstration, my hope is to make it easier for other developers to either help me figure out the confusion on my end, or if these are indeed bugs in Firefox, to ease the process of getting those fixed. On that note I've created two tickets using Mozilla's bug tracker:

What do you think? Was the demonstration easy to follow? Do these bugs look legitimate? If so, do you know any Mozilla engineers?

Announcing Lunch Bug!

2012-07-20T00:00:00Z

Play Lunch Bug now!

Today Geoff and I are very excited to announce our first major game in almost 2 years, Lunch Bug, a free-to-play, strategy puzzle game built using HTML5.

Lunch Bug is available to play now on Pokki, the Chrome Web Store, and the open web. It even works in mobile browsers like Mobile Safari and the Android browser! For more information, please see the landing page and media kit.

Watch the Lunch Bug trailer

Useful links

Play now in your browser
Visit the official landing page
Download the media kit

As always, we're dying to know what you think! Please play the game and tell us your thoughts on Twitter, Facebook, or via email. Thanks!

Lunch Bug 1.20.16

2012-07-23T00:00:00Z

In case you missed it, we launched Lunch Bug last week! It's available to play right now on Pokki, the Chrome Web Store and the open web. It supports modern browsers like Google Chrome and Mozilla Firefox as well as mobile browsers such as Mobile Safari and the Android browser.

We're pleased that the feedback has been overall very positive, but as always, there are improvements that can be made. I think the biggest issue with the game right now is the tutorial. In the first five levels of the game, players must go through mandatory modals and step-by-step instructions on how to play. Additionally, the tutorial first sets the expectation that there will be an "OK" button to press, but then the very next step changes the focus to the game board, confusing many players.

In version 1.20.16, I've added the ability to skip the tutorial, as well as an animated hand image to indicate when users are asked to interact with the board instead of a button. These simple changes should help make the game both easier for new players to understand and less frustrating for returning players.

What's next?

Players like the very helpful Vincent Scheib have suggested that the tutorial may introduce too much too quickly, and I definitely agree. Believe it or not, the live version of the tutorial is the fifth (or so) iteration! The early versions of the tutorial were really unintuitive, so we've come a long way. But I'd like to do at least one more from-scratch approach to the tutorial, this time focusing on transparency, simplicity, and smaller steps.

We've also talked a lot about adding new pieces and levels to the game. However, it might be a while before I can work on Lunch Bug, as Geoff and I are now in fulltime production mode for our next game Lava Blade. We've got a working prototype and Joshua Morse has already done a bunch of really amazing songs. More to come!

Lava Blade art assets and concepts

2012-07-28T00:00:00Z

We're deep into production on Lava Blade, our combat-centric platformer game with procedural content generation, and I thought I'd take a break to share some of the early art concepts.

Lars, the main character

The first thing I wanted to do is nail down the look of the main character, Lars. My thinking was that once we were happy with how he looked, it'd be easier to visualize the rest of the world around him.

First I did a rough pass on the general style, proportions, and colors (#1). This was intended to be a quick sanity check. Next I went back and better defined his shapes and detailing (#2). In #3, I added shading, highlights, and dark inner lines. I liked the way this one "popped" but I felt like it took away from his detailing, so in #4 I introduced more interior colors to replace the black. Lastly, I added hair highlights, glossier metal, and additional shading.

I'm pretty happy with how Lars turned out, though I'll probably make yet another pass (maybe to add some detail to his hands). As you can see below, I also experimented with some different styles. I wanted to see if something wonderful might accidentally happen, and make sure we were in the right place between cute and combat-ready.

The ogre

We're thinking that an ogre will have a pivotal role in teaching people how to play Lava Blade. In the beginning of the game, perhaps an ogre will kidnap someone (or do something else naughty), and you've got to chase him down, learning the game mechanics along the way.

However, I wanted him to remain relatively faceless (note the hair covering his eyes) since he wouldn't be a recurring character, like the main villain. I like to jump on inspiration when it hits, and I happened to be near some graph paper when it did, so I sketched him out quickly on paper before doing a digital version. Doing this in repetition is great for practice, and even though I didn't use the sketch, I think it helped the final product.

Since the art style was already defined by Lars, I didn't need to experiment with the ogre as much. Instead, I could simply sketch him out and render him, as seen below.

More to come

Did you see the teaser on Twitter (try clicking the characters!). We'll be putting some more scenes up there as we develop the game. Stay tuned!

Help fund Dragons Gameboard, get new Onslaught!-style pixel art

2012-08-09T00:00:00Z

The awesome team over at Brass Monkey has just launched a really interesting kickstarter called Dragons Gameboard. It's an open source, virtualized role-playing game mat that allows up to 16 simultaneous players. Instead of role-playing on a tabletop, imagine lounging around on your couch, with the gameboard visible on your television set, and everyone interacting with their mobile phones. Sounds cool to me!

As you can see from the above photo, they've got pins with Onslaught! Arena artwork that they've been using while developing prototypes. Part of the project's fund includes commissioning new, free-to-use artwork from us in that same style. So by backing Dragons Gameboard you'll also be helping our little game company out too.

Anyway it's a super cool project, created by a team that has proven they can build cool things. Speaking of which, have you played Onslaught! Arena on Brass Monkey? If not, you should! It's really cool tech that "just works" and it's neat to see Onslaught! integrated with it.

Lunch Bug now featured in the Chrome Web Store!

2012-08-15T00:00:00Z

We just received notification from a kindly Googler that Lunch Bug is now featured in the Chrome Web Store! It can be seen here on the homepage:

And also in the games section:

Please note that if you are one of the intelligent, attractive players who have already installed Lunch Bug, you won't see it featured when browsing the Chrome Web Store. Not a Chrome user? Lunch Bug is also available on Pokki and the open web. Also try it in your mobile browser!

Lunch Bug 1.20.19: tutorial bug fix

2012-08-20T00:00:00Z

This might be confusing -- there was a bug in Lunch Bug! While the game does revolve around feeding fruit to the title characters, we don't want there to be any software bugs. This particular bug was a pretty nasty one. Here's what was happening:

As you can see in the above screenshot, a tutorial window pops up on level 5, explaining the new Spade piece. As expected, many players are skipping the tutorials altogether. The problem with level 5 was that the Store button is disabled by default, assuming the tutorial would enable it at the appropriate time. But when players skipped the tutorial, the game forgot to enable the Store button.

I've fixed this bug in version 1.20.19. Not sure if you're on the right version? Try refreshing your browser and looking for the version listed on the title screen.

Lunch Bug is on FIRE!

It's great to be receiving bug reports from users, because that means people are playing the game! Did you see that Lunch Bug is currently featured on the Chrome Web Store? Well now it's on FIRE (whatever that means, but we assume it's a good thing).

If you haven't played it yet, you should right now on Pokki, the Chrome Web Store, or the open web. It works in modern browsers like Google Chrome and Mozilla Firefox as well as mobile browsers such as Mobile Safari and the Android browser. Have fun, and keep reporting those bugs!

Get the Lunch Bug OST for just two bucks

2012-08-26T00:00:00Z

Good news, everyone! The Lunch Bug original soundtrack is now available on Bandcamp. Composed by indie game composer Joshua Morse, it's yours for just $2 (USD). You can pay more if you like, which is of course appreciated. Thanks for supporting independent artists!

Listen to the Lunch Bug OST

Geoff Lava Bladed

2012-09-16T00:00:00Z

It's Geoff's birthday! As a fun little gift for the old guy, I've added a little Geoff character into the Lava Blade teaser.

And as you can see below, he'll also be a playable character!

Sorry we don't have a playable demo ready for you yet. And on that note, I'mma get back to work! Please wish Geoff a happy birthday via email or Twitter!

Join the Lava Blade alpha test!

2012-09-21T00:00:00Z

We've been making steady progress on our next game, Lava Blade. With the game nearing alpha test readiness, we're in need of brave souls to test out the game and provide feedback and bug reports.

If you'd like to receive email updates with playable alpha test links please signup. We promise to keep your email private and we'll never spam you or sell your address. Please see our privacy policy for more information.

The alpha should be ready in the next week or two so expect an email from us around that time.

Signup for Lava Blade alpha

Unfortunate Lostcast news

2012-09-23T00:00:00Z

I'm really frustrated right now. Our most recent attempt to record Lostcast failed. About 20 minutes into the conversation, we noticed that the microphone had stopped picking up Geoff's voice. The culprit was a faulty microphone connector, so I tossed the cable. That particular problem shouldn't happen again, but the wind was nonetheless taken out of our sails. To prevent an episode in which we both sounded irritated and stressed, we decided to try again later.

Fast-forward to Saturday, when we recorded an episode on Skype. We knew the audio quality would be lower than normal, but it turned out to be much worse than expected: even after we did an initial sanity pass, the audio ended up being unusable due to inexplicable crackling sounds.

So, apologies, but we're currently too swamped with development to continue failing attempts to record Lostcast. We'll try again soon!

Lava Blade alpha 0.2.1

2012-10-07T00:00:00Z

We just sent out the Lava Blade alpha to the first batch of fine players who signed up to be alpha testers. To help spot critical issues early, we're contacting alpha testers in waves. So if you signed up and haven't received an email yet, don't worry! We have your contact information and we'll get in touch shortly.

What's next?

There's still so much to do. This is just an early alpha! The next change we'll be implementing is a complete overhaul of the attack mechanic (to us, it currently feels weak and unsatisfying). After that, the game is in desperate need of a tutorial.

On top of all this, we just entered production on our next game! (More on that soon.)

Help test Lava Blade

If you haven't signed up to be an alpha tester, you can do so by filling out this form.

Game on!

Lunch Bug now available on Google Play

2012-10-11T00:00:00Z

While Android users have been able to play Lunch Bug in their mobile browsers since its launch, the game runs pretty slowly on some devices, and the sound is severely handicapped in the mobile browser. Now, thanks to CocoonJS, Lunch Bug runs beautifully, sounds great, and can be played without an Internet connection on Android devices.

Download Lunch Bug for Android

As always, we're happy to hear what you think! If you experience any issues with the game on your device, please comment below or contact us directly.

CocoonJS

Those of you at the Introduction to the Ludei HTML5 Mobile Game Dev Platform meetup yesterday already heard Geoff talking about his experience with CocoonJS. If you missed it, they'll be posting pictures (and I think video) soon. See you at the next meetup?

Play our HTML5 games on your Xbox 360

2012-10-28T00:00:00Z

A recent update to the Xbox 360 dashboard made Internet Explorer available as a free download. This is exciting news for an HTML5 game company like us, as it means that our games are now playable on Xbox 360 consoles.

In an interview with ImpactJS creator Dominic Szablewski, we talked about some of the developer frustrations revolving around Microsoft and HTML5. Dominic has his game Biolab Disaster running natively on an Xbox 360, but at a completely unplayable 3 frames per second. It's so close to working but there's no apparent interest from Microsoft to seal the deal, despite their repeated pushes into the HTML5 game space.

Microsoft has financed or otherwise produced a handful of HTML5 game projects in the past few years, including Pirates Love Daisies, Agent 008 Ball, Cut the Rope, and most recently the apparent game platform Atari Arcade.

These projects are beneficial to the HTML5 game development scene and we're glad Microsoft has sponsored them, but it does contrast the decidedly lackluster support for HTML5 on its Xbox 360 consoles.

The release of Internet Explorer on Xbox 360 is a step in the right direction. Hopefully someday you'll see our HTML5 games running natively via XBIG, but in the meantime, why not fire up Internet Explorer?

How to play our games on Xbox 360

First, download Internet Explorer onto your console. Then, open Internet Explorer and navigate it to arcade.lostdecadegames.com. Once there, it should look like this:

First, I recommend a quick game of Onslaught! Defense. I played a game and happily got my highest score ever! Fair warning, there is some awkwardness with the controls: you'll need to move Internet Explorer's cursor to the directional slider at the bottom of the screen. Hold down the A button and you should be able to control the character.

Onslaught! Defense isn't a terribly deep game, so next up how about some Lunch Bug? It feels best with a touch or click interface, but Internet Explorer's cursor is good enough. Of course, like in many other browsers, the sound playback is buggy and unreliable, but the game runs pretty smoothly and the graphics look great on a big TV.

I think you'll agree that the games show a lot of potential, but there are plenty of issues that would be largely solved by a native wrapper. For example, the audio in Lunch Bug is pretty bad in desktop and mobile browsers, but sounds great in the native Android version.

So this is really exciting and awesome, but our question is: will we get native HTML5 games on Xbox 360, or will we have to wait for the next generation of consoles? If someone at Microsoft happens to read this, please do get in touch.

Lava Blade feedback word clouds

2012-11-17T00:00:00Z

Yes indeed, the Lava Blade alpha is still going on. We're swamped with other projects, but we're eager to dive back into the game, especially after having received so much excellent feedback.

On that note, my lovely wife Andrea (a professional user researcher) has compiled some of the feedback we have so far and is beginning to examine it. Just for fun, she made word clouds out of some of the open-ended survey questions.

This data isn't really all that useful from an actual research perspective, but I think it's pretty cool to look at. It's interesting that it can give you a slight feel for the game without even having played it.

Lastly, there's this pretty large overall game pacing image that wouldn't fit into our narrow blog.

We're neck-deep into development of a realtime multiplayer game so I need to get back to the grind. You might too, if you're competing in the GitHub Game Off competition I'm judging!

On a side note, tomorrow's the one year anniversary of Lostcast and we're posting an extra-long podcast to celebrate. Hope to see your ears there!

Thanksgiving mini-jam

2012-11-22T00:00:00Z

Yesterday, I decided to take a break from bigger projects and challenge myself to a mini game jam. Making a simple game from scratch is a good way to see how our game engine is coming along. I've been wanting to do some holiday themed stuff and Thanksgiving seemed like a good excuse.

I ended up with a really simple "whack-a-mole" style game involving turkeys and pumpkins. I'm pretty happy with how far I got in ~8 hours. The art work is terrible, so you'll probably understand why Matt handles most of our artistic needs!

Without further ado, I present Turkey Hunt! The game is designed to work best on mobile so try it out on your phone or tablet. Let me know what you think in the comments.

The game ends up being pretty fun, although shallow. Perhaps I can enlist Matt's help in cleaning up the art and other loose ends at some point in the future.

I also want to take this opportunity to wish all our readers and listeners a Happy Thanksgiving! Thanks for your feedback and support on our adventures in indie game development.

Eat lots of great food, enjoy your families and be safe!

The Wii U web browser's HTML5 gaming capabilities

2012-12-09T00:00:00Z

Visit this page in your Wii U browser and play Onslaught! Defense!

HTML5 games on consoles

Several weeks ago Microsoft released Internet Explorer on the 360. In my article Play our HTML5 games on your Xbox 360 I discussed that browser's HTML5 gaming capabilities and the impact it could have on HTML5 game studios like ours. Around the same time, Nintendo launched their next-generation console Wii U, which (after a ~3GB system update) also has its own internet browser.

This isn't the first time web browsers have been available on gaming consoles. Nintendo's previous console (Wii) featured a version of Opera called Internet Channel. Sega's Dreamcast had a web browser more than 10 years ago! But now in 2012, HTML5 games are on the rise. Is Nintendo's new browser capable of running them?

The GOOD

In the Wii U's browser, I visited the Lost Decade Games arcade and was pleased that at least two of our games are playable out of the box. Here are some of the positive take-aways:

Nearly complete 2d canvas API support.
The Wii U controller's excellent d-pad maps perfectly to the arrow keys (up/down/left/right).
The A button is mapped to enter/return.

Remarkably, the browser also aced the Acid3 Test. Its rendering engine is slow but draws everything very well. Unfortunately, there's a lot more to say about what's bad.

The BAD

Using the online HTML5 Test tool (as well as a few of my own scripts), I compiled the capabilities of the Wii U browser. Here are some of those results:

No Audio support
No Web Audio API
No WebGL, WebSockets, or File API
No AppCache, some security
No WebWorkers
Framerate is very low (~10 FPS for tested games)

An Audio object exists but it doesn't support any standard audio formats (such as mp3, ogg, or even wav). Sadly there's no WebGL support at all. Though the localStorage object exists and will accept commands to get and set data, the local storage data is wiped when the browser is closed, breaking its functionality completely.

It DOES play games!

Although there's no audio, you can't save your game, and the framerate is terrible, two of our games are playable. Lunch Bug is even monetized via Google Wallet, though without a working local storage, there's really no point in buying anything.

If you only end up playing only one HTML5 game in your Wii U browser, make it Onslaught! Defense. I added keyboard functionality today, and since the Wii U controller's d-pad maps to the arrow keys, you can even play the game with the d-pad.

Wii U controller's browser commands

Lastly, here's what seem to be the default browser commands of the controller's buttons:

A: mouse click or enter/return key equivalent (USABLE!)
B: history.back()
Y: open bookmarks
X: toggle TV visibility
d-pad: arrow keys (USABLE!)
Left stick: pan
Right stick: zoom
-: zoom out
+: zoom in
L/R: history.back/forward
LZ/RZ: previous/next tab

(Feel free to correct me if I'm wrong about any of these.)

We'll discuss the Wii U and its web browser in the next episode of Lostcast, our independent gamedev podcast. You should tune in!

Indie life: high quality photos of us making games

2012-12-21T00:00:00Z

Recently a friend of a friend contacted me about doing a photoshoot with us. She's a local photographer and was looking for subjects that would fit a "startups in startup environments" kind of vibe. Naturally, we were game!

So Maki of Maki Photography came by one afternoon and shot us doin' our thing. We'd be coding or whiteboarding and she'd be running around looking for and taking excellent shots. She has created a gallery of 36 of these photos on her website.

I've also included a few I liked quite a bit right here; click any image for a high resolution version.

Our games on many devices

A culture of cats

Double-Dragoning

Lostcast

Our games run on cats

Matt at the home studio

Whiteboarding fun stuff

A lost portrait

Maki Photography

Maki has a great eye for a good shot and is really fun and easy to work with. If you're looking for a photographer local to the bay area, be sure to contact her!

Lost Decade's goals for 2013

2013-01-07T00:00:00Z

Goals are important. Without them, it can be difficult to gauge your progress, and that makes it hard to tell how much ass you're kicking! Geoff and I banged out some goals for this year and I thought I'd share them with you.

1. Make $100,000 total revenue

Unfortunately, money is the most fundamental aspect of staying independent. Rent is due, and somebody's got to pay it! We made a little more than half of this amount in 2012, and we want to stay ambitious, so this seemed like a nice, round number.

It's ambitious but doable. In order to achieve this number we're going to need to hit one of these bullet points really hard:

Pursue passive revenue streams
Sell game licenses
Find development contracts

We're most interested in passive revenue streams. Really successful indies are making money in their sleep, and our goal is to join them. Game licenses are the most immediate way to pay rent, but the HTML5 game market is very young and tumultuous (translation: it's unreliable). Lastly, development contracts were far and away our biggest earner last year, but were also the most demanding of our time.

2. Make $1,000 in passive revenue during a single month

In our best month last year we made a few hundred dollars in passive revenue, but spikes like that typically only happen when a game is launched or first introduced to a new platform/market. Payouts from portals like AOL and Kongregate have been sadly lackluster so we'll be busy this year trying to dig up great portals for our games where we can share in the advertising and IAP revenue.

3. Get a news story on a popular games news site

I'm proud and happy about our coverage on VentureBeat last year, as well as our coverage on TechCrunch in 2011 (even if we aren't the focus in the former). But we want our games to be put directly in from of gamers as well as entrepeneurs and techies.

Getting high-profile media coverage for indie games is extremely difficult to say the least, but offerings like Joystiq's Indie Pitch are a big step in our direction. Rock, Paper, Shotgun is also known to be very indie-friendly, though it may be difficult to get their attention as browser-based developers.

Either way we're hoping to somehow garner the media's attention and get many gamers playing our games!

4. Get 5,000 Twitter followers

I was really stoked last year when we reached 1,000 Twitter followers, but each 100 feels like a sprint. As of this writing, we're not even 100 over that first 1k yet, and though I'd love to shoot for 10,000 followers, it doesn't yet feel like a reachable goal. So I'd be really happy with 5,000 by this time next year. Help us out by retweeting our stuff!

Last year

We met two of our goals from last year: get 1,000 Twitter followers and get 10,000 unique hits in a month. Both of these milestones were hit near the end of the year; we just barely made it.

Developers! Developers! Developers!

Notice that our goals list doesn't include a bullet point like, "Launch 5 games." Our primary focus is always developing games, and we will release several games this year (as you'll soon see!), but we don't want to restrict ourselves to an arbitrary number. We're not even sure what exactly we need to stay afloat just yet, but the world is an ever-hungry bottomless pit of desire for games, so we'll keep cranking them out and experimenting with ways to make them profitable.

Wish us luck, and thanks for your support!

Asylum Night: making a tower defense game in 48 hours

2013-01-15T00:00:00Z

We recently participated in Indie Speed Run, a new game jam apparently started by some members of The Escapist. Those who have already been exposed to other popular game jams such as Ludum Dare or Global Game Jam may find Indie Speed Run very familiar -- developers have a 48-hour window in which to develop a game based on a randomly generated theme (and in this case, element).

Indie Speed Run offered some unique additions to the typical game jam format. Of all the game jams out there, we chose to participate in this one for the following reasons:

Well respected group of judges helped legitimize the contest (also, who wouldn't love for Notch or Yahtzee to play their games?).
Ability to use your own tools without having to open source them.
Developers choose the 48-hour window that works for them.

Additionally, Indie Speed Run had a $25 entry fee which, while it probably turned off a few teams, surprisingly made us feel better about the whole process. It's a small amount of money that acted as a barrier to entry, meaning that only dedicated developers would participate.

Our game: Asylum Night

Our randomly-generated theme and element were telepathy and booby-traps, respectively. We looked each up on Wikipedia and dictionaries to ensure that our understanding was correct (and to help give us ideas). One common trait of telepathy is that it can be used to move objects, which plays well with the booby-traps element. So we wanted to make a game where booby-traps could either be set or disabled by using one's mind.

Though we were obviously on a tight deadline, we knew that allocating several hours for game design would pay off in the end. So we rapidly discussed and threw out several concepts for various games. Pretty early on we settled on a mental hospital for the skin (graphics) of the game. Asylum Night could have been about a telepathic person in a castle or on the moon, but with the telepathy theme it seemed appropriate for the game to exist in a place dedicated to the mind.

We liked the idea of a player trying to navigate through a maze riddled with booby-traps, disarming them with telepathic abilities. But we know from experience that mazes need to be relatively deep and large to be compelling, which meant a scrolling tilemap and time we didn't have dedicated to content generation. A game where all the action took place on a single screen seemed doable, and we wanted something that simple so we'd have plenty of time to polish it up.

Additionally, we preferred a side-scrolling perspective. Since we were allowed to use our internal tools in this game jam, we wanted to use them! One of our more powerful tools, the Doll Animation Tool, allows us to animate 2d sprites cheaply and effectively. For those familiar with the popular Kickstarter project Spriter, it's a very similar tool.

After several ideas that didn't pan out, we settled on a tower defense game. Players would control a telepath kept in an insane asylum operated by murderous doctors. Using their telepathic powers, they could knock out doctors directly or set booby-traps to help protect them. The first day, Geoff banged out the game's model, I began working on art concepts, and Joshua Morse started composing music.

Geoff did a fantastic job with the game model. On the second night, I was playing through the game and it had a drastic difficulty spike. We wanted the game to be about surviving a week in an insane asylum, but on the fourth day the game became impossibly hard. Doctors would inevitably overrun the player and there was nothing, mathematically, that the player could do about it.

But on the second night, Geoff committed a major update to the model. After three more sessions, I was able to beat the game -- but just barely! This demonstrated the game's depth and learning curve. I think it's a game now that's impossible to beat on the first (or second!) play, but can be mastered with practice and learning. This is all Geoff's doing and I think it turned out great.

Joshua Morse also did a terrific job with the audio. The funky title screen can really get you into the groove! Joshua also took extra care to note when sounds would be repetitive and took steps to make them pleasing when they could easily have been irritating. You may notice while playing: sounds that happen often such as the use of basic abilities or doctors dying cycle through a handful of slightly different sounds. This means that if you kill three doctors in a row, you'll hear three distinct sounds, which I think makes the game much more enjoyable.

Mini-mortem

We're really pleased with how Asylum Night came out, but it took more out of us than we expected. The second night, Geoff and I were both on 4-5 hours of sleep, which bled into the next day. So though we only planned for a 48-hour window, it ended up costing us 3-4 days of lost productivity on other projects. We could have avoided this by scoping the game down even more, or by cutting unnecessary polish.

On the plus side, I think we were able to deliver a very playable game in the allotted time. We also learned a lot in the process, such as when (and where) to cut corners to increase productivity, and the great feeling of motivation that comes from shipping immediately. This was the first 48-hour game jam for all three of us, and it was a wonderful experience. If you've been thinking about participating in a game jam but never have, consider this a gentle nudge!

What's next for Asylum Night?

As a young independent company, we need to be frugal with regards to how we spend our time. We literally wouldn't have been able to afford to dedicate a couple of days to Indie Speed Run if we didn't think we could use the game to help pay our bills. With that in mind, we designed Asylum Night from the ground up to be mobile-friendly so that we could add it to our growing portfolio of HTML5 portal games. If you've got an Android or iOS device, play Asylum Night in the browser -- it runs surprisingly well!

Additionally, designing for mobile will make it easy for us to launch the game natively on Android and iOS using Ludei's CocoonJS platform, so the next time you see Asylum Night, hopefully it will be in the App Store and Google Play.

Lava Blade alpha 0.5.44

2013-03-25T00:00:00Z

We just sent out the latest Lava Blade alpha to our mailing list. If you signed up and haven't received an email yet, don't worry! We're sending the game out in waves; we have your contact information and will get in touch shortly.

Want to sign up to alpha test?

If you haven't signed up to be an alpha tester, you can do so by filling out this form.

Whoa, this is really different!

Yeah, if you played the previous Lava Blade alpha you may notice that things are quite different. What was once a side-scrolling platformer is now a turn-based strategy RPG. That's quite a drastic change! Those interested in the reasoning behind this could have a listen to our recent podcast where we discussed this.

Game on!

Play our new game Treasure Goblin

2013-03-27T00:00:00Z

Today we're happy to announce our new game Treasure Goblin, also available on the Chrome Web Store!

Treasure Goblin is a free, gamepad-enabled, side-scrolling platformer built in HTML5. Players control a nimble goblin who explores dangerous caves in search of treasure. The game features tight controls, procedurally generated levels, achievements, and of course, lots of treasure!

Play Treasure Goblin

Play our new game Treasure Geoff

2013-04-01T00:00:00Z

Today we're happy to announce our new game Treasure Geoff!

Treasure Geoff is a free, gamepad-enabled, side-scrolling platformer built in HTML5. Players control a nimble Geoff who explores dangerous caves in search of treasure. The game features tight controls, procedurally generated levels, achievements, and of course, lots of treasure!

Play Treasure Geoff

Lava Blade now available on Chrome Web Store

2013-04-11T00:00:00Z

Today we're pleased to announce Lava Blade, our new tactical strategy RPG, now available on the Chrome Web Store. In Lava Blade, players control the mighty warrior Lars as he ventures towards a dangerous volcano to retrieve the sacred sword, Lava Blade!

Features

Turn-based tactical combat
Five unlockable party members
Dozens of weapons including swords, warhammers, shurikens, and more
Hordes of monsters including goblins, lizardmen, and demons
Three environments to explore
Three unique boss encounters

Buy on Chrome Web Store Play the demo

Screenshots

For high resolution screenshots, please download the Lava Blade media kit.

Get the Lava Blade OST

The Lava Blade Original Soundtrack is available for purchase on Bandcamp for the low, low price of $3. Support independent musicians and get an amazing soundtrack for cheap!

Coming soon to another platform near you

We're working hard on getting Lava Blade on more platforms including Pokki, Android, iPhone, Windows desktop, and OS X.

Lava Blade arrives on Mac OS X

2013-04-18T00:00:00Z

Following the release of Lava Blade on Chrome Web Store we're excited to bring you Lava Blade on Mac OS X. The Mac version of Lava Blade installs easily, works offline and contains absolutely no DRM!

Buy on Mac OS X Play the demo

Screenshots

For high resolution screenshots, please download the Lava Blade media kit.

Get the Lava Blade OST

The Lava Blade Original Soundtrack is available for purchase on Bandcamp for the low, low price of $3. Support independent musicians and get an amazing soundtrack for cheap!

Coming soon to more platforms

We're still working hard to bring you Lava Blade on more platforms including Pokki, Android, iPhone, and Windows desktop.

Mailbag: Frameworks, Canvas vs DOM, Native mobile

2013-04-19T00:00:00Z

We often get email from readers or podcast listeners asking to expand on certain topics. Many of these questions can be of value to all our readers so I'm going to start posting them Q&A style on the blog now and then. So, without further ado, on to this installment of LDG Mailbag!

JavaScript Frameworks

Firstly, I notice you don’t appear to use any Javascript frameworks for your projects. Is there a particular reason for this? I tend to use MooTools for the majority of apps as it just means that things are a bit simpler and more straight forward to code but over the past few months have been wondering if this is the right thing to do.

We've developed our own JavaScript game framework over the last year or so, called Djinn. It's a heavily canvas based game framework because we prefer to use canvas rather than DOM (more on that in the next question).

When we started developing HTML5 games, the available canvas based frameworks were few and far between. Since Matt and I have lots of JavaScript experience we decided to roll our own framework tailored exactly to our needs. However, that's not a choice I would recommend to everyone developing HTML5 games. There are a number of mature game frameworks out there these days and developing your own takes time away from actually creating games.

I'd suggest using a game focused framework as opposed to something like jQuery or MooTools because most of them weren't created specifically for browser based games. That said, if you're familiar with a certain framework and you're creating a DOM based game then it could be a good choice for your needs.

If you're looking for a game framework I'd have a look at ImpactJS. You'll need to purchase a license, but it's totally worth it in my opinion. Checkout our interview with Domenic Dominic Szablewski, the creator of ImpactJS.

There are some open source options available as well, such as Crafty. Louis Stowasser, the creator, was also a guest on Lostcast.

At the end of the day, you'll want to be using whatever framework fits your particular needs, coding style and project requirements. For example, a side-scrolling action game is much easier to develop building on ImpactJS than jQuery. However, a text or menu based game might be easier to develop using a more DOM centric framework.

Canvas vs DOM

The canvas object is featured very heavily in your games. I played about with canvas coding in 2010(ish) and was put off by the very limited support in some browsers. I know that the baseline browser has significantly improved but does the canvas offer that much improvement over moving elements on the page? Generally I will change the position of a div element (or similar) to move something but know the canvas can do this.

Canvas support and performance is definitely much better these days. The canvas API has always been pretty straight-forward which makes browser differences less likely. At its core, canvas is all about copying pixel data from images to the canvas and isn't as affected by the DOM box model or other browser specific layout quirks.

I find JavaScript to be a very elegant language (sans the DOM). Instead of our games consisting of a bunch of code spread out across HTML, CSS and JavaScript we have almost no HTML and CSS code to deal with and maintain.

I personally like the canvas approach more because the concepts are closer to traditional game development. Some developers choose to go a hybrid route with canvas and DOM, but I prefer to keep our stack homogeneous. One benefit of that choice is that all our UI elements can be layered and animated in the same way as our in-game sprites.

Canvas also has a bunch of cool features including filling and stroking paths and compositing operations. Some of these can be replicated in DOM, but not as cleanly.

A downside to canvas is that being so low-level, you'll have to handle certain tasks yourself that the DOM would provide for free. For example, when rendering text in canvas you'll need to handle text wrapping explicitly. User input controls is another area where DOM gives you a leg up, but in my experience it's been pretty easy to create re-usable canvas based input controls with our framework.

I believe that canvas based JavaScript code is more portable as well. There are quite a few native wrappers out there (such as CocoonJS or Game Closure) which simply execute your code inside one of the various JavaScript virtual machines (V8, SpiderMonkey, JavaScriptCore, etc.) and implement the canvas calls behind the scenes using OpenGL or whatever graphics engine exists on that platform.

Again, using canvas, DOM or both definitely comes down to personal preference and project needs. The closer your game is to a tradional web app, the more you are likely to lean towards the DOM.

Native mobile

Finally I read the post about using the Game Closure framework to get Onslaught! Arena running on an iPad. At the end of last year I had to develop my iPad orientated first web app (an interactive publication for a customer) and although I got quite a few things working OK such as finger swipes and similar, developing for the iPad clearly requires a slightly different approach to a regular web app. To this end it’s an area that I’m really trying to push myself to learn more and possibly start developing some native apps. Looking at the Game Closure site, it appears to basically be a development server for static html5 applications and a fully fledged JS framework, plus a compiler. Did you have to recode parts of your game using their framework or did it largely just import in OK? Are there any pitfalls you found when using it?

Integrating Onslaught! Arena with Game Closure's tech was pretty easy. We had developed the game with a few main entry points such as handling input, updating the game world and rendering the game. Game Closure's framework took a similar approach so we simply wired up their handlers to ours and everything mostly just worked.

While it was easy to wire up our existing game code, the end result wasn't extremely maintainable or able to leverage the advanced features of Game Closure's stack. To get the most benefit out of any JavaScript framework or development environment you should really build your game from the ground up on that platform.

I think the primary selling point of using Game Closure would be that it solves the framework, IDE and deployment hurdles in a single tool.

There are some framework agnostic solutions out there as well, such as CocoonJS or PhoneGap which will natively wrap pretty much any JavaScript game. My understanding is that PhoneGap embeds a browser which means it can handle CSS and DOM based games, while CocoonJS is better for primarily canvas based games as it maps canvas calls to OpenGL behind the scenes instead of relying on browser rendering.

Got questions?

Ask your own questions by contacting us or posting a question in the comments section below!

Lava Blade arrives on Windows

2013-04-24T00:00:00Z

We're pleased to announce that Lava Blade is now available on Windows! As with the Mac OS X release, the game runs offline and does not include any DRM.

Buy on Windows Play the demo

Screenshots

For high resolution screenshots, please download the Lava Blade media kit.

Get the Lava Blade OST

The Lava Blade Original Soundtrack is available for purchase on Bandcamp for the low, low price of $3. Support independent musicians and get an amazing soundtrack for cheap!

Coming soon to mobile platforms

Lava Blade is coming soon to your Android or iOS device!

Rampart Rush Beta

2013-04-25T00:00:00Z

Rampart Rush is our new defensive shoot 'em up. Players control a warrior fighting off hordes of monsters with swords, daggers, shurikens, fireballs, and more! Players can also place buildings in their castle grounds, such as a Weapon Shop to buy more weapons, or a Magic School to learn more powerful magic.

Join the mailing list

We're rolling out the Rampart Rush beta to our mailing list so they can help us find bugs before launch. To join our mailing list, just fill out this form.

Game on!

Geoff's List of Awesome OS X Apps

2013-04-26T00:00:00Z

I've been using a MacBook Pro as my primary development machine for 6+ years now. As such, I've collected a bunch of great OS X applications which make my life easier.

Today, in the same vein as The Setup, I'd like to share some of my favorite apps. Many of these apps require you to purchase a license, but most are in the $5-15 range. Quite a steal, if you ask me.

Although I'm linking to each app's homepage, many of them are also available from the Mac App Store. When I can, I'll choose to purchase/download apps from there since it's easier to stay up-to-date with newer versions.

Some of these apps have previously been mentioned on Lostcast, but I've picked up a few new ones since recording that episode.

Enough talk! Here is my list of awesome OS X apps, in alphabetical order:

1Password

1Password is an excellent password manager and one of the apps that I don't know how I ever lived without. It has great organizational features and can store other bits of sensitive information such as credit card numbers and software licenses.

I create unique, complex passphrases for various sites so that if any particular service is hacked I don't need to change a bunch of different passwords.

Dropbox can be used to store your 1Password keychain and sync your data across multiple devices. I personally use the Mac desktop and Android versions every day.

If you're not using some kind of password manager stop reading here and go download one.

Alfred

Alfred is another app I use many times a day, every single day. Aside from just launching apps quickly from a hotkey, you can also search your files for certain documents, look up word definitions or spelling. My personal favorite is using the calculator to perform quick math operations in order to check some game development math.

I cannot say enough good things about Alfred. The base version is free but you should buy the Powerpack in order to support the developer.

Balsamiq

Creating mockups is a great way to visualize game flow and UI elements. I've found Balsamiq really easy to use and it comes with a ton of standard UI elements that cover most use cases. This one is a bit pricey, but totally worth it.

Caffeine

A useful little app which allows you to keep your Mac awake (or not) with a simple toggle in the menu bar. Great for presenting.

ColorSnapper

Need to grab an RGB or hex color value from anywhere on your screen? ColorSnapper does the job with a simple hotkey. In addition, it keeps a log of recently used color values which is very handy.

Daisy Disk

Want to know what's taking up all your hard disk space? Fan of pretty graphs? Daisy Disk provides a great visualization of space usage and allows you to drill down into various sections.

If you're looking for a free alternative, try out Disk Inventory X.

Divvy

Managing windows sizes on a Mac is a terrible experience. Luckily, Divvy makes that problem go away. With a simple set of user-defined hotkeys you can snap applications to full screen, half screen (left or right) and any other size and position of your choosing.

DMGCanvas

I just recently discovered DMGCanvas while creating our Mac installer for Lava Blade. This simple app allows you to create professional looking disk images (.dmg files) for your games. Easy WYSIWYG editor for adding background images, text, shortcuts and files to your disk image.

The built-in Disk Utility in OS X can do some of these same tasks, but it's a little more complicated and involves using the command line.

DragonDrop

A handy drag and drop buffer. DragonDrop is invoked by dragging some files and wiggling the mouse. The buffer floats above all other windows making it easy to then drag the contents into another application. I mostly use this for batching up files to attach to emails.

f.lux

Automatically adjusts screen brightness to coincide with time of day. Great for working on games in the middle of the night in bed!

Icon Slate

Handy little app for creating .ico and .icns files, among others. As we start supporting more and more platforms, I'm finding this app to be a great resource.

Kaleidoscope

I personally cannot stand reading source code diffs in Terminal. Kaleidoscope is a clean and simple diff viewer which can be integrated with many source control systems. I use it as my git diff tool and I can't begin to count the number of times I use this app every day. It also diffs images!

Less.app

CSS sucks. LESS makes it suck a little less. Less.app is a handy tools that scans LESS files and automatically compiles them into CSS on the fly.

There's also CodeKit from the same developer, which compiles many more types as well as LESS.

Marked

An excellent Markdown viewer. These kinds of apps are a dime a dozen, but Marked is the best one I've used. I typically write Markdown in Sublime Text 2 and view the results live in Marked. (Using Divvy to snap each application to one half of the screen.)

Pixelmator

I find Photoshop to be too expensive and bloated for my tastes. Pixelmator is a great alternative for OS X users and has many of the same features. This is my go-to image editing software for games and the web.

Reggy

I'm a big fan of small apps that serve a very specific purpose. Reggy is an excellent tool for testing and debugging regular expressions on the fly.

Sublime Text 2

My text/code editor of choice! I could probably write a whole blog post on the awesomeness that is Sublime Text 2. For now, I'll just say that if you're more of a TextMate person than a Vim person, Sublime Text is for you!

What about you?

What are some of your favorite OS X apps? Let us know in the comments!

Lava Blade 1.1 and Steam Greenlight

2013-05-10T00:00:00Z

Hot on the heels of our initial release of Lava Blade, we've just pushed out the first content and bug fix patch! Lava Blade 1.1 is now available on all 3 of the currently released platforms: Chrome Web Store, PC, and Mac. CWS users should see the update automatically while PC & Mac users can download the new version via their original download link from BMT Micro.

The 1.1 update includes:

Extended Forest and Swamp zones
3 new types of goblins: Sappers, Shaman and Raiders
3 new types of Trogs: Slaves, Elites and Cultists
2 new, unique boss encounters in the extended Forest and Swamp

In addition to this content update, we've also put Lava Blade up on Steam Greenlight!

Lava Blade on Steam Greenlight

Steam can be a great distrubution channel for independent studios like ours. Please help us prove that HTML5 games are ready for prime time by voting YES!

Vote for Lava Blade on Steam Greenlight

Play Crypt Run at California Extreme July 13-14

2013-06-27T00:00:00Z

Want to play our upcoming game Crypt Run? Then you should come to our LIVE DEMO next month!

What?!

California Extreme is an annual arcade and pinball convention held in the California bay area. It's basically a huge room packed with tons of classic arcade cabinets (it's super awesome).

This year, we'll have an 8-foot table (that's ~2.5 meters for our Metric friends) with at least one computer set up to play an early preview of Crypt Run. We'll be giving out stickers, high-fives, and possibly some other cool stuff.

When?

California Extreme 2013 lasts two days:

Saturday July 13th: 11am - 2am PST
Sunday July 14th: 11am - 9pm PST

Where?

California Extreme takes place at the Hyatt Regency Santa Clara in Santa Clara, California. Their address is:

Hyatt Regency Santa Clara 5101 Great America Parkway Santa Clara, California, USA, 95054

Registration

If you're interested in going, you can register online or buy tickets at the door. Looks like it's $40 for Saturday, $30 for Sunday, or $60 for the whole weekend. My wife and I go every year and it's always a ton of fun.

We hope to see you there!

The making of the Indie B-Side, Vol. 1 album cover

2013-07-05T00:00:00Z

Video game composer and arranger Joshua Morse just released his new album Indie B-Side, Vol. 1. It features eight arrangements from indie darlings such as FEZ and it's pay-what-you-want!

Joshua tapped me to do the album art. He had the idea of a vinyl record sleeve with the disc slightly exposed, and he wanted it to be in a low-resolution pixelart style. Given these directions, I first drew a quick sketch to see if we had the same vision.

Once Joshua gave it the thumbs up, I started placing pixels. The first element I wanted to tackle was the sleeve, since I thought it would be an "easy win" that would get the ball rolling. I knew I wanted the cube to be orange so I made the sleeve mostly blue to complement the cube.

As you can see, I dithered the edges to give them the appearance of fading out. The top and right sides are intended to look as if they're slightly raised, as cardboard-like materials tend to do near their edges.

I easily spent the most time on the cube. I really wanted it to draw the eye so I gave it dramatic, high contrast lighting. As you can see from the below animated gif, it went through many iterations before I ~~was satisfied~~ ran out of time.

Below is what I guess I'd call a beta. It was almost there, but the text definitely needed to be more fun to read. I made the text big and fat enough that it squeezed out the room leftover for "Vol. 1". This forced me to be creative and move that text to the record label. I believe this demonstrates a benefit of limitations!

The cube looked fine to me, but it wasn't interesting enough. I wanted it to look more like it was made of Tetris pieces shoved together (I imagine that's how the FEZ cube was envisioned), so I combined many of the cells and made the ridges much softer.

Want to see the tiny, unscaled version of the final album cover? It's here. Now go check out the album, it's awesome!

More to come

Joshua's already working on Waveform 5, and we've got fun stuff planned for the album art. For the next one I'll even do a timelapse (aren't those fun?)!

Announcing Crypt Run on Kickstarter

2013-07-12T00:00:00Z

Huge news from Lost Decade! Today we're SUPER excited to launch a crowd-funding effort on Kickstarter.

Crypt Run is a medieval fantasy hack 'n slash for Windows and Mac. Play the alpha in your browser, back us on Kickstarter to receive your reward, and PLEASE help us spread the word!

Our first week on Kickstarter: The Numbers

2013-07-19T00:00:00Z

It's been exactly one week since we launched Crypt Run on Kickstarter, and since it's a 30-day campaign, that means it's 25% over. What a great time to reflect on the week, examine the trends, and see where this campaign is headed!

We launched via an email blast to our mailing list of about 200 fine human beings, as well as the mandatory blog, tweet, and Facebook post. I'm not aware of a way to check, but if memory serves, we closed our first day at around $2,000. One of our biggest and most awesome fans even contributed $1,000 (and claimed NO reward), which is just incredible.

California Extreme

The very next day (Saturday July 13th) we did a live demo at California Extreme, which is an annual arcade and pinball expo in Santa Clara. This was an exhausting day, lasting from 9am-3am (we each basically worked 18-hour shifts that day). This was our first live demo and it was exciting and educating. We made some amazing connections, including a Sony rep, that have the potential to be beneficial in the future.

Crypt Run performed surpsingly well, especially with young males (around 8-15 years old). One enthusiastic young gamer played for FOUR HOURS straight! The pledges kept coming in throughout the day, energizing us when fatigue kicked in. Our friend Ricky came by and took high-quality pictures with fancy lenses, which I'll upload soon.

Sunday was much less extreme (pun intended). The expo was only open 11am-9pm, and the crowds were much thinner. We even had some time to play a few games ourselves! Over the weekend, we gave away hundreds of stickers with "cryptrun.com" printed on them, and the pledges continued to come in steadily.

Sometimes it's impossible to tell where exactly a pledge came from, but through emails and messages from backers, we know that a few hundred dollars came in directly because of California Extreme. Overall the live demo was a fantastic success and was just what this campaign needed to help its launch.

The Weekend is Over

Monday, the pledges really hit the breaks. Up until Monday, I'd wake up to several new pledge notifications and they'd be relatively common throughout the day. Starting Monday, there was just one new pledge, and then only a small trickle throughout the day. This would be the trend throughout the week.

Tuesday was more of the same. We did the math, and at this point we needed about $75/day worth of pledges to make our $5,000 goal. Fortunately around this time I was doing nothing but media outreach, trying to establish relationships, and emailing anyone on the planet that I thought might care and be able to make a difference. Which leads us to…

Media Response

Crypt Run hasn't had a ton of coverage yet, but it's only been a week, and I think these things take time. I do feel like we've been lucky with the coverage that we have had. Here are the ones that I'm aware of:

(Please contact me if you have a URL to add to this list!)

I've also had promising discussions with Indie Game Mag and Fund This Game, and I'm really hoping that Rock, Paper, Shotgun will include Crypt Run in its weekly Kickstarter Katchup series.

Reddit Promotion

We also tried a Reddit promo where you can play as the Reddit alien. Kind of a stunt, I don't know man, we're just experimenting. It didn't go terribly well but there's a small chance somebody saw it and pledged. You've gotta try, right?

GET TO THE NUMBERS!

OK! As of this writing, Crypt Run is 67% funded ($3,350 out of $5,000). Here are the stats that are available on Kickstarter's website:

(Click any of these pics to view a larger version.)

The above pie chart shows that $566 were pledged via Kickstarter. This means that these pledges came directly from Kickstarter's own discovery channels, such as the recently launched and games category pages.

This graph shows the overall progress of the campaign. As you can see, it started off strong, but its ascent has slowed considerably.

What's Next?

Good news if you're a fan of Lostcast (or podcasts in general), because Geoff and I will be on an episode of DarkCast next week. We'll also be recording a new "The Story Behind Crypt Run" video, as well as pushing out a new alpha build with many bug fixes and improvements.

We'll also be at Indie Prize Showcase which is a part of Casual Connect in San Francisco. This is a live 3-day demo that, thanks to California Extreme, we now feel well-prepared for.

Overall, our first week went really well, and we're very happy with the results and the current state of the campaign. It's now clear to us, though, that Kickstarter campaigns are a lot of work, the lion's share of which takes place AFTER the campaign has launched.

High quality photos of our California Extreme demo

2013-07-22T00:00:00Z

The live demo was so much fun! Big thanks to our friend Ricky for taking these excellent photos! If it's easier, check out these photos on imgur.

(Click on any image to viewer a larger version.)

We're also demoing Crypt Run at Indie Prize Showcase next week, so stop by if you can!

Half-time! 15 days left in the Crypt Run Kickstarter campaign

2013-07-26T00:00:00Z

What a crazy couple of weeks! There are only 15 days left in the Crypt Run Kickstarter campaign, which seemed like a great time for a recap of what's been happening.

With 164 backers, we're currently at 86% of our goal. Thank you! These promising numbers, combined with our 3-day demo at Indie Prize Showcase next week, give us a lot of confidence that we'll be able to finish this game for you! To keep the momentum going, we've been pushing hard on updates, including…

Another way to pay

If you're subscribed to our mailing list or already backing the Kickstarter, you may have heard about Crypt Run's new Humble Store widgets. These widgets allow you to use any payment service you prefer, via PayPal or Google Wallet.

Introducing a new reward tier

Some wonderful people informed us that they wanted to make their mark on Crypt Run, but that the $100 in-game portrait reward was a bit too pricey. We listened, and have introduced a new reward tier at $50, for which you get to label a tombstone in a special room in the cemetery dungeon. We don't yet know exactly how this will work, but we'll do something cool with it, promise!

JumpToGamer interview

I had a great email conversation with Stefan Richings of JumpToGamer, which led to this thoughtful and well-written article. Check it out!

Game Front's Indie Gems spotlight

Oh man, it's so hard to watch someone playing your unfinished game! But I'm still really excited about Crypt Run's Indie Gems spotlight on Game Front:

DarkCast podcast

Lastly, good news for Lostcast fans: we were on another podcast called DarkCast! It's over an hour of Crypt Run and general gaming chat, have a listen!

I think that's everything, at least for now. Thanks for reading, and YOU! You have yourself a great weekend. Thanks again for your support!

Crypt Run alpha 0.0.95

2013-07-27T00:00:00Z

We've been working hard! Here's the massive changelog since the last version of Crypt Run you've played. These changes are now live on the web-based demo:

Support enter/return keys anywhere space is supported
boomBarrel, boomSpear tweaks
Tutorial flow tweaks; introduce resurrection object
zombieGraveRobbers are role=monster by default
Cleanup dungeon seeding so the player isn't stuck in a specific challenge
Art for shattering ice block; fix a step script bug
Don't start music from beginning on unpause
Play sound effects when counting up numbers on results screens
Add shovel sounds
Fix white border bug when fading out after death
Make player face direction of dungeon room when exiting a room
improve step enraged behavior with a few more properties
probably fixes: (zombie)GraveRobbers get stuck on solids
Polish ResultsScene & ProgressScene
Polish plants shooting fireballs
give humanoids blood 'n guts; set groundwork for plant polish
Art/polish for blinking shopKeeper
Determine loot drops at generation; loot tables are now zone specific
New challenge UI
Add zombieGraveRobber to zombieRoom and graveHeist
zombieGraveRobber; direBat health nerf
don't piss off the new graveRobber
intl tweak; Add required scenario rooms; clean up scenario data; add tombstoneRoom requored scen
Private PRNG for dungeon generation
Triple Dagger intl
?killerBees=1 to start with killerBees
Get killer bee's buzz sound to work
Container lootTables are attached at generation time
looping ogg files
Reduce chance of mimic traps; give mimics a proper loot table
Increase healthPotion cost (HP = 100 per point healed)
Fix shopKeeper torchTurret activation
Use marbleBlue for HoT
graves spawn 10 zombies max
goldenAxe spawns treasureNugget
Multiple room trial zones
Guard against detatched entities in utils/Entity.updateHealth
Scale zombieRoom with room difficulty
Fix debug container data
blueSoulOrb collectible (awards blueSouls), dark monsters drop blueSoulOrbs (often)
Refactor containers; include pots; fix boomBarrel and bigBoomBarrel debris
graveRobbers drop shovels rarely
Humanoids sometimes drop treasureNuggets
First pass at lootTables; torches drop treasureNuggets
Add arrows to tutorial; buff spikeTraps in tut death room to get past leather; type
treasureNugget prefab
Mimics are traps, not monsters
Add boom barrels to zombie rooms; randomize zombieRoom entity quantities
Art for freeze state, code too
killer BEEEEEEEEEEES
In tutorial, change lantern reward to something with a more obvious benefit
Art for keys/doors with keyholes
Art for gold nuggets
art for armor (placeholder)
MEAT
food.png
Damage reducing armor items
Display item names when collected
Fix error when dropping gold
Polish spawning of dropped items
Refactor view/ui/Inventory; add boots2; boots are equipment
Refactor inventory dropping into sim/systems/shared/inventory; drop equipment when player dies
Fix Room.spawnEntityByTile centering
nerf greatOwl
Nerf werewolf
Mini-map fixes from geoff-post-alpha
Preload core env graphics

You'll be getting weekly builds of Crypt Run for Windows or Mac in your inbox if you back Crypt Run for at least $25. Thanks for your support! More soon.

Challenge a friend to a game of Crypt Run

2013-07-28T00:00:00Z

You can now challenge a friend to see who's better at Crypt Run! Here's how to do it:

Visit cryptrun.lostdecadegames.com in a modern browser.
Play through the cemetery dungeon.
At the Game Over screen, copy the text in the "Challenge URL" input box.
Send that URL to a friend via email, Twitter, or carrier pigeon.

Your friend will play the exact same procedurally-generated dungeon you played, and your two scores are compared at the end. Instant bragging rights!

Video tutorial

Hate words? Or maybe I explained that badly? Watch this video instead:

Game on!

Nintendo approves Lost Decade as official developer, Crypt Run sets Wii U stretch goal

2013-08-04T00:00:00Z

I'm so excited I can barely type this! Today I get to announce that Lost Decade Games is now an officially licensed Nintendo developer! Lifelong dream unlocked!!

We met two awesome Nintendo guys when we were at Casual Connect last week, and they've been very responsive and eager to help. I can't go into detail, but I've been pleasantly surprised by Nintendo's remarkable support.

So given this exciting news, we've updated Crypt Run's stretch goals to include Wii U. Read all about it on the Kickstarter update and please help us spread the word to Nintendo's legions of fans!

Crypt Run in the media

Have you seen Crypt Run popping up on the Interwebz? Here's some of the recent coverage:

Join us for the Crypt Run Kickstarter live countdown

2013-08-05T00:00:00Z

This Sunday, August 11th, we'll begin live streaming Crypt Run gameplay on Twitch. For two hours we'll be talking about Crypt Run, answering questions from the chat, and counting down the final two hours of the Crypt Run Kickstarter.

Here's the Facebook event. Hope to see you there!

How to help a crowd-funding campaign without spending any money

2013-08-08T00:00:00Z

Found a project on Kickstarter or IndieGoGo that you're really into? Is there an event, store, or even a game you want to support? But maybe you're strapped for cash. Or possibly, you've already backed your favorite project, but you still want to do more to help.

Whatever the case, if you want to help a project you care about without a spending a dime, here are a few thoughts on how to do that.

Tell your friends

Nothing is more powerful than word of mouth. I don't know about you, but when Geoff, or my brother, or someone else I respect personally tells me about a campaign, that speaks louder than any advertisement or review. When you mention a campaign directly to a person, you're letting them know that if they check it out, an interesting conversation about it is bound to be had.

Create forum threads

If you're already a known member at a forum that might be interested in the campaign you care about, you could really help that campaign by telling your community. If that community is a forum, here's an example thread you could post:

Hey friends! I'm so excited about Crypt Run that I just had to tell you about it. It's a medieval fantasy hack 'n slash with a twist -- the game isn't over when you die!

http://www.kickstarter.com/projects/richtaur/crypt-run-death-is-just-the-beginning

Play the alpha: https://cryptrun.lostdecadegames.com/

After you play, SEND ME THE CHALLENGE at the end and I will beat your score! ;)

Even if you're not a member at any forums, you could find related communities and let them know about the campaign. Lists like Pixel Prospector's Big List of Video Game Forums or Wikipedia's List of Internet forums are great places to start looking.

Contact media

If the folks running a campaign want it to succeed, they'd better be busting their butts, emailing everyone on the planet! But that doesn't mean you can't, too. Emails from 3rd party fans who aren't directly attached to a project are invaluable. Having vocal fans speaks volumes about a project's quality, and seeing multiple emails about the campaign may help convince a notable journalist to write about that project.

As an example, Pixel Prospector once again delivers a great list of Gaming Press and YouTubers.

Make a video

Is it a game you want to help? YouTube and Twitch are changing the way players find out about games. More than ever before, gamers use these social discovery channels to determine where to spend their time and money. One popular approach is to simply record your screen to video while playing a game. Some of these "Let's Play" videos attract millions of views and could be a huge benefit to a campaign.

Be social

Obviously the obligatory tweets and Facebook posts are a great way to let friends know about projects you care about. But you should be careful not to oversaturate and upset your friends! Other social networks gaining popularity recently include Tumblr and GitHub.

Cheer them on!

Lastly, reach out straight to the people behind the project. Chances are, they're overwhelmed and stressed out! Comment on the project and/or send them messages of encouragement. Sometimes that can provide the motivation a hard-working crowd-funder needs to get through the day!

Crypt Run 180% funded

2013-08-12T00:00:00Z

WOW! Crypt Run was successfully funded with just OVER $9,000 in pledges from 320 glorious gamers. Thank you so much! This week we'll gather survey information from backers and then we'll start divvying out juicy rewards! Fun times will be had.

You can still preorder and get early access

Did you miss the Kickstarter? No worries! You can still preorder Crypt Run AND get early access to weekly alpha builds!

Crypt Run alpha 152

2013-08-15T00:00:00Z

Here's the changelog since the last version of Crypt Run. These updates will soon go out to the currently 78 alpha gamers who either backed the Kickstarter for at least $25 or purchased the weekly alpha bundle:

152 Shake ice just before it cracks apart
151 Fix spawner and Ice guts
150 Move GutsEmitter to utils/Room; clean up Room.entityContainer on reset
149 stick slimes into sewer
148 Expire existing states when an entity dies
147 Teach running in tutorial
146 Add support for additional R button for running
145 Clean up ProgressScene
144 Get sewer and crypt into the flow
143 fix: Edges show up between dungeon/progress scenes
142 fix lich -- was checking target twice, range was too short
141 fix ice view double
140 Tweak lich behavior so he only shoots at you if you're within range
139 imageOptim
138 Don't play pain sound and death sounds simultaneously
137 Fix RotD visuals
136 Running
135 kickstarter -> preorder
134 Hide UserInfo for now
133 Hall of Trials -> The Arena
132 skeletonKing room has zombieDarkSpawners which despawn when skeletonKing dies
131 Pause Room.entityContainer during freezeFrame
130 Deferred collectors can't collect weapons or collectibles with a cost > 0
129 merge dark monsters, darkness tweaks
128 Guard against invalid itemIds in place.shopItem
127 User auth basics + display
126 ice sounds
125 zombie sfx
124 Optimize room->room transitions
123 Fix invisible goldChest
122 Increase difficulty of dark monsters and rooms
121 new ogg music
120 nerf mimic health
119 Shopkeeper behavior update phase 1
118 Geoff's forest env lol
117 Add flickering to light sources
116 Give dropped items a grace period so they can't be collected right away
115 Refactor chests and shops to use new loot tables
114 chargeable and charger components, transformers require full charge before triggering
105 Allow pawns to set their death particles
113 Adjust RotD monster weights
112 werewolfDark
111 zombieDarkSpawner
110 zombieDark
109 owlDark
108 Disable ghost and skeleton for now, fix tutorial
107 darkPortal -> batDarkSpawner
106 Placeholder batDark and batDarkSpawner
105 Player can interact with entities
104 GamepadStatus UI in TitleScene
103 Default challenge URL to cryptrun.lostdecadegames.com for file: protocol
102 Prep for alpha build
101 Despawn skeletonKing spikeBall when dying
100 Normalize keyboard/d-pad movement
99 More skeletonKing behavior; draw chain to spikeBall
shiiiii-
98 Fix bats deprecated flocking flag
97 Entities with step behavior should not have flocking
97 treasure chalice -> treasure bar
96 skeletonKing and lichLord tweaks

You'll be getting weekly builds of Crypt Run for Windows, Mac, and Linux in your inbox if you preorder Crypt Run for at least $25. Thanks for your support!

Crypt Run Kickstarter postmortem

2013-08-21T00:00:00Z

On July 12th of this year, Lost Decade Games launched a crowdfunding campaign for Crypt Run, our medieval fantasy hack 'n slash game. The goal was $5,000 USD during a 30-day funding period. We made the goal (and many mistakes) during this exhausting campaign. Let's talk about what worked, what didn't, and what we'll do differently next time.

What went right

1. Thorough research

There's an overwhelming amount of information out there on crowdfunding best practices. I spent roughly a year with my ear to the ground, reading the occasional crowdfunding article and getting a feel for the current Kickstarter community. A great place to start is the Kickstarter School, but these best practices change so often and are so contextual that custom research is best.

The last few weeks before we launched our own campaign, I dug through dozens of bookmarks and spent hours per day reading up and educating myself. I'd say that this more than anything else contributed to the campaign's success (except perhaps having a strong web-based demo). There's no excuse these days: know your stuff!

2. Reasonable goal

Coming up with the budget for a game is difficult, even without complicating things with crowdfunding. Conventional budgeting approaches are not always applicable in the crowdfunding arena, where backers expect a game to be far along in development before they'll consider funding it. This environment requires that a studio fund initial development upfront.

Our approach was to develop Crypt Run until we were almost out of money, then look to Kickstarter to see if we could gather a crowd who wanted us to continue development. Rather than estimating the budget to finish a complete game design, we decided to target a goal that we felt was within our reach, and design the rest of the game based on this yet-to-be-determined budget.

$5k seemed like a solid, reasonable goal that we could accomplish with our current network. This would allow us about one more month to develop Crypt Run, which is approximately how long the Kickstarter project itself took to create! So if we met our goal, we would break even.

This method of budgeting for what's affordable instead of what's ideal for the game certainly isn't the optimal approach for all projects.

3. Live demos

We launched the Kickstarter along with a live demo at California Extreme, an annual arcade and pinball expo in the California Bay Area. With hundreds of gamers playing Crypt Run over a 48-hour period, this undoubtedly contributed to our exceptionally strong opening weekend (58% of our goal pledged in just two days).

With about two weeks left to go, we also participated in Indie Prize Showcase, which is part of the very popular Casual Connect conference. While this conference was much more business-oriented, we definitely found new backers here, in addition to making solid networking connections.

Live demos can't be beat when it comes to establishing a connection with an audience. There's nothing better than shaking a gamer's hand, then putting a gamepad in it.

4. Short, concise video

Our first video was largely live action, comprised primarily of us talking at the camera interview-style. We set up a rough script and took an entire day to film this video, complete with green screen and some fancy editing. However, it didn't survive first contact with viewers; smart people whose opinions we respect suggested we ditch our talking heads in favor of more gameplay footage.

We saw their point, and made a new video that focused entirely on the game. The initial video was over 5 minutes long, and our final video clocked in at only 2:06. We feel that having a concise, game-focused video was one of the stronger aspects of our campaign.

5. Constant promotion

I was really hustling for about 5 solid weeks, emailing everyone in the gaming press industry I could find. We did several interviews, updated our blog a few times per week, and managed to get some decent press coverage. We also launched a challenge a friend feature that allowed for asynchronous competitive multiplayer.

There were even some Reddit threads that did pretty well, although use Reddit at your own risk, as some Redditors can be unnecessarily hateful. The takeaway here is that being constantly noisy about a campaign can keep interest up.

What went wrong

1. Incomplete core mechanic

Money was running out and we weren't as far along as we'd hoped. We had plans for an ambitious and poorly-defined "unique death mechanic" that involved the game continuing after death. This feature was so incomplete it was almost cut from the Kickstarter demo entirely, but we wanted to provide players with a small taste of what was to come.

However, this incomplete feature left many gamers understandably scratching their heads. Was it just a corpse run, like in World of Warcraft? Was it another world, like in The Legend of Zelda: A Link to the Past? It wasn't any of these things in our early preview -- it was simply incomplete and left as a big question mark. Some people found this intriguing; others did not.

2. Quickly saturated network

After the first week, our network of followers across Twitter, Facebook, YouTube, and even our podcast certainly knew about Crypt Run. If they were interested in pledging, they likely already had.

Constantly promoting was good, but we should have had a better plan for finding new backers outside of our previously-existing network. I'm still not entirely sure how to do that, but it's clearly worthy of investigation.

3. Aggressively bad high tier rewards

We spent a lot of time talking about and planning the top tier rewards (everything above $100). However, nobody wanted them! I think it speaks volumes that even the very generous backers who pledged enough to afford them chose not to accept them.

Their very presence made things needlessly more complicated for the 300+ backers who did choose rewards. For future crowdfunding efforts, I'd shy away from offering any rewards priced above $100.

4. Poor updates

I suck at updating. Even at this moment I can't tell you what kinds of updates gamers expect, or keeps people interested, or increases pledge amounts, or anything similarly valuable. I know now that there's no reason not to update every single day, so that's what I'd likely do in the future. The only problem is: I have no good ideas on how to deliver so many interesting updates!

In this vein, I also forgot the final edit to direct traffic to our Humble Store widgets. I had intended to edit the top of the project description with a prominent link to our new landing page where gamers can still preorder Crypt Run. When a Kickstarter project ends, it can no longer be edited, so this ship has sailed.

There will undoubtedly still be a trickle of traffic reaching the Crypt Run Kickstarter page, and since there isn't a prominent call-to-action to preorder, I have essentially left money on the table.

5. Wiik stretch goals

Crypt Run had weak stretch goals. They were poorly thought out from the beginning and were doomed to suck the moment I hit the "Launch Project" button. Some potential backers thought it was weird that, for example, the Linux stretch goal ($5k) was just as much as the game itself. An understandable complaint! The reason for this is that we paid for the initial development out of pocket, but we didn't have Linux support in our tech stack, so we had to have more time to support it.

Our addition of Wii U support was handled particularly poorly. Based on severely incomplete information, we came up with an unrealistic goal of $13.5k for Wii U support. This turned off many potential Wii U backers, and probably hurt our chances of getting better coverage on gaming sites. And in the end, we still promised to deliver Crypt Run on Wii U (albeit, at a completely unknown date).

At the time, we felt that it would take $5k to make that happen, a number that we changed our minds about during the campaign. It wouldn't surprise me a bit if some people viewed our budgeting incompetence as some type of greed, or were simply turned off by our inconsistency.

For a future project, I believe we'd avoid this problem entirely by simply not having any stretch goals.

Result

Crypt Run reached its funding goal on July 31st, 19 days after the campaign began. When the campaign ended, it was 180% funded at $9,013. That's just over 9,000 and I gotta say, I really love our fans for that. Especially our good friends Joe and Rich, who awesomely lobbed us over some important milestones.

In my mind, the crowdfunding campaign was a complete success. On top of being able to spend more time developing Crypt Run, we also increased the size of our audience. I'm kicking myself for not counting our followers across the various social networks before the campaign began. It would have been great to know the exact numbers, but I'm pretty familiar with them, so I can provide a decent guess:

~100 new Twitter followers
~50 new Facebook likes
~25 new YouTube subscribers

These numbers may seem low to people at larger companies, but to a small indie studio like us, this is a healthy dose of new fans. It's clear that being noisy and focused for a solid month is beneficial not just as a funding tool, but also as a means to grow an audience.

Overall we're very pleased with the results of our campaign, and quite humbled by the amazing support from our small but loyal fanbase. Crypt Run's successful crowdfunding almost certainly sets the stage for another campaign from Lost Decade Games, but before we can even think about that, we've got a game to finish!

The making of the Waveform 4 album cover

2013-08-25T00:00:00Z

Video game composer and arranger Joshua Morse just released his new album Waveform 4. It features five awesome songs (including my favorite You Got Me) for just $4. That's cheap folks, so go buy it!

Joshua tapped me to do the album art. He had the idea of a Game Boy playing drums, which is obviously an awesome idea. So first I did a quick sketch:

Once Joshua gave it the thumbs up, I started placing pixels. I typically start by drawing out the silhouettes to make sure each element has a good shape and is recognizeale even without detailing. Then I decide on light sources and start to lay down pixels to represent shadows and lighting. Then I just repeat this process until I'm either happy or out of time!

Below is a near-complete work-in-progress. I took another few passes at some lighting and details, and then redid the typography from scratch (I almost always need to do that, as my first pass of text is usually terrible).

In this case, I unfortunately ran out of time before I was happy. I don't think it's a bad piece that I'm ashamed of (like some of my earlier work), but I know that I can do better so I'm overall disappointed with the result. What do you think? Crappy? Pretty cool?

Anyway, go buy Waveform 4, it's awesome!

Understanding Canvas Rotation

2013-08-30T00:00:00Z

From time to time, we get reader or listener email asking about various aspects of developing games in HTML5. Instead of responding directly, we prefer to put the answers up on our blog in case the information can help other developers.

Transformations in canvas can be tricky to understand at first. Conceptually, most people tend to think about rotating and scaling individual images. They're often surprised and confused when the canvas API transforms their entire game when calling .rotate or .scale.

The only way to transform images in canvas is by modifying the entire canvas. The trick is that you need to modify the canvas context just before you draw a transformed image and reset it right after. This is where the .save and .restore methods come in.

Saving a canvas context stores the current configuration, including transformations (or lack thereof). Restoring a canvas context does just the opposite, resetting the current configuration to the last saved state.

Another gotcha for transformation is that by default, all transformations occur from the origin of 0, 0 on the canvas, which is the upper left. The most common use case for rotation and scaling is from the center of an individual image such as a game sprite. Luckily, there's another canvas method we can use to change the transformation origin, .translate.

Let's take a look at how we'd achieve a simple rotation of a rectangle. Inline comments in the code explain what's happening in more detail.

// Create our canvas
// Append it to the document body
var stage = document.createElement("canvas");
stage.width = 320;
stage.height = 240;
document.body.appendChild(stage);

// Grab a reference to the canvas' 2D context
var ctx = stage.getContext("2d");

// Paint a background color
ctx.fillStyle = "cornflowerblue";
ctx.fillRect(0, 0, stage.width, stage.height);

// Draw a non-transformed red rectangle on the left
ctx.fillStyle = "red";
ctx.fillRect(40, 80, 80, 80);

// Now, let's draw a rotated
// yellow rectangle on the right
// First, let's save our canvas context in order to
// easily restore it after our transformations
ctx.save();

// Next, we'll translate (move the origin) to the
// center of where we'll be drawing the rectangle
ctx.translate(240, 120);

// Any transformations applied from here on out
// will be relative to the origin of 240, 120
// Note that we're using radians to specify rotation
ctx.rotate(Math.PI / 4); // 45 degrees

// If we desired to scale the rectangle
// 1.5x normal size on both the x and y axis
// ctx.scale(1.5, 1.5);

// Now we're ready to draw our rectangle
// The difference this time is that our coordinates
// are relative to the origin, just like .rotate
ctx.fillStyle = "yellow";
ctx.fillRect(-40, -40, 80, 80);

// Finally, we restore our canvas context so
// that subsequent draws are not transformed
ctx.restore();

Tada! A rotated rectangle without rotating the entire canvas.

Here's a gist of the entire sample code. Check out this canvas graphics article on MDN for more information.

Wish Geoff a happy birthday by playing as him in the Crypt Run alpha

2013-09-16T00:00:00Z

It's Geoff's birthday! He's 96 or something. Here at Lost Decade, it's kind of a tradition to give each other company-branded products (shirts, stickers, etc.), but we're especially poor at the moment, so instead I animated him and stuck him in Crypt Run. What fun!

For Geoff's birthday last year, I added a sprite of him to Lava Blade (a graphic we didn't use until we "launched" Treasure Geoff). We've come a long way since then! At the time, Lava Blade was being built as a side-scrolling platformer, and we now know how that went…

In the next build going out soon, Crypt Run early alpha users can type "ldgeoff" and their player avatar will turn into Geoff. Good Geoff-related times are to be had by all. Will we introduce some secret that only Geoff can unlock?!

Be sure to wish Geoff a happy birthday on Twitter or the LDG forum!

Crypt Run is now A Wizard's Lizard

2013-10-21T00:00:00Z

Big news! Our Kickstarter-backed game Crypt Run is now called A Wizard's Lizard. Why change the name?

This isn't a decision that we made lightly. We've been pushing this game for some time, and it's not really resonating with the press. We're grateful for the coverage we've been able to get, but the reality is that this game needs to find a big audience in order to be able to support us.

Our feeling is that "A Wizard's Lizard" has more personality and is more memorable than "Crypt Run". Additionally, it works great with our new narrative where players take on the role of a lizard transformed into a humanoid!

Here's a teaser from the upcoming storyline:

You are Raga, the lizard familiar of a respected wizard in the town of Amberfall. When your master unlocks the magic of eternal life, Death is offended and takes him away. In the turmoil, a magical shape-changing potion spills on you, transforming your figure into a humanoid! In this action RPG, wield powerful weapons and battle monstrous beasts as you avenge your master and conquer Death!

New release date

The bad news is that we're pushing the release date back. Why?

We've had the good fortune of being invited to participate in the HTML5 Developer Conference's 2013 keynote. This is a great opportunity for Lost Decade Games but has had the unfortunate side effect of taking up a bunch of our dev time.
Halloween seems like a great date to launch a grizzly game about death, but actually it's pretty bad from a marketing perspective. For one, a Thursday before an event-packed weekend is a lousy time to launch any game. Additionally, this date conflicts heavily with the gaming industry's launch of new consoles (including PS4, Xbone, and Steam Box).
We're behind! Making games is hard, and we're terrible estimators of how long this stuff takes. Our apologies for not making this goal, and we plan to make it up to you in spades.

The good news is that we'll be working on the game longer, making it much better for you! Our hope is to do the big launch in Q1 2014. Also, that means more updates for you wonderful Early Access gamers (both from Kickstarter and Humble).

Beta release coming early November

To make up for our slowness, we'll be pushing out a beta version of A Wizard's Lizard in early November. This won't be a complete game of course, but will allow us to deliver a timely experience to those of you who are expecting it.

Check out the new website and let us know your thoughts!

A Wizard's Lizard Art Asset Overview

2013-11-16T00:00:00Z

We're working hard on finishing A Wizard's Lizard (previously Crypt Run) and I thought it might be fun to visualize how much content this game has so far. Below are incomplete samplings of some of the monsters, objects, traps, weapons, and characters we've added so far:

Monsters

There are currently over 30 monsters in A Wizard's Lizard, and we haven't even finished the boss encounters yet!

Objects

Objects include stuff like barrels, chests, treasure, tables, pots, jars… fun thematic stuff!

Traps

These are the elements in the game that players might not be forced to deal with, but can be quite dangerous if they do!

Weapons

Who doesn't love a good weapon?! A Wizard's Lizard has swords, axes, daggers, lances, boomerangs, shovels, tridents… you name it!

Characters

We're only just now starting to flesh out characters with actual stories and player interaction, but we frontloaded a bunch of the artwork for them.

We'll be releasing a beta build of A Wizard's Lizard to ALL preorders next week, so be sure to preorder if you haven't yet! This build will also include a bunch of Kickstarter backer paintings, for which I'll probably make another post. Fun times ahead!

What it was like making HTML5 games in 2013

2013-12-20T00:00:00Z

As the year comes to an end, we at Lost Decade Games like to take a step back to see what kind of progress we've made. One of the (few) unique aspects about our game studio is that we have chosen HTML5 as our development platform, a highly controversial technology. Let's take a look and see how HTML5 has served us this year.

How was HTML5 as a platform?

Technology is arguably the most important consideration when choosing a platform to develop on. If the tech is too hard to work with, it could compromise one's ability to ship a quality experience. If the tech isn't stable and robust, surely it'll crack under the pressure of a large gaming audience!

The good news is that HTML5 on desktop is “ready” for prime time. Using the fantastic open source framework node-webkit, we've been distributing desktop binaries on Windows, Mac OS X, and Linux for most of this year. All of our video, audio, input, and rendering demands have been met by HTML5. Performance is reasonable, development is fast, and our customers' feedback has been overwhelmingly positive.

I'm happy to report that our current mountain of problems on desktop has nothing to do with the technology, and everything to do with design, marketing, and distribution. The same problems everyone has!

To distribute our HTML5 games on Google Play and the iOS App Store, we use Ludei's CocoonJS, which is an impressive and powerful product. Our HTML5 games work great for the most part, but performance can be a problem if your game is doing tons of computing or image compositing (which games tend to do). Simple 2d HTML5 games can be made quickly and efficiently, and distributed on native mobile stores. We're very close to that “holy grail” of easy cross-platform development, and it's pretty great.

How was the tooling?

HTML5 tooling has a long way to go. Flash developers are accustomed to having a rich IDE at their fingertips, and many of these developers making the move to HTML5 may be sorely disappointed by the lack of mature tools available.

We've been iterating on our own internal tools for about three years now, including a full-featured game engine, build scripts, and a skeletal animation editor. These things we've built for ourselves are good enough for our specific purposes, but studios new to the HTML5 scene will likely want to use pre-existing tools.

Regarding engines, ImpactJS was the leader of the pack in 2013, despite the $99 USD price tag. Phaser has been picking up steam as an open source alternative, and there are many other solid choices. The tooling has a long way to go, but things are looking bright for the future, with offerings like Intel's XDK and PlayCanvas's cloud-based IDE pushing forward every day.

How did we make money?

As with any technology, there are many different approaches to monetizing software. HTML5 doesn't really have any limitations here, as it's perfectly capable of supporting premium downloads, F2P with IAP, subscription models, or probably any other crazy scheme. That said, monetizing consumer products is hard, and this year it was worlds easier to make money with HTML5 games through B2B deals.

Below is a pie chart breakdown of our revenue from 2013:

Development Contracts

Contracts are primarily what kept us afloat in 2013. This essentially equates to other companies that have either already figured out the best way to monetize HTML5 games or (more often) they are flush with capital and eager to experiment in the space. These contracts tend to pay similar to what we used to make as web developers in Silicon Valley, but they also take up the lion's share of our time. It's closer to “employment” than we'd like to be, and probably where a lot of indies find themselves these days.

There's lots of interest in HTML5 from companies with money, and from what we've seen, they're spending more on contracts each year.

Licenses

HTML5 gaming portals are popping up everywhere. They typically pay a one-time non-exclusive licensing fee for a quality mobile HTML5 game, ranging drastically in price. From what we've seen, an individual license could earn between $350-$2k USD, depending on the quality of the game and success of the partner. (These numbers will likely decrease as more developers saturate the market.) Many portals offer revenue split only, from which we've never seen better pay than the one-time fee.

These licenses seem like easy money on the surface, and once in a blue moon they are. The vast majority of licenses, however, end up being bloody time vampires. Portals usually want support for a dozen or more devices, going back as far as Android 2.1 and iOS 3 (these devices are slow and have pitiful audio support). Since many of these portals are brand new, they tend to be very volatile. We've experienced companies switching contacts multiple times, pivoting away from HTML5, and even shutting down entirely during discussions.

These issues make it difficult to actually profit from licenses. Still, licenses were the easiest way to make money with HTML5 games in 2013.

Consumers

Developing and marketing HTML5 games directly to consumers? Good luck! You're in the same crowded market as the rest of the world. HTML5 has some advantages, such as being able to provide a demo instantly in the browser, but are demos even worthwhile for developers? We got a big spike in this category by running our Kickstarter for ~~Crypt Run~~ A Wizard's Lizard earlier this year. Additional sales have all come through Humble widgets and IAP.

What games did we make?

One way to measure the effectiveness of a platform is to look at how productive its developers have been. So what was our output from 2013? Here is an incomplete list of the games we made:

Lava Blade (turn-based strategy RPG, launched via our own Humble widget)
Rampart Rush (unreleased, got tied up in publishing deals)
Retreat to the Jeep! (Indie Speed Run 2013 entry)
Midtown Mayhem (unreleased, also tied up in publishing deals)

These games were developed while handling dozens of licenses and creating many prototypes to sharpen our skills and tools. Additionally, throughout almost the entire year we were developing A Wizard's Lizard in one form or another. Any studio can always be more productive, but we're satisfied with what we were able to build on HTML5 this year.

Summary

I believe 2013 was the year we started to see the gradual transition from experimental HTML5 games to production-quality HTML5 games. The tooling has a long way to go, but the money is there if you do quality work. Overall, it was a good year for HTML5 gaming.

A Wizard's Lizard 1.0.185

2014-02-02T00:00:00Z

It's been over a week since we launched A Wizard's Lizard, and it's been going fairly well! Our Steam Greenlight campaign is currently ranked #80 out of all the games on Greenlight, and we've even seen a healthy dose of sales thanks to attention from popular streamers.

We've been hard at work zapping bugs and adding new features to keep up with player demand. The latest version has over 50 incremental changes, including:

Items

Be Your Best (book)
Demon Spear
Demon Sword
Detox Potion
Elvish Tunic
Heat Axe
Magic Book
Mithril Mail
Scythe
Self Improvement (book)
Spiked Lantern
Spiked armor (5 piece set)
Vampire Crown

Features

"Otter trap"
Clearer/better stats in menu
Display total wins/deaths
Key pentacle health restoration amount off of player magic
Magic property
Pick a random character
Random Zombie Warlord room layouts
Redesign access to Den of Thieves

…and LOTS of bug fixes/general improvements. Have a request? Please let us know on the AWL forum. GAME ON!

Asylum Night graphics are now free to use

2014-04-16T00:00:00Z

Remember Asylum Night? We made it a while ago as part of Indie Speed Run, a 48-hour game jam. We were randomly given the theme "telepathy" and the element "booby-traps" which we had to use in the game. (It also needed to be mobile-friendly so we could license it to portal companies, an internal requirement.)

What we came up with is a weird riff on a game Geoff and I both love: Plants VS Zombies. And now the graphics in Asylum Night are free for anyone to use! The license is straight-forward: you can display, distribute, remix, profit, whatever you wanna do, please just attribute "Original artwork by Lost Decade Games" and we're solid.

Get the graphics on Open Game Art

A Wizard's Lizard: Immortal Edition launches June 16

2014-06-04T00:00:00Z

You knew A Wizard's Lizard was coming to Steam because it was greenlit back in February. However! Did you know that there have since been four additional months of hardcore development? New content, features, abilities... there's so much stuff we decided to call this update...

A Wizard's Lizard: Immortal Edition!

Seriously, look at all this great new stuff:

Meaner Bosses

The Zombie Warlord, Sewer Hag, Death, two crystal bosses and others have all seen improvements. Their behavior is more varied and less repetitive.

---

Puzzles and Mini-Games

Pressure plates, puzzle rooms, gravity fans, and bear traps now guarantee chaotic good times.

---

Quality-of-Life Settings

You spoke, we listened! Custom keyboard configuration, gamepad sensitivity, mouse support, volume sliders, and more will make your dungeon crawling life easier.

---

New Monsters

Giant Flaming Skulls, Green Slimes, exploding mushrooms, and [spoiler alert]!

---

Soul Blast Ability

The new Soul Blast ability fires soul energy from the player, damaging nearby monsters. Power it up with magic items!

---

Totems

Totems can be stuck in the ground, after which they'll blast fire, freeze monsters, poison baddies, and more!

---

Big Explosions

If you like blowing stuff up, we've got you covered. "Boom Barrel" rooms abound in A Wizard's Lizard: Immortal Edition!

On Humble and Steam June 16

That's a lot of stuff! So even if you've been enjoying wizards and lizards for a few months now, you're certain to have fun new adventures with this big update. Look for it on both Humble and Steam on June 16, 2014.

Celebrate independence with a Skyrocket

2014-07-04T00:00:00Z

Whether you celebrate July 4th or not, independence is a grand thing. We here at Lost Decade Games care deeply about independence, and indie games are a fun way to express that.

To celebrate properly, we've added a new Skyrocket weapon to A Wizard's Lizard. It's available for purchase in town. If you can't afford it yet, you might need to explore the dungeons to see if any grateful hostages might contribute to your cause…

Happy 4th, happy gaming, and thanks for all your incredible support!

A Wizard's Lizard by the numbers: our HTML5 game on Steam

2014-10-08T00:00:00Z

A Wizard's Lizard is an action roguelike where players control a pet lizard, made by a small, independent game studio in California called Lost Decade Games. Our mission was to make a solid desktop game that would pave the way for our next project, and help our studio thrive. Let's examine the numbers to see how we did.

Kickstarter

We first Kickstarted the project as Crypt Run in July 2013, earning $9,013 during its 30-day funding period. Part of the campaign's success is likely due to our live demo at California Extreme, an annual arcade and pinball expo.

During the funding campaign, we met Greg Love of Whippering and started working together on marketing and business development. Greg has been a huge help with marketing, press and YouTube outreach, as well as general consultation. (He even presented a talk about the business behind the launch, with even more lovely charts and numbers!)

Around this time we also decided to change the name of the game from Crypt Run to A Wizard's Lizard. We agonized over this decision, but ultimately felt it was best, as it made the game much more memorable and helped introduce a compelling main character.

Steam Greenlight and Humble

On January 8th we launched our Steam Greenlight campaign, which was successful on February 19th. Some of our developer friends have had games on Greenlight for more than a year, so we feel really grateful that we were able to move through this painful process quickly. Many votes came from the gaming communities of Twitch streamers CobaltStreak and Lethalfrag. If not for them, who knows? Maybe we'd still be slowly crawling up the Greenlight charts.

On January 22nd, we launched A Wizard's Lizard on our own website with a Humble widget, selling 516 copies in the first month. From the Humble launch up until the Steam launch, we sold 859 copies.

Steam launch

A Wizard's Lizard launched on Steam June 16th, at $14.99, but this time with a 34% launch discount (actual price: $9.89). As does any new game on Steam, we received homepage placement, a valuable and coveted position. Fortunately, we were able to stay above the average conversion rate, so our time on the homepage was extended by about 40x what we would have received if our game was not performing well.

A large part of our initial launch success is due to the wonderful YouTuber and Twitch communities, especially Northernlion who did a series on A Wizard's Lizard. Video content creators are probably the primary way games discover our game, so we're really grateful for coverage. In the first 72 hours on Steam, we sold 6,340 copies. And then...

Steam Summer Sale

The Steam Summer Sale made us really nervous: would our new, small game disappear in the vast ocean of prolific games with deep discounts? The massive Steam sale began Thursday, June 19th, just three days after our launch.

Immediately we started off on the wrong foot -- we set "34%" for our Steam Summer Sale discount, the same as our launch sale. Our thinking was we'd just continue with the launch sale through the SSS. But nope! The discounts stack, and so A Wizard's Lizard was 68% off for a short period, causing some unhappy tweets from early supporters.

We brought the discount back down to 34% as intended within one hour, during which we moved 528 units. Previous to that spike, our hourly high was 428 units right at launch!

During the Steam Summer Sale we sold 5,834 copies in total. It's tough to say if we would have moved more units if SSS hadn't taken place so soon after our launch, but our conversion rate was slipping, so we likely wouldn't have had homepage placement for much longer anyway.

In our first week on Steam, we sold 8,344 units. The excitement over the Steam launch also brought in additional Humble interest, netting another 541 sales during that week on Humble.

Our own Steam sale

Well before launch we had plans to update AWL with bug fixes and additional Steam features (trading cards are in the works!). We also wanted to add new content, which we used to couple with a sale. With this new content and another 34% discount, we brought in another 615 sales in one week.

As you can see, our ability to drive our own traffic is minimal compared to Steam's massive audience. It took us a week to drive a few more sales than our 68% discount during SSS made in just one hour!

Totals

From January 22nd to the writing of this article, we've sold a grand total of 14,719 copies of A Wizard's Lizard. Here is a breakdown of where those sales came from.

Steam: 12,671
Humble: 1,739
Kickstarter: 309
Total: 14,719

What's next?

There will probably be another Steam Winter Sale, and as you saw above, Steam accounts for 86% of our sales, so you bet we'll participate if we can! We also hope to drive more interest with even more content, such as a Halloween-themed boss encounter, but our ability to continue work on the game depends on how it performs in the market.

I believe if nothing else our experience confirms what we've heard from other indies, which is that Steam is the place for desktop games to be. Hopefully this information will help other developers out there. We also share this kind of information on our podcast and on Twitter, if those sorts of things interest you. Game on!

How to Make a Video Game All By Yourself

2022-03-15T00:00:00Z

Hey it's Matt. I wrote a book!

It's called How to Make a Video Game All By Yourself.

I wrote and illustrated it over about 2 years. You should totally check it out.

Read all about it here.

Buy the physical version here.

You can also buy it digitally on Kindle, Itch.io, or Gumroad.

Thanks for checking it out! I hope you like it and I hope it helps you make video games.

Lost Decade Games

Why Geoff Failed and the Road to Redemption

Will code for food

Creepy features

The one man army

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

The pie in the sky

Loss of motivation

Summary: how to avoid these problems

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

More about Diggy

More about Bombada

Those links again please?

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

Onslaught! v0.2 & Freeplay Awards

Boing Boing Contest Post Mortem -- Onslaught!

The Game We Built

What Worked Well

What Didn't Work So Well

Conclusion

Links!

Fun With Logos

A Simple Guide to Game Development Contests

How do you find out about these things?

News sites:

Indie-related Twitter profiles:

How do you know if you should enter?

Will you benefit from entering?

Determining if a contest or promotion is shady

Decide quickly and move on with your development

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

My vicious cycle

My prevention plan

Why a match-3 game in JavaScript?

What? A Puzzle Quest clone?!

Connecting the pieces

So what happened?

What was good

What was bad

Google Docs

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

It's too easy

It's too hard

So, it's too easy AND too hard?

The difficulty curve

What we're going to do and why

Onslaught! Arena 1.0 Gameplay Teaser

Obfuscating JavaScript with Closure Compiler Advanced Optimizations

Don't access object properties as string literals

Don't use string literals

Stay away from built-in JavaScript object property names

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

About Onslaught! Arena

About Lost Decade Games

About the Chrome Webstore

Related links

App Engine and Chrome Webstore Issues

Quick background

The troubles we were (and are) having

Licensing API calls failing

Server Error pages

Asking for email addresses

Conclusion

Our first week in the Chrome Webstore (the numbers)

Reviews of 6 Screen Recording Apps for OSX

Desired features

Which applications did I review?

Camtasia

CaptureIt!

iShowU HD Pro

Screen Mimic

Screenium

ScreenFlow

Bonus: QuickTime

Summary

Onslaught! Arena now on sale for $1.99

Details about our next game Burn Tactics

Why we chose to work on this game

Accessibility

Small in scope