Ladies & gentlemen,
Over the years, besides of course being an astronaut, I have created many a project. These are mostly gamedev many a project. But there be many of them, and making a thread for each would inefficient. Therefore I present you - a long list of my excuses on why WhyDungeons still isn’t done after 3 years 
RAGO
[ AppStore | Google Play ]
About
Led by the siren voices of aquatic mammals, and contemplating their remarkably high quotient of intelligence (they repeatedly told me to make an MMO, but it is not the time for that yet) I have marched off the path less travelled, right onto the highway of creativity.
Based on this very picture, Rago was a weekend project created over 4 weekends. It is a Portal-like game about a hero that is cat and also fully forklift certified.
How It Works
Flexible Tile Maps
Rago is build entirely with Blender and a custom gamedev-y framework:
Interactions are defined using custom properties and interpreted in Three using userData.
Tile merging and physics
Since Rago maps are built with many tiny pieces, mobile phones obviously be like “no.” if you try to run the game like that - especially if each of these pieces is also a cannon-es body.
To reduce the amount of bodies and draw calls, Rago merges bodies depending on context and interactivity:
If a body is a static mesh, floor, or a navmap - it is instanced in three and merged into a single, giant static-body in Cannon. If body is dynamic, it can still be instanced, but receives a separate physics body. That way all the world-building blocks become essentially 3-4 instanced meshes per level, and cannon must check collisions only between a few dynamic bodies and the static world.
Each level / world-tile is it’s own GLTF
To limit memory usage on mobile, each level is saved as a separate GLTF and loaded / disposed on-demand. Partial-scene encapsulation (ie. binding models together with time listeners, audio, physics etc.) is the very essence of the framework - otherwise webview on mobile quickly gets overwhelmed, crashes, and reloads
Daylight Squad
[ Google Play ]
About
A daylightful racing game created as a base for a gamedev framework that is (definitely) later (I promise) going to be used to finish (eventually) WhyDungeons (or most likely not. 
)
I also wanted to learn gameplay design a bit. Cause it’s surprisingly god-damn hard. And also mobile release pipelines. And marketing. Lots of learning.
Unfortunately - it will absolutely never be released on iOS. It was done with a prototype of mentioned gamedev framework, and that prototype was so prototypic that untangling the code would take longer than writing it from scratch :')
How It Works
Google-class AI Support
Daylight Squad uses map nodes (pink cubes above) and individual perception nodes to guide opponents around the map (and make sure they are going the right way.)
Steering isn’t also just directly lerping direction towards the next node - instead it modifies the acceleration, to add a level of realistic overshoot (and also a level of bots getting realistically stuck in walls 
)
Audio & Interactive Surfaces
Daylight Squad also uses raycast surfaces - which are basically navmaps, but cause different kinds of interactions. Snow is a pretty example of that, where the displacement is added to the surface in the same spot where the vehicle currently is.
While not in DSQ itself - that can also be expanded to things like audio navmaps, where metal surfaces give different footstep sounds than wooden ones etc. 
Infinite scroller
Since the gameplay loop of Daylight Squad was kinda limited to like 10hrs max - the game also includes a state-of-the-art infinite scroller called Sunrace. While the player races against the time on an indefinite amount of prefab tiles - their phone memory races against the leaks and forced webview reloads 
CommonApp
[ Web ] (requires free account)
About
Probably the most ancient of projects I’ve done in three - and surprisingly one of the most stable ones. Common is a Sims-like builder that was meant to be the converted into WhyDungeons (this was virtually a screenshot from Common with RPG assets.)
Unfortunately, while stable and quite fun to use - it also features being quite slow. Not slow beyond usability. But there’s no justification for it being as slow as it is, since with it’s graphics it should easily be doing 120fps. Maybe the fact that I was learning three on the go when writing that app has something to do with that
How It Works
Scene-as-a-react-state
Can’t remember precisely, but I’m almost quite convinced Common started before (or at the same time) as react-three-fiber - and uses a similar way of defining the scene.
Common places objects’ definitions in React context - then parses that JSON and transforms it into three scene. It’s nowhere near the quality of r3f - but it does the job
(That also made server-side storage super easy - since you’re not exporting 3D models or three objects directly, all you need to store is a tiny configuration JSON.)
Wall chains
Common does some cool mathematical / graph calculations to detect wall chains. Walls are defined not as blocks but as points connected via lines. That way all intersections, bends, arches, wall lengths, can be calculated with quite trivial vector math combined with traversing a graph of points.
Should have been R3F
Were I to create that again, it would definitely be done in R3F. Probably the most important thing learned from Common is that react-three-fiber is virtually made for configuration-based apps like that - and doing them in vanilla three or, especially, vanilla three + vanilla react is just pure pain
DefaultCube
About
DefaultCube is a gamedev framework aiming (attempting to aim) for mobile devices - focusing on memory management, subscene encapsulation, and making making games easier (to a various degree of success.)
It uses Blender as a primary editor and three to add interactions. Should it be considered mature and stable? No. But does it ship games? Kinda yes
