Game Development General Personal Development

Thousander Club Update: December 4th

For this week’s Thousander Club update:

Game Hours: 235 / 1000
Game Ideas: 507 / 1000

Target: 945

I started working on my Space Invaders clone. I first created a mind map, trying to come up with as many ideas as I could regarding the project. I didn’t want to make a standard clone when I could make something a bit different. I gave myself permission to let the ideas flow. In the end, I had a really complex game that only vaguely resembled Space Invaders. It featured multiple planets, multiple weapon types, multiple types of aliens, politics, research and development, and various resources. Even time played a role in this grand game.

Then I remembered that the point of doing this game was that it was simple. So I scaled back to the basic Space Invaders game. I could always add a feature later, but I won’t let myself do so until I actually finish the basic game.

So now that I had a good idea of what game I would make, where did I start? Fred Brooks wrote that representation is the essence of programming, referring to the data structures that you would use to code any software. Someone else once wrote that the user interface IS the game. Put those two together, and I realized that the easiest way to start working on this new project was to start with the interface.

My first running program was just a blank 800×600 window. When you press the left or right arrow keys, text would appear in the console indicating which direction you pressed. When you press space, the console states that you are firing your weapon. It was a simple yet fundamental accomplishment. It showed progress.

Then I added a background graphic, which required initializing the Kyra Sprite Engine. I then made a small alien sprite and displayed it at the top of the screen. Then I made it move back and forth along the top of the screen. Then I made a ship graphic display. Then I made the ship move depending on the arrow keys being pressed.

And just like that, taking small steps, I have the beginnings of a Space Invaders clone. Many months ago, I would probably have tried to do everything at once. For instance, the player’s ship would be an entire class with all sorts of features, like thrusters and a weapon, which would be a different class. I would try writing all of this code at the same time, and debugging would be incredibly hard. This time, I put together one thing, and it worked. Then I did another small thing. Then another. And another. Each step was simple and yet brought me closer to finishing the game.

Currently, if you press the fire button, the text still appears in the console. If you press the arrow keys, no text appears, but the ship moves. This week I will work on getting the weapons systems online, and I will work on this problem in a similar way. Previously I would have tried to get a weapon that shoots bullets that cause damage against aliens that get hit, which involves code for the weapon, the bullet, the interaction between the enemies and the bullets, and explosions. It is just too complex to handle all at once. Now, I know that I will do one thing at a time. Maybe I’ll start by creating a bullet that simply moves. It doesn’t have to do anything other than move. No damage assessment, no launching it from a non-existent weapon. Just movement. I can then worry about creating and destroying bullets. Then I can worry about the bullet-alien contact causing the two things to be destroyed.

And eventually I will have waves of aliens moving back and forth, slowly descending. Eventually I will have multiple levels. A menu system. Possibly some new, unique features?

Conquering complexity. Representation. The interface. Did I really not think about these things before? They seem so obviously useful.

7 replies on “Thousander Club Update: December 4th”

Wow you’re finally getting it! This is pretty much how I develop. Worry about the smallest possible feature you can add and build on it. I’m sure you’re finding that constant small progress is far more productive and easily testable than trying to create everything at once.

RohoMech: That’s a good question. I know that I’ve spent some time thinking and writing, verifying the code, then compiling, and I can be confident that it works because I know why it will work.

When I just try something and recompile without thinking about it too much, I’m more likely to run into “Why isn’t this working?!?” problems.

I do have to say that actual coding hasn’t taken me much time at all. It’s the thinking that takes up more time. I suppose that if I was just measuring coding time, the Thousander Club hours would be a lot less than 200 hours. I was surprise at how quickly I managed to get this clone going, and I probably could have done it quicker if I didn’t get distracted so easily.

Impossible: Yeah, I basically hit a bunch of small goals, which was way more satisfying than spending days trying to get something complicated to work.

heh, yea I compose at the keyboard basically, but I refactor my code a crapload….though I think we had this conversation before, if you wanna code this way, you must have tests!

I prefer rapid dev like this cause people really like seeing progress (btw, Mr. Action will tell you the same thing) so doing things quickly and refactoring later generally gets me more motivated than thinking about stuff first…

Comments are closed.