I have spent the weekend completely sorting out the inputs for the game. I really wanted the game to be played with a gamepad but also be played with the keyboard. I have created a hint bar that slides in the top corner as the player will need to learn the controls. These are displayed periodically through triggers as the player plays through the first part of the level. The first part was railroaded so the player could learn the controls so having this be where hints are popping up is perfect. However, the main issue was with creating a way to detect input from the player using the new input system. Using the player input component would have made it easier but as I wasn’t, I struggled to find a way to get the previously used device. Therefore, I found a way to detect if the console has a DualShock or gamepad connected. If they DO, then the input tooltips will change to the device connected and they would need to disconnect the controller to use the keyboard. This is not how I wanted it to work but this works and I am happy with it. I have different input prompts, and most are interacting prompts that pop up when in range and available. Therefore, most sprites get themselves just before they appear on screen so that they are not constantly checking and are up to date with the current input. However, there is a button(s) on the HUD that checks every few seconds for the input to update its sprite. It's not instant but by the time you plug in or unplug a device and get back to playing it's pretty much done.
(Watch it change as I plug in my controller)
I wanted a modular system to display inputs so I would be able to drag and drop an image into a UI (for something that is interactable or displays an input like a hint), attach a script called "InputPrompt" and type the input name in the inspector, then, whenever it is about to be displayed it checks the current input and fetches its sprite with the corresponding action and device.
I have also begun implementing some of the dialogue and quests into the game. I am using Pixel Crushers Dialogue system and it is proving to be a great plugin. After getting used to the way it works (its also reminiscent of the time we made a warcraft campaign in Warcraft 3 engine) it is relatively easy to make new quests and dialogues. I am not fully comfortable with it and I am going to steer clear of camerawork until I have polished the game rather well. I am focusing more on just dialogue and showing the player their current quest so the player knows what do do at all times just not HOW to do it as this is a factor that makes the quests feel too easy. Adding dialogue and quests has also allowed me to get a better feel for the pace of the game and allowed me to work on piecing events together. I aim to have all the quests and dialogue implemented in the next couple of days so that over next week and maybe easter, I can have a huge amount of testing being done.
Comments