-
Notifications
You must be signed in to change notification settings - Fork 1
Code Requirements for Collection Game in Chapter 1 to 3
This section details the functions that each side game needs to use and call, and also gives simple examples of functions that other groups need to complete in order to support us.
The player approaches a damaged switch, and a prompt pops up. The switch is currently in a damaged state. The player needs to collect the specified battery, then return to the damaged switch, complete the repair with the given tool, and then the switch is working.
The switch needs the location parameter and the isWorking(boolean) parameter
The switch isnearby function Call the distance measurement function written before npcinteraction to test the current distance. If the distance meets the conditions, then check whether the current switch is good or bad. If it is good, it will pop up saying that it has been repaired. We have batteries and tools in our backpacks, and we ask if we want to use the batteries and tools in our backpacks to repair them to get clues. (If the user confirms to repair, then use the switch repair function to repair, if not repair, close the sign). If we don't have three batteries and a tool in our backpack, prompt the player to find three batteries and a tool to repair and get clues.
Breaker repair function First call the backpack function, delete the three batteries and one tool, change isworking from false to true, and then call the prompt box function to display a clue.
ps: The battery location inherits the prop class Tools location inherits the prop class
Similar to the last switch, but this time you need to talk to the NPC, and this also needs to communicate with the group responsible for the NPC. The key is that how the group responsible for npc communication realizes this chap2 dialogue needs to accurately locate option 1: tell her the truth. / Option 2: This step of hiding the truth temporarily before we can start our game.
The flow of this game is like this. After the mission of the first card is over, the player enters the second chapter, and through continuous dialogue with the npc, comes to option 1: tell her the truth. / Choice 2: When the choice to temporarily hide the truth, enter the side quest. If the player chooses to choose 1 and tell the NPC the truth, then the NPC will feel angry, and then the player cannot get the clue and end the side quest. If the player chooses option 2, the NPC will give the player instructions to collect coral. After the player collects the coral, the NPC will try to use the coral to repair the luster of the scales, but it still fails, and then enters the third chapter.
The trigger of this game lies in how the npc interaction group is designed. My idea is to use step 2 and 3 with stepid and option 1 or 2 to record which branch the player has reached. We need to call their function in option 1: tell her the truth . / Option 2: Join the game when the truth is temporarily hidden. The dialogue steps in it need to be called according to the implementation of other groups. When we really need to do a small game, we only need: CheckHasitem function to check whether there are 5 corals in the backpack. If there is a function in the backpack, delete 5 corals. Corals, if not, prompt the player again to find five corals to get clues. ps: Coral (inherited prop type) needs to have a location parameter
Similar to chap2, which is what the small game above does, but with a branch line, when the player communicates with the npc in Chapter 3 to option 1: tell him the truth about Nereus' death. / Option 2: Conceal the situation. , we need to describe what to do.
If the player chooses to choose 1, then the npc will ask the player to find one for jellyfish, one for coral, and one for seaweed. If the player chooses option 2 and hides the truth, the npc will express anger (through dialogue) and then ask the player to find five jellyfish, five corals, and five seaweeds.
The subsequent process is similar to the above. When the user comes back after collecting the items, the NPC will deduct the number of items on the player according to the selection selected by the player. If the number of items on the player is not enough, the NPC will ask the player to find it again. When the player collects all the items requested by the npc, and after the npc deducts the items, the player will be given a repaired scale, and the player will put it into the backpack, so as to continue the chat of chap3.
The following code frame simulates the NPC dialogue process in chap3, by recording the stepid to confirm where the NPC and the player are directly talking to, and by recording option1 and 2 to indicate which option the player has selected. Store these two key data in the array list to record the game progress.

- Uniform Pixel Grid Resolution
- Storyline
- Instruction
- NPC info
- NPC Communication Script
- Inventory-System-and-Consumables
- Storyline User Test
- Traitor Clues
- Game Characters
- Player Profile User Test
- Player Eviction Menu Sprint1: User survey (Team 7)
- Player Eviction Menu Sprint2: User survey (Team 7)
- Sprint3 - Win/lose Condition: User survey (Team 7)
- Sprint4 - Polishing-tasks: User survey (Team 7)
- Transition Animation/Special Effects/Sound Effects: Feature Overviews
- Transition Animation and Effects: Design Process & Guideline
- Sprint 4 User Testing
- Transition Animation & Effect: Code Guideline-Sprint4
- Sound effect when players complete npc tasks and hover over npc cards
- Fixing the clue bug
- Music Test
- Player Eviction Menu: Design Process & Guideline
- Player Eviction Menu (Feature Overviews)
- Player Eviction Menu: Code Guideline - Sprint1
- Sprint 1 User Testing
- Detailed Eviction Card: Design Process & Guideline
- Detailed Eviction Card: Feature Overviews
- Sprint 2 User Testing
- Player Eviction Menu: Code Guideline - Sprint2
- Sprint 2 Inventory System and Consumables Items User Testing
- Sprint 2 Inventory System and Consumables Items Functionality
- NPC interaction testing plan sprint3
- NPC interaction testing results sprint3
- NPC Dialogue Scripts
- Code Guideline
- Win/lose Condition: Design Process & Guideline
- Win/lose Condition: Feature Overviews
- Sprint 3 User Testing
- Win/lose condition: Code Guideline - Sprint3
- Enemy List
- User Testing 1: Enemy Image Filter
- User Testing 2: Enemy Animation and AI
- User Testing 3: Basic Attack