Implementation Process

In this project, the instructor tried to let us experience what it is like to work on a software project over a short time frame and it is a mockup of industry software development. We used Agil development system and CASE tools based on JIRA. Jira is linked to document creation tools, a git repository and a chat system. We used Slack as a chat tool.
*All our project work, deliverables and communications were fully documented on these tools, and unfortunately I do not have access to them now. The biggest problem we faced was everyone pictured the game idea differently in their own minds. As the lead artist, I had to change the entire art style of the game in the implementation process because of the design of using the game engine to create a 2.5D game instead of a 2D game.

Design Goals

• Performance
• Response time: Ideally, the program should respond to the user immediately or as soon as possible so that the player can have a great game experience. However, it might take some time to load the game.
• Throughput: The system should complete basic movement, compute enter and exit of tubes, counting how many times left, score the collection player has earned, and determine whether the player has reached the destination at the same time.
• Memory: Player, tubes, maps, and time counter need separate memory space. Moreover, since the game has a saving function. The levels that the player has completed and the scores should be stored so that the next time the player enters the game, they can start from where they left off.
• Dependability
• Robustness: All input despite “W A S D” and mouse clicking on the menu are recognized as invaild input, which will not have any movement regard on the player.
• Reliability: “W A S D” is used to perform movement of the player. Mouse licking is used to interact with menus. All other behaviours will not be considered as valid behaviours from players, which will not be take from the system.
• Availability: Before the game actually begins, tasks are considered to complete the functions associated with the menu list. Within the game, system should go through the algorithms inside the game. Therefore, the time percentage depends on how long users would stay on the menu page and game running, but normal tasks should always be completed as long as the program is running.
• Fault Tolerance: All valid inputs should not be taken, system should report in an error box message when any unexpected crash occurs.
• Security: Unreal engine has been used to build the graphic, it should be safe enough for a game. Saving data has no need to be encrypted as it rarely leads to the crash of a game.
• Safety: The players will not be hurt in our video game even if there are errors or failures.
• Cost - Since we do not have any sponsors or investors, we do not have any cost except our time and effort.
  • Development Cost: Class, levels, methods should be implemented. Game graphics will be implemented by unreal engine.
  • Deployment Cost: Unreal engine is free for making non-profit games, so there is no cost for installation.
  • Upgrade Cost: Updates associated with class, levels, methods are considered to be high cost, while changing in GUI and graphic model are comparably low.
  • Maintenance Cost: Reporting error message is an approach to monitor buges and keep maintenance. Error or crash could be detected, located, and fixed by specific detailed error report.
• Maintenance
  • Extensibility: Each class of the system should be separated. Characters and tubes will have their own class, hence it should be easy to append new functionality/new classes to the system. For example, if developers want to set a new enemy instance to our game, an enemy class can be created and then link the class to our main game object class.
  • Modifiability: It should not be hard to change functionality of our game. We can just go to the class that we want to modify and edit the code.
  • Adaptability: This program only aims to present as a video game..
  • Portability: This program only aims to run on Windows operating system.
  • Readability: Comments should be added at every class, function ,method, and levels. Since classes, levels, main are written separately, coding should not be difficult to understand,
  • Traceability of Requirements: Methods and functions’ name should be specified regarding their purpose, in order to acknowledge the use of a certain function.
• End User Criteria
  • Utility: The system is simply used to perform a video game to public view.
  • Usability: The users should be able to easily understand how to play the game, since the difficulty of understanding this game is considerably low. Public would easily gain the purpose of this program.

Division of Work:

• David - programming the haskell system, including health parameters, the character, and the movable enemy
• Divay - menu system and help organized Bitbucket
• Marcus - lead modeler in Blender, creating pipes and collisions
• Zimo - lead artist, creating pipes and helping with demo level layout
• Cheng - key and door systems, try to fix bugs
• Fiona - lead for Jira, and find sound effects

Your software must have a GUI or web-browser interface. It can run on a PC, a Mac or a portable device (or all of the above).

Written Code