T-machine.org

I’ve been using this technique for a year or so and it’s awesome. Sadly it’s not something you’d ever find unless you knew to look for it, but I’d like more people to know and use this. It works beautifully for any situation where you have multiple lines of code that must stay together, but which have to remain separate – e.g. an API that requires you to call “manager.Begin();” … then your own code, then … “manager.End();”

We’re going to commandeer the “using” keyword for something it wasn’t originally designed for but which is a 100% legal use of it.

Have you ever needed to do this in C#?

In Unity there are some very common examples of this problem, most famously in the old GUI.* API (which is finally, slowly, being replaced by UIToolkit – but there’s a lot of GUI.* code still in live games).

GUILayout.BeginVertical();
GUILayout.Label( "Options" );
if( GUI.Button( "Option1" ) )
{
   Process1();
}
if( GUI.Button( "Option2" ) )
{
   Process 2();
}
GUILayout.BeginHorizontal();
GUILayout.Space( 20 );
GUILayout.BeginHorizontal();
GUILayout.Label( "[advanced]" );
if( GUILayout.Button( "Option3" ) )
{
   Process3();
}
... and now I have to remember which order to EndHorizontal, EndVertical, and how many times for each

This is a very simple example and yet already it’s both timeconsuming to type all those “GUI.EndHorizontal/EndVertical” (the IDE cannot autocomplete them for you because it has no idea what you want here) and also highly error-prone.

Problems: Code together … but apart

It’s annoying trying to remember all the bits you’ve Begin’d but not yet End’d, but the real problem comes when you need to edit that code, inserting another piece of embedded horizontal layout halfway down.

Or when you copy/past a chunk of it and try to re-use it elsewhere.

You might try to be smart and move this stuff to a method call, but … that quick becomes painful for two reasons:

1. You need to generate method calls and insert them in your sourcecode based on context. You can do that, but now you’re having to pass-around functionpointers, it’s no longer a simple method.
2. You don’t know which order they’ll happen in, or how many times, so now you also need to create a stack object to keep track of this. You also have to implement all the cases of Exceptions etc and making sure the stack unwindws correctly, and … and …

Solution: IDisposable / using{}

C# has a nice little feature that fixes all of this. It converts my code above into:

using( new Vertical() )
{
   GUILayout.Label( "Options" );
   if( GUI.Button( "Option1" ) )
   {
      Process1();
   }
   if( GUI.Button( "Option2" ) )
   {
      Process 2();
   }
   using( new Horizontal() );
   {
      GUILayout.Space( 20 );
      using( new Horizontal() );
      {
         GUILayout.Label( "[advanced]" );
         if( GUILayout.Button( "Option3" ) )
         {
            Process3();
         }
      }
   }
}

Two things have happened here:

• Improvement 1: We never have to remember to End() anything!
• Improvement 2: All code is now surrounded in {braces} making it much easier to read, and to edit safely!

Both of them are side-effects of IDisposable/using.

How to implement it

You have to create a class that holds the magic code. In the GUILayout.BeginHorizontal example I made a class “Horizontal”. This class has to implement Microsoft’s IDisposable interface – and there’s plenty of docs online for how to do this, it’s quite easy. Here’s a simple example:

class Horizontal : System.IDisposable
{
   public Horizontal()
   {
      GUILayout.BeginHorizontal();
   }

   public void Dispose() // but read WARNING below
   {
      GUILayout.EndHorizontal();
   }
}

The way that “using” is implemented by Microsoft is:

1. The object is created as normal (when you call ‘new’ in “using( new Horizontal();”)
2. The code in braces runs as normal
3. When the close brace is encountered, MS destroys the temporary object you created
4. …which has the side effect of calling “Dispose” on that object
5. All of this is managed for you, and copes well with exceptions etc

WARNING: the simple example isn’t quite correct

If you subclass your Horizontal object this may start to go wrong because of how Dispose works. This is documented on MS’s official pages, but the simple explanation is that “Dispose” can be called more than once on the same object (when they’re subclassed), so you need to add some code to ignore the extra calls. Here’s the classic example:

class Horizontal : System.IDisposable
{
   public Horizontal()
   {
      GUILayout.BeginHorizontal();
   }

   public void Dispose() // perfect example
   {
      Dispose(true);
      GC.SuppressFinalize(this);   
   }
   protected virtual void Dispose(bool disposing)
   {
      if (!_disposed)
      {
        if (disposing) 
        {
            GUILayout.EndHorizontal();
        }

        // Indicate that the instance has been disposed.
        _disposed = true;   
      }
   }
}

Performance optimization: ZERO garbage-collection!

If you care about performance then you typically want to make your core methods non-allocating. Creating temporary objects like in the above examples has no effect most of the time – but if you ever use it on a core method that you call tens of thousands of times a frame (note: anything less than tens of thousands and you probably won’t notice, unless your game is very performance-heavy) it’ll start to create enough garbage that GC becomes a problem.

We can fix that, and get rid of the double-dispose problem, by converting it to a struct.

Unfortunately … C# doesn’t allow structs to have a zero-argument constructor, so we have to add at least one fake parameter to make this work. In most cases there’s some obvious parameter you can think of that improves your implementation. e.g. here I’ve added the same optional param that GUI.BeginHorizontal has:

struct Horizontal : System.IDisposable
{
   public Horizontal( params GUILayoutOption[] options )
   {
      GUILayout.BeginHorizontal( options );
   }

   public void Dispose() // but reading WARNING below
   {
      GUILayout.EndHorizontal();
   }
}

To save myself an hour next time I need to install JupyterLab (the latest 2020 version of Jupyter) here’s a step-by-step install from scratch on self-hosted AWS, warts-and-all. Key points:

• We want to use jupyter-lab instead of the legacy jupyter-notebook
• The notebooks/labs must be private, it’s absurd to think otherwise
• We want online / cloud access to our work
• We want the minimum of effort to install and get working with Jupyter
• We want the minimum complexity to maintain the installation

Core investigations + conclusions

Hosting: Use AWS

I researched many sources of 3rd-party hosting for Jupyter and they all … well, sucked. There was a great article on free hosting – but all of those forced your private data to be placed in public for anyone/everyone to take.

I looked at the ones that had private “upgrades” available from their free/public tier, but they came with intensely complicated procedures (e.g. you lose access to all your data) and confusing and difficult pricing (mostly designed for ML programmers, but irrelevant to people not doing ML).

Finally I went through the most widely-referenced “Jupyter hosting” companies I found via Google and forums posts and reddit etc etc. Some of these looked good, but nearly all of them were running either legacy Jupyter (which was superceded 2 years ago!) or their own custom “this isn’t jupyter, it’s a thing-that-is-a-bit-like-jupyter, missing core features, with our own proprietary changes” which is undesirable. Poster-child there was Google who – yet again – created a pointlessly proprietary system that you’re locked into, and which has a high probabilty Google will shut it down and delete all your data with no upgrade option (as they are currently doing multiple times a year :)).

Eventually I came back to self-hosting: how hard would this be? There are multiple guides on this, both from 3rd parties (some of them broken/incorrect with key steps missing) and from the official Jupyter website. Custom instructions were provided for AWS which was a good sign (along with GCE, Microsoft cloud, etc) Reading through the instructions they were essentially:

