21/10/22 - Further ideas

Sorry for the missed week, I couldn't put my headset on due to a very long headache.

In the meantime, I created a few modelled assets I plan to use for the project, this includes the button, lever, and the base model for a clipboard (this is likely going to be a mix between an in game menu and the painting tool). I have also spent the time reconsidering some design choices I noted in my previous posts, notably the "gravity gun" tool and the door.

For the door, I decided to make some small additions to the idea based on information I gained on one of the lecture sections, which was about providing the player with feedback. I will aim to include both visual and tactile feedback by adding two elements, a cartoon-like speech balloon popping up when the player knocks and when the door unlocks; for the tactile feedback I will make use of the controller vibration to provide instant feedback. For the visual element, I may add cartoon sound effect balloons to alert the player that is had worked. There could be one for the knocking, and one for the door unlocking. There will of course also be audio elements to aid the player as this is very simple to implement.

For the gravity tool, I have decided to have it as something attached to the players hand by default. This decision was based on a VR game I played recently called "I expect you to die" this features a tool similar to what I want to use but can be done with either hand without any additional tools. While playing the game, I realised if selection this feature was manual then it would be quite difficult and complicated to use, especially as certain elements in the game are time-sensitive. One issue I had with the tool is when moving items with text/information on them, they would often become skewed/rotated and hard to read. The game lacks a button dedicated to reorienting an item; if it does have one, it does a poor job of communicating that to the player. For the change I plan to allow the player to operate the object manipulation tool with their dominant hand without having to equip a designated tool. This will work well as other tools such as the clipboard will also require the player to select/draw things with their dominant hand while holding the clipboard in the other; the other intended tool, the car keys will also be simple to use with only a button press meaning a dominant hand is not required to adequately control it. The items will be available the the user using a radial menu with the non-dominant hand (I may also use this to allow the player to access a reset tool to move manipulatable objects back to their original position). Due to this, I will have to add an additional setting when starting the game, letting the player choose which hand is their dominant one; this will go alongside other start settings such as player height.

I plan to start implementing the five mechanics within the next few days now that I can put my headset back on.

I will likely start my researching how the players control data can be accessed and used with blueprints as this will be necessary for all the mechanics, this includes the location data of the player and their controllers, the controller hitboxes, what buttons the player is pressing, etc. Furthermore, I will aim to implement a state system depending on what state the controller is in, this can include grabbing, (using the grip button), selecting (using the bumper button), and pointing (using neither). This is based off information I learned in another course (gameplay programming) which can help avoid lots of nested if statements which can become cluttered and complicated to understand/build upon.

Using this data, I plan to start with the lever and button mechanics, then the door. The following are my initial plans for each mechanic.

Button

This is the simpler of the two mechanics, for the base design I will likely the "point" hand state mentioned above. The program will then check whether the player's hand is colliding with the button making use of collision boxes for the players hand and the button itself. This will then set the button to an on state with the model playing an animation showing the button pushed. 

Given time to improve this, I will aim to have the button move adaptively with the hand/finger collision box. So it will move inward depending on how far the player is pushing it then triggering once it had reached a certain threshold. One issue that could arise with this is if the player approaches the protruding button from the side, I do not yet know how to combat this.

Lever

For the lever, I intend to make use of the "grabbing" hand state mentioned above.  When the players hand collision reaches the lever handles box, the hand model will snap to the lever. It will then measure the vertical axis value of the hand, the lever handle will turn vertically according to the players hand with two boundaries, the starting position, and the end position, the location of which will depend on whether the lever was initially in on a on or off state. The lever will do nothing upon hitting the starting boundary but will move towards the end boundary depending on the players controller vertical axis value (relative to its start position) until the lever reaches the end boundary where the lever will be switched to the on/off state opposite to what is was originally and the players hand will be automatically detached from the lever. I will aim to avoid tracking it in an arc as its will be both complicated and unnecessary.

One issue that could arise with this is the hand being attached to the lever from an unrealistic distance if the player moves it and does not release the grip button before moving their hand far away. To combat this, once the players hand has moved far enough away from the lever, either vertically or horizontally it will automatically be detached until the players hand is within a suitable range again.

Door

For the knocking mechanic to open the doors, there will be a collision box for the door either at a suitable height or encompassing the entire model. Once the players hand collides with this hitbox the game will register a knock. This will cause several feedback effects, an audio clip of a knock, a short vibration in the controller, and possibly a visual cartoon sound effect balloon; these will alert the player that they have done something right. This will then trigger an event such as the door unlocking/opening or something passing through the letterbox. One possible issue is the trigger or feedback effects happening repeatedly due to the hitboxes being constantly colliding. To help avoid this, I will implement a system to only trigger the event if it has not been done within a small previous time frame, it could also only trigger again once the hitboxes have stopped colliding for a long enough time prior.

For the handle itself I will use a similar grabbing system to as the lever but with the door opening fully with only a minor push, this avoid having the user move their arm extensively to open it. I could also require the user to tilt their controller once they have grabbed the handle to emulate a real door knob.