Recent submissions

Comment · 2 years ago
https://sluglibrary.com/ - game library used in many engines to do vector graphics and fonts directly on the GPU
Comment · 2 years ago
Building a helm chart right now to see if I can get it self-hosted in our cluster... :D
Comment · 2 years ago
Comment · 2 years ago
OK soooooo.... Prediction is there is going to be a correction as % holding stocks are currently close to an all-time high. So what asset am I buying right now?
Comment · 3 years ago
Open sourced - nice!
Comment · 3 years ago
We made https://rocketbotroyale.winterpixel.io in godot 3.5. ~ 20MB wasm binary, ~20MB game assets. We did however, have to do a ** ton of engine modifications to get the performance characteristics we needed on web, so mileage may vary depending on what you are actually building. But overall, 3.5 supports web very well. 4.0 is too unstable for us to use it yet, so jury still out on that one.

But the absolute, most amazing thing ( coming from the anxiety of app 'submissions', going through 'reviews', etc ), is the ability to update/fix/hotpatch everything instantly. Like within seconds. We have a simple CI/CD workflow that builds, updates & deploys a new godot site ( with dedicated gameserver backends) within seconds. The ability to just do this however you want, whenever you want, without going through some kind of platform distribution interface is great. With the exception of WGSL being such a dumpster fire of a spec, I'm pretty bullish on web for gamedev & distribution. There's some really great stuff being built right now, see: wasm+webtransport+wgpu

Comment · 3 years ago
Would you be able to provide support for dotnet 8 alpha? Super interested in this, but would need iOS,MacOS and wasm... Seems like cross-compile support for all those targets are already in 8.0.0 alpha?
Comment · 4 years ago
Comment · 4 years ago
Comment · 4 years ago
I always think of the Monty Hall problem with 100 doors. And with the game show host revealing 98 'goat' doors thus leaving two doors left (the original guess, and another one). You'd switch then right? :)
Comment · 4 years ago
We flipped a coin, and it ended up being heads (just us), meh... Nothing more to it: https://arxiv.org/pdf/1806.02404.pdf I believe the TLDR of that is, if you monte carlo the drake equation, and account for the uncertainty of the error margins, you don't really end up with much of a paradox.
Comment · 5 years ago
This is EXACTLY the issue we are currently running into while hosting our gameservers on kubernetes via agones https://agones.dev/site/. While our gameserver processes don't really need a full core, they do need to be scheduled regularly to meet their tick simulation deadlines. A gameserver that ticks at 60hz absolutely needs CPU time at the very least every few milliseconds. Not getting scheduled back in time for a game tick means more input latency, and wreaks havoc on game clients trying to adjust their prediction buffers to optimally time their input receipt server side before the next server tick.

Bad, bad, bad scenario all around. A gameserver process really needs to get scheduled like a heartbeat. Ticks can't be late on the server as it really screws everything else up big time. We've seen these "bursting" effects really start to take it's toll, to the effect that we're now just setting a request and limit of 1CPU for each game server process (even though we could pack a lot more punch here).

Comment · 5 years ago
This is exactly why we are using DigitalOcean to host our gameservers... Our egress costs are basically 1/10th of what we would pay on the big three.

DigitalOcean Egress - $0.01/GB

Comment · 5 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton