AshleysBrain

Sure, mistakes happen, and sometimes it's our fault. But the point is Apple's policies turn what would normally be a routine bug fix in to a total nightmare.

Is it idiosyncratic to assume that two variants of the canvas API support the same things?

Browsers don't have the same access as native apps, and shouldn't. There are permission prompts, privacy controls and access limits. For example the File System Access API is not unfettered access, it's limited to only files and folders manually selected by the user and nothing else. This is not at all "random access to your computer", which is in fact what traditional desktop apps tend to have.

Saving user's work to IndexedDB turned in to a real problem for us for a similar reason: sometimes users go in to their browser settings and click an option with wording like "clear cookies", and then it also wipes IndexedDB and all their saved work. I don't know if that applies to OPFS, but saving to the real file system (rather than just OPFS) seems a lot safer, and also integrates well with other tools, like backup software.

I've also long felt that "cookies" is a really poor term - these days it really refers to "storage on your local device accessed by websites", and the confusion literally leads to data loss.

Arguably looking at the whole picture means recognizing that some of these use cases will instead be done by traditional desktop apps that have far more invasive access often without needing to prompt the user for permission at all. In my view web browsers are a more secure and privacy-preserving option than that.

The key is the file and folder picker methods (showOpenFilePicker() etc), allowing the web app to interact with existing files and folders on the device. OPFS does not allow that, as it's internal storage in the browser, like IndexedDB.

The File System Access API does not grant arbitrary file system access. At most it provides access to a folder manually chosen by the user, with limits on which folders can be accessed (e.g. root or entire documents folder is not allowed).

To be clear, we also offer cloud save (e.g. to Google Drive), or downloading a copy of your project. Our software makes no particular effort to highlight any particular option. We see 65% of users freely choose the file system option, and most of the others use cloud save.

I agree - the File System Access API with full integration with local files and folders is essential for desktop web apps. Ours[1] supports File System Access for saving and opening projects in Chromium-based browsers, and our stats show a full 65% of users save that way. So it's also what real people actually want to use in browsers.

[1] https://www.construct.net

You need to change the 'Start on layout' property of the timeline to make sure it plays in preview. I think our guided tour should include that though, so I'll see about updating that.

Not sure why that error happened when exporting a GIF - I just tried it and it's working here (Chrome/Windows). Could you copy and paste the error message and send it to me at ashley@construct.net? I'll see if I can figure it out from that.

If your video editing tool can use an image sequence (e.g. 000.png, 001.png...), I'd recommend using the Image Sequence exporter[1]. If you want an actual video file with transparency, you can do that by using FFmpeg to encode a video from the image sequence, which we also have a guide for[2].

[1] https://www.construct.net/en/tutorials/exporting-image-seque...

[2] https://www.construct.net/en/tutorials/exporting-videos-tran...

Thanks, we were aiming to make a desktop-grade UI in the browser and it's nice to hear feedback like that!

The UI was separately developed with JavaScript, it wasn't made in Construct itself (which is mostly canvas-based). The whole runtime is also in-house - we don't use PixiJS or any other libraries, once again it's all our own in-house engine, custom WebGL/WebGPU renderer, etc.

You can import SVG files to the project and display them with the SVG Picture object, and that all works in the free edition.

It's browser-based so it's all HTML, CSS and JavaScript, written using our own in-house framework.

Treasure hunting to find an API widely supported on 95%+ of devices?

We have an in-house UI library, mainly because we started writing code in the mid-2010s and there was nothing good out there at the time. Maybe that's changed but while I haven't researched it thoroughly, I also haven't come across anything that looks like it does everything ours does. But our UI lib aims to be as simple and straightforward as possible, standard model-view-controller, no virtual DOM, making full use of HTML and CSS features. Personally I view a lot of modern CSS frameworks with suspicion as they all seem to massively overengineer this stuff. We have a whole desktop IDE running on basically old fashioned desktop app engineering style but on top of HTML, and it works great.

Apart from a few extra services on the side, the main app is all static resources so no real backend to speak of. Again, engineered like a traditional desktop app with everything running locally, which also means the UI always responds promptly (no waiting for network) and it all works offline.

Maybe I should write up a blog post about how it all works, but not sure how many people out there want to hear more!

I think that was the case several years ago but I thought these days much more of the browser rendering pipeline was automatically GPU accelerated. It's hard to find up-to-date references (would appreciate any links) but for example going to chrome://gpu shows it using GPU acceleration for both compositing and rasterization (including "multiple raster threads"), as well as the usual suspects like video decoding, canvas and WebGL.

AFAIK modern browsers all use GPU accelerated rendering, so using HTML/CSS does give you a GPU-backed user interface.

Also desktop PWAs are IMO underrated and a really good way to distribute a desktop app without having to bundle a whole browser engine with your app. We do this for Construct (www.construct.net) - a complete game development IDE - and I think it's worked out great.

How does this handle garbage collection? AFAIK the WebAssembly GC proposal is still in development. Does it implement GC in WASM code?

I've not heard of flow fields before! Do you know a good reference to read up on them?

(Author here) I can imagine multithreading in C++ is a last resort. But with web workers it's guaranteed safe and relatively easy to do with message passing. So why not? Even using one thread lifts the performance overhead of pathfinding off the main game thread, which helps scale it up to 1000s of units, which I'm hoping to do!

Shameless self-plug: we make Construct, which has a visual block-based system, runs in the browser with no install, and also supports progressing on to JavaScript coding: https://editor.construct.net/

This has no bearing on cheating. You can do this approach and still have an authoritative server which clients only send their inputs to.

Everything I've read about the lock-step approach is that it is a total nightmare to develop - keeping games deterministic is really hard and a de-sync bug that happens out the blue after 1 hour of 4-player multiplayer is the kind of thing that is extremely difficult to get to the bottom of. Streaming everything is by comparison much easier to develop in my view since that class of problems disappears. It also allows late-joining, including spectators, as it syncs the full state of the game periodically, and it makes it resistant to brief network outages, such as going through a tunnel on a train while on cell data.

I think it's also worth sometimes revisiting the assumptions made for the current algorithms and approaches in use. The original design was for dial-up modems. The networking landscape is completely different now. Maybe some of the original assumptions are no longer valid and a different set of tradeoffs is worthwhile.

Yeah, the units all shoot. One-off events turn out to take negligible bandwidth if they are cosmetic and the client can predict what happens.

What I find interesting about the lockstep approach described here is it seems a lot of modern RTS games still use the same approach, even though the bandwidth calculations have changed radically. When developing my own RTS game I was able to fairly straightforwardly get 1000 units in combat to live stream using about 50 KiB/s bandwidth, which is nothing these days: https://www.construct.net/en/blogs/ashleys-blog-2/rts-devlog...

So as much as this is a fascinating piece of history and an impressive technical solution to the constraints of the time, I think modern games ought to move past it.

In the same blog series I point out that this seems to be an idea carried over from the days of modems and is no longer really necessary: https://www.construct.net/en/blogs/ashleys-blog-2/rts-devlog...

1000 units in intense combat can be synced with about 50 KiB/s - so why go to the trouble of deterministic gameplay, dealing with de-sync bugs, and making it diffiuclt to late join?

It might not yet do everything, but we're having a go at a modern web-based animation tool with Construct Animate, currently in open beta: https://www.construct.net/en/blogs/construct-official-blog-1...

It can export videos, GIFs, image sequences, can use modern JavaScript coding, and has a surprisingly strong block-based visual alternative to coding.

Changing tab doesn't tell you where or what someone clicked on outside of the page itself though, only that the page is no longer visible.

> The ability for a website to see when you click on things outside of the page itself

It doesn't let pages see what you're clicking on outside of the page. That would indeed be a serious privacy violation. It merely tells the page that it's not on-screen any more. Personally I don't see any problem with that.