Evaluation
Achievements - MoSCoW List
| ID | DESCRIPTION | PRIORITY | STATE | CONTRIBUTORS |
|---|---|---|---|---|
| 1 | The game should be visually engaging for the children | Must | All | |
| 2 | There must be tutorials throughout the game to effectively guide the children | Must | All | |
| 3 | The game must not be overstimulating | Must | All | |
| 4 | Each part of the game must be adapted to 2 players | Must | All | |
| 5 | The children need to be able to play using MotionInput OR keyboard controls | Must | All | |
| 6 | The MotionInput actions required will be clear and intuitive | Must | All | |
| 7 | Clear interface: someone with little to no technical experience can set up and navigate | Must | All | |
| 8 | Must work on a Windows computer | Must | All | |
| 9 | Game will have physically stimulating components | Should | All | |
| 10 | There should be a high replay-ability aspect | Should | All | |
| 11 | The children shouldn't need to complete all the games and have the freedom to try out the various features in their own time | Should | All | |
| 12 | Background music to add to the magical atmosphere | Should | All | |
| 13 | System will have maintainable code for future modifications/additions and updates | Should | All | |
| 14 | Game should run on at least 30fps even on low-end computers to ensure it's playable | Should | All | |
| 15 | Contain a sort of reward system for each game, whether it's a prize or acknowledgement of your progress | Could | All | |
| 16 | Animals throughout the game | Could | All | |
| 17 | Crafting aspects within a game | Could | Victoria | |
| 18 | Font size adaptability | Could | All | |
| 19 | Include a colourblind-friendly mode (or modes), offering alternative colour schemes that are distinguishable for individuals with different types of colour blindness | Could | All | |
| 20 | Scoreboard | Won't | ||
| 21 | Academic components e.g. mathematics and chemistry | Won't | ||
| 22 | There will be no login functions which will keep track of each new player | Won't | ||
| Key Functionalities: | 100% | |||
| Optional Functionalities: | 95% | |||
List of Known Bugs
| ID | DESCRIPTION | PRIORITY |
|---|---|---|
| 1 | Game UI will display weirdly with monitor that does not have an aspect ratio of 16:9 or 21:9. | Medium |
| 2 | Character camera in exploration will be inverted if the player moves the camera to the bottom-most position and look up. | Medium |
| 3 | There is a very rare chance of MotionInput mode not changing when switching games. It occurs when the game is running at a very low frame rate or the game is not focused. We suggest not to switch the other windows when loading between games or scenes to decrease the chance of this occurring. | Low |
| 4 | Upon MotionInput mode switching, the game window is not focused and has to be manually focused. This is due to Windows API restriction that a unfocused window cannot grab focus from focused window. | Low |
Individual Contribution Table
System Artefact Contribution
| DESCRIPTION | VICTORIA | THADDEUS | SAMSON | MOHAMED |
|---|---|---|---|---|
| Research and Experiments | 28% | 26% | 22% | 24% |
| UI Design | 25% | 25% | 25% | 25% |
| Coding | 22% | 26% | 26% | 26% |
| Testing | 25% | 23% | 27% | 25% |
| Overall Contribution | 25% | 25% | 25% | 25% |
Website Report Contribution
| DESCRIPTION | VICTORIA | THADDEUS | SAMSON | MOHAMED |
|---|---|---|---|---|
| Website Template and Setup | 15% | 40% | 20% | 25% |
| Home | 20% | 40% | 20% | 20% |
| Video | 40% | 40% | 10% | 10% |
| Requirement | 50% | 20% | 15% | 15% |
| Research | 20% | 40% | 20% | 20% |
| UI Design | 50% | 20% | 15% | 15% |
| System Design | 15% | 45% | 20% | 20% |
| Implementation | 15% | 15% | 55% | 15% |
| Testing | 35% | 35% | 15% | 15% |
| Evaluation and Future Work | 15% | 40% | 20% | 25% |
| User and Deployment Manuals | 15% | 15% | 20% | 50% |
| Legal Issues | 15% | 15% | 20% | 50% |
| Blog and Monthly Video | 20% | 30% | 10% | 40% |
| Overall Contribution | 25% | 25% | 25% | 25% |
Critical Evaluation
User Experience
Throughout the development of the game, we kept in mind the user experience as this is a particularly sensitive point for our target users: children with autism. We had to ensure that they are not overstimulated by either their auditory or visual senses, while still giving them a visually appealing game. Our project was often praised for its stunning visuals. We have also provided interactive tutorials for each game to ensure that the players know how to play the game.
We rate ourselves Very Good for User Experience.
Functionality
Our game works as intended. Players are able to roam and enjoy a magical forest, while engaging numerous mini-games along the way.
We have fulfilled all the key requirements discussed with our client regarding functionality: a game that children with autism can play alongside their friends, exploring a forest and playing various puzzles/games along the way.
We rate ourselves Very Good for Functionality.
Stability
This is an area in which our project struggles with. When using MotionInput as the input option, the player might face some problems with stability. One of the existing known bugs is that tabbing in and out of the game might cause issues due to the drop in frame rates. This can cause the MotionInput to fail to switch modes when transitioning between games.
Another issue with stability is that the game UI will become glitchy when the monitor is not using an aspect ratio of 16:9 or 21:9.
We rate ourselves Adequate for Stability. We would like to have resolved the problem with the stability of the game UI on different aspect ratios had we had more time.
Efficiency
Efficiency was a key concern of this project as our clients typically have lower-end computers, and hence we had to make sure that the game we develop is efficient and can run on them. However, we also needed to provide an aesthetically pleasing game which led us to have to thread a fine line between performance and graphic quality.
One means we used to improve efficiency was to use FOD (Foreign Object Debris) which helps with rendering details more efficiently. It also include level-of-detail (LOD) systems which would fade out details past certain distances to maintain and improve performance.
We rate ourselves Good for Efficiency. Since we had to maintain good graphics quality, we sacrificed some performance to provide a more visually appealing game.
Compatibility
Our game can only be played on systems with the Windows Operating System currently. Currently, the main factor preventing the game from being able to be run on other systems is MotionInput which can only run on Windows.
We rate ourselves Good for Compatibility.
Maintainability
The code base is split into independent games, making it easier to find the necessary files and reducing the number of files that have to be looked through during maintenance. Each of our games has various scripts that have specific purposes and responsibilities, which should alleviate finding the necessary parts under scrutiny for maintenance.
However, one flaw is that we did not include much documentation in the code base to describe what each method does.
We rate ourselves Good for Maintainability.
Project Management
As a team, we managed the project well. We planned our time out for the project duration by making a GANTT chart using Jira. This helped us with our time management and ensured we were on the right track and meeting deadlines. We also used Unity Version Control in order to collaboratively work on the project. Our team met on a weekly basis with 2 hour meetings each time to discuss our progress and what were the next steps moving forward.
During the development of our game, we decided to make each game a separate scene so that we could make each game independent of one another. This would make integration simpler, while also decoupling the games - ensuring that each game does not affect another.
We rate ourselves Very Good for Project Management.
Future Works
Bug Fixing: Fix all the current known bugs as listed in the list of bugs section.
MotionInput Multiplayer Capability: Currently, players are unable to play together simultaneously when using MotionInput as it is unable to handle more than one player's movements. In the future, we could work with MotionInput to implement a solution.
Cross-Platform Compatibility: We can look into making our game available on other Operating Systems such as Mac and also other devices such as mobile devices too.
Create Winter Season: Creating a Winter season would create a significantly different aesthetic from the current Spring and Autumn seasons. Some children could like the Winter aesthetic more.
Procedural Map Generation: We currently have static maps for exploration, golf and racing. In the future, we could create procedurally generate the maps for each of these games. This would create unique and new maps each time, preventing players from getting bored of the same maps.
Documentation: We can add more documentation throughout our code base to make it easier for our team and possible predecessors who might continue the project.