1 / 13

OpenSpace Collaborative Art Game Proposal

OpenSpace is a collaborative art guessing game where players take turns as illustrator or assistants. Guess the drawing and alter brushes with effects for points. Coded in Java. Stand-alone client app. Optional server. Weekly development timeline and detailed testing plan.

bkunkel
Download Presentation

OpenSpace Collaborative Art Game Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OpEnSpaCe LCA Proposal Calvin Chin David Couvrette Jung Son Mikiko Jama CSE403 Summer 06

  2. Operational Concept - OpenSpace is a collaborative art guessing game, in which one player acts as an illustrator and the other players serve as his or her assistants. - The assistants attempt to guess what the illustrator is drawing in a short time frame, and get to alter the illustrator’s brush with a random selection of effects that change each round. - Assistant gets points for guessing correctly, and so does the illustrator (to prevent unmotivated illustrators) - Each round does not last longer than 2 minutes. - After every round, a new person is selected as an illustrator, so everyone gets a chance to draw. - After everyone has gone, scoring is tabulated and a winner declared.

  3. System Requirements - Coded entirely in Java using the standard Java libraries - Stand alone client application - Clients need to be running JRE 1.5 - Optional stand alone server application - Server needs to be able to handle simultaneous games, with each game holding from 2-6 players.

  4. System Requirements

  5. System Requirements

  6. System Requirements

  7. System Architecture

  8. Team Structure • Server/Network Team-David, Mikiko • GUI Team-Jung, Calvin -Once the high priority features are done, all four of us will pool together to integrate and produce the lower priority features

  9. Timeline • Week 1 , 2: -develop Server/networking and GUI(client) -Integration of both portions • Week 3: -refinement & adding already desired features -release and gathering feedback • Week 4: -refinement & adding more features based on feedback • Week 5: -feature lock & final heavy testing

  10. Test Plan • J Unit testing Server side tests: - Multiple users connecting - Finding maximum users that the server can handle - Running simultaneous games on multiple threads - Communication between clients via server - Listening for commands - Sending commands - Keeping track of the game state (big suite of tests)

  11. Test Plan • J Unit testing Client side connectivity tests: - Connection to server - Sending/receiving messages to and from server - Interpreting messages accurately - Keeping in sync with other clients - Listening for commands from the server

  12. Test Plan • J Unit testing Client side GUI and media tests: - Synched brush effects between clients (a suite of connectivity and media tests) - Accurate switching between illustrator and assistant mode - Switching between game browsing mode and game playing mode - Sound and music tests to assure that correct sounds and musics are playing - Brush effects are rendering in the right color, texture, and behaving appropriately.

  13. Risks - Custom Server/Client architecture is toodifficult to implement in the timeframe given. However, current tests of the built in Java libraries have lessened our worries over this risk. - Many graphical effects provided in game may be too difficult to implement. This is an area that still requires more research for a better assessment. - Feedback may indicate issues with core components of OpenSpace gameplay, but we will not have time to go back and redesign them. This is a risk that cannot be assessed until about week 3 in our initial schedule.

More Related