Recent Changes - Search:
ECG Home

GitHub

People

Publications

Calendar

Projects

Fall 2017

Older Courses

Spring 2017

Fall 2016

Spring 2016

Fall 2015

Spring 2015

Fall 2014

Spring 2014

Fall 2013

Spring 2013

Fall 2012

Spring 2012

Fall 2011

Spring 2011

Fall 2010

Spring 2010

Fall 2009

Spring 2009

Fall 2008

Spring 2008

Fall 2007

HOWTOs

edit SideBar

SoftwareEngineeringFall2007.Prototypes History

Hide minor edits - Show changes to output

Changed lines 34-39 from:
*'''Links:'''
** '''[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]'''
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/javadoc/ | JavaDoc]]
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/ | Source Code]]
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher_final.rar | RAR of NetBeans project]]
to:
'''Links:'''
*'''[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]'''
*[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/javadoc/ | JavaDoc]]
*[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/ | Source Code]]
*[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher_final.rar | RAR of NetBeans project]]
Deleted lines 39-44:
*'''Notes:'''
** The package is named "smasher" although the game itself is named "Jailbreak". This is a result of starting development without having a final name for my game :-)
** I did not add a different sound for each animal. The first reason is that the file size would be larger, and I am trying to keep the game as small as possible. Second, Jailbreak loads animated GIFs based on an index file in /images/animations/index.txt. In order to match up sounds to each animal, I would need a separate index of animal sounds. It would be fairly easy for this list to become out of sync with the list of animated GIFs. Finally, finding sounds for every animal would have taken a significant amount of time, which is in limited supply.
** The game itself is more complicated that it really "needs" to be. I intend on making Jailbreak's framework into a generic framework for 2D applet-based games. This will be a side project, not related to this course. The reason I was able to change my entire game in just one week was because of the framework I developed. It makes adding objects, levels, sounds, and images very easy. With this framework--even in its present state--one could make anything from Jailbreak, to a Super Mario clone, to Breakout. User interfaces elements such as panels and buttons could also be easily implemented using this framework. Jailbreak itself is fun, but the framework is the really cool part of this project.
** In general, the code is not as generic as I'd like. There are some Jailbreak-specific methods in the Utilities library, which is bad practice. I would also like to implement errors as framework-specific exceptions rather than things like null returns. It results in more readable code, and it is better practice in Java.

Changed lines 20-21 from:
{-In the first phase of development, I plan to create a solid foundation for my applet.  This process will include planning and writing helper functions that I will rely on throught the development process.  This will be the most important, not the most difficult, part of the development cycle.  (e.g., transfer from intro screen, to main screen). for Fri: working applet with transition from intro screen to game window. -}
to:
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.
Changed lines 23-24 from:
{-Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described.-} (controls and interface work) http://www.cs.uml.edu/~wbrendel/91.411/shatter/Shatter.html (Shatter) http://www.cs.uml.edu/~wbrendel/91.411/tandem/Shatter.html (demo of tandem style gameplay)
to:
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 :-)
Changed lines 26-28 from:
I completely changed the concept of my game (see tandem example from last week). For week 3 I should have a rough version of the game done. [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/Jailbreak.html | Week 3 Demo]] [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/source.zip | Week 3 Source]]
-> '''loved it; fred thought it was hard; have after-party when you clear the screen; add audio (different for each animal) -- JailBreak 2'''

to:
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.
Changed lines 29-42 from:
Making it look good... Coding it right... Bug fixes, adding last minute stuff, etc.

Dec 10 2007 Revision:
- Made each ball bigger at Bonnie's request

*'''Changes:'''
** Changed the end of the game. The
animals, once freed, now remain on the screen. Once all the animals have been freed, a crowd cheers for the player three times. After the cheers are done, the game restarts.
** Added sound effects for when animals are freed, when the tandem actor swaps, and when the game ends.
** Added intro and in-game music.
** Implemented resource caching system.
** Completed code commenting and JavaDoc.
** Other small bug fixes.

