The Animal Farm

August 8th, 2010

See the Light Android Sales Update

It’s time for everyone’s favorite foray into small numbers:

Trials - 1556
Sales - 25
Total Profit - I don’t wanna think about it

Man: Are you Abe “The Rail Splitter” Lincoln?
Abe: Used to be. These days they call me Mr. President.

June 27th, 2010

Designing an XNA Art Build System

If your project’s artists have to open Visual Studio to work, you’ve failed them. If they have to come to you to get every piece of art implemented, you’ve failed them worse.

The primary driving motivator behind every engineering decision I’ve made for Iron Heinrich is thus: I want to allow the artist (Nate) to do awesome things. Each barrier in his way is a high priority for me.

There are plenty of barriers, and we’re working on addressing a lot of them. The purpose of this post in particular is the art build system. The system set in place so that when an artist does something, after he’s modified the data, he can see everything running.

The Goals
The current XNA content workflow is pretty much the following:
(1) Start Visual Studio
(2) Add your content to the Content project
(3) Set any necessary importers or content processors
(4) Build and wonder why you got all those errors
(5) Fix up those errors
(6) Build and run

Which isn’t particularly good for an artist. It’s cumbersome. It’s error-pone. It requires technical knowledge. Here’s the ideal:
(1) Build and run.

A lofty goal, but can it be done? It’s not entirely trivial, but I do believe it can.

Changing the Art Build Step
The first thing we need to do is take Visual Studio out of the equation. Artists shouldn’t need to know about IDEs or content projects or importers. Artists should be able to double-click on a file and watch it go. This is an art build step, and a good art build step hides all the ugly details from the artist.

How is this done with XNA? Here’s an outline of the current process we’re using now:
(1) The Content directory is crawled by a program. Each file is evaluated against an Art Manifest which details how that file should get built. The artist doesn’t need to know about the Art Manifest.

(2) Based on the above, a new Content project file gets generated that the XNA build system can interpret. This file is actually a mashup of a Template file (which contains all the standard stuff that goes in a Content project) and the new data determined by the crawler/manifest.

(3) msbuild is run on the new Content project, which performs the necessary art build.

All this is fairly simple. The trick is in the details - the details specified by the Art Manifest.

The Art Manifest
Each type of file has a few things associated with it:
(1) An importer & exporter
(2) An asset name
(3) Various parameters

It’s not enough to specify these once per file type and be done with it. That would lead to a broken build within minutes. Consider:

Level1.x is a level file. It uses an exporter that spits out its vertices for collision purposes.
Char1.x is a character. It uses an exporter that spits out a skeleton for animation.

The same “type” of file, but they meet radically different requirements. The art system has to manage that.

The Iron Heinrich build system specifies a hierarchy, where each part of the hierarchy takes precedence over the previous:
(1) Default (Per File Type) - If a file of this type is encountered, this is how it will be built by default

(2) Group (Per Directory) - Build information can be set at the directory level such that if a file is in the directory, the ‘Default’ no longer applies. For instance, all levels may go in a group “Levels” and will be built specially.

(3) Override (Per File) - Specific files have specific requirements regardless of where they are.

(4) Ignore (Per File) - Sometimes you just don’t want a file in the Content directory to get built. For example, we definitely want the crawler to ignore Content.contentproj.

I as a programmer handle that - I setup the manifest, specify the importers, exporters, etc, and the artist almost never has to worry about it. Sometimes he may need to add something to the Ignore list or even the Override list, but 99% of the time he just puts his assets in place, executes a script, and runs the program.

Final Thoughts
The system isn’t perfect. Some errors will still require some technical knowledge, and the manifest is more cumbersome to make small changes to than settings within Visual Studio. Comparatively, though, I think it allows for a much smoother workflow, which is vital to artists.

This is all overkill for small projects, but for larger projects (and especially projects which are largely data driven), it can be pretty helpful. It also sets up the framework for a rapid iteration scheme which I’ll talk about… if/when I ever implement it.

Not nearly as complex as some of the build systems I’ve worked with.

June 21st, 2010

The Next Android Project: Dungeon Kid

See the Light has wrapped up, and although it will definitely receive updates (1.5 support and a Spanish translation are in the pipeline), I’m moving onto my next project: Dungeon Kid.

Only a handful of people are familiar with Dungeon Kid. Back in my college days, I was tasked with creating a small, charming dungeon crawler for the (Nokia?) t300 and t610 series phones using the Mophun SDK. It was a humble game - the t300 version supported a wopping 101 x 80 resolution - but it was complete.

Complete as it was, it never saw daylight. The Mophun platform was rubbish, and the gatekeepers kept claiming a bug which for the life of me I could never reproduce. After weeks of trying, we finally folded and shelved the project. Which is kinda OK, since even then cell-phone games weren’t making a lot of money. It’s the fate of that market to be constantly saturated by rubbish, but that’s another post.

Fast forward to now, and despite my cynicism, I’m back on cell-phone games part time. I needed a new project; something fresh. But I was concerned about the art requirements. As I’ve stated, the only interested artists I know is already over tasked. But in Dungeon Kid I have a game that only maybe 5 others have seen, and all the content is already done. The workload isn’t trivial, but it isn’t gigantic. And I have plenty of Android knowledge/code carrying directly over from the last project.

So I’ve started.

Thus far, the random dungeon generator is working. Still a few kinks, but it’s working. I don’t have a timeline for this game - the Big XNA game takes priority - but knee-jerk guesses place it between 1.5-2 months. When I’m not feeling so lazy, I’ll grab some of the assets and throw them up.

It’s late. Do I have another blog post in me?

June 20th, 2010

Coding Horror

Digging through some (very old) source code, I found this little gem:

//Place corners and walls depending on the pattern of walls around this wall
if ( !wall[0][0] && !wall[1][0] && !wall[2][0] && !wall[0][1] && !wall[2][1] && !wall[0][2] && !wall[1][2] && wall[2][2])
setActualTile(actualmap, amx, amy, amw, 1, 2, 11, 12);
else if ( !wall[0][0] && !wall[1][0] && wall[2][0] && !wall[0][1] && !wall[2][1] && !wall[0][2] && !wall[1][2] && !wall[2][2])
setActualTile(actualmap, amx, amy, amw, 81, 82, 91, 92);
else if ( !wall[0][0] && !wall[1][0] && !wall[2][0] && !wall[0][1] && !wall[2][1] && wall[0][2] && !wall[1][2] && !wall[2][2])
setActualTile(actualmap, amx, amy, amw, 9, 10, 19, 20);
else if ( wall[0][0] && !wall[1][0] && !wall[2][0] && !wall[0][1] && !wall[2][1] && !wall[0][2] && !wall[1][2] && !wall[2][2])
setActualTile(actualmap, amx, amy, amw, 89, 90, 99, 100);
else if ( wall[0][0] && wall[1][0] && wall[0][1] && !wall[2][1] && !wall[1][2] && !wall[2][2])
setActualTile(actualmap, amx, amy, amw, 1, 2, 11, 12);
else if ( wall[1][0] && wall[2][0] && !wall[0][1] && wall[2][1] && !wall[0][2] && !wall[1][2])
setActualTile(actualmap, amx, amy, amw, 9, 10, 19, 20);
else if ( !wall[1][0] && !wall[2][0] && wall[0][1] && !wall[2][1] && wall[0][2] && wall[1][2])
setActualTile(actualmap, amx, amy, amw, 81, 82, 91, 92);
else if ( !wall[0][0] && !wall[1][0] && !wall[0][1] && wall[2][1] && wall[1][2] && wall[2][2])
setActualTile(actualmap, amx, amy, amw, 89, 90, 99, 100);

How on earth did I ever write this?

June 20th, 2010

See the Light is OUT!

The Android edition of See the Light was released late last night. There’s a paid version and a free version for the cheaper among you. If you have an Android phone, go check it out!

Unfortunately, I can’t find a way to link to an Android app, so you’ll just have find it the hard way.

Super special thanks to Ricky. I don’t think he knew what he was getting into when he casually offered to try the game out, but he went above and beyond with his testing. Were it not for him, the game would’ve likely been a buggy mess.

I’m sorry, but the display issue is still there…

June 11th, 2010

PAC-Match In Review

PAC-Match gets a good review!

The Gamezebo review gave it 4/5 stars. “Much to our surprise and delight, Pac-Match Party brings a number of new twists to the genre that help it hold its own against the competition.”

I haven’t been able to scrounge together other reviews. Unfortunately, running a search gets me a lot of reviews for a different game named PAC-Match. I did, however, stumble upon a forum post where people seem to be enjoying it. Quotes:

right now, I’m in level 21 and I have to admit, it’s my new favorite match-3 game. It’s just perfectly executed. Controls are perfect. There are a lot of cool power-ups, the music and sounds are fantastic (old themes in a wonderful chilly mood). I was expecting half the game I got now. Really, really love it. Highly entertaining. ”
–your personal robot

“This is the most fun i’ve had with a match 3 game. The next closest would probably be azkend. This is a blast, and the price point is perfect. They didn’t gouge on the big name for once. Highly recommended. ”

There are, as with any forum, some negative words in there (and some fair critiques), but… who wants to mention those?

Will reference more reviews as I find them.

Hope you’re enjoying the game.

March 14th, 2010

Word Duelist Sales Update

The short version: I won’t be quitting my job any time soon to make XBLIG games full time.

The game is selling nearly identically to See the Light (read: low). It has a decent conversion ratio (7%) but an abysmally low number of trials (around 800 so far). And this is while it’s on the New Arrivals section - once it leaves that, I expect trials will drop sharply.

I have no clue how to drive people over to the game. I did a marketing blitz, but that had to wait until after the game was released since I wasn’t sure when it would come out, and so none of the reviews are up yet. There are trailers and promo videos, but their views are limited by the number of people viewing the sites they’re on.

I think one mechanism to employ is to start blogging about a game early and often, getting the blog as much exposure as possible so that people know something is out there and have incentive to keep up with it. It’s a strategy I’m going to try employing with my next projects.

As an aside, this site gets nearly 200 hits per week. Which isn’t big by any standard but is a fair bit larger than what it was a year ago. Which makes me curious who’s seeing this site and where they’re coming from.

I can keep rhythm with no metronome.

January 24th, 2010

Word Duelist Back in Review

The seven day jail has elapsed, and as far as I can tell Word Duelist is bug free - it’s been tested and retested and has had other sets of eyes on it. So it’s back in Review. The list is short this time around, so hopefully it won’t take a full two weeks like both my previous experiences, but who knows.

As for the next project: I’m hoping to make an announcement soon. Its release is still well off (and to be quite honest, uncertain), but there’s been enough progress on it that a pretty teaser screenshot might be coming your way in the next couple weeks.

All they want to do is talk about words and word-related things. Dictionaries and stuff.

December 22nd, 2009

See the Light: Buy It


My game on Xbox Live Indie Games. Available right now.

Get it. Rate it (highly). Tell your friends.

November 30th, 2009

Game Polish 4: Fonts

Anyone familiar with XNA games knows Kootenay. It’s the default sprite font, and it’s widespread. And it’s ugly and overused.

I know nothing about font selection. I’m not a multimedia designer, I don’t make web pages or advertisements for a living. I wouldn’t be able to tell Times New Roman from Arial by sight. So obviously I’m ill prepared to talk about how to pick a good font. Find someone else to ask or guess wildly like I do.

I can, however, point to a few places to find fonts. urbanfonts is my first point of contact. It has a lot of free stuff and not horrible search capacity. dafont is also a site I look to. And there’s FontSpace.

Of course, there’s one thing you have to be very careful of when using a font: fonts are subject to copyright like anything else. Many of the fonts you’ll find are marked for personal use only. Some don’t even come with a license, and those are the ones I immediately delete to stay safe. It’s important to read those notices and not just trust that a site claiming free fonts actually has free free fonts.

Free as in beer or free as in speech?