Hey HN, I haven't done a lot of technical postmortem blogpost-style writing
so I'd welcome any feedback or tips on how to improve. Is it too long, too
short, too technical, not technical enough? Boring? Interesting? Is it
enlightening or does it just come off like content marketing? I literally
have no idea how good I am at this.
Keep on writing!
I enjoyed reading what you tried and why you ended up with what you did.
It is fine to mention your game, I do not consider that content marketing at all.
I don't think anyone here is going to complain about a post where you make a game work by reverse engineering Bezier splines encoded in XML by Adobe Flash.
However I wonder why the OP didn't try to keep vector graphics and use to SVG for instance? That would allow for infinite scalability. It is mentioned that "GPUs don't like vectors" but if the game doesn't change too often it should not make a lot of difference?
I did consider it. Infinite scalability isn't required during runtime; the scene doesn't ever zoom or scale in the games, because that was always so slow in Flash, so the only real benefits would be 1) supporting higher resolutions and 2) reducing file size.
For 1) I decided I'd rather just release an update with larger textures if these ones ever start to look dated. That way I get to keep the runtime code simple. Less code means fewer bugs. I don't want to spend a lot of time fielding support requests from users who hit edge cases in the rasterizer. As for not changing too often, that's true, but taking advantage of that means doing change tracking with dirty-rectangles or similar, which not only adds complexity but also feels like it would make performance less predictable.
And for 2) the game as it stands now is under 50MB so I didn't feel a pressing need to make it smaller, although a tiny executable would be cool in a satisfying, demoscene kind of way.
So, I think I need to elaborate on "GPUs don't like vectors". What the OP meant was "GPUs have literally no support for rendering anything other than pixels on triangles and getting them to efficiently draw Bezier curves and fills is an active area of research". You'd need specific hardware support for rasterizing them, and as far as I'm aware no such hardware exists.
When Adobe hacked on "HTML5 support" to Animate, they did exactly the same thing the OP did. It renders every shape in the FLA to a sprite sheet and then draws it to a canvas tag. If you have knowledge over what will be drawn ahead of time, this is the most reasonable thing you can do.
Even before HTML5 support, the AS3 Starling framework that let you "use the GPU" would pre-render all your vector assets to bitmap textures at runtime. And that was a framework built for Flex developers; if you were accustomed to building things on the timeline, you rendered on CPU, because that's where all of Flash's very particular rendering logic has to live.
Ruffle gets around this by tesselating every shape into a GPU-friendly triangle mesh. This lets us render stuff that's technically vectors on GPU. But as you can imagine, this creates its own problems:
- Flash has very specific stroke-scaling rules. If a stroke is smaller than 1px[0], it will be rounded up to 1px. This is how Flash's "hairline stroke" feature works: it actually asks for a 1/20px[1] stroke, and that gets rounded up to whatever the current scaling factor for that shape is. When your stroke is a polygon mesh, you can't vary the stroke to match Flash without retesselating, so hairline strokes on shapes that stretch don't animate correctly.
- Likewise, any stretch of a stroke that changes the aspect ratio also distorts the stroke, since its baked into the tesselated mesh. There's a minigolf game that does this to hairlines and it will basically never look right in Ruffle.
- Tesselated vectors lose their smoothness, so we have to sort of guess what scale the art is drawn at and add enough detail polygons for things to render correctly. Most of the time we get it right. However, there are some movies that do crazy things like store all the art at microscopic scale and blow it up. This provides a compression benefit, because it quantizes the points on the art with little visual difference on Flash Player. On Ruffle, however, the art becomes very low-poly.
- All the tesselation work takes a significant amount of time. There are certain movies (notably, a lot of Homestuck) that would hang the browser because of how much ridiculously complicated vector art was being processed before the movie even loads. We had to actually limit how much art could tesselate per frame, and expose that to movies as bytesLoaded, which is why Ruffle movies have preloaders even though we don't support streaming download.
There's another approach to drawing Beziers on GPU: drawing the hull of control points with a procedural texture that calculates the underlying polynomial. This is especially simple for quadratic curves (the ones with one control point), which is what all Flash timeline art[2] is.
However, strokes are more complicated. You'd think we could just take the hull of the stroke and draw that as a fill, but you can't. This is because the offset of a Bezier curve is not a Bezier curve. Drawing the stroke in a pixel shader would make sense, except you still need to define a polygon mesh around your stroke with a reasonable texture coordinate system to make the math work. And the polygonal outlines of Bezier curves can get really funky; there's no obvious way to quickly say "here's a curve, now give me the polygon that encloses a 5px stroke around it". Remember how tesselation takes so long that it would hang Ruffle?
[0] I'm not sure if this is virtual or device pixels.
[1] Flash specifies vectors in fixed-point units called tw...
> "GPUs have literally no support for rendering anything other than pixels on triangles and getting them to efficiently draw Bezier curves and fills is an active area of research"
Well fuck me, I had no idea. I figured that 'simple 2D vectors' would be beyond piss-easy for modern GPUs. I'd never considered that it wasn't the actual math space that was accelerated, rather the fast memory mapping of everything on presumably comparatively simple geometries. You've just turned my view of the world upside down :(
Yeah, this is something that many many people assume (vectors are "easy" on GPUs) and then are amazed (like I was!) that they aren't even in the function set. My thought was that if you were "accelerating" desktops you'd really want vectors right? But no.
The interesting thing is that graphics cards in the 90s - which were "desktop accelerators" past the low end - specifically supported accelerated 2D primitives, including Bezier curves for the more powerful ones. It was all gradually dropped as cards focused on 3D games specifically.
Also, as far as I understood, both GNU Gnash and Lightspark were using OpenGL for rendering. So I always expected that GPU would still bring some sort of acceleration for 2D path rendering ?
Have you tried splitting the area covered by each shape into several 8x8 pixel rectangles, then running a compute shader over each one that executes the exact same rasterisation algorithm as Flash did? That's more or less how triangles are rasterised on the GPU anyway.
It's definitely not a simple solution, but might enable you to do runtime rasterisation with a good framerate on the GPU rather than pre-rasterising all the vector art.
I liked it a lot! It doesn't feel like marketing at all, and I think it's a good balance between technical and non-technical (though I wouldn't mind more details).
There's a gem of a hidden narrative here for more junior developers that you don't always need to start over (which 9/10 fails) but instead be resourceful within your constraints and to be mindful of what your constraints actually are, which don't have to be new and shiny.
It was a pretty insightful article, I didn't know how a flash game worked internally and how it could be reimplemented! I think it is also relevant for those migrating their projects to newer technologies, I always found this process fun(except there is a deadline) :)
(Edit: I love your games and used to play a lot when I was a kid)
It's interesting for sure, I'm left wondering if it was less work to make flash continue to work somehow instead of re-authoring the original games.
I mean you've probably learned a lot, but you could have learned to author games using a more modern tool than flash instead and that would have been useful in the future, right?
I thought it was great, and I have no interest in games or game development, but I read the whole thing top to bottom and came away thoroughly impressed. Excellent post and work!
Flash was my 2nd programming language (after VB6) back when it was still Macromedia. I had a lot of fun making really crappy minigames and learning the basics of coding. This article brought some good nostalgia and plenty of astonishment at the lengths you went to.
Your writing itself is great. A lot of writing linked by HN seems too verbose because people try to sound smart. Yours is succinct while engaging. Right length, just technical enough, and interesting. I really enjoyed this, thanks for writing it!
Also:
> Object-orientation is not fashionable right now in gamedev circles
Probably how OO teachers and mentors failed horribly (AFAIK we still don't warn new students about the pitfalls of inheritance ?), so ECS got popular as a better alternative to shitty OOP code ?
Not only that, but due to CPU caches and memory alignment issues, ECS have better performance than inheritance; also because most ECS systems ditch virtual function calls.
Whether or not an ECS will actually be faster depends entirely on the type of game and access patterns of the inheritance structure. Further, it matters how you are doing inheritance (LTO can eliminate a lot of the pitfalls even if you use virtual function calls).
This is nothing against ECS. I just find the current claims of performance dubious and potentially flat out wrong given modern compiler optimizations and changes in CPU caches (mainly that they got a LOT bigger).
I believe claims of "compilers getting faster/bigger enough" are the exact reason we have ECS now. It surely depends of the kind of game, but games with any kind of entity which isn't unique should feel the performance improvements.
Ideally, compilers should be able to transform classes into ECS layout when generating code. Shouldn't be hard to have a pass before compilation, if we use clang.
Object-orientation is kind of the old-school way of doing things, these days it's all about ECS - entity component system. This is a more data-oriented approach that has the potential for much higher performance when you have thousands of objects that need updating in your game. It's similar to how OO languages like Java/C# are going out of style and more (nominally, at least) data-oriented languages such as Go or Rust are in style.
Yeah, "OO is going out of fashion" is a common phrase in gamedev, but what's actually meant is "deep class hierarchies defining the behaviour of game objects is going out of fashion". Most ECS code is still written in OO languages and makes heavy use of OO features.
I watched this talk years ago: CppCon 2014: Mike Acton "Data-Oriented Design and C++"
I was very impressed by the ideas presented.
Java/C# can be used to write a program with "just a bunch of structs + static methods". Isn't that data-oriented enough? Ya, I know we can do 72 levels of inheritance also... for ignore that for a moment.
This was a great read. I distinctly remember playing Hapland as a kid. Armour games or Crazymonkeygames, can't remember which one it was. So this was a great nostalgia trip.
Great article! I also still use Flash by using a custom runtime that interprets the output of the “Export as texture atlas” feature. I was wondering if you had attempted to use this feature in order the rasterize the graphics?
Looks like that feature was added in Animate CC, which I don't use, so I haven't tried it.
Looking at the docs, it looks like something I would have at least tried. Might have saved me writing the rasterizer, though I'd still have wanted to atlas everything together into bigger atlases, and make binary animation files.
One downside vs the .fla parsing approach I went with is that even if you can script away the GUI clicking, you'd still have to have Flash open while the build script runs. I quite like having an exporter that is just a CLI program you can run without Flash, though it's not a massive deal.
I'd be interested to see what exactly Animate puts into the animation.json file it generates. The docs don't seem to mention it, and I couldn't find any example ones online.
Your tool looks great, by the way — have you made any games with it?
I’ll add to the chorus and say that this was a wonderful post and the type of content I hope to find when I come to HN.
I enjoyed how you explained certain technical concepts succinctly and using simple language. For example, as someone who never used Flash, you explained the 1000 ft view of how Flash works. When I’m looking at a new tool or framework, I try to star by understanding the mental model behind it. Yet, a simple explanation of it is often difficult to find.
I was also struck by how much technical work was involved here—you made it sound easy. How long did this project take you?
Also, the idea of using text/assembly as an intermediate format of binary files is pure genius. I will probably use that occasionally for similar use cases.
Adobe couldn’t figure out how to monetize Flash, other than selling the Flash authoring tool to Flash designers, a dying breed, for a few hundred bucks or bundled in Adobe’s Creative Suite. Adobe tried selling Flash video DRM, which got undercut by Google Widevine, and selling licenses to unlock Flash opcodes for advanced 3D and C++ cross compilation, which was undercut by web technologies like WebAssembly.
Also, I think Flash was more expensive to maintain than Adobe’s other design applications because the Flash Player needed constant security patches. Adobe was usually happy to milk cash cow products, such as Director and Shockwave, transferring maintenance to remote teams in India.
I might have missed this in the article but are you sharing any of your work? I know that a lot of the work was manual but some of your tooling might be useful for anyone else who want to go this craftsman route of converting a flash game.
Is it too long, too short, too technical, not technical enough? Boring? Interesting? Is it enlightening or does it just come off like content marketing
Long, but well-organized and not ranty. You can quit after a few sections and still learn interesting things. Technical enough with enough screenshots to keep it from being "wall of text". It is a good way to share some eye candy from your games. [E]nlightening? Yes. [C]ome off like content marketing? Yes, but this is the kind that we want to read -- basically, interesting content marketing. Don't be ashamed that you need to hustle a little bit as a small software shop.
Oh, and you forgot funny. This part made me laugh:
Flash stores its vector graphics in XML format. You might argue that XML is a poor choice for graphics data, but you weren't a product manager at Macromedia. Behold: ...
It is perfectly balanced. It can be read top to bottom in a few minutes.
If you feel like to expand a part you can write a new post and link it from the original one.
Some other posts are born with all the tiny details, are too long to be read on one session and I end up missing even the key points because that second session never happens.
But if you had read TFA you would have realized it talks about creating a new player that can understand swf files so those don’t have to be rewritten, it’s not about using the old, ugly, insecure Flash player from Adobe.
Bank UI authors: Management wanted a pretty UI, so we made a semi-attractive chalice out of Roman dichroic glass. If it breaks, bad guys take your money.
> I don't know if there is anything as good for SVG/HTML.
There's not because the DOM isn't suited for complex animations. People manage to animate SVGs (see Greensock etc.), but it's a pain in the nether regions
Similar experience with using the showcase "AsteroidX" albeit no "unresponsive" dialog though just wouldn't load. It looks like the root of that issue is it requires 3rd party cookies to load but modern browsers block that by default and the error isn't bubbled up to the user. https://www.construct.net/en/free-online-games/asteroidx-650...
Flash was actually pretty great. The big problem with it was the "oh, that thing? it's still around?" attitude of Adobe, which led to massive security problems.
Actionscript was a pretty good language, certainly around the level of what Javascript has become. It was poor-mouthed for the same reasons Javascript was (is?), but now we use Javascript to run 90% of the Web.
I remember back in the early 00s playing with the PHP Flash module. It was a really interesting environment that had a lot of promise. But, alas, it was doomed.
Flash could do 3D 20 years ago, before WebGL and threeJS, and you didn't have to be a Javascript (or ActionScript) expert to build them.
Nothing really exists that beats Flash, partially because the switch to mobile killed Flash's momentum. It also led to the switch in Internet content from Flash animations/toons/games to Youtube/Patreon/Twitch videos. It was easier to make money with weekly videos than trying to get Adsense bucks by making a game every few months.
One college near me still teaches 101 classes through Flash. When presented as an educational tool with disclaimers that the end result is not secure, it's a perfect product to teach with. You can take someone who does not even know how to turn on a computer and by the end of the class they understand what programming is, how to draw on a computer, vector vs bitmap, etc.
Like the sibling comment says, while there are alternative flash players, they are either unmaintained (Shumway since 2016) or not feature complete yet (Ruffle). Since performance was stated as the main goal, a bespoke solution that only supports what the games actually use is probably the best performing.
That would be the easy part. From the post they are already stored as such, but the complexity would be to render the vector graphics in C++ at 60FPS. There is no simple solution to this, and rolling it yourself is quite the task too.
If you look at some of the modern approaches to animation in C++ (like Lottie or Rive) their C++ clients are pretty poorly supported in my opinion, mostly for anti-aliasing quality in native clients over their web equivalents.
I really enjoyed this, thanks for writing the article. Just the idea of bits of Actionscript on Frames and figuring that out would have made me quit never mind everything else. I miss Flash. I used to love the Flex Builder/SWC setup as I used to be really productive with it.
I wish Flash would just be fully open-sourced for niche users to maintain and use it AS IS. I know it supposedly has a lot of vulnerabilities but there are use cases where the pros matter more and this con doesn't matter too much.
Flash is fantastic and I wish it got the respect it deserves from tech circles. It got an entire generation into animation and software engineering, and had really robust and approachable tooling which is yet to be replicated. I think back to the gaming experiences made in Flash and Shockwave as far back as the mid 90s, and nothing today even comes close. Back then, you could load up a webpage on a Pentium II and play a really robust game made by a teenager in their spare time, and that game will be stable and display extremely good performance. Compare that with the complexity and barriers that come with mobile game development today, or the jank and poor performance of JS based games.
TL;DR: It's been decades and there's still no suitable replacement for Flash, and the web is poorer for it.
Flash was conceptually fantastic, and today we can do everything Flash did, and more, with HTML, and WebGL. Unfortunately we don't have the authoring tool to do so. Flash IDE became Adobe Animate, but it has relatively restricted output and capabilities, compared to Flash before.
Unfortunately also Flash was full of bugs, FULL. I mean the player, the IDE, everything. And Macromedia and consequently Adobe were increasingly desperate in monetizing the player by attaching downloads to it, like Adobe Reader or anti-virus software. Or adding nonsense features like half-baked 3D gaming to it.
I don't deny that it had lots of issues. In addition to what you mentioned, it was an accessibility nightmare, and had tons of security problems. All that said, it's difficult to argue with results.
slowly lowers flamethrower indeed, you're right, HTML and WebGL with JavaScript or webasm can do anything flash can..
They can't do it in the cycle-count that flash could (I remember seeing 3D vector demos running in 640x480 pixels on my 133 mhz pentium), but they will do it, and probably look almost identical across two different versions of the same brand of browser..
But the real point is the authoring tools, and there simply aren't any.. We're stuck in the early 80s with a f*cking text-editor for GUI work..
Geez, there were authoring tools for making nice GUI applications in the Windows 3.11 era.. But modern web development has yet to reach that level of maturity.
This is admittedly a few years ago, and the scene has evolved _a bit_ since then, but I remember seeing really simple JS games (think tetris, or a very simple sidescroller) being heartily applauded on sites like reddit and HN. We're unironically cheering approaching parity with a toolset from almost 20 years ago! Things could be so much better.
Back when it was still Dynamic HTML and I was in middle school, I copied the page source to put those into my homepage. I even figured out how to edit levels in the Mario clone.
> today we can do everything Flash did, and more, with HTML, and WebGL.
There's one big piece missing: we don't have an animation/gaming interface that's as easy and intuitive as Flash.
Flash didn't become ubiquitous because it was powerful, but because it was easy for any 13 year old to pick up and do something nice in a couple of days without reading any documentation or doing any course. Good luck getting anything to work in WebGL without any web programming experience.
Developers love saying "But you can do everything that was in Flash directly in Javascript today!!"
I wish they could understand that what they're saying would be equivalent to switching out Excel for a Python IDE and saying "but you can do calculations here too!"
Adobe never cared about Flash beyond it being the webs video player.
Honestly the whole thing just began to rot from a tool perspective since their purchase.
Their management is too PDF-brained to think of investing in quality work in their tools as insane as it sounds they seem to consider their creative tools an afterthought and B2B PDF solutions their main business. I can’t find any other way to explain their actions.
> and today we can do everything Flash did, and more, with HTML, and WebGL
This is a myth, theoretical true, but practically impossible. Flash was so much more than a browser plugin. With HTML5 it is so much harder to maintain a framerate, while in Flash you almost didn't need to care about that.
Flash did skip frames when it couldn't keep up, and this is what any animation framework would do as well for HTML5, or video in video players and so on.
We don't have a well established (in people's minds that is) framework and IDE for it that did all Flash did. But actually I do believe we have everything in place in terms of APIs and capabilities, and in fact even more, because... have you seen some of the WebGL animations? PixiJS? The others?
I doubt. WebGL + the rest of the web stack is way more powerful than Flash EVER was.
Mindshare matters. Without an established IDE and people knowing about it... it's not happening. Another issue is that Flash-like content was notoriously mobile-unfriendly. So we do less of those types of UIs now. Not that we can't... but it's harder.
Wow! Talk about a love letter at the end of 2022! The dev has identified a gap and applies time and effort to solve it through building it.
Halfway, the dev complains about the orignal devs using XML, because it is not efficient "Hey, I'm not complaining, it makes my job easier."
Well sounds like the original developers of Flash made a good decision. If it makes it easier to parse the content at a later stage, I'm willing to call it a win!
Yup, this is classic Unix style! Having data-centric interoperability among tools also helps you port to new platforms more smoothly, as opposed to throwing away your code or rewriting from scratch.
Examples:
1. Using text formats embedded in XML -- he took advantage of this when reverse engineering
2. Generating text ASM -- he said this aids debuggability, and allows using existing ASM tools that he didn't have to write
3. Generating C++ -- taking advantage of the type system, as mentioned, and a huge array of other tools (profilers and debuggers)
It's data-centric rather than code-centric. It's a interoperable and transparent architecture, not a monolithic one. (Which is not surprising because Flash itself was made for the web.)
I was expecting "Attempt 3" to involve Bluemaxima's Flashpoint, and was surprised not to see it mentioned. Does anyone know why that wouldn't have been an option, or is this essentially what Attempt 1 would have involved?
For anyone not familiar with Flashpoint, it's a project to preserve old flash games and animations and keep them playable on modern platforms. It's open source and includes a huge library (including it looks like Hapland 1-3).
Edit: Reading a bit further down the article, it looks like they were able to make some big improvements by building their own engine like supporting wide screen and higher FPS so that sort of answers my question!
I still play games on Flashpoint. Hell, I speedrun and showcase games in Flashpoint during some regular events with my other friends playing ""real"" games. It's not the best UI, but you do have an easy search function to find content you might like.
Gotta be careful to avoid the porn games though. Flashpoint archived some.
It's like Steam for Flash, Shockwave, and Java Applet games. I highly recommend it. Though I do wonder if it's going to survive the transition away from x86...
You mention that while using Flash you found it missing basic features, could you give some examples?
One of my long-term projects is to build a Flash clone (Flash-the-authoring-tool). So I'd love to hear from people who are still using Flash, to see what features / pain points are most important.
* You can't set keyboard shortcuts for some common actions like changing the brush mode between "paint behind", "paint inside", etc. You have to click the button every time.
* No way to import or export any standard vector graphics formats.
* No easy way to just add custom properties to objects on the stage.
* No outliner. Unless you put exactly one object on each layer, it's very hard to find and select objects on the stage that aren't large and obvious. Invisible objects? Nightmare!
* You can name frames, but there's no menu to quickly select one to jump to. In a 500+ frame timeline, you've just gotta manually scroll around to find the frame you're looking for, even if you've named it.
* You can't set an alpha component for the grid to make it semitransparent.
These are all missing in Flash CS6, the last thing that was called "Flash". I don't know if any were added in Adobe Animate because I don't like to rent software.
There's definitely room for a Flash authoring replacement. Every now again I look at all the programs I can find in the space and try them out, but nothing reaches Flash yet, in my opinion, despite its limitations. Best of luck with yours!
Have you tried writing any custom plugins/editor panels to use in the editor? The process is pretty arcane at first, but eventually you are just writing html+javascript and have access to a very powerful editor API.
When I was working with Animate a few years ago I wrote a plugin to navigate around the timeline to find tagged frames and export things.
Yes! In fact, out of those problems I listed, I always thought the timeline navigation (and maybe the outliner) would be good candidates for a .jsfl plugin, I just never got round to doing it. Good to hear it's doable!
I recently used Ruffle [2] to get some Flash applications [0] working in the Pro version of my web browser [1], which is specifically designed to be remotely accessible and embeddable in an iframe. To run Ruffle on pages that require it, I utilize the Chrome Remote Debugging Protocol [3], similar to how a Chrome extension content script operates. Ruffle itself relies on WebAssembly and runs smoothly. It's been exciting to see the audio and video functionality of these old games restored and being able to play them again.
They did mention it. They use it for some of their older games but it seems like Ruffle isn't yet feature-complete with Action Script 3 and thus cannot be used to run their newer games
It sounds like adding those features to ruffle would have been three order of magnitudes easier than writing a flash player from scratch
I understand contributing to OSS is a pain (I often end up with half implemented features in my own branch and never manage to merge them upstream) but he could have saved himself some trouble.
It seems to me like a very different skillset required to reimplement a runtime like the SWF player vs hacking together an alternative FLA compiler that's just good enough to work on your own games.
Ruffle still doesn't support Actionscript 3.0, I suspect the task is not that straightforward.
While Ruffle's AS3 support is still lacking a lot of features, since a couple months ago it's been able to play some simple games that require it. The build used on author's site is from 2021, and I just checked that the latest build is able to play several more AS3 games hosted there.
I'm waiting for it to develop further, I'm very excited, especially because I still play Crystal Saga everyday, I don't know why, but it's got something that I haven't been able to find in any other games.
But sadly, I haven't been able to make Crystal Saga work using Ruffle
MMOs are pretty much the last game Ruffle or any in-browser emulator will get to support - not just because it's likely some of the most complex piece of code you can find, but also because MMOs are likely to use sockets, which AFAIK can't really be accessed in modern browsers at all.
That's great news! I've been meaning to write a cron script or something to fetch the latest Ruffle every week or so, so thanks for reminding me to do that. Thanks also for your work on Ruffle, it's really great.
I would invest more time into a tool that ports your game to Unity. You already have "code" attached to "sprites" with "actions" happening based on some triggers and entity states.
I recently picked up a copy of Flash MX to use on an old PowerBook, highly recommend others do the same. As many have commented, today’s authoring tools are poor substitutes (someone should do a list of the superior abandonware versions of SaaS products).
This linked issue is - quote - "a non-exhuastive, basic checklist of where we are aiming". As in, a checklist for MVP level support. And indeed, we have pretty much reached the MVP level, with several simple games (and some nontrivial libraries like box2d or mochicrypt) working.
From this point on, it's hard to make a simple TODO checklist. We could analyze the entire Flash API surface and make a tracking issue for each available class, but that's a lot of bookkeeping and it doesn't really say that much about real support (as, assuming pareto principle, 80% of fancier features are used by only 20% of games).
I do really enjoyed this kin-of-post-mortem! Please write more, I'd love to hear about your other projects!
As a side note: In my opinion the closest replacement for Flash is currently Construct 3 engine - you should definitely take a look on it! (I'm not associated with Construct 3 team (Scirra) by any means - I'm just a happy user of their product)
> Although I developed the game mostly on my Mac, during development Apple invented this thing called “Notarization” where if you run any app on a new version of MacOS, it'll make a network request to Apple to ask if the app's developer pays Apple a yearly fee. If the developer does not pay Apple a yearly fee, MacOS will pop up a dialog strongly implying the app is a virus and refuse to start it.
> For this reason, Windows will be the first and maybe only release platform for this game.
this seems like the wrong answer to the (arguably legitimate) concern posed. the first and maybe only release platform for this game, based on the reasoning, should have been Linux. It's not like Microsoft can't decide to arbitrarily force exe's to phone home for "security" reasons, but good luck getting the Linux kernel, or any distro, to do that.
I'm 100% convinced that Linux will be the way all software will be preserved in the future; Proton will take care of windows exe's and VM's will take care of Macs, and a deterministic OS like NixOS will let you define exactly what any piece of software needs to build and run, forever. The incentives just line up.
Also the fact that macOS doesn't actually block unnotarized software...Many programs are un-notarized and just need to give the user the 1 step instruction to bypass it
Yes, and I also never felt the macOS warning about it "strongly suggested it was a virus." That was pretty much hyperbole. And I could also argue that Apple expecting devs to pay a nominal fee to get their app officially code-signed creates a barrier to entry for bad actors who are likely to not want (or be unable to afford) to pay such a fee, especially when that simultaneously gives control to Apple to block the malicious code en-masse once it is discovered.
Also the fact that you only need to pay the £99 fee once; after the executable is signed, notarised and stapled, that's it. I think there might be a network request if the executable hasn't been stapled, but it's only to check that it has been notarised in the past, it doesn't check for an active Developer Subscription. At least this is my understanding of the situation, I would be happy to be corrected if any of that is wrong.
Also - you have to sign code on Windows too! If you don't then Edge will try as hard as possible to stop the user opening it, and AV scanners can get very curious about what you're doing. Maybe Steam doesn't care if your game is signed?
I didn't quite follow the logic around notarization either. Steam imposes more requirements and takes a slice of revenue! Notarization is a lot cheaper and faster than that. But I guess the idea is that Steam gives you features, whereas notarization is just a tax.
If Proton is accepted as the solution to Linux gaming what is the reason for a developer to build for Linux over Windows?
Funnily enough there are parallels with that to why Apple didn’t want Flash on iOS. If you could make it in Flash and ship to both why code an iOS app.
Same thing, zero reason to make a native Linux build while that works fine.
It's a good point. Turns out that the Windows API is more stable than whatever Linux offers; I have multiple games now that have native Linux versions on Steam but whose Windows versions running under Proton are simply less buggy (and also synchronize cloud saves with my pure-Windows machine).
A native Linux build is still better performance than Proton, so with the popularity of Steam Deck it is worth the effort recompiling for Linux for higher performance games.
Initially, Apple actually looked at an iOS version of Flash. This was around 2009/2010 IIRC. There were special dev iPhones that ran Flash. Adobe didn’t want to optimize it because they thought the iPhone would fail. Apple thought the performance was garbage and the communication mostly ended. I got to play with one for a few days and the performance was terrible. Even simple games lagged and the touch points were a disaster.
I was heavy working in Flash around this time, I remember Apple saying the performance of Flash was too bad to consider using on iPhone and I remember around 3 months later the Mac version of Flash magically ran 4 times better when for years and years it always ran a lot slower than Windows and Adobe pretended there was nothing they could do about it.
Many 2D illustrators, industrial designers, and graphic designers considered it one of the best 2D drawing tools ever made.
One of my roommates in the heyday of Flash was an industrial designer who was paid by an Italian business to design aftermarket wheels for cars, which he did in Flash. Eventually he figured out a Flash > Studio Max workflow he liked and finished projects in 3D that way.
That guy could draw anything in Flash and preferred it over Illustrator, Photoshop, and Fireworks.
Funnily enough that was actually the original goal of Flash - back when it was called SmartSketch. The idea was to have a vector drawing tool for pen tablets. But it sold absolutely horribly.
Jonathan Gay pivoted it to animation shortly thereafter and rebranded it as FutureSplash, and then got bought out by Macromedia.
> I like to use binary formats where possible for end-user software; I don't believe in making customers' computers chew through reams of XML.
I feel an urge to object here! This is a false dichotomy; there are efficient middle-ground solutions between XML and custom binary formats e.g. Protobuf and Cap'n proto.
Having said that, I loved the trick of using an assembler to write it.
> The vintage Flash UI is great. Buttons have edges. Icons look like things. Space is well-used. It's amazing! Using old UIs makes me feel like an archaeologist discovering some sort of forgotten Roman technology. The lost art of UI design. It's neat.
This was one my favourites parts in the article. An the real piece of the pie comes right after it: there's a screenshot with like thirty icons and they're different enough that you can tell one from the other.
It's like entire industry at one point decide to optimize UIs for the first 30 minutes of usage and not the years of users using apps once they get familiar with them.
"oooh let's not put too many buttons to scare users away", "they got 22 inch screens, let's just waste space for no good reason, it looks modern and airy"
Yes. What we see in UI design today is a consequence of game theory at work. It's to optimize business. In fairness you don't want to scare users away. I think though many people equated it all to "clean looking", without realizing removing micro-interactions is a net negative....
I think touch screens are a bigger factor. You can't have small buttons in a touch-screen UI, because they must be targets for your finger. (OTOH, swipes in a touch UI are a lot easier than mouse drag-and-drop. So the optimal touch UX probably has lots of drag-activated pie menus. And confirmation flows for potentially destructive actions, to cope with the lower accuracy of touch interactions.)
Yeah, if my memory serves a lot of UI design started to get more airy around the time smartphones became more popular. Even on desktops, which I think may just be because large buttons and text became trendy and although some may deny it, I think a lot of ui design is just following trends. It takes a good designer to not just blindly copy things because they look cool.
The problem is these "designers" bring those touch-optimised UIs to desktop. And so you end up with hamburger menus on 4k-screens, tall narrow alert dialogs on MacOS etc.
One of the early attempts to balance those two goals was an option in the settings to switch between Beginner/Intermediate/Advanced mode. Never really see that anymore.
That's the discipline of data-driven business. If 20 people use your app and despise it and are depressed by it, that's better than 19 people using it and loving it. No sentimentality allowed.
How could anyone possibly measure that an app is despised and depresses people (or vice versa)?
Usage can't be it, because I use a ton of software that I despise and get depressed by, but only because I get paid to do so, or the app is so niche there isn't a viable replacement.
> How could anyone possibly measure that an app is despised and depresses people (or vice versa)?
You'd have to actually talk to your users. But that requires genuine human investment, so it doesn't scale. It doesn't come in the form of a third-party SaaS with a pretty dashboard, generous free plan, and integration via single <script> tag.
In short: they could measure this, they just don't bother to.
UI is now optimized for PowerPoint. The #1 goal of all UI work is so the designer and/or product manager can get an "oh, that looks nice!" showing off screenshots to an interviewer or to someone higher-up who'll help them get a promotion. Trendy (you don't want to look outdated, do you?) and pretty are what matter, not usability.
I find it somehow intriguing how you already pre-destined this imaginary book to be great… That stood out to me for some reason. How about a great title for a shitty book?
Funnily enough, The Lost Art Of UI Design sounds like a potentially very mediocre book to me. One of those stretched-out "self-teaching" design guides that listicles will recommend you. It chooses a couple of very specific rules of thumb, it gives way too much importance to them, and somehow manages to water them down to 250 pages. Probably written either by someone who's a skilled writer but barely knows enough about the industry, or an experienced specialist in the field who unfortunately can't write for life.
I get (and agree with) this idea in general, but these buttons are still present in any Adobe apps (esp. Photoshop) and they're not going anywhere.
Hell, I don't think they're original to Flash to begin with, more like borrowed from Photoshop when Adobe bought Macromedia (this is purely my speculation; but Photoshop is much older).
For years I've had a "Google" folder on my phone which links to all the obligatory things - Drive, Maps, Calendar, Meet, etc.
Ever since they made this move to every icon being a minimal shape with the 4 Google colors, I haven't been able to quickly differentiate between app icons. I have to read the labels half the time now cause they're so non-indicative of the app's purpose.
407 comments
[ 2.4 ms ] story [ 329 ms ] threadIf that's not "Hacker" News, what is?
However I wonder why the OP didn't try to keep vector graphics and use to SVG for instance? That would allow for infinite scalability. It is mentioned that "GPUs don't like vectors" but if the game doesn't change too often it should not make a lot of difference?
For 1) I decided I'd rather just release an update with larger textures if these ones ever start to look dated. That way I get to keep the runtime code simple. Less code means fewer bugs. I don't want to spend a lot of time fielding support requests from users who hit edge cases in the rasterizer. As for not changing too often, that's true, but taking advantage of that means doing change tracking with dirty-rectangles or similar, which not only adds complexity but also feels like it would make performance less predictable.
And for 2) the game as it stands now is under 50MB so I didn't feel a pressing need to make it smaller, although a tiny executable would be cool in a satisfying, demoscene kind of way.
When Adobe hacked on "HTML5 support" to Animate, they did exactly the same thing the OP did. It renders every shape in the FLA to a sprite sheet and then draws it to a canvas tag. If you have knowledge over what will be drawn ahead of time, this is the most reasonable thing you can do.
Even before HTML5 support, the AS3 Starling framework that let you "use the GPU" would pre-render all your vector assets to bitmap textures at runtime. And that was a framework built for Flex developers; if you were accustomed to building things on the timeline, you rendered on CPU, because that's where all of Flash's very particular rendering logic has to live.
Ruffle gets around this by tesselating every shape into a GPU-friendly triangle mesh. This lets us render stuff that's technically vectors on GPU. But as you can imagine, this creates its own problems:
- Flash has very specific stroke-scaling rules. If a stroke is smaller than 1px[0], it will be rounded up to 1px. This is how Flash's "hairline stroke" feature works: it actually asks for a 1/20px[1] stroke, and that gets rounded up to whatever the current scaling factor for that shape is. When your stroke is a polygon mesh, you can't vary the stroke to match Flash without retesselating, so hairline strokes on shapes that stretch don't animate correctly.
- Likewise, any stretch of a stroke that changes the aspect ratio also distorts the stroke, since its baked into the tesselated mesh. There's a minigolf game that does this to hairlines and it will basically never look right in Ruffle.
- Tesselated vectors lose their smoothness, so we have to sort of guess what scale the art is drawn at and add enough detail polygons for things to render correctly. Most of the time we get it right. However, there are some movies that do crazy things like store all the art at microscopic scale and blow it up. This provides a compression benefit, because it quantizes the points on the art with little visual difference on Flash Player. On Ruffle, however, the art becomes very low-poly.
- All the tesselation work takes a significant amount of time. There are certain movies (notably, a lot of Homestuck) that would hang the browser because of how much ridiculously complicated vector art was being processed before the movie even loads. We had to actually limit how much art could tesselate per frame, and expose that to movies as bytesLoaded, which is why Ruffle movies have preloaders even though we don't support streaming download.
There's another approach to drawing Beziers on GPU: drawing the hull of control points with a procedural texture that calculates the underlying polynomial. This is especially simple for quadratic curves (the ones with one control point), which is what all Flash timeline art[2] is.
However, strokes are more complicated. You'd think we could just take the hull of the stroke and draw that as a fill, but you can't. This is because the offset of a Bezier curve is not a Bezier curve. Drawing the stroke in a pixel shader would make sense, except you still need to define a polygon mesh around your stroke with a reasonable texture coordinate system to make the math work. And the polygonal outlines of Bezier curves can get really funky; there's no obvious way to quickly say "here's a curve, now give me the polygon that encloses a 5px stroke around it". Remember how tesselation takes so long that it would hang Ruffle?
[0] I'm not sure if this is virtual or device pixels.
[1] Flash specifies vectors in fixed-point units called tw...
Well fuck me, I had no idea. I figured that 'simple 2D vectors' would be beyond piss-easy for modern GPUs. I'd never considered that it wasn't the actual math space that was accelerated, rather the fast memory mapping of everything on presumably comparatively simple geometries. You've just turned my view of the world upside down :(
they are, but on nvidia only... https://developer.nvidia.com/gpu-accelerated-path-rendering
But signed distance fields work well and easily on GPUs.
Here's a recent article and discussion about it:
Vector graphics on GPU (gasiulis.name)
235 points by mpweiher 4 months ago | hide | past | favorite | 95 comments
https://news.ycombinator.com/item?id=32384016
https://gasiulis.name/vector-graphics-on-gpu/
(OK those links are for NVidia, but if they can do it I guess others can too ?) (also see https://www.researchgate.net/publication/262357352_GPU-accel... )
I've seen some font rendering work that has already embraced them for high perf rasterization.
Still, may be hard to get flash equivalency.
It's definitely not a simple solution, but might enable you to do runtime rasterisation with a good framerate on the GPU rather than pre-rasterising all the vector art.
Keep writing!
(Edit: I love your games and used to play a lot when I was a kid)
I mean you've probably learned a lot, but you could have learned to author games using a more modern tool than flash instead and that would have been useful in the future, right?
Your writing itself is great. A lot of writing linked by HN seems too verbose because people try to sound smart. Yours is succinct while engaging. Right length, just technical enough, and interesting. I really enjoyed this, thanks for writing it!
Also:
> Object-orientation is not fashionable right now in gamedev circles
Can you elaborate on this?
https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...
Can have.
Whether or not an ECS will actually be faster depends entirely on the type of game and access patterns of the inheritance structure. Further, it matters how you are doing inheritance (LTO can eliminate a lot of the pitfalls even if you use virtual function calls).
This is nothing against ECS. I just find the current claims of performance dubious and potentially flat out wrong given modern compiler optimizations and changes in CPU caches (mainly that they got a LOT bigger).
Ideally, compilers should be able to transform classes into ECS layout when generating code. Shouldn't be hard to have a pass before compilation, if we use clang.
I watched this talk years ago: CppCon 2014: Mike Acton "Data-Oriented Design and C++"
I was very impressed by the ideas presented.
Java/C# can be used to write a program with "just a bunch of structs + static methods". Isn't that data-oriented enough? Ya, I know we can do 72 levels of inheritance also... for ignore that for a moment.
I wish the Hapland series was coming to Mac, but I respect your decision to snub Apple.
https://github.com/jackwlee01/animate_cc_runtime
Looks like that feature was added in Animate CC, which I don't use, so I haven't tried it.
Looking at the docs, it looks like something I would have at least tried. Might have saved me writing the rasterizer, though I'd still have wanted to atlas everything together into bigger atlases, and make binary animation files.
One downside vs the .fla parsing approach I went with is that even if you can script away the GUI clicking, you'd still have to have Flash open while the build script runs. I quite like having an exporter that is just a CLI program you can run without Flash, though it's not a massive deal.
I'd be interested to see what exactly Animate puts into the animation.json file it generates. The docs don't seem to mention it, and I couldn't find any example ones online.
Your tool looks great, by the way — have you made any games with it?
I enjoyed how you explained certain technical concepts succinctly and using simple language. For example, as someone who never used Flash, you explained the 1000 ft view of how Flash works. When I’m looking at a new tool or framework, I try to star by understanding the mental model behind it. Yet, a simple explanation of it is often difficult to find.
I was also struck by how much technical work was involved here—you made it sound easy. How long did this project take you?
I second that. I find the better someone knows a subject, the harder it is for them to provide this perspective, making it all the more impressive.
Also, the idea of using text/assembly as an intermediate format of binary files is pure genius. I will probably use that occasionally for similar use cases.
It's an impressive piece of writing. You're definitely good at this.
Did you investigate Haxe or OpenFL?
Also, I think Flash was more expensive to maintain than Adobe’s other design applications because the Flash Player needed constant security patches. Adobe was usually happy to milk cash cow products, such as Director and Shockwave, transferring maintenance to remote teams in India.
Oh, and you forgot funny. This part made me laugh:
Some other posts are born with all the tiny details, are too long to be read on one session and I end up missing even the key points because that second session never happens.
I think you could still call this a soft port.
Security people: %drops it on the ground and it shatters% yes but glass is terribly insecure, why not redo it with PVC and LEF strip Christmas lights.
Bank UI authors: Management wanted a pretty UI, so we made a semi-attractive chalice out of Roman dichroic glass. If it breaks, bad guys take your money.
Or maybe it's just me reminiscing
There's not because the DOM isn't suited for complex animations. People manage to animate SVGs (see Greensock etc.), but it's a pain in the nether regions
It can export videos, GIFs, image sequences, can use modern JavaScript coding, and has a surprisingly strong block-based visual alternative to coding.
1. Clicked on your link
2. Moused over "Construct 3" in the header, clicked "Showcase."
3. Clicked on a game in the showcase at random ("Bunnicula in Rescuing Harold").
4. Page loaded with a graphic & a play button.
5. I tried clicking play & nothing happened.
6. Shortly after, Brave (Chrome) showed its "Page unresponsive" dialog.
Actionscript was a pretty good language, certainly around the level of what Javascript has become. It was poor-mouthed for the same reasons Javascript was (is?), but now we use Javascript to run 90% of the Web.
I remember back in the early 00s playing with the PHP Flash module. It was a really interesting environment that had a lot of promise. But, alas, it was doomed.
I was always surprised that it didn't get more traction. Though Typescript is leaps and bounds beyond where AS3 ever was
Nothing really exists that beats Flash, partially because the switch to mobile killed Flash's momentum. It also led to the switch in Internet content from Flash animations/toons/games to Youtube/Patreon/Twitch videos. It was easier to make money with weekly videos than trying to get Adsense bucks by making a game every few months.
https://scratch.mit.edu/
Also, it might compete with Adobe Animate.
"Service as a Software Substitute"
https://www.gnu.org/philosophy/who-does-that-server-really-s...
But I see that ActionScript is not supported in HTML output either, so I agree that it doesn't compete much.
https://github.com/mozilla/shumway
https://ruffle.rs/
If you look at some of the modern approaches to animation in C++ (like Lottie or Rive) their C++ clients are pretty poorly supported in my opinion, mostly for anti-aliasing quality in native clients over their web equivalents.
The AS3 VM at its heart however was open sourced.
TL;DR: It's been decades and there's still no suitable replacement for Flash, and the web is poorer for it.
Unfortunately also Flash was full of bugs, FULL. I mean the player, the IDE, everything. And Macromedia and consequently Adobe were increasingly desperate in monetizing the player by attaching downloads to it, like Adobe Reader or anti-virus software. Or adding nonsense features like half-baked 3D gaming to it.
They can't do it in the cycle-count that flash could (I remember seeing 3D vector demos running in 640x480 pixels on my 133 mhz pentium), but they will do it, and probably look almost identical across two different versions of the same brand of browser..
But the real point is the authoring tools, and there simply aren't any.. We're stuck in the early 80s with a f*cking text-editor for GUI work..
Geez, there were authoring tools for making nice GUI applications in the Windows 3.11 era.. But modern web development has yet to reach that level of maturity.
Back when it was still Dynamic HTML and I was in middle school, I copied the page source to put those into my homepage. I even figured out how to edit levels in the Mario clone.
There's one big piece missing: we don't have an animation/gaming interface that's as easy and intuitive as Flash.
Flash didn't become ubiquitous because it was powerful, but because it was easy for any 13 year old to pick up and do something nice in a couple of days without reading any documentation or doing any course. Good luck getting anything to work in WebGL without any web programming experience.
I wish they could understand that what they're saying would be equivalent to switching out Excel for a Python IDE and saying "but you can do calculations here too!"
Honestly the whole thing just began to rot from a tool perspective since their purchase.
Their management is too PDF-brained to think of investing in quality work in their tools as insane as it sounds they seem to consider their creative tools an afterthought and B2B PDF solutions their main business. I can’t find any other way to explain their actions.
This is a myth, theoretical true, but practically impossible. Flash was so much more than a browser plugin. With HTML5 it is so much harder to maintain a framerate, while in Flash you almost didn't need to care about that.
We don't have a well established (in people's minds that is) framework and IDE for it that did all Flash did. But actually I do believe we have everything in place in terms of APIs and capabilities, and in fact even more, because... have you seen some of the WebGL animations? PixiJS? The others?
I doubt. WebGL + the rest of the web stack is way more powerful than Flash EVER was.
Mindshare matters. Without an established IDE and people knowing about it... it's not happening. Another issue is that Flash-like content was notoriously mobile-unfriendly. So we do less of those types of UIs now. Not that we can't... but it's harder.
Halfway, the dev complains about the orignal devs using XML, because it is not efficient "Hey, I'm not complaining, it makes my job easier."
Well sounds like the original developers of Flash made a good decision. If it makes it easier to parse the content at a later stage, I'm willing to call it a win!
Examples:
1. Using text formats embedded in XML -- he took advantage of this when reverse engineering
2. Generating text ASM -- he said this aids debuggability, and allows using existing ASM tools that he didn't have to write
3. Generating C++ -- taking advantage of the type system, as mentioned, and a huge array of other tools (profilers and debuggers)
It's data-centric rather than code-centric. It's a interoperable and transparent architecture, not a monolithic one. (Which is not surprising because Flash itself was made for the web.)
Related: The Internet Was Designed with a Narrow Waist https://www.oilshell.org/blog/2022/02/diagrams.html
A Sketch of the Biggest Idea in Software Architecture https://www.oilshell.org/blog/2022/03/backlog-arch.html
For anyone not familiar with Flashpoint, it's a project to preserve old flash games and animations and keep them playable on modern platforms. It's open source and includes a huge library (including it looks like Hapland 1-3).
https://bluemaxima.org/flashpoint/
Edit: Reading a bit further down the article, it looks like they were able to make some big improvements by building their own engine like supporting wide screen and higher FPS so that sort of answers my question!
Gotta be careful to avoid the porn games though. Flashpoint archived some.
Ruffle is the flash emulator https://ruffle.rs/
One of my long-term projects is to build a Flash clone (Flash-the-authoring-tool). So I'd love to hear from people who are still using Flash, to see what features / pain points are most important.
* You can't set keyboard shortcuts for some common actions like changing the brush mode between "paint behind", "paint inside", etc. You have to click the button every time.
* No way to import or export any standard vector graphics formats.
* No easy way to just add custom properties to objects on the stage.
* No outliner. Unless you put exactly one object on each layer, it's very hard to find and select objects on the stage that aren't large and obvious. Invisible objects? Nightmare!
* You can name frames, but there's no menu to quickly select one to jump to. In a 500+ frame timeline, you've just gotta manually scroll around to find the frame you're looking for, even if you've named it.
* You can't set an alpha component for the grid to make it semitransparent.
These are all missing in Flash CS6, the last thing that was called "Flash". I don't know if any were added in Adobe Animate because I don't like to rent software.
There's definitely room for a Flash authoring replacement. Every now again I look at all the programs I can find in the space and try them out, but nothing reaches Flash yet, in my opinion, despite its limitations. Best of luck with yours!
When I was working with Animate a few years ago I wrote a plugin to navigate around the timeline to find tagged frames and export things.
-
[0]: https://github.com/ruffle-rs/ruffle/wiki/Test-SWFs
[1]: https://github.com/crisdosyago/BrowserBox#bb-pro-vs-regular-...
[2]: https://github.com/ruffle-rs/ruffle
[3]: https://chromedevtools.github.io/devtools-protocol/tot/
I understand contributing to OSS is a pain (I often end up with half implemented features in my own branch and never manage to merge them upstream) but he could have saved himself some trouble.
The tool that the author made reads Flash fla files and exports data from that.
Swf files contain binary data. The ActionScript code has been compiled into bytecode. The vector data is probably also represented in binary format.
Fla files, as pointed out in the OP blog post, contain XML data.
It sounds like OP is doing something quite different from what Ruffle does.
Ruffle tries to be a player for swf files.
OP wanted to export data from Fla XML to other formats, so that he could build executable games.
Ruffle still doesn't support Actionscript 3.0, I suspect the task is not that straightforward.
(note: I'm a Ruffle dev)
But sadly, I haven't been able to make Crystal Saga work using Ruffle
From this far away it looks like it could work.
https://github.com/ruffle-rs/ruffle/issues/1368
I recently picked up a copy of Flash MX to use on an old PowerBook, highly recommend others do the same. As many have commented, today’s authoring tools are poor substitutes (someone should do a list of the superior abandonware versions of SaaS products).
From this point on, it's hard to make a simple TODO checklist. We could analyze the entire Flash API surface and make a tracking issue for each available class, but that's a lot of bookkeeping and it doesn't really say that much about real support (as, assuming pareto principle, 80% of fancier features are used by only 20% of games).
As a side note: In my opinion the closest replacement for Flash is currently Construct 3 engine - you should definitely take a look on it! (I'm not associated with Construct 3 team (Scirra) by any means - I'm just a happy user of their product)
> For this reason, Windows will be the first and maybe only release platform for this game.
this seems like the wrong answer to the (arguably legitimate) concern posed. the first and maybe only release platform for this game, based on the reasoning, should have been Linux. It's not like Microsoft can't decide to arbitrarily force exe's to phone home for "security" reasons, but good luck getting the Linux kernel, or any distro, to do that.
I'm 100% convinced that Linux will be the way all software will be preserved in the future; Proton will take care of windows exe's and VM's will take care of Macs, and a deterministic OS like NixOS will let you define exactly what any piece of software needs to build and run, forever. The incentives just line up.
I didn't quite follow the logic around notarization either. Steam imposes more requirements and takes a slice of revenue! Notarization is a lot cheaper and faster than that. But I guess the idea is that Steam gives you features, whereas notarization is just a tax.
Funnily enough there are parallels with that to why Apple didn’t want Flash on iOS. If you could make it in Flash and ship to both why code an iOS app.
Same thing, zero reason to make a native Linux build while that works fine.
https://en.wikipedia.org/wiki/My_Little_Pony:_Friendship_Is_...
https://en.wikipedia.org/wiki/List_of_Flash_animated_televis...
One of my roommates in the heyday of Flash was an industrial designer who was paid by an Italian business to design aftermarket wheels for cars, which he did in Flash. Eventually he figured out a Flash > Studio Max workflow he liked and finished projects in 3D that way.
That guy could draw anything in Flash and preferred it over Illustrator, Photoshop, and Fireworks.
Jonathan Gay pivoted it to animation shortly thereafter and rebranded it as FutureSplash, and then got bought out by Macromedia.
Uhhhhhhh, hold on a second, wait a second... this is not readily apparent nor obvious as a course of action at all!!
I would rather have gathered the raw assets and tried recoding the game using the same game logic on a better platform...
Also happy to see all the libraries I love to work with pop up here and there.
I feel an urge to object here! This is a false dichotomy; there are efficient middle-ground solutions between XML and custom binary formats e.g. Protobuf and Cap'n proto.
Having said that, I loved the trick of using an assembler to write it.
This was one my favourites parts in the article. An the real piece of the pie comes right after it: there's a screenshot with like thirty icons and they're different enough that you can tell one from the other.
"oooh let's not put too many buttons to scare users away", "they got 22 inch screens, let's just waste space for no good reason, it looks modern and airy"
The crucial difference between then and now is the amount of whitespace.
Usage can't be it, because I use a ton of software that I despise and get depressed by, but only because I get paid to do so, or the app is so niche there isn't a viable replacement.
You'd have to actually talk to your users. But that requires genuine human investment, so it doesn't scale. It doesn't come in the form of a third-party SaaS with a pretty dashboard, generous free plan, and integration via single <script> tag.
In short: they could measure this, they just don't bother to.
I seriously think that's what's going on.
This sounds like a great title for a really good book.
Funnily enough, The Lost Art Of UI Design sounds like a potentially very mediocre book to me. One of those stretched-out "self-teaching" design guides that listicles will recommend you. It chooses a couple of very specific rules of thumb, it gives way too much importance to them, and somehow manages to water them down to 250 pages. Probably written either by someone who's a skilled writer but barely knows enough about the industry, or an experienced specialist in the field who unfortunately can't write for life.
Hell, I don't think they're original to Flash to begin with, more like borrowed from Photoshop when Adobe bought Macromedia (this is purely my speculation; but Photoshop is much older).
Ever since they made this move to every icon being a minimal shape with the 4 Google colors, I haven't been able to quickly differentiate between app icons. I have to read the labels half the time now cause they're so non-indicative of the app's purpose.