Live data from Hacker News

Half-Life 2 in a Browser

hl2.slqnt.dev

201–210 of 283 posts

Re: Half-Life 2 in a Browser

#201
post #9

And Quake 3: https://thelongestyard.link/q3a-demo/ And Unreal Tournament: https://dos.zone/mp/?lobby=ut There's also https://noclip.website/ which, while not playable, has hundreds of levels from dozens of older games that you can explore freely. Including Half-Life 2, with more accurate rendering than this web port (which seems to be missing many shaders including character eyes).

> And Quake 3 There is QuakeJS as well.

Yeah but my port is better because it supports phones/touch and gamepads and multiplayer over UDP and has better performance and a bunch of other small details.

Re: Half-Life 2 in a Browser

#203
post #9

And Quake 3: https://thelongestyard.link/q3a-demo/ And Unreal Tournament: https://dos.zone/mp/?lobby=ut There's also https://noclip.website/ which, while not playable, has hundreds of levels from dozens of older games that you can explore freely. Including Half-Life 2, with more accurate rendering than this web port (which seems to be missing many shaders including character eyes).

Also The Simpsons Hit & Run! https://shar-wasm.cjoseph.workers.dev/

It works so seamlessly on macOS at 6016x3384. What a delight.

Re: Half-Life 2 in a Browser

#205

[dead]

It only loads the first 50 MB needed to start the game at first, as you interact/progress it loads more. 50 MB is definitely at the boundary of "how many users appreciate a button vs how many are ignored they have to click it to load the initial page" size.

Having to click a button to see anything itself is even a scammy pattern as it's used by scam sites to get more permissions before the user has a chance to doubt the content at all.

Re: Half-Life 2 in a Browser

#207
post #131

With WASM and WebGL being mature technologies, I'm not sure why there aren't more video games published this way. For really big games with lots of assets, having those assets in local storage makes sense. But I wouldn't mind if a game "installer" is just your browser asking "This game wants to use up to 20 GB of local disc space. Is that okay?"

I’ve always wondered a bit about the ssr side of these things a bit. Something like time crisis where the main video is pre-rendered and streamed but the interactive elements (enemies, explosions) are superimposed in front on the client. Feels like you could make a very low bandwidth experience (around the same cost as a YouTube video plus some assets?).

But why not just render everything 3D? GPUs are more than good enough and it will look more consistent.

Re: Half-Life 2 in a Browser

#208
post #131

With WASM and WebGL being mature technologies, I'm not sure why there aren't more video games published this way. For really big games with lots of assets, having those assets in local storage makes sense. But I wouldn't mind if a game "installer" is just your browser asking "This game wants to use up to 20 GB of local disc space. Is that okay?"

For what purpose, though? Why saddle yourself with the overhead & restrictions of WASM and the limitations of WebGL (or even WebGPU), just to run in a browser? The typical answer for running in a browser is the fast deployment, but if the user has to sit through a 20GB download anyway , then what's the point? Just to avoid needing an install wizard? And in case you aren't aware, 20GB would actually be a relatively sm…

> but if the user has to sit through a 20GB download anyway, then what's the point?

They don't have to unless the game makes them. Assets can be streamed in. This Half Life 2 port streams in each chapter so you are playing without having the entire game downloaded. World of Warcraft is over 100GB but you can start playing with only a fraction complete and it will continue downloading as you play

Re: Half-Life 2 in a Browser

#210

Earlier quoted context omitted.

Isn't Godot kinda flawed for deploying to the web? For example, no C# as of now, although there have been plenty of efforts to make it work. Or AFAIU audio being forced to stay in the main thread which can cause glitches. I just mean that it's not all fun and games as soon as you want to make a more ambitious game and not just a quick demo or game jam thingy.

I found GDScript to be quite powerful in terms of functionality. I don't have experience in professional game Dev to be aware of the benefits of C# beyond it being the industry standard for Unity. Single threaded audio is a big concern. I haven't implemented music in my game yet to know if it is a deal breaker. The main problem that I have run into is shader compilation stutters on the compatibility render. Makes the…

gdscript is missing basic features like interfaces (only abstract classes with no multiple inheritance) or custom value types. spawning scenes from code is tricky and not type safe. asset loading and globals are a mess. the engine is built around using a lot of nodes but nodes are expensive, so you need to drop down to confusing low level server apis if you have performance issues.

the worst part is theres no defined build step so `@tool` scripts run both in the editor and at export time. its easy to accidentally crash the editor or mess up your scene with a bad editor script missing one line of code. and as far as i remember its impossible to undo so remember to save often.

godot is still the best option if you want a open source engine for your game but only because bevy is not production ready yet.

Post reply on HN