DeltaVR improvements
Ranno Samuel Adson
DetavVR is a virtual reality application where people walk around a virtual copy of the University of Tartu's Delta educational Building. It has different interactions for the players along with multiplayer capability. DeltaVR's function is to introduce one to the different activities happening in the real Building and to be a showcase of the work made by students. It is shown off in many expos and events that the University of Tartu takes part in.
The current tasks tend to differ with each milestone. The general lean is toward adding and fixing multiplayer features. So assets that can change their state and supporting multiplayer in general. This is mainly to challenge myself, for I've been avoiding configuring multiplayer as it is new ground to work on and tedious to test. Other outliers may appear depending on player feedback.
Possible features to be added are:
1) Redesign the UI to improve the experience for presenters.
2) Redesign player location calculations to improve immersion.
3) Add grabbable objects with gravity (such as monitors).
4) Fix VR doors to improve immersion.
5) Add interactable objects to mirror real life, such as storage cabinets and trashcans with flaps.
In the end there should be a link to the final build, repo and a 10-20 sec final result video.
Milestone 1 (07.10)
For this iteration, I will improve the UI used to manage the game. Since it's a multiplayer game, setting it up can be confusing because it is complex under the hood. Currently, the presenter has to start the server, start advertising it online, start listening for it online and then join. This is a relic from a time when DeltaVR was developed by another. I made a solution a while ago, but it somehow got corrupted. In this iteration, I will remake the UI and add additional capabilities to it.
Tasks
1) Design the UI layout (1h)
2) Have the game start with 1-2 button presses (2h)
3) Add quit button (1h)
4) Configure multiplayer server joining (4h)
5) Test the UI (1h)
[Current menu]
For one, DeltaVR has no quit button, with Alt-F4 being the main way to close it. I also hope to add a button that resets the player tutorial functions to the start state. This is secondary, but a thing that could be done. This improvement is important because it removes the barriers for the presenters to present. If they can easily manage the application, they tend to prefer presenting it. If the game doesn't get presented, it's not fulfilling its function.
Results
Tasks
1) Design the UI layout (1h -> 2h)
2) Have the game start with 1-2 button presses (2h -> 1h)
3) Add quit button (1h -> 0.5h)
4) Configure multiplayer server joining (4h -> 4h)
5) Test the UI (1h -> 2h)
Designing the UI layout was not complex. In the beginning, I had hoped to add a restart button that would simplify showing the application in expos. More than half of the time went to designing the restart button with its icon and working on its colours. I spent hours trying to implement it, but since it's a multiplayer application, it turned out to be even more complicated than I had feared. I currently have it disabled, which is fine, because it wasn't a hard goal established, and thus, the time spent on its functionality is not counted.
Having the game start in singleplayer was not complex, but it took a while to worm out the bug that made it dysfunctional. I also spent an hour or three getting the VR-keyboard options working properly, but, since I did not establish it as a goal, it is not officially under time spent.
The quit button was the simplest. Straightforward and quick. However, it did confuse me for a bit. You can use the quit button in the build, which was the goal, but in Unity editor it would need another way to do it. It would be simple, but I thought it ultimately unnecessary (You already have a quit button in there). Adding it would have added unneeded complexity.
Multiplayer joining was a proper headache. After a lot of investigation, it turned out that the processes checking for available servers were running on background threads instead of the main thread. It is problematic because only the main thread can manage the objects in the scene and has default access to the usual methods. It was so difficult to puzzle out, because instead of a warning, console log or anything. If you try to do something on the background threads that you can't, then the processor just has a stroke and halts the method. Nothing on the console. I was able to switch the execution to a main thread after some fiddling.
The UI did not actually need 2 hours of testing. However, I took part in 2 expos showcasing my application, where I got extensive testing done as a side benefit.
In total, I was off with the time estimates by half an hour. Instead of taking 9 hours, it took 9.5 hours.
[Updated menu]
Milestone 2 (21.10)
This milestone has the general theme of player colliders. To put it shortly, there are 2 general issues, both decreasing player immersion and game enjoyment:
The player character's main collider (see green capsule) can be offset from their perceived location, dictated by the camera. This happens when the player moves around freely in the real world. This is not an issue, for such movement makes the application much more immersive, and the player collider shouldn't prevent such movement in any way. With teleporting around, the player's main collider is not reset to the camera position. This is an issue because this collider is used to detect the player's position, which can result in teleporting portals not detecting when the player tries to use them (see figure below, green box is the portal's detection area).
[Player main collider issue]
Another issue is the player's hand collision. Currently, the player's hand just goes through any object, decreasing immersion. Fixing this is difficult because the solution shouldn't interfere with the ability to grab items, and the solution needs a dynamic way to manage the resulting offset between the real and VR hands.
[Player hand collider issue]
Tasks
1) Make the player's main collider readjust when teleporting, OR add and configure a separate collider trigger tracking camera movement so no offset is perceived. (4h)
2) Make dynamic, colliding VR hands to increase immersion (8h)
Results
Tasks
1) Add and configure a separate collider trigger tracking camera movement so no offset is perceived. (4h -> 2,5h)
2) Make dynamic, colliding VR hands to increase immersion (8h -> 8h)
I had to add a new collider to the camera instead of having the teleportation readjust the player collider. The solution is better in a way where the player detection is happening where the player actually percieves themselves to be. The collider is a simple trigger that could be used by other components.
The downside to that approach is that some scripts have to be rewritten to detect the new collider. Also, the original disparity still exists. I tried to have the main movement type (ray teleportation) adjust fix the disparity upon teleport, but its functionalities are part of a plugin. When I tried to create custom scripts to emulate the behaviour, they stopped working properly. The reason for that is, that the scripts in the plugin are heavily intertwined and cannot be edited in isolation.
Hand collisions were easier in the places I expected to be hard and harder in the places I expected to be easy. The displaying and synchronising of the elements in multiplayer were surprisingly easy. However, there were controllers in the hands of the players that did not easily move along with the hands.
Milestone 2 (04.11)
Tasks
1) Improve the collisions in the scene to more properly mirror the actual dimensions of the objects (8h)
2) Improve the current VR project hand colliders, having the controllers not visibly pierce rigid objects. (8h)
