Recent Changes - Search:

In order to run these games, you need Java installed on your computer. Here is where you can download it.

All games are based on a single gesture—either pressing the space bar or clicking the mouse. Some require click-and-hold (e.g. Battle Tanks).

Quick Links -- as of Nov 26

William Brendel

Week 1: The first stage of development focused on creating a good framework for 2D Java game development. First I created a Utilities library I thought might be useful. For example, I created a blocking loadImage() procedure so the game would not start until all resources could be loaded. There was not much to show for this week.

Week 2: I continued refining my framework, adding things like heirerarchical event handling. For example, an Actor can register itself with its Stage to receive mouse and/or keyboard events. This abstracts the raw event handling to the Stage object, which passes it on to its Actors (if they registered themselves). This is cool because an Actor object can control itself based on input, rather than changing the Stage object every time new behavior is needed. Very clean :-)

Week 3: For this week I had a demo of my game ready. It demonstrated the framework indirectly, showed off my animated GIFs, collision detection, and the tandem Actor object. This demo did not have sound.

Week 4: I added sound this week. I also changed the behavior of the JailedActor object so they did not run off the screen once freed. This way there is a party feel after all the animals are freed.

Final: I made the ball size larger on the TandemActor object. This should make it easier for the kids to see what's going on.

Links:

Ryan Buckley

http://www.cs.uml.edu/~rbuckley/game/dist/muzak.html

Tentative timeline for the next four weeks.

Week 1

  • Begin experimentation with playing sounds and displaying pictures in an applet.
  • Once this is achieved utilize a object pool (get a random one from a particular category). don't create or destroy objects.
  • This will be demoed on Fri Nov 2.

Week 2

  • Add interative portion. More specifically, the proper listening techniques so that the user will be able to supply the game with input.

Week 3

  • Design and implement the introductory page of the game. Decide on game title. Improve game aesthetics if necessary.
looks good; collect images and songs; think about signed applet with local MP3s; Japplet

Week 4

  • Experiment with getting songs and pictures from a non-internal source. Perhaps from a directory on the users computer or a disk the user may have. Obviously the proper user interface would be necessary for selecting a directory. Also, a menu to select this feature would need to be available at the start of the game.
want to have limited set of songs and images so that kids can easily go back to the ones they like. figure out how to talk to the server that you came from, and figure out way to do a dir listing so filenames don't have to be hard-coded into the source.
"Bonnie: choice of pictures very nice, very engaging colorful. Personal taste: music is wonderful, kids will enjoy it particularly our teenagers. tried messing it up -- double clikc, slow release , it didn't make a big difference. it doesn't necessarily respond to every click. if i were going to do music 2, I would choose different set of pics for each piece of music. kids are anticipating, what am i going to see and hear. kids will enjoy it just as it is.
Technical issues; I didn't wait long enough, but then when I did it works beautifully.

Daniel Gabriel

http://www.cs.uml.edu/~dgabriel/myApplet.html

Introduction: I will be developing my "Bonfire" game. The game is fairly simple but has a few advanced features. The fire animation, for example, will only be completed for the prototype if I have time. Otherwise, it will be released with the fina version of the game.

Week 1 Develop all foundations of the game.

  • Get a picture to display
  • Get a sound to play (ideally: background sound + foreground sound)
  • Detect mouse click
  • Set mouse click to trigger an event (sound + picture)
  • The above will be demoed on Nov 2

Week 2 Week 2 I am going to concentrate on the graphics. I'll make the graphic for the grill and for all of the objects. I am also going to convert the objects to the right format and give them a transparency layer. I will load them into my program (object pool). Predrawn flames. Demo: similar to above, but lots of objects in random order.

Week 3 Week 3 will be focused on creating "gameplay". I will create a physics system and will develop a main loop. By the end of week 3, it will start to look like a game. Demo: simple full game.

make more game objects; sync fire to climax of song; randomize fire graphic?; stop the music

