Exercise 43: Basic Object-Oriented Analysis and Design
I'm going to describe a process to use when you want to build something using Ruby, specifically with object-oriented programming (OOP). What I mean by a "process" is that I'll give you a set of steps that you do in order but that you aren't meant to be a slave to or that will totally always work for every problem. They are just a good starting point for many programming problems and shouldn't be considered the only way to solve these types of problems. This process is just one way to do it that you can follow.
The process is as follows:
- Write or draw about the problem.
- Extract key concepts from 1 and research them.
- Create a class hierarchy and object map for the concepts.
- Code the classes and a test to run them.
- Repeat and refine.
The way to look at this process is that it is "top down," meaning it starts from the very abstract loose idea and then slowly refines it until the idea is solid and something you can code.
I start by just writing about the problem and trying to think up anything I can about it. Maybe I'll even draw a diagram or two, maybe a map of some kind, or even write myself a series of emails describing the problem. This gives me a way to express the key concepts in the problem and also explore what I might already know about it.
Then I go through these notes, drawings, and descriptions, and I pull out the key concepts. There's a simple trick to doing this: Simply make a list of all the nouns and verbs in your writing and drawings, then write out how they're related. This gives me a good list of names for classes, objects, and functions in the next step. I take this list of concepts and then research any that I don't understand so I can refine them further if needed.
Once I have my list of concepts I create a simple outline/tree of the concepts and how they are related as classes. You can usually take your list of nouns and start asking "Is this one like other concept nouns? That means they have a common parent class, so what is it called?" Keep doing this until you have a class hierarchy that's just a simple tree list or a diagram. Then take the verbs you have and see if those are function names for each class and put them in your tree.
With this class hierarchy figured out, I sit down and write some basic skeleton code that has just the classes, their functions, and nothing more. I then write a test that runs this code and makes sure the classes I've made make sense and work right. Sometimes I may write the test first though, and other times I might write a little test, a little code, a little test, etc. until I have the whole thing built.
Finally, I keep cycling over this process repeating it and refining as I go and making it as clear as I can before doing more implementation. If I get stuck at any particular part because of a concept or problem I haven't anticipated, then I sit down and start the process over on just that part to figure it out more before continuing.
I will now go through this process while coming up with a game engine and a game for this exercise.
The Analysis of a Simple Game Engine
The game I want to make is called "Gothons from Planet Percal #25," and it will be a small space adventure game. With nothing more than that concept in my mind, I can explore the idea and figure out how to make the game come to life.
Write or Draw About the Problem
I'm going to write a little paragraph for the game:
"Aliens have invaded a space ship and our hero has to go through a maze of rooms defeating them so he can escape into an escape pod to the planet below. The game will be more like a Zork or Adventure type game with text outputs and funny ways to die. The game will involve an engine that runs a map full of rooms or scenes. Each room will print its own description when the player enters it and then tell the engine what room to run next out of the map."
At this point I have a good idea for the game and how it would run, so now I want to describe each scene:
- This is when the player dies and should be something funny.
- Central Corridor
- This is the starting point and has a Gothon already standing there that the players have to defeat with a joke before continuing.
- Laser Weapon Armory
- This is where the hero gets a neutron bomb to blow up the ship before getting to the escape pod. It has a keypad the hero has to guess the number for.
- The Bridge
- Another battle scene with a Gothon where the hero places the bomb.
- Escape Pod
- Where the hero escapes but only after guessing the right escape pod.
At this point I might draw out a map of these, maybe write more descriptions of each room---whatever comes to mind as I explore the problem.
Extract Key Concepts and Research Them
I now have enough information to extract some of the nouns and analyze their class hierarchy. First I make a list of all the nouns:
- Escape Pod
- Central Corridor
- Laser Weapon Armory
- The Bridge
I would also possibly go through all the verbs and see if they are anything that might be good function names, but I'll skip that for now.
At this point you might also research each of these concepts and anything you don't know right now. For example, I might play a few of these types of games and make sure I know how they work. I might research how ships are designed or how bombs work. Maybe I'll research some technical issue like how to store the game's state in a database. After I've done this research I might start over at step 1 based on new information I have and rewrite my description and extract new concepts.
Create a Class Hierarchy and Object Map for the Concepts
Once I have that I turn it into a class hierarchy by asking "What is similar to other things?" I also ask "What is basically just another word for another thing?"
Right away I see that "Room" and "Scene" are basically the same thing depending on how I want to do things. I'm going to pick "Scene" for this game. Then I see that all the specific rooms like "Central Corridor" are basically just Scenes. I see also that Death is basically a Scene, which confirms my choice of "Scene" over "Room" since you can have a death scene, but a death room is kind of odd. "Maze" and "Map" are basically the same so I'm going to go with "Map" since I used it more often. I don't want to do a battle system, so I'm going to ignore "Alien" and "Player" and save that for later. The "Planet" could also just be another scene instead of something specific.
After all of that thought process I start to make a class hierarchy that looks like this in my text editor:
* Map * Engine * Scene * Death * Central Corridor * Laser Weapon Armory * The Bridge * Escape Pod
I would then go through and figure out what actions are needed on each thing based on verbs in the description. For example, I know from the description I'm going to need a way to "run" the engine, "get the next scene" from the map, get the "opening scene," and "enter" a scene. I'll add those like this:
* Map - next_scene - opening_scene * Engine - play * Scene - enter * Death * Central Corridor * Laser Weapon Armory * The Bridge * Escape Pod
Notice how I just put -enter under Scene since I know that all the scenes under it will inherit it and have to override it later.
Code the Classes and a Test to Run Them
Once I have this tree of classes and some of the functions I open up a source file in my editor and try to write the code for it. Usually I'll just copy-paste the tree into the source file and then edit it into classes. Here's a small example of how this might look at first, with a simple little test at the end of the file.
In this file you can see that I simply replicated the hierarchy I wanted and then added a little bit of code at the end to run it and see if it all works in this basic structure. In the later sections of this exercise you'll fill in the rest of this code and make it work to match the description of the game.
Repeat and Refine
The last step in my little process isn't so much a step as it is a while-loop. You don't ever do this as a one-pass operation. Instead you go back over the whole process again and refine it based on information you've learned from later steps. Sometimes I'll get to step 3 and realize that I need to work on 1 and 2 more, so I'll stop and go back and work on those. Sometimes I'll get a flash of inspiration and jump to the end to code up the solution in my head while I have it there, but then I'll go back and do the previous steps to make sure I cover all the possibilities I have.
The other idea in this process is that it's not just something you do at one single level but something that you can do at every level when you run into a particular problem. Let's say I don't know how to write the Engine.play method yet. I can stop and do this whole process on just that one function to figure out how to write it.
Top Down versus Bottom Up
The process is typically labeled "top down" since it starts at the most abstract concepts (the top) and works its way down to actual implementation. I want you to use this process I just described when analyzing problems in the book from now on, but you should know that there's another way to solve problems in programming that starts with code and goes "up" to the abstract concepts. This other way is labeled "bottom up." Here are the general steps you follow to do this:
- Take a small piece of the problem; hack on some code and get it to run barely.
- Refine the code into something more formal with classes and automated tests.
- Extract the key concepts you're using and try to find research for them.
- Write a description of what's really going on.
- Go back and refine the code, possibly throwing it out and starting over.
- Repeat, moving on to some other piece of the problem.
I find this process is better once you're more solid at programming and are naturally thinking in code about problems. This process is very good when you know small pieces of the overall puzzle, but maybe don't have enough information yet about the overall concept. Breaking it down in little pieces and exploring with code then helps you slowly grind away at the problem until you've solved it. However, remember that your solution will probably be meandering and weird, so that's why my version of this process involves going back and finding research, then cleaning things up based on what you've learned.
The Code for "Gothons from Planet Percal #25"
Stop! I'm going to show you my final solution to the preceding problem, but I don't want you to just jump in and type this up. I want you to take the rough skeleton code I did and try to make it work based on the description. Once you have your solution then you can come back and see how I did it.
I'm going to break this final file ex43.rb down into sections and explain each one rather than dump all the code at once.
1 2 3 4 5 6
As you saw in the skeleton code, I have a base class for Scene that will have the common things that all scenes do. In this simple program they don't do much, so this is more a demonstration of what you would do to make a base class.
I also have my Engine class, and you can see how I'm already using the methods for Map.opening_scene and Map.next_scene. Because I've done a bit of planning I can just assume I'll write those and then use them before I've written the Map class.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
My first scene is the odd scene named Death, which shows you the simplest kind of scene you can write.
After that I've created the CentralCorridor, which is the start of the game. I'm doing the scenes for the game before the Map because I need to reference them later. You should also see how I use the dedent function on line 4. Try removing it later to see what it does.
This is the rest of the game's scenes, and since I know I need them and have thought about how they'll flow together I'm able to code them up directly.
Incidentally, I wouldn't just type all this code in. Remember I said to try and build this incrementally, one little bit at a time. I'm just showing you the final result.
After that I have my Map class, and you can see it is storing each scene by name in a hash, and then I refer to that hash with @@scenes. This is also why the map comes after the scenes because the hash has to refer to the scenes, so they have to exist.
1 2 3
Finally I've got my code that runs the game by making a Map, then handing that map to an Engine before calling play to make the game work.
What You Should See
Make sure you understand the game and that you tried to solve it yourself first. One thing to do if you're stumped is cheat a little by reading my code, then continue trying to solve it yourself.
When I run my game it looks like this:
$ ruby ex43.rb The Gothons of Planet Percal #25 have invaded your ship and destroyed your entire crew. You are the last surviving member and your last mission is to get the neutron destruct bomb from the Weapons Armory, put it in the bridge, and blow the ship up after getting into an escape pod. You're running down the central corridor to the Weapons Armory when a Gothon jumps out, red scaly skin, dark grimy teeth, and evil clown costume flowing around his hate filled body. He's blocking the door to the Armory and about to pull a weapon to blast you. > dodge! Like a world class boxer you dodge, weave, slip and slide right as the Gothon's blaster cranks a laser past your head. In the middle of your artful dodge your foot slips and you bang your head on the metal wall and pass out. You wake up shortly after only to die as the Gothon stomps on your head and eats you. I have a small puppy that's better at this.
- Change it! Maybe you hate this game. It could be too violent, or maybe you aren't into sci-fi. Get the game working, then change it to what you like. This is your computer; you make it do what you want.
- I have a bug in this code. Why is the door lock guessing 11 times?
- Explain how returning the next room works.
- Add cheat codes to the game so you can get past the more difficult rooms. I can do this with two words on one line.
- Go back to my description and analysis, then try to build a small combat system for the hero and the various Gothons he encounters.
- This is actually a small version of something called a "finite state machine." Read about them. They might not make sense, but try anyway.
Common Student Questions
- Where can I find stories for my own games?
- You can make them up, just like you would tell a story to a friend. Or you can take simple scenes from a book or movie you like.