The blog of Matthijs Hollemans, indie app maker and author of The iOS Apprentice

After a good start in January, I have to admit that not much has come of my plan to push out one new game each month. Shame on me!

February: I started work on a clone of Defender of the Crown (an Amiga classic), or at least the strategy portion of it. Alas, I got no further than the very basics:

The goal is to conquer all enemy territories by sending out your campaign army. You only have one army and you don’t know where the enemy armies are.

As far as strategy games go, this one is pretty simple. But as I’ve never made a turn-based strategy game before, starting with something simple won’t hurt. I do want to revisit this game at some point because I like the idea.

March: No work on a #1GAM game but I did give a 15-minute “blitz talk” at NSConference, which was really cool to do. The topic: why making 12 games in 12 months is a good idea.

My argument was that doing a challenge such as One Game a Month is good for learning to finish projects instead of just starting and abandoning them a week later. In addition, imposing constraints on yourself – such as an extreme time limit — help you become more creative.

If you’re into iOS development you should really buy the NSConference videos, they are great. And visit the conference next year!

April: I don’t know if this counts, but I did a remake of Juicy Breakout. This game is from a talk by Martin Jonasson and Petri Purho titled Juice It or Lose It. They show how to take a boring breakout game and make it really awesome, not by changing the gameplay but by adding tons of cascading animations and other effects.

The original game was done in Flash and their presentation isn’t really about the actual code, so I thought it would be cool to remake the game in Objective-C and Cocos2D for the iPad.

Pssst, here’s a little secret: I’m making a tutorial video out of this for RayWenderlich.com. Stay tuned for that.

About a week ago I signed up for One Game a Month, a challenge to make twelve games in 2013, roughly one per month. I already planned to release five new iPhone and iPad games on App Store in the first half of this year, so adding another seven isn’t such a big deal.

This is a screenshot of the game I made for January, Galaxy Apocalypse:

It’s a pretty simple game where you have to swipe planets into portals of the matching color before those portals run out of power and the whole galaxy explodes. You don’t want that to happen on your watch…

The game took five days to make from scratch to finish. If I had more time I would polish it more and put it on the App Store. In its current shape it’s not a bad game but still a bit below the level of what I think is good enough for the App Store, so I will clean up the source code (it’s quite messy right now) and put it on Github as a programming example.

Update: Here’s the code, github.com/hollance/GalaxyApocalypse

Here is a video of the game in action:

I have to say I like these sorts of challenges. I’ve done similar challenges in the past, such as composing at least one piece of piano music or coming up with at least one app idea each day for 30 days in a row. It’s a lot of work but it also pushes your creativity to higher levels.

When you limit yourself to making a game in a very short time, then by necessity you have to limit the scope of the game. Such constraints can be quite inspirational. How small can you make a game that is still interesting?

One of my most successful games, Ultimate Countdown (now removed from the App Store but coming back later this year in an all-new version), was done in a single weekend as a similar kind of challenge. It ended up being downloaded over 250,000 times, which I found quite impressive back in 2008, even for a free game.

So if you’re into game development — or if making games is something you’ve always dreamed of — then head on over to www.onegameamonth.com and sign up! Make games, not excuses.

The other day I received an email with the following question:

“I have this great idea for a game, but I’m new to iOS development and this goes way over my head. So I’m wondering if you could help with the development or know anyone else who can? Of course, we’ll split the profits.”

Since this isn’t the first time I’ve received such a request, I thought I’d put up my answer here.

It’s not easy getting started, that’s for sure. It can take a long time to go from noob to someone who can make quality apps. Also, not everyone is cut out to be a programmer.

Having a great idea is only the beginning, but the money is in the execution. If you don’t know how to execute, then you might need to take another approach to get the app made.

Even if you can pull off the programming part, that is not enough to make your app a success. You also need to get it to the right people, in the right place, at the right time. That also takes certain skills.

Sell your idea to find your team

Here’s what I would do: To find someone to work on this with you (for a part of the profits rather than work-for-hire), you’ll have to convince them of the potential of your idea. The best way to do that is to make a short demo video. Appsterdam’s Mike Lee wrote a good blog post about that.

With that video you can set up a project on Kickstarter or a similar site, that allows you to raise money from small-time investors and at the same time attract attention from developers and even potential customers. With that money you can hire a professional programmer, designer, and anyone else you need.

Let’s say you raise only $5,000. That by itself won’t be enough to pay for the development of the app, but it will serve as a decent down payment for the people you will hire. With some up-front cash and a convincing demo video, professional developers might be more willing to work for profit sharing.

In other words, if you don’t have the programming or design chops to make the app by yourself, you will have to play the role of a producer (like a movie producer) instead of a programmer, and gather a team of people who are willing to work with you.

Most of these people — if they are any good — aren’t interested in working for profit if you’re not also bringing something to the table. Asking someone to work on your project for a share of the (hypothetical) profits is asking them to invest their time and talent into your idea — and by extension, your leadership — at their expense, based on nothing but a promise of a fat payday. You’d better be ready to deliver on that promise!

But what if someone steals my idea?

You’re putting your great idea out there for the world to see in order to attract investors and talent, so what’s to stop others from simply copying it?

Here’s the thing: it is incredibly hard to make a hit game or app. If your idea is something anyone can build in a handful of days that is guaranteed to sell itself without any effort, then keep it to yourself. These are one in a million ideas and chances are yours isn’t one of them.

Your idea will take many months of dedicated effort to turn into something real and many more to find its way to customers. No one will steal it because no one else will care about it as much as you do or is willing to put in that kind of effort.

It’s not the idea that is worth money, it’s the execution of the idea. Most of the hit games on the App Store are not 100% original ideas — for example, Angry Birds and Tiny Wings are both based on other games — just very well executed versions of those existing ideas.

The idea isn’t really yours to keep

Now personally, I believe that you have to let go of the notion that you can “own” an idea. An idea by itself is nothing. That’s why you can’t really “steal” ideas. On the other hard, you can certainly own the execution of the idea, and that is protected by copyright laws and by the fact that’s it’s just a lot of hard work.

The only way you will ever profit from your idea, is to make sure you are the one with the best version of that idea.

If your idea is truly good but you put out a very basic, average implementation of the game that you programmed and designed yourself, chances are that hardly anyone will care about it. But it might inspire some other developer and a few months later some other team makes a lot of money from your idea but done better. You will have blown your opportunity.

So if you want to be the one with the hit app, you need to be the one making the most amazing version of it. And that requires programming help if you’re not a very good programmer, design help if you’re not a good designer, and marketing help if you’re not a very good business person.

So start working on that video!

Illustration by Oscar S.R. / miutopia (from openclipart.org)

On sites such as Elance, I often see job listings for games. Here is a tip if you’re considering having a game developed: first hire a developer to make a prototype to see if it’s worth investing in building the full game.

Let there be no mistake about it, making a game is a lot of hard work. There is a ton of design, programming, graphics, sound effects, music, testing, tweaking and polishing that needs to be done. It will take months. And the kicker is, you won’t know if the game is any fun until it’s nearly finished.

That’s a big gamble to take. If the game turns out not to be any fun, chances are it won’t sell very well and you’ve just wasted a lot of time and money on a dead product. Unfortunately, it’s impossible to predict whether the gameplay will be any fun until you can actually play the game.

Play your game as soon as possible

There is a smarter way. First build a prototype in order to test out the gameplay mechanics. The prototype has only one purpose, to learn whether the gameplay idea works. Is it possible? Is it fun? And we want to find this out as quickly as possible.

You can do a lot of the prototyping yourself long before you set out to hire a developer. Start with pen and paper, cut the game pieces out of cardboard, get some friends together and try it out. A lot of games can actually be prototyped this way. You get to do beta testing before a single line of code has been written.

If your paper prototype works, there still is no guarantee the idea can be transferred to a computer game. The next step is to hire a developer to convert your paper game into software.

Prototypes are messy

The keywords to making a software prototype are “quick and dirty”. It will use ugly placeholder graphics, there is often no sound or just very basic bleeps, the game won’t have much of a menu structure, the source code will be awful. It also requires a bit of imagination to see how it will end up being the final game. But none of that matters: the only purpose of the prototype is to tell you whether the gameplay mechanics will work.

Here is an example of such as prototype:

This is a block-stacking game idea I had a few months back. You have to rearrange the blocks into a tower by dragging and/or rotating them, so that the cute creatures (the red circles) can reach the exits. Not a bad idea, except for one thing: it doesn’t really work well on the iPhone. Your fingers obscure too much of the playing field, so it’s hard to see what you’re doing. Only a prototype will tell you those things!

It took me a few evenings to put this together. I hacked it out as quickly as I could, cutting corners where possible. As you can see, it’s not very pretty. Simple colored blocks represent the game characters. There’s no point in making beautiful artwork if you don’t know yet whether the game is worth building.

Unfortunately for me, the game idea did not turn out to be viable. Well, that’s how it goes. It’s better to know that sooner rather than later.

Prototype, tweak, repeat

If the prototype just isn’t any fun to play — and often the very first version isn’t — then you can tweak it. At this point, changes to the gameplay rules are cheap and easy. You don’t have to throw away expensive artwork, because you didn’t create any yet.

Early in the project is the best time to make big changes. Major modifications to something as fundamental as the game idea will become much more expensive as the project goes on. If the changes end up being way outside of the project scope, it may mean having to renegotiate with your developer. It means throwing away artwork you’ve already paid for and having to pay for new artwork. In any case, it will cost you.

Throw away the prototype

If your game idea works, that is wonderful. Now throw away the prototype and start over from scratch. Prototype code is meant for throwing away, not for publishing. Don’t feel like you have to use this code because you paid someone to write it. What you paid for was the validation of your idea, nothing more.

You don’t want to build the final product on a code base that was slapped together as quickly as possible. Instead, give the developer the freedom to go back to square one and build a proper foundation for the game.

Writing the prototype should already have given the developer a better idea of how to structure the code properly, because he understands the underlying problems now (he already solved them once). As software project management guru Fred Brooks says, “Build one to throw away.”

Reduce your risk

To summarize: first hire a developer to build a prototype, work through several iterations until you are sure that either: a) The game is fun and it’s worth doing it for real, or b) The game just doesn’t work and it’s time to drop the idea and move on to the next.

Certainly, getting a prototype built is a lot cheaper than getting the full game developed. The software business is risky; use prototypes to reduce your risk.

By the way, this goes for apps too. If you’re unsure about the best approach to your app — and this is something I see on a regular basis — then get a prototype done. In fact, that is how I usually treat the first milestone of any client work I do.