1.4 Your project

As mentioned before, the best way to learn programming is to have some project that you yourself want to work on. Read through this section and then take a look at the exercises at the end of the chapter. Exercise 1.1 is designed to get you into a mind-set where you're thinking about things you might possibly do, and Exercise 1.2 encourages you to take the initial step towards specifying a game project you can build with the Pop Framework. It would be a good idea to actually write out your answers, especially to Exercise 1.2.

Once you've come up with some ideas about what you might want to do for your project, remember to keep thinking.

Don't lock in on a particular project idea too early. Keep an open mind. You should plan on getting feedback and revising your project idea several times before you finalize anything. This iterative process is an example of what's called requirements gathering. Here are some suggestions for your requirements gathering.

First of all, you'll want to become familiar with the Pop code we're using so as to get an idea of what kinds of technical things will be easy to do.

Secondly, you'll need to make sure you find a project of the right level of difficulty. You don't want a project that's trivially easy, on the other hand you don't want a project that's too hard to finish within the available time. Given the realities of software development, it's wiser to pick something on the easy side, as software projects always take longer than you first expect them to. Your professor can help you gauge this.

Thirdly, you may be using this book in a course where you're expected to work with a team, and you're going to need to have a project that all of the team members can commit to.

Fourth, don't plan for your game to be an exact clone of an existing game such as one of the Nintendo games, and don't plan on using bitmaps or character names from any commercial games or other media sources such as Disney or Warner Brothers. Although you may want to use the basic design and play of an existing game, you must come up with your own, independently developed name and graphics theme. Otherwise you will be (a) violating copyright or trademark and (b) writing an 'imitation' game that is going to forever look second-rate compared to the 'real' version of it. Regarding the copyright issue, you might feel that a big game company wouldn't bother to come after a student project ? and you're probably right. But what if your project turns out really well and you want to put it up on the web for free download? At this point you actually do stand a chance of running afoul of a corporate webcrawler. Regarding the issue of being second-rate, students sometimes feel that using a commercial game's graphics will make their game seem better. The opposite is true. Reminding users of a real Nintendo game when they play your game is only going to make your game look weak! Your game needs to stand or fall on its own qualities, not on the borrowed glamour of some other work.

A fifth thing to keep in mind is that sometimes it only takes one good concept to really make a game interesting. Try and think of an original concept that is fresh and not over-familiar. Don't be afraid to be inventive or even downright weird! Even an easy project can seem fresh and new if it has a good concept.

Take, for instance, our Spacewar game. This is more or less a copy of the familiar Asteroids game. It has nice code in it, but the appearance isn't fresh. Perhaps the simplest kind of projects that students do is to take Spacewar and to add something to make it seem new. One might, for instance, have the player be a fairy with a wand, and have the enemies be bees. Or one might have the player be a swimmer with a harpoon and have the enemies be sharks. Or have the player be a photographer with a camera and have the 'enemies' be wild animals seen on a photo-safari. Or have the player be a deer who's shooting at hunters. Or have the player be a shepherd who's chasing away wolves. In each case, you'd still be using the same guns-and-bullets code of Spacewar, but you'd be clothing the program in a concept that made it look a little fresher.

A more powerful notion than redecorating an existing game is to come up with some wholly new elements in the game. You might, for instance, have a game like Spacewar, but specify that, to start with, the enemies are all inside a box and the player is outside the box. And then have the enemies come tunneling out one by one. Or have a treasure that the player has to pick up as well having to shoot enemies. Or have your player racing the enemies through a maze or around a track.

Also keep in mind that a game doesn't have to be like Spacewar at all. There are several other examples of games in the Pop program, and you may think of still more.

The best of all is if you can think of some completely new idea. If you look at the range of commercial games for arcade machines, game consoles and personal computers, you'll notice that there are a handful of games totally different from the others. These are the killer apps, the ones that nobody's thought of before.

A final suggestion is that you should take a look at some of the descriptions of past student projects in the Hall of Fame section of Chapter 19: More Ideas for Games.

    Part I: Software Engineering and Computer Games
    Part II: Software Engineering and Computer Games Reference