Project Overview
Purpose of the project
Room of Horror is a VR learning game set in a hospital / nursing room. Nursing trainees have to detect safety-relevant and care errors in a VR environment — e.g. syringes lying around, an unsecured bed, a child in an adult bed, or a medication that conflicts with a documented allergy.
Room of Horror 2.0 (this project, HWR Berlin, summer semester 2026) extends the existing application with diverse patient profiles, patient-specific error scenarios, an interactive patient file, a weighted scoring system, and technical modernization (PostgreSQL, WebSockets, Zod validation).
Project components
| Area | Path | Task |
|---|---|---|
| Unity/VR game | room-of-horror-unity | Renders the VR room, spawns the selected patient model, shows the game code, activates error objects, and reports found errors to the backend. |
| Backend/API | room-of-horror-api | Manages accounts, game codes, game status, patient profiles, error catalog, mistake attempts, and computes the evaluation. |
| Frontend/website | room-of-horror-frontend | Enables login, game-code entry, patient selection, error configuration, start/stop, and live evaluation. |
| Assets | room-of-horror-assets | Logos, images, videos, Adobe XD design file. |
| Models | room-of-horror-models | 3D source models (FBX) and textures for room props. |
Basic game flow
Unity/VR game starts
-> Backend creates or loads a game
-> Unity displays a game code
-> Instructor logs in on the website
-> Instructor enters the game code
-> Instructor selects a patient profile (targeted or random)
-> Instructor configures errors and mistake attempts
-> Instructor starts the game
-> Unity activates patient, room configuration, and the selected errors
-> Trainees search for errors in VR
-> Backend computes the weighted evaluation, website shows the report
State at project completion (July 2026)
- 6 diverse patient profiles (A–F) are integrated in database, frontend, and Unity scene — see Patient Models.
- The error catalog contains 32 errors with category, weighting, and criticality — see Error Catalog.
- The database was migrated from SQLite to PostgreSQL; game state is additionally stored in normalized tables.
- The frontend receives game events in real time via WebSockets (Socket.IO).
- Accessibility: color-vision modes in the frontend (protanopia, deuteranopia, tritanopia, achromatopsia).
- The architecture is fully documented — see Architecture.
History
The first version of this page was written at project start as an analysis of the inherited codebase (Room of Horror 1.0 by Kaan Turan). At that time: SQLite as the database, 1 standard patient model, no central error catalog. These points were implemented during the project and the page was updated accordingly.
Information sources
- Repository structure and code of all sub-projects (as of July 2026)
- Original analysis of the inherited application (project start, April 2026)
Last build: 19 Aug 2026, 05:20+00:00