How does one best manage complexity when designing and programming a computer game?
I've been developing a Space Invaders tutorial. Version 1 (beginner) and 2 (intermediate) were straightforward to make but I also want to include an advanced version in my tutorial, for those keen students who want to learn advanced features of game maker.
I'm finding this has become a complicated exercise in design, programming, refactoring of code, representation and communication.
I wanted the enemies (clown sprites) to advance wave upon wave in relentless, mechanical fashion, increasing their speed with each new advance. Start off quite slow, so the player thinks he will win but as the speed increases it becomes inevitable that the Shooter will die.
The word here is phalanx, meaning a body of infantry drawn up in close order. Or maybe it is serried, as in shoulder to shoulder, without gaps
Initially, I put together some code and eventually got it working.
I couldn't put all the code on the clowns because if you shot all the clowns then the game would crash. So, I made a controller which was responsible for making and remaking the serried ranks. But some code had to stay on the clowns, for example, the bit where when you advanced far enough down the room, then the shooter would lose a life. That can't go on the controller because the controller doesn't move.
if y > 448 {lives = lives -1};
Another advanced feature of the game was a powerup object. These were created out of thin air and moved in the general direction of the shooter. When the shooter ate them he received more power, which in turn enabled him to kill multiple clowns with a single shot.
When I tried to write this advanced version down on paper it was messy.
I decided to refactor the code, to tidy it up, to make it easier to follow.
Programs must be written for people to read, and only incidentally for machines to execute
- Abelson and Sussman
There is another problem. As well as being messy the code is more advanced than versions 1 and 2. But I'm just giving it up to students in chunks for them to copy. Probably not a good way for students to learn.
First, I have to get the design options clear in my own head and then work out how to communicate those options to students in a way which hopefully will help them learn.
Simply, writing down the main game objects (and renaming them more systematically) on paper and the main actions of those objects does help.
objClownControlAction: Create new rows of enemies.
This immediately helps. Under what conditions do I want new rows of enemies created? Fixed time intervals? Randomised time intervals? When all other enemies are destroyed? That is a design decision. I think I want fixed time intervals in keeping with the phalanx / serried ranks approach. So the code needs to go on an Alarm Event.
On each cycle I want the clown speed to increase. So, I need a speed variable. Do I want the speed to increase forever, no ceiling on the speed. Yes. The shooter must die, after being lulled into a false sense of security.
objClownAction: When the clown reaches the bottom of the room, then the shooter loses a life
Action: When a bullet hits the clown then the clowns explode, the radius of destruction is determined by the current power of the shooter
It looks simple when written down systematically like this but it has taken me some time to get to this point,where I can articulate the issues clearly.
I believe there is a lot of teaching involved in all of this ... programming skills, discussion of design decisions, the representation of the design, refactoring of code. It requires more than a motivating, constructionist environment.
I think that a good way to represent this diagramatically would help a lot in the communication and discussion of the issues with students. We need pictures to help us think about design and programming because the code itself is too detailed, its granularity is too fine. I think I need to dig back into my UML book and perhaps revisit my Event Progress Diagrams of the past to work out a good way to represent this.
Reading:
What I've learned from failure - Reg Braithwaite
A wonderful essay about commercial programming reality.("I'm not going to tell you about some theoretical anti-pattern, or relate some broken thing I've fixed, I'm going to share things that caused me to leap from the deck of a burning boat to avoid drowning.")
