Still alive, much has changed!

Hello there!

In the nearly 3 years since I last posted:

  • Stalled out on the Project Smart Birds I was talking about last
  • Took on some game dev contract work
  • Taught a java class at a community college
  • My first son was born!
  • Got a programming job at an insurance company
  • Decided to bring my old Captain Dynamite project back from the dead, started porting to Unity
  • Got a different programming job, this one at a much cooler company
  • I have another son on the way, due in March!
  • Still working on Captain Dynamite Unity, focusing on iOS release.  Getting closer.

I intend/hope to keep this more current.  Let’s see how it goes!

Deploying to iDevices

I spent a good chunk of my day yesterday doing the prerequisites needed to deploy a Unity test build onto my 2 iDevices (iPod Touch 4 and iPad 2). This was a lengthier-than-expected process, which included…

  • Finished registering for an Apple Developer account. Paid the $99 the night before. For right now, it’s set up as an individual account so I could start without delay. Sometime soon, I’ll have them convert it to a company account for my LLC, but for the time being this will work.
  • Upgraded OS X to the newest version. At least it was pretty cheap, only $20. Considering that Apple’s hardware is pretty expensive, I was pleasantly surprised at the low cost here.
  • Waited quite a while for the above’s download and installation to finish. The broken progress bar (“-5 minutes remaining,” etc.) was a fun touch.
  • Downloaded XCode, synced my devices, and built and deployed one of Apple’s sample projects as a test.
  • Built and deployed a Unity project to both devices. It worked! But deploying is super-slow. Did some research to find out that if I update the device OSes, this process should be faster.
  • Updated both devices, and deployed again on both. Much faster!

As an aside, I am primarily a Windows user; I only have a Mac to facilitate app development. These 2 OSes have a lot of subtle differences, but the one that bothers me the most is the fact that on Macs, you use Cmd (Command, or the Windows key) + [whatever] instead of Ctrl + [whatever] for shortcuts. I have nothing logically against the Mac way, but 15-ish years of doing it the Windows way… I’ll just say that each time I had to scrunch my pinky over to hit that Windows key after first hitting Ctrl, I would cry a little on the inside. So after doing this one too many times, I finally dug into the Mac settings and found the way to change it — now I can use Ctrl for my shortcuts!

Unity workflow: expectations vs. reality

By this point I’ve gone through tutorials for both Unity and 2D Toolkit, and I’m really pleased about my decisions to use both. Unity is a solid engine and editor, and the fact that it can output to so many platforms with minimal hassle is really impressive. And 2D Toolkit is a fantastic extension — it essentially lets me forget about the fact that Unity is a 3D platform, which for this project is a big help.

But, working in Unity is a lot different than what I’m used to. Sure, it lets me use C#, which I already know. But I’m used to something like…

void main()

…and within that I would build a state machine and start making the game. Using that method, game logic is pretty straightforward (at least as much as a given game design will allow), but asset- and display-related issues (loading, drawing, animating, cameras, etc.) require a decent amount of work.

But Unity is not like that. I knew Unity was somewhat different than what I was used to — I had seen editor screenshots and skimmed a video or two — but honestly, I thought it was more or less the above but with something like 3D Studio Max built in for doing level layouts. Though my expectation of the scene editor was pretty close to reality, I was wrong about the coding aspect. There is no main(), at least not one that you have direct access to.

In short, to contrast the above, with Unity the asset- and display-related issues are essentially free — you don’t worry about loading things via function calls, just make sure they’ve been dragged into the appropriate scene and they’ll display. Same for audio: if a button needs to play a sound effect upon tap, drag the sound file onto that button — no loading required. Now, you’ll still need to write code, but not in the way I was used to. I don’t control the main loop. Instead, I write code files (“scripts”) that I attach to objects in a scene, and each object’s script is run each frame. It works, and honestly I believe this set up will end up being very efficient, but for now it feels very foreign.

I’ve resigned myself to the fact that — particularly because this is a new paradigm for me — I’m going to be doing a lot of things the “wrong” way on my initial implementation of Project Smart Birds. But in order to finish the project relatively quickly, I must. It will pain me somewhat, but I must! After the game is complete and I have learned enough to realize that I made some boneheaded implementation design decisions, I can go back through and fix things as warranted.

Not Corona

So I chose Unity, but my runner up was Corona. For iOS and Android games, Corona is certainly a solid choice. From what I gathered, 2D game development seemed more straightforward than on Unity. And it’s capable of great results — the polished Major Magnet for iOS was made with Corona and proves that point. But a few aspects helped push me to Unity:

  • Corona is multiplatform, but only for mobile devices. No PC, Mac, or console support. Those platforms aren’t my priorities, particularly not immediately, but I want them to be options.
  • Corona builds are made “in the cloud”. You can run your code on a simulator without building, but if you want to build, it has to happen via their online process. There’s a benefit: they update the SDK often, and you don’t have to worry about constantly downloading SDK updates. But if either you or they have network problems, you can’t build. And if the company ever goes out of business, effective immediately you can no longer make builds — unlikely, but still a risky position to be in.
  • Corona requires a yearly fee to keep using it. The per-year fee is less than a similarly-featured Unity license, but the Unity license is permanent for that version of the software. If this works out for me, I intend to do this for at least a few years, so the larger up-front cost ends up being a better option.


I’m using Unity to develop Project Smart Birds. Why Unity?

The game will be initially for iOS, but after that initial release I want to port to Android, PC, and Mac — and later on, perhaps other platforms too. To increase my chances of success, it’s important that I reach as many potential players as possible with as little extra work as possible. So using some sort of multi-platform SDK was a given. I researched my options, and Unity won out for these reasons:

  • It uses C#, which I have experience with from using XNA.
  • It supports a LOT of platforms, including web browsers and consoles. They support more platforms than any other SDK I could find.
  • Since it is already on the PS3 and 360, chances are good that it will be supported on the PS4 and 720 as well. Not that I’m anticipating going to these platforms anytime soon, but good to know that they’ll likely be an option.
  • Unity the company is established and successful. They’ve been around since 2008 and continue to grow. Sure, any company could tank unexpectedly, but all signs I can see point to this company to continue to exist and support the technology that I’m tying myself to.
  • A lot of companies are looking for Unity programmers. If my indie stuff fails, experience in Unity could help me land a job elsewhere.

The main con for me is that — right now at least — I’m making a simple 2D game, and Unity is more complex than it needs to be for 2D-only games. But luckily, Unity’s asset store has some solid 2D systems that are pretty inexpensive (I’m going with 2D Toolkit), and these help make this issue mostly moot.

All told, I believe that of the available options, I have the best chance of success — both immediate and longer term — with Unity.

iOS Menu Design

I think user interface (UI) design is really important.  While well-designed menus & gameplay UI can’t save a bad game, they can make a good game feel even more polished.  And luckily, I really like doing UI design – the functional part, that is.  I’m not an artist and don’t try to make things pretty, but I can handle usability and layout.

I’m done fleshing out the functional mockups for Project Smart Birds’ menus, so I wanted to share them and the rationales for many of the decisions I made.


My process for functional mockups is pretty simple.  It’s all pen and paper until I’m done, then I scan it for a digital copy.  First I use a lot of “scratch paper” to narrow down what to do.  Then once I know what I want, I draw each screen’s mockup into a pre-printed rectangle of the appropriate dimensions.  My iOS templates have 8 rectangles per sheet of paper, with each rectangle a little larger than an iPod 4’s screen.


My high-level goals for the menus are few and straightforward:

  • Menu layouts should be appropriate for iOS (mobile & tablet) AND for other platforms like PC and console.  I don’t mind making tweaks later, but I want a solid base that won’t need to be completely redesigned.
  • While still meeting the above, try to stick with solid iOS standards & conventions.  Since iOS is my lead platform, I want the interface to be familiar and friendly to iOS gamers.
  • Consolidate info where possible, and try to minimize clutter.

Read more…


I’m trying to wrap up the high- and mid-level design for Project Smart Birds (see 1st listing under “My Projects” here), and one of the topics I’m dealing with is monetization — how to make money from the game. My current plan is for it to be a paid app with optional in-app purchases (IAP). But such an approach can hurt gameplay and feel exploitative — see Ben Kuchera’s article on the IAP for Final Fantasy: All The Bravest (FF:ATB) for an example of what not to do — and it’s very important to me that I avoid those pitfalls.

(To be clear, my problem with FF:ATB’s IAP isn’t the slot machine-style character purchasing — choosing not to purchase those characters doesn’t really hurt the core game. In contrast, the game’s Hourglass mechanic, where when your party loses you either need to wait an hour or buy an IAP Hourglass to continue immediately. And since the game is a paid app, this really rubs me the wrong way.)

