Apr 082013
 

I’m trying to test the viability of Monster Loves You! on the new iPad, and I’m running into a bit of a gotcha. Any advice would be appreciated.

(I’m use Haxe+NME and Adobe AIR)

The high resolution of the new iPad means that the background art takes a half second to load for each image (and there are about 40 or 50 of them). This puts a very visible “chunk” into the gameplay, which I work around by pre-loading all the backdrops at load time. Which takes quite a while and takes up a horde of memory, but it works. Still, fetching the image from memory makes a (now smaller) but still noticeable delay.

Worse, pre-loading all the images requires more memory than the iPad 2 has, and it crashes on load right at the start. So I’m stuck with the individual-loading delay no matter what here.

I’m terrified of even glancing sideways at the original iPad.

Is there an easy way to get large (2048×1536) images from the Haxe Asset Library to display onscreen super quickly that I’m overlooking?

Dec 282012
 

This is a meta-post about this blog and game development. Bear with me for a few minutes. It’s in disguise:

===

Sometimes life is a constant stream of discoveries and surprises; revelations brought on by the self are some of my most cherished.  To me, living is about exploration.

That may explain why I insist on making all of my own mistakes and re-inventing the wheel over and over again. It can be a flaw!  It may even produce some stubborn opinions about things, but as long as I’m having fun, I don’t mind.

But sometimes (well, okay, frequently,) I lack the expertise to even start questioning myself, to know if I’ve made a mistake. I lack the ability to make a decision for myself, or draw a conclusion. The internet can be a good resource, but sometimes data is sorely lacking. Here’s some examples I thought of in the shower this morning, questions I cannot answer (and suspect I may never be able to convince myself of, in my lifetime):

  • When doing the “Plank” exercise, why is it always carried out on the elbow and not on the extended arm? If it’s about hip-distance-from-floor, can I use an extended arm and just put a cardboard box under me? If it’s about angle on the ankles, can I just put the ankles up on the cardboard box?
  • Ever since I received (as a teenager) my very own Gillette Mach 3 razor – I’ve never cut myself shaving. Is this a property of the razor? Or is it that my skill reached a certain point and the razor type is incidental?
  • Do the three blades of the Mach3 actually matter? I used to swear by it, but I don’t actually remember what I used before that. The other day I bought a 50-cent double-blade disposable from a corner store and it seemed to cut just as good as my Mach3 back home. What’s up with that?
  • When going for weight loss, people often recommend eating a full 3 meals a day (or, preferably, 5 smaller meals throughout the day). How much of that is game theory? How much of that is people trying to bake healthy-eating stuff in but is otherwise ineffectual to weight loss itself? For example: If I skip breakfast every day for the next 5 years, that is sample A. If I eat breakfast every day for the next 5 years, that is sample B. If nothing else changes (theoretical, big if), will “B” actually lose more weight?! I find this unbelievable, yet experts say it is true. Are they counting on increased energy levels and activity levels that result from breakfast? If so, why don’t they just say so?!
  • Who says 5 is the best number of meals for a day? What if I have 6 slightly smaller meals throughout the day? 7 slightly smaller than that? Someone, somewhere, probably made a call on how many meals was “too annoying to bother with.” What was their math based on? What is the actual underlying formula? Is best case actually to eat a single pea from a pod every other minute in the day?
  • How many glasses of water per day should I have for my current (sedentary, high-humidity) lifestyle? I mean, aside from the stuff I get from food (like a bowl of soup shouldn’t count towards a glass of water).

I don’t think I’ll ever be able to answer these myself because they are benign, low-interest, and generic enough that not many people really care. Most of it is about body and diet, and scouring the library, the internet, or even “professionals” (like the trainers at the gym I go to) will just respond with rote responses they learned, without understanding the underlying reasons. Arguing about razors and how much they cut is like asking a room full of people about opinions. Where are my facts?!?!

I just want to find out the truth behind these, so I can start asking follow-up questions and living a more fulfilling life. For that, I need an expert.

