Lost Decade Games – HTML5 to the Crypt.. and Beyond

Lost Decade Games is an award winning indie game development studio from California founded by Geoff Blair and Matt Hackett.

They’ve been focusing on HTML5 from the very beginning, when HTML5 gamedev wasn’t yet known and when game engines like Quintus or LimeJS weren’t around to make our lifes easier.

Besides making games that can be played in a myriad of platforms, Matt and Geoff have a podcast about HTML5 gamedev called Lostcast of which I’m a big fan. In this podcast they talk about game development (their passion) and entrepreneurship/business side (what they need to do in order to be able to live on their passion).

Lostcast recently had a successful Kickstarted campaign, where thousands of game enthusiasts made possible the funding of Crypt Run, a Zelda-style dungeon explorer action RPG.

Thank you guys for being here with us at the GameDev Academy and sharing your story.

Did you guys make games before Lost Decade Games? and I don’t mean published games, but just game demos for fun. Any with HTML5?

Matt and I have both been developing little game demos on the side for a number of years. Funnily enough, we both got started in QBasic. Once the web browser was even remotely capable of games, we’ve been creating hobby projects. Early on I developed a game called Shapes and Matt created Spacius.

Both games were DOM based as canvas wasn’t on our radars yet. Our first canvas effort was Onslaught! Arena, which we originally made in our spare time for a Boing Boing contest.

Screen shot 2013-09-16 at 4.10.14 PM

 

After all you guys have learned over these years, if you were starting your company with all this knowledge in your head, what things would you have done differently on the business side and on the technology side?

We’d definitely start with an established engine. There’s a handful of HTML5 engines gaining maturing out there and we’d rather have someone else doing the bug fixing for us. :) Specifically, I’d probably look at Pixi, Impact or the CreateJS suite. On the business side, I think we’d be more focused now. It took quite a while to really understand the various markets and where we wanted to build games.

HTML5 is interesting because there are several ways to go. On the one hand you’ve got developers building small, mobile focus games for web-based portals. These portals generally share ad revenue or pay licensing fees. Another way to go is trying to build more social style games leveraging the cross device nature and IAP. Yet another direction is building desktop or mobile apps in HTML5 but wrapping them for distribution in node-webkit or CocoonJS. We’ve dabbled in each market, but ultimately it comes down to what kind of games you want to make and where that audience plays. For us, we’re historically console and desktop gamers.

Initially, we focused more on the mobile web and native mobile devices, but that’s just not where we play games. It took a while to realize that we really just wanted to be making games you can play with a gamepad on your couch or at your desktop.

 

Do you have a general workflow or a methodology to carry out the game making process or is it pure chaos?

I think there’s a big difference when developing game vs apps. In general apps usually have a more rigid definition and scope as you’re creating to solve a specific problem or use-case. Games tend to spiral out of control very quickly, especially in the hands of hobbyists or inexperienced game devs. One main issue with developing games is that there’s this intangible idea of fun.

You can get weeks into a game project and simply get bored because the game isn’t what you imagined it to be. Conversely, you could be so excited about a game project that you keep adding features left and right until you overwhelm yourself. The key is to start small. Don’t build your dream game. Build something simple that you know you can finish. Be ruthless about scope and feature creep.

If you have an amazing idea, save it for the sequel. Focus on finishing, it’s the hardest part of game development. We try to keep the game design simple and pure. Start with a really basic concept and iterate. Add new pieces to your game design slowly and thoughtfully. Even small additions can create mountains of extra work in terms of code, artwork or content.

 

How far into the gamedev process you show your game to somebody else for testing?

The sooner the better, honestly. The first time anyone plays your game they will notice things and find problems that you hadn’t noticed or just ignored. Watching someone play your prototype can be gut-wrenching because you want to keep apologizing for all the bugs and unfinished content. Take feedback with a grain of salt, though.

It’s really tough for anyone to provide feedback on unfinished works. Pay more attention to how they interact with the game. Do they understand the controls? Are the wandering around aimlessly? Do they understand the goals?

 

How do you know when to stop when making a game?

For us, when we’re out of money! Kidding aside, that’s a really tough question. It’s always sooner than you think. Most game devs I know could be perfectly content tinkering with a game design for a long time.

