- First Coding Attempt -

The purpose of this section of the Journal is to provide a compendium of all the problems I encountered while attempting to write the program for the first time.

FIRST PROBLEMS:

While writing my top-level class, Simulation, I recalled that GP provided a color chooser for us. Looking back at the lectures I found out that the class that did this was a GP.Attributes.Colors.Chooser. It acted upon any class which implemented the GP.Colorable interface. Understanding this relationship I decided that my Ship class should implement this interface so I could color it easily. Since this class is now containing its shape rather than inheriting from it I would have to write the methods SetColor(GP.Attributes.Color) and GetColor() for my Ship class.

I also noticed that while a lot of classes had association relationships with the ShipHolder, no one had a containment relationship to it. That is, I hadn't decided who was going to create it yet. In deciding which class should be in charge of creating it I looked at all the classes which needed to know about it. These classes turned out to be all of the choosers. Since I was going to create all of the choosers in the Simulation class I decided to create the ShipHolder here as well. This way when I created the choosers I could tell them about the ShipHolder by passing a reference to it as a parameter to their constructors.

As I started to wirte my InputChooser class I realized that I hadn't really thought about my input devices in the detail that was now going to be necessary. My InputChooser would still be a bunch of toggle buttons but what would happen when a button was pressed? If we had selected to use the keyboard I would have to install key interactors on the current ship. If I selected to use the mouse I would have to either pop up a window to control the ship with the mouse or just activate a bunch of already created buttons. I decided to choose the latter since I thought it would be nice to have all the GUI options visible even if they weren't functional.

but this led to a problem I had not forseen. Unlike key interactors push buttons cannot be turned on and off. If they were going to be present the entire time then I would have to give them the ability to be turned on and off as well. This seemed a simple solution and I added a Boolean state to the mouse buttons and mimicked the way keys were turned on and off. So I created TurnOffReactor() and TurnOnReactor() methods in my push buttons. These methods woukld alter the Boolean state of the buttons so that if they were off nothing would happen if they were pressed.

The next class I decided to work on was the ShipChooser. As soon as I did I realized that I was going to have a problem. I knew that I wanted to have a generalized button class to place ships on the screen but I didn't know how to do it. Each button would need to know about a specific type of ship, but how could I do that if I only had one class? Again I decided to go ask a TA. Laura was on hours and I approached her.

She told me that I could parameterize the type of Ship to the button and have it place copies of the ship into the ShipHolder. This way I can have buttons know which Ship they create and I can just have one button class. As I was about to go Laura called to me and asked me if I was interested in knowing about the associated design pattern to what she had just taught me. Being a person of a curious sort I said sure. She told me that it was a Prototype pattern. What this pattern allowed us to do was to keep one copy of something and whenever someone else wanted one we could give them a copy of it. Well at least thats all I got out of her explanation, which I am sure was pretty good.

Soon I was ready to deal with the Ship class and its subclasses. This was going to be a lot of code and I felt I was ready for it. The first thing I needed to think about was how I was going to model the Ships movement. Remembering how we modeled bees in Swarm I decided that I would use a cs015.SP.Vector to orient the Ships.

Originally I had decided to place the methods for Thrusting and Dethrusting in my subclasses of Ship. This made sense at the time but now I saw that I could do it differently. Since the only the difference in how the Attacker and Explorer moved was the velocity with which they moved. I could have each subclass specify the velocities at which they moved and the code could be the same. Turning was even more generic and I left all that in the superclass as I had designed. I decided to make these methods final so that the subclasses could never redefine them. The Activate method I kept abstract so that all subclasses would have to override them.

But how would the ship actually move? Thrusting would only increment the speed as would dethrusting. They wouldn't actually propel the ship along. I needed a way to keep the Ship moving if the user wasn't pressing any keys. Thinking back to Swarm I realized that I could use a behavior to do do this. I could install a behavior on my ship that would continually propel it along. The only problem with this was that behaviors in GP acted only on shapes. Aha! But my Ships have shapes as well. I could install a behavior on my Ship's shape and have the behavior manipulate that. This sounded like a winner to me so I decided to implement it. In order to do this I had to add a few accessors and mutators. I had to allow access to my Vector and my shape's Position.

Soon my generic Ship class was completed. I then decided to tackle a subclass of Ship, Atatcker. The big striggle here would to have it shoot a Weapon when it was Activated. My Weapon would be a FilledOval and would need to move just like the Ship did. So I gave it a Vector and a behavior and it seemed like it would be ready to go. I wanted to make sure that it always went faster than the ship that fired it so when it was fired it would add extra velocity to the Ships velocity. Also, I used the proptype pattern again for when the Ship actually fired the weapon. The Ship would keep around one reference to a Weapon and would make copies of it to Activate them.

I decided to only write one of the subclasses first for debugging purposes. If I had done something awfully wrong I didn't want to have to undo more of my code. Now it was time to compile.

And this was a really bad idea. Why? Because I had written 742 lines of code and not compiled once! I had sommany errors I almost got lost. After I got through the tedious amounts of syntactical errors I started seeing where I had made some bad choices. For one, I had used a GP.Attributes.Colors.Chooser when I really meant to use a GP.Components.ColorChooser in order to select the color of the Ship. I noticed this because the parameters were wrong that I passed to its constructor.

Finally my code compiled and I ran it.

FIRST RUN:

The thing that was most apparent was that my GUI design was terrible. All of the choosers were next to each other in a row. There was a lot of wasted space below them which made the applet look really bad. Besides this the color chooser did not work, all I could do to the ship was activate it, turning and thrusting did not work at all, and the more I selected the Attacker ship in the ShipChooser the more that popped up in that window. It was looking pretty bad.

But something worked. The switching between key and mouse input worked perfectly. Also, the weapon that the Attacker fired did move faster and in the same direction as the ship. This was good! But that was about all. I needed to make some improvements and fix up a lot of stuff.

• Screen capture of first run
• Classes for first run