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

41–50 of 65 posts

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

#41

Post by charcircuit »

peterashford wrote: post #38
charcircuit wrote: post #34

Earlier quoted context omitted.

JavaScript will typically have better performance than WASM. WASM is good for porting existing software to the web. So if you have tens thousands of engineering hours dumped into some game engine that engine can be brought to the web instead of having to duplicate that work with a rewrite. Using javascript apis from WASM isn't possible and requires you to do extra copies. Yes, there are optimizations that browsers ca…

“Preliminary results show that WebAssembly, while still in its infancy, is starting to already outperform JavaScript, with much more room to grow,” https://thenewstack.io/javascript-vs-wasm-which-is-more-ener...

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.

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

#42

Post by EarthLaunch »

fenomas wrote: post #26

Wow, as someone who's been maintaining a JS voxel engine ("noa") for some years now it's surprising to find a bunch of influences here I hadn't seen before. I also got started from the algorithms on Mikola Lysenko's blog, but I'd never come across VoxLords at all. Great stuff OP!

I just checked out noa - I'm shocked that Minecraft Classic just went and used it without much contact? That's a really huge feather in your hat. Would you have done anything differently about that? (I just switched from MIT to AGPL, so this has been on my mind.)

Babylon.js, cool. How did it do with voxels, or how did you work with it? If you feel like answering. I used it previously on my project.

I have to check out all the other games on that list [0].

0: https://github.com/fenomas/noa

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

#43

Post by SeanAnderson »

I'm still reading this, but I just wanted to say this bit of your analysis was SO cathartic for me to read:

> React+Redux setup was too much performance overhead for the real-time gameplay section. The state updates through the Redux action reducer pipeline, and the minimal React render updates were enough to cause noticeable hiccups in the gameplay frame rate. Performance in the browser environment is susceptible to garbage collector management. To minimize garbage collector hits, you need to use object pooling. Object pooling is a mutable state management pattern in which you pre-allocate a pool of objects. The collection of allocated objects gets mutated and reused during the program's life to minimize runtime memory allocations. This object pooling pattern conflicts with the immutable update patterns of React and Redux. Hitting these performance issues was a significant roadblock and essentially became a 'rewrite' in which I had to rewrite the game state management to be performance optimized. This rewrite was costly and took a lot of time.

This is 100% the conclusion I came to when trying to build a web-first game from a React/JS background and it's wildly reassuring to read someone else coming to similar conclusions.

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

#44

Post by bnegreve »

SeanAnderson wrote: post #43

I'm still reading this, but I just wanted to say this bit of your analysis was SO cathartic for me to read: > React+Redux setup was too much performance overhead for the real-time gameplay section. The state updates through the Redux action reducer pipeline, and the minimal React render updates were enough to cause noticeable hiccups in the gameplay frame rate. Performance in the browser environment is susceptible to…

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.

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

#45

Post by fenomas »

EarthLaunch wrote: post #42
fenomas wrote: post #26

Wow, as someone who's been maintaining a JS voxel engine ("noa") for some years now it's surprising to find a bunch of influences here I hadn't seen before. I also got started from the algorithms on Mikola Lysenko's blog, but I'd never come across VoxLords at all. Great stuff OP!

I just checked out noa - I'm shocked that Minecraft Classic just went and used it without much contact? That's a really huge feather in your hat. Would you have done anything differently about that? (I just switched from MIT to AGPL, so this has been on my mind.) Babylon.js, cool. How did it do with voxels, or how did you work with it? If you feel like answering. I used it previously on my project. I have to check ou…

Thanks! I know basically nothing about the Minecraft thing - I didn't hear about it until a week after it launched, and by that time the multiplayer servers were dead and the game was abandoned. Apparently the Babylon.js folks had some backchannel dialog with Mojang about it, but they declined to include me or tell me what was discussed.

As for what I'd do differently - I should have ignored it. I invested a fair bit of emotional energy into trying get info, doing some work that the Babylon team asked for in hopes it would lead somewhere, etc. But nothing came of it and it was pretty depressing; I'd have been happier if I'd just tweeted once and moved on.

