Show HN: Unity like game editor running in pure WASM

Works fine for me running Firefox in Windows with a 3090. Also already have Unreal open on another screen. So lots of my GPU memory is already being eaten up.

The experience will probably be hellish anyway because of the Web integrity API. Javascript compiled to asm.js could produce painted-to-canvas websites too, and it won't be any less viable especially considering the growth of the CPU scores. Webassembly is prevalent in the canvas use cases because DOM manipulation with it is slower, clunky(due to the poor browser integration) and because people want to reuse native-language codebases.

If the canvas website really was a threat we would have seen much more of it by now already, but it hasn't happened for a number of reasons -- we only see them in the dedicated desktop-app-like use cases like this one. Anything scrollable won't be viable because it would be inherently less responsive than the real deal. Fonts look different, most designers actually prefer for people to be able to select text, and be able to use browser functionality that looks native for the different OSs. Canvas websites are also more expensive in terms of blob loading and ability to cache pages. So it's not really a threat.

Most adblocking happens by the means of network/URL blocking and I don't see any potential difference between WASM and JS in this regard(unless the APIs are enshittified, but JS isn't impervious to this too). If ads can't be blocked by network, and the website proxies ad contents through its own domain(as far as I know that's not prevalent, maybe I'm ignorant -- they need to track users and clicks themselves anyway), than you could get hard to block websites with JS+DOM too -- it's possible disrupt DOM based blocking by frequent randomization/obfuscation to the degree that one would need some kind of advanced AI to even hope to find the ad DOM elements. Between WEI, web bundles, Topics API push, webassembly's supposed higher indecipherability (which isn't true, chrome "disassembles" WASM into the WAT form and it's pretty readable. More readable than wasm.js) doesn't even register.

>And for what?

To not deal with JavaScript? To be able to develop for the web in the language you want, without floats being the fundamental numeric type and other BS? Is that too fantastical of a desire?

> 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 

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...