*
'''Files:'''
to:
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:'''
Deleted lines 45-52:
-> ''seems like it's done.  let's get feedback from Bonnie and maybe you'll make another game using this framework.''

->Bonnie's feedback:  it's hard to play , make the balls bigger, jail animation is fun, sounds are great. Increasing the number of animals (fred's comment), congrats at the end are good. 

->Will:  slow it down?  Bonnie -- not sure.  Moving target, small target.  Figuring out what you need to do to get it in the direction you need to go.


Changed lines 47-49 from:
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher.zip | ZIP of NetBeans project]]
** Source is available on the SVN server in the "Jailbreak" directory (svn+ssh://techcreation.cs.uml.edu/home/svn/repos/sweng/Jailbreak)

to:
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher_final.rar | RAR of NetBeans project]]
Changed line 46 from:
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/smasher/ | Source Code]]
to:
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/ | Source Code]]
December 12, 2007, at 03:20 PM by 129.63.223.22 -
Changed lines 183-188 from:
to:
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)
Changed lines 213-214 from:
to:
* rotational physics
December 12, 2007, at 03:14 PM by 129.63.223.22 -
Changed lines 130-135 from:
to:
Final changes:
* work on sound using Ryan's code
* animate fire
* get space bar to work

Changed lines 225-227 from:
to:
* fixed the flickering!!!! yay.
* can you make animations smoother and a bit faster?

Added lines 223-225:
Final comments:
* make sure sound stops when browser window is closed.

Added lines 199-203:
Final comments: 
* make brighter -- eg colored background
* add basket and make it easy to score points
* bouncy sound

December 12, 2007, at 12:34 AM by Jonah Choquette -
Changed lines 223-224 from:
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. After a certain period of inactivity from the user, the blocks randomly "pop" out of the field, disappearing one by one until the applet screen is once again empty, allowing the user to rinse and repeat.
to:
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.
Changed lines 231-232 from:
* Changing blocks to .gifs, giving them more zass.
* Splash Screen (only works when applet is first loaded, page refresh has issues)
to:
* Changed blocks to .gifs, giving them more zazz.
* Splash Screen
Changed lines 235-236 from:
To do:
* Check to clear blocks randomly.
to:
To do for the 18th:
Changed lines 237-238 from:
to:
* Add way to reduce number of blocks to fill screen, probably a selection option of some sort at the splash screen.
Added lines 32-34:
Dec 10 2007 Revision:
- Made each ball bigger at Bonnie's request

Added lines 3-4:
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).
December 05, 2007, at 03:22 PM by Fred Martin - integrated bonnie's feedback from the prototypes
Changed lines 11-12 from:
to:
* Tor Valeur, ''[[http://www.cs.uml.edu/~tvaleur/91_411/Jigsaw/Jigsaw.html | Jigsaw]]''
Added lines 85-88:
-> "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. 

Added lines 121-125:
->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. 

Added lines 142-147:
->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!

Added lines 169-173:
->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.

Added lines 192-193:
->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. 
Added lines 209-212:
->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.

Changed lines 207-210 from:
-> ''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.''
to:
-> ''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.

Added lines 52-57:
->Bonnie's feedback:  it's hard to play , make the balls bigger, jail animation is fun, sounds are great. Increasing the number of animals (fred's comment), congrats at the end are good. 

->Will:  slow it down?  Bonnie -- not sure.  Moving target, small target.  Figuring out what you need to do to get it in the direction you need to go.


December 03, 2007, at 01:57 PM by Fred Martin - added link to Java download
Added lines 1-2:
'''In order to run these games, you need Java installed on your computer.  Here is where you can [[download it --> http://www.java.com/en/download/index.jsp]].'''
December 03, 2007, at 12:13 AM by Jonah Choquette -
Changed lines 192-194 from:
to:
* Splash Screen (only works when applet is first loaded, page refresh has issues)
* Tuned down background music so popping noise is louder over it.

Changed lines 197-199 from:
* Splash screen.

->
''it's too hard -- need mode with fewer blocks.  popping noise needs to be louder w/r/t background music.  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.''
to:
* Filled Screen event

->
''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.''
Changed lines 8-9 from:
* Jonah Choquette, ''[[http://www.cs.uml.edu/~jchoquet/PopBlocks/build/Main.html | Pop Blocks!]'' (formerly, ''Oregon Trail... in Space!'')
to:
* Jonah Choquette, ''[[http://www.cs.uml.edu/~jchoquet/PopBlocks/build/Main.html | Pop Blocks!]]'' (formerly, ''Oregon Trail... in Space!'')
November 26, 2007, at 04:34 PM by Fred Martin - created quick links at top
Added lines 1-11:
!! Quick Links -- as of Nov 26
* William Brendel, ''[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Jailbreak]]'' (formerly, ''Shatter'')
* Ryan Buckley, ''[[http://www.cs.uml.edu/~rbuckley/game/dist/muzak.html | Muzak]]'' (formerly, ''Music and Image Game'')
* Daniel Gabriel, ''[[http://www.cs.uml.edu/~dgabriel/myApplet.html | Bonfire]]''
* Justin Corriveau, ''[[http://www.cs.uml.edu/~jcorrive/BouncingApplet.html | Bouncing Pathways]]''
* Jim Dalphond & Matt Ouellette, ''[[http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game/BattleTanks | BattleTanks]]''
* Jeffrey Albert, ''[[http://www.cs.uml.edu/~jalbert/bball/ | B-Ball]]''
* Jonah Choquette, ''[[http://www.cs.uml.edu/~jchoquet/PopBlocks/build/Main.html | Pop Blocks!]'' (formerly, ''Oregon Trail... in Space!'')

----

Changed lines 184-186 from:
* Splash screen.
to:
* Splash screen.

-> ''it's too hard -- need mode with fewer blocks.  popping noise needs to be louder w/r/t background music.  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.''
Added lines 95-96:
-> '' 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. ''
Added lines 37-38:
-> ''seems like it's done.  let's get feedback from Bonnie and maybe you'll make another game using this framework.''
Added lines 61-62:
-> ''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.''
Added lines 110-111:
[[http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game/BattleTanks]]
Changed lines 125-127 from:
[[http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game/BattleTanks]]
to:

-> ''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.''
Changed line 25 from:
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]
to:
** '''[[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]'''
Changed lines 29-30 from:
to:
** Source is available on the SVN server in the "Jailbreak" directory (svn+ssh://techcreation.cs.uml.edu/home/svn/repos/sweng/Jailbreak)
Changed line 16 from:
*Changes:
to:
*'''Changes:'''
Changed line 24 from:
*Files:
to:
*'''Files:'''
Changed line 30 from:
* Notes:
to:
*'''Notes:'''
Changed lines 16-35 from:
Changes:
* Changed the end of the game. The animals, once freed, now remain on the screen. Once all the animals have been freed, a crowd cheers for the player three times. After the cheers are done, the game restarts.
* Added sound effects for when animals are freed, when the tandem actor swaps, and when the game ends.
* Added intro and in-game music.
* Implemented resource caching system.
* Completed code commenting and JavaDoc.
* Other small bug fixes.

Files:
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/javadoc/ | JavaDoc]]
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/smasher/ | Source Code]]
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher.zip | ZIP of NetBeans project]]

Notes:
* The package is named "smasher" although the game itself is named "Jailbreak". This is a result of starting development without having a final name for my game :-)
* I did not add a different sound for each animal. The first reason is that the file size would be larger, and I am trying to keep the game as small as possible. Second, Jailbreak loads animated GIFs based on an index file in /images/animations/index.txt. In order to match up sounds to each animal, I would need a separate index of animal sounds. It would be fairly easy for this list to become out of sync with the list of animated GIFs. Finally, finding sounds for every animal would have taken a significant amount of time, which is in limited supply.
* The game itself is more complicated that it really "needs" to be. I intend on making Jailbreak's framework into a generic framework for 2D applet-based games. This will be a side project, not related to this course. The reason I was able to change my entire game in just one week was because of the framework I developed. It makes adding objects, levels, sounds, and images very easy. With this framework--even in its present state--one could make anything from Jailbreak, to a Super Mario clone, to Breakout. User interfaces elements such as panels and buttons could also be easily implemented using this framework. Jailbreak itself is fun, but the framework is the really cool part of this project.
* In general, the code is not as generic as I'd like. There are some Jailbreak-specific methods in the Utilities library, which is bad practice. I would also like to implement errors as framework-specific exceptions rather than things like null returns. It results in more readable code, and it is better practice in Java.
to:
*Changes:
** Changed the end of the game. The animals, once freed, now remain on the screen. Once all the animals have been freed, a crowd cheers for the player three times. After the cheers are done, the game restarts.
** Added sound effects for when animals are freed, when the tandem actor swaps, and when the game ends.
** Added intro and in-game music.
** Implemented resource caching system.
** Completed code commenting and JavaDoc.
** Other small bug fixes.

*Files:
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/javadoc/ | JavaDoc]]
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/smasher/ | Source Code]]
** [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher.zip | ZIP of NetBeans project]]

* Notes:
** The package is named "smasher" although the game itself is named "Jailbreak". This is a result of starting development without having a final name for my game :-)
** I did not add a different sound for each animal. The first reason is that the file size would be larger, and I am trying to keep the game as small as possible. Second, Jailbreak loads animated GIFs based on an index file in /images/animations/index.txt. In order to match up sounds to each animal, I would need a separate index of animal sounds. It would be fairly easy for this list to become out of sync with the list of animated GIFs. Finally, finding sounds for every animal would have taken a significant amount of time, which is in limited supply.
** The game itself is more complicated that it really "needs" to be. I intend on making Jailbreak's framework into a generic framework for 2D applet-based games. This will be a side project, not related to this course. The reason I was able to change my entire game in just one week was because of the framework I developed. It makes adding objects, levels, sounds, and images very easy. With this framework--even in its present state--one could make anything from Jailbreak, to a Super Mario clone, to Breakout. User interfaces elements such as panels and buttons could also be easily implemented using this framework. Jailbreak itself is fun, but the framework is the really cool part of this project.
** In general, the code is not as generic as I'd like. There are some Jailbreak-specific methods in the Utilities library, which is bad practice. I would also like to implement errors as framework-specific exceptions rather than things like null returns. It results in more readable code, and it is better practice in Java.
Added lines 30-35:
Notes:
* The package is named "smasher" although the game itself is named "Jailbreak". This is a result of starting development without having a final name for my game :-)
* I did not add a different sound for each animal. The first reason is that the file size would be larger, and I am trying to keep the game as small as possible. Second, Jailbreak loads animated GIFs based on an index file in /images/animations/index.txt. In order to match up sounds to each animal, I would need a separate index of animal sounds. It would be fairly easy for this list to become out of sync with the list of animated GIFs. Finally, finding sounds for every animal would have taken a significant amount of time, which is in limited supply.
* The game itself is more complicated that it really "needs" to be. I intend on making Jailbreak's framework into a generic framework for 2D applet-based games. This will be a side project, not related to this course. The reason I was able to change my entire game in just one week was because of the framework I developed. It makes adding objects, levels, sounds, and images very easy. With this framework--even in its present state--one could make anything from Jailbreak, to a Super Mario clone, to Breakout. User interfaces elements such as panels and buttons could also be easily implemented using this framework. Jailbreak itself is fun, but the framework is the really cool part of this project.
* In general, the code is not as generic as I'd like. There are some Jailbreak-specific methods in the Utilities library, which is bad practice. I would also like to implement errors as framework-specific exceptions rather than things like null returns. It results in more readable code, and it is better practice in Java.

November 26, 2007, at 08:52 AM by Will - Added week 4 info
Added lines 16-29:
Changes:
* Changed the end of the game. The animals, once freed, now remain on the screen. Once all the animals have been freed, a crowd cheers for the player three times. After the cheers are done, the game restarts.
* Added sound effects for when animals are freed, when the tandem actor swaps, and when the game ends.
* Added intro and in-game music.
* Implemented resource caching system.
* Completed code commenting and JavaDoc.
* Other small bug fixes.

Files:
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/Jailbreak.html | Play Game]]
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/javadoc/ | JavaDoc]]
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/src/smasher/ | Source Code]]
* [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak_final/zip/Smasher.zip | ZIP of NetBeans project]]

