# Changeset 709

Ignore:
Timestamp:
05/04/2012 12:30:42 PM (3 years ago)
Message:

Updated documentation

Location:
releases/v1/doc
Files:
2 edited

### Legend:

Unmodified
 r703 \item The game must have a clear and simple storyline that leads towards a specific end goal. This will motivate students to complete the game, ensuring that the educational goal is achieved. \status{Met} \item All buttons in the game should be clearly labeled and fully functional. There must be no ambiguity or nonoperational buttons, as this would severely hamper the user's experience with the game. Any incomplete or broken features would discourage students from completing the game, which would not allow them to learn all that the game could teach them. \status{Met} \item The text in the game must be simple and aimed at the middle school students for which the game has been created. The reading level for the bulk of the text must therefore be no higher than second or third grade, and any text that is more complex must not be integral to the basic learning objectives or playability of the game. \status{Met} \item The text in the game must be simple and aimed at the middle school students for which the game has been created. The reading level for the bulk of the text must therefore be no higher than second or third grade, and any text that is more complex must not be integral to the basic learning objectives or playability of the game. \status{Pending} \item The game must be able to be played in its entirety without crashing or stopping for any reason. Any significant bugs that prevent completing the game interfere with the learning objective. \status{Met} \item The player must be able to save their progress and then resume their play. This will ensure that a player can complete the game, even if it takes longer than a single class period. It also allows the player to try a couple of decisions and then revert to a saved checkpoint if they determine that they want to undo certain decisions. \status{Met} \subsubsection*{Game Logic and Calculations} Throughout the game, progress is measured in the form of 5 resources: money, food, power, material and pollution. Each decision the player makes might affect any subset of these. When a player goes to build a piece of technology, they must first have a sufficient amount of resources to pay for the item's one-time cost. If purchased, these costs will be deducted from the player's resources. However, as many technologies have lasting effects, items also have on-going costs, which might differ from the one-time costs, that are charged each turn. However, these might also be benefits, such as a windmill's production of energy. \\ \\ In addition to resources, there are other thresholds that are required to purchase a item. For one, some items require having already purchases some other items. This requirement is in place to both reflect the reality of interdependence between technologies, as well as prevent players from finding shortcuts that bypass the essence of the game. Furthermore, buildings require a certain amount of research has been conducted. Thus a player can choose to perform research on a given turn in order to further advance development in that field and make new technologies available, as well as improve the resource-use of that field in general. This element of the game was added to convey the important development that is essential in producing new technologies.\\ \\ In addition to resources, there are other thresholds that are required to purchase a item. For one, some items require having already purchases some other items. This requirement is in place to both reflect the reality of interdependence between technologies, as well as prevent players from finding shortcuts that bypass the essence of the game. Furthermore, some buildings require that a certain amount of research has been conducted. Thus, a player can choose to perform research on a given turn in order to further advance development in that field and make new technologies available, as well as improve the resource-use of that field in general. This element of the game was added to convey the important development that is essential in producing new technologies.\\ \\ Some events triggered throughout the game after each turn affect the player's resources. For instance, if an excessive amount of transportation introduces invasive species, the player's food supply drops.\\ \\ Thus resource management is at the heart of both game logic and the player's strategy. They provide a quantity metric for both progress and an item's affect on society. Of course, these purely numeric indicators work in tandem the more visceral elements, such as events, alien feedback and events. \\ \\ Thus, resource management is at the heart of both game logic and the player's strategy. They provide a quantity metric for both progress and an item's affect on society. Of course, these purely numeric indicators work in tandem the more visceral elements, such as alien feedback and events. \\ \\ Alien feedback is determined by the items in their proximity. Nondeterministically, aliens respond either positively or negatively to their surroundings in order to convey the various perspectives an entire society might feel toward certain technologies. Additionally, feedback is given for each resource the player manages, with suggestions about ways to improve it, by either new purchasing or removing existing ones. All this feedback is produced dynamically based on the current state of the game. This keeps the game both interesting and as informative and educational as possible, by adapting feedback to the player's choices throughout the game. The screen layout emphasizes consistency as well as engagement with the alien planet. As seen in Figure (XX), the main screen has a metallic frame that contains the essential buttons a player needs to interact with throughout the game. Except for scenes, this frame is always present and thus achieves a consistent user interface design that the user quickly becomes familiar with and used to. The toolbar is sleek and has only the essential elements, while menus that stem off of it allow the player to access all the elements of the game. Likewise, the player's resources are visible in the upper right hand corner and thus provide a clear reminder of the need to manage them responsibly.\\ \\ The landscape occupies most of the screen. This is to provide the greatest amount of engagement with the alien planet for the players, both in seeing the terrain and interacting with the aliens. It also occupies most of the screen in order to convey a nearly first person experience.\\ \\ The game supports hover events, which allow brief descriptions of the various graphical elements to be displayed instantly. The following are all types of information conveyed through the various hoverable elements: explanations of what a button does, an item's description, suggestions for how to improve a particular resource and reminders of the long-term goal. The game supports hover events, which allow brief descriptions of the various graphical elements to be displayed instantly. The following are all types of information conveyed through the various hoverable elements: explanations of what a button does, an item's description, suggestions for how to improve a particular resource, and reminders of the long-term goal. \section*{Game Design -- Backend} \subsection*{Implementation} \section*{Testing} Testing was done at all levels of development. Testing was implemented in three different ways: regression tests of the game logic, black box tests of the front end and user tests of the gameplay. These tests in tandem created a comprehensive means of evaluating, and ultimately improving, our game. Detailed descriptions as well as the results of each individual test can be found in the Test Report. Testing was done at all levels of development. Testing was implemented in three different ways: regression tests of the game logic, black box tests of the front end, and user tests of the gameplay. These tests in tandem created a comprehensive means of evaluating, and ultimately improving, our game. Detailed descriptions as well as the results of each individual test can be found in the Test Report. \subsection*{Regression Tests} Regression tests were white box tests that tested the various components of the game logic. They were implemented as Python scripts using the \verb+unittest+ library, allowing us to automate and streamline the testing process. In particular, these scripts tested that calculations were correctly made in the classes that retain the player's game data. Among the things tested were whether a player's resources updated correctly, whether heuristics for events were triggered appropriately and if suggestions made to the player based on their progress were appropriate and as expected. Testing these aspects of the game was essential because it ensured the accuracy of the game logic and that a player's progress was correctly updated and evaluated with each decision they make. Any errors in such would have interfered with both the enjoyment of the game as well as undermine the learning objective. Moreover, it was critical that these be regression tests so that as new features were added, we would be able to quickly and rigorously gauge whether the game logic remained correct. Ensuring that all of these tests worked at every stage of develop was thus one means of assessing the correctness of our solution. Regression tests were white box tests that tested the various components of the game logic. They were implemented as Python scripts using the \verb+unittest+ library, allowing us to automate and streamline the testing process. In particular, these scripts tested that calculations were correctly made in the classes that retain the player's game data. Among the things tested were whether a player's resources updated correctly, whether heuristics for events were triggered appropriately, and if suggestions made to the player based on their progress were appropriate and as expected. Testing these aspects of the game was essential because it ensured the accuracy of the game logic and that a player's progress was correctly updated and evaluated with each decision they make. Any errors in such would have interfered with both the enjoyment of the game as well as undermine the learning objective. Moreover, it was critical that these be regression tests so that as new features were added, we would be able to quickly and rigorously gauge whether the game logic remained correct. Ensuring that all of these tests worked at every stage of develop was thus one means of assessing the correctness of our solution. \subsection*{Black Box Tests} Black box testing of the interface simulated the interaction a player would have with our game. These tests were used throughout to identify bugs in the GUI, as well as assess the game's performance. We performed both stress and endurance tests for the game's graphical elements. The stress tests attempted to expose bugs or mistakes in the design by using the game elements and windows against their intended purpose. Thus these tests looked for proper error handling for certain types of user input, as well as the general functionality of all the buttons and window elements. Endurance tests ensured that the program could withstand extending periods of use, by using the game for 10 to 20 minutes at a time. Lastly, we assessed the performance of the program by using Python's \verb+cProfile+ library to determine what parts of the program were inefficient and accounting for a lot of the processing time. This process enabled us to greatly reduce the running time of the program by optimizing the amount of rendering, image resizing, as well as internal window updating. Passing and performing well was deemed essential to verifying the quality of the game produced. Black box testing of the interface simulated the interaction a player would have with our game. These tests were used throughout to identify bugs in the GUI, as well as assess the game's performance. We performed both stress and endurance tests for the game's graphical elements. The stress tests attempted to expose bugs or mistakes in the design by using the game elements and windows against their intended purpose. Thus, these tests looked for proper error handling for certain types of user input, as well as the general functionality of all the buttons and window elements. Endurance tests ensured that the program could withstand extending periods of use, by using the game for 10 to 20 minutes at a time. Lastly, we assessed the performance of the program by using Python's \verb+cProfile+ library to determine what parts of the program were inefficient and accounting for a lot of the processing time. This process enabled us to greatly reduce the running time of the program by optimizing the amount of rendering, image resizing, as well as internal window updating. Passing and performing well was deemed essential to verifying the quality of the game produced. \subsection*{User Tests} User tests were conducted on three occasions. The first was done on an initial user interface design that reflected the intended model of our game. The second and third instances were done using the Alpha release and a pre-Beta release. The purpose of these tests were to gather feedback on how intuitive the design was, how the clear the goals were and solicit any other feedback an outside user would offer for the game. The UI testing was conducted with middle school students and thus gave us an indication of what was clear and unclear about the layout of the window and the general gameplay. The subsequent tests were effective at determining what was confusing or vague in the overall game structure, as well as identifying areas for improvement, along with bugs. Users were given high-level instructions and had to navigate the interface to determine how to accomplish each task. While we did not have the opportunity to test the final result with students and thus accurately assess whether we accommodated the feedback suggested throughout, all the feedback was indeed evaluated and handled in a manner intended to satisfy the most number of users. The layout and gameplay underwent many revisions as a result of this feedback. \section*{Results} \subsection*{Lessons} There were many lessons that we learned throughout this process, ranging from insights on user interfaces, to large software design to facts about technology. In addition to simply learning the importance of user testing, such an endeavor demonstrated how easy it is for the developers and people familiar with the game to perceive the game much differently, and perhaps understand it more, than most users would. It is easy for a designer to become too familiar with their own work and sample users provide an abundance of insightful observations that would be otherwise overlooked. Thus we learned to appreciate the value of the outsider perspective to offer fresh ideas and feedback. Moreover, we learned that user interfaces should aim for simplicity and elegance. Clarity is essential and something our solution did not emphasize at first. Realizing the importance of these qualities in interface design significantly impacted our entire visual layout and was some of the invaluable feedback received from users.\\ \\ One of the most influential lessons learned through the process was about extensible program design. After designing our alpha prototype, we resorted to almost entirely scrapped out framework and starting over. This opportunity allowed us to fully assess and critique the architecture we had been using and design an entirely new framework that would resolve and address those issues. In particular, our previous model was not conducive to adding new features. Each added element need to be properly linked and integrated in nearly all other components. By better encapsulating and separating the game logic and graphical elements, as well as demonstrating design principles through techniques like inheritance, we created a much more effective and efficient architecture that once in place supported many additions and modifications to the actual gameplay. Moreover, by continually abstracting out information through refactoring and relying on data files to provide much of the game content, adding features became a simple task, which allowed for streamlined development.\\ \\ There were many lessons that we learned throughout this process, ranging from insights on user interfaces, to large software design and facts about technology. In addition to simply learning the importance of user testing, such an endeavor demonstrated how easy it is for the developers and people familiar with the game to perceive the game much differently, and perhaps understand it more, than most users would. It is easy for a designer to become too familiar with their own work and sample users provide an abundance of insightful observations that would be otherwise overlooked. Thus, we learned to appreciate the value of the outsider perspective to offer fresh ideas and feedback. Moreover, we learned that user interfaces should aim for simplicity and elegance. Clarity is essential and something our solution did not emphasize at first. Realizing the importance of these qualities in interface design significantly impacted our entire visual layout and was some of the invaluable feedback received from users.\\ \\ One of the most influential lessons learned through the process was about extensible program design. After designing our alpha prototype, we resorted to almost entirely scrapped out framework and starting over. This opportunity allowed us to fully assess and critique the architecture we had been using and design an entirely new framework that would resolve and address those issues. In particular, our previous model was not conducive to adding new features. Each added element needed to be properly linked and integrated in nearly all other components. By better encapsulating and separating the game logic and graphical elements, as well as demonstrating design principles through techniques like inheritance, we created a much more effective and efficient architecture that, once in place, supported many additions and modifications to the actual gameplay. Moreover, by continually abstracting out information through refactoring and relying on data files to provide much of the game content, adding features became a simple task, which allowed for streamlined development.\\ \\ Lastly, we ourselves learned much about technology. In particular, certain technologies logically depend on others while some are independent. Moreover, we had to cursory research in the different effects technology has on aspects of communities and the environment in reality. Having done so, we also learned that many players are quick to understand these dynamics between technology and society in the context of a game, but perhaps might not think about it as much in the real world. Thus by instilling this information and our message in the realm of a computer game, we provide an effective means of reaching the player and conveying the learning objective. This demonstrated to us that a game can significantly affect the way the its content and message is perceived because of the context it is presented in and based off of the effectiveness of the game itself. \subsection*{Final Deliverables} The final submission includes the game directory along with a user guide that features installation instructions, game instructions, a chart demonstrating the features of the buildable items, as well as a troubleshooting and known bugs section. These are indeed all the tangible deliverables promised in the original proposal.\\ \\ While we believe all the functional requirements enumerated at the onset of the project (and included above in the Requirements and Analysis section), we believe certain requirements could be better met. In particular, we believe we have not fully optimized the actual values of item costs, heuristic triggers and resource allocation. As a result, while it is possible for a player to make bad'' decisions throughout the game and still win (which was the explicitly stated requirement) we feel it is nevertheless important that these values be both realistic and not such that the game becomes too challenging. Although considerably effort was made to test the difficulty of the game and the effectiveness of the values chosen, we believe this could have been performed in a more rigorous way than trial and error. In particular, future work would have entailed designed a framework to test these values (perhaps using a genetic algorithm) to find an optimal values for the various stats. The importance of doing so is that these values ultimately reflect the message we communicate to the users regarding the difficult technologies and thus they should be well-founded and meaningful. However, we consider the solution offered in our game sufficient for its intended use. Moreover, as this was prioritized as only the 10\textsuperscript{th} Functional Requirement, we consider such incompleteness acceptable. \\ \\ While we believe all the functional requirements enumerated at the onset of the project (and included above in the Requirements and Analysis section) were achieved, we believe certain requirements could be better met. In particular, we believe we have not fully optimized the actual values of item costs, heuristic triggers and resource allocation. As a result, while it is possible for a player to make bad'' decisions throughout the game and still win (which was the explicitly stated requirement) we feel it is nevertheless important that these values be both realistic and not such that the game becomes too challenging. Although considerably effort was made to test the difficulty of the game and the effectiveness of the values chosen, we believe this could have been performed in a more rigorous way than trial and error. In particular, future work would have entailed designed a framework to test these values (perhaps using a genetic algorithm) to find an optimal values for the various stats. The importance of doing so is that these values ultimately reflect the message we communicate to the users regarding the difficult technologies and thus they should be well-founded and meaningful. However, we consider the solution offered in our game sufficient for its intended use. Moreover, as this was prioritized as only the 10\textsuperscript{th} Functional Requirement, we consider such incompleteness acceptable. \\ \\ Regarding our non-functional requirements, we feel two areas would have benefitted from improvement, though, again, they were achieved in some form in our final result. The first of which is the consistency of the game artwork. While we continuously updated our artwork and general game aesthetics throughout development, we feel the game would still benefit from further improvement. In particular, we relied primarily on vector graphics libraries which were useful but sometimes do not mesh well across different libraries. Thus the ideal for future work would be to develop artwork from scratch that would appear homogeneously and mesh well together. Moreover, this would resolve some issues of image perspectives which are not always consistent, for instance, with the buildings on the landscapes.\\ \\ Lastly, while we believe we have achieved it, we have not had a reliable means of testing the ease of playing in our final result. We were unable to conduct user testings on our final result and thus cannot accurately gauge how effective our development was in addressing previous concerns raised. Thus, while we made every effort to ensure the game was intuitive and easy to learn, we are unable to conclude such simply by our own observation. Rather, future work should pursue conducting thorough user testings to evaluate whether this requirement was indeed achieved---something we ourselves inherently cannot determine.