Hacker News Reader

Comment by greggman3 | Hacker News Reader

I'm very skeptical that big game engines will have any impact on the web. The issue is they're built for downloading XX gigs of data to a hard drive. Not for launching instantly like say google maps 3d mode.

Further, they re-implement everything themselves instead of using the features already built into the browser. Image decoding, video decoding, sound mixing, networking, text rendering, etc meaning you end up downloading 10-50meg of WASM. And every time they make a tiny change expect another large download.

Vs something like three, pixi, babylon, playcanvas, which are designed web first.

I think, it's likely a successful real-time 3d web based game will be designed for the web and I don't think the big game engines are engineered to make that easily possible.

View on HN

I use UE5 and I started playing with Godot[0] years ago, and I think this article on game engine selection has some merit on the importance over which game engine leads in a multi-billion dollar industry that is so pervasive in our culture and economics[1].

I was using Raylib for my fun little toy projects and a gateway library into game dev, but it is not as much of an integrated system as Godot, UE5, or Unity.

Gamers are made use to very high-end graphics and the look and feel that would lend UE5 and Unity an advantage, although Godot's capabilities have improved exponentially since I first played with it. It is also a very nice community.

On my last project, a very large walkthrough with animations of a very big model was very playable on everyone's laptop where I worked, but this was more of a visualization application. It was done in UE4 and utilized a company's proprietary kit to make it happen, not vanilla UE4.

[0] https://godotengine.org

[1] https://members.newdesigncongress.org/the-coming-game-engine...

We’re optimizing Unreal to work in the web, both for performance and load times.

Our asset streaming system bypasses the need for users to load an entire game upfront. Only what is needed is fetched, everything else is streamed in at runtime in the background. We’ve also implemented basis texture compression, which reduces file sizes and reduces load times further.

Unity is pretty good for smallish package sizes. There’s a few people in the Web Game Dev discord making money from Unity exports to the web on portals. That said I do think web native engines are the way to go ultimately as the package size will end up smaller in a like for like comparison. Unity games can be smaller than a lot of websites depending on how they’re put together.

The thing to keep in mind is overall audience expectations, the size of that market segment and how you want to monetise because that can result in some trade offs that are on the whole different to the average web app.

With all that said smaller initial packages, less processing on load and later streaming of assets should all be first line concerns for any web native engine.

> The issue is they're built for downloading XX gigs of data to a hard drive.

In the end, bandwidth is everything. If you can stream the asset data in the background that's most likely needed next, and discard the asset data that's most likely no longer needed without disrupting gameplay, storage space (or upfront download waiting time) is no longer an issue. The web server essentially becomes your hard drive.

It won't work for games that have been built for traditional gaming platforms of course, it basically requires to design the game from the ground up around the bandwidth limitations.

That said, I'm also sceptical about the whole idea of bringing AAA games to the web, even if it would be technically feasible. The main problem is that the business model isn't there (outside closed platforms like Facebook, TikTok or WeChat, which focus on entirely different types of games).

You'd first need a successful "Steam for the web" platform before tackling serious game projects. A typical chicken/egg situation.

PS: I fully agree about traditional game engines not being fit for the task, if there is a "web gaming" disruption, it will come out of the web hemisphere, not the traditional PC/console game engine side.

PPS: I'm reasonably sure it's possible to pack a complete 3D game client into a ~3..4 MByte WASM download (compressed) if you write the whole thing from scratch and don't use one of the 'industry standard' engines. That was the (compressed) size of the native Drakensang Online game client for Windows I worked on in the past, and this didn't use any services from the operating system that aren't also available in the browser in some form or another (e.g. all rendering, including UI and text... was all done from scratch on top of D3D9, networking was done on top of UDP sockets via RakNet, sound was done via FMOD).

PPPS: While traditional game engine runtimes are not fit for the task, maybe their asset pipelines, editor tools and workflows are. The 'engine' is just that little unimportant thing dangling off at the end of the asset pipeline after all ;) The Unity editor can be used to some extent in such a 'bring your own engine' role, but I guess that's at least a 'legal gray area', if not downright illegal.

For the PPPS case there is Needle Engine which is making some strides to using Unity as an editor for its own export.

The other side of bringing AAA style titles to the web are browser runtime memory limits. They can be pretty restrictive compared to the amount used by modern titles.

Reply on news.ycombinator.com