Slime Rancher is another Unity game to have black screen problems on Linux, here's a temp fix

I don't have the game :/


Last edited by Creak on 5 March 2018 at 4:41 pm UTC

Quoting: ShmerlHow can such regressions be even released? Unity has no QA?

I don't think this is a regression. Unity supports/releases updates for multiple versions concurrently and just looking at the major.minor version isn't enough to work out which version is older than another.

Slime Rancher is on 2017.1.0p4, which was released in August last year. The fix for the issue highlighted here didn't land in the 2017.1.x branch until 2017.1.0p5, which AFIK coincides with it being fixed in the 5.6.x branch.

IMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.


Last edited by Cheeseness on 5 March 2018 at 11:47 pm UTC

Quoting: CheesenessI don't think this is a regression.

It is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

Quoting: Shmerl

Quoting: CheesenessI don't think this is a regression.

It is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

It's definitely a bug, and everybody felt very embarrassed when it was discovered that that bug made it into release builds. The problem was resolved pretty quickly and, in my opinion, it was handled as well as it could have been. So far as I'm aware, it also resulted in improved testing practices, which is really all we can expect/ask for.

I think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that aren't updated by developers anymore.


Last edited by Shmerl on 6 March 2018 at 2:32 am UTC

Quoting: ShmerlI think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that arne't updated by developers anymore.

As I understand it, the engine specifically looks for data files made by the corresponding editor version so that it's not possible to mismatch engine/data versions. Given how much stuff can change between releases and how much work upgrading can be, that's pretty sensible.

Allowing users to swap in/out whatever engine version they please sounds nice, but it would also create more opportunities for QA oversights (not to mention increased support overheads for developers who couldn't be certain of what versions their users are running). A cool thought, but definitely a double edged sword.

Quoting: CheesenessSlime Rancher is on 2017.1.0p4, which was released in August last year. The fix for the issue highlighted here didn't land in the 2017.1.x branch until 2017.1.0p5, which AFIK coincides with it being fixed in the 5.6.x branch.

Yep, we've improved our testing and QA workflow for about a year now. When we detect a regression, we backport it to the earliest supported branch. The idea is that we don't backport a fix to a previous version until the next version is fixed. This is done in order to prevent from having a bug fixed in 2017.1 and 2017.3, but not 2017.2, which would be considered as a regression.

The "p*" releases are patched versions that contains the most recent fixes. At some point, we pack together all the patches and re-delploy a new release.

That is why a fix can be in both 5.6 and 2017.1, but the game devs still need to use the latest version of their release in order to have the latest fixes.

Quoting: CheesenessIMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.

You're right, we do have detailed release notes for each versions, but it's very difficult to bring interest to them.

Quoting: ShmerlIt is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

It's not because a bug is easy to reproduce that it means it is easy to discover. We have tens of thousands of tests that runs non-stop on our build machines. When we create a feature, we also create tests for it, and each time we detect a regression, we create a test to prevent it from reappearing. But despite all that, it happens that we don't detect some bugs in time for the next release.

But as you can see from Cheeseness comment, we fixed the linux-fullscreen bug and backported it on all the supported releases. Now it is up to the game devs to make the update. If they're using 2017.1.0p4 and the fix is indeed in 2017.1.0p5, it should not be too much of a risk to upgrade their game to this release. But upgrading the engine is not an easy job as a game dev, you still need to verify that it doesn't add more regressions in your game. If they don't have QA resources (which must be the case for 99% of the indie devs), or unit tests of their own (which would not surprise me if it was also another huge majority), upgrading the engine is definitely a riskier move to make.

Quoting: Cheeseness

Quoting: ShmerlI think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that arne't updated by developers anymore.

As I understand it, the engine specifically looks for data files made by the corresponding editor version so that it's not possible to mismatch engine/data versions. Given how much stuff can change between releases and how much work upgrading can be, that's pretty sensible.

Allowing users to swap in/out whatever engine version they please sounds nice, but it would also create more opportunities for QA oversights (not to mention increased support overheads for developers who couldn't be certain of what versions their users are running). A cool thought, but definitely a double edged sword.

Well put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.


Last edited by Creak on 6 March 2018 at 4:02 am UTC

Quoting: CreakWell put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.

Simplest, but not available if developers don't have time or will to do it. So giving users that unsupported option is not a bad thing in such case. Most will never use it, and those who would, know it's not a guaranteed method. If Unity would have been properly FOSS, it would have been doable anyway, just by the nature of the openness :)


Last edited by Shmerl on 6 March 2018 at 4:08 am UTC

Quoting: Shmerl

Quoting: CreakWell put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.

Simplest, but not available if developers don't have time or will to do it. So giving users that unsupported option is not a bad thing in such case. Most will never use it, and those who would, know it's not a guaranteed method. If Unity would have been properly FOSS, it would have been doable anyway, just by the nature of the openness :)

I've been helping/working with Levi (one of Unity's primary Linux developers) to identify and resolve issues with Unity's Linux player for years and have had the opportunity to witness this first hand. For a variety of reasons (some more valid than others), many developers are unwilling to upgrade.

As a proponent of Free Software and a Free Software developer, I love the idea of getting rid of the distinction between users and developers. As someone who also exists within the proprietary world, I can see that if we end up in a situation where proprietary developers can be sell a Linux game and then leave it up to Linux users to solve their own problems, the long term impact of that would be that we wouldn't get any actual support :(

It's not a nice situation either way, but I think this is just the nature of the proprietary world. The best thing we can do is focus on rewarding/supporting developers who support us properly and report bugs/work with/make note of those that don't (FWIW, I've shot information through to the developers of Slime Rancher with details on the issue and its resolution).

Quoting: Creak

Quoting: CheesenessIMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.

You're right, we do have detailed release notes for each versions, but it's very difficult to bring interest to them.

It's bigger than this though. That focuses on what's fixed in each patch release, and doesn't make note known critical issues that have/have not been resolved in future patch releases. If I could point a developer to a list like that, I think I'd have an easier time convincing them of the value of upgrading.


Last edited by Cheeseness on 6 March 2018 at 8:09 am UTC

@Cheeseness: Maybe you could use the issue tracker? Once a bug is reported, it appears in our issue tracker.
Here is an example of a fixed issue in the issue tracker. If you see that it is missing some information, you can still ask the devs to fill out some information in the tracked issue.

The idea would be that thanks to the issue tracker, you would be able to give one single URL to the devs you're in contact with, and they would be able to follow this exact bug.


Last edited by Creak on 6 March 2018 at 2:42 pm UTC