iDevGames

Development Tools

Because I was a beginning developer, I didn’t have all the fancy, expensive tools that most other people seemed to have. In fact, I created my game and all of its assets in only four different applications: TNT Basic to write the game, Appleworks 6 to create the graphics, PlayerPro to write the music and sound effects (yes, the sound effects are all made out of musical instruments!), and TextEdit to write everything from the licenses to this postmortem. And the best part about it? The only cost for all this software was the twenty-five dollars to register TNT Basic.

Well, as it turns out, I didn’t really know what I was getting into. I signed up for the contest as soon as I could and began work on my game. I soon realized that it is a lot easier to make a game if you know exactly what it is you’re going to make. But I wasn’t really set back by this, I just happily opened Appleworks and started drawing pixel art—something I had never done before in my life. If you’ve played this game, you’ve probably noticed the low-quality 32-bit graphics. Every single image in the game was made by me in Appleworks, my first ever attempt.

1.pict

What Went Wrong

Music

When my game had become complex enough that it took a while to test it (every time), I decided that it would be a bit easier on me if I added a bit of music that I could listen to while I waited to for everything to happen. Of course, at the time, I didn’t see this as a problem with my game. If I was getting bored… well, other people might be too. But anyways, I just went and opened PlayerPro, and started figuring out exactly how good music sounds. I guess I never found out. I wrote all of the music that went with the game with PlayerPro, and I still to this day cannot figure out why people rated it as well as they did.

Ignoring Beta Testers

I had the game beta tested, and then ignored my beta testers—never a good idea. The basic game concepts were in good order, but the way in which the game ran was just much too ugly. I found out the hard way: when people play games, they want to play them, not spend five minutes setting up their game. I had made the assumption that people wanted to customize their games in the maximum number of ways possible, but I found out that this is only true if it doesn’t take any time.

The Gameplay

The thing that nobody would look at. I can’t say that I blame them. The most annoying bug was the thing that pretty much demolished the game—the keys went crazy. Well, almost. It turns out that TNT Basic in Mac OS X has some complications with the keyboard buffer, and sometimes if keys were pressed a bit too often, they would register in the reader and keep on getting read into the computer long after the player had let go of the key. There was a simple solution to this for the player, but it still annoyed them, and me. This problem stayed with my game through voting, and it even earned a place in the readme.

Sprite Collision

I ran across a problem in my game, and never found out if it was a coding problem, or a glitch in TNT Basic. When the player built up their ship, at the end of each “stage” (there were eight of them), the picture of the player’s ship would be copied and stored as a sprite. This was necessary because the player’s ship image changed depending upon what the player was purchasing. But unfortunately, the image copied was a very large area, because of the large sizes of some of the ships. So if a player picked the smallest ship class (a fighter), the entire large area around it would be copied as part of the image. And then I couldn’t shrink the sprite. The large area around the ship counted as the ship’s ‘bounds’, so if someone shot at a ship and missed it, but just slightly, it would still register as a hit. This was another bug that stayed with my game, but fortunately not very noticeable due to the high average velocity of most of the weapons used.

Selection Menu

I got lots of good feedback about how not to make a selection menu. Apparently, the setup I used was way too inefficient. It was a linear system: the user picked components for each section, and progressed along an an eight-point line. But once you picked something, you couldn’t go back. This was because of the ship picture. Once the picture was “taken,” it replaced the older copy of itself, a bad idea on my part. People also suggested that it should be much more flexible, and the players should be able to choose whatever component they wanted at any time. I think that this would have been a good idea too.

Game Design Issues

Many gamers didn’t like the idea of building a ship. Many suggested that players should be able to buy “pre-made ships,” or at least be able to save their ship designs so they wouldn’t have to redesign it every time. I actually had started working on a procedure to save ship designs, but I had to drop it due to time constraints. I guess it would have been a good idea to squish it in anyway.

2.pict

What Went Right

Some of the votes I got were actually pretty high (e.g. four).

Weapons

Once I got into pixel art, I found that making some of those 60-frame weapon animations was actually pretty fun, although I can’t say that I’m much of a design student. I think that overall, some of the weapons looked pretty good. My personal favorites were the plasma spread array and the space-time disruptor. The plasma spread array shot off a large cloud that slowly expanded and changed colors from yellow to dark red as it travelled. The space-time disruptor was a bunch of lines rapidly crisscrossing, but when used in large numbers gave a wicked-looking effect.

Story

I spent a bit of time working on it, and I felt that I would get a decent vote on it by most developers (which I did). But I guess not many people got far enough to read most of it. And I thought I wrote it okay, but one voter left the comment that I should spellcheck the game (always a good idea).

3.pict

Looking back on uDevGames

One of the good things about this project was that it was actually for a contest. Not only did this contest push me to make a game that was actually playable, but to make one that would be fun, enjoyable and look good. I also cannot list all of the things that I learned while participating in the contest; the looming deadline made me strive to learn how to get things done, and quickly. Even if you never before have made a game in your life, I would challenge you to take part in this contest and just try your best. You’d be surprised what you can get done if you actually have a strong motive behind you.

Plans for Astroknights

Unfortunately, I have to say that with all of the feedback I got, I’d pretty much have to go back and change everything from the ground up in order to get the game how people want it. I might release a small, patched version, but that would probably be it. I have to say that I learned a lot, but as I game, I don’t think that Astroknights as it is makes the cut. The graphics were described as “cheesy,” the sounds as “corny,” and the gameplay as “lacking,” but I guess that all could be fixed. The most important thing holding me back is the bad code structure that I used. It just really wasn’t meant to be played with much. But hey, there’s always next year.

TNT Basic,beta testers,gameplay,sprite collision,game design

Further Resources