Introduction:

This week I began designing and constructing the Main Map, which represents the central hub or “inside myPhone” world in the VR experience.

The focus was on defining the spatial layout, lighting mood, and early interaction zones where the player will navigate and engage with core gameplay elements.

Achievements:

• Created the initial environment blockout using ProBuilder for quick geometry prototyping.

• Defined the scale reference based on human hand and head height in VR (Quest 3 calibration).

• Imported optimized 3D assets and tested material performance under URP.

• Implemented teleportation anchors and basic movement boundaries for smooth navigation.

• Added ambient sound layers to create immersion in the environment.

Challenges and Solutions: 

• Challenge: Scene scale felt inconsistent when switching between build versions.

• Solution: Recalibrated the player rig and verified Unity units (1 unit = 1 meter) matched Quest 3 tracking space.

• Challenge: High draw calls due to overlapping materials and dynamic lights.

• Solution: Combined meshes, baked static lighting, and used light probes for dynamic objects.

• Challenge: Early map tests showed slight motion sickness from uneven locomotion transitions.

• Solution: Tweaked camera smoothing values for predictable comfort movement.

Screenshots/Images:

• None

Resources:

• [iPhone Size]

🔗 link 🔗

• [iPhone Size and Layout Reference]

🔗 link 🔗

• [Unity URP Optimization Guide]

🔗 link 🔗

• [Meta Quest Performance Optimization Tips]

🔗 link 🔗

Next Steps:

• Work on the Proposal and Concept Prototype, integrating the Main Map into the gameplay loop and preparing interactive elements for user testing.

Introduction:

During these two weeks I focused on formalising the project proposal and building an early concept prototype for the overall game direction. The central idea was refined into a VR experience set inside a smartphone-inspired world, where the player interacts with stylised apps and digital threats in a playful but structured environment.

The goal of this stage was to move from a broad idea into a clearer gameplay concept that could support several mini-games while still feeling like one coherent project. This helped define the project identity early and gave the later development stages a stronger foundation.

Achievements:

• Finalised the main project concept and prepared the proposal presentation.

• Defined the “inside myPhone” theme as the primary visual and gameplay framework.

• Built an early prototype scene to test scale, interaction distance, and general VR readability.

• Planned the project as a hub-based experience containing multiple mini-games connected through one main environment.

Challenges and Solutions: 

• Challenge: The original idea was too broad and risked becoming difficult to complete within the project timeframe.

• Solution: I narrowed the design into a hub world with smaller connected mini-games, allowing development to be broken into manageable systems and milestones.

• 
  

• Challenge: It was initially unclear how to make the smartphone theme readable in VR.

• Solution: I focused on exaggerated scale, bold visual motifs, and app-inspired spatial zones to make the concept understandable at a glance.

Screenshots/Images:

• None

Resources:

• [Unity ProBuilder Manual:]

🔗 link 🔗

• [Unity 6 Meta Quest workflow:]

🔗 link 🔗

• [Unity OpenXR Plugin Manual:]

🔗 link 🔗

Next Steps:

• Develop the visual identity of the fake applications.

• Begin creating app icons and app-specific spaces for the main map.

Introduction:

These two weeks were dedicated to designing the fake app icons and the visual identity of the in-game applications. Since the project is based around the idea of being inside a phone, the app icons are an important part of both navigation and storytelling.

Rather than creating icons that behave like standard flat mobile UI assets, I explored ways to make them readable and interesting in 3D VR space. The aim was to keep them simple enough for immediate recognition while also making them fit the stylised world of the game.

Achievements:

• Designed a set of fake app icons to represent different gameplay areas.

• Established a visual style based on bold colour, simple shapes, and strong silhouettes.

• Tested icon readability at VR viewing distance inside the environment.

• Integrated the icons into the main map to begin defining the player’s route through the hub.

Challenges and Solutions: 

• Challenge: Flat UI-style icons looked weak and difficult to read in 3D space.

• Solution: I redesigned them with stronger contrast, simplified forms, and more visible borders so they remained readable in VR.

• Challenge: Some icons looked too similar when viewed quickly during movement.

• Solution: I increased variation in shape language and colour so each app could be distinguished more clearly.

Screenshots/Images:

• None

Resources:

• [Apple Human Interface Guidelines, App Icons:]

🔗 link 🔗

• [Unity UI overview:]

🔗 link 🔗

• [WCAG contrast guidance:]

🔗 link 🔗

Next Steps:

• Move from environmental identity into gameplay planning.

• Start defining which mini-games belong to which apps.

Introduction:

At this stage I shifted the project from concept and visual development toward interactive gameplay. The main task was to decide which mini-games would best fit the smartphone-virus theme while remaining achievable within the project timescale.

