Game Design Document of Rescue Tom

Intro
Once upon a time, there was a candy factory, which remodeled from a gothic castle by a queen like witch. She punished one of her cleaning robot— Tom for breaking a vase, by spelling him. The spell kept winding him. In such a dangerous castle like factory, full of machines and trick, let’s Rescue Tom by playing this 2D platform game, to help him out as far as you can!
Character bios
Tom is a cleaning winding robot, who works for the candy factory. He has enough tools to help him survive from the factory.
Queen like witch is not that important as she only appear in game title animation.
Jack is a bad boy robot who works together with Tom. He always play trick with Tom. He is a machine repairman.
Rough plot               
Started by Tom being spelled. Then Tom starts his adventure in the castle. During the adventure, he may encounter with Jack and beat him. After he solved the puzzle in the castle, he triggered the switch of the gate and escape. Then he realized he need to remove the spell, so he came back to his old master…
Gameplay description
Core game play is using tool to help Tom avoid injury by the environment or Jack. The tool is listed below:
Magnet—jump higher if there is danger below
Umbrella— avoid injury from upper place
Plunger— if there is danger below but no metal above
Fun— help Tom move lower, but the recharge is slow. Could not always be used (Cancelled)
Fire extinguisher—fly higher or attack player could choose the direction, also, has limitation.
Sometimes player could have multi-solutions when dealing with one danger. So the second gameplay is to collect candy in the factory to earn higher score. Sometimes candy is hidden in secret place.
The third game play is puzzle solving by using the tool, but not sure about the time schedule, so this part could be discuss later.

Artistic style outline
2D style 3D production with strong hand drawing style
 

Systematic breakdown of components
Main menu UI>> start/ opinion/ quit/
In game UI>> score/ tool/ pause/ warning (like sign with”!”)/ U R badly hurt(dead)
Asset breakdown
  Art Assets: Three character/animation: Tom/witch/Jack/
                       Five buttons about the five tools
                       5 tools design
                       Animation when interact with tool and environment
                       Background 1/ background 2 (each level has two background, which means number of level*2 background need to be produced)
                       Environment objects and their animation
                       Title animation
                       Main menu UI/ in-game UI
       
  Text: five tutorial of five different tools/ dialogue between Tom and Jack/ dialogue between witch and Tom
  Sound Assets: sound FX of five different tools, UI/HUD feedback sound/music in different level/ sound effect in different level/ voice of Jack/ Jack come sound effect
  FX: collection candy/ interaction with environment/ tools/ Tom/ Jack
(each part may have more than one FX, will be listed in work sheet too)

Further description about character design/animation/sound/ will listed in working sheet and upload next week!

Suggested Game Flow Diagram
Start Animation (could skip)>> main menu >> start game>> level together with tutorial and tips>>End game (check the score)>>leave or restart
It is good if there is an option menu in the main menu, which allow users chose UI for left header or right header.
Suggested Project Timeline
Since we have maybe 8 weeks to build the prototype. So below is the suggested timeline:
Week 1 character design
Week 2 environment objects documentation writing and production
Week 3 environment objects production
Week 4 engine test with the produced object & level plan
Week 5 UI and particles production & level plan
Week 6 left element check and first level end
Week 7 level design & feedback
Week 8 final refine.
Additional Ideas and Possibilities
I want to check this kind of interaction fun enough to turn the game into an endless score-earning game.  It is great to build random level. But as lack of programmer, I think at the beginning, we should try if the mode is interesting by hand building some level. After the prototyping, we may find out further clue. 


No comments:

Post a Comment