Thanks so much! With a bit of luck and talking to the right people at the right time, we got our start when Mozilla gave us the opportunity to create technical demos for the release of Firefox 4 back in 2010. Among other demos, we created a game called Mozilla BrowserQuest at the time, which really set us on the path to working on creative, tech-driven projects through word-of-mouth. These days, most of our clients are already excited about creating campaigns that can spark conversations and generate organic sharing, so we don’t usually need to sell them on the concept—they come to us because they already believe in its potential.
I should have said that it's not officially supported. For client work, we prefer not to choose an engine that may not work on a few devices and which we have no ability to fix.
Nothing complicated, we simply have initialization code that parses the GLTF scene on startup by iterating over the children of a specific group, and creating Rapier colliders for each of them (Triangle Mesh Colliders to be specific, in order to allow things such as curved ramps). Since their geometry is very simple, we can use directly the rendering geometry for the collider geo.
The main draw of the Unity Editor for us is how it auto-reloads assets, like 3D models, as soon as the asset file is updated. So the workflow is having your DCC app open in which you model things and export assets from, and Unity Editor to design your level where every model is always up-to-date.
This is not possible with Blender because it contains all models inside a single .blend file, so assets must be manually re-imported each you change them. There is a Link feature in Blender but in my experience it's not as good as what Unity does out of the box.
The glowing line represents a timeline of Netlify's milestones that you have to follow in order to discover their journey. No particular reason for the physics-based gameplay except to have a bit of fun.
The rendering engine is using Three.js which is a WebGL library. The physics/collision detection code is using Rapier through a WebAssembly module available on npm [1], which means that it can be used on the web even though it's originally written in Rust.
The levels were built inside the Unity Editor, then exported to FBX, then went through a pipeline based on Blender python scripting that optimized their geometry, assigned materials and exported them to GLTF (the final format that we load in the browser).
The physics engine we are using is Rapier 3D which does a lot of the heavy lifting, even though we had to tweak a lot the physics properties of the ball and surfaces in order to get something that felt right. For hotspots specifically, we implemented the magnet-like effect with custom code (by applying a force that pushes the ball toward the center and slowing it down at the same time) as there is no attractor primitive in Rapier.
The dual input is indeed a consequence of our isometric-view design choice, which I agree may not be the easiest way to control the ball. But the 45 degree angle just looks cooler in our opinion.
Yeah, sometimes the ball does some crazy things due to the way collision detection works. We tried to optimize and avoid most of the issues but it can happen.
There is code in place to respawn the ball if we detect that it's stuck inside a block or wall, which can occur due to frame drops during the physics simulation. I'll try to reproduce this issue. Thanks for reporting it!