Version 47 (modified by hwu, 4 years ago) (diff)


Tuesday Meeting , September 20th, 2011 at 11:00 AM

Sprague Memorial Center Lab

Attendees: Paul, Stephen, Helen, Colin

Scribe: Helen, Paul


  • Complete Management Plan 9/20
  • Discuss Phase II plan and update goal stack

Postmortem for Phase I

What went right and what went wrong? Did you achieve the goals you had set out? What can you do to avoid similar problems in the future?

Last week

We completed all the deliverables and developed a more extensive prototype than we even thought possible. We created an economic model that will serve as the basis for our alpha release, with a few modifications. Our proposal turned out well, according to our classmates. The game treatment clearly describes the game in a fun video-game-box-like manner, and we hope the prototype animations will turn the middle school students toward our game from the beginning. We accomplished all of the goals itemized in the September 13th notes.

Phase I

In general, we completed all of our deliverables on time. We believe that assigning specific tasks to team members during the Tuesday meeting and setting intermediate deadlines/meetings during the week was the key to our success in completing all our planned goals. Every member contributed highly to the project thus far and we are very pleased with our results.

The beginning of Phase I was met with some confusion in terms of requirements and expectations. We didn't quite understand what the management plan had to include. In addition, we also misunderstood the requirements for the use case documents due to differences between the rubric and the phase I description. However, after talking to the grutors and professors we came to understand these deliverables better. As a result, our management plans are much more organized now. They include a clear goal stack and goal plan with time estimates and assignments. We believe that this also results in much better organization within the team. In addition, we have updated our use cases in our proposal, which are prioritized with rationale. In the future, we will make sure to understand requirements through the rubric and/or communication with the grutors or and professors. We have also started proofreading documents within the group, which will also avoid similar problems.

At the beginning of Phase I, our trac was not completely organized. However, throughout the phase, we have been modifying the trac so that our management plan and deliverables are easy to find and follow. We have also been deciding on the best format for our goal stack. Given that we can always improve our organization, we may further improve our trac to prevent any future organizational problems.

Game design has been a large portion of weekly meeting discussions. Our idea of our game design isn't the same as it was at the beginning of phase I, and the design is always changes. Given our development methodology[agile], we do not think this is a bad thing. We believe that we are constantly determining better ways to design and implement features, while throwing away previous ideas that involved certain weaknesses. However, we do not have an extremely clear design for some elements including AI. These topics may need further discussion during the next phases.

Lastly, we are starting to notice that finding common meeting times during the week is getting harder as the semester progresses. However, this is fine as long as we use our lab time on Tuesday efficiently to create a good management plan for the week.

How good were your predictions on how long the goals would take to achieve?

Last week

In the Sept. 14 notes, we make predictions about how long the goals will take to achieve. The management plan and treatment definitely took the predicted amount of time, but the prototype and proposal both took longer than expected.

The prototype took longer than 4-7 hours for a few reasons. First, Stephen wisely spent a long time (3-4 more hours) developing the button class so that the resource and policy buttons could inherit from it easily. Second, Paul spent an extra 4-5 hours creating the economic model and improving the art. Both tasks were entirely unnecessary at this stage, but both will make our game seem more attractive in the prototype and will make it easier to develop the alpha release in the next few weeks.

The proposal was predicted to take 5 hours. Our estimate was due to believing that many parts of the proposal would be copy and paste. However, our proposal contains a large amount of new content, and therefore took approximately 14 hours combined. In particular, we rewrote the use cases now that we have a better idea of our game. Requirements were similar to ones in previous documents but more rationale and thorough risk analysis/risk mitigation plans are provided. We also revised our technology assessment form the previous version in order to incorporate the grader's comments. Finally, a group effort was made to edit and proofread the proposal.

Although we went over our time estimates for the proposal and prototype, we believe that it is very reasonable. These two documents give us a strong foundation for the rest of our project, and we are glad that we allocated more time to them.

Phase I

Although we estimated approximately 3 hours or less for all week 1 and week 2 deliverables, we didn't explicitly state them in our goal stack. Given that, most of the deliverables in Phase I were completed within time estimates with the exception of the proposal and prototype.

Management Plan Phase II

The initial Phase II management plan will consist of a vague plan outline. Alpha use cases and corresponding high priority goals are identified and put onto the goal stack. Overall Risk Analysis is performed. Management Plan for Week 4 is described thoroughly, but plans for following weeks will be less detailed, but give a feel of the overall plan. These plans will be updated every week in a more detailed manner in the Management Plan Updates.

Alpha Use Cases and Corresponding Goal Plan

The alpha release should "incorporate core architecture and provide a playable experience" (CS 121 Phase II site)

We believe that our Priority 1 and Priority 2 Use Cases from our proposal meet this requirement and are within the Phase II time scope. The prototype has already completed two of the priority 1 Use Cases [Initialize game and Initial trade setup], and has set up the framework for other use cases. Therefore, given our experience with the prototype, we believe that these use cases are feasible for alpha release.

Priority 1 Use cases are defined as absolutely necessary for the player to start the game.

Priority 2 Use cases are defined as essential in achieving primary learning objectives as well as providing initial function to the game.

Use case Priority Status
Initialize game 1 Completed
Initial Trade Setup 1 Completed
Play Game 1 to do
Make Policy 2 to do
Make Tax Policy 2 to do
Meters 2 to do
Hover 2 in progress