I began planning the mini-games as short, replayable interactions linked together by a central player system and a shared hub world. This decision was important because it meant the project could benefit from reusable mechanics such as movement, grabbing, haptics, and scene transitions.

Achievements:

• Defined the mini-game approach as a collection of short VR experiences inside one themed project.

• Planned the Mail mini-game as the first development priority.

• Identified reusable systems needed across all mini-games, including movement, grabbing, menu handling, and scene flow.

• Began blocking out how mini-games would connect back to the main hub.

Challenges and Solutions: 

• Challenge: There were too many possible mini-game ideas, which made prioritisation difficult.

• Solution: I selected one mini-game as the first fully playable target and used it to guide the design of reusable supporting systems.

• 
  

• Challenge: A disconnected mini-game structure risked feeling fragmented.

• Solution: I kept the shared phone-virus theme central so that each mini-game would feel like part of one larger experience.

Screenshots/Images:

• None

Resources:

• [Unity XR Interaction Toolkit overview:]

🔗 link 🔗

• [Unity XR Locomotion docs:]

🔗 link 🔗

Next Steps:

• Refactor the player into reusable systems.

• Build the underlying architecture needed for multiple mini-games.

Introduction:

These weeks focused on the internal architecture of the player and the wider interaction framework. Rather than depending on ready-made XR interaction prefabs for movement and object handling, I began building the player logic as a custom system made from smaller subsystems.

This was a major technical direction change for the project. The advantage of this approach was that it gave me full control over how interaction should behave across all mini-games, while also making it easier to debug and extend later.

Achievements:

• Created a central PlayerManager to coordinate the player logic.

• Split the player into custom subsystems including input, tracking, movement, grabbing, locomotion, audio, haptics, and animation.

• Began standardising references for the head, controllers, and interaction objects.

• Reduced dependency on stock XR interaction prefabs by moving more behaviour into custom scripts.

Challenges and Solutions: 

• Challenge: A growing number of systems made the player difficult to manage in one script.

• Solution: I refactored the code into dedicated subsystems with clear responsibilities, improving readability and maintainability.

• Challenge: Reusable systems needed to work across different scenes and mini-games.

• Solution: I designed the architecture around shared managers and configurable references so the same player could operate in multiple contexts.

Screenshots/Images:

• None

Resources:

• [Unity Input overview:]

🔗 link 🔗

• [Unity Input System Manual:]

🔗 link 🔗

• [Unity Scripting section:]

🔗 link 🔗

• [Unity Components overview:]

🔗 link 🔗

Next Steps:

• Improve movement, jumping, crouching, and comfort options.

• Continue testing the custom player architecture in VR.

Introduction:

The next major task was implementing reliable player movement and comfort systems for VR. This included forward movement, turning, crouching, jumping, player height control, and a comfort vignette designed to reduce discomfort during locomotion.

These systems were especially important because they affect every mini-game in the project. The goal was not only to make movement functional, but also to make it consistent, adjustable, and comfortable for different users.

Achievements:

• Implemented configurable player movement and turning behaviour.

• Added snap turning and smooth turning options.

• Added crouching, jumping, adjustable player height, and support for multiple jump counts.

• Implemented a locomotion vignette system with separate settings for idle, moving, and turning states.

• Added menu-accessible comfort settings through the options UI.

Challenges and Solutions: 

• Challenge: Jumping and grounded detection were initially unreliable, especially around collider setup.

• Solution: I refined the movement logic and grounded checks so the system behaved more consistently and could support multiple jumps.

• Challenge: The player head and collider alignment became incorrect during movement changes.

• Solution: I adjusted the head and capsule relationship so the head remained correctly contained within the player collider.

• Challenge: Comfort settings needed to remain usable without breaking gameplay flow.

• Solution: I exposed the relevant settings in the UI while keeping the rest configurable in the Inspector for development control.

Screenshots/Images:

• None

Resources:

• • [Unity Rigidbody Manual:]

🔗 link 🔗

• [Unity XR Locomotion docs:]

🔗 link 🔗

• [Unity OpenXR Plugin Manual:]

🔗 link 🔗

Next Steps:

• Develop object interaction and grabbing in a way that matches the custom player architecture.

• Improve the relationship between gaze, hand pointers, and physical grabbing.

Introduction:

These weeks were spent building a fully custom grabbing system tailored to the project. Instead of using standard XR grab interactors, I implemented grabbing with colliders, cone-based detection, hand proximity checks, rigidbody following, and object-specific offsets.

This was one of the most important parts of the project because object interaction is central to the VR experience. The same system also needed to support future mini-games and items such as the battery and backpack.

