How to Build VR Apps with TypeScript Using the Adamas SDK
Most VR development today still starts with the same assumption: open Unity, write C#, build a standalone app, and ship the entire experience as one package.
That workflow works. Unity and Unreal are still powerful tools, and a lot of amazing VR software has been built with them. But as I spent more time building VR projects, especially multiplayer ones, I kept running into the same feeling: a lot of VR development is not really about the app idea itself. It is about rebuilding the same infrastructure again and again.
Avatars. Locomotion. Object interaction. Multiplayer rooms. Project setup. Build pipelines. Distribution.
For small VR projects, prototypes, research demos, social experiences, and creative tools, that overhead can be way too much.
Adamas VR is an attempt at a different workflow.
Instead of treating every VR project as a full standalone application, Adamas lets you build VR projects as regular TypeScript / Node.js packages that can be loaded into a shared VR runtime. The runtime provides common VR infrastructure, while your project focuses on the actual content and behavior.
In other words, your VR project can feel much closer to writing a normal TypeScript package.
Why TypeScript for VR?
TypeScript is already one of the largest developer ecosystems in the world. It has great tooling, package management, type checking, and a huge number of developers who already know how to build with it.
For many software developers, especially people coming from web, backend, or tooling backgrounds, TypeScript is much more familiar than a game-engine-specific workflow.
That is one of the reasons Adamas uses TypeScript.
The goal is not just to use TypeScript as a scripting language. The goal is to make VR development fit better into the broader JavaScript and Node.js ecosystem.
That means:
- Projects can be structured like normal npm packages.
- Dependencies can come from the JavaScript ecosystem.
- Code can be edited with familiar tools like VS Code.
- Developers can build and iterate without treating every project as a full engine project.
- VR logic can be shared, reused, and composed more naturally.
A simple Adamas project should feel more like this:
import { Project, TransformManager } from "@adamasvr/sdk";
import { projectBundle } from "adamasvr:editor";
import { vec3 } from "gl-matrix";
Project.FromBundle(projectBundle).Launch(async (sceneGraph, project) => {
const cube = sceneGraph["@Cube"].entityId;
await TransformManager.SetWorldPosition(cube, vec3.fromValues(0, 1.2, -2));
});
This is the kind of workflow Adamas is exploring: define objects, behaviors, and interactions through TypeScript, then load the project into a runtime that already understands VR.
How is this different from Unity?
Unity gives you a full game engine. That is great when you need full control over rendering, physics, platform builds, asset pipelines, and game-specific systems.
But for many VR projects, especially early-stage experiments, the full-engine workflow can feel heavy.
If you want to make a small multiplayer VR tool, you still need to deal with:
- XR rig setup
- avatar representation
- hand/controller interaction
- networking setup
- room/session management
- distribution
Adamas tries to move more of that common infrastructure into the runtime.
Instead of every project rebuilding those systems, the project can focus on what makes it unique.
For example, if you are building a point cloud viewer, a collaborative whiteboard, a small physics toy, an education demo, or an interactive research prototype, you should not need to rebuild the entire multiplayer VR stack first.
With Adamas, the runtime provides the shared space. Your TypeScript project provides the app logic.
That is the core difference.
Unity is an engine-first workflow.
Adamas is closer to a package-first workflow.
How is this different from WebXR?
WebXR is also JavaScript-based, so it is natural to compare Adamas with WebXR.
WebXR is great because it brings immersive experiences to the browser. It is open, web-native, and easy to access. For many use cases, especially lightweight demos, it is a good choice.
But Adamas is aiming at a different layer.
Adamas is not just trying to display VR content through a browser API. It is trying to provide a shared VR runtime where multiple TypeScript projects can be loaded, composed, and experienced together.
The difference is less about syntax and more about the application model.
With WebXR, you usually build a web app that enters an immersive session.
With Adamas, you build a VR project package that runs inside a larger multiplayer runtime.
That runtime can provide shared infrastructure such as:
- avatars
- locomotion
- multiplayer presence
- interaction primitives
- room/session support
- project composition
So instead of every WebXR app being its own separate world, Adamas explores what happens when VR projects can be smaller, more modular, and loaded into a shared space.
What value does the Adamas SDK provide?
The Adamas SDK is designed around a few core ideas.
First, VR projects should be easier to start. A developer should be able to create a project, write TypeScript, and see something running in VR without spending days setting up the same boilerplate systems.
Second, multiplayer should not feel like an advanced feature you add at the end. It should be part of the runtime from the beginning.
Third, projects should be shareable and composable. A VR project should not always need to be a full app store-style application. Sometimes it can be a tool, a scene, a simulation, an interactive object, a visualizer, or a small experiment.
Fourth, the development workflow should feel familiar to people who already build software with Node.js and npm.
That is why Adamas projects are designed to fit into the TypeScript ecosystem.
A project can have a structure like:
my-adamas-project/
├── .adamas/
│ ├── generated.d.ts
│ └── project.json
├── index.ts
├── package.json
└── tsconfig.json
And the project can be installed, updated, and managed like other npm-based code.
A simple tutorial: creating your first Adamas project
A basic Adamas project starts with a normal Node.js package.
mkdir my-first-vr-project
cd my-first-vr-project
npm init -y
npm install @adamasvr/sdk gl-matrix
npm install -D typescript @types/node
Then create an index.ts file:
import { Project, TransformManager } from "@adamasvr/sdk";
import { projectBundle } from "adamasvr:editor";
import { vec3 } from "gl-matrix";
Project.FromBundle(projectBundle).Launch(async (sceneGraph, project) => {
const cube = sceneGraph["@Cube"].entityId;
await TransformManager.SetWorldPosition(cube, vec3.fromValues(0, 1, -2));
await TransformManager.SetLocalScale(cube, vec3.fromValues(0.4, 0.4, 0.4));
});
The exact project loading flow depends on the current Adamas runtime and tooling version, but the core idea is simple: your TypeScript entry point defines what the project adds to the VR scene.
You are not creating a whole VR application from scratch.
You are creating a project that can run inside a virtual space.
Adding behavior
A static object is useful, but the fun starts when it has behavior.
For example, imagine we want an object that slowly rotates:
import { Project, TransformManager } from "@adamasvr/sdk";
import { projectBundle } from "adamasvr:editor";
import { quat } from "gl-matrix";
Project.FromBundle(projectBundle).Launch(async (sceneGraph, project) => {
const cube = sceneGraph["@Cube"].entityId;
let yaw = 0;
project.ScheduleUpdate(async (timestep) => {
yaw += (timestep / 1000) * 45;
const rotation = quat.create();
quat.fromEuler(rotation, 0, yaw, 0);
await TransformManager.SetLocalRotation(cube, rotation);
});
});
This is the kind of pattern Adamas is designed for: write project logic in TypeScript, attach behavior to entities, and let the runtime handle the VR environment around it.
What can you build with this?
The early use cases I am most excited about are small to medium VR projects that benefit from being multiplayer and easy to share.
For example:
- collaborative design tools
- 3D data visualization
- education demos
- virtual exhibition spaces
- XR research prototypes
- interactive training simulations
- small social VR apps
Some of these could be built in Unity, WebXR, or Unreal. The point is not that Adamas replaces all of them.
The point is that Adamas gives developers another option: a TypeScript-first workflow where the runtime handles the common VR layer and the project stays closer to a normal software package.
Why this matters in 2026
VR hardware keeps getting better, but software development still feels harder than it should be.
A lot of people are interested in building for VR, but the cost of starting is high. Even small projects often require learning a full game engine, understanding XR setup, handling multiplayer, managing builds, and solving distribution.
In 2026, I think there is room for a more lightweight, modular, developer-friendly way to build VR apps.
That is what Adamas VR is trying to explore.
Not every VR project needs to be a massive standalone app.
Some VR projects should feel like packages.
Some should feel like tools.
Some should be small interactive things you can load into a shared space and use with friends, collaborators, students, or users.
That is the direction Adamas is moving toward: a TypeScript SDK and runtime for building multiplayer VR projects that are easier to create, share, and experience together.
If you are a TypeScript developer, a VR developer, a creative coder, or someone who has wanted to build VR apps but found the traditional workflow too heavy, Adamas might be an interesting place to start.