I need someone that knows their stuff. Someone that can answer all the hows and whys of those questions. Someone that can unveil the (often boring) reasons behind all those decision. Someone that has the balls to say to my face that, yes, the 5-glasses-of-water-per-day number was a completely made up statistic with no backing to it, but it can’t be bad for you, so I should just do it anyway. Someone that can say, with confidence, accuracy, and supporting articles, that it’s bullshit.

Or maybe it isn’t bullshit?

I can’t know. And it’ll drive me crazy!

===

And this is why I post so many intimate details here on my blog.  Why I post my contract terms, my Y-axis, my personal life and how I deal with it (and how that correlates with game dev), and all sorts of other information: I may not be an expert, but some of the things I’ve posted to this here blog are unique on the internet: for those categories, I’m the best you will (publicly) get.

By posting my data, I get comments, private emails, and lots of feedback. Sometimes my assumptions are corrected, sometimes my statements are backed up. I learn new things. People more talented than myself flock to my blog to point out my mistakes (THANK YOU!!), and those less talented flock to my blog to learn from my mistakes (I LOVE YOU!!!!). People on equal footing are just sharing in this awesome experience of life (YOU ARE AMAZING!!!). This is why my target audience here is other game developers, not the fans of my games.

This blog is my opportunity to help other people out, and learn myself. I’m frustrated that some questions can’t be answered directly by any professional, and questions asked on how to code certain things properly in forums are usually responded to with a shovel full of opinions.

When I find the answers, in this one tiny niche that I call my field of expertise, I post it publicly. So that everybody else can know the answer too. Some may say this is silly (if I keep my secrets, I can be hired as an expert!).  I disagree; speaking my mind about silly bugs and flaws and holes in various languages has landed me more job offers than any resume I’ve ever written, and more than my stupid LinkedIn profile. Never mind all the new friends I’ve found here! (*waves to followers happily*)

So I hope you enjoy it, getting some details you might not see elsewhere. I hope you learn something, or help me to learn something. I hope you love this blog as much as I like writing it.

Now I just have to find an expert on the human body that is willing to swap notes with me…

Dec 032012
 

Ugh.

I’ve been banging my head against the wall for 4 days now, trying to get SteamWorks integration into Monster Loves You. Long story short, the SteamWorks API is only available in C++; someone made an unofficial SWC/ANE in AS3 that helps link it up; I’m trying to import that into Haxe; it only runs wrapped in an Adobe AIR runtime.

I feel like some kind of evil wizard, trying to smash together Haxe, AS3, a C++ Library, and AIR. Noxious fumes arise from my boiling cauldron.

I’ve almost got it all working now, and thanks to some help in IRC and such, but now I’m stuck. Maybe someone out there can help?

Here’s the library I’m trying to use.

I’ve unzipped the .SWF from the .SWC file and have it code-completing in FlashDevelop, and compiling without error. Code is executing.

In one of the .SWF classes, there is an Adobe AIR function call; the app no longer works unless I wrap it in Adobe AIR (ADL.exe works great for this). Haxe/NME doesn’t include AIR references, but I worked around that by using Jan Flanders “Air3″ haxelib. That hurdle overcome.

Line 24 of this class, though, throws a null error.

Line 23 is the AIR call to instantiate the extension. This function returns null if it’s unable to find the reference to the extension in the AIR XML. “Oh,” I think. “I know this one! If I add:


[extensionID]com.amanitadesign.steam.FRESteamWorks[/extensionID]

to my application.xml, it should work!” (brackets changed for HTML sanity) So add it I did. But this is where my problem lies: upon execution AIR attempts to import all the listed extensions and include them in the binary. This is an unnecessary step, since Haxe already compiled the library into the .SWF. If I don’t list the extension, I get the null error listed above. If I include the extension, I get this error when ADL tries to run:

Error: The extension com.amanitadesign.steam.FRESteamWorks has either a namespac
e version or library.swf with a version that is incompatible with the applicatio
ns namespace or root SWF.

So my question then is: Is it possible to get AIR to register an extensionID that is already included, and not attempt to include it itself?

- or –

Is it possible for Haxe to externally include the .SWF (not internally) so AIR can grab it and do it’s thing?

- or –

Am I making some grievous error that is making this more complicated than it should be?

