University of Calgary

frogger

Frogger
2002-2003




Assignment Links:

JavaCurses (lab notes)
Graphics Slides:


Classes you can use:

GameVal.java (constants, all static)

easyCurses.help (Documentation)
play.java (a sample main)
Frogger.Play (Documentation: game options - text)
Point.java ( X and Y coordinates)
Thing.java ( base class for guys on screen )
easyCurses Classes: (window stuff) easyCurses.class trackerUtil.class ucAnswer.class ucError.class
WARNING: Start early!!!!!!!!!!! If you run into serious problems (conceptual or program design) during the last week you may not get help. Design problems must be dealt with in the first 1 1/2 weeks. If you have not got most of your program working by Nov. 13 the TA's Tutors, Instructors, and Lab Coordinator may not have time to help you. (In other words if you leave it till the last minute, you may be out of luck)
But hey, how often are you going to get an assignment that starts off with:
Go Play.
I really mean it too. The best way to get a feel for what your program is supposed to do and how it's supposed to work is to actually play the game for a while. On-line versions are linked below.
 
Goals & Concepts
- inheritance
- also larger, more involved, 3 weeks
- students will get some help here: definition of base class and outline of driver [engine]
- inheritance mechanism must be obvious
- more complex relationships between classes
- a problem with no single correct implementation : students are encouraged to make design choices
- a fairly open-ended problem
- a problem that could easily take much more time than we have to complete so students are forced to specify their own bounds

The Original Frogger (info) [where the images mostly came from]
More info
A Java-Version you can play
See the Lab Notes for background information.

The following files will be available in the course directory:
~becker/Courses/233/A5
Frogger.Play (Documentation: game options)
easyCurses.help (Documentation: easycurses )
myRand.java
GameVal.java (constants, all static)
Point.java ( X and Y coordinates together in one object )
Thing.java ( the base class for the guys on the screen )
play (maybe: sample to run )
play.java (a sample main)
the easyCurses Classes:(window stuff)
easyCurses.class
trackerUtil.class
ucAnswer.class
ucError.class

Problem Statement:

Write a program to play a simple version of the old classic arcade game, "Frogger".
 
Background & History
from: http://www.geocities.com/arcadeclassics.geo/FROGGER.html
Everyone remembers Frogger. They remember the colorful graphics. They remember the catchy music. They remember the addictive gameplay. But do they remember who created the game?

Konami was a young kid in an increasingly crowded video game market in 1981. They had released many games with minimal success each time, but had finally seemed to come up with something with the game of Frogger. Based on an old Jonathan Winters joke about a frog trying to cross the highway, Frogger pitted a huge frog with the task of dodging traffic, snakes, crocodiles, and a raging river of obstacles to make it to his home.

Frogger was an instant hit. Young and old enjoyed the game. Konami, however, ran into a problem when looking to release the game in the United States. They had no US branch at that time, and looked for a company to distribute in in America.

Enter Sega/Gremlin. Later known as just Sega, this company was formed from two merging amusement manufacturing veterans. Sega had expanded considerably over the late seventies and early eighties with hits such as Monaco GP and Astro Blaster. Konami approached them about producing Frogger in the US. Sega agreed to do so. This is where it becomes complicated.

The game was a huge hit in America. It put Sega up with Midway and Atari with it's mega hit status. But Sega and Sega alone was credited with the game. As it was between Namco and Midway with Pac-Man, wording in the American distribution contracts left Konami's name out of the credits for the game. Sega had sole rights to license products and home versions of the game. Konami, needing a break like this, was left out in the cold.

After Sega was once again credited alone in the Parker Bros. made home versions of the game, it went to court. Due to the odd nature of the contract between the two companies, BOTH companies ended up with rights. And neither wanted the other one to have them.

Frogger proved to be a merchandising bonanza. T-shirts and even a cartoon hit the US market during it's heyday. Parker Bros. produced millions of home versions of the game as well as a rare sequal of sorts in 1983 known as Frogger II: Threedeep! However, the problems between Sega and Konami forced the game into oblivion for some time. When Sega wanted to produce a Game Gear version of the game in 1991, Konami threatened action. Sega, not wanting to go through the trouble, scrapped the port.

