Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I built a multiplayer voxel browser game engine

kevzettler.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Show HN: I built a multiplayer voxel browser game engine

#51

Post by wsc981 »

preommr wrote: post #16

> The game dev UI complaint is because game engines use geriatric 2-way mutable state management UI code that is error-prone and brittle. Web developers have solved these UI complaints and built tools like React that make creating UIs easy Borderline satire.

I don’t know if that comment was mainly regarding web-based game UI libraries, but it seems on many other platforms there are many stateless immediate mode UI libraries available. Many based on (or inspired by) Dear ImGui [0].

By the way, I tried to use an immediate mode game UI in the past (Lua-based, SUIT), but somehow I feel more comfortable working with object-based UIs. Perhaps years of object-oriented programming has damaged my brain a bit :)

I think in the past the object-oriented was seen as a big improvement regarding GUI dev, but I guess with regards to game dev, it can be problematic wrt performance.

———

[0]: https://github.com/ocornut/imgui

Re: Show HN: I built a multiplayer voxel browser game engine

#52

Post by shmde »

nitwit005 wrote: post #48
bnegreve wrote: post #44

Earlier quoted context omitted.

Damn, it took me years to accept that dropping C-style or C++-style explicit memory management in favor of garbage collection was an overall improvement. And now we have to reuse and mutate objects instead of creating new ones because of it.

The React style forces a lot more object creation and copying then you're probably imagining. If you want to update an array, you generally have to make a new array, and copy over all the data except for your mutation: https://react.dev/learn/updating-arrays-in-state If you, for example, hold your voxel level data in a big array, that means copying that data every time the level is modified.

"The React style forces a lot more object creation and copying then you're probably imagining."

Its not react style its literally the core of how react works(immutablity). To rerender a component you need the new state to point towards a new reference to an object/array (hence the copying data to a new array) because JS compares objects/arrays through reference and not value. Not exactly react's fault but how JS works.

Re: Show HN: I built a multiplayer voxel browser game engine

#53

Post by nitwit005 »

shmde wrote: post #52
nitwit005 wrote: post #48

Earlier quoted context omitted.

The React style forces a lot more object creation and copying then you're probably imagining. If you want to update an array, you generally have to make a new array, and copy over all the data except for your mutation: https://react.dev/learn/updating-arrays-in-state If you, for example, hold your voxel level data in a big array, that means copying that data every time the level is modified.

"The React style forces a lot more object creation and copying then you're probably imagining." Its not react style its literally the core of how react works(immutablity). To rerender a component you need the new state to point towards a new reference to an object/array (hence the copying data to a new array) because JS compares objects/arrays through reference and not value. Not exactly react's fault but how JS work…

I said "react style" because they are not using React in a conventional way: https://github.com/kevzettler/react-regl

Re: Show HN: I built a multiplayer voxel browser game engine

#54

Post by charcircuit »

flohofwoe wrote: post #50
charcircuit wrote: post #41

Earlier quoted context omitted.

I would like to see this done with JavaScript that is an actual game or application. A gameboy emulator is a virtual machine and is not heavy on IPC with the DOM. Measuring a C++ program compiled into JavaScript (C virtual machine) doesn't seem representative either. The paper more shows that if you are building a virtual machine in the browser you should use WASM. I agree that is a sensible choice.

The calling overhead from WASM into JS in order to talk to browser APIs is usually negligible compared to the actual cost of the called function. Also see this article from 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-a... Quote: "calls between JS and WebAssembly are faster than non-inlined JS to JS function calls"

The problem is that these function only work with numbers. If you are trying to use functions that take or return objects or strings you start running into trouble.

So either you end up making a JavaScript engine that does all of the heavy work in regards to interfacing with the browser (including APIs like webgpu) or you come up with some serialization scheme to allow for wasm to work with these functions.

My point is that if you are making a big chunk of JavaScript already there is a benefit to just doing most of everything else with JavaScript if you can get away with it. I'm not trying to claim that in all circumstances WASM will be slower and I will encourage people to check for themselves, but I will stand behind the claim that performance should not be the reason you choose to make your web application with WASM.

Re: Show HN: I built a multiplayer voxel browser game engine

#55

Post by pavlov »

> "When I started progressing with Stackgl, I took a year off and worked on it full-time throughout 2017. I lived off some savings and unemployment checks until late 2018"

Impressive dedication, congratulations!

I did something similar when I was 23. (Now two decades ago - wow...) That project wasn't a runaway success on its own, but it was a fundamental learning experience. Those years spent building a software project of my own, yet one meant for other people to use and extend, completely changed how I think about my career and life and its external dependencies.

Re: Show HN: I built a multiplayer voxel browser game engine

#56

Post by nergal »

Very nice!

I'm the author of VoxLords, one of my early Voxel engines written for the web. Super fun to see/read about other projects like this!

My last webgl voxel-engine was this one: https://github.com/Lallassu/voxelengine3 (a bit more optimized than the VoxLords one) :)

Re: Show HN: I built a multiplayer voxel browser game engine

#57

Post by flohofwoe »

charcircuit wrote: post #54
flohofwoe wrote: post #50

Earlier quoted context omitted.

The calling overhead from WASM into JS in order to talk to browser APIs is usually negligible compared to the actual cost of the called function. Also see this article from 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-a... Quote: "calls between JS and WebAssembly are faster than non-inlined JS to JS function calls"

The problem is that these function only work with numbers. If you are trying to use functions that take or return objects or strings you start running into trouble. So either you end up making a JavaScript engine that does all of the heavy work in regards to interfacing with the browser (including APIs like webgpu) or you come up with some serialization scheme to allow for wasm to work with these functions. My point…

> performance should not be the reason you choose to make your web application with WASM

This I can mostly agree with, but it's a slightly different take than "JS is faster than WASM" though ;)

The marshalling for 'non-trivial types' (like strings or data structures) can indeed be a performance problem, but quite often one can get away with just passing numbers between the JS and WASM side. I'm actually a bit disappointed that WebGPU turned out so 'object-oriented' (e.g. most WebGPU objects are actual Javascript objects instead of 'number-handles'), which means that a lookup-table needs to be maintained on the JS side (I think that's what the externref proposal is supposed to solve).

Re: Show HN: I built a multiplayer voxel browser game engine

#59

Post by DonHopkins »

crazygringo wrote: post #11
drusepth wrote: post #4

Earlier quoted context omitted.

Pedantry activated: in my game dev circles, I've only ever heard .io pronounced "dot i-o" when talking about itch.io. The style, however, I usually hear as "i-o style" or an "i-o game".

Interesting -- if I see "open a .jpg file" I never hear people pronounce the dot, it's "open a jay-peg file". You'd definitely say "open an .exe file", again because no "dot". On the other hand, "Microsoft .NET" includes the "dot", as well as "bought five .com domains". Yet in contrast, "bought five .edu domains" would usually be said without the dot. Hypothesis: we don't pronounce leading dots unless for some reason…

It was funny when Sun proudly and unilaterally proclaimed that Sun put the "dot" into "dot com", leaving it wide open for Microsoft to slyly counter that oh yeah, well Microsoft put the "COM" into "dot com" -- i.e. ActiveX, IE, MSJVM, IIS, OLE, Visual Basic, Excel, Word, etc!

And then IBM mocked "When they put the dot into dot-com, they forgot how they were going to connect the dots," after sassily rolling out Eclipse just to cast a dark shadow on Java. Badoom psssh!

https://www.itbusiness.ca/news/ibm-brings-on-demand-computin...

Post reply on HN