CSE 131 Module 10: Game
The game selected for this year's lab 10 is
agar.io. You will
implement a very simple form of the game for this lab, but you are free to
do extra work for some extension credit.
I have recorded some videos to give an overview of how you might structure
your game. The code from these videos is in your repository, in the
lab10 package found in the
labs source folder.
- Video 1
- Defines the Anim interface, which insists that objects
can draw themselves and say whether they are done.
- Reviews the standard animation loop that we use for all
- Shows how we use a List of Anims for a scene, and
we keep animating until all of those Anims are done.
- Video 2
- Adds more moving objects to the animation.
- Shows how to remove objects safely from a List while iterating
over that List.
- Video 3
- Introduces the notion of real time into the objects, so that they can
do something for a prescribed amount of time, regardless of the
showPauseTime used in the animation loop.
- Shows the effects of changing showPauseTime: the animation
becomes choppy or smooth as the time is increased or decreased, respectively.
- Illustrates some other animations I developed for my game. Each
of the objects described below implements Anim:
- Text that fades. I did that by changing the transparency of
the Color of the text as time progresses. The Color
begins solid and eventually is totally transparent, at which time that
particular animation is done. For more detail on transparent colors,
see the Flower Power extension.
- Text that scrolls. I did this by defining an object with an array
of Strings. That object has a delay time and as scroll time.
Each element of the array is shown on the screen after its delay time and
for the scroll time duration, with the vertical placement dependent on the
actual time relative to the scroll time. So the text appears to begin at the
bottom of the screen and move upwards.
- Text that jiggles. I did this by defining an object whose placement is
randomly changed at each call to draw() by a small amount.
- Shows some Food objects (not included in your repos) whose
radii are a function of their mass. The Blob causes a Food object to die when it touches it. The video does not show the Blob's mass increasing as it digests food, but your game should.
- Video 4 (completely optional)
- Shows how to extend a Blob into a
WigglyBlob (included in your repos).
- This demonstrates object inheritance, a topic covered in much more
detail in CSE 332S.
In the files I distribute to you, the GameOnVideo is the version
of the game I developed on the videos. It is somewhat cluttered because
I intentionally had to change some things. The Game class is
a cleaned-up version of what you see in the videos.
To receive credit for this lab, you must do the following:
- Design and implement a Food object that implements
Anim. Such an object
- has-a mass
- has-a isDead that reflects whether the food has
Initially, isDead is false
- eaten, in which case isDead is true or
- not yet eaten, in which case isDead is false
- can tell whether it is currently interesecting a Blob
- draws itself on the screen in a way that reflects its mass
- returns isDead as the result for isDone()
- Cause some Food to appear on the screen
- Cause your Blob to appaer to eat Food when it
intersects a Food
- At point, the touched Food dies
- The Blob takes on the mass of the food and its radius
- Cause your game to end when the player wins. It's up to you to decide
when that occurs, but here are some ideas:
- After some specified amount of time has passed. So, the goal here is
to eat as much as you can within the specified time.
- When the Blob obtains exactly some predetermined mass by
- When the Blob meets or exeeds some predetermined mass by
Extra Credit (extension points)
See the extension activities published for the game module. Check back
in case some new ones are added.
We will hold a contest of those worthy entries that are demo'ed and submitted
on time. To be worthy:
Winner(s) will be decided by the TAs and prizes will be awarded to the
- Your entry must be received on-time, not late
- You must have committed all code, images, and sound in your repo by
the on-time demo date.
- You must have completed at least 10 extension points for the game
- You must convince a TA (who signs off on your demo) that your game
How do I process keyboard input?
This game uses only the mouse, so no keyboard input is needed to play the
basic game. If you want to use keyboard input please use the following
keys, so that if we play the game on the IEEE arcade it will work.
| Key || Meaning|
| W or w || Up |
| S or s || Down |
| A or a || Left |
| D or d || Right |
The methods of use to you from Sedgewick's API:
- boolean StdDraw.hasNextKeyType()
- You can call this method to see if the player has typed any key. It does not
wait for input, which is very useful in this context.
- char StdDraw.nextKeyTyped()
- This method returns the next key typed. You should only call this method
if the above method has returned true.
Submitting your work (read carefully)
- You must commit all of your work to your repository. It's best to do this
from the top-most level of your repository, which bears your name and student ID.
- You must demo the commited work to a TA. Make sure the TA knows that
your demo is for credit at this point.
- Follow the directions below to have your demo for this work recorded.
Last modified 09:53:17 CDT 16 May 2016
When you done with this lab, you must be cleared by the TA to receive credit.
- Commit all your work to your repository
- Fill in the form below with the relevant information
- Have a TA check your work
- The TA should check your work and then fill in his or her name
- Click OK while the TA watches
- If you request propagation, it does not happen immediately,
but should be posted in the next day or so
This demo box is for lab 10