About Time and Space in Indie Software Development

So yeah not a lot of post recently on here, so let’s make a combo kinda like a blog post
about some articles I’ve seen on the wire, and yep it will be related to ActionScript 3.

Let’s start with this, which is about time

‘Aztez’: The bloody indie brawler that should’ve been big
‘I know we’re going to be okay, but everything blows right now.’

Oh man… it always make my little dev heart aches when I read such story.

To summarise, 2 indie dev decide to build a game, they build it with blood, tears and sweat;
for 5 freaking years, while they are doing it they are in their dev bubble, the market changed.

What changed? well steam is not anymore proposing a small curated list of games but is now
an overcrowded place with gazillions of games being released every damn day, their game?
does not get noticed enough, not enough sales and it sucks (not the game, the effort/reward ratio).

And you know what? it’s not the first time I’m reading this kind of story, it keeps popping up,
again and again and again, it’s sad.

That’s the time parameter for all indie dev: is it worth spending that much time on that software?

And let’s be clear, I’m not trying to discourage anyone here, if you feel it in your guts
whatever it is, app or game or anythign really, if you are really into “doing it” sure go for it,
by all means.

But … you should consider that time parameter.

That does not mean you should cancel your project, that just means you should optimize for time.
And to do so think about what can make you save time or spend less time to reach your goal,
eg. building whatever software.

It’s here that I raise the card ActionScript 3!!

But ActionScript alone is not enough, it’s just a language, any language is good enough to build software, the most important good parts is how easy you can build software with it.

Well, “easy” is not exactly the right term, it’s more about something that is not getting in your way,
that if you tackle it long enough it will be days not months before you can see something on your screen.

That’s the very strength of AS3, you can prototype and test and experiment pretty damn fast with it,
simple proof: all those flash games you have seen on your web browser for the last decade or so.

Counter story to the story above is Super Meat Boy

Super Meat Boy is an independent video game designed by Edmund McMillen and Tommy Refenes and developed by Team Meat. It is the successor to McMillen and Jonathan McEntee’s 2008 flash game Meat Boy. Super Meat Boy was released on the Xbox 360 through Xbox Live Arcade in October 2010, on Microsoft Windows in November 2010, on OS X a year later in November 2011 …

Those dev did test their gameplay with a small prototype first, and you can still play it here (~10 years later).

The second important thing that comes with AS3 is the Flash API, an API that is not perfect but good enough to do the basic things simply like playing sound or displaying an image or moving things on screen or using sockets to talk to a server etc.

And this same philosophy extend to Adobe AIR (the Flash API extended for desktop and mobile if you want), where basic simple things will be there like drag n drop, keyboard shortcuts, touch events, reading/writing files etc.

See, in this AS3 ecosystem, on top of the language and the API, you also have the tooling;
that very special blend between tools for artists/animators/… like Animate CC (Flash CC)
and proper command-line tools like MXMLC/COMPC/ASDOC/… for the dev/coder/… inclined.

Just being solo you can do a lot, if you are 2 (1 dev + 1 gfx) the sky is the limit already.

Oh yeah you can argue all you want if that or this programming language is better, sure
they will have command-line tools too, but will they have something like Animate CC ?
something that can produce SWF that combine code and graphics altogether and can be reused in apps or games ?

Not really …

We could also argue if their API is better than Flash ? I mean … com’on even if, right now, you are not using AS3; I’m pretty sure you wish you had some of its easy API at your disposal, or maybe even you already started to clone some of those API because you miss them and need them badly.

I’m not kidding, search “Flash API ported”, you will find version for JS, Dart, Java, Swift, etc.
Not the most extensive API but it does shine by its simplicity so much that you want to mimic it.

Forgive me the shameless self plug, but yeah I do try to follow the same philosophy with Redtamarin, and again it’s not only the language or the API.

The same way you can easily prototype an app within Animate CC (gfx inclined) or something like Flash Builder (dev inclined), that let you quickly and easily see it on the screen (a simple SWF), and then you can jump to building an AIR app, maybe only for one platform first, but then you can work more on it and make it work on another platform to the point of building an ANE to add very specific custom features.

With Redtamarin, in its own limited environment to the command-line, you can simply start with a shell script (plain text, not even need to compile it) then maybe move to something a bit bigger like few classes you compile to an *.abc, and then maybe you want to reuse a library and so that lib and your code you export a *.swf (that combine many *.abc together), to finally produce a single executable for maybe one platform or more platforms later.

Even if it’s not visual, the idea is to keep things frictionless, in both case you can pretty much jump from small prototype to full blown app with tons of features (not overnight OK…).

In fact, you’ll hit friction mainly if you want to do very hard things, but the easy things stay easy;
while other ecosystem may make you jump through many many loops.

Being able to do things pretty fast is a unique selling point (USP) for AS3.

And now let’s talk about the other part: the space, or where you gonna publish this app or creation of yours.

In the sad story above, while the developers were in their “coding bubble” the marked they planed to publish to had dramatically changed (read the whole story for all the details), and toward the end they think “hey we already spent 5 years to build a game for steam on PC, let’s put more time to publish it to console”.

Ok … maybe …

Really I’m not trying to discourage anyone, but even if there have been a lot more of opportunities for indie dev to publish on console, man … that is a much bigger investment, especially if you did not plan it right from the start and you use that as your “escape gate”.

It’s simple as that: you don’t magically port an app from one platform to another platform.

Unless, right from the start, you picked up an ecosystem that allow you to do it not so painfully,
and that’s where I’m talking about ActionScript again.

Let’s kill the elephant in the room first: publishing to the web.

If you’re not living under a rock you must do know that Flash EOL is planed for 2020,
so at the very best, easy publishing of SWF files embedded in HTML will come to an end.

And I do agree, for some times, publishing to the web have been the “be all, end all” of Flash apps and games, but when you’re thinking about that space parameter, same as with the time, you must ask yourself: is it worth publishing that software in that space?

This bring me to another little story

Stealing sensitive browser data with the W3C Ambient Light Sensor API

In this post we describe and demonstrate a neat trick to exfiltrate sensitive information from your browser using a surprising tool: your smartphone or laptop’s ambient light sensor.

WTF am I smoking right? please … allow me to explain while I puff on regular nicotine.

In the HTML5 race to compare and compete with Flash since the late 2010 to reach the point “yep we made it, we can do the same things as Flash, we are now the better platform”, the development of the Web APIs have been all over the place.

And that W3C Ambient Light Sensor API illustrate perfectly the problem.

By trying so hard to push the web to compete with native apps, well… they blew it.

Adding everything and anything, in API, to be able to say “oh yeah we can do the same as native app”
kind of ruin the whole HTML purpose as a document, a bit like if tomorrow you decide you
want to make all your nice cat animated gif also do stuff that app does.

Crazy right?

So that’s basically the battle of web apps vs native apps.

Everyone use the web so web apps should win defacto … oh really?

Not so fast, I already mentioned in an earlier post, but let’s say it again:
your space (where you publish your app) will be determined by the users that are supposed to use your apps, and where there is more users is better for you as an indie developper/creator of apps.

It is all about the market share (again).

Ok it’s not only that but it is a pretty damn important factor.

The kind of app you want to build can directly influence where you gonna publish it,
but let’s be clear you will not see a lemonade stand in the middle of winter,
it will be much more successful in the middle of summer when it’s hot.

A very stupid thing is that with basic potato logic any web user is either a desktop or a mobile user first, the browser does not run by itself, it is just another app on your desktop or mobile device.

Let’s see some numbers

see: 2017 U.S. Cross-Platform Future in Focus

Oh shiznits… web apps does not seem all that people promise them to be, who knew???

Could it be that mobile took over the web ?

That’s a lot of growth alright :smile:

But again take those stats with a grain of salt, see that for example

The web get a lot of visitors but less engagement while the apps gets 20x more engagement.

And there, people spend more time on mobile but spend more on desktop.

So yeah it is not that clear cut, if you want to sell stuff with e-commerce, you certainly want to follow the amazon model where users use a browser to shop, a desktop app here would make less sense as it would have less reach to users, online search, etc.

My point here is that web apps can be extremely good (vs desktop apps) but only in certain specific categories, the obvious one being search engine (duh!).

The other point here is to see what drive digital growth and mobile is clearly the winner,
and by association users prefer native apps (vs web) on mobile but then you also end up in the “publishing on a crowded market like Stream” (like the sad story at the beginning) where users, even if more engaged, will not install 100 of apps per day.

For the big fish (or sharks) like apple, google, amazon, facebook etc. there is no difference really between web or native apps, even if Google promote HTML5 hard they are still publishing native appas where users want them (you probably use gmail on your browser for the desktop and on a native app for mobile).

Still, this growth show that there are cycles, if sometimes ago it was the web, now it’s mobile, but all that does not mean platform shrink in favour of other platform, there are just more and more users every day.

And most importantly things change all the time when it comes to software.

From 20 years ago publishing a freeware desktop app on Windows, to 10 years ago publishing a Flash game on the web, to 7 years ago publishing mobile apps, to 5 years ago “hey desktop is a la mode again” let’s publish to Steam.

The where depends on the when too.

And yeah ActionScript not gonna allow you to target everything and anything, but that’s a good thing.

By focusing on the main interesting targets (where most users are): Windows, macOS, Android, iOS
well… you can hardly go wrong.

Off course, it’s not for all the apps, aided by Adobe AIR your app can really shine on those
4 “little” platforms, you will be able to do much more than with a web app, just look at all
those dev (who for some reasons do not know AIR) are happy to publish their desktop app
with Electron because it allow them to target the desktop and not the web.

See the irony :wink: ?

There are dev who actually chose web technologies to not publish their app on the web.
Could it be that the web itself limit what their apps can do?
Could it be that a native app, once you reach a certain level, offer a better experience?

I mean, think of the mobile apps, why users prefer so much more the native apps?
Or let’s go to the extreme, would you load a 2 Gigabytes web app to launch “Photoshop Web CC” ?

I’m not saying that web apps are dead or that there are no users on the web,
but there are specific type of apps which will work better on the web,
and a lot of other apps that will work better as native.

You should see Adobe AIR as your graduation from web app developper (ex-Flash) to somewhat native app developper.

Where you can push the limit a bit further in fact, as you are out of the limitations of those web technologies (the Out Of Browser experience that is AIR).

See it like that, even if you were building a mini-photoshop that works as a SWF in a web browser,
just purely out of “you not being crazy” it would make sense to improve it even more and make it a desktop and/or mobile app.

It’s again the harder vs easier of the space where you want to publish.

Let’s reduce it to the basic, a simple text editor, no formating, no syntax highlighting,
simple pure text like notepad.exe on Windows.

You could build that in HTML/CSS/JS but it will be harder for many parts,
and I bet more code would go into the server backend than the JS code.

If you build it in AIR, oh yeah it get easier pretty … pretty fast!,
oh wait … you can even directly build it for macOS and Windows
and because it is on the desktop it makes it so much easier for users to
actually create/read/edit/save/delete their *.txt file on the … desktop!.

And by just using basic AIR stuff that are already there and easily usable,
you can think of tons of other features that will end up being pretty hard
to implement with HTML/CSS/JS

  • use all the different font installed on the user computer
  • use custom font that the user does not have installed on its computer
  • drag n drop (great API in AIR, sucks in HTML)
  • share/sync files over RTMFP on the local network (no server needed)
  • etc.

And yeah that’s a damn good example because technically text editing
is much more easy to do in HTML (it is made orignally to display and format text, see SGML)
but not for the nice thing like saving a damn text on your desktop
which also explain why every damn single desktop operating system out there
come with a default basic text editor like notepad.exe, TextEdit.app, etc.

Users expect to edit their private text on their machine, not the web.
But then if the text need to be public and shared, sure a wiki on the web will win over a desktop text editor.

Now, this space is not all rosy.

It is always a pros and cons thing, for all the advantages that AIR can bring you fast,
you get also one big disavantage: the publishing part.

That’s the unbeatable USP (Unique Selling Point remember?) feature of web apps,
they live on the web, they do not need to be installed or updated (or remembered).

And at the opposite, this is the biggest shortcoming of using AIR,
not really for mobile apps, as there, it is streamlined with mobile app stores,
but for desktop humm yeah… the publishing can be tricky.

As much as being able to publish an *.air file (and even from a web page which was genious) was all nice and dandy, nowadays you would want to go with a captive-runtime AIR app which lead to the numerous headache of creating an installer for it, and signing it and converting it (case of Windows 10 universal app) and updating it.

My point in all that, still saying that AS3 and AIR (and even Redtamarin) are great to build apps,
you could see the web as a platform to publish “lite” apps and you could see native as the platform
where you publish “more advanced and/or serious” apps.

Where you define the threshold of what is lite or advanced is up to you.

Now for the conclusion, whatever app or game you want to build, if you combine both parameters of time and space as an indie dev and based on what kind of app you would prefer to build, I do think using AS3 can make you go faster (to a certain degree, it’s not magic either) while still targeting platforms where most users are.

But still, you’re not out of the wood, because even if your app does not work in the browser you still gonna have to build a minimal web presence to reach those users wether blog, advertising, video, forum, etc.

Another irony :smile:, a native app can not really exists without a web site promoting it.

But one last thing that can be great about AS3, see this

Mainly on the desktop and less on mobile, you can build your AIR desktop app as a kind of smart client, a main SWF (the shell of your AIR app) that load remote SWF, I bet you already did it tons of times on the web with Flash :wink:.

Thanks for this breakdown zwetan. We are in good position for the future requirements :wink:

Let’s just code!!! In debug mode :wink: