|Version 15 (modified by hwu, 3 years ago) (diff)|
Prototype Update due 10/4
Goals: Implement dynamic meters that reflect changing money, GDP, and happiness values. Refine pop ups to manage the policies. Implement value system to drive meters.
Completed: Meters and pop ups, still working on fine tuning values system.
The reason we chose to implement these elements is to allow our game to start functioning on a turn by turn basis. Before this, ending a turn called an update function, but the update functions were not implemented. Now basic game responses to player actions are present at the end of turns. This is mainly present in the meters. Now meter values are updated and function as actual indicators of success and not just placeholder images. This is critical to making the game playable, because if nothing ever changes, the game is completely unenjoyable and flat. We refined the policy management pop up system using the simple design from last week (see below) and made it more user friendly. This involved changing colors and highlighting to make the game more intuitive, as well as modifying how the events were handled to fix some bugs. Ultimately fixing this is important because it is the primary user interaction with our game and thus needs to be one of the most polished and functional pieces.
The meter system was implemented such that it displays values held in the map class. These values are updated whenever the player changes his policy or when "economic forces" cause changes in the player's economy. These are quite simplified to be targeted toward middle school students - everything that happens has a clear and direct cause, and every action has clearly illustrated and simple consequences. The meter system displays values using colors (red for low and green for high) and numbers for maximum clarity. We learned that it is very important to have good color coordination and consistency. We did a color revamp of our policy buttons largely to keep things consistent and clear. We discovered this problem when testing the game and discovering that it was non-obvious what certain elements were displaying - such as which policy level was selected. Changing the color system and making good and bad values more obvious should make the game easier to play by middle school students.
The greatest weakness in our code is the merging of different code pieces at this point. With 4 people simultaneously working on the same code we have had a number of conflicts, which are time consuming and lead to bugs. We are working on not stepping on each other's toes, and feel that the code will become more cohesive as the code gets larger. This is mainly because the likelihood of two people working on the same class decreases as more classes are added, especially since we have been very good about keeping class interfaces separate from implementation. We may also break current classes down into smaller classes in the future.
Prototype Update due 9/27
Goals: Create turns and implement policy management tools, organize code
Completed: All of the goals
The reason we choose to implement these elements is to allow our game to begin functioning as the game we want it to look like. Implementing the turn system allows us to work on many of its components independently and test them, such as the map updater and the AI. It gives us the framework to start filling in the game elements. This is essential early on. Furthermore we worked on the policy management tools, which is the interface for users to create and manage policies. There was a great deal of discussion as to how this should function, mainly on how complex it should be. We opted for the less complex interface with the reasoning that middle school students need simple ideas and a simple interface. This interface is important to be able to test policy implementations and user inputs. Ultimately we met both of these goals with a great deal of success. Our assessment was that we completed as much code as we had set out to write for this week and accomplished our goals.
Another priority was organizing code. This was a basic reformatting of our code to be stylistically consistent. This was rather uneventful and was mostly a discussion of how our code should look to maintain consistency. Ultimately our code is inconsistent and poorly commented and a goal for this week was changing that to make it better. This will always be a work in progress. This week we learned the importance of consistent code and testing code before committing it to subversion. We also learned the importance of consistent interface, as it looks and feels awkward when the interface is not consistent.
- prototype_9-27.zip (647.8 KB) - added by pmccormack 4 years ago.
- README.txt (716 bytes) - added by pmccormack 4 years ago.
- main.exe (5.4 MB) - added by slevine 3 years ago.
- README.2.txt (780 bytes) - added by pmccormack 3 years ago.
- econopolis_exe.zip (5.3 MB) - added by pmccormack 3 years ago.
- econopolis-2011-10-11.zip (5.3 MB) - added by pmccormack 3 years ago.