“Steps 1-20: Setup a new AWS default cloud instance (identical to all AWS hosting.
Steps 21-25: Do a couple of Jupyter-specific post-install steps”

…with the vast majority of the setup work being AWS (which isn’t a great install process, but if you’ve used AWS you’ve already done this many many times and are comfortable with it), self-hosting seemed the best way forwards.

AWS: tiers and options

Confusingly there’s two branches of Jupyter self-hosting: Jupyter and JupyterHub. The latter is a multi-users-working-on-one-machine with each having their own loing username and personal password, with private or semi-private notebooks etc. For myself as a single user that was overkill – although the install instructions were even simpler than the main Jupyter (ironically).

None of the install guides were detailed (or useful) in their advice on picking an AWS instance, apart from the JupyterHub one. With some digging on reddit it turns out that 100MB or so of RAM should be more than enough for running notebooks, with “as much more as the size of data you intend to hold in RAM”. If you’re coding very lazily you might try loading massive source data into RAM but … we’re sensible programmers, we don’t do that.

Summary: The smallest AWS instance - t2.nano - works fine with 0.5GB RAM, and the (2020) minimum EBS disk of 8GB SSD.

(If you hit the RAM limit: spin down your AWS instance, replace it with a t2.micro, attach the EBS to the new AWS, then spin it up again. This is exactly what cloud hosting was invented for! It’s easy, so no need to worry about it here)

UPDATE:

Jupyter doesn’t need much RAM.

But node.js – which a lot of UI-related Jupyter plygins rely on – requires gigabytes of RAM to work at all, and it crashes with useless error messages rather than handle its own errors.

It’s quite eye-opening how bad node.js code is (I believe this isn’t node.js itself, rather it’s an ecosystem and habits of people who write node.js apps – there’s nothing wrong with their choices, but they’ve prioritised embedding other people’s code they don’t understand (and mostly don’t need) rather than spend a few minutes writing simple code themselves. The net result is that if you want to install (or even reconfigure :() any of the JavaScript related plugins (which is all of the UI ones) then you’ll need to temporarily boost your AWS instance to a larger instance each time, and then downgrade it after the upgrade. 2GB RAM is recommended for node.js. To be clear: for actually using Jupyter, 200MB is more than enough – i.e. node.js alone requires 10x as much RAM as the entire system you’re running!

AWS install summary

If you’ve created EC2 instances before, the short version here is:

• A small EC2 instance
• Running standard ubuntu (18.04 or 20.04 as of this writing)
• A security-group which unblocks SSH (for manual install tasks) + one port (for web access)

Traditionally a lot of people unblock port 8888 but there appears to be no reason for this other than installation being done by people who don’t really know what they’re doing with web server configs. A bit like the node.js setup – people copying random pieces of instructions without actually reading them. In months of usage, I’ve found no ports need to be unblocked (why create a security hole when you don’t need to?).

Jupyter initial install

Installing Jupyter core is straightforward … and broken in ubuntu 18.04 (the main ubuntu release when I did this in early 2020, unless you’ve upgraded to 20.04 already). By default it will fail to install – this appears to involve known bugs, but the workarounds are so quick to do that no-one is in a rush to fix it. I’m assuming that in ubuntu 20.04 it’s been fixed.

Step 1: Update Ubuntu

Do your apt updates etc (I prefer to use aptitude for all apt management so I can see what’s happening and make more informed choices about versions etc – for me it’s hitting ‘u’ and let aptitude do it automatically).

Step 2: install jupyter

The apt is named ‘jupyter’ and should automatically bring in all the required modules, python3, pip, etc. It should also setup a basic install of jupyter with Python notebooks enabled etc. The magic of debian/apt!

Step 3: install the python parts of Jupyter (specifically: JupyterLab)

Here’s where it goes python-y and stops working. Unfortunately Ubuntu does not (yet) have an apt for JupyterLab that actually works – and it has to be installed over the top of a legacy Jupyter installation (that we already have thanks to parts 1 and 2).

What follows is all standard for python developers, nothing new. But if you’re not a python developer … You have to “install” jupyterlab by using python’s in-built self-management systems, which aren’t as good as the OS ones. No more apt for you :(. For extra pain: python wants you to jump through hoops to keep multiple copies of itself on the system – because the packages aren’t managed well enough for the OS to use python and for you to use it at the same time.

In my case: I have a dedicated server that is doing nothing but running Jupyter and I have no intention of upgrading python on one without upgrading the other. I was happy to use a single Python install, and avoid a lot of problems and confusion. Worst case if one does something weird in a future release I’ll simply wipe the server and re-install – we’re in the decades of commodity cloud computring, and re-installing OS’s in seconds, not hours.

In theory (from the docs), you run:

pip3 install jupyterlab

In practice, that:

• Installs it in a hidden folder buried inside the home-directory of the current user
• Fails to install it correctly: it cannot work
• Leaves a different version of Jupyter on the system that is missing the new features

FAIL. Maybe related to the expectation that you have multiple Python installs – but I wasn’t going to mess around with that added complexity only to discover that it was broken anyway (if it doesn’t work out of the box, I don’t trust it to work out of a more complex box…).

The nearest I found to an official workaround appears to be: update your linux user’s PATH to make it preferentially run the hidden-secret-silently-mis-installed version of Jupyter. Do that and everything appears to work fine. Or … just remember to always type

/home/ubuntu/.local/bin/jupyter

everywhere that you would normally have typed:

jupyter

Step 4: configure jupyter to work correctly

Out of the box Jupyter won’t work on a server: it’s been deliberately designed to fail even if you correctly installed it (this is not a bad thing: it’s designed to be idiot-proof for people who install on their personal laptop). To make it run as a server you can either mess around wasting time doing ssh-tunneling (why? WHY??!! Why have so many online guides told people to do this? Blind leading the blind, it seems…).

…Or: you can simply enable the server mode :), which works fine and is easier to setup (and cleaner).

But at first: you cannot do that. Out of the box jupyter can’t even be configured: it’s missing it’s own config file. Fortunately it has a ‘feature’ where you can get it to auto-create the config file (why it doesn’t do this as part of installation I have no idea), but it’ll be placed somewhere super-annoying:

jupyter notebook --generate-config

…and helpfully it’ll immediately tell you where it created it, probably:

/home/ubuntu/.jupyter/jupyter_notebook_config.py

As per this stackoverflow answer (https://stackoverflow.com/a/43500232/153422) you only need to change two lines to enable server mode. One line allows server access, and the other says “listen on all IP addresses”. You can find the commented-out lines in the file and uncomment them + change their values, or you can just copy/paste the values from that SO answer into the bottom of the file.

While you’re there, it’s worth changing the default values / inserting:

c.NotebookApp.open_browser = False
c.NotebookApp.port = 8888 (whatever you unblocked in AWS security group)

Step 5: run Jupyter-lab and login for the first time

To run jupyter-lab you need something like this:

~/.local/bin/jupyter-lab

Three things now happen:

1. Jupyter is up and running and spits out lots of info to the command-line. Check it for errors – there shouldn’t be any
2. It specifically tells you which IP addresses it’s listening on.
3. It gives you a magic, temporary, token to login with.

The IP address list is wrong, but … at least it will show you that it’s listening to more than just localhost and 127.0.0.1 (if it’s only listening to them then you failed to edit the config properly).

It tries to guess the info using OS lookups, but they did it naively and they did it wrong: they will fetch private addresses that don’t exist, instead of the public ones. But if you’ve used AWS before you know how to get the public IP and/or public DNS from your EC2 management console (in AWS management console, select the EC2 instance, and click on the “Connect” button and you get a popup telling you exactly how).

So use the correct IP/DNS, go directly to that server / port address (ignore the ?token rubbish that the jupyter commandline app wanted you to use). You’ll get a login page where you can copy/paste the token from the commandline output and immediately login.

Or, better: jupyter’s login page helpfully gives you the option here to use the temporary token to generate a password you can use in future instead.

Step 6: Switch to TLS/HTTPS (make the web-browser connection secure)

Don’t self-sign, self-signing is being aggressively blocked by web-browser vendors (Google, Mozilla, Apple, etc) – again: ignore the bad advice and articles written by Jupyter users who don’t know what they’re doing. Instead use the free LetsEncrypt service for industry-standard automatically renewing signed certificates that you can fire-and-forget.

Follow the jupyter main docs directly:

https://jupyter-notebook.readthedocs.io/en/stable/public_server.html#using-lets-encrypt

Step 7 (final!): make Jupyter run as a service

This part shows how poorly this python app is integrated with the host OS – Jupyter doesn’t run as a service. You have to manually convert it into one.

Most people do this the brutally simple way: either run the command line with ampersand (i.e. linux’s “run-in-background but if you lose your ssh connection it might die”) or run it with ‘screen’ (linux’s more advanced multi-tasking app that makes it easy to re-access later and will survive even if you lose SSH connection or logout of ubuntu).

Much much better would be to convert it into a full ubuntu service – I googled the latest recommended instructions for this and followed them, but sadly I didn’t save the URL. It depends slightly whether you used new-style ubuntu (with systemd) or legacy (init) – but creating new ubuntu services is very common and quite easy to do so I’ll leave that for you to Google and find your preferred approach :).

I’ve always found ContentSizeFitter a source of great hope … and bitter disappointment: often it’s the only way to “solve” a problem in UnityUI, but half the time when you try it messes up your UI and breaks the UnityEditor Undo function. You have to delete your UI elements and rebuild them from scratch :(.

Unity’s own staff have pointed out on the forums that it only works in limited scenarios (some of what we think of as bugs they’ve explained as side-effects of Unity’s built-in layout algorithms, which make it “impossible” to expand content to fit. That’s not entirely true, since Flexbox4Unity is able to do all of these, and it’s embedded inside the Unity system :), but I agree the core Unity layout alogirithm isn’t great).

CSS/Flexbox has a much better layout algorithm (and a free, open-source, speification that anyone can implement). In the Flexbox4Unity plugin, this works nicely, and auto-resizing / size-to-fit UIScrollviews just happen “for free”, every time, no problems. I’ve posted a guide for setting up UIScrollviews this way inside Unity: http://flexbox4unity.com/2020/04/08/guide-automatically-resize-uiscrollview/

My simple OpenOffice spreadsheet for tracking Unity Asset Store revenues per-asset.

http://t-machine.org/wp-content/uploads/UnityAssetStoreRevenues-Template.ods

Usage/setup instructions included on the first page (scroll down).

To fill in the data, I use a script that scrapes the Unity publisher portal. But for short periods of time, you can easily fill this in by hand. My script needs some cleanup before I share it – some recent changes to the Unity webpage broke it and I haven’t updated it yet.

Unity Terrain is a good Terrain renderer, but the API’s behind it are famously badly documented and rather clunky (most of the documentation still hasn’t been written, almost 10 years after it was launched). At Unite this year they were showing-off some of the “new Terrain” features/tools, all of which were aimed at artists, and look great.

But what about the Terrain itself? Unity 2019.2 and 2019.3 still have the ponderous old API and it seems we’re stuck with it for at least another few years. Today I found and fixed an issue in my custom Terrain-tools that took our Editor rendering from < 4 FPS back to normal realtime speeds.

The secret is to use Unity’s required float[,,] arrays (which Microsoft only partially supports in C#) but plug the gap in C# which causes them to be slow when interacting with Unity’s Serializer (which fires 6 times per frame in the Editor, magnifiying any slowdown considerably!)

NB: As far as I can tell, you cannot fix the Unity “serialize 6 times even if it’s not needed, where only 1 would have been fine” issue, because the methods to do that only exist on Custom EditorWindows, and not on Custom Inspectors. But it’s bad practice to be slowing-down the serializer anyway, so I’m happy with fixing MY code to run fast, and then stop worrying about the Unity Serialization layers being inefficient.

The problem: float[,,] isn’t supported by Unity

Unity requires you to use float[,,] for textures/splats/alphamaps on their terrain.

However, Unity has never supported multi-dimensional arrays in their engine (this is finally getting fixed sometime in 2020, I believe, with the new Serializer). So your data gets wiped every frame. Thats a pain when making Terrain-editing scripts.

The workaround is to implement Unity’s ISerializationCallbackReceiver interface, and provide the missing code that Unity doesn’t (i.e. serialize a float[,,]). The standard way of doing this is something like:

NB: I’m only showing half of the serialize/deserialize here, just to illustrate the point

[code language=”csharp”]
void ISerializationCallbackReceiver.OnAfterDeserialize()
{
deltas = new float[_Serialize_2D_Length0, _Serialize_2D_Length1, _Serialize_2D_Length2];

/** NB: iterate in C#’s internal storage order for [,,] */
for (int i0 = 0; i0 &lt; _Serialize_2D_Length0; i0++)
for (int i1 = 0; i1 &lt; _Serialize_2D_Length1; i1++)
for( int i2 = 0; i2 &lt; _Serialize_2D_Length2; i2++ )
deltas[i0,i1,i2] = _Serialize_1DArray[i0 * _Serialize_2D_Length1 * _Serialize_2D_Length2
+ i1 * _Serialize_2D_Length2
+ i2];
}
}
[/code]

…which retrieves every cell in the float[,,] from a cell in a private float[] (which Unity DOES support and will auto-serialize for you).

The problem is that C# for-loops are extremely slow when used like this, simply because of the scale of the operation. For a typical Unity terrain, you’re copying up to 4096 x 4096 samples (your splatmap) with anywhere from 5 to 10 values for each. Each value is a 4-byte 32-bit float.

i.e. 4k x 4k x 10 x 4 == 640 MB of data

…which destroys your 100+ FPS frame-time, taking it to 1 FPS or worse.

You need to copy this data in a single call, not in 640,000,000 separate method calls.

But … how?

Array.Copy() to the rescue!

It doesn’t work. You can compile your C# class, and then the C# runtime will cry when you try to execute it:

RankException: Only single dimension arrays are supported here.

Bummer. In theory, Array.Copy() would have solved the problem – this is literally what it was designed for: bulk copying of large arrays without the overhead of doing millions of tiny copy-calls.

Try again … Buffer.BlockCopy()

Fortunately there’s another method in C# core that steps-in and saves us. I often find that when C# ties your hands behind your back, the reason it hasn’t been changed/updated/improved is that there’s a lesser-known behind-the-scenes low-level method that you can (ab)use to achieve what you need, and the language maintainers recommend you do that instead of them updating the mainstream stuff. Fair enough!

The one caveat with BlockCopy is that you need to tell it the size in bytes that you’re copying NOT the number of array items.

i.e.: [code language=”csharp”]Array.Copy( from, 0, to, 0, length )[/code]
becomes: [code language=”csharp”]Buffer.BlockCopy( from, 0, to, 0, 4 * length ) // if copying float, or int, or any of the other 32bit primitives[/code]

20x faster Terrain data handling

The modified serialization callback becomes:

[code language=”csharp”]
void ISerializationCallbackReceiver.OnAfterDeserialize()
{
deltas = new float[_Serialize_2D_Length0, _Serialize_2D_Length1, _Serialize_2D_Length2];

int bytesPerFloat = 4;
Buffer.BlockCopy( _Serialize_2D, 0, deltas, 0, bytesPerFloat * deltas.GetLength( 0 ) * deltas.GetLength( 1 )*deltas.GetLength( 2 ) );
}
}
[/code]

One of Unity3D’s greatest successes has been the Asset Store. Bursting to life 9 years ago, initially sounding a lot like an optimistic clone of Apple’s 2-year-old App Store (and boasting the same 70%/30% revenue share), it turned out to be so much more.

But Unity still struggles to figure out what it should look like and how it should work for users/purchasers. The raw content is the biggest determinant of the store’s success, but closely followed by the browsing and discovery experience – which have hardly improved at all (and in some ways have gone backwards) over this past decade.

Based on hundreds of purchases, and having launched and maintained some small assets on the store myself over the past 5 years, here’s what I’d like to see now.

The A-test for Unity Assets

Every asset-purchase page should have a section that answers the critical, machine-answerable, fully 100% automatable questions that matter to purchasers. There is no excuse to miss this out – these make a huge difference both to users, and to authors, and to Unity itself: they massively reduce the amount of refund requests, and increase the purchase volume due to increased buyer-confidence.

How well do your assets score on these? If you’re an author, do you publish all this information up-front (some do – their Full Description on the asset page is long and scrolly)

Art Assets

• Min/avg/max verts per model in package
• Top 3 shaders in package, with number of models that use each
• Min/avg/max texture sizes in package
• Total number of materials with unassigned textures/colors vs fully assigned
• Total number of materials using Standard shader with Albedo, Metallic, Normal, Roughness maps assigned
• Total number of models with LODs vs number of models without LODs
• Min/Max LOD levels for models with at least one LOD
• Number of prefabs in package that have same prefix-name as an FBX/model file

Code Assets

• Number of files that include source code (C#) vs number without source code
• Number of (Unity official) Unit-tests in package
• (one line for each Unity version): Num Errors, Num Warnings, when installing the project
• (one line for each Unity version): Num Errors, Num Warnings, when opening the marked demo-scene
• (one line for each Unity version): Num Errors, Num Warnings, when pressing play in the marked demo-scene
• (one line for each Unity version): Number of Unit tests passed, number failed

All Assets

• Number of demo scenes in package
• PDF documentation in package
• Time since Author’s last edit of package (upload)
• Time since Author’s last discussion of package (meta files + comment threads)

Self-reported / author-tagged info

All the above was easily automatable by Unity (Apart from “issue reports”, which Unity keeps private, I’ve written scripts myself that do all of them!)

What happens when we extend the Asset Store Publisher Upload tool to let authors add extra info that Unity can then collate and publish? Well…

Art Assets – author controlled

• Render-pipelines supported: Default?, URP?, HDRP? (tickboxes)
• Player platforms compatible: Windows, PS, XB, VR, iOS, Android, WebGL (tickboxes: “compatible” means “author expects it to work, but isn’t actively testing that platform – it may not work out of the box”)
• Player platforms supported: Windows, PS, XB, VR, iOS, Android, WebGL (tickboxes: “supported” means “author actively tests on this platform and promises it will work out of the box (or fixed very rapidly)”)

Nice-to-have’s only Unity can provide

• Ask-the-author question box on purchase page (SO MANY TIMES people need to check if an asset supports X or Y, or ask the author if they include something, and Unity still provides no way for the purchaser to do this)
  …with answered-questions automatically appearing for all to see (just like Amazon has done for the past 15+ years)
• Number of reported issues per Unity version (OR: star-rating per unity version)
• Number of refund requests (successful + unsuccessful) by Unity version and/or package version

2020 future-looking awesome “make everyone rich” features

• When author uploads the asset, choose a Demo scene that will be auto-built as a WebGL build and embedded in Asset Store page (if build succeeds)

I witnessed three basic flaws in latest Android this week – all of them redolent of bad UX design on Google’s part – and surprising in an almost 10 years old OS (none of them are new features).

So … you may notice the site disappeared for some time, and now it’s back all images are missing. This is down to three things: