There will be a classic gameplay mode called casual and also an arcade mode where you find as many words as you can in a given amount of time.

I began development today on the classes which will populate the word field. I had to learn a few new details about NSString that I didn’t know before. I am still relatively new to objective-c and it is quite a departure from C# which I develop with every day.

It is going to use cocos2d in order to get some fancy graphic effects.

Good thing I began programming with standard c years ago or I’d be completely lost!

The good news is that I am now the proud owner of a shiny new iPad. The market for iPad applications is relatively small right now, also. So I am going to shift over to writing a game for the iPad. I have an idea that is going to be based off of some old code that I wrote when playing around with Irrlicht. It’s a game much like Homeworld though not quite as complex.

I’ve deleted my asteroids plan. I’m moving on!

At about 9:00 p.m. tonight I finally got over issue #1 (stop watching so much television) and decided to write my game design doc. My wife is asleep, so I pulled up openoffice and got to work.

Here’s what I realized: Writing a game design document is HARD!

Don’t take me for a newbie; I’m a consultant software developer by trade and have written technical documents dozens of pages long describing even the most menial, boring details like database designs and government standards compliance documentation. However, writing a game design document is an entirely different beast than what I have taken on before. I have in my mind what would make a great game, but committing it to words is a difficult enterprise indeed.

The most difficult problem I encountered was deciding how detailed I want to be in my descriptions. I may have the basics in mind, but once I sit down and actually analyze how those basics will work together, I found that getting bogged down in details did nothing but slow me down. I don’t see the game design document as a technical document. It describes what you want the game to do, not how it will go about doing it. I’m going to save that writing for a later time. So I decided that the language in the design doc would touch on the highlights, and give very high-level descriptions of how the game will play out.

It’s hard to stay high level. Once you get going on your document, you want to describe in depth each detail. You want to start putting code together, describing classes, determining what math you are going to use to achieve it. I ended up wiping out half of what I had written because I didn’t want to go to commit myself to any given method of implementation just yet.

So here’s what I decided. I’m going to finish this document, and I’m going not even going to think about the game for a few days. Then I’ll open it back up, and first decided if it’s still a good idea. If it is, THEN I will set about deciding the details of how to implement what it is I wrote in the design. At that point, however, I am going to have to mark the design as done and no additional ideas are going to be incorporated.

It’s going to be fun.

I will post code, plans, screenshots, etc.

First, my plan for my next iPhone/iPod Touch game.

1. Stop watching so much television.
2. Quit getting distracted reading news sites or Wikipedia.
3. Write a design document. (I have this already in the form of notes and a few drawings..)
4. Write a technical design doc. For my next game, I will be using Cocos2D and Chipmunk, along with a version of an old engine of mine called Dusty Engine that I have ported to Objective-C.
5. Don’t focus on graphics to begin with, make the game WORK and then make it pretty.
6. Don’t ignore my wife.

I work full time as a business software developer so #1 and #2 are very important, as it gets easy to be distracted and burned out when writing my own code. Adhering very closely to #6 will also make the development process go much smoother.

My next game will be an Asteroids clone. Before you click away, I have a very good idea for controlling the ship, and with Chipmunk physics I think it will blow away the competition. I was going to call it “StarRoids” until I found out that an old Mac game from the 1980s had that exact name and I don’t want those kinds of problems. Part of the failure of Smiled Out is that I am afraid to mention “Lights Out” anywhere official with it since Lights Out is trademarked.

So I haven’t yet named my project. Let’s just call it “Unnamed Asteroids Clone” as a working title.

Check back regularly for updates.