Frogger DID made an appearance in a final season episode of Seinfeld. Jerry's friend George had been trying for years to get the high score on a local Frogger machine and finally accomplished his goal. To make sure the score was preserved, he tried to cross a busy street with the machine as the old game music began to play. As was always the eventual results with anyone who played the game, George and his machine failed to make it home as the machine got snagged on the curb and wiped out by a passing truck.

In late 1996, all rights to Frogger went to Hasbro Interactive. They produced a horribly received 3-D remake of Frogger that same year. Critics and fans of the original game did not take to it well, which ended up with a good thing for owners of a couple of older home game systems. In 1997, Hasbro released the classic version of the game for the Sega Genesis and Nintendo Game Boy. Production was short on these versions of the classic Frogger, though, as they were packaged in the same boxes as the hardly liked remake, and many failed to notice it was indeed they classic the all loved inside.

Description of Our Version:
- no sound
- ASCII graphics
our game will consist of a WINDOW defined using "easycurses" and marks displayed in the window will be standard ASCII characters (size: 80W X 24H)
- graphics done using easycurses
- our "universe" is two dimensional
 
Since we do not yet have the experience to create a full-blown event-driven system our game will run as "snapshots in time". (in other words, we make a move or take a turn; the screen is updated, then we make another move...)

Game Basics:
The game consists of a screen, on which we 'draw' numerous Things. Some Things can move and others not. One of the Things is controllable by user input (we can make it move).

We will create an initial configuration at the start of the game consisting of a number of different Things. When we have crossed the road and river, we win. If we get run over, drowned, or eaten first, we loose.

 
Each object will respond to the conditions as they were at the end of the previous time interval.
 
At each time interval:
- each object will make a move based on the screen as it was last
- Things continue to move
- we retrieve input from the user to tell us what the "Frog" (that's the player) should do (which could be null meaning don't move the Frog)
 
