The reason why business apps went all to the web still holds for games as well. Games like agar.io use these features, such as no downloads and instant start, and their success speaks for itself.
It's complicated.
I don't regret writing Loop Thesis in Javascript; there are substantial benefits to the web as a platform. If I went back to rewrite Loop Thesis from scratch, I wouldn't do anything different. But benefits aside, there are also complications and headaches, particularly around timers, audio, controller support, and garbage collection. I think there are concerns that have to be balanced.
There's definitely room for more games on the web, and there are huge benefits to looking at it as a platform, but I don't want to give the impression that it's all rainbows.
As a quick test I just opened two browsers in my PC (Windows), ran the Acid3 test, and got different results at different speeds. My phone's browser gave me yet a third result. That's a bad start for a multimedia platform that I'll be in charge of supporting.
For all its weaknesses, there was a platform that offered all you mentioned plus good portability and saw the success you speak of: Flash.
Furthermore, because of Google's dominance, not many browser engines are left in the market. Essentially all you have to do is support WebKit, Gecko, Blink, and you'll cover 99.9% of your userbase.
From what I know, canvas rendering is pretty much the same across different browsers. It's a pretty low level API so there's not as much room for interpretation. In any case, the Acid3 test you're running is focused on the specifics of HTML/CSS layout, and don't think it tests the canvas at all.
I think that canvas has done a good job of taking over the use cases that Flash had, and is very portable these days (basic canvas has 98-99% support[0]).
- OSX likes to turn random Unicode symbols into emoji (extends past Canvas)
- Fractional font sizes on Chrome/Linux get bizarrely stretched out (after a transform that makes the font not a fractional size)
- Complex clipping operations freak Chrome out
- All the compositing rendering options are broken somewhere or mis-defined to the point that it's weirdly hard to render anything to an alpha channel
You also need input APIs to make a game, and the input APIs often have strange inconsistencies in function names, returned objects, or event ordering.
Canvas is nice and straightforward if you want a purely sprite-based game with only mouse/keyboard input (but even then you need to jump through hoops if you want pixel art). Anything beyond that is going to need cross-platform debugging.
The thing is, you can target Unity/Unreal/etc at a browser and get most of the benefits listed above, plus the benefit of using more-or-less the same toolkit as everybody else.
It's worth checking the Acid Tests homepage [1] here:
> Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers.
Tom Greenaway is making the same argument: https://web.dev/ready-player-web/
> You can just send a link to your friends and they can join your game with a single click.
Web Bundles takes it a step further and lets you share the entire game, P2P, as a single file: https://web.dev/web-bundles/
Disclosure: I work on web.dev
It seems pretty neat, my question is what the functional difference between this and running something like wget with recursive and convert-to-local flags?
Let's say I have some contrived portfolio website and it contains links to several sub-page sections, and some static resources (images, JS, fonts, CSS, etc).
I can run this and get an offline copy of the website that I can browse or distribute how I wish:
wget --mirror --convert-links --adjust-extension --page-requisites --no-parent http://example.orgThe value proposition just isn't there when Unity and similar engines exist.
In fact, this is the exact justification why HTML/JS business apps have thrived, because even though JS has tons of problems, all of them can be overlooked when you gain the capabilities of the web.
Jokes aside, there are some Korean MMOs that rely on excessively trusting the client as a core part of their business model. If you offload as much state as possible to the client your server costs go way down. Maplestory is an example of this: if a player is alone on a map, essentially all map state, physics, etc. is handled purely on the client. When another player enters the map, half of the NPCs get 'handed over' to that player, and the server syncs state between the two clients.
On the other hand, you have to keep in mind hacks like bots and wallhacks. In the case of bots obfuscation is practically your only defense. In the case of wallhacks you can try to keep clients in the dark as much as possible, but there will always be a period where the client knows more than the player should (unless you want enemy players to 'pop in' once they are fully in view).
It also makes the game much more fluid without adding a lot of complexity to hide the latency. I think South Korean games can get away with it because they require an SSN to register. If you get caught cheating then making a new account isn't easy.
It's a pain when a site has heavily obfuscated code that constantly spawns anonymous functions that look like `function() { debugger; }`.
has been an absolute dream to develop for a 2 person team. One of the benefits we've found that rarely gets mentioned is that there are minimal fees. Our only outgoings are server costs and Stripe fees: no payments for Unity/Unreal, no App/Play store cuts. Another is that depending on your game mechanics lots of existing technologies solve problems that big game engines often handle for you. Thanks to Postgres transactions we have never spent a second thinking about client/server synchronisation.
For those who saw the game on HN a few weeks back, we have turbocharged our tutorial and game information and the player base is growing. Jump on and play a round!
By the way, browser compatibility is not a concern if you develop for Electron. Just target Chrome and you're done.
Although saying that memory in lower level languages is basically treated as an array of numbers and you can treat the array buffers similarly. It’s also how Wasm memory is exposed. So you can serialize JS and other data in and out of them.
If you need strings you can use the native TextEncoder/TextDecoder and shuffle things around as UTF-8. If you need JSON-like objects you can look at encoding formats such as Protocol Buffers, Thrift, and the like. This introduces non-zero latency shuffling data between formats but that's largely what normally occurs over IO boundaries anyways.
[0]: https://www.sitepen.com/blog/the-return-of-sharedarraybuffer...
https://github.com/LiveAsynchronousVisualizedArchitecture/si...
It should be MUCH faster than loopback IP IPC if that's what you were trying.
Are you using it for P2P, or making the 'peer' be a central server?
Last I checked a few months ago this library was working for WebRTC data channels on node.js. Check it out, but it might not work properly: