A Year of Failed Prototypes

It’s been over six months since I released my last game, and almost that long since I’ve updated this blog.

I’ve been busy with non-gamedev stuff, but I’ve also been hacking away in my spare time. Unfortunately, most of these projects haven’t really gone anywhere. So I decided to go through the ones that had some promise, record a brief demo video, and upload the code to GitHub.

One of the hardest things for anyone who does creative work as a hobby is finding the balance between quality and getting stuff done. For most of these prototypes, I didn’t they were good enough to keep working on them. So I let them digitally rot in some deep folder of my hard drive. Thing is – there’s some good stuff buried in there. By going through and at least getting the projects into a shape to share the code, maybe someone else can take away something useful. Plus – it makes me feel slightly more productive.

And who knows – sharing these prototypes may kickstart enough motivation to turn them into full-fledged games.

Open Ocean Test

Source: https://github.com/tdonlan/OpenOceanTest

This is a prototype built in XNA to simulate an open world ocean. You swim a submarine through the ocean, underwater passages and lots of different fish. The terrain is generated using similar algorithms used to generate the Platform Hack tile maps. Some of the fish (flocking) move with similar algorithms to some of the germs in NanoDoc. I also put together some code for skeletal-based movement, and was going to have the larger fish (whales, sharks, big squids, seaweed) move that way instead of sprite sheet animation.


  • How the divide the sea from the air? I could never find a surface that looked good. Right now I’m just using a fat line tracing an oscillating sine curve. But if I ever used any sort of texturing on for the waves, it looked pretty bad.
  • How to handle all the fish + terrain? Running collision on all the fish would have been too slow. And I was just spawning various fish at different depths, not checking if they were in water or in rock first. One solution was to just have fish get repelled by the thickest rocks until they were in the ocean, but this led to strange bugs. The other issue was when to save the state of the world? If the world gets large enough, you can’t store it in memory effectively, so you have to come up with some sort of “chunking” algorithm for the world, which can be a lot of overhead to program.
  • How to make a game out of it? I thought the game would be mostly a sandbox with some loose missions and some upgrade trees for various tools on the subs: harpoon guns, engines, fishing rods, manipulator arm. Maybe even a flashlight. Missions could be something like: find this exotic fish in this section of the map. Catch a 500 lb marlin! Pull up the treasure from the sunken Pirate ship! Fun stuff, but a good bit of overhead to implement (questing system, mini-map, etc)

Fishing Test

Source: https://github.com/tdonlan/FishingTest

This prototype was partially inspired by a tweet for a fishing game jam, playing Ridiculous Fishing, and also fond memories of fishing minigames in videogames of yore (Ocarina of Time). I wanted to find a gameplay mechanic that mimicked the gentle tug and pull of real fishing – finding a balance between reeling in a fish and having the line break.

Anyway, the core mechanic is basic math, but the most technical part of the demo is the physics of the fishing line. This was actually done using Farseer Physics rope joints.


  • Getting the mechanics to feel just right. The fishing line feels a bit too floaty. And the fishing minigame feels a bit too random – like the player doesn’t have enough control reeling it in. Once both of those variables are adjusted, I think it could be a pretty fun prototype.


Source: https://github.com/tdonlan/JSRPG

This is a rough RPG built in JavaScript. It was actually created to try to build a RPG plugin for Twine games. I wanted to create a nice framework for building gamebooks (like Lone Wolf), where you could read through a choose-your-own-adventure style text game, but also handle battles and inventory. The pure RPG battle stuff ended up working ok in JavaScript, but the Twine integration was a nightmare (worthy of a separate post).

This demo is just the standalone JavaScript RPG functionality. Most everything is data-driven, so you can customize the game however you like, using JSON and CSV files.


  • Building complex logic with JavaScript: Things like – I want an item to grant an ability – which would be trivial in a strongly-typed compiled language, are pretty frustrating to build in JavaScript. Since there are no real enums, you have a ton of code to check for different strings, which can get cumbersome.
  • Display Loop: Right now the battle loop does the logic, then just recalculates all the HTML and updates the div. Ideally, there would be a way to separate it into some sort of MVC pattern, where the logic and data of the RPG was broken up a bit better from the display. Right now it’s a tightly coupled mess.
  • Everything in the browser: all the problems with doing stuff in the browser – how to save state (to disk or server), how to prevent cheating (you can’t). At the very least, I think I proved to myself that using Twine + JavaScript to make a Lone Wolf gamebook system isn’t really feasible (at least for someone with my level of skill + patience). I’m thinking Client + Server or iOS App would work much better.

SpaceTest Asteroid Clone

Source: https://github.com/tdonlan/SpaceGameTest

This is an iOS game built using Cocos2D. I had this idea to do an asteroids game where you could destroy asteroids and enemy ships, collect minerals, level up your ship, etc. Right now the prototype has the flying around part working pretty well – it feels a lot like the classic game of asteroids. It’s using touch screen controls to steer and shoot.


  • Does this game belong on iOS? I think my original intentions were larger than the limited screen real estate of an iPhone. The touch controls felt a little sluggish, especially the precision required for shooting and flying a spaceship through asteroid belts.
  • Parallax backgrounds in Cocos2d – there’s a built-in parallax functionality, but it’s not infinitely scrolling in 2 directions. I ended up hacking together a system to draw a background starfield and have it scroll as a function of the player’s movement. But it never felt very smooth. One of the biggest frustrations I’ve had with Cocos2D is finding a middle ground between using CCSprite to draw a static sprite object, and using low level OpenGL calls to draw lines and other primitives. Makes me miss XNA Spritebatch…
  • Realistically, I could grind on this game for a few months, find some decent art, and have something publishable on the App Store. Unfortunatly, my ADD kicked in and I was off to the races on something else. We’ll see if I pick it up again.

iOS, Cocos-2D and Heartline PostMortem

My game Heartline came out a few weeks ago.  Here’s a breakdown of how it was built, challenges, and what I learned.

Mac and iOS

I wanted to get into iOS development late last year, so I bought a Mac Mini around Christmas.  After learning the ropes of the new OS, the thing felt a little sluggish, so I dropped another 50 bucks and added some RAM.

XCode and Objective-C took a little while to get the hang of.  At first I was turned off by the incredibly verbose method calls.  Calling methods with block syntax felt ugly.  Memory management was strange as well (when to use init vs alloc?  what attributes for properties?)  But going through a few tutorials, and just spending time in the environment, I was able to manage.  I’m still not a pro at all the nuances of objective-C, but I can get done what needs to get done, and that’s the important thing.



I decided to go with Cocos2D once I did some research and found that most dev tools for iOS App development came with a cost.  Unity, Corona, MonoTouch – all were pretty pricey to release an app.  Cocos2D was free, open source, and had a really good community.

Biggest differences from XNA:

No game loop! 

There’s probably some sort of game loop going on under the hood, but I wasn’t able to access it via Update Methods, like you do in XNA.  I think the tutorial method of managing objects in Cocos2D is to queue up actions and let the framework handle the movement/collision.  But that wasn’t fine-tuned enough for me.  And besides, I learned to make games with a game loop.  Thankfully, you can add a gameloop manually using a scheduler.

Everything is a game object

The other big challenge was that every Cocos2D object was a game object.  If you inherit from CCNode, you have a position, and can draw on the screen.  But stuff also has to be added (and removed) from scenes to be “in” the game world.

Scene system

One advantage of Cocos2D over XNA is the built-in screen system, using Scenes and Layers.  Scenes are added to a Director.  Layers contain all the game objects.  So you can easily have a Pause Menu pop up in a few lines of code, without having to worry about managing the state.  Even better, there’s a menu system, with the ability to layout buttons in grids or lists.


Drawing is a little different in Cocos2D and iOS.  Spritebatch in XNA is pretty powerful – you can use it to scale and rotate textures, and even draw primitives (out of 1 pixel textures).  In Cocos2D, the draw method of a game object pretty much just draws the texture at the position.  If you want to get fancy (transparencies, primitives) you have to start using low level OpenGL calls, which can get tricky and feels like a bit of a hack.  Drawing a straight line requires a bunch of calls, setting different rendering modes and stuff.

Color objects are also a pain in Cocos2D.  Instead of single Color object like in XNA, there are 3 or 4 different Color structs, using different data types.  Depending on the function, you have to convert between them, which leads to verbose and inelegant code.  Alpha blending isn’t as versatile as spritebatch either.

Overall though, I’m very happy with Cocos2D and will be making some more games with the framework.

Ray Wenderlich

Ray’s blog has the best tutorials for building iOS apps, not only because he goes in such great detail and walks through the code, but includes standalone applications you can download, run and reference.  Best tips were on how to build a Save Game singleton, and info on in-app purchases.

In-App Purchases

These were annoying for two reasons – setting up the metadata in iTunes Connect and testing it through the sandbox, and then the technical challenges of implementing the API.  At first I tried to do it from scratch, using a Wenderlich tutorial.  Built a delegate class, used the notification center waiting for asynch responses from the store, was able to purchase to unlock game features.  But the entire thing felt very messy and tightly coupled with my game code.  And during testing, the sandbox was notoriously slow, so if I hit the buy button a few times, I’d get spammed minutes later with Purchase popups on my iPhone.  I ended up submitted with this first version of the code, but it failed because I didn’t include a “Restore Purchases” button.  Not sure if a bug would have been found, but I decided to implement MKStoreKit.

MKStoreKit abstracts all the in-app purchase stuff into a nice package, and wiring it up into an application only takes half an hour. The biggest step is converting the app to ARC, which is required for MKStoreKIt.  For Heartline, I ended up only converting the MKStoreKit code to use ARC, since the rest of the game, and Cocos2D was written without ARC.  Your mileage may vary.

Testing with TestFlight


I wanted to beta test my game, so I decided to use TestFlight.  Once you make an account, you can upload a binary of the game, enable test users to access it, and even get feedback from an API (crashes, checkpoints, etc).  Building the binary was pretty straightforward, but setting up the various provisioning profiles was tricky.  Note: the provisioning profile must match the bundle ID exactly (case-sensitive!)

The only other frustrating thing about TestFlight was that once friends and testers signed up, I had to get the ID of their device, and manually copy this into the provisioning profile, then send out an updated binary.  You’re limited to only 100 devices, so if you ever wanted to do a massive beta test, you’re out of luck (unless you get an enterprise iTunes developer account or something)

iTunesConnect and Release


Once the game was complete, releasing it on the store was pretty easy.  It’s a minor annoyance that you need screenshots for both iPhone 4 and iPhone 5, since they have different dimensions.  The actual review process was quick and clear.  When a problem came up with my first build (missing the Restore Purchases button), the status of my app changed and I was sent an email with the problem.  I was able to get a new build up there in a few days, and within a week it was approved.  Much better than the XBLIG lockout period and peer review.

The tools to monitor sales are also very nice, with charts and breakdowns by the day/month/year.  Of course, the app store is flooded with small little games, and since my app wasn’t really promoted, downloads dropped to almost nothing after the initial release.

But overall I’m pretty happy with the experience of building and releasing a game on iOS.

My next goals are to build some more advanced games using what I’ve learned with Cocos2D.  I’m not sure the in-app purchase model is the way to go.  It seems like you only cross a threshold of profitability if your game is very popular.  But it’s a good reminder: I’m not in this for the money 😉

Some New Games!

I recently released three small games. Heartline – for iOS, The Party – web/TWINE, and Starvin Stu’s Spud Farm – my LD48 XNA game.

The Party
The Party
Starvin Stu’s Spud Farm

All three games are free, so check them out!

I’ll be doing postmortems on each of these games and their respective tech stacks. Lots of fun stuff learned in the process.

New Year, New Plans

It’s already halfway through February, but I’ve been kicking the tires behind the scenes.

This is a big transition year for Daydalus Studio. I think it’s safe to say that I’m leaving Xbox Live Indie Games behind for good. XNA itself is officially dead, but I love the API enough to stick with it for a few more games (utilizing MonoGame). I’m also going to be putting out a few games on iOS. Here are some brief overviews of what I’m working and hope to release this year!

1 or 2 quick iOS action/puzzle games – I’m using Cocos2D, which is almost nicer than XNA in some regards (built in support for primitives, animation, basic collision). However, ObjectiveC and the iOS stack is a somewhat frustrating to work with, so I doubt my iOS games will be as complex as my XBox Live games. The goal is a quick little action / puzzle game that uses minimalist art (shapes, colors) and is released as free to play. I may sell bonus levels for a dollar.

ios2 ios1

“Open World” Ocean Game – I’ve had a prototype running of this since I worked on flocking for NanoDoc. It’s a lot of fun to see colorful fish “flock” in schools. This game would be somewhat of a sandbox, where you could explore, fish and buy upgrades. It would be built in XNA / MonoGame and released on PC via Desura / Steam.


Thief in the Night – This is the big idea I’ve been churning in my head for years now. Stealth mechanics are all the rage these days, and I’ve always loved stealth games. This game would have a top-down world, line-of-sight stealth, lockpicking and pickpocketing minigames. And on top of that would be a dynamic story with dialog trees and mini-quests. It wouldn’t be a full RPG with stats, but you’d be able to craft better gear. I have some promising tech demos for this now (2D shadows using Krypton, Pickpocketing with Farseer physics, etc) now to pull it all together into an alpha.

Stealth1 Stealth2

Platform Hack 2 – I’d like to go back and do Platform Hack right, the way I originally intended. A full metroidvania world (connected levels where you backtrack), with procedurally generated stages. I’d probably use all the same assets. I’d give the player a bit more control (infinite wall jumps, etc) to prevent getting stuck. The frustration of super-high hitpoint enemies and the deadly grappling hook would be revised.


Stay tuned for more news on these projects!