Use Cases are detailed in the Proposal. These use cases may be expanded during our architectural designs. However, these are our core use cases and give a good idea of our alpha release.

In order to ensure a functional alpha release, we break up the core use cases into subtasks. Since some subtasks for each use case are more important [e.g. main tasks vs enhancements], we further prioritize these subtasks in the following table. Priority A is the highest, priority C is the lowest. A* are our goals for the next prototype (9/27).

The priority A subtasks will make the game playable and setup a core game architecture. There needs to be a turn mechanism, a way to implement policy, and a way to see the effects of that policy in the meters. Although educational goals may not be reached at this point, completing these subtasks will provide us with a functional prototype and therefore minimizes risk for the alpha release.

The priority B subtasks primarily focus on the educational goals. There should be more info about policies, and the game will allow more specific policies to be enacted.

The priority C subtasks are extra features we could add if we have time. In particular, adding event dialogs, highlighting icons to assist in enacting a policy, and creating meter popups are all not necessary at this point but would improve the quality of the game.

Use Case SubTask Priority Status Time
Play Game create turn mechanism, button A* to do 1-2 hrs
add initial game instructions, tutorial in info box B to do 1 hr
include additional event dialogs C to do 4-5 hrs
Make Policy write instructions in info box for implementing policy A to do 1 hr
highlight appropriate icons when choosing a policy C to do 1 hr
create popup window describing policy details A* to do 1-2 hrs
add adjustable policy components to above window C to do 3-4 hrs
apply generic policy to country or resource A* to do 1 hr
Make Tax Policy (follows directly from Make Policy), determine meters/resource consequences B to do 1 hr
Meters choose concrete level goals for each meter (quantify) A to do 1-2 hrs
implement functions to set meter levels A to do 2-3 hrs
update meters from country stats during turn A to do < 1 hr
Hover provide information about resources/capitols hovered over B to do 1-2 hrs
provide information about buttons hovered over B to do < 1 hr
provide information [includes reason] about meters hovered over C to do 2-4 hrs

Our goals for the tasks are as follows:

Task Priorty Week
A* 4
A 5
B 6
C 8

Week 4 Plan 9/20/2011 to 9/27/2011 [Start Phase II]

Time estimates

1 is highest priority

Deliverable Due Date Time Estimate Priority Mainly Assigned to Reasoning
Management Plan Update 9-22 1-2 hours 1 Helen, Paul Management Plan was discussed in the Tuesday meeting. We still need to write up a goal plan, update our goal stack with respect to Phase II goals, and do risk analysis
1st Architectural Design Draft: Use cases 9-27 0.5 hours 2 Helen Use cases are already outlined in the proposal. However, we might need to expand them a bit, but it shouldn't take much time.
1st Architectural Design Draft: Domain Diagram 9-27 0.5 hours 2 Helen Domain diagram was also already created for the proposal. Again, we may need to reconsider aspects of the design, but it will only take a small amount of time.
1st Architectural Design Draft: Initial Class Diagram 9-27 1-2 hours 2 Stephen New diagram: Depending on how detailed our class diagrams may be this will take approximately 1-2 hours. This may take more time than estimated since we would really like a good basis to build our game on.
1st Architectural Design Draft: Sequence Diagrams 9-27 1 hour 2 Paul Also new diagrams. However, most sequences present in our game are known, but not detailed. Therefore we estimate one hour.
1st Architectural Design Draft: Design Analysis 9-27 1 hours 2 Colin The design analysis will be discussed by everyone during a late week meeting (Sunday or Monday). Writing this document up should take less than 1 hour after the discussion.
Prototype Update 9/27: A* Tasks 9-27 5-8 hours 2 Everyone Our goal for week 4 is to implement A* use cases. These use cases are the higher priority use cases in group A. They are necessary to make the game playable.
Play Game: create turn mechanism, button 9-27 1-2 hours 2.1 somebody
Make Policy: create popup window describing policy details 9-27 1-2 hours 2.2 somebody
Make Policy: apply generic policy to country or resource 9-27 1 hr 2.3 somebody

We split up the Architectural Design Draft among group members. We would like everyone to work on the Prototype this week. This way, people who worked on the proposal last week can familiarize themselves with the code.

Week 5 Plan 9/27/2011 to 10/4/2011

Deliverable Due Date
Management Plan Update 9-27
Second Architectural Design Draft 10-4
Initial UI Design 10-4
User test 10-4 [in class]
Prototype Update 10/4: A Tasks 10-4
Meters: implement functions to set meter levels 10-4 2-3 hrs 2 somebody

Week 6 Plan 10/4/2011 to 10/11/2011

Deliverable Due Date
Management Plan Update 10-4
Architectural Design Review Package 10-6
Design Review 10-11
Final UI Design 10-11
Test Plan 10-11
Prototype Update 10/11: B Tasks 10-11

Week 7 Plan 10/11/2011 to 10/18/2011 Fall break Week

Deliverable Due Date
Management Plan Update 10-11

Week 8 Plan 10/18/2011 to 10/25/2011

Deliverable Due Date
Management Plan Update 10-18
Final Architecture 10-20
Test plan implementation Stage I 10-20
Test plan implementation stage II 10-25
Alpha release Executable: C Tasks 10-25

Week 9 Plan 10/25/2011 to 11/01/2011 [End Phase II]

Deliverable Due Date
Management Plan Update 10-25
Alpha release Class presentation 10-27
Alpha release Documentation 10-27