Running the Game:
- ( optional ) can have command line arguments for game "parameters":
- level of difficulty (affects # of Vehicles, Critters, Frog's jumping abilities (range), etc.)
- or could allow user to specify range, etc.
- with no arguments, it would be run like:
java Play
- can have a restart option or can simply require the user to quit and start again
 
(suggested) user input: (everyone but Frog moves EACH "turn")
q

= Quit

<blank>
= move everyone but Frog
z

= move Frog left

/

= move Frog right

f
= move Frog forward
j
= make Frog Jump
(like hyperspace i.e. move
several squares at once)
The "names" of these commands need not be as specified - can use others (single-character Highly Recommended). Check the keyboard for conveniently located keys.
 
I would suggest implementing them in the above order (roughly). Do <blank> and 'q' first with just the Vehicles to make sure they behave as they are supposed to. Do this before your Frog even exists.


The Objects:
The core of the program consists of a Game Class (known as the "AI" in games-writing circles) and a hierarchy of "things". You must use inheritance in this assignment. The "things" (Vehicles, Critters, Frog) are all derived from the same base class (Thing or some-such).
 
The Game Class
The Game Class will keep track of who is on the "board". This is "the AI". It is the part of the program that enforces the rules, keeps score, and acts as the go-between (between the user/main program and the "things" on the screen). The main program is a simple go-till-quit loop, and any time something needs to happen in the game, it's the "AI" that gets called to do it. There are many ways to implement this and the following description outlines only one. Different approaches will require different data and methods.
 
The Game Class needs to keep track of the following things:
DATA: some kind of list of the objects (Vehicles, Critters, me)
- this could be: Thing[] list = new Thing[100]; // an array containing pointers to the objects
- may need a count of things (a count for Vehicles, Critters, and maybe a total)
- may want to keep a pointer to the Frog (seperately)
 
It needs to be able to get the following information:
- calculate the distance between two points
- determine if two objects have collided
- check for collisions with the Frog & Vehicles (in this game, Homes, Vehicles, & Critters should not be in danger of colliding wih each other)
- move all objects to their next spot
- given a point on the board the AI should be able to say "who's there" (a pointer to the object would do it; if there's no-one there it can return NULL)

 
Possible access functions:
return a pointer to the Frog
 
Possible forwarding functions:
- make the Frog move left
- make the Frog move right
- make the Frog jump
- make the Frog move forward
 
The Objects:The ThingClass
 
This is the base class for the major objects: Vehicles, Critters, Frog, (Missiles?)
 
It contains all the parts common to all:
DATA: Point origin (the centre or head of the object)
int status (whether it's alive, or dead, or what)
-in the guide status may have one of these values: ALIVE, DIVING, GAPING, DROWNING, DYING, DEAD
- the usual "image" is printed when the thing is ALIVE
- things can sometimes change their status, in which case they should be drawn differently
- if it's status is DYING it will be erased from the screen and its status changed to DEAD
- The effect seen on the screen as a result of this is that objects appear to change and then will stay that way until the next "turn", when they disappear
int orientation (what direction is it headed? - one of: N, S, E, W)
int size (how many 'squares' wide is it?)
int radius (for this game, mostly 1)
int speed (how many 'squares' does it move with each turn?)

  There are 4 Utility Routines:
nextX, nextY, prevX, prevY
- these give the next value (row or column) but takes into account the current edges of the screen as well as the size of the object so we don't "draw outside the window"
- they also do wrap-around so if you are at the right edge and say nextX you get a point on the far left
- can base these on the "nextX" and "nextY" methods in cursWindow
 
Public Routines:
- some are abstract so they MUST be defined in the derived class.
 
- constructor and access functions are already defined and don't need to be redefined in the derived class (remember we still need to do the constructor for the derived class)
- base class constructor does nothing so you'll probably want to look after things in the derived class.
 
Others:
Move() - abstract move in current direction
- usually the thing will first be erased, then re-drawn depending on it's current status
Draw() - abstract draw a picture of me on the screen
Erase() - abstract get rid of the picture of me on the screen
Die() - draw a picture of me dying on the screen

 
The FrogClass
origin : middle of screen at bottom
status : alive
orientation: facing north
size: 1?
radius : 1?
 
Note: if you have your image made of only one character (a 'head' ) drawing it is simpler. Its orientation will not change.
 
- can move one square at a time
- can change direction
- can move N,S,E,W ONLY
 
Also need:
Jump (move 2-5 - you pick)
Move (LEFT or RIGHT)
Forward()

The Critters Class (there are actually several kinds of Critters)
origin : each 'group' originates in the same row
status : alive
orientation: E or W
size: 1-10?
radius : 1?
speed : 1-5 // how many squares it moves with each 'turn'
the frog can land on some safely but not others
 
- movement is E or W with wrap, or with each 'dying' when it reaches the other side and new ones being created.
- every alternate row moves in a different direction
- size may vary in 'width' (#columns) but not length (#rows)
- the direction it moves depends on which Critter it is (start with just one kind)

A Vehicle Class
origin : each 'group' originates in the same row
status : alive
orientation: E or W
size: 1-10?
radius : 1?
speed : 1-5 // how many squares it moves with each 'turn'
the frog must avoid all of these

- movement is E or W with wrap
- every alternate row moves in a different direction
- size may vary in 'width' (#columns) but not length (#rows)
- the direction it moves depends on which Critter it is (start with just one kind)

A Home Class
There are a number of homes - any of which can serve as places for the frog to go UNLESS the home is occupied by an alligator.
 

Summary of "Things" on the Screen:

--
asst level
move?
direction
role
when touched
Home
C
no
---
goal
SAFE, unless occupied by aligator
Frog
C
yes
North
He's the Dude
--
Vehicle:

C [2 rows]
B [5 rows]
yes
E-W
move 'N' squares each turn
FROG DIES, when no more frogs,
GAME OVER
Critter: Aligator
B
yes
E-W
Safe, as long as the mouth is closed
OK to land on
Critter: Small Log
B
yes
E-W
safe
OK to land on
Boulevard
B [no timer]
A [with timer]
no
---
safe
OK to land on
Critter: Turtle
A
yes
E-W
safe, but sometimes they dive
OK to land on, unless it dives
Critter: Long Log
A
yes
E-W
safe, but can harbour snakes
OK to land on, watch out for snakes
Critter: Girl Frog
Bonus
yes
E-W
safe
gives bonus points
Critter: Aligator
Bonus
yes
E-W
NOT safe
FROG DIES
Critter: Snake
Bonus
yes
E-W
bad guy, can be found on log or boulevard
if touches frog, frog over
Multiple Frogs
Bonus
yes
North
next one appears when current one gets home
Minimal Solution & A-B-C Requirements:
Get some graph paper so you can draw your window and objects. Calculating x,y coordinates is easier if you have a picture of what your are doing.
C Requirements The minimal passable solution will have only a single Frog that moves correctly on the screen, 2 rows of Vehicles moving in opposite directions and one Home at the top. This solution is worth a maximum mark of C+
 
B Requirements The midrange solution will have 3 Homes, 5 rows of Vehicles, and a working Frog who can move [ jumping is bonus] and ONE OF: two kinds of Critter, ---OR--- a Boulevard to rest on (with NO time limit),
This solution is worth a maximum mark of B+
 
NOTE: having the frog ride river creatures properly (and not "slide" off) is BONUS and not part of the base requirements.
A Requirements The best solution will have 5 Homes, 5 rows of Vehicles, one Frog, AND 5 rows of Critters all working correctly. It is worth up to an A The boulevard will have a time limit, [BONUS: and the turtles must sometimes dive.]
The "full-function" Frogger is Bonus. It includes the girl Frog; Aligators whose mouths open, and snakes on logs and on the boulevard
 
HINT: (!!!!) Get the game working in this order: (TEST AFTER EACH STEP!!!!!)
1. the main program that sets up the window
(start by drawing a specific 'picture' in a specific location)
and runs the main game (switch on user input)
2. the Home
3. the Vehicles ( ONE row; get them placed , then worry about other rows)
4. the AI (who will be in charge of all Things)
5. the Frog (move forward then the rest)
6. The Boulevard
7. the Critters (move, do other stuff last)

Testing and Marking:
Needs external documentation that user can refer to while playing the game.
 
Sample Mark Guide Here
 
Notes on Marking:
We will be looking for the usual good, clean design; documentation, etc. as always.
In order to pass it must work. (Some marks will be given to all *reasonable* attempts, working or not)
Specifics we will be looking for when marking [some parts only apply to 'B;-level or above]:
  • Initial Configuration
    is everyone inside the lines?
  • Vehicles
    • drawn correctly?
    • do they cause the Frog to die when they run over it?
  • Frog
    • initial position correct?
    • can the player move him?
    • can the player make him jump?
    • does he die when hit?
    • is it possible to win?
  • Critters
    • can the frog land on them?
    Homes
    can the frog go in them?
  • Boulevard
    can the frog go on it?
    is there a time counter?
    How to submit your assignment:
    This assignment SHOULD be 'demo'ed for your TA. Be sure to arrange a time IN LAB (or when your TA is scheduled in CT or MS218) with your TA.
    This assignment can be submitted electronically using submit.
    Include:
    - all '.java' files
    - all '.class' files
    - javadoc documentation
    - your external documentation, including a diagramatical form of your classes

  • BONUSES:
    1. [up to 6 points] Make a girl frog.
    2. [up to 6 points] Make the aligator's mouth open.
    3. [up to 10 points] Include the snakes.
    4. [up to 10 points] Multiple (5) frogs per game. [homes can be occupied by only one frog]
    5. [2-3 points] Detect "Game Over": when Frog dead; or when Frog gets across.
    6. [2 points] Keep score.
    7. [2-5 points, per level] Allow different levels of difficulty (different #'s of things, different ranges, etc.)
    8. [2 points] Set up "key bindings" so player can use the arrow keys, etc.
    9. [4-? points] Make it Interrupt Driven

    CHALLENGE:
    1. [4-? points] Add sound.
    2. [4-? points] Create a full GUI
    3. [5-? points] Do it in colour
    4. [5-? points] 3-D



    Updated: December 20, 2005 05:19 PM