Creating Custom Roles with the new VR-Engage SDK

Let's say you're a solutions engineer and you've been tasked with creating a helicopter door gunner simulator. You’ve been using VR-Engage in many roles (helicopter pilot, LAV driver, UAV sensor operator), but there is no Door Gunner role for helicopters and you're unsure where to start actually building it. You know how to use the existing roles within VR-Engage and have an idea about how VR-Engage uses a big library of components that make up those roles… but putting it all together to create this custom role seems daunting.

Alright pause. Before you freak out about creating this new role for players in your scenario, you should know that the new VR-Engage SDK in MAK ONE 2025 is about to make your life a lot better.

Real quick, let's start with a review of components in VR-Engage. Basically, a role is a configuration of different components - and those components can be anything from vehicles to weapon systems to turn signals. These are the pieces that, when combined, come together to build a role for your first-person simulation.

So back to your task. You need to make a helicopter door gunner role. For that, you'll need a helicopter model (already a component within VR-Engage, thank you RTDynamics) and a gunner system (clue: you can borrow this from an existing ground vehicle role). Here’s how to actually make this happen:

Understanding The Component Architecture

These components are defined within Dynamically Linked Libraries (DLLs), which are essentially plug-ins that VR-Engage loads when it runs. When you start VR-Engage, it loads the available components from the plugins folder. Each component has its own set of parameters that you can adjust to suit your specific scenario and role needs. These parameters are configured in Lua files and loaded at runtime.

Think of it like this: VR-Engage provides a library of LEGO blocks. Your job is to assemble these blocks into a door gunner role.

The VR-Engage Player interface is organized into several broad categories:

Vehicle Control Components - Observer positioning and camera management - Vehicle movement and navigation controllers - Environmental interaction systems

Weapon & Targeting Systems - Weapon control logic and firing systems - Targeting and sensor interfaces - Ammunition management

Player Interface Components - Input device handlers (joystick, keyboard, VR controllers) - Qt Quick UI overlays and HUDs - Audio systems and voice communications - Menu and dialog systems

Data & Communication Components - Network protocol handlers - Entity state synchronization - Mission data and scenario management

This modular approach means you can mix and match front-end components to create exactly the player experience you need - whether that’s a submarine sonar operator, tank commander, or helicopter door gunner.

Step 1: Identify Your Required Components

For a helicopter door gunner role, you’ll need these key components:

  • RTDynamics helicopter model (included)
  • Weapon system logic (borrow from existing ground vehicle gunner roles)
  • Observer/camera positioning (use the included Gunner Observer Updater to position the player’s viewpoint)
  • Input handling (configure the included Gunner Control Logic with appropriate input mappings)
  • UI overlay (adapt the existing gunner HUD using the QtQuick Overlay)

Step 2: Create Your Role Configuration Script

Next, you’ll write a simple Lua script to assemble these components into a coherent role. The Lua code acts as the glue between all the connections of your new role. It directs which components will be instantiated when you engage into the role at runtime. 

To see how it might look, download the unabridged version of this article that includes example script.

Step 3: Configure Entity File Parameters

This is where you’ll associate your new role with a particular simulated entity by adding it into your entity file. There are several elements of this to consider.

Weapon System Integration

The door gunner role requires a weapon system component that can handle the M60 machine gun. VR-Engage includes a number of weapon systems out of the box that can adapted for a variety of weapons (rifles, handguns, cannons, missiles, etc.). 

This weapon system connects to the articulated part defined in our full example and references an ammunition table that maps the DIS entity types to specific ammunition loads.

Now, you’ll want to add a weapon system to your entity configuration. You’ll also need to ensure your helicopter entity file includes the proper articulated parts for weapon mounting and role support, so go ahead and configure the weapon mount points here too.

Again, you can find example code for this here

Input Configuration

To define how player controls map to weapon functions, you’ll create a separate input configuration file. The control logic component reads these mappings and automatically connects them to the weapon system’s input ports. For example, when a player moves the mouse, the mouse motion mappings translate those movements into commands that are sent to the weapon controller.

The input system works through a straightforward message flow: your input configuration maps physical device actions (joystick buttons, mouse movement, keyboard presses) to logical commands (“fire weapon”, “aim left”, “reload”). The Gunner Control Logic component converts these device inputs into standardized simulation messages that flow through VR-Forces’ component communication system. These messages are then received by the appropriate simulation components - weapon controllers receive firing commands, observer components receive aiming commands, and so on.

This approach keeps your role configuration simple while ensuring that complex input handling, device compatibility, and simulation message routing are handled automatically by the underlying VR-Forces infrastructure. 

Customizing the User Interface

Beyond simulated behavior, you might want to customize the user interface for your door gunner role. VR-Engage uses Qt Quick/QML for its UI overlay system, making it straightforward to create custom interfaces. 

See the full example here.

Step 4: Test and Iterate

Once you’ve written your Lua configuration script, place it in your VR-Engage roles directory and test it in a scenario. The great thing about this approach is that you can rapidly iterate - adjust viewpoint positions, weapon parameters, and input mappings by simply editing the Lua files.

Common adjustments include fine-tuning the observer position for realistic door gunner viewpoints, configuring appropriate weapon elevation and azimuth limits for helicopter door mounts, and ensuring proper ammunition handling.

Going Further with Custom Components

Let's take it a step further now and say that you've been tasked with extending a ground vehicle’s functionality – for example, adding a turn signal system. This is functionality that doesn’t exist out of the box in VR-Engage. That's where the new VR-Engage C++ API comes in. You can write C++ code to extend our library of input controllers, plug them in, and configure them into your new role.

If the existing components don’t meet your needs, you can develop custom ones using the VR-Engage C++ API. For example, to create a custom turn signal system for your ground vehicle, you’d need to work on both sides of the VR-Engage architecture:

Front-end Player Component: 

  1. Inherit from DtPlayerComponent to create your custom UI and input handling component 
  2. Implement the required interfaces for initialization, update cycles, and cleanup 
  3. Define custom data messages for communicating turn signal state to the simulation engine

Back-end Simulation Component: 

  1. Extend the entity’s simulation behavior by adding turn signal logic to the sim engine 
  2. Modify entity state data to include turn signal status in the data exchanged between front-end and back-end, and with others on the simulation network.
  3. Compile both components into DLLs and place them in the plugins directory 
  4. Register your components in your Lua role configuration

This will get your turn signals working correctly in the simulation (affecting AI behavior, network traffic, visual models) while providing intuitive player controls in the VR-Engage interface. The SDK provides the means for message passing between your front-end player controls and back-end simulation logic. And any new state data can be sent from the simulation to the front-end and reflected in a custom UI for the role.

And at a high level, that's it. 

You can rest easy because the VR-Engage SDK comes with examples and documentation so you aren't starting from scratch when you're building your new roles. The examples directory contains over a dozen working implementations covering everything from vehicle blinkers to custom projectile systems - perfect references for your door gunner development. 

And as mentioned several times, here's the full, unabridged version of this blog post that includes examples of everything mentioned above.

Hope you enjoyed this walkthrough of creating custom roles within VR-Engage using the new SDK coming with the MAK ONE 2025 release!

(Oh and just so you know, VR-Engage comes with ground models [including many 10- and 12-wheeled vehicles - new with this release] for you to experiment with!)

Hungry for more?

Learn more about this and the rest of what's included in the MAK ONE 2025 release at our recent webinar "A First Look at What's Coming in MAK ONE" with Jim Kogler!

ST Engineering

ST Engineering

Save
Cookies user prefences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Essential
These cookies are needed to make the website work correctly. You can not disable them.
Support
Assists delivery of support services to customers
Accept
Vimeo
Supports video display through the content delivery network
Accept
mak.com
Session cookie - required for user logins to work correctly
Accept
Analytics
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics
Aggregated user information key used to identify website use trends
Accept
Decline
Marketing
Keys used to analyze data to measure the effectiveness of third party marketing efforts and inbound network traffic.
Google
Advertising key used to track the efficacy of targeted marketing efforts
Accept
Decline