I’ll owe you a beer if you can help.

Sep 072012
 

For some background on one of my latest games, D.U.C.K., I’ll have to tell a personal story. And it’s going to sound a bit like bragging, but bear with me.

THE JOB OFFER

Last November, a “dream job” caught my attention.  A new (only 1 published game) casual game company in California was looking for someone to rapidly prototype quick gameplay mechanics – hopefully a new one per day, on average – and just keep cranking them out. Basically do a game-jam every day, with just grey-boxes and no presentation or polish necessary.

It was the company’s intention to get a nice catalogue of gameplay mechanics, pick out the best ones, and hand them to another team to brush up and insert as mini-games into their larger casual titles (for both launch and game updates down the road).

Wow. For a guy like me, that was perfect. I dislike working with content-reliant games; I tend to focus on pure mechanics and quick 5-minute gameplay experiences.  I think of polish and art as necessary chores for success; and none of that was required here.  I think one of my greatest strengths is my rapid delivery style; the drawbacks for such (unusable code, for example) don’t count against a job posting like this (where the mechanic will just be rewritten anyway).

Imagine that: Spend a few hours hammering out a quick silly fun game… and hang up your hat, call it a day, and move on. I could make a game a day for an entire year (minus weekends and holidays) and not have to worry about paying rent?! Fantastic!

THE INTERVIEW

I seriously considered giving everything up for this job.  Moving to California, halting Radial Games, cancelling any outstanding projects… It was very promising.  I was flown in on two occasions for interviews, and the salary offered was triple any amount I’ve ever made before (not that indie development is a rockstar job). They even picked me up from the airport in a limo. A limo with free wi-fi on board.

Part of the interview process was a test. You know, one designed to show off your chops, both for game design fundamentals, technical proficiency, source code legibility, and speed of development.  To make things [arguably] a bit easier, they provided a theme of “classic video game with a new spin,” and a time limit of 1 day of development (and up to 6 days of preparation).  The game being fun, marketable, or casual were not requirements at all;  just the ability to execute.

I hung up the phone at 5PM, with an expectation to deliver the game the same time next week.

Sounds like a challenge.

THE GAME

I started off with Duck Hunt as a theme, and thought back to those old typing-tutor games I used to like so much. Why not smash the two together? The idea flew off the top of my head pretty danged quickly.

I figured if I was working at this company, I’d need to execute on ideas in a day. I know the standard of “8 hour shifts” include copious amounts of goofing off and cat videos, but I know personally that I can get three or four solid, uninterrupted work hours in a day. So I set that as my personal goal: finish this game in 3 hours. I started a log file.

5:45PM: Thinking
5:50PM: Began setting up environment, generating API keys for stat tracking, etc.
6:00PM: Began Art Asset generation, OFFICIAL START TIME
6:25PM: Finished all intended art. Begin Code!
6:40PM: Basic mechanic implemented (not fun yet)
7:11PM: First fun playable build (#47). Taking a break to fix weird preloader error in the IE8 + Flash 10.0
7:48PM: That particular combination doesn’t like classic programatic debug-mode detection. Developed workaround.
8:10PM: Caught edge cases, changed scoring and added score threats. Not just fun, but a challenge now. (#61)
8:17PM: Added countdown timer.
8:25PM: Added end state and fixed keyboard focus issues.
8:32PM: High scores implemented; sending game out for playtesting (#73)
9:09PM: Added some basic bird animations and waving grass.
9:20PM: Build 108 final build created, incorporates minor fixes and edge cases.
9:30PM: Official Deadline (not counting 30 minute preloader error)

Blammo. I had created D.U.C.K. You can play it by clicking here. Shoot each wave of ducks down by typing the letter card they are holding. Bonus points for juggling a single duck multiple times; big penalties for mis-typing! Perfection is the only way to win!

PLAY HERESOURCE HERE

It’s a basic idea of a mechanic that can be fleshed out into it’s own full-blown game, if there were any interest in that. It’s fun-enough and polished-enough to the point where it’s easy to see where it can possibly go, and where it’s potential failings are.  This game is worth a whole lot more than a design document for a similar game, and was probably executed faster than that design doc could have been written.

But it’s not just a grey-boxed mechanic. Take a look at that development log again. It includes asset creation, play-testing (yay twitter!), bug fixing and multi-browser compliancy tests, in-game metric linkages (highscores are recorded on the back-end; not publicly displayed yet), and even some bonus parallax grass waving in the foreground, just for some visual flair. And all of this in just 3 hours work.

THE GREATEST RESUME

People often ask me how to “break into” the games industry.  My standard response is to make your games your resume. Not many companies actually care about your education (I have no academic degrees!) or your years of experience; the most important thing is what you’ve created so far.

In this situation, I had created a game that said I could do exactly what the job required of me, and then some. I could go above and beyond. And better yet, I have a history of a dozen games under my belt that do the same – all those jam games are not worthless.

WHAT ABOUT THE JOB?

I had taken a long hard look at the situation. I really wanted the money, and really didn’t want to move. I wanted to be released of my indie responsibilities, but not have a boss.  I was very much flip-flopping on the whole job offer, and had to go renegotiate a few times for more concessions in my favour. But still, this was a casual game company. Their primary focus was a style of games I didn’t agree with or enjoy. I wasn’t sure I was willing to sell my soul for any price.

In the end, I decided not to take the job, and continue on my own special indie career. All the same, the company was snatched up by Zynga a few months later, and I would have lost all my potential indie cred then.

I AM NOT SPECIAL

I know this has sounded a whole lot like bragging so far, but here’s the thing: I’m not very good at this ultra-fast-game-dev-thing. I’m just one of the few that tries. Everybody else I know that takes my 5-minute game challenge makes better, more interesting games – faster than I can imagine possible. I’ve seen 48-hour game jam games that absolutely blow me away, being made at my own local game jams, by people I’ve never met before.

I’ll bet that nearly all the game designers/engineers out there reading this blog could do better than friggin’ D.U.C.K. if they set aside just 3 hours of time tonight. So why not give it a try? It might land you that dream job… or it might set you off on an indie development career. Go to game jams. Take the Ludum Dare challenges.  MAKE SOME GAMES.

Jul 012012
 

I’m using the Flex 4.6 SDK and compiling .SWF files with it. Occasionally, I add an SWC library to my projects, and usually they behave normally – whether they are external libraries or internal libraries (In FlashDevelop, right click the SWC file, hit options, and you’ll see the choices there).

Recently, I’ve been using a lot of products from MilkManGames to help my AS3 applications take full advantage of mobile features. As I became more and more reliant on them, I realized I had – at some point – crossed a line where my applications would start crashing on launch on mobile devices… But only when compiled to native bytecode (as opposed to content projector, aka the “fast compile”).

I’ve actually been banging my head against this one for 4 or 5 months. It’s kind of a problem, because content projectors run more slowly than native bytecode. And, more seriously, it’s against Apples TOS to submit content-projector items to the App Store.

In a fit of frustration, I submitted the latest version of IceBurgers to the iOS market as a content projector and Apple didn’t notice, so that’s why you can buy it today. It’s still against the TOS and they could technically pull it at any time, so I still wanted to get to the bottom of this. The fellows at MilkManGames were quite patient and tried all sorts of things. FlashDevelop support couldn’t help. Twitter was no use.

Well, last night, I finally figured it out.

It’s a pretty serious bug in the Flex compiler (and/or a really shitty intended feature?), that only kicks in when your project uses a PRELOADER. Here’s a screenshot of my Main.as file:

You can see I’m using the compiler-command factoryclass method to import a preloader at runtime. I also picked a random .SWC file to include, in this case it is the SilentSwitch utility. I’ve instructed the compiler to include SilentSwitch as an external library – that is, I intend to bundle the ANE file together with it at some point, and I don’t want it to import the library into my compiled .SWF file.

This works as intended, so far.

But if, in the preloader file, I make a reference to SilentSwitch… It will include the SWC library into the SWF file. If I were then to compile it together with the ANE file and make a native IPA file for iOS release, the incorporated ANE classes conflict with the precompiled SWC classes (they are one and the same) and the app will CTD. (haha, that was a lot of acronyms!)

If you’re having trouble following, and have a copy of FlashDevelop, just check out this project I put together. If you don’t have FD or the appropriate compilers handy, I included two SWF files in that archive – one compiled each way, so you can explore and see that the assets were included in one and not the other.

I’m guessing that when the Flex compiler encounters a FactoryClass method, it forgets the compiler instructions for including things externally for some reason.

I’ve filed an official bug report, but in the meantime there is a quick and easy solution: Move all of your SWC references out of any factoryClasses (preloaders) you may have.

Edit: It appears this is a terrible tech limitation of the Flex compiler, and is pretty-much working “as intended.” You are expected to put all external libraries in frame 2… Of course this behaviour is not documented anywhere, and no tutorial mentions it as a gotcha. :)

Jun 022012
 

What makes a really good color theme for your code? I don’t even know. I’m blindly following other people’s examples and trying to find something that works for me. Sometimes I’ll stumble across awesome text editors that have great default themes, and sometimes I’ll bump into threads on forums that have a bunch of screenshots.

I tried to write out what I’d like in list form, and this is what I came up with:

  • I’d like a dark theme, as I do a lot of late-night coding. White backdrops just hurt the eyes with brightness!
  • I know that a flat-black backdrop makes for some quick eyestrain.
  • I don’t like it when a particular element really grabs my attention; if boolean values are bright orange, I get angry!
  • I personally like earth-tones; browns and greens.
  • I also like the old flourescent-green monitors of yester-year and also The Matrix.
  • I want the main body of text – the things I’ll be looking at the most – to be easily readable.

After searching for a while I decided I’d build my own theme. I had seemed to find those elements separately in other themes, but never together in one package.

Here’s what I came up with:

This is actually my third attempt at making a theme and I think it’s the best one yet… But it’s always evolving. I’d be interested to hear what other people look for in a theme (and any comments on this one in particular)! Maybe someday I’ll come across something I can consider perfect.

I used to have a thing for making my comments bright yellow, but I’m veering away from that for the first time as a test. :)

Download here! If you have FlashDevelop installed, just double click the file and re-start the application. I’ve only coded the AS3 language extension, so if you use Haxe or something you won’t get this effect.

May 232012
 

So I swore I’d never touch Haxe ever on twitter recently. At least for a year or so. Why? Well, I’m too busy; Haxe isn’t quite mature enough for my tastes; support forums are kinda slim pickings and it’s hard to Google solutions to common problems. Mostly, though? I’m just scared of new things. I knew I should probably give it a try, and just decided not to.

A Wild Update Appears!

Well, early this morning a new version of FlashDevelop was released, with enhanced support for Haxe NME. I found myself in a fell mood, locked myself in with a livestream, and gave myself 1 hour to learn Haxe and make a game!

First up, some Q&A. These are questions I had that I didn’t really know the answers to until I dug into it, so I’ll share what I found with you:

What is HAXE?

 It’s a free programming language whose syntax is based on ECMAScript (similar to UnityScript, ActionScript 3, and Dart syntax). The project grew out of AS3, so it bears the most similarity to it. Here’s the official website and the wikipedia entry. I don’t recommend you download Haxe just yet, read on…

How do you pronounce it?

Wikipedia says it’s officially “hex,” but some jerks call it “hacks” and it’s starting to stick. I’m going to call it “hex” from now on!

What is NME?

It’s a free library collection for Haxe that closely emulates the Flash libraries we know and love – the DisplayList, Sprites, Bitmaps, Textfields, Points, Events… All those lovely things. The combination of Haxe and NME creates the most comfortable transitional environment for AS3 developers, though there are some big changes. See the official website here. The download for NME includes Haxe itself, along with a bunch of other requisite files, so I recommend grabbing this!

Why use Haxe NME?

The two biggest reasons to use Haxe NME are SPEED and OUTPUT TARGETS.

SPEED: Haxe NME consistently outperforms every single AS3 metric I’ve seen. Name a test. Any test. Haxe NME will outperform it. Adobe’s .SWF compilations, AIR compilations, and even AIR’s swf-to-native-bytecode iOS/android compilations introduced in AIR 3.1 can’t touch this magic. From iterating through arrays to displaying particle effects, Haxe is simply a better compiler.

OUTPUT TARGETS: Haxe NME can compile to just about anything, natively. iOS, Android, WebOS, BlackBery, Windows, Mac, Linux, HTML5, and good ol’ fashioned SWF. If you lose the NME library, you can even target PHP, C++, JavaScript, Java, Neko, and C#. This is the swiss-army-knife of development tools.

Another good reason to use it? It’s a more advanced/mature language than AS3, so some common annoyances have been addressed and many aspects of development are much easier.

What’s different between AS3 and Haxe syntax?

Take a look at this article right here, it’s pretty much my bible as an ActionScript developer. Check out the awesome upgrade to FOR loops in there. We even have (optional) automatic type inference in there, while maintaining strict typing! Less keystrokes with all the debugging magic. You should also read this whole blog, it’s great.

So what did I make?

I opened up FlashDevelop, and with no experience (and armed with only the basic knowledge above) I started hacking away at a Haxe project. LiveStream captured my hour-long effort, but an hour of me getting frustrated and looking at docs doesn’t make for good TV, so I didn’t paste it to youtube. If you really badly want to check it out, look in my Twitch.TV video archive. :P

With a lot of help from the studio audience (Pekuja in particular!), I managed to get a little game together: FACE CHASER! Play it now!

  • Your face is being chased down by an ANGRIER face!
  • The angry face has 3 hit points, which it loses as it bumps into the edge of your browser. You’ve got to play chicken with it!
  • When angry face dies, a FASTER angry face appears!
  • If angry face touches you, YOU DIE Spams the background!

You can check out a .ZIP of my complete FlashDevelop package here, if you want it. I wouldn’t. :3

So how was Haxe NME?

Intriguing. It’ll take a lot of practice to get coding in it quickly, and I’ll need to convert a lot of my library helper functions, but it’s overall pretty darn good.

I wouldn’t use Haxe NME for a commercially sensitive project right now. If something goes wrong, or you need a fancy binary plugin library or something, you might be out of luck. But if you keep things simple…

Well, let’s just say I’m going to try to use Haxe NME for all my future game jams. :) Maybe slowly over time I’ll get up the courage to use it for everything!

Mar 122012
 

“Andy, Andy,” a man shouts excitedly. “I love your blog post on improving mobile performance with AS3!”

Andy has heard this phrase dozens of times now, having just attended a GDC full of flash and mobile development friends. “Thank you, fine sir. I hope it worked out well for you.”

“Well…” He stammers for a few seconds, and tugs on his collar in an absent-minded fashion. “I’m not seeing the performance increase of astounding amounts. It might be a little faster… I just can’t figure it out. It’s a simple game, and it gets quite low FPS!”

Andy has heard this complaint before, and is immediately skeptical, but maintains his composure. He asks the standard battery of questions – did they do the bitmap caching properly, do they have a proper static variable in the wrapper class, but they never seem to lead to a solution. Everything seems fine. That is, until Andy asks the fateful question: “Are you displaying the Bitmaps wrapped in a Sprite, as I suggested in the article?”

“Oh, I don’t need to,” he responds. “I’m using flixel.”

It really is a sight to see; watching somebody calmly grab the edge of a table, and in one quick motion flipping it over. The world seems to enter bullet-time; the salt shaker spinning through the air, the table completing two full rotations before first touching down on the ground. As Andy rises from his chair – face bright red in anger, veins bulging from his incredibly muscular neck – he looks to the sky. With arms outstretched, a primal roar escapes his lips.

Andy then sits back down, corrects his table, and instructs this fellow developer to read the whole article, particularly the bit at the end that says that blitting (and by extension, all blitting engines, such as Flixel and Flashpunk) circumvent the performance enhancements. Andy then recovers the salt shaker, and calmly explains how the start of the article also mentions the use of flash’s standard display list.

The man finally realizes his folly. Flash does not* have access to the powerful GPU on desktop computers, and blitting is a way to more efficiently use the CPU to render things. On mobile devices, flash DOES have access to the GPU, and automatically does a blitting-equivalent of the display list. Telling flash to use blitting manually (by using Flixel/Flashpunk) is telling it to NOT use the GPU, but the CPU instead, hobbling perfromance. He then gives Andy a million dollars.

*stage3d not counted

Feb 292012
 

In June of 2011 I launched a game called ATC Blitz. I had this article half written in my drafts folder, and decided to finally push it out there – now that we have some data!

Inception

After a long day of coding UI stuff for SteamBirds, I settled into bed and had a quick game of Flight Control HD with my girlfriend. With Air Traffic Control on my mind as I tried to fall asleep, my thoughts wandered back to some old ATC games I used to play.

One of my favorites was ATC Simulator by Russel B. Davis/AeroStudios. This is a very high quality product and one of the first indie games I bought – it is as close as you can get to the real thing, even including full-on voice support and using actual airplane data.

Couldn’t the realism of ATC Simulator be combined with Flight Control?

I couldn’t sleep for an hour or two. I lay there wondering if I should just bolt out of bed and get my ideas down – but decided I’d just keep laying there, thinking about the ton of gameplay possbilities here. I was really excited.

Gameplay

The idea I settled on was something like a semi-realistic ATC game. Unlike Flight Control, where airplanes turn on a dime, planes would slowly turn to take on the headings you grant them. You’d also tell the aircraft at what speed to fly, and at what altitude (at least, initially). This would be done from a  familiar interface though; here’s what it ended up looking like:

I actually ended up going for a visual style I first used with Dan Cook in the original SteamBirds prototypes: cut-out airplanes, shadows, and cartoon-like forests. I really like it!

Execution

I really wanted to get this prototype done and out the door as fast as possible, so I set a goal: complete the game with only 24 hours of total work. For the entire game, not just my portion of the work! It’s like a game jam, but with each person you team up with, your time halves!

So right after waking up I started coding and went straight for around 9 hours. Since this game is mostly about time management with time-sensitive movement, this is the first game I’ve ever made that uses the clock as a gameloop instead of just using “ticks” or logic-loops tied to FPS.

The game actually runs at 60FPS, but the planes only update their positions at 10FPS.  That’s allright, since the planes don’t do a lot of zipping around and it makes the UI feel super responsive. It also helps cut down on the expensive collision/landing checking.

It’s always fun to try something new, and I think this approach was interesting – where items in the game are all synchronizing and updating at different speeds. I spent more time than I’d have liked to on it, but worth it in the end.

After I finished up the bulk of the code and the game was playable, I started asking around on chat rooms to see if there’s any artists that want to clean things up for me. It’s hard to find someone willing to get the job done in around 8 hours or less, but Andrew Sandifer was willing to accept the challenge!

We also got together with DVG Music, who was able to put together an audio track for us within our rediculous time constraints. One of my favorite things about the game is the music!

The Twist Ending

After everything was said and done, I sat back and gazed fondly upon my creation. A good little flash game! It was fun, if rough in places. But I hadn’t quite used up my entire 24 hour allotment. What should I do next?

Port it to Blackberry Playbook, obviously! Other than some initial hurdles and signing problems, it ended up being relatively painless with only minor code updates.

Blackberry ended up sending me a free playbook for the deal, and the game remains otherwise unreleased to this day.

Afterthoughts

Two lessons learned with this game.

The first lesson was about user experience and the concept of fun.

Being a pilot, and having played a lot of ATC games, I know about procedures – I know how things should look – I know how fast things play out. Here’s a quick fact: All airplanes try to turn 360 degrees in 2 minutes. Sure, each airplane can turn faster than that, but for the sake of ATC sanity there is a “standard” turn that is both safe, relatively fast, and an important bonus: is comfortable for passengers.

The 2 minute turn is a concept that has been in this game for ages – since the very first lines of code.

And it was terrible. It was not fun at all. I hate it when this happens – I mean, there’s realism, and there’s sticking to your artistic guns… But when it doesn’t pan out? That’s really rough.

The second lesson is about the wonderful world of Twips.