Achievements:

• Implemented a GrabSubsystem using gaze, left-hand pointer, right-hand pointer, and hand proximity triggers.

• Added object highlighting and best-object selection inside trigger zones.

• Added grab offsets so items can sit naturally in the player’s hand.

• Improved root-object detection so complex objects with child colliders can still be grabbed reliably.

• Extended the system toward two-hand support so one hand can hold an item while the other performs a separate action.

Challenges and Solutions: 

• Challenge: Multi-collider objects sometimes highlighted correctly but failed to move properly when grabbed.

• Solution: I resolved the actual grabbable root object instead of using whichever child collider first entered the trigger.

• Challenge: Hand-only interaction was less reliable than pointer-based interaction.

• Solution: I added dedicated hand proximity logic so physical hand placement could support grabbing in a more natural way.

• Challenge: A single active-grab assumption limited more advanced interactions.

• Solution: I refactored the grab state so the system could support more independent left-hand and right-hand behaviour.

Screenshots/Images:

• None

Resources:

• [Unity Input System Manual:]

🔗 link 🔗

• [Unity Trigger Collider setup:]

🔗 link 🔗

• [Unity OnTrigger events:]

🔗 link 🔗

• [Unity Rigidbody Manual:]

🔗 link 🔗

Next Steps:

• Improve menu usability and add a better desktop testing workflow.

• Connect interaction systems to UI and scene management.

Introduction:

These weeks focused on usability, testing, and interaction with in-game menus. I improved the menu behaviour so the game could be paused without breaking UI interaction, and I also expanded the keyboard and mouse testing workflow to make iteration faster when a headset was not immediately available.

This stage was particularly useful for debugging because it reduced the need to build to device for every small logic change. It also made the project more practical to test during development.

Achievements:

• Improved the options UI so settings could be adjusted more reliably in-world.

• Added support for pausing gameplay while keeping menu interaction responsive.

• Updated time-dependent UI behaviour to use unscaled time where needed.

• Expanded PC testing mode so mouse and keyboard input can simulate VR head and controller behaviour for debugging.

• Added menu-related quality-of-life improvements such as hiding other UI panels while the menu is open.

Challenges and Solutions: 

• Challenge: Pausing the game with Time.timeScale = 0 caused menu interactions and some previews to stop working properly.

• Solution: I moved affected logic to unscaled timing so UI and previews could continue while gameplay remained paused.

• Challenge: Some buttons visually stuck after being disabled and re-enabled by menu flow.

• Solution: I reset the visual interaction state when objects were disabled so they returned cleanly when reactivated.

Screenshots/Images:

• None

Resources:

• [Unity UI overview:]

🔗 link 🔗

• [Unity Time.timeScale Scripting API:]

🔗 link 🔗

• [Unity Input System Manual:]

🔗 link 🔗

Next Steps:

• Build the first complete mini-game loop.

• Connect player systems, UI, and fail states into one playable scene.

Introduction:

At this point the first complete mini-game, the Mail mini-game, became the primary focus. The core concept was to avoid moving walls representing spam or malicious content while restoring corrupted inbox slots. This mini-game became the first real test of how well the shared player systems worked in a complete gameplay loop.

This stage was important because it transformed the project from a technical prototype into an actual game experience with goals, failure states, and progression.

Achievements:

• Implemented the Mail mini-game gameplay loop.

• Added moving obstacle walls and player failure states.

• Added a three-life structure and restart flow.

• Implemented hazard zones, tutorial messaging, and in-world UI updates.

• Connected the mini-game to the hub structure and return flow.

Challenges and Solutions: 

• Challenge: Scene-specific references such as the player root and life objects became difficult to manage once scenes were swapped.

• Solution: I added rebinding logic so scene objects could reconnect automatically after loading.

• Challenge: Restarting after failure needed to feel clear without becoming frustrating.

• Solution: I used reminder/tutorial messages, life tracking, and controlled restart delays to make the loop understandable.

• Challenge: Environmental boundaries needed better warning feedback.

• Solution: I introduced haptic warning walls so the player receives feedback before leaving the intended play area.

Screenshots/Images:

• None

Resources:

• [Unity SceneManager.LoadScene:]

🔗 link 🔗

• [Unity Coroutines Manual:]

🔗 link 🔗

• [Unity Trigger Collider setup:]

🔗 link 🔗

Next Steps:

• Improve scene transitions and persistent state between the hub and mini-games.

• Generalise game progress logic for future mini-games.

Introduction:

Once the first mini-game became playable, the next challenge was making the whole project behave like one connected experience rather than a collection of isolated scenes. I therefore focused on scene swapping, persistent managers, return positioning, and progression logic for entering and completing mini-games.

This work laid the foundation for the final structure of the project, in which the player can move from the hub into mini-games and return with progress preserved.

Achievements:

• Implemented persistent manager behaviour using DontDestroyOnLoad where appropriate.

• Created a MiniGameManager to track unlock state, completion state, and cooldown availability.

• Added door-based scene entry and return positioning.

• Added logic so completed mini-game doors can be removed or visually updated.

• Improved scene-load rebinding for gameplay systems and UI.

Challenges and Solutions: 

• Challenge: Persistent objects created duplication problems when scenes reloaded.

• Solution: I added duplicate protection and ensured only one active persistent instance survived scene transitions.

• Challenge: Player position was sometimes lost or restored incorrectly when changing scenes.

• Solution: I stored and reapplied explicit return positions after scene load completed, ensuring the player appeared in the intended location.

• Challenge: Scene-local references regularly broke after transitions.

• Solution: I added rebind logic in the relevant systems so objects could reconnect after each new scene became active.

Screenshots/Images:

• None

Resources:

• [Unity SceneManager.LoadScene:]

🔗 link 🔗

• [Unity Coroutines Manual:]

🔗 link 🔗

Next Steps:

• Expand secondary systems used inside the mini-games.

• Add battery gameplay, haptics, and stronger environmental feedback.

Introduction:

These weeks focused on secondary gameplay systems that increase immersion and communicate state to the player more clearly. A battery system was added to represent device power, alongside charger behaviour, haptic warnings, and low-battery notifications.

Although this was not a full mini-game by itself, it became an important support mechanic and helped reinforce the smartphone theme of the project.

Achievements:

• Implemented a battery percentage controller with visible strip feedback.

• Added low-battery notifications and repeated haptic warnings at critical thresholds.

• Created a charger interaction that accepts thrown battery objects.

• Added environmental haptic warning walls around the play area.

• Improved battery UI rebinding after scene swaps.

Challenges and Solutions: 

• Challenge: Scene changes caused battery UI strip references to break.

• Solution: I added rebinding logic and tag-based reassignment so battery strips could reconnect automatically in the active scene.

• Challenge: Trigger and collision setup for battery charging required reliable object detection.

• Solution: I standardised the interaction around tagged battery objects and improved detection logic for the charger.

• Challenge: Haptic warnings needed to be noticeable without becoming excessive.

• Solution: I tied haptic events to battery thresholds and environmental boundary triggers rather than playing them continuously.

Screenshots/Images:

• None

Resources:

• [Unity UI overview:]

🔗 link 🔗

• [Unity XR Input Manual:]

🔗 link 🔗

• [Unity InputDevice.SendHapticImpulse:]

🔗 link 🔗

• [Unity 6 Meta Quest workflow:]

🔗 link 🔗

Next Steps:

• Improve physical item handling through a wearable storage system.

• Extend interaction so larger carried objects can fit naturally into gameplay.

Introduction:

The focus of this stage was adding a physical backpack system to support inventory-style interaction in a way that still felt natural in VR. The backpack was designed as a real object that can be worn, grabbed, and used to store items rather than as a traditional 2D inventory interface.

This system also pushed the grab logic further because it required more flexible two-hand interaction. The player needed to be able to hold the backpack with one hand while retrieving or storing items with the other.

Achievements:

• Created a BackpackSubsystem integrated into the player architecture.

• Added physical storage slots for normal objects and a dedicated back slot for the backpack itself.

• Added item shrinking for stored objects while keeping the wearable backpack at full scale.

• Added DoNotStore and Backpack tag-based behaviour.

• Split the storage logic into separate item and backpack triggers for more precise control.

• Improved two-hand grab support so the backpack can be held while another hand interacts with stored objects.

Challenges and Solutions: 

• Challenge: The backpack trigger was too aggressive and could store objects while the player was still inspecting them.

• Solution: I changed the logic so storage happens when the grip is released below a configurable threshold rather than immediately on overlap.

• Challenge: One-hand grab assumptions prevented natural backpack interaction.

• Solution: I updated the grab system so left-hand and right-hand interactions could work more independently.

• Challenge: The backpack itself required different behaviour from normal items.

• Solution: I separated “items trigger” and “backpack trigger” logic and used tag-based routing to send the backpack to its dedicated back slot.

Screenshots/Images:

• None

Resources:

• [Unity Trigger Collider setup:]

🔗 link 🔗

• [Unity OnTrigger events:]

🔗 link 🔗

• [Unity Rigidbody Manual:]

🔗 link 🔗

Next Steps:

• Expand the number of mini-games supported by the shared systems.

• Continue improving item interaction as more mechanics are added.