[meheleventyone]

That's not really a like for like comparison though. You could for example light up a white pixel on a black background in the browser, which almost everyone has installed by default, or using the basic OS APIs or by downloading PICO-8 which is pretty small IIRC.

There are tradeoffs being made in all three choices and each will suit a different context.

[ziaddotcom]

Does anyone seriously write games for the browser anymore? Can Jonathan target the browser to make Braid, and seriously expect any commercial success?

Maybe you'll think "What about Celeste?" at which point you'll have only proven both of our points equally at best.

[meheleventyone]

Yes they do. There are also plenty of games written on a web stack and shipped as executables.

[ziaddotcom]

And how is that meaningfully different or better than using unity to ship an executable?

I thought your whole point was that everyone already has a stable browser, and shipping games as some bare metal or in some half bare metal form is really the developers imposition if the game could have just as well run in a browser.

[pharke]

There are still people developing efficient and capable game engines. Godot[0] is a good example of one that has achieved widespread success. It's a few dozen megabytes in size, does 2d and 3d, supports VR, and can target Windows, MacOS, Linux, Android, iOS and HTML5/WebAssembly. It's open source and free as in beer too.

[0] https://godotengine.org/

[ziaddotcom]

I think Godot has only recently become mature enough to be remotely comparable with unity etc.

From the Godot download page:

"Godot is currently not code-signed for macOS. See the last section of this page for instructions on allowing Godot to run anyway. Alternatively, you can install Godot from Steam to work around this." So what does that leave, Windows and Linux on x86-64?

Isn't this the kind unjustified hoops that Jonathan is criticizing, that people criticize Apple for not making it viable for a clearly legitimate OSS project to have to deal with? It definitely isn't something that would make me confident recommending a middle school game programming class to depend on working one semester to the next.

[meheleventyone]

No my whole point was that you're comparison was silly because there are lots of ways to accomplish what you said without downloading gigabytes or using Unity. I listed two other ways that weren't the browser and said that there were contextual trade-offs in what you'd choose to use.

You've decided to take one of those options and attribute a bunch of arguments to me I've never ever uttered.

[ziaddotcom]

Fair enough. I think you've called me out reasonably there.

I still don't think you've addressed my core point, and it's quite probable I wasn't clear enough to make that possible.

My white pixel example was referencing the talk, where I interpreted Jonathan saying almost verbatim about the barriers to just lighting up a single pixel on a modern computer. I made the assumption that everything he opines on publicly is in the context of him making games.

Is this whole stack overflow thread just a bunch of masochistic programmers, or is it needly complex to achieve consensus on how to plot a pixel in a browser canvas? I'll take responsibility for begging the question in jest. https://stackoverflow.com/questions/4899799/whats-the-best-w...

If one wants to start the game they are going to make in the same engine the are going to finish making it in, for most people, unity is going to be worth the gigabyte download. If you just want to teach kids html/css, the server stack in python, and how to change the color of one pixel in the browser is lesson one day one on a raspberry pi, fantastic. If one wants to write a mario clone and ship it in electron, bravo.

[meheleventyone]

Plotting a single pixel is amusingly difficult in general particularly in the age of 3D acceleration. It was also not necessarily a picnic in the past either as there often wasn't space for a fully addressable frame buffer.

I actually did this whilst playing about with Zig a while ago. I made an offscreen buffer, rendered pixels to a frame buffer array in WASM and then copied them into the offscreen buffer. Not going to win speed awards but it worked, was fast enough and was super simple. Also it meant I could scale the canvas to scale my image. This was for a very small screen representing windows in a building. My proof of concept was approximately 30 lines of JS and the same again in Zig. Most of the latter is type definitions.

Although given that Canvas is supposed to be a friendly abstraction it definitely feels like a weird oversight. Personally for pixel sized things I love PICO-8.