CS190 Top Level Design for SimsU by Ning Ge (nige) 1. Overview This document contains top-level design for SimsU, a strip-down conbination of The Sims and simcity. It is derived from the specification document written by Richard Hsieh. 2. Levelized high-level component diagram(s) and description of components; ----------------- ------------- | Graphics |--------| Animation | ----------------- ------------- | ----------------- | UI | ----------------- | | -------------------------------- | Logic | | Management Character | | | -------------------------------- | | | | ------------ ------------- | FILE I/O | | Sound | ------------ ------------- ------------- | Art Work | ------------- 2.1 Logic Logic controls the game cycles. It takes input from player, and come up with results of the decisions the player makes. Logic is the center of the game. It calls methods in UI to display changes in the game, it calls Sound component to play sound/music at certain time, and it calls File I/O to save/load a game file. Besides all these funcationalities, Logic has two major components: management component and character component. Management component handles inputs that could change the operational condition of the university, such as building certain buildings, hiring professors in certain fields, student enrollment and funding. The character component handles the following things: Determines interaction between people in the game based on their personality ratings Controls how player reacts to certain actions Contols actions characters take based on schedules set by player or default(automatically generated actions based on their personality) Determines player's action(walking) and avoid collision 2.2 User Interface User Interface displays the game playing process and receive inputs mainly by mouse clicks on graphical iconic menu on main map screen. By clicking on people or buildings in game, certain information or options will show up. User Interface gets input from the logic and displays information on the main map screen reflecting changes in the game. 2.3 Graphics Graphics contains the top-down view of the campus using an tile-vased map. It gets from UI and displays on the map. Graphics interface allows player to manipulate buildings, people and the map, it also offers menu support to help the user set up the game. 2.4 Animation Animation component animates buildings to show activity going on inside of them, and animates people to have gestures, walking/running around campus. 2.5 File I/O File I/O handles loading/saving game files. The formatted game file contains all the information of the current game. When saving a game, File I/O component will write/overwrite a game file with formatted information. When loading a game, a parser will parse the game file to retrieve information and send it back to Logic component. 2.6 Sound Sound component is responsible for playing music/sound specified by Logic. 2.7 Art Work Art work component is responsible for drawing buildings, characters for the game. 3) external dependencies; There are not obvious dependencies. Sound libraries are needed for the game, but it should not cause a major problem. The operating system has to support 3D graphics. 4) task breakdown; 4.1 Project Manager (number of people 1) The project manager is responsible for finalizing all designs, approve any changes made during the coding process. Project manager should keep track of the progress of the program and make sure everything run smoothly and according to schedule. Project manager should be an experienced coder who has great interest in this project and who is familiar with problems or difficulties involved in this project. Project manager makes sure that goals are achieved within deadlines and maintains the group's spirit. 4.2 Librarian (number of people 1) Librarian is responsible for keep track of all the documents and design diagrams throughout the process, including all the changes that have been made on component designs. Librarian is also responsible for writing the user manual of this game. 4.3 Tester and Debugger (number of people 1) Tester and Debugger will have to stay in touch with all the coders and keep track of the progess of each part of the project. Once a component is done, or partially done, tester should starting writing test programs/interfaces to test and debug this component. Thus tester has to be familiar with the whole program. After final integration, tester is responsible for testing and debugging the whole program. 4.4 Coder (number of people 7) Coders are each responsible for coding certain component of the program. Coders are responsible for their part of the design and they should inform the project leader and the librarian if there is any changes. Once the component is partially done, coder has to work closely with tester to test and debug their components. 5. Group organization; Project Manager: Richard Hsieh Librarian: Louisa Rosenheck Tester and Debugger: Michelle Lin Coder: Bernard Peng, Andrew Hull, Ning Ge, Mark Humphrey, Ian Tang, Dan Shue, Heather Yazawa 6. Schedule; 3/3 - -select one top-level design -assign individual responsibility within group -work on Final Design Document 3/10 -finalize design -librarian keep track of all top-level design revisions 3/15 -individual interface proposals -librarian should keep track of all documents 3/17 -interface comments -librarian should keep track of all documents 3/21 -final interface Final interface has to be approved by Project leader and librarian. Tester should go through all interfaces. 3/22-3/30 break 4/2 -component designs Component designs have to be approved by both Project manager and librarian. Tester should go over it as well. -librarian should keep track of all documents 4/7 - 4/16 Coding -project manager should make sure everything is on schedule 4/16 -base should be done -initial integration -librarian should keep track of any changes made 4/21 -tester should have tested and fixed most bugs together with coder -implement extended features -all design document should be collected 4/28 -finalize functionality -system fully integrated -user manual finalized -tester and coder should keep testing and debugging 5/9 -final demo -handin all documentation 6 Assumptions you made about specifications that were not clear from the specifications doc. 6.1 It's not exactly clear from the specifications that if this game is a network game or a stand-alone game. It is assumed here that it's a stand-alone for 1 player. 6.2 It's not clear in the component explaination how Graphics component interact with other components. It is assumed here that graphics component is the main game map. 6.3 How File I/O is handled is not specified in the specifications. It's assumed here that game files are in text file format.