This one was a mind-boggling bug, but eventually tracked it down thanks to the FGL Forums and Twitter. As the aircraft slowly creeped across the screen in full-realism mode, I was incrementing the pixel location values by small amounts (this.x += 0.04;, for example). These changes appeared to be rounded-down to zero and the planes weren’t moving at all.

Turns out Flash stores coordinates in Twips, which is 1/20th of a pixel. That means anything smaller than 0.05 gets lost in the background noise. I was surprised I had never run into this before, but there we have it!

The quick and easy solution is to record the actual X/Y coordinates in your own number variables and increment *those*. They don’t get rounded down. Then you can just say this.x = myXVar;

Show Me The Money!

lol, what money?

I mean it’s nice seeing the occasional cheque every month, but so far the game has only grossed $220. That’s $9/hour! Yesss, above minimum wage! As sales continue into the future it’ll only get better, too!

Part of this is a function of the day-long dev cycle on this game, and how unpolished it really is. The bigger function is this is on the Blackberry Playbook. Frankly I’m happy with how well it’s done!

Future Prospects

Both Andrew Sandifer and I think this game has a lot of potential and – given some actual work and polish – this game could become something awesome. Look forward to a properly-done sequel!

Was it worth it?

I launched a prototype. I got some good feedback on the fun-levels; I learned something new; I implemented new code systems, ported to a mobile device, and dipped my toe in the pond of a new piece of hardware. I’ve got a ton of tested ideas for what is fun in gameplay, and I have a few dozen ideas for sequels.

All of this only cost me around 11 hours of my time. And for my trouble, I was given a free playbook and $220 (which I shared with my co-conspirators).

Worth it? Hell yes.

Feb 232012
 

Well, it’s about time I wrap up my word-game devlog, since development finally finished! I’ll continue on with more news as it happens, you know, if the game makes me a bazillionaire or something.

The last 10%

It’s really not a whole lot to talk about. I think I announced on Twitter that my game was “bug free!” about 9 times; I struggled with iOS provisioning profiles; I installed my first ever Mac OS so that I could upload my app to the store… I mean, really, not much… That’s all I did. And it only took around 25 hours to do. *shakes fists* That almost doubled my current time-on-project!

So! Let’s recap what has happened so far:

Development Timeline

  • January 22nd: Started working on the game
  • Devlog: First four days of development
  • Devlog: Day Five
  • Devlog: Day Six
  • Devlog: Day Seven
  • Devlog: Week Two
  • A bunch of boring bug-hunting and iOS submission headaches for week 3 and 4
  • The game was pushed to the iOS App Store for review on February 22nd, exactly 1 month after development started!

Total Time Investment

The development timeline has me working for almost exactly 30 days from start-to-end, but if you read my devlogs you’d notice I skipped out on a lot of days; vacations and events were intermixed, and I wasn’t exactly sitting at my desk, 9-5, Monday through Friday. I thought this might happen, so I did my best to record how many hours I actually spent on the project. Here’s how it breaks down:

  • 9 hours spent developing the core game/engine/tech/etc – prototype complete.
  • 22 hours spent iterating on the prototype design and polishing up the experience
  • 20 hours spent doing graphical polishing, bug-hunting, etc.
  • 20 hours spent wrestling with iOS related headaches

That means I’ve put in a total of 71 hours (8 days of full-time work, or a standard “crunch” work week) over the course of this project. Awesome!

It wasn’t just me, though; Alec Holowka provided a musical track for the game, which I’m guessing took him around 10 hours to do (he’s unsure, he was working on other projects at the time too).

I also had Sven Bergrstom do the art for the game, which he estimates to be around 30 hours of work (but again, many other projects going on and that figure is probably inaccurate).

What’s Next?

Barring any unforseen problems, the game should be up for sale on the iOS app-store within the next week. I’ve ordered some TShirts and Stickers, and will be giving them out at GDC. I’ve got Kert Gartner working on a trailer for me, and hopefully I can show that off soon.

Basically, my GDC week is once again going to be full of anxiety as I launch a game.  I seem to do this every year!

Thanks for reading this far!  As a bonus you get to see some sneak-peak mockup pictures.