Virtual Vitality·educational VR in Unity
The VR client of a serious game for care students, built by my whole class at Firda as five departments. I was one of the two Unity developers and wrote the login screens, scene flow and question shelf.
| Context | whole-class project at Firda, five departments, a serious game for care students |
| My part | one of the two developers of the VR client |
| I wrote | login screens and scene flow, question shelf, answer return, player reset, results room, menu music player |
| Stack | Unity 2022.3.21f1, C#, XR Interaction Toolkit 2.5.3, OpenXR, URP |
| Runs on | Windows PC-VR build, played on a Quest tethered to a PC |
| Built | 4 March to 2 July 2024, mockup due 20 June |
Virtual Vitality was a VR serious game for care students, built from March to July 2024 by my whole class at Firda working as one simulated company of five departments. I was one of the two developers in the Unity department, which built the VR client: a hospital room where the student answers questions by placing numbered briefcases in a slot, then leaves through a door whose keypad code is the answer sheet. I wrote the login screens and scene flow, the question shelf and the results room.
Five departments, one headset
A teacher set the class the challenge of a serious game in which care students practise cases from their course, in a room their teacher prepares. The class plan split the work: a login and admin team (a Laravel system with users, roles, schools and classes), Blackbox (a Flask data broker), Library (a store for 3D objects), Web (a site for building scenes) and the VR client. Each department had its own repository, plan and task board, and the mockup was due on 20 June. Along the way the departments held joint test runs, where every team’s code had to run together as one system with a shared server, logins and database, and presented their progress to the class.
April: cubes in a hospital ward
On 16 April 2024 an early version of the VR client ran in a classroom as a ward with several beds, where the player picks up cubes and places them in translucent target zones. A development build from 25 April already had the five-scene flow the final version kept: teacher login, scenario hub, student login, the room, and a results room.
Logging in through another team’s API
I moved my local Unity project into the department’s repository on 16 May. The login team wrote a C# class for every department to drop in, and I built the login screens and scene flow around it. Their class reads a config file in which every line is AES-256 encrypted. From 11 June it has eight lines: the endpoint URL, five shared secrets, and the key and IV for the reply. The client posts the credentials, then decrypts the first name, last name and rights that come back. The API’s error codes tell a blacklisted account apart from wrong login details, and the login screen shows which one it was.
The flow is two logins on one machine. The teacher signs in and picks a situation from a hub, then the student signs in on the next screen and lands in that room. A timer starts with the room, and the results room at the end shows the time spent, with buttons to repeat the room or return to the hub. By the deadline one room existed; the other ten names in the hub are placeholders.
June: the quiz room
For the mockup the room became a quiz. The hospital room, shelf and briefcase models are downloaded assets; I brought the shelf in on 4 June and wrote its code between 13 and 19 June. The shelf is a stack of floors, one per question, that moves like a lift: two buttons scroll it, the active floor glides into place on a smoothstep curve (half a second for each floor it passes) and its cover flips open, and the answers for that question appear on the tray beside it. Each question’s pick is remembered, and scrolling back puts the chosen briefcase in the slot again. The four questions are placeholders; the first asks how many legs a dog has.
Two smaller scripts keep a session from getting stuck. A briefcase dropped anywhere except the shelf or the slot glides back to its place on the tray, and a player who falls out of the room is put back at the start.
The exit is a keypad by the door, which a classmate built. From 19 June the player types the numbers of the briefcases placed for each question, in order, and the door opens only when those are the correct answers.
Two prototypes against local servers
The scene loader asks a local endpoint for a list of objects (prefab, position, rotation, scale, material, colour) and spawns them; a classmate wrote the first version, and I added rotation, scale and on-screen error messages. Blackbox was meant to serve that list, and that connection was never made. On deadline day a classmate added a websocket client for an instructor outside the headset: it spawns, moves and removes one test cube and plays audio sent to the headset as an intercom.
After the deadline
I kept working on the client after 20 June. By the demo build of 27 June I had added a music player to the menus, and the last commit, on 2 July 2024, changed what a denied code does: the shelf clears every wrong answer, keeps the right ones and scrolls back to question 1.