-
Notifications
You must be signed in to change notification settings - Fork 0
⚙️Technical Designs
Olli Appelt edited this page May 23, 2024
·
14 revisions
To realize the movement mechanic we will use unity's rigidbody physics system. We chose to do this because this enable's us to have the movement interact with the environment really easily. Also making a own physics system would be to much work. So we will add force in the direction of the player's input
To properly and cleanly keep track of where the game is and which systems should be running, we are using a statemachine. To realise this we will be using a base state class where new state's inherit from. This class will have 3 functions that can be overwritten (enter, update, exit). We do this so the state can handle most of the state specific code.
To keep track of what every player is doing they each have a playerstatemachine. To realise this, we will be using enum's and in specific action be checking which enum is active in the playerstatemachine. We do this because these player state specific actions can easily be handled in the player scripts.
To realise this feature we need to make a StructClass with name, objects and broken state. Class that handles broken parts when the Robot enters the workshop and handles whole part that can be broken. Class that handles breaking new whole parts on a timer. When this feature is completed the Robot is able to spawn into the game with broken parts already attached to him and the players are from the start able to grab these parts and begin to repair them. Players are now also able to bring repaired parts to the Robot and the logic will automatically add these repaired parts to the “WholePartList”.
To realise a local multiplayer lobby we first need to check if a controller connected, we will save the controller when it is connected and give it the option to join the lobby. We will be doing this by using unity's new input system, this instantly gives an event when a controller is connected, then we can connect the logic. To keep track of the player's in the logic we will be using a struct with the necessary data for the player. We use this because its a easy way to store a lot of data that doesn't need to be changed.
The Quicktime event works as follows: There are to images(sprites). One sprite(01) indicates when the player needs to press the button and the other sprite(02) gets smaller until reaching size 0,0. When the players sees that the sprite(02) reaches the same size as sprite(01), the player presses the button and sprite(02) resets to it's original size and does the whole thing again. This happens 3 times, then the player has completed the QuickTimeEvent.
To make the throwing mechanic reality we are gonna make use of the unity input system and scripts. We decided to do this so that we can easily bind an input to the throwing, this way the player can easily use it. The reason we create this mechanic is this way we can easily stimulate the players to work in a team without forcing it too hard on the players.
To properly and cleanly keep track of where the game is and which systems should be running, we are using a statemachine. To realise this we will be using a base state class where new state's inherit from. This class will have 3 functions that can be overwritten (enter, update, exit). We do this so the state can handle most of the state specific code.
To keep track of what every player is doing they each have a playerstatemachine. To realise this, we will be using enum's and in specific action be checking which enum is active in the playerstatemachine. We do this because these player state specific actions can easily be handled in the player scripts.
To realise this feature we need to make a StructClass with name, objects and broken state. Class that handles broken parts when the Robot enters the workshop and handles whole part that can be broken. Class that handles breaking new whole parts on a timer. When this feature is completed the Robot is able to spawn into the game with broken parts already attached to him and the players are from the start able to grab these parts and begin to repair them. Players are now also able to bring repaired parts to the Robot and the logic will automatically add these repaired parts to the “WholePartList”.
To realise a local multiplayer lobby we first need to check if a controller connected, we will save the controller when it is connected and give it the option to join the lobby. We will be doing this by using unity's new input system, this instantly gives an event when a controller is connected, then we can connect the logic. To keep track of the player's in the logic we will be using a struct with the necessary data for the player. We use this because its a easy way to store a lot of data that doesn't need to be changed.
The Quicktime event works as follows: There are to images(sprites). One sprite(01) indicates when the player needs to press the button and the other sprite(02) gets smaller until reaching size 0,0. When the players sees that the sprite(02) reaches the same size as sprite(01), the player presses the button and sprite(02) resets to it's original size and does the whole thing again. This happens 3 times, then the player has completed the QuickTimeEvent.
To make the throwing mechanic reality we are gonna make use of the unity input system and scripts. We decided to do this so that we can easily bind an input to the throwing, this way the player can easily use it. The reason we create this mechanic is this way we can easily stimulate the players to work in a team without forcing it too hard on the players.