Week 4 I will add secondary features not integral to the game itself as well as finish up smaller features.

  • Create a preference panel
  • Add background music and synch it to action
  • Refine gameplay
some issues with recycling the game. make prefs panel (change dwell period; change size of items; instead of fire, turn into popcorn). fred would like an explosion at the end when the music hits its last phase. will: you could pass a parameter at the HTML level if you wish.
Sound quality suffered on my computer. We're going to have a hard time waiting for it to get started. Music choice is great. Result two objects. Wait time to start is good. Display seems a little static. If there was more movement, you would engage kids better. Choice of items, amount of time it takes, click click click, and you just wait, that is nice. Add more visual, or shorten length of whole activity from start to finish. It's fun, kids will enjoy it. What will be fun to see which kids connect with which game.
Some wait is good, for kids to understand they need to wait. There is a big difference depending how many objects they pick. At the end when you see the final visual, with the objects in the flame, the objects don't move.

Final changes:

  • work on sound using Ryan's code
  • animate fire
  • get space bar to work

Justin Corriveau

http://www.cs.uml.edu/~jcorrive

Week 1: Procrastinate until week 2 (Actually, establish applet guidelines for plan and create rough outline of code for engine). Come up with better name. Before graphics are done, each button creates a color. First thing that pops up on the screen is the first color you click. Next is half previous color and have new color, etc. Animation is depended on button you just clicked and button you clicked previously. (that's the demo)

Week 2: Finish game engine - begin work on actual animations and sounds. Fade engine.

Week 3: Scrap week 2's animation - Create real images from scratch, color, and establish basic guidelines for simple animation. Rework layout to be proper size.

work on button highlighting, mouse click or space bar to advance.

Week 4: Mop up any unresolved issues (like the actual animations and putting images on buttons and getting a dwelling principal established) and constantly test. Tear hair out.

Bonnie: I've found the 6 blocks, good objects, nice n colorful, not too complex, graphic is wonderful, but then I have 6 objects and I don't know what's supposed to happen.
Justin: A ball is supposed to animate from left to right across the objects.
Bonnie: Sound should be great!

Jim Dalphond & Matt Ouellette

http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game/BattleTanks

Week 1: The goal for week one is to get the control panel working. Given the feedback from Bonnie, we will be implementing a changing tone as the power and angle goes up and down the scale. To do this we will use a MIDI keyboard on a mac, convert it to a wave file, and play it in a loop while the player is selecting the power and angles respectivley. Consider breaking up a big WAV file into a bunch of little ones, one per position of the control. This is the Nov 2 demo. Splash and reward screens.

Week 2: The goal for week two is to get the physics of the game as well as the tanks firing working. A secondary goal for this week is to get music in the background as all this is happening. By the end of this week the user should be able to hear the tones as the power and angle bars go up and down, use those controls to make their selections, and watch as the ball is fired from their tank.

Week 3: The goal for week three is to get the collision detection of the game working. A secondary goal for this week is to get all the buildings used as interference in the game implemented. By the end of this week the user should be able to use the controls to fire their tank, then watch as the ball is fired and explode as the ball hits a wall, shoots off-screen, or hits the other player. This week we will also be getting the animations for the blown up tank, and explosions implemented as transparent gifs.

music sync is still an issue; punch up control viz.

Week 4: The goal for week four is to get the AI for the opponent implemented, and possibly making a second player able to join in as player two. By the end of this week we should have a fully fuctional demo of the game ready for Bonnie to show to the kids and to her co-workers.

background is awesome -- works with control sounds; make AI better; winning and losing screens, changing the tanks so they don't look like propane tanks; change stroke width on control drawing BasicStroke class; explosion when tank is destroyed.
Bonnie: splash screen is great, kids will love that. I see the controllers, but it doesn' seem to work. Music and sounds are great. Buildings don't blow up.
Click and hold: some of are kids can do that. Sometimes there is a game that will work for some kids, and that's nice. Alternative: left click, right click, or double click, but intuititvely hold it down makes more sense.

Final changes:

  • tanks blow up & get fireworks for winning
  • tanks move around
  • make controls have thicker lines (context change)
  • buildings blow up
  • tanks shouldn't look like propane tanks (or, change name)

Jeffrey Albert

Things done. Objects designed, lighting, thread pool, basic mouse functionality, and more other basic design aspects. http://www.cs.uml.edu/~jalbert/bball/

JAJavaError

Week 1: Reintegrate applet functionality. Basic Physics interactions + Beginning complex physics interactions.

Week 2: More object creation and Finish Complex physics interactions.

Week 3: Game interaction and control scheme. Customization. Sound.

Week 4: Goals implemented with multiple difficulty levels. Maybe some online play if I can get to it.

Bonnie: I saw planets, I saw them colliding, screen was really dark, I had a hard time seening the planets, when I pressed the mouse button, I wasn't sure, was I making the planets larger and smaller, but screen is so dark I almost see nothing. When I click, Earth gets bigger, hardest thing is I'm not seeing well. I get complete black for large periods of time. Bounce sound could be stronger compared to background music. So little visual stimuli, looking for anything I can get. Planet is not in sunlight; we're on the dark side. Kids can really enjoy this -- just make it brighter. Going to be beautiful.

Final comments:

  • make brighter -- eg colored background
  • add basket and make it easy to score points
  • bouncy sound
  • rotational physics

Tor http://www.cs.uml.edu/~tvaleur/91_411/Jigsaw/Jigsaw.html

Week 1: Image manipulation - be able to cut up an image into individual puzzle pieces and move them about.

Week 2: Sounds - Implement background music and sound effects playing at the same time as piece movement.

Week 3: Playlists - Repetitive playing through preselected images and music.

more shapes for the edges, break up into more pieces, stop the music.

Week 4: Importing - Allow the users to add their own music and images, retain custom playlists.

Bonnie: they're flashing, not sure if my clicking is making a difference, or am i waiting between clicks? kitten is really cute. it's beautiful, sound is excellent, applause at the end is good, i was expecting that the piece would just pop to where it should go, make puzzle bigger (take up more of screen), flashing must be fixed (some kids could have seizures) if it's going to flash,
Fred: if it weren't flashing, idea of smooth animation is appealing. Pull custom image.

Final comments:

  • make sure sound stops when browser window is closed.
  • fixed the flickering!!!! yay.
  • can you make animations smoother and a bit faster?

Jonah Choquette

Pop Blocks! Concept in short: Simple graphical/audio game, single button control. User hits any key or mouse button which causes a colorful block of random color to appear on screen, followed by a "popping" audio cue. When they fill the screen, something "fun" will happen, and then the screen will be emptied so the player can start all over.

http://www.cs.uml.edu/~jchoquet/PopBlocks/build/Main.html

So far:

  • Randomized creation of colored rectangle for KeyEvent/MouseClicked Event.
  • Tracking of created rectangles and their xy coordinates in a vector for checking existing objects on draw and for later removal of objects.
  • Added background music that stops when applet is closed/navigated away from in the browser window.
  • Changed blocks to .gifs, giving them more zazz.
  • Splash Screen
  • Tuned down background music so popping noise is louder over it.

To do for the 18th:

  • Filled Screen event
  • Add way to reduce number of blocks to fill screen, probably a selection option of some sort at the splash screen.
fred's response: i want to fill the screen, and then i want something fun to happen when it's filled. collapsing, scattering, etc. we'll see bonnie's reaction to the game play.
Bonnie: this is something completely different, I like the "plop" sound, very appropriate to what you're seeing. Number of blocks is great. It's challenging -- the sheer number. Helping kids develop perseverence. Keep going. Darkest block is too dark. I filled the whole thing and nothing happened at the end -- something to say, hey you did it. I pleased to see something that will take kids a longer period of time to get to. Some kids would benefit from fewer blocks.