Space

- Spec Change and Cleanup -


PURPOSE:

Here we see what happens when the spec is changed just as I am about done with my assignment. We see how and if my design can accommodate the changes and how hard it is to implement them. Also to show one how they can make their program more entertaining.

NEW SPEC:

While ordinary space travel is exciting, it is pretty slow. We would like you to implement a "Warp" action which all ships can execute. Once the warp selection is made a selection graphic should appear on the screen so the user can select where they want to the ship to warp to. Once selected the ship should speed off to that spot and stop when it gets there. The user cannot break warp once it has begun and turning off the ability to affect the ship while it is in warp is extra credit.

INITIAL BREAKDOWN:

Wow, there sure is a lot of functionality to cover here. But what about design? To make a new action all I have to do is create another ShipManipulator subclass which encapsulates the added functionality. Then all I have to do is create two instances of Key and Mouse so that the user can actually use the new functionality. I also have to get a new graphic for the new functionality.

So I started coding. Design wise it was very simple to add the classes I needed to add. No structure had to be changed at all. This was great! Implementation wise it was a different story. It turned out that it was sort of difficult to get my ship to stop at the specified warp point. Most of the times it would keep on flying super fast eventhough I had set its velocity to zero. I was perplexed.

So what I tried then was to create a new vector and set its velocity to zero and then set the vector of the ship to the new one. This worked. All that remained for this spec change was to add the mouse button. This took me a total of five minutes from finding the picture on the web to adding the code. I'd like to say that it worked on the first try but it did not. I realized that I had not been turning off the different input devices when the other was active. Especially my mouse buttons which I had to custom turn on and off. For now they were always on. All I had to do was add code to the constructors of both controllers to make sure that they started off and the, whenever a Mouse instance tried to execute its ShipManipulator it would actually check the boolean I had setup.

When all was said and done the added change had taken an hour and a half (mostly due to stupid compiler errors) and I had added only three classes to my code. The classes I added were: Space.Manipulators.Warp, Space.Manipulators.WarpSelector and a WarpBehavior.

New Classes:

Changed Classes:

CLEANUP:

One thing that was upsetting me about my program was that the ship always started off black. And since I was using someone else's class I could not change it. Normally in a situation like this you would subclass and override what you didn't like. However in this situation the GP.Components.ColorChooser was not designed with extensibility in mind.

What was I to do? I decided to write my own color chooser class to be able to do what I wanted it to do. But this didn't work. It turned out there is some error in GP that would crash horribly whenever I manually changed the value of a slider by calling SetValue() on it. This would be a major stumbling block. Or would it? Certainly it was nice to reuse the code the GP provided but perhaps I should write my own to insure that I get the functionality I wanted. This is what I would do.

One thing I wanted to make sure when I wrote this class was that it wasn't tied down to my program specifically. That is, I wanted anyone to be able to use it on anything they wanted. Keeping with this idea I designed it like GP's GP.Components.ColorChooser and GP.Attributes.Colors.Chooser relationship. I would have a color that was based upon my chooser as well. This seemed to be a very nice way of solving it. It was very useful for me to be able to see how GP worked internally so I could see how Brian solved the problem I had.

All in all it took three more classes to get my color chooser working the way I wanted it to:

Now it was time for some killer sound effects. So I surfed the web for a bit and got some really nice sounds. A really great page for sounds is http://sunsite.unc.edu/pub/multimedia/sun-sounds/. It would be really simple to add these to my program. All I had to do was create instances of GP.Sounds and Play() them when I wanted to.

I noticed a flaw in my design while I was adding the ultra-gratuitous button select sounds. That is that my KeySelect and MouseSelect should really have a common superclass to factor out some of their code. Also, to do this I would need to have my controllers either have a common superclass or interface.

As I set out to do this I realized that my Mouse and Key classes could also be generalized into an interface I called Input. This generalization would allow me to have a generic Controller which could turn on or off its inputs whenever it was clicked on. This proved to simplify my design nicely. Here are my new classes after the mini-redesign:

New Classes:

Changed Classes: Sound Augmented Classes: When these changes were finsihed I was satisfied with my product. Here is a screen shot of my final Space program.

This page was last updated by Shoe on 03/04/98.
Comments or suggestions, should be sent to: ahs@cs.brown.edu
Space is copyright 1996-1998 by Andrew H. Schulak