Hardware Requirements
- PC equipped with mouse and keyboard
- Minimum system requirement of:
- OS: Windows 10 / MacOS Catalina
- Processor: Intel Core i5 / Ryzen 5
- Memory: 8 GB RAM
- Graphics: GeForce GTX 660 / Radeon R9 270
- Storage: 4 GB available space
- Sound Card: DirectX compatible
Infrastructure
Assets and other files are sorted into the following category folders: World, Objects, Entities, Interface, Audio, and System.
Asset filenames are presented in the format “TYPE_OWNER(_SUBTYPE)_DATA(_SUBTYPE)”, meaning that the first word is the overall asset type (a logic system, an entity, a voice line), the middle word or two words describe what the asset does or what uses it (a navigation algorithm, a specific character, a set of greetings), and the last word or two words identify the type of data it is (a script, a 3d model, a sound file).
For example: “mob_sheep_white_tex_diffuse” refers to the diffuse texture of the white sub-type of a sheep in the "mob" (mobile entity/creature) type. Type tags may be more specific than the main categories to which they belong; for instance, the Entities folder contains "CHAR", "MOB", and "ENT" types, referring to humanoid characters, creatures, and non-living mobile entities respectively.
Scripts belonging to entities go inside the sub-directory of that entity, as do the model and texture files and any other data.
- World contains the terrain and scenery data for each level as well as level-specific controllers and triggers.
- Objects contains items and objects that don't move, such as scenery props and collectibles.
- Entities contains mobile entities such as characters, creatures, projectiles, and vehicles.
- Interface contains graphics and behaviours for GUI/HUD including menu screens and inventory.
- Audio contains all the audio, including sound effects and dialogue.
- System contains global scripts and logic as well as miscellaneous features.
Asset filenames are presented in the format “TYPE_OWNER(_SUBTYPE)_DATA(_SUBTYPE)”, meaning that the first word is the overall asset type (a logic system, an entity, a voice line), the middle word or two words describe what the asset does or what uses it (a navigation algorithm, a specific character, a set of greetings), and the last word or two words identify the type of data it is (a script, a 3d model, a sound file).
For example: “mob_sheep_white_tex_diffuse” refers to the diffuse texture of the white sub-type of a sheep in the "mob" (mobile entity/creature) type. Type tags may be more specific than the main categories to which they belong; for instance, the Entities folder contains "CHAR", "MOB", and "ENT" types, referring to humanoid characters, creatures, and non-living mobile entities respectively.
Scripts belonging to entities go inside the sub-directory of that entity, as do the model and texture files and any other data.
Game Engine
The game engine the team have agreed to use is Unity. This is because all team members have had prior experience with this game engine. It is also widely used and therefore a vast amount of information and solutions can be easily found on perhaps, online forums, if we were to encounter any critical errors during the development process. Unity is also considered rather easy to use in comparison to many other game engines, and therefore will be a lot easier for our small team to handle and navigate.
Overall, the main reason why we have chosen to use Unity as the game engine to develop The Cure on is due to the fact of it being free to use (as long as we have not made $200K profit in the last 12 months), and will suit the restrictions we have budget-wise with the project. However, we have factored in the possibility that we might need to subscribe to Unity into our £80'000 cost of production price, should we need it.
Overall, the main reason why we have chosen to use Unity as the game engine to develop The Cure on is due to the fact of it being free to use (as long as we have not made $200K profit in the last 12 months), and will suit the restrictions we have budget-wise with the project. However, we have factored in the possibility that we might need to subscribe to Unity into our £80'000 cost of production price, should we need it.
Time System
The game will have time system implemented to increase realism and player immersion. This time system will affect the tasks the player can perform (i.e. Only talking to the witch doctor at night) and the environment around them (i.e. Lighting and skybox changes).
The time system will run off the idea that 1 minute in real-time equates to 20 minutes in the game time; This essentially means the player will have reached the full game cycle after 1 hour and 12 minutes of real-time. This time system is used in The Elder Scrolls V: Skyrim and has proven to be a successful time mechanic.
The time system can be implemented by essentially assigning time to a hidden game object, with a set of conditions that must be met at each given time when reached (i.e. Villager NPC follows path to into their home at 18:00).
The player can skip a portion of the day to prevent them waiting with no tasks available, but to prevent this making the game not challenging enough, the player can only sleep if they have access to their bed, in their home in Peperit. This sleep function will require the user to input the time they would like to sleep until.
The time system will run off the idea that 1 minute in real-time equates to 20 minutes in the game time; This essentially means the player will have reached the full game cycle after 1 hour and 12 minutes of real-time. This time system is used in The Elder Scrolls V: Skyrim and has proven to be a successful time mechanic.
The time system can be implemented by essentially assigning time to a hidden game object, with a set of conditions that must be met at each given time when reached (i.e. Villager NPC follows path to into their home at 18:00).
The player can skip a portion of the day to prevent them waiting with no tasks available, but to prevent this making the game not challenging enough, the player can only sleep if they have access to their bed, in their home in Peperit. This sleep function will require the user to input the time they would like to sleep until.
Good-will
A method will be required to set and store the percentage of good will the player has. Good will refers to the reputation that the player has with the NPCs in the game. The player can gain good will by doing tasks for NPCs or interacting with them in the correct way. This will essentially be the main point system within the game and will determine the quality of the ending the player receives; it works as follows:
Possible good will which can be gained by the player at certain points in game:
Tutorial Level: 12% Witch Doctor: 13% City of Haven: 40% Healer Level: 18% Ingredients Level: 18% / 45% (dependant on success of previous level) |
Criteria for the percentage of good will required for each ending:
Ending 1 (“Bad” Ending): <=59% Ending 2 (“Normal” Ending): <=94% Ending 3 (“Golden” Ending): >=95% |
This method will be comprised of constantly checking if the Good Will is increased/decreased and running through perhaps an if statement to compare the current good will percentage to the criteria whenever an ending is required to be determined.
Game cheats
Cheats should be used by the testers by entering a secret cheat code which will be supplied to them by the programmer.
Some of these cheats may also be used by the player in “New Game +” to enhance user experience and the reward for completing the game.
- Cheat which allows the user to skip to different levels in the game.
- Cheat for teleporting throughout the game’s map on the input of x and y values
- Cheat to skip to time of day by inputting the time in the 24-hour time format (i.e. 13:00 as opposed to 1:00pm)
- Cheat for increasing/decreasing the money player has
- Cheat for increasing/decreasing player reputation
- Cheat to increase/decrease health state
- Cheat to have unlimited money/health
- Cheat to add items to inventory
- Cheat to navigate the map via flying
Some of these cheats may also be used by the player in “New Game +” to enhance user experience and the reward for completing the game.
Primary algorithms | Data structures
A* Search Algorithm: This algorithm will be helpful whenever generating the game’s map, more specifically to find the most suitable, shortest path between two locations on the map to create a waypoint system. This feature will benefit the player as it will help them to navigate an open world environment at ease.
Sorting Algorithm: This algorithm could be useful for things such as the shop that player can buy items from and could sort the items into the correct alphabetical order, high to low (price) and vice versa etc, to enhance the player’s experience.
[ARTIFICIAL INTELLIGENCE] Algorithms for Steering Behaviours: Behaviours such as fleeing, following and arriving at waypoints will be useful for certain AI in our game to both make NPCs seem more human-like and to also contribute to the game world (i.e. Witch Doctor fleeing from player until he arrives at certain point on map and comes to a halt). This can be programmed by using basic object transformations and a set of switch/if else statements.
Finite State Machines: A finite state machine is required for AI to enter different states (i.e. Enemies: Attacking the player, Idle, Wandering etc). This can be via general behaviours or the different states of animations of the player character and NPCs.
Sorting Algorithm: This algorithm could be useful for things such as the shop that player can buy items from and could sort the items into the correct alphabetical order, high to low (price) and vice versa etc, to enhance the player’s experience.
[ARTIFICIAL INTELLIGENCE] Algorithms for Steering Behaviours: Behaviours such as fleeing, following and arriving at waypoints will be useful for certain AI in our game to both make NPCs seem more human-like and to also contribute to the game world (i.e. Witch Doctor fleeing from player until he arrives at certain point on map and comes to a halt). This can be programmed by using basic object transformations and a set of switch/if else statements.
Finite State Machines: A finite state machine is required for AI to enter different states (i.e. Enemies: Attacking the player, Idle, Wandering etc). This can be via general behaviours or the different states of animations of the player character and NPCs.
Major Technical Questions | Risks
During the development of any project, it is necessary to assess potential risks and take precautions against them to avoid damages and delays. For each risk, I will assess the likelihood and severity of the risk to produce a score using a risk assessment matrix and suggest precautions for each step of the problem resolution process as outlined below.
For the purposes of this design, the risk assessment matrix is a table representing the likelihood of a problem occurring and the severity of that problem if it occurs, ranked according to a five-point scale on each metric. The numerical product of these two scores is calculated to determine an overall risk factor, with the highest risk factor indicating the problem that demands the most attention and extensive safeguards and fail-safes.
For this project, we have selected the problem areas to focus on based on their potential to cause damage to the whole project. The persistent risk of data loss is tackled in a broad variety of ways, but our other major risks may be less obvious at first. These include tool failure, sunk cost, tech deficit, and scope creep.
For the purposes of this design, the risk assessment matrix is a table representing the likelihood of a problem occurring and the severity of that problem if it occurs, ranked according to a five-point scale on each metric. The numerical product of these two scores is calculated to determine an overall risk factor, with the highest risk factor indicating the problem that demands the most attention and extensive safeguards and fail-safes.
For this project, we have selected the problem areas to focus on based on their potential to cause damage to the whole project. The persistent risk of data loss is tackled in a broad variety of ways, but our other major risks may be less obvious at first. These include tool failure, sunk cost, tech deficit, and scope creep.
As this design document facilitates our pre-production ideals and production goals, it is very difficult to know with certainty how likely or unlikely a particular risk is on a case-by-case basis. The reality of risk assessment is that where insufficient information exists to make a judgement, preparation for the worst case is the second-best option and so it should be considered likely that the project will meet setbacks throughout development, but those setbacks will not be as severe as they could be were the risks not considered at all.
Our four-phase approach to resolving risks in our design applies to this assessment also, but with the nuance that it must incorporate new findings as the project evolves.
Awareness: being informed of a potential problem so that it is possible to respond to it.
Periodic review of progress in the project is of utmost importance. Finding that a part of the project is delayed should always be seen as a result of potential problems, and not a source of future problems. Early identification allows enough time to be dedicated to a setback or delay that any technical deficit or adjustment in scope around the problem simply does not occur. Allowing the problem to go unaddressed is not appropriate in any circumstance.
Prevention: setting out precautions to reduce the likelihood or delay the onset of a problem.
After setting aside the necessary resources to attend to any issues that would arise during development, all team members should take steps to identify the cause as according to the above categories in a manner that does not assign blame but enforces responsibility. The results of preventative actions will invariably lead to new findings or the discovery of difficulties in the project, allowing for refinement of the design document and design goals to occur alongside production holistically.
Mitigation: utilising damage control methods to reduce the severity of a problem once it occurs.
Risk assessments of individual project elements prior to this one form the first part of mitigating actions - identification of possible sources of risk. Outside of this, preventative actions before any delays are identified and periodic meetings help maintain the quality of the project, reducing the scale of sources of risk if they did become apparent during the production of the game over the course of that year.
Recovery: returning to a functional state after a problem has occurred and recouping losses where possible.
Despite the probability of risk and the effects each risk factor may have on the project, each of them can be addressed easily and effectively - data loss, in particular, is high-risk and high-impact but resolved by an automatic backup. Provided that the team bears any possible problems with the project in mind at all times and the risks are reassessed semi-periodically, production can be streamlined around the measures that must be taken to prevent and recover from any risks.
Our four-phase approach to resolving risks in our design applies to this assessment also, but with the nuance that it must incorporate new findings as the project evolves.
Awareness: being informed of a potential problem so that it is possible to respond to it.
Periodic review of progress in the project is of utmost importance. Finding that a part of the project is delayed should always be seen as a result of potential problems, and not a source of future problems. Early identification allows enough time to be dedicated to a setback or delay that any technical deficit or adjustment in scope around the problem simply does not occur. Allowing the problem to go unaddressed is not appropriate in any circumstance.
Prevention: setting out precautions to reduce the likelihood or delay the onset of a problem.
After setting aside the necessary resources to attend to any issues that would arise during development, all team members should take steps to identify the cause as according to the above categories in a manner that does not assign blame but enforces responsibility. The results of preventative actions will invariably lead to new findings or the discovery of difficulties in the project, allowing for refinement of the design document and design goals to occur alongside production holistically.
Mitigation: utilising damage control methods to reduce the severity of a problem once it occurs.
Risk assessments of individual project elements prior to this one form the first part of mitigating actions - identification of possible sources of risk. Outside of this, preventative actions before any delays are identified and periodic meetings help maintain the quality of the project, reducing the scale of sources of risk if they did become apparent during the production of the game over the course of that year.
Recovery: returning to a functional state after a problem has occurred and recouping losses where possible.
Despite the probability of risk and the effects each risk factor may have on the project, each of them can be addressed easily and effectively - data loss, in particular, is high-risk and high-impact but resolved by an automatic backup. Provided that the team bears any possible problems with the project in mind at all times and the risks are reassessed semi-periodically, production can be streamlined around the measures that must be taken to prevent and recover from any risks.
A data loss event is likely to occur and would have a severe impact on the project depending on what is lost. If not resolved, even a minor data loss could have damaging effects on the end result: for instance, a single missing texture that is not replaced before release would disrupt gameplay and potentially damage the reputation of the developers.
Awareness: Team members should be aware that data loss may occur due to accident, user error, or a technical fault, and should be prepared to negotiate this.
Prevention: To avoid a data loss event, team members should make sure to save their work frequently during development and prepare backup copies and old versions of any work produced.
Mitigation: By storing backups in a separate location it is unlikely that all copies of a file or project will be lost due to an event.
Recovery: Load the backup or revert to an old copy to restore work; if this is not possible, recreate the work.
Awareness: Team members should be aware that data loss may occur due to accident, user error, or a technical fault, and should be prepared to negotiate this.
Prevention: To avoid a data loss event, team members should make sure to save their work frequently during development and prepare backup copies and old versions of any work produced.
Mitigation: By storing backups in a separate location it is unlikely that all copies of a file or project will be lost due to an event.
Recovery: Load the backup or revert to an old copy to restore work; if this is not possible, recreate the work.
A tool failure is unlikely to occur, but it may have a catastrophic impact on the project if it does happen, depending on which tool fails and whether a replacement is available. An example of the significant case would be for an image or model editor to malfunction, causing delays but with recoverable files; an example of the catastrophic case would be for the game engine or world editor to cease functioning, causing a potentially irreversible loss of the game project.
Awareness: Team members should be aware that production tools may malfunction or cease functioning entirely and should be prepared to make changes to the production workflow.
Prevention: To avoid a tool failure, team members should ensure that all production software is on the latest stable version and that there are no version differences between devices being used.
Mitigation: In many cases, a tool failure can be resolved by reinstalling the tool and/or making configuration changes; tool failures that cannot be resolved may be mitigated by ensuring that backup project files are stored in data formats readable by other tools in case a change is needed, and team members should be competent in multiple tools such that a new tool can be used to continue work.
Recovery: If possible, use a new tool to resume work or attempt to reproduce lost work.
Awareness: Team members should be aware that production tools may malfunction or cease functioning entirely and should be prepared to make changes to the production workflow.
Prevention: To avoid a tool failure, team members should ensure that all production software is on the latest stable version and that there are no version differences between devices being used.
Mitigation: In many cases, a tool failure can be resolved by reinstalling the tool and/or making configuration changes; tool failures that cannot be resolved may be mitigated by ensuring that backup project files are stored in data formats readable by other tools in case a change is needed, and team members should be competent in multiple tools such that a new tool can be used to continue work.
Recovery: If possible, use a new tool to resume work or attempt to reproduce lost work.
A sunk cost scenario is very likely to occur and may have a significant impact on the project depending on the nature of the cut content and the timing in relation to the project schedule. An example of the trivial case would be for an optional costume material to be scrapped; an example of the significant case would be for the flow or balance of a level to be compromised, calling for heavy restructuring of that level.
Awareness: Team members should be cautious of over-investing in content that may be cut or over-optimising a stage that has not been fully defined and be aware that quality assurance and scope changes may render some production obsolete or unnecessary.
Prevention: To prevent sunk cost, production priorities should be clearly laid out before development work begins on each section and formative evaluation should be undertaken during production to identify which aspects are most solid and which are likely to need revision.
Mitigation: To limit the knock-on effects of revisions and cut content, it is advisable to “sandbox” tentative production work and use placeholder assets for prototyping.
Recovery: Recouping losses from sunk cost is generally not possible but cut content may be kept on record for future reference in case it is needed or as bonus trivia for players.
Awareness: Team members should be cautious of over-investing in content that may be cut or over-optimising a stage that has not been fully defined and be aware that quality assurance and scope changes may render some production obsolete or unnecessary.
Prevention: To prevent sunk cost, production priorities should be clearly laid out before development work begins on each section and formative evaluation should be undertaken during production to identify which aspects are most solid and which are likely to need revision.
Mitigation: To limit the knock-on effects of revisions and cut content, it is advisable to “sandbox” tentative production work and use placeholder assets for prototyping.
Recovery: Recouping losses from sunk cost is generally not possible but cut content may be kept on record for future reference in case it is needed or as bonus trivia for players.
Tech deficit is very likely to occur and may have a significant impact on the project if it is poorly managed. An example of the moderate case would be background actor scripting not being fully optimised; an example of the severe case would be a core system being incomplete at the time of release.
Awareness: Team members should be familiar with the causes of tech deficit and the consequences of letting it go unchecked.
Prevention: To prevent a tech deficit developing, regular progress reviews should be made between milestones to ensure that all production is occurring on schedule.
Mitigation: To limit the impact of a tech deficit, additional development time should be made available to catch up on any work that is behind schedule when a milestone is reached.
Recovery: If sufficient time and resources are made available for catching up and any production that depends on delayed systems or assets is not rushed, tech deficit can easily be resolved.
Awareness: Team members should be familiar with the causes of tech deficit and the consequences of letting it go unchecked.
Prevention: To prevent a tech deficit developing, regular progress reviews should be made between milestones to ensure that all production is occurring on schedule.
Mitigation: To limit the impact of a tech deficit, additional development time should be made available to catch up on any work that is behind schedule when a milestone is reached.
Recovery: If sufficient time and resources are made available for catching up and any production that depends on delayed systems or assets is not rushed, tech deficit can easily be resolved.
Scope creep is very likely to occur and may have a significant impact on the project depending on the requests made and how far into production this occurs. An example of the moderate case would be the addition of a minor location or background NPC; an example of the significant case would be the addition of a fully interactive NPC or larger side-quest.
Awareness: Team members should be familiar with the causes of scope creep and wary of late-production additions or changes.
Prevention: To prevent scope creep from affecting development, all additions and changes to the project definition after the preproduction stage should be fully reviewed by all team members to avoid unnecessary workload; no significant changes may be made during the later stages of production or during post-production.
Mitigation: To reduce the impact of scope changes, any requirements connected with the change should be carefully considered and minimised through compromise if necessary.
Recovery: It is difficult to recover from scope creep, especially if it is not properly controlled, as attempting to revert changes once production is underway, leads to sunk cost but allowing scope creep to continue can exacerbate tech deficit.
Awareness: Team members should be familiar with the causes of scope creep and wary of late-production additions or changes.
Prevention: To prevent scope creep from affecting development, all additions and changes to the project definition after the preproduction stage should be fully reviewed by all team members to avoid unnecessary workload; no significant changes may be made during the later stages of production or during post-production.
Mitigation: To reduce the impact of scope changes, any requirements connected with the change should be carefully considered and minimised through compromise if necessary.
Recovery: It is difficult to recover from scope creep, especially if it is not properly controlled, as attempting to revert changes once production is underway, leads to sunk cost but allowing scope creep to continue can exacerbate tech deficit.
Specific Details
Key technical features for the game include a traditional hit-point system which is controlled by "hurt-boxes" (a collision region that is marked as being able to do a specific amount of damage) intersecting or colliding with player hitbox regions (which is a collision region marked as being able to receive collision from other hitboxes and damage from hurt-boxes.) This method of hit registration is fairly common amongst games with melee combat and will serve the game appropriately.
In order to monitor the player's reputation amongst in-game factions, a global script will be operating in the background that keeps scores based on player actions in-game - each major story event having a numerical value associated with it, or setting reputation flags that automatically set player allegiance or opposition of factions (notably attacking the Fera marks the player as an enemy of the islander faction outright, regardless of their score to that point).
Sound controllers will be attached to two places - trigger boxes in level areas so that region-appropriate sounds are played according to factors like time of day and player actions, and to enemy encounter logic so that various audio stings can be used to alert the player to events that they may not immediately see.
An encounter controller is necessary to govern the rate and difficulty of enemy encounters with the player and will likely entail a region-specific weighted "spawn list" that contains a table of possible enemy encounters and the likelihood of their appearance off-screen or when entering an area. To simplify progression, combatants will be only strong enough that the player can defeat them on their first time through that area, "new game +" play-through scaling these values to prevent the experience becoming too easy.
Speech craft and questing will be tied to the same overall system of branching dialogue selections and flag-setting so that the technical aspects are simplified. Providing enough of the "correct" responses for a conversation will open up Speech craft possibilities, story progression and player-facing information (rumours, chatter, information on the world, etc.) while a similar system monitors quest progression. Completing events in order throughout a quest or side quest marks an objective complete while unlocking and/or displaying the next objective in a quest sequence. After all steps in a sequence are complete, the quest or side-quest is marked as fully complete and any tasks linked to that final completion flag will also become available.
In order to monitor the player's reputation amongst in-game factions, a global script will be operating in the background that keeps scores based on player actions in-game - each major story event having a numerical value associated with it, or setting reputation flags that automatically set player allegiance or opposition of factions (notably attacking the Fera marks the player as an enemy of the islander faction outright, regardless of their score to that point).
Sound controllers will be attached to two places - trigger boxes in level areas so that region-appropriate sounds are played according to factors like time of day and player actions, and to enemy encounter logic so that various audio stings can be used to alert the player to events that they may not immediately see.
An encounter controller is necessary to govern the rate and difficulty of enemy encounters with the player and will likely entail a region-specific weighted "spawn list" that contains a table of possible enemy encounters and the likelihood of their appearance off-screen or when entering an area. To simplify progression, combatants will be only strong enough that the player can defeat them on their first time through that area, "new game +" play-through scaling these values to prevent the experience becoming too easy.
Speech craft and questing will be tied to the same overall system of branching dialogue selections and flag-setting so that the technical aspects are simplified. Providing enough of the "correct" responses for a conversation will open up Speech craft possibilities, story progression and player-facing information (rumours, chatter, information on the world, etc.) while a similar system monitors quest progression. Completing events in order throughout a quest or side quest marks an objective complete while unlocking and/or displaying the next objective in a quest sequence. After all steps in a sequence are complete, the quest or side-quest is marked as fully complete and any tasks linked to that final completion flag will also become available.