(I guess technically I should also have bugged Mojang to comply with the MIT license by adding my code's copyright notice, but... life is short.)

Re: Babylon.js, it doesn't have any voxel-related features, so to be honest all the babylon-specific code in my engine would probably look very similar if I'd gone with three.js. But Babylon's real killer feature is definitely its forum, which is extremely helpful and active. I'd probably never have been able to build my engine in three, just because I don't know any way of getting answers to thorny "oh you need to set mesh._dirty before calling that API" type questions for it.

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

#46

Post by sroussey »

bnegreve wrote: post #44
SeanAnderson wrote: post #43

I'm still reading this, but I just wanted to say this bit of your analysis was SO cathartic for me to read: > React+Redux setup was too much performance overhead for the real-time gameplay section. The state updates through the Redux action reducer pipeline, and the minimal React render updates were enough to cause noticeable hiccups in the gameplay frame rate. Performance in the browser environment is susceptible to…

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.

I can see the need for memory management for a game. There are other things, also graphics related like map points or point clouds.

You are more likely to a struct of arrays than an array of structs/objects as well. Very handy in C but also JS.

I suppose you can use a sliding window object (or “fly” object) that pretends to be the object when the data is really split across various arrays, just don’t actually loop over them. ;) I bet someone has done a library for something this way and used proxies.

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

#47

Post by lloydatkinson »

fenomas wrote: post #45
EarthLaunch wrote: post #42

Earlier quoted context omitted.

I just checked out noa - I'm shocked that Minecraft Classic just went and used it without much contact? That's a really huge feather in your hat. Would you have done anything differently about that? (I just switched from MIT to AGPL, so this has been on my mind.) Babylon.js, cool. How did it do with voxels, or how did you work with it? If you feel like answering. I used it previously on my project. I have to check ou…

Thanks! I know basically nothing about the Minecraft thing - I didn't hear about it until a week after it launched, and by that time the multiplayer servers were dead and the game was abandoned. Apparently the Babylon.js folks had some backchannel dialog with Mojang about it, but they declined to include me or tell me what was discussed. As for what I'd do differently - I should have ignored it. I invested a fair bit…

Wow, that's really shitty of both of them. They should be ashamed.

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

#48

Post by nitwit005 »

bnegreve wrote: post #44
SeanAnderson wrote: post #43

I'm still reading this, but I just wanted to say this bit of your analysis was SO cathartic for me to read: > React+Redux setup was too much performance overhead for the real-time gameplay section. The state updates through the Redux action reducer pipeline, and the minimal React render updates were enough to cause noticeable hiccups in the gameplay frame rate. Performance in the browser environment is susceptible to…

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.

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

#49

Post by flohofwoe »

charcircuit wrote: post #34
peterashford wrote: post #28

Earlier quoted context omitted.

Really? My understanding was that WASM support was good these days. And performance is a key issue with games

JavaScript will typically have better performance than WASM. WASM is good for porting existing software to the web. So if you have tens thousands of engineering hours dumped into some game engine that engine can be brought to the web instead of having to duplicate that work with a rewrite. Using javascript apis from WASM isn't possible and requires you to do extra copies. Yes, there are optimizations that browsers ca…

> JavaScript will typically have better performance than WASM.

That's a very - erm - interesting opinion which I haven't seen elsewhere yet ;)

IME, asm.js can achieve similar performance as WASM, but not 'idiomatic' JS.

Calls from WASM into JS are fast nowadays, but they are still an optimization barrier, doing this frequently (e.g. hundreds-of-thousands times per frame) is neither recommended, nor needed (and that's about the only situation where I can imagine that pure JS might outperform WASM - and IIRC I've seen some poorly built benchmarks which showed exactly this and which then claimed that "JS is faster than WASM").

(to be clear: JS and WASM performance is closer than most people think, but JS consistently outperforming WASM is the same sort of myth like "Java is faster than C++ because a JIT has more optimization opportunities" - that might be true in theory, but not in the real world outside some fabricated benchmarks).

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

#50

Post by flohofwoe »

charcircuit wrote: post #41
peterashford wrote: post #38

Earlier quoted context omitted.

“Preliminary results show that WebAssembly, while still in its infancy, is starting to already outperform JavaScript, with much more room to grow,” https://thenewstack.io/javascript-vs-wasm-which-is-more-ener...

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"

Post reply on HN