For the final project of my first cs class (CS 150) we had to implement a version of the classic arcade game Frogger! We worked in teams of three. It was required that we have lanes of traffic which went different directions at different speeds with random cars on them. It was optional whether there would be log lanes as in the original Frogger. Our group was the only one to make log lanes that year.

We knew that if we were going to complete this project in a short amount of time we would have to properly abstract and model the problem. It seemed clear that the cars were each concrete subclasses of some abstract class Vehicle. Once we developed the idea of having the dead frogs stay in the road we knew that this clearly indicated a state pattern (though time constraints turned this into a flag variable). The frog would be either in an alive or dead state which would determine its appearance and behavior. In trying to develop how the actual play area would be modeled we realized that the game of Frogger is based around the concept of a lane. So we created an abstract lane class. The safe lane across the bottom is one subclass of this. Since we planned from the beginning to have both car and log lanes we created an abstract motion lane for handling a lane filled with moving objects. Since all the objects in a lane were to move in sync we decided to let the lane handle their movement. Car and log lanes are concrete subclasses of our abstract motion lane.

Once all these things were designed we had to figure out how they interacted. Most things were fairly obvious. The one which took the most development was the Frog. We realized that the frog needed to move between lanes but also that lanes may need to affect this process. This led us to the idea that a frog could jump onto and off of a lane as well as see the adjacent lanes. The most difficult interaction was how to make the frog move with the logs. One of my teammates realized that since the lane knew how to move all the logs in sync all that was needed was for the lane to move the frog. This required that we abstract more, and I knew just the abstraction needed. All the logs, cars, and the frog were sprites. This abstraction was the right one and gave us all the needed power simply and easily.

Since the lanes needed a constant flow of cars or logs to put into their lanes, but the lane new nothing about how to make these items we knew a sprite factory was needed.

In addition to modeling the frogger game we created systems to contain it, interact with the user and paint. We used multiple threads allowing the simulation to run independent of the painting which was very helpful.

jwalker@cs.oberlin.edu