AshleysBrain

We ported our game development software Construct [1] from a Windows desktop app to the browser in 2017, and haven't looked back since - it's been great!

The approach of "local app in the browser" works very well and is underrated IMO. It's the approach we use too - everything is downloaded via a Service Worker for offline support, and it's very responsive as nothing needs to wait on the network, unless the user chooses to (e.g. saving their work to Google Drive).

Chrome 86 also introduces the File System Access API [2] which is the icing on the cake - you can get read/write access to actual local files and folders, bypassing any issues about IndexedDB limits or persistence. I think this is one of the last pieces of the puzzle to make tools like Electron and NW.js more or less redundant, as now you can just do it directly in the browser and not have to ship the whole runtime around to everyone as well.

[1] https://www.construct.net [2] https://web.dev/file-system-access/

The last part is what I was referring to by "modern derivatives". OpenGL is widely regarded to have a poor API. If you want a higher level API, wouldn't you want a new modern layer with a nicer API instead? How long will technologies like OpenGL last just because people have already learnt them? Surely eventually we will switch over to better alternatives?

It's cool seeing the tech develop to run D3D/OpenGL on Vulkan/DX12/Metal, moving a lot of code out of drivers and in to libraries. But in the long term apps should all end up using Vulkan/DX12/Metal themselves directly (or modern derivatives) - so there won't be many uses for the old legacy D3D/OpenGL stacks left, so these libraries will probably fall out of use too. So, nice for the short/medium term, but probably no longer relevant in the long term.

It's a shame they have a messy pile of API-specific hacks to propagate the "user gesture". Chrome solved this problem with a change to the spec (which they called "User activation v2" [1]). It's basically two flags and a short timeout, and it covers basically all cases. Safari's approach means you have very specific codepaths, and if you do something async outside of that, tough luck, you can't use the feature and will have to nag the user to touch the screen again. This already affects APIs like clipboard (want to copy something that takes async work to generate? tough luck), limits APIs like OffscreenCanvas (want to move your game engine to a worker? tough luck, you lose access to all user gestures), and this too. Hopefully Apple can consider aligning with Chrome on this.

[1] https://www.chromestatus.com/feature/5722065667620864

We've been trialling the Native File System API in our PWA Construct 3 (a browser based game editor - https://www.construct.net).

I think it's absolutely fantastic, and users love it too - it gives them exactly what they expect from IDE-style software in the browser, such as "Save as" to any location on disk, and the ability to use folder-based projects (that are spread across multiple files).

The security concerns are obviously important but I'm pretty confident it's largely mitigated through the permissions model (which is similar to one Windows Store apps use). Also as noted elsewhere, existing web features already allowed reading files and even entire directories; the writing files part is new, and you cannot choose system directories, or ask for too much (e.g. root of the user directory).

So in short I think this is great news for the web and a big step towards allowing web apps to reach parity with desktop/native apps, while managing to do it in a reasonably safe way.

In my experience, if it's just an option on a settings page somewhere, virtually nobody will change it in practice. So if that's what they do and it's still enabled by default, this could be completely ineffective - but provide some political cover for them.

We make the engine this was made with (Construct 3). This looks like a problem with our engine if Safari loses the WebGL context at just the wrong time. I'd guess it's rare, but I patched this for the next release of our software just in case.

Note sometimes WebGL context loss is unrecoverable though - it can happen if the GPU driver crashes, for example.

It's great to see a game made with our web game engine Construct 3 appear on Hacker News! (https://www.construct.net/)