Again, finishing is hard. You have to really consider your goals for the game and the target market. You’re almost always going to need to release before you think it’s “done”. This comes back to keeping it simple. If you overload yourself with features and content, you’ll never finish the game.

 

Crypt Run is conceived as a desktop game from day 1. One hears most “sillicon valley/startup/techcrunch” people (probably your neighboors and everyone you see at the grocery store) repeat the “mobile first” mantra and you guys are making the opposite. Any reasons to switch to desktop games after having made mobile games?

Mobile is a tough space to play in especially for indies. There are definitely indie hits out there, but the app stores are really tough to compete in given how saturated and popular that market is at the moment. Not only that, but the audience and monetization is different in the mobile space. Many games are freemium, which really affects your game design. Players simply aren’t expecting to pay upfront for games.

Some might say that this is just how game monetization is trending, but if you look at Steam, there’s a healthy community of players willing to pay for games. There’s a whole host of technical challenges with mobile as well, especially with HTML5. The mobile web browsers are getting better, but still quite a ways from native performance. That’s not to say you can’t make compelling games in the mobile web, but there are absolutely limitations there. For us, it mostly comes down to making games where we play games. And that’s consoles and desktop.

Initially, we went down the mobile route because that’s where HTML5 seemed to be strongest. That’s the wrong way to approach the business, I think. The tools shouldn’t dictate the game. Think about the game you want to build, where people will want to play that game and then figure out how to build it. Maybe HTML5 is a good choice, maybe not.

 

Do you think a game can actually be both mobile and desktop and do both well or is the whole “build once, deploy everywhere” HTML5 salespoint just a myth?

It’s perfectly possible. It really depends on the game design and interaction. For example, Lunch Bug, World of Goo and Plants vs Zombies are all great desktop experiences, but really shine on tablets. The latter two examples aren’t HTML5 of course, but those designs could definitely be built in HTML5. Bridging the gap between desktop and mobile is really a design problem, not a tech problem in my opinion.

Even targeting solely desktop we feel that HTML5 is an advantage. Using node-webkit we can easily distribute our game as a native desktop app for Windows, Mac and Linux. The same goes for mobile devices and CocoonJS. There’s no porting involved.

 

Do you have any tips for indie game developers wanting to run a Kickstarted campaign to finance their projects?

Do a ton of research! Make a great video pitch, keep it short and fun. Make sure you really think through your reward tiers. Stretch goals are almost a given but I think that some campaigns might to well to drop them. Have a playable demo, it gives people a better idea of what you’re building and shows them that you can actually deliver something. Release constant updates. The hardest part of a Kickstarter is after launch.

You really have to hit the ground running and try to drive people to your campaign. It’s like a month long sales pitch.

 

Any other advise to people who love HTML5 game development?

I’d say you’e all masochists. :) Use an engine, but know how to write your own. Don’t try to conquer the world (at first). Launching a cross-platform game is hard. Launching a cross-platform game across desktop and mobile is even harder. Don’t get so caught up in the promise of HTML5 that you you lose sight of actually building an engaging and fun experience for players.

If that means desktop only so be it. If there’s interest and demand for your game then you’re in luck because HTML5 does have advantages when it comes to cross-platform.

 

Thank you Geoff and Matt for answering all our questions!! And as a bonus for the GameDev Academy readers, Matt and Geoff recommended us to check out Crypt Run their upcoming hack ‘n slash dungeon crawler! And if you preorder for 20% off or purchase the Early Alpha package, receive weekly alpha builds of the game.

PREORDER CRYPT RUN FOR WINDOWS, MAC AND LINUX

 

Links:

http://www.cryptrun.com

http://www.lostdecadegames.com

http://www.lostdecadegames.com/lostcast/

http://www.youtube.com/LostDecadeGames

https://github.com/rogerwang/node-webkit

http://www.ludei.com/tech/cocoonjs

About the author  ⁄ fariazz

Pablo is an entrepreneur and developer based in Chile. Founder of two tech startups that thrive on innovation: Zenva and Super Colegio, Pablo is always enthusiast about new technologies and creating solutions for an exponential world.