The map data is provided in the USD format which is a 3D authoring and interchange format that can be used with a lot of software. Unlike the final optimized data used by the game this doesn't require revere engineering and can be seen as source data that is in fact useful for graphics researchers and game developers.
That mega man clone is great. The movement feels exactly how I remember mega man 3 feeling. You absolutely nailed it. I also appreciate how you've set up the code, with the build script being written in zig. I checked the code out, compiled it, ran the web server and bam! It just worked. It doesn't seem like that should be a big deal, but competence is such an exotic bird in these woods that I appreciate it whenever I see it.
Nice! Looks pretty rad. I've never used Zig but it sure looks like an interesting language. Did NanoVG help with the animation stuff like the little text that pops out of the beetles and the lines that zip between them?
Sorry, totally missed your reply!
At first we had normal text and then we switched them for hand-drawn sprites. The text animation consists of 2D transformations (translation, rotation, scale) interpolated over time. It's all animated in code. NanoVG helps by having a transformation stack like OpenGL. In Zig I can open a block like this:
{
vg.save();
defer vg.restore(); // undo all transformations at the end of the block
There are tools in the upper right corner. You can pick one and use it on a beetle. ;) This introduces various faults in the simulation that the database has to recover from.
Minor spoiler: there's another tiny game hidden at the end of the third level.
That adds some interactivity, but I still wouldn't call this a game yet. Games generally have some sort of challenge you must overcome. This is more like a highly polished interactive simulation of a distributed db. Still really cool and well done.
Interesting tool. But looking at the code when you load a video it simply decodes all frames into memory. If you deal with 1080p footage at 30 fps you will hit 4 GB with just ~23 seconds of video.
Sadly, videos can't be larger than that. For one there's a memory limit per browser tab. Secondly, wasm32 is not able to address more than 4 GB of memory.
Editing feature length movies is certainly out of scope for this editor. It's meant for editing short 10-30 second video clips that are well within the limits of 2 GB. We keep compressed video in memory and only deal with a few decompressed frames at a time.
We avoid H264 patents by not shipping an H264 encoder/decoder. We leverage the browser's WebCodecs API which in turn uses the platform's native codec API. It's the OS and the hardware vendors that license H264 patents because they're the ones providing the H264 implementation.