A VR Fruit Ninja-inspired prototype in Unreal Engine 4: sword grabbing, destructible mesh slicing, and score-based game loop.
This project is a VR game prototype built entirely in Blueprints with Unreal Engine 4, developed following this Udemy course. It’s the earliest VR project in this series and the only one built in UE4 rather than UE5 — a useful baseline for understanding what changed in the UE5 VR development experience. The concept is simple and immediately readable: fruits are launched into the air, the player slashes them with a virtual sword, and the score accumulates. It’s a direct translation of the Fruit Ninja formula into room-scale VR.
You can watch the prototype in action here: YouTube
Why Fruit Ninja Translates Well to VR
Fruit Ninja on mobile works because the slashing gesture — a swipe across the screen — maps naturally to the touchscreen input. In VR, this gesture maps even more naturally: the player is physically swinging a controller through space, which is precisely the motion the game is designed around. The VR version adds the depth dimension — fruits fly toward and past the player in 3D — which makes the spatial judgment of when and where to swing more demanding and more satisfying than the 2D original.
The game’s appeal in VR comes from the physicality of the interaction: the player is actually swinging their arm, and the feedback from successfully slicing a fruit — the visual split, the particle burst, the sound — arrives as a direct response to a real physical action. This physical feedback loop is what makes simple VR games feel rewarding in a way that screen-based equivalents don’t.
Sword Grab Implementation
The sword is a grabbable actor — the player picks it up from a holder position at the start of the game and holds it for the duration. The grab implementation in UE4 follows the same physics constraint approach described in the VR Mechanics project: the sword is attached to the grip hand via a physics constraint that moves the sword toward the controller position each frame, preserving physics simulation rather than teleporting the object. This produces a grab that feels physically weighted rather than magnetically snapped.
Once grabbed, the sword is held rigidly in the dominant hand — there’s no two-handed grip for this implementation, since the sword is designed for one-handed slashing. The sword’s orientation follows the controller’s rotation directly, giving the player full angular control over the slash angle.
Destructible Meshes: Fruit Slicing
The fruit slicing effect uses Unreal’s Destructible Mesh system — a feature that fractures a static mesh into predefined chunks that separate and physics-simulate when a destruction event is triggered. Each fruit actor has a Destructible Mesh component configured with a radial fracture pattern that produces the characteristic clean halves of a sliced fruit.
When the sword’s sweep trace (active during the swing, inactive at rest — the same notify-gated trace pattern from the melee combat project) intersects a fruit actor, it triggers the destructible mesh’s fracture event. The fruit breaks along its predefined fracture plane at the hit location, with the two halves flying apart in the direction of the sword’s momentum. A particle burst and a slice sound play at the impact point for audiovisual feedback.
It’s worth noting that UE4’s Destructible Mesh system (based on NVIDIA PhysX Apex) was deprecated in UE5 in favor of the Chaos Destruction system covered in the Chaos Destruction project. The conceptual outcome is similar — a mesh that fractures into physics-simulated pieces — but the implementation layer is completely different between the two engine versions.
Fruit Spawning and Trajectory
Fruits are spawned from spawn points positioned outside the player’s field of view and launched with an initial velocity that carries them into the player’s space, arcing under gravity. The spawn timing is randomized within a configurable interval — frequent enough to keep the player active but spaced enough that the player can track each fruit individually.
The fruit trajectory needs to be tuned so that fruits pass through a reachable zone — not too fast to track, not so slow they feel floaty, and at a height and angle that requires actual swinging rather than minimal wrist movement. Getting this trajectory feel right is one of the main design tuning tasks of the game.
Fruits that aren’t sliced and fall below a threshold height are destroyed and penalize the score — the same penalty model as Fruit Ninja. This creates dual pressure: hit the fruits for positive score, but don’t miss them either.
Score System and Game Loop
The game loop is simple and clear: the score increments with each successful slice, decrements or ends the game on missed fruits, and ends after a fixed time or when the player accumulates too many misses. The score is displayed in the HUD — a world-space widget visible within the VR field of view — and a final score screen appears when the game ends.
The HUD in VR requires specific placement considerations that don’t apply to flat-screen games. A widget attached to the player’s head (following the headset) can be readable but feels unnatural — the UI moves with every head movement. A widget positioned in world space at a fixed location in front of the player’s starting position is more natural but requires the player to turn to look at it. The standard solution for simple score displays in VR is a small, unobtrusive world-space widget placed in the peripheral view area — visible without requiring a deliberate head turn.
Quixel Fruits and Visual Presentation
The fruit meshes are sourced from Quixel Bridge — photorealistic fruit scans that provide the visual quality the game’s close-up inspection requires. In VR, objects are perceived at real-world scale and proximity, which means low-quality assets are immediately apparent in ways they wouldn’t be on a flat screen. Quixel’s scan fidelity holds up to VR’s close-range scrutiny.
The visual feedback on slice is as important as the interaction itself — a clean particle burst, juice splatter decals, and flying halves all contribute to the satisfaction of the mechanic. Each of these elements is a Niagara system or a decal spawned at the slice point, layered together to produce the multi-sensory response that makes the slice feel impactful.
UE4 vs UE5 for VR Development
This project sits at the beginning of the VR learning arc in this series, before the UE5 VR Mechanics and VR Prototypes projects. The primary practical difference between UE4 and UE5 for VR development is the XR plugin layer: UE4 uses the OVR plugin for Oculus devices; UE5 recommends OpenXR, which provides a cross-platform abstraction that works across headset manufacturers. The Blueprint-level VR development experience is similar between the two versions — the pawn setup, the motion controller components, and the grab mechanics are conceptually identical — but UE5’s OpenXR integration is more future-proof and actively maintained.
The deprecation of Destructible Meshes between UE4 and UE5 is the most significant practical difference for this specific project. Migrating a Fruit Slayer prototype to UE5 would require replacing the Destructible Mesh system with Chaos Geometry Collections — a more capable but more complex system that produces better results at the cost of a steeper setup process.
Reflection
The Fruit Slayer prototype is the simplest complete VR game in this series — one mechanic, one game loop, clear win/lose feedback. Its simplicity is what makes it a good starting point for VR development: it isolates the fundamental challenges of VR interaction (grab, swing, hit detection, physical feedback) without the complexity of navigation, AI, or multi-system design. Every more complex VR project in this series builds on the foundation established here.
The Fruit Ninja inspiration is instructive beyond the specific game. The most successful VR experiences tend to be those that find an existing gesture that people find satisfying and make it the core interaction. Slashing, throwing, archery, climbing — all of these are physical actions that VR can make feel real in a way no other medium can. The design challenge is finding the gesture first, then building a game around it.
Nicolás Bertoa 
Leave a comment