For those curious about the technical details, you might be interested to know the game code is running entirely off the main thread in a Web Worker and rendering directly from there with WebGL 2 using OffscreenCanvas (in Chrome where it's supported anyway, it has fallbacks). Nice to see this working out in the wild. I blogged about this architecture here previously: https://www.construct.net/en/blogs/ashleys-blog-2/performanc...

The video points out things like: how do you spot an eTLD? There's .com, but what about .co.uk? .github.io? Do you know all the exceptions? There's basically a database of them and you just have to know them to correctly interpret the security origin of the domain.

Reading URLs is actually really hard - even for experts. This video covers the problems well: https://www.youtube.com/watch?v=0-wB1VY3Nrc

This is bad for web security, since the registerable domain is the part you have to trust, but it's surprisingly difficult to figure out that part.

However I feel a bit uneasy about this since URLs are important and tell you where you are on a website. I prefer Firefox's approach which emphasises the registerable domain in the URL bar and fades out the rest of it, making it easier to spot the important bit. However it's still quite subtle - it could do with being a clearer distinction.

That rationale doesn't seem to add up - if you render the same content in 1080p and 4K, the only change is the amount of memory bandwidth for filling pixels. Multicore support in the layout engine will help speed up layout calculations (and maybe CSS), but the amount of work involved in that ought to constant regardless of the display resolution.

> I don't know of an equivalent program to help build HTML5 games.

We make Construct 3, a web app aimed at exactly this: https://www.construct.net

Shameless plug here, but I made a quick-and-dirty perf test that does something similar in our HTML5 game engine Construct 3, and it appears to run way faster even with 20000 boxes: https://www.scirra.com/labs/boxperf/index.html

This kind of test is easy work for a well-batched renderer. You can accumulate everything in to a single big typed array, copy to a single vertex buffer, and do one call to drawElements() in WebGL, and bingo, tens of thousands of sprites drawn in one go.

I've got other similar performance tests that can do hundreds of thousands of sprites @ 30 FPS (on a high-end machine), which I believe are bottlenecked mainly on memory bandwidth, because I only managed to make it go faster by reducing the size of the JS objects involved.

Modern JS is ultra fast - if you have the right performant coding style.

We make a browser-based game development IDE (www.construct.net), and IMO an important aspect of this is CSS containment: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Contain...

You can use 'contain' CSS properties to guarantee that layout inside the element won't affect anything outside it and vice versa. 'contain: strict' is basically a bulletproof container for arbitrary content, with performance benefits too. I'm not sure if it covers everything the article was trying to achieve, but it seems surprising not to mention it.

I've been surprised at being able to draw parallels between programming and music performance, writing and more. I think there's plenty in common at a high level when working on a creative project of any kind, such as your attitude to improvement, dealing with setbacks, analysing results, and the joy of when it all comes together!

Our startup builds a Flash replacement called Construct 3: https://www.construct.net

It's a web-based animation/game development IDE with support for JavaScript coding too.

Hasn't this always been a risk for third-party developers - that the platform owner might incorporate popular third-party features to the main platform? I vaguely remember Microsoft Word used to have a third-party addon for a spell checker, then made it built-in - and got sued by the third-party developer. I think they lost though...

This fits the pattern of Google consistently going "oops we broke Firefox" (or otherwise made it worse than Chrome) to the extent it raises suspicion of a deliberate strategy, as described by this former Mozillian: https://twitter.com/johnath/status/1116871246510264320

Isn't the sandbox a useful feature of WebAssembly? It gives you much better security guarantees than running untrusted native code on your system.

We build Construct 3, another web-based block programming editor, using a different approach which we think is more powerful and can make more sophisticated games. You can check it out at https://www.construct.net

They did then go on to get nearly 2000 "very positive" reviews, which is indicative of many more sales. I think they did well in a sale later down the line.

Sure. The Greenworks library lets any JavaScript game integrate with Steamworks in NW.js or Electron: https://github.com/greenheartgames/greenworks

That's about right. Phaser is a framework, and Construct is a full-fledged IDE. Its main feature is a drag-and-drop system for game logic rather than programming, so it's more designed for making game development accessible to a non-technical audience (so not sure how many HN folk will be in the market for that, although it's still great for rapid prototyping or fast development).

Construct 3 is browser-based so you can give it a spin here: https://editor.construct.net/

For those interested in HTML5 games on Steam, our HTML5 engine Construct has supported Steam publishing with NW.js for some years now - here's a selection, all built with HTML5 too:

https://store.steampowered.com/app/332250/The_Next_Penelope/

https://store.steampowered.com/app/317250/Airscape__The_Fall...

https://store.steampowered.com/app/412660/Klang/

https://store.steampowered.com/app/293240/Cosmochoria/

If you thought there weren't HTML5 games on Steam, it's probably because they're so good nobody notices.

I have to say, having tried both the RPi and Tinker Board, the Tinker Board's GPU driver is far better. Yes, it's proprietary, but unfortunately the RPi driver is simply not reliable enough to run something like WebGL in Chromium. It's slow and glitchy. The Tinker Board runs WebGL like a dream by comparison.

On a related note, we could use Proxys to have pretty good cross-worker APIs handled automatically, but unfortunately we need cross-heap collection for it to work: https://www.scirra.com/blog/ashley/38/why-javascript-needs-c...

Microsoft have tried this kind of thing more than once in the past, usually ultimately cancelling the projects. There was Microsoft Popfly (retired), Project Spark (retired), Microsoft Kodu (still going), now MakeCode. I suspect there are even more if you go further back.

Our startup has been doing the visual programming thing successfully for around 6 years now, and our latest tool is at www.construct.net. Maybe they should give us a call since it looks like they're struggling to get this right ;)

Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.

It's true nobody knows what the actual bug is, but I was working with what Ars Technica described: "If the problem were just that it enabled the derandomization of ASLR, this probably wouldn't be a huge disaster... The industry reaction... suggests that it's not just ASLR that's defeated and that a more general ability to leak information from the kernel has been developed." https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...

Haha good point! That's what I meant of course :) edited for clarity.