Jul 17


Welcome to our blog! We’ll be detailing our adventures in developing our first indie game right here!

Please feel free to leave comments or ask questions. We’d love to hear from you!

Jul 29

The genesis of an idea

What is the hardest part of game development? Probably the very beginning: the idea. Coming up with a great idea for a game is often impossibly difficult. It’s gotta be something that’s unique, fun, achievable, marketable, and probably several other adjectives. The sad truth is that even this very beginning part can take months or longer just to find.

Personally, I have pages upon pages in notebooks strewn everywhere of ideas for complete games, individual mechanics, character names, etc. I even have a font ready to use when the right game idea comes along. Even with all of this, it’s still incredibly tricky to piece it together into a cohesive whole.

Luckily, for this game, we were handed the idea on a silver platter. A fellow veteran game programmer and good friend, Dave LeCompte, has been working diligently on his new year’s resolution, which is to create one web game per month for the whole year. One of these games was an interesting puzzle game using dominoes. Once he had finished his month’s work and showed me the result, I was immediately enamored. The game was different and very engaging, but not overly difficult or complex. Just the right mix for potential success!

I told him that this game could be really great on mobile devices and he said “Go for it!” And so I did.

Aug 05

What’s in a name?

One important item we wanted to nail down immediately was what the name of the game would be. Did we want it to say something about dominoes or puzzles? Should it be funny or serious? How long is too long? Would people remember it, and would they be able to find it easily in a search?

We began to compile a list of possibilities, with help from some friends and family (thanks to Katie and Sadie!). A great many ideas appeared and we began to evaluate their promise. We decided that we didn’t want “domino” to be in the title because even though the game uses dominoes, it’s more about the puzzles and less about the dominoes themselves. There are also lots and lots of versions of the traditional game of dominoes in the app stores, which we didn’t want to obscure our title. The name also had to be something catchy and memorable.

Ultimately, we went with a name that would help inform our character design, and also ended up being a bit of a play on words with our domino subject. If you happen to remember from your high school English class (or even if you don’t), there was a mythological king named Minos who built the labyrinth which housed the Minotaur. As soon as we remembered that, it was natural that our game’s representative would be a minotaur who was slightly different from his maze-loving brethren in that his game of choice was, of course, dominoes. His name would be: Odd Minos.


Aug 12

Nuts and bolts

As the primary programmer on this title, it was up to me to decide on what tech to use to create it. I didn’t take very long at all to make the decision to go with Unity. Why’s Unity so great, you ask? Well, I’ll tell you. It’s easily downloadable, full-featured, multi-platform, and well-supported by a strong community of users. It’s also the software I’d been using with great success for the past 2 years.

Probably the best thing about Unity is how easy it is to get something up and running with it. I’ve been able to get all of the basic mechanisms of the game ported over from the web app in just a few days.

We also decided that eliminating production obstacles early would streamline the development process and help us reach our goals in a timely manner. To that end, we’ve decided to release on Android first, and then iPhone once the first release was set. The main reason we chose Android, even though it has a smaller user base, is that it’s simpler to publish with Google. We hope that will mean a less complicated, and thus more successful, launch.

Aug 19


One of the difficulties of being a small indie developer is not having all of the talent you need in-house to accomplish everything required for the game. When those things arise, it usually means either getting really creative with some aspects (and by creative, I mean slip-shod, half-assed, and ugly as sin) or hiring someone on a contract to help with what’s missing.

When faced with the need for a minotaur character design and some animations, we had to find someone with the artistic chops to handle it. There are lots of websites out there which bring freelancers together with employers, but the one we chose was guru.com. Guru has a lot of tools that make it easy to securely hire someone and have a high degree of confidence that you won’t get ripped off via their escrow system.

After posting the project, we immediately got dozens of people sending offers. Many were unacceptable due to price, location (we wanted to stay in the US, partly for tax reasons), or just a general lack of understanding of what we wanted versus what they provided. (One guy offered to do less than half the listed work for more than 10x the estimated budget.)

Eventually, we found someone who both had a respectable portfolio and was proposing a reasonable price. He also was in the same time zone! Even with all of this supporting him, I still wasn’t sure what we were going to get from this process, but I hoped for the best. Luckily, the best is what we got and ended up with a fantastic experience! Our contractor was professional through and through. He communicated well and was very responsive to our feedback, listening well to our ideas and providing his own suggestions based on his artistic vantage. He also was very quick to make any changes requested and just generally a great person to work with. We hope that every future contractor we hire is just as fantastic!

In the next post, I’ll include some of that wonderful art we got!

Aug 26

The Process

Creating the perfect character isn’t a matter of just putting pen to paper and designing the perfect image right away; there are a lot of steps along the way, and many, many (so many!) revisions. We wanted several key features, including a big head on a little body and a manly, but cute, demeanor. Here’s a tiny slice of the back and forth between us and our artist contractor:


One of the initial concepts that turned out to be a little too clean-shaven for us.


After a few more revisions, we found a good starting point.


Here’s the colorized version, but that head might be a little too big.


The final character, being as casual as possible.


As you can see, there’s a lot of iteration that happens, and that’s just for one piece of art!

Sep 03

Feature: Puzzles

Ok, so I’m a big puzzle design nerd and in recent years there have been a few that have simply astounded me. They’ve been so great that my perception of the genre has been forever altered. Some of my favorite choices for this pure and unadulterated design perfection are: Portal (1 & 2), Limbo, and Braid. These games contained puzzles so exceptional, they made puzzle creation look easy. Truth be told, it’s anything but. Well, let me rephrase: making overly simple or horrible, disgusting, and frustrating puzzles is easy. Making great puzzles that people celebrate requires a handful of components in just the right amounts, like making a cake! Delicious, delicious cake.


It’s surprising to me how many people seem to equate easy with fun in games. They often complain how games should be easier so they’re more fun to play. I, however, argue that easy is boring. While it might keep your attention for a bit and prevent you from whining, very quickly you’ll get bored and move on to something else. What people really want is an appropriate level of challenge. Something that doesn’t let them steamroll the content, but that also doesn’t lead to frustration (which is often the point when people quit). This varies from person to person and as such becomes a very delicate balance to appeal to the largest number of people possible.

In addition, as people experience something, they learn the little tricks that make it easier the next time around. This means that there needs to be a steady, but gentle, increase in difficulty as the game goes on so that players have a consistent progression of challenge throughout. It sometimes seems simple to just add more components as the difficulty progresses, but this method has potential drawbacks as well. Adding pieces might not be an option because of screen space requirements or perhaps the number of pieces available is finite. Too many moving parts could produce results that are overly complicated. It’s also possible that adding more stuff to a working puzzle will actually end up making things easier.


Some puzzle games are blessed by having randomly generated levels, but most are not. They have dozens upon dozens of levels, each of which must be meticulously designed by someone. On top of just having to make lots and lots of them, the designers must create levels that are different enough from each other to keep the player engaged. Nowadays, it’s harder than ever to keep people’s attention. With so many thousands of other games clamoring for face time, each and every level must be as unique and compelling as possible.


A lot of novice designers think that if a puzzle CAN be solved, then it’s good to go. What they don’t take into account is HOW the puzzle must be solved. For most good puzzles, there’s a path of discovery where the player slowly pieces things together in a fairly steady way until they solve the whole thing. Good puzzles provide a subtle guidance to allow the player to gradually figure things out. When games deviate from this (usually through ignorance or neglect) and have puzzles that require superhuman leaps of logic, it often leads to frustration (and possibly a great comic book).


Luckily, for this game, we had some good tools to help take care of a few of these issues.

One of the nice things about our game is that it’s pretty easy to test the solvability of the puzzles programmatically. Before diving into writing my own solver, I did some research to see what else was out there. I found numerous implementations for solving sudoku puzzles which were pretty nice. None of them fit my needs, however, because they were optimized to find just one solution. What I needed was something that could find ALL solutions for a given puzzle. As unfortunate as it sounds, the best algorithm turned out to be the brute force one. Granted, there were lots of opportunities for early-outs to boost the efficiency, but when you need to search the whole space, well you gotta search the whole space.

Finding every solution gave us the ability to tweak puzzles that had too many solutions and would thus be too easy. It also gave us a very nice surprise: difficulty evaluation.

We noticed that there was a strong correlation between the time the solver took on a puzzle and the time a human took. This allowed us to use the solver’s times as a rough guide for the difficulty of any given puzzle. Automating that process saved us countless hours of organizing the level layouts by removing the tedious chore of finding new people to evaluate the designs.

If you’re making a puzzle game, keep these ideas in mind to help guide your process. Also, politely demand that your programmers give you tools to evaluate your designs.

(Sorry for saying “puzzle” so much. Synonyms are hard.)