My game will be a paid app, and for its IAP I have 3 guidelines:

  • IAP should not directly affect core gameplay
  • IAP should not feel exploitative (to reasonable people; I understand that some may consider any IAP to be exploitative)
  • IAP should still be worthwhile enough that some players will want to buy it

In line with those guidelines, my plan is for the IAP to affect only the meta-game, not gameplay itself. Without going into specifics about Project Smart Birds, the best way to describe my intent is with an analogy. Let’s pretend that Animal Crossing was a paid (not free) iOS game with IAP. Further, let’s narrow our focus to the game’s fishing gameplay, which is pretty simple: buy a rod, go to the water, play a timing-based mini-game to catch fish, and later sell them at the shop for Bells (the Animal Crossing currency).

If Square-Enix was making IAP for Animal Crossing fishing, given what they did for FF:ATB, it might go like this:

If a fish gets away, your rod has an 15% chance of breaking. If your rod breaks, either A) wait an hour to receive a replacement rod for free, or B) buy an IAP rod to continue fishing immediately.

For a paid app I find that appalling, so in contrast, my approach would be something like this:

If you want to make more Bells from fishing, you can buy an IAP Fishing Badge. When you activate the badge, all fish you catch on that same calendar day will be worth twice as many Bells.

Sure, both approaches give a benefit to IAP buyers, but I think that my approach is a compromise that is worthwhile but doesn’t hurt the game for the players who choose not to buy the IAP. Luckily, since Project Smart Birds is still early in development, there’s still time to revise the design if I find a better fit. But for now, I’m pretty happy with this idea.

Hello world!

Welcome to my blog! I’ll use it to post news and interesting info about my indie video game development, as well as other thoughts and musings. I hope you find it worth reading.

To kick things off, here’s the info from the blog’s original About page. Of course, the About page will be revised as time goes on, but this will stay here for history and posterity.


Who am I?

I’m Andrew P. Bilyk (pronounced BILL-ick), a video game developer. I live in Springfield, MO with my lovely wife Camille and our two cats.

I wanted to make video games since I was 9 years old. I got a computer science degree from Missouri State University, and shortly after college I formed a tiny game development company, Dungeon Monkey Studios, with my friend Doug Hill. Within a year, our company was acquired by Black Lantern Studios, and we began working there.

I worked at Black Lantern for 7.5+ years, in programming, production, and design roles. I was credited on 52 released games — mostly licensed kids games, across a wide variety of genres. But this past November (2012), I was terminated as a result of a company restructuring.

I want to continue making games professionally, and I also want to continue living in Springfield, MO. But game development here is sparse, and there aren’t any job openings right now. The only option that would allow me to continue making games here in Springfield is independent development. I know that the odds of financial success are low, but I’m going to give it a shot anyway.

Though I am continuing to look for work in case something pops up, in the meantime I’m developing a small game for iOS, which I plan to release on the App Store this Spring (2013). If it turns out to be successful, then I can continue indie development. But if it fails, then I’ll have to move on and expand my job search — to another field, another city, or both.


My Projects

Project Smart Birds

The “small game for iOS” mentioned above. It’s not an Angry Birds ripoff, I promise — that’s just a code name. I’m keeping the details close to my chest for now, but I can say that it’s a Popcap-style puzzle game that I believe will have a wide appeal. If the iOS version is successful, I will port it to Android, PC, Mac, and perhaps other platforms too.

Captain Dynamite and the Fallen Hero / Invisible Games

Captain Dynamite and the Fallen Hero is an audio-only rhythm game, and Invisible Games is my development label for audio games. The game is similar to classic rhythm games like Space Channel 5 and Parappa the Rapper, but there are no visual cues, only audio. It’s essentially a radio drama (audio movie) about heroes and villains, with rhythm gameplay during the action scenes.

I worked on this as a side project separate from Black Lantern, alongside some very talented collaborators including composer Chad Seiter. We created the first quarter of the game in late 2010 and submitted it to several indie game competitions, and in 2011 I released a playable Windows PC demo to the public. But nothing came from those competition submissions, and I’ve dragged my feet on development since then. I do intend for us to finish it eventually, but I feel that right now my time is better spent on Project Smart Birds, which I believe has a greater chance of financial success.