Just try it, in the worst case you have to git reset --hard and git clean -dxn / -dxf and dnx 2dog add again, but I think the dotnet restore --force should do it! There’s only changes to the native library and the glue code.

I plan to use 2dog a lot in future jams… it wasn’t quite stable enough for GMTK jam, though, so… something to look forward to in upcoming jams.

Yay! Your game works! *asterisk…

I released a new release (v4.7.1.59) of 2dog that hardwires all the native WASM trampoline functions. It’s one of those bugs that has me scratching my head, as in “how did this ever work?”, but it did, including for samples from the Godot foundation, three friends’ games, and two of my own. So… mega big thanks for this bug report, this was a big one!

You may need to run dotnet nuget locals all --clear and dotnet restore --force or similar to get the fresh packages.

Anyway. The asterisk: the loading performance of certain scenes and textures isn’t great at all 😓, and I’m working on ways to make that nicer in the web html harness; and I also need to figure out where the majority of that time is spent; sometimes it’s WASM compile time, sometimes it’s scene load.

PS: Super adorable game idea. That angry beach ball can get bent, though… sheesh. Ey, I’m walkin’ crawlin’ here!

Getting closer, it’s GD.PushError and some other functions with 7 parameters under the hood. (a little confused why these aren’t generated, or how the native equivalent to GD.PushError(“Blah”) has 7 params, maybe it tries to look up all candidates) … I need to do something else for the next hour or so, and then can get back to this. My automated and manual tests always fail on errors so ironically that led to GD.PushError never being tested.

In related news, who ever in the .NET/mono team thought it was a good idea to call native signature strings “cookies” in the context of WASM specifically deserves a villain award… I navigated away from the documentation page three times thinking it was about web cookies.

Awesome, thanks for the detailed report and prepared repository to reproduce in. The failure is a bit different on my end - first I get a bunch of issues trying to serve the blender files (which it shouldn’t, on the web, very likely my bug! bad dog, bad dog… - should already be imported), and then I get your crash. Is this what you get, too?

Game seems to run okay in the editor. I’m working on making the blender import happen correctly or raise an error during the 2dog import step, I think this is where it goes wrong. (also, fantastic test case for future tests… I built 2dog because of resource import issues, now resource import bites me in the belly yet again, ha.)

Edit: No, the problem is not the missing blender import, after correctly setting it to my blender path I get your behaviour. Which is great, only need to find the missing native trampoline now…

Oof, looks like a Godot crash, do you have a public repo with the game jam entry somewhere? I probably have to dig a little deeper, my suspicion is something related to some kind of native function/trampoline being completely missing. (weird)

You could also try to create a source map: dotnet publish -c Release -p:WasmEmitSymbolMap=true -p:WasmNativeStrip=false

I, for one, welcome our new robot overlord!

It’s been a while since this was “hot news” - but here’s a link to one of their GDC talks :) https://www.gamedevs.org/uploads/data-driven-game-object-system.pdf

That’s really awesome, would love to see how and what you’re doing with it! There are many approaches to composition in the various ECS flavors, and the “OG” ECS, “Entity System” in Dungeon Siege, had no-code composability for designers as one of its core principles.

“shared” folders seem like an antipattern to me. It quickly becomes the largest folder of even a small projects, and large projects developed by whole teams often end up with multiple shared (sub-)folders.

What techinques can you suggest against this, or to, in an advanced project, safely refactor and move many such folders without breaking the project?