HN Explorer

Show HN: Unity like game editor running in pure WASM (raverie-us.github.io)

644 points by TrevorSundberg ↗ HN
In the wake of all the Unity nonsense, just wanted to toss the Raverie engine into this mix :)

We’re building off a previous engine that we worked on for DigiPen Institute of Technology called the Zero Engine with a similar component based design architecture to Unity. Our engine had a unique feature called Spaces: separate worlds/levels that you can instantiate and run at the same time, which became super useful for creating UI overlays using only game objects, running multiple simulations, etc. The lighting and rendering engine is scriptable, and the default deferred rendering implementation is based on the Unreal physically based rendering (PBR) approach. The physics engine was built from the ground up to handle both 2D and 3D physics together. The scripting language was also built in house to be a type safe language that binds to C++ objects and facilitates auto-complete (try it in editor!)

This particular fork by Raverie builds both the engine and editor to WebAssembly using only clang without Emscripten. We love Emscripten and in fact borrowed a tiny bit of exception code that we’d love to see up-streamed into LLVM, however we wanted to create a pure WASM binary without Emscripten bindings. We also love WASI too though we already had our own in memory virtual file system, hence we don’t use the WASI imports. All WASM imports and exports needed to run the engine are defined here: https://github.com/raverie-us/raverie-engine/blob/main/Code/...

The abstraction means that in the future, porting to other platforms that can support a WASM runtime should be trivial. It’s our dream to be able to export a build of your game to any platform, all from inside the browser. Our near term road-map includes getting the sound engine integrated with WebAudio, getting the script debugger working (currently freezes), porting our networking engine to WebRTC and WebSockets, and getting saving/loading from a database instead of browser local storage.

Our end goal is to use this engine to create an online Flash-like hub for games that people can share and remix, akin to Scratch or Tinkercad.

https://github.com/raverie-us/raverie-engine

165 comments

[ 3.9 ms ] story [ 220 ms ] thread
Ashwinning
Holy wow, opened this on my phone and it was like unity editor was running on mobile with a smooth 3D viewport!

Gotta give this a shot on desktop later.

TrevorSundberg
The mobile version needs a lot of work! But we'd love to support the full editor on phones eventually :P
kaliqt
So I take it that this would be the highest performing + most customizable engine for web deployment due to its deep WASM nature? What about rendering, does it use WebGPU?
meheleventyone
Poking the code it looks like it's based on an OpenGL renderer translating to WebGL2.
TrevorSundberg
I'm sure there are higher performing engines out there, but it certainly should be easily deployed to any site. For rendering, this engine currently just uses WebGL. It was built on OpenGL originally (with a swappable renderer backend so we could target other 3d APIs). Eventually we may support WebGPU when support grows among the other browsers.
raytopia
I'd guess Threejs or Babylonjs would be because they're web first but regardless super cool project!
meheleventyone
This is super cool, it's great to see a pure WASM offering in this space. It does chug quite a bit on my M1 Mac Pro though!
[deleted]
(comment deleted)
a2128
This looks great! Some feedback - I clicked on the link and tried to find out if it's on GitHub. I looked in Help > About but it didn't seem to have much. Then I clicked on Help > Documentation and it brought me to a 404
TrevorSundberg
Ah sorry about that, this is still a big work in progress. A lot of the old links have died so we're porting over things like documentation still. I'll add a back-link to the github!
notpushkin
Very slow load in Firefox – stuck on “Downloading Runtime”. No error in console, and the .wasm file is stuck in the loading stage in the Network tab – a few minutes first time, 20 seconds now (with cache cleared). No such problems in Chromium. Weird!

Overall though it's a cool project. Personally I would prefer if it was a desktop app as well (with better integrations and less overhead – and certainly with hi-res support!). Congrats on the launch!