November 24, 2007, at 05:05 AM by Jonah Choquette -
Deleted lines 148-150:

To do:
* Check to clear blocks randomly.
Added lines 150-152:

To do:
* Check to clear blocks randomly.
November 20, 2007, at 10:04 PM by Jonah Choquette -
Changed lines 148-149 from:
to:
* Added background music that stops when applet is closed/navigated away from in the browser window.
Deleted line 151:
* Adding background music.
November 19, 2007, at 01:51 AM by Jonah Choquette -
Changed lines 134-153 from:
Week 4: Importing - Allow the users to add their own music and images, retain custom playlists.
to:
Week 4: Importing - Allow the users to add their own music and images, retain custom playlists.

----

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. After a certain period of inactivity from the user, the blocks randomly "pop" out of the field, disappearing one by one until the applet screen is once again empty, allowing the user to rinse and repeat.

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.

To do:
* Check to clear blocks randomly.
* Adding background music.
* Changing blocks to .gifs, giving them more zass.
* Splash screen
.
November 16, 2007, at 03:17 PM by Fred Martin - comments from week 3 demos
Changed lines 11-12 from:
to:
-> '''loved it; fred thought it was hard; have after-party when you clear the screen; add audio (different for each animal) -- JailBreak 2'''
Added lines 35-36:
-> '''looks good; collect images and songs; think about signed applet with local MP3s; Japplet'''
Added lines 62-63:
-> '''make more game objects; sync fire to climax of song; randomize fire graphic?; stop the music'''
Added lines 82-83:
-> '''work on button highlighting, mouse click or space bar to advance.'''
Added lines 98-99:
-> ''' music sync is still an issue; punch up control viz.'''
Added lines 132-133:
-> '''more shapes for the edges, break up into more pieces, stop the music.'''
Changed lines 13-14 from:
Bug fixes, adding last minute stuff, etc.
to:
Making it look good... Coding it right... Bug fixes, adding last minute stuff, etc.
November 16, 2007, at 02:50 PM by 129.63.223.185 -
Added lines 19-20:
[[http://www.cs.uml.edu/~rbuckley/game/dist/muzak.html]]
Changed lines 10-11 from:
I completely changed the concept of my game (see tandem example from last week). For week 3 I should have a rough version of the game done. [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/Smasher.html | Week 3 Demo]] [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/source.zip | Week 3 Source]]
to:
I completely changed the concept of my game (see tandem example from last week). For week 3 I should have a rough version of the game done. [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/Jailbreak.html | Week 3 Demo]] [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/source.zip | Week 3 Source]]
Changed lines 10-11 from:
I completely changed the concept of my game (see tandem example from last week). For week 3 I should have a rough version of the game done.
to:
I completely changed the concept of my game (see tandem example from last week). For week 3 I should have a rough version of the game done. [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/Smasher.html | Week 3 Demo]] [[http://www.cs.uml.edu/~wbrendel/91.411/jailbreak/source.zip | Week 3 Source]]
November 16, 2007, at 01:57 AM by 76.118.161.133 -
Changed lines 73-76 from:
Week 3:  Continuation of week 2 animation and sound - toss beta versions around to anyone willing give feedback.  Start animation when game starts.  Build animator.

Week 4:  Mop up any unresolved issues and constantly test.
to:
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.

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.
Added lines 109-121:

----

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.

Week 4: Importing - Allow the users to add their own music and images, retain custom playlists.
Deleted lines 2-4:
'''Introduction:'''
My game development plan includes three weeks of programming and one week of testing.  The main development challenge will be designing the gameplay mechanics, as well as figuring out how to make the shatter effect look good.  Collission detection will be an interesting challenge.  I already know how to implement the basic algorithm, but I want to make sure I do it right so it looks realistic.  Following the coding process, I will be spending a week testing the game myself and with others.

Changed lines 4-5 from:
In the first phase of development, I plan to create a solid foundation for my applet.  This process will include planning and writing helper functions that I will rely on throught the development process.  This will be the most important, not the most difficult, part of the development cycle.  (e.g., transfer from intro screen, to main screen). for Fri: working applet with transition from intro screen to game window.
to:
{-In the first phase of development, I plan to create a solid foundation for my applet.  This process will include planning and writing helper functions that I will rely on throught the development process.  This will be the most important, not the most difficult, part of the development cycle.  (e.g., transfer from intro screen, to main screen). for Fri: working applet with transition from intro screen to game window. -}
Changed lines 7-8 from:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described. (controls and interface work) http://www.cs.uml.edu/~wbrendel/91.411/shatter/Shatter.html (Shatter) http://www.cs.uml.edu/~wbrendel/91.411/tandem/Shatter.html (demo of tandem style gameplay)
to:
{-Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described.-} (controls and interface work) http://www.cs.uml.edu/~wbrendel/91.411/shatter/Shatter.html (Shatter) http://www.cs.uml.edu/~wbrendel/91.411/tandem/Shatter.html (demo of tandem style gameplay)
Changed lines 10-11 from:
This week will be dedicated to making the cannon fire and collision detection.  As long as I have the rest of the game working by the beginning of this week, I should have a good shot at finishing on time.  With the NetBalls game I made, I did point-circle colli sion detection, which is really just a special case of circle-circle detection.
to:
I completely changed the concept of my game (see tandem example from last week). For week 3 I should have a rough version of the game done.
Changed lines 13-14 from:
This week will be dedicated to bug fixes and beta testing the game.  The main problem I am anticipating is with the collision detection algorithm.  There may be small inaccuracies that make the game seem unrealistic, and thatís something I need to make sure gets fixed.  Beta testing the game to make sure itís actually fun is also a big task.  If something having to do with the basic gameplay turns out to be ďnot funĒ, there could be a big problem.
to:
Bug fixes, adding last minute stuff, etc.
November 10, 2007, at 11:17 PM by matto - fixed game link
Changed line 94 from:
[[http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game]]
to:
[[http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game/BattleTanks]]
Changed lines 10-11 from:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described. (controls and interface work) http://www.cs.uml.edu/~wbrendel/91.411/shatter/Shatter.html
to:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described. (controls and interface work) http://www.cs.uml.edu/~wbrendel/91.411/shatter/Shatter.html (Shatter) http://www.cs.uml.edu/~wbrendel/91.411/tandem/Shatter.html (demo of tandem style gameplay)
November 09, 2007, at 05:04 AM by Will - added week 2 of my game
Changed lines 10-11 from:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described. (controls and interface work)
to:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described. (controls and interface work) http://www.cs.uml.edu/~wbrendel/91.411/shatter/Shatter.html
Changed lines 103-104 from:

to:
[[JAJavaError]]
Added lines 70-71:
http://www.cs.uml.edu/~jcorrive
Added lines 42-43:
http://www.cs.uml.edu/~dgabriel/myApplet.html
November 02, 2007, at 01:44 PM by 129.63.220.14 -
Changed lines 96-98 from:
Things done.  Objects designed, lighting, thread pool, basic mouse functionality, and more other basic design aspects.

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



Changed lines 7-8 from:
In the first phase of development, I plan to create a solid foundation for my applet.  This process will include planning and writing helper functions that I will rely on throught the development process.  This will be the most important, not the most difficult, part of the development cycle.
to:
In the first phase of development, I plan to create a solid foundation for my applet.  This process will include planning and writing helper functions that I will rely on throught the development process.  This will be the most important, not the most difficult, part of the development cycle.  (e.g., transfer from intro screen, to main screen). for Fri: working applet with transition from intro screen to game window.
Changed lines 10-11 from:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described.
to:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described. (controls and interface work)
Changed lines 26-27 from:
* Once this is achieved utilize a thread pool.
to:
* 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
.
Changed line 47 from:
*Get a sound to play
to:
*Get a sound to play (ideally:  background sound + foreground sound)
Changed lines 49-50 from:
*Set mouse click to trigger an event
to:
*Set mouse click to trigger an event (sound + picture)
* The above will be demoed on Nov 2

Changed lines 53-54 from:
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.
to:
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.
Changed lines 56-57 from:
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.
to:
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.
Changed lines 68-72 from:
Week 1:  Procrastinate until week 2 (Actually, establish applet guidelines for plan and create rough outline of code for engine).
Week 2:  Finish game engine - begin work on actual animations and sounds.
Week 3:  Continuation of week 2 animation and sound - toss beta versions around to anyone willing give feedback
.
week 4:  Mop up any unresolved issues and constantly test.
to:
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:  Continuation of week 2 animation and sound - toss beta versions around to anyone willing give feedback.  Start animation when game starts.  Build animator.

Week
4:  Mop up any unresolved issues and constantly test.
Changed lines 80-81 from:
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.
to:
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.
October 26, 2007, at 02:05 PM by 129.63.220.14 -
Added line 90:
Changed lines 98-99 from:
Week 3:  Game interaction and control scheme.  Customization.
to:
Week 3:  Game interaction and control scheme.  Customization. Sound.
Changed lines 81-82 from:
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.
to:
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.
Changed line 84 from:
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 read for Bonnie to show to the kids and to her co-workers.
to:
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.
October 26, 2007, at 01:48 PM by 129.63.220.14 -
Added lines 87-99:


Jeffrey Albert
Things done.  Objects designed, lighting, thread pool, basic mouse functionality, and more other basic design aspects.


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.

Week 4:  Goals implemented with multiple difficulty levels.  Maybe some online play if I can get to it.
Changed lines 25-27 from:
        Begin experimentation with playing sounds and displaying pictures in an applet.
     
Once this is achieved utilize a thread pool.
to:
* Begin experimentation with playing sounds and displaying pictures in an applet.
*
Once this is achieved utilize a thread pool.
Changed lines 29-31 from:
        Add interative portion.  More specifically, the proper listening techniques so that
     
  the user will be able to supply the game with input.
to:
*  Add interative portion.  More specifically, the proper listening techniques so that  the user will be able to supply the game with input.
Changed lines 32-33 from:
       Design and implement the introductory page of the game.  Decide on game title.  Improve game aesthetics if necessary.
to:
* Design and implement the introductory page of the game.  Decide on game title.  Improve game aesthetics if necessary.
Changed lines 35-38 from:
        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 haveObviously 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.
to:
* 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 directoryAlso, a menu to select this feature would need to be available at the start of the game.
Changed line 88 from:
[[www.cs.uml.edu/~mfouelle/SoftwareEngineering/game]]
to:
[[http://www.cs.uml.edu/~mfouelle/SoftwareEngineering/game]]
Changed line 88 from:
to:
[[www.cs.uml.edu/~mfouelle/SoftwareEngineering/game]]
October 26, 2007, at 01:13 PM by Jim - JimEditFinish
Changed lines 77-80 from:
''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
.
to:
''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.

''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.

''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 read for Bonnie to show to the kids and to her co-workers.

----
October 26, 2007, at 01:03 PM by Jim - Jims Addition
Changed lines 13-14 from:
This week will be dedicated to making the cannon fire and collision detection.  As long as I have the rest of the game working by the beginning of this week, I should have a good shot at finishing on time.  With the NetBalls game I made, I did point-circle collision detection, which is really just a special case of circle-circle detection.
to:
This week will be dedicated to making the cannon fire and collision detection.  As long as I have the rest of the game working by the beginning of this week, I should have a good shot at finishing on time.  With the NetBalls game I made, I did point-circle colli sion detection, which is really just a special case of circle-circle detection.
Changed lines 72-80 from:
week 4:  Mop up any unresolved issues and constantly test.
to:
week 4:  Mop up any unresolved issues and constantly test.

----
'''Jim Dalphond & Matt Ouellette'''

''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
.
Changed lines 63-72 from:
*Refine gameplay
to:
*Refine gameplay

----

Justin Corriveau

Week 1:  Procrastinate until week 2 (Actually, establish applet guidelines for plan and create rough outline of code for engine).
Week 2:  Finish game engine - begin work on actual animations and sounds.
Week 3:  Continuation of week 2 animation and sound - toss beta versions around to anyone willing give feedback.
week 4:  Mop up any unresolved issues and constantly test.
October 25, 2007, at 07:57 PM by Daniel Gabriel - My 4 week plan
Added lines 40-63:
----

Daniel Gabriel

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
*Detect mouse click
*Set mouse click to trigger an event

'''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.

'''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.

'''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
Changed lines 1-2 from:
William Brendel
to:
'''William Brendel'''
Changed lines 10-13 from:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls.

The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described.
to:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls. The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described.
Changed line 3 from:
Introduction:
to:
'''Introduction:'''
Changed line 6 from:
Week 1:
to:
'''Week 1:'''
Changed line 9 from:
Week 2:
to:
'''Week 2:'''
Changed line 14 from:
Week 3:
to:
'''Week 3:'''
Changed line 17 from:
Week 4:
to:
'''Week 4:'''
Changed lines 4-5 from:
My game development plan includes three weeks of programming and one week of testing.  The main development challenge will be designing the gameplay mechanics, as well as figuring out how to make the shatter effect look good.  Collission detection will be an interesting challenge.  I already know how to implement the basic algorithm, but I want to make sure I do it right so it looks realistic.  Following the coding process, I will be spending a week testing the game myself and with others.
to:
My game development plan includes three weeks of programming and one week of testing.  The main development challenge will be designing the gameplay mechanics, as well as figuring out how to make the shatter effect look good.  Collission detection will be an interesting challenge.  I already know how to implement the basic algorithm, but I want to make sure I do it right so it looks realistic.  Following the coding process, I will be spending a week testing the game myself and with others.
Changed lines 15-16 from:
This week will be dedicated to making the cannon fire and collision detection.  As long as I have the rest of the game working by the beginning of this week, I should have a good shot at finishing on time.  With the NetBalls game I made, I did point-circle collision detection, which is really just a special case of circle-circle detection.
to:
This week will be dedicated to making the cannon fire and collision detection.  As long as I have the rest of the game working by the beginning of this week, I should have a good shot at finishing on time.  With the NetBalls game I made, I did point-circle collision detection, which is really just a special case of circle-circle detection.
Changed lines 18-19 from:
This week will be dedicated to bug fixes and beta testing the game.  The main problem I am anticipating is with the collision detection algorithm.  There may be small inaccuracies that make the game seem unrealistic, and thatís something I need to make sure gets fixed.  Beta testing the game to make sure itís actually fun is also a big task.  If something having to do with the basic gameplay turns out to be ďnot funĒ, there could be a big problem.
to:
This week will be dedicated to bug fixes and beta testing the game.  The main problem I am anticipating is with the collision detection algorithm.  There may be small inaccuracies that make the game seem unrealistic, and thatís something I need to make sure gets fixed.  Beta testing the game to make sure itís actually fun is also a big task.  If something having to do with the basic gameplay turns out to be ďnot funĒ, there could be a big problem.
October 24, 2007, at 02:35 PM by Will - Added my plan
Added lines 1-21:
William Brendel

Introduction:
My game development plan includes three weeks of programming and one week of testing.  The main development challenge will be designing the gameplay mechanics, as well as figuring out how to make the shatter effect look good.  Collission detection will be an interesting challenge.  I already know how to implement the basic algorithm, but I want to make sure I do it right so it looks realistic.  Following the coding process, I will be spending a week testing the game myself and with others.

Week 1:
In the first phase of development, I plan to create a solid foundation for my applet.  This process will include planning and writing helper functions that I will rely on throught the development process.  This will be the most important, not the most difficult, part of the development cycle.

Week 2:
Once I have a solid foundation, I will create the user interface of the game.  This will include writing the opening screen and gameplay area.  The opening screen will be different from the video.  It will just show the Shatter! graphic and move straight into the game window.  Creating the gameplay window will consist of making the cannon work properly and making the grid for the glass balls.

The cannon will function  like the cannon in the Battle Tanks game.  It will rotate automatically and just rely on a button press for firing.  This will make it easier for the kids to play.  There will be a score  meter like Bonnie described.

Week 3:
This week will be dedicated to making the cannon fire and collision detection.  As long as I have the rest of the game working by the beginning of this week, I should have a good shot at finishing on time.  With the NetBalls game I made, I did point-circle collision detection, which is really just a special case of circle-circle detection.

Week 4:
This week will be dedicated to bug fixes and beta testing the game.  The main problem I am anticipating is with the collision detection algorithm.  There may be small inaccuracies that make the game seem unrealistic, and thatís something I need to make sure gets fixed.  Beta testing the game to make sure itís actually fun is also a big task.  If something having to do with the basic gameplay turns out to be ďnot funĒ, there could be a big problem.

----

Added lines 1-20:
Ryan Buckley

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 thread pool.

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.

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.

Edit - History - Print - Recent Changes - Search
Page last modified on December 17, 2007, at 01:10 AM