GabeIsko
Worked fine for me in Firefox.
notpushkin
Probably some very flaky issue then. My current ISP isn't very reliable, although everything else seems to work fine right now.
TrevorSundberg
I haven’t done a lot of testing with Firefox, I’ll take a look!
sakras
Wow you guys wrote Zero Engine? I used it in summer camps at DigiPen a long time ago, I really enjoyed using it and programming in Zilch (I wrote an AI that played a galaga clone!). This Unity fiasco had me wondering how Zero was doing. Seems like it's going to have a resurgence! Super exciting!
TrevorSundberg
That's so cool! Zilch was my baby, that makes me so happy :D
adamrezich
Zero/Zilch was great, and I wish DigiPen would've stuck with it! I heard that these days, they don't even have students make games from scratch anymore, and everyone just uses Unity or Unreal instead—any idea if that's true? it would be a bummer if it were, because striving to make a cool engine (especially once Zero was there as something to aspire to!) was like the best and most useful part of my time at DigiPen.

glad to see the spirit of Zero still going strong through Raverie, though!

TrevorSundberg
I heard the same thing and I really hope what they're doing is for the best. It would have fundamentally changed my path if I didn't get that core low level experience of building game engines.
DougZwick
I teach GAM 300/350 at DigiPen. We still require them to create custom engines in their sophomore year, but in their junior year (and beyond, in some cases), they're all using commercial engines. One of the main things we want to focus on is giving them a chance to work on a truly cross-discipline team, where every member has a chance to thrive at their work, regardless of their degree program. If you're a student of game design or art, it can be very stressful to be on a team with a custom engine, because the bar is so high for them to provide the features you need to get your work done and accomplish your goals. If the engine and its editor and other support tools are all already completed when the project begins, these stresses and barriers are removed. Meanwhile, the programming students get a chance to work in an existing engine, which is applicable for the career trajectories of so vastly many of them, who will graduate and go on to work for companies that are using an existing engine (possibly even the one they used in GAM class). If they use Unreal, they're often working in C++, interfacing directly with the engine code. These are valuable experiences as well.

I have an imperfect perspective of the students' attitudes, but it seems to me that they tend to agree with my point of view: at the beginning of the year, I said, "Raise your hand if you wish you'd be working on a custom engine this year," expecting to see a few dozen hands go up. Surprisingly, only about one and a half hands were raised! Working on a custom game engine is an amazing and unique experience, but it's not the end-all-be-all of game programming.

adamrezich
I think it's great that sophomores still have to make their own engine from scratch.

making two engines, one in C for GAM150, and another in C++ for GAM200, were extremely formative experiences for me. when I was attending DigiPen, it was at the beginning of the ECS craze, so, naturally, I implemented terrible, extremely naive ECSes, in C and C++. they were woefully inefficient and byzantine to the point of ridiculousness (look up Game School Simulator 2015 on the DigiPen student games site—its framerate is terrible, despite rendering just consisting of a few dozen sprites), but I learned so much from making them—both good and bad. I especially enjoyed GAM200 when we got to have artists who had any spare time to work on a GAM project, because working with them to integrate them into the workflow was an amazing experience.

I understand that DigiPen wants to provide students with as much career opportunity as possible, and that means Unity and Unreal. or rather, it did mean Unity and Unreal, until very recently—now, it's kinda just Unreal. and Unreal isn't going away anytime soon, of course—but that's what we would've said about Unity just a short while ago.

even though it's certainly the pragmatic choice as far as getting a job after graduating goes, personally I firmly believe it's a mistake to forgo having students make their own engines after sophomore year. at least when I was there, there was borderline zero education about how to even go about making a game engine, despite requiring teams to make one, so there was that—but there was also a vibrantly competitive culture of one-upmanship among students, and it was fun to see what other teams were working on, and strive to do better and cooler stuff yourself. (Josh Fisher, if you're somehow reading this for some reason, your shit was always way better than mine and I was always super jealous.)

if students stop learning about how video games work at any lower level than "just use an off-the-shelf general-purpose game engine", then who's going to make game engines going forward? some of the smartest classmates I had were guys who put their heart and soul into their engine projects, and they all went on to find success one way or another as far as I know.

perhaps more importantly—and I only say this now with a decade of hindsight and experience since then—you don't need to make a general-purpose game engine in order to make a video game. our GAM 150 game did not need an ECS written in C to function. when I look at the code now, it's completely unreadable—everything is strewn about in random files, tenuously connected, such that it's a real archeological task to even figure out how the (extremely simple) core logic of my GAM 150 game even works. like I said, I really appreciate having had the experience of making terrible garbage tech, such that I could go on to learn how to do better. but it would've been even better if we had better instruction from professors, explaining that you don't need any of these fancy features to make a fully-functioning video game, especially on the scale of what's expected of a GAM 150/200 team.

I worry that going forward, the new generations of video game programmers are going to be too entrenched in thinking about things in terms of how e.g. Unreal does them, rather than what the solution to a given problem necessarily entails at the minimum level. sure, these people will be able to go onto find work in the industry at Unreal shops, but then what happens in the (admittedly extremely unlikely) event that something happens to Unreal as it did to Unity?

I don't know what DigiPen has been like in the past decade, but after I dropped out and talked to students from other game schools, it sounded like they had always, even back then, been pretty much Unity-centric—what happens to their former students now that Unity's in the situation it's in? do they feel cheated, like the only way...

johnnyanmac
>if students stop learning about how video games work at any lower level than "just use an off-the-shelf general-purpose game engine", then who's going to make game engines going forward?

could this be a specialization or "minor", perhaps?

IDK, it's tough. I want more students to be learning this stuff while in a proper environment, but the reality is that so much of the real tricks and sauce are either a) buried deep, deep inside some "public" repos, or more likely b) tribal knowledge at a AAA studio. Maybe Digipen is different as a gaming focused school, but I never learned about ECS or object pooling or profiler usage or especially cache coherency in college. And I'd struggle grouping all these important engine concepts into a course since the knowledge is simultaneously disparate but related. each topic could be its own thesis if you wanted them to be.

>what happens to their former students now that Unity's in the situation it's in? do they feel cheated, like the only way that they know how to make games, the way they were taught, has now been somewhat invalidated?

custom engine or not, I do adamantly feel like a proper game dev program should teach enough CS chops for this to not be a problem. using a high level engine is useful, but the rest falls on fundamentals. Data structures and algotithms to know what to use to group data together and the tradeoffs, systems level programming to understand memory management (yes, even in Unity. Intuiting the cost of allocating and deleting game objects only helps. Any one of mulitple of various domains (network, graphics, databases, UI) to get different perspectives on how data can be structured and processed, etc.

adamrezich
> Maybe Digipen is different as a gaming focused school, but I never learned about ECS or object pooling or profiler usage or especially cache coherency in college.

I could write maybe a short pamphlet's worth of information that I wish I was taught by professors while I was at DigiPen that would've made all the difference in the world to me at least. the existence of cache coherency is definitely one of these topics, but ECS definitely is not. it would just be a few other general ideas, like:

“hey, y'know how you just learned about malloc() and free() in CS 120 when you learned C? well, it's not a good idea to be calling those all the time in your game. instead, have something like this:

    #define MEMORY_NEEDED 1024 * 1024 * 4 /* adjust as needed */
    unsigned char all_the_memory_you_need[MEMORY_NEEDED];
    size_t end_of_game_memory  = 0;
    size_t end_of_level_memory = 0;
    size_t end_of_frame_memory = 0;

    void *alloc_for_game(size_t bytes) {
        assert(end_of_game_memory + bytes <= MEMORY_NEEDED);
        void *ptr = all_the_memory_you_need[end_of_game_memory];
        end_of_game_memory += bytes;
        return ptr;
    }

    void *alloc_for_level(size_t bytes) {
        assert(end_of_level_memory + bytes <= MEMORY_NEEDED);
        void *ptr = all_the_memory_you_need[end_of_level_memory];
        end_of_level_memory += bytes;
        return ptr;
    }

    void *alloc_for_frame(size_t bytes) {
        assert(end_of_frame_memory + bytes <= MEMORY_NEEDED);
        void *ptr = all_the_memory_you_need[end_of_frame_memory];
        end_of_frame_memory += bytes;
        return ptr;
    }

    void reset_frame() { end_of_frame_memory = end_of_level_memory; }
    void reset_level() { end_of_level_memory = end_of_game_memory; reset_frame(); }

    /* likely not quite perfect sample implementation but you get the gist */
check it out: now instead of malloc() and free()ing everything everywhere all the time and worrying about memory leaks, we have "lifetimes" now, one that's per-frame, and one that's per-level (if your game needs levels). you just use alloc_for_game() to allocate stuff that your whole game needs at the start of the program's execution, and then you reset_level() and alloc_for_level() when you change levels, and reset_frame() at the end of your frame and alloc_for_frame() during it, and bam, now you don't need to worry about memory leaks, you don't need garbage collection, and your temporary bump allocator is reset and ready for the next frame—and the only cost was resetting a single variable to zero in a couple key places. neat, huh?”

stuff like that—stuff that's super basic and easy to understand once it's explained to you, but that most people wouldn't intuitively conclude on their own, especially when you're new to game programming and just chasing cargo cults like ECS without sufficiently understanding how stuff really works. for example, the ECS I wrote in C was terrible in part because I only understood the high-level ideas at the time—the whole thing was (hysterically, when looking back now) implemented with linked lists, as I was approaching systems design in terms of API, instead of actual functionality.

once you've taken a CS course to learn the basics of C, and a math course to learn the basics of matrix math and how it pertains to game programming (both of which were excellent at DigiPen, by the way!), you're just a few pointers like these away from being able to completely—and relatively competently—implement your own 2D "game engine", given that you're using external libraries for e.g. rendering, input, and sound playback.

but then, of course, the resulting student games whose screenshots and video clips you gather to use for promotional material for your school wouldn't be as flashy, compared to contemporaries who only teach e.g. Unity...

johnnyanmac
>the ECS I wrote in C was terrible in part because I only understood the high-level ideas at the time—the whole thing was (hysterically, when looking back now) implemented with linked lists, as I was approaching systems design in terms of API, instead of actual functionality.

well that sounds awful. I wasn't making too deep a thought on which topics I'd throw onto a curriculum, but I'd hope that they wouldn't treat ECS like some pattern to memorize like some design patterns in my SWE course (literally called "software engineering". Quite confusing in retrospect). It should be treated as a way to apply and understand some data oriented design so you can make informed decisions on how to implement things.

I'm especially a fan of always identifying any and all shortcomings of an approach too. Because there's no better way to understand an approach than to reason about with its weaknesses. ECS is nice but you shouldn't try to shove it in stuff that requires tight complex coupling (e.g. a playercontroller), nor for random, infrequent events (UI input). And of course, if you are making a small game that can almost entirely fit in RAM anyways (well, in theory. Desktop OS's wouldn't allow this, obviosuly) these patterns are overkill and a half

>of course, the resulting student games whose screenshots and video clips you gather to use for promotional material for your school wouldn't be as flashy

well that is reflective of the modern game industry, haha. I imagine even in a place like digipen where you are working with motivated game artists that there's still technical constraints to consider with the art team (especially students). And building tools to help with that would take as long as the small game.

I did ponder if it'd be a good idea to have a CS game dev course each some basic 2d/3d art, and vice versa for an artist learning some CS101 style stuff. But the CS curriculum was already jam packed as is, at least at my alma mater. I believe the average course work required 170 units and CS (like other engineering degrees) was topping out at 190.

son_of_gloin
Hey Doug, it’s Avi Eisner - long time no see! Dan told me you’re working on your own game engine - would love to see it some time and catch up!
TrevorSundberg
I second that!
DougZwick
Trev, I think the last time we had breakfast together, I had already caught you up on the latest developments of my engine which is now gathering e-cobwebs over in its Github high-density urban housing development repo. Doesn't mean we shouldn't have breakfast again anyway!
DougZwick
Hi Avi! Great username. I assume the Dan you're talking about is my brother-in-law, because I don't recall telling Danny about my engine. It's true, technically: I was working on a game engine in JavaScript and then later TypeScript and then later JavaScript again, and since I haven't literally deleted the repo, I guess you could say I'm still working on it, but it's pretty far from the top of my priority stack right now. Still, I'd be happy to chat about it sometime, even if I can't really show anything running in it! I'll send you a message and we can catch up.
son_of_gloin
Thanks, yep - I had lunch with Dan last week. I understand, I have a half-dozen coding projects that I’ve got in various stages of (in-)completion.
wahnfrieden
do you know what engine was in use or development during around 2002-2003? the engine was somewhat baked but flexible and had entry points where you drop c++ snippets in, I believe with a GUI
sakras
Was it a 2D game engine? I recall before using Zero I used an engine called ProjectFUN, which is similar to what you described. That was around 2013 though, not 2002.
GabeIsko
Very cool! I can't seem to get the script editor open in the demo though.
WatchDog
Cool project.

Is there any way to scale the UI for high dpi displays?

On a 2:1 display, the fonts look aliased, if I set the browser zoom to 50%, the UI looks crisp, but everything is a bit small to be useful.

iddan
I fail to understand why not use the native browser rendering engine, or at least SVG for the UI. It must be cheaper in resources (memory, network, cpu), easier to make accessible and easier to render
jjcm
Anecdotally, in the very early days Figma rendered its UI entirely in canvas, but we eventually switched over to React for the UI. It ended up being far easier for development cycles and for accessibility/integration with existing browser features.
solardev
I thought you guys recently rewrote everything to be in WebGL instead?
rileyphone
Go inspect the source and see for yourself, the UI is normal HTML.
pests
I think their UI is react but the actual drawing canvas is WebGL.
TrevorSundberg
I always thought it was so cool Figma just rendered to a canvas! Oddly enough I ran into this at my previous job doing browser isolation when we got a bug report that Figma wasn’t displaying properly in our browser.

Makes sense to switch the rest of the UI to react though, just for how many people know it.

TrevorSundberg
The main reason was just because this engine was entirely built for native platforms originally in C++ (not for the Web). This is a port, hence why the UI is running in WASM/WebGL.
Matheus28
To OP:

The fix is setting canvas width to window.innerWidth * window.devicePixelRatio, and height to window.innerHeight * window.devicePixelRatio. Then use CSS to maximize the canvas on the screen.

[deleted]
(comment deleted)
hnreport
What’s Digipen’s stature now days?
mdaniel
heh, I got a kick out of there being a Project > Exit (bound to alt-f4!) which didn't actually exit anything but it thankfully did stop the tab from taking over my machine, so ... win-win?
TrevorSundberg
Still a lot of hold overs from being a native app :P

Good find though!

hoistbypetard
It's been sitting on "downloading runtime" for a very long time.

That makes me think this must be a challenge to host. What are the pain points to hosting it?

TrevorSundberg
The runtime is currently about 37MB, and when served with gzip it’s around 11MB compressed. Once it’s downloaded it should be cached and quickly startup. I think a lot of the challenge is going to be spent getting the binary to be smaller, or potentially breaking it up into separate individually loadable parts.
damon_c
How do I add WASD controls to the camera?
TrevorSundberg
That's something you'll have to code up yourself, however to get you started this script checks for pressing the W key and moves forward:

https://pastebin.com/8kMTCu3Y

TiredGuy
The Spaces feature reminds me of how Movie Clips were used in the old days of Macromedia Flash, where I'd put many different often-independently-running clips overlayed on top of each other to encapsulate different behavior. Of course Spaces sounds even more flexible. Very neat.

I'm not seeing documentation linked in the readme or within the github project. Are there how-tos and tutorials anywhere?

sansseriff
This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyone know if there could be a WebGL optimization issue?
TrevorSundberg
It almost sounds like it’s not using your dedicated graphics card. Do other WebGL demos run alright for you?
sansseriff
Yes I can run about 200 jellyfish in this demo with similar GPU load, resolution, and frame rate. https://akirodic.com/p/jellyfish/

Maybe not the most helpful comparison haha. Anyways, great work, this is very impressive

h4zel
Same experience here. I'm able to run other webgl projects fine, including the jellyfish project you linked, but this engine blows up my gpu. Strange
Narishma
That's WebGL. This engine seems to use WebGL2.
a_JIT_pie
I'm getting a really nice smooth experience on my Intel HD Graphics 620 (7th gen intel integrated graphics, old and slow). Also just looking at the default ball scene, and I was really impressed how smooth it was on my system. I'm using chrome.
meheleventyone
I suspect this is possibly down to the use of readPixels and how slow that is on various devices. The engine seems to run in a worker and render to an offscreen canvas then transfer the image data in JS to the main thread before drawing it to a canvas there.
TrevorSundberg
The transfer of image data only happens when we yield inside the engine which only occurs when you hit a breakpoint in script. Otherwise we're just rendering to the OffscreenCanvas and letting the normal flow blit it to the screen (not doing any copying).

I just did some profiling on Firefox and I feel like the profiling result doesn't quite make sense but it's saying that the majority of time is spent calling Performance.now() from the clock calls in C++. I'm wondering if that's because we're calling it too many times and maybe we should just call it once per frame.

meheleventyone
FWIW my poor performance is in Chrome on Apple Silicon not Firefox.
TrevorSundberg
Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/
darknavi
Trevor! I loved your CS elective at DigiPen on designing programming languages with grammars.

Many of the students you taught are working on Minecraft now. I'm using so many fundamentals taught by you and my time at DigiPen when designing the Minecraft scripting API today.

Glad to see you're still rocking it.

TrevorSundberg
Awwww I'm so glad it's been helpful! One of these days I'll get back into teaching ;) I'd love to see the scripting interface you're working on too, I spent so much time making Minecraft mods back in the day and I always wanted some kind of dynamic scripting.
[deleted]
(comment deleted)
diogenes4
Tinkercad and scratch were never tied to a browser! Why go with wasm?
TrevorSundberg
I’m fairly certain the native version of Scratch is just a browser with Scratch running in a web view. I’d also mention that WASM isn’t tied to a browser either (despite being called WebAssembly, it’s now widely used outside of browsers). You can in fact make native executables now from a WASM binary.
diogenes4
That's certainly an innovation. Scratch didn't use to involve browser-play at all.
what-no-tests
> Our end goal is to use this engine to create an online Flash-like hub for games that people can share and remix, akin to Scratch or Tinkercad.

AMAZING.

Hackable games are such a great in-road for new developers, and for anyone who takes an interest in software because of gaming.

ccvannorman
This is awesome! What would you say are the primary differences between Raverie and PlayCanvas.com?
TrevorSundberg
I haven’t tried PlayCanvas yet, but it looks great. I think the primary difference is that this engine is a learning tool primarily, and doesn’t have any intention to compete with bigger name engines.
3836293648
Yet another reminder that WebGL is terrible in Firefox. Looking forward to webgpu being standardised and widely used instead.
levkk
Same experience here, getting really low fps just moving around in an empty scene.
hutzlibu
The current status seems to be, chrome is also way ahead of firefox with webGPU. They just don't have the manpower anymore, so I would not get my expectations up high and just use chrome for games and co amd be happy if webgpu comes to mobile FF at all. Or petition mozilla into rehiring some engeneers..

And with this concrete project I cannot compare, because on my mobile nothing loads, neither on ff or chrome.

TrevorSundberg
Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs: https://raverie-us.github.io/raverie-engine/
3836293648
Didn't see that till now, but yes, that is so much better.
benkillin
Why invent your own scripting language instead of using one of the infinity other existing languages?
TrevorSundberg
This project was made in 2012 when there weren’t that many languages, especially not ones that bind to C/C++ (and we’re type safe). LUA was the primary embeddable language back then, and C# wasn’t even open source yet :)
pathartl
The summer workshops for HS students at DigiPen helped launch me into a programming career :)

No experience with Zero, but when I did the workshop in 2008 we used the .NET-based engine. I forget the name of it and the backup I have is in a pile of unlabeled burnt CDs.

adamrezich
it was ProjectFUN, same name as the summer workshop program—I wish I still had a copy of it, or at least the game I made with it that same summer!
pathartl
It's sitting on some old drive somewhere. I'll probably do some digging at some point and put it on archive.org, if only for preservation.