Opinion: New EU ruling forcing Steam & co. to allow re-sale, may be bad for games market

What happened?

The EU has just recently ruled that Steam and other, similar distributors, including console vendor’s online shops, must allow players to re-sell games they bought and played on the platform. Since this is a topic that I have spent some time thinking about, and all of a sudden it became relevant, here are my thoughts.

I must preface this by stating the obvious: I am biased - I am a game developer myself and hope to sell my game Puzzle Pelago and more in the future - on Steam. So with that out of the way, let’s go!

The Difference Between Physical and Digital Goods

Upon months ago seeing people complain in comments sections that they can’t re-sell Steam games (or on other platforms), because they used to be allowed to do that with physical copies, I started wondering why I felt that those cannot at all be compared, as so many other stated.

The main reason is, of course, that physical goods and digital goods are fundamentally different. Physical goods

  • Take up space

  • Degrade over time

  • Must be physically shipped

All of those factors mean that there is a limit to the efficiency with how you can re-sell a used game. The degrading means I can no longer take full price, the taking up of space means I cannot own an infinite number of them without paying for storage somehow, and the cost of logistics means that exchanging the game will always cost me - whether somebody travel to me to pick it up, or I send it via mail. This is likely also the reason the games market was OK despite re-sale of physical copies. Lots of people just want the new thing, even if it costs a little more.

For digital goods, none of this applies! If allowed, we could exchange goods

  • At no storage cost at all

  • With no degradation at all

  • By transferring them across the globe in microseconds.

In addition, most games, like movies, and much more even than music, are consumption goods. When you are done with the game, you are most likely done with the game for good. It’s a bit like cake. Except you should never ever re-sell a cake after you have eaten it - please!

What Does This Mean?

Who knows? Such matters are hard to predict because it all comes down how the new legal requirements of “re-selling" are enforced and what remedies are implemented. So, let us consider one possible scenario, in which Steam and co must offer a services, where for example Steam lets you generate a game-key, in exchange for no longer being able to play said game - you now own the key, which you can re-sell, and somebody else can activate to own the game and play it.

What stops people then from setting up a P2P licence exchange? Just like Napster did for music back in the day, but without shitty ISDN connections, and you only had to transfer a short code - and it was all legal! “Offering Dark Souls 2, looking for Assassin’s Creed 3”

Within the framework of such a system, users could exchange games, with nobody paying each other, because why would they? The used goods are indistinguishable from the new thing, and if players are not using the old, used games any more… Lets all trade!

And just like this, we could see publishers and developers cut out of a big chunk of revenue. If we are being pessimistic (yeah yeah, I might be), this chunk could even be so large that developers and publishers, as well as the platforms themselves, will have to rethink how they monetise. Because if selling games does not yield enough revenue anymore, what will?

  • Renting - it’s like buying the thing, for less, and not being allowed to keep it.

  • Free-2-Play - most PC gamers were happy that F2P was not as dominant on their market as it is on mobile.

  • Subscriptions - like Spotify, or Apple Arcade. Could be an option, but is disadvantageous for smaller developers who did not get into one of those, and we do not yet know how much revenue this can yield.

Thinking as a consumer, I don’t like any of these options over just simply owning the game. Renting may turn me off from enjoying games for an extended period because it gets more expensive over time. I have unfortunately not encountered too many F2P games that I enjoyed, because mostly I feel like I’m doing chores for the publisher rather than playing a game. And for subscriptions, I really don’t know. This could work, in theory, and will come down to - again - how its implemented, how developers get paid, etc.

Of course, one can argue that a lot of people will know about the problems and buy the game still, to support developers. But while that’s nice, most people won’t.

So let us hope that this is not at all what is going to happen, that I am totally off with my predictions, and what was I thinking LOL!?!? Or that the ruling will be changed, or successfully challenged.

Let me know what you think this means below in the comments!

Adding an iPhone X/XS/XR Screen Layout / Safe Zones Overlay in the Unity Editor

UPDATE: I just found a Unity asset that seems to make this blog post redundant for anyone on the Unity with .net > 3.5, and like a much better solution. Check it out Notch Solution! For anyone stuck with an older version, this post could still be helpful.

Original Post:

Today’s post is a quickie and more of a resource than the usual tutorials!

For anyone building a Unity game for iPhone, I made a semi-transparent overlay version of the iPhone X/XS/XR screen layout that shows exactly where the camera notch is, and the safe zones for UI elements and anything else on screen.

It is based on Apples SVG Version from their Human Interface Guidelines, but optimised such that you can just drop a PNG into your scene.

… a lot to do here!

… a lot to do here!

Using the iPhone X Save-Zones Overlay in Unity

Screenshot 2019-02-08 at 08.43.37.png
Screenshot 2019-02-08 at 08.46.05.png
  1. Download the picture below and drop it into your Assets folder. On the new asset, change Texture Type to “Sprite (2D and UI)”, and make sure that “Alpha is Transparency” is checked.

  2. Create a new Canvas in the scene with your UI/game and give it the “EditorOnly” tag so you don’t accidentally ship it with your build. I called it “Screen Overlay”. Leave the Render Mode as “Screen Space - Overlay” and the UI Scale Mode as “Constant Pixel Size”

  3. Set your Game viewport to either iPhone X Portrait or iPhone X Landscape. If those don’t exist, you can add them - the resolutions for iPhone X are 1125 x 2436 and 2436 x 1125, respectively.

  4. Add a new UI>Image on this new canvas, call the new Game Object “Portrait”, and on the image component click “Set Native Size” - This should Scale the image correctly to match the Game View’s size. Make sure to center it, e.g. by setting the anchor to “Middle Center” and setting X/Y of the image to 0.

  5. Duplicate the “Portrait” object, rename it to “Landscape”, and set the RectTransform’s rotation to Z=90. Switch your Game View to “iPhone X Landscape”. The overlay should fit as-is.

  6. If you want to be able to see the layout at any time during play mode etc., set the new canvas’ Sort Order to something high, like 200!

Screenshot 2019-02-08 at 08.46.15.png
Whoops! My current layout does not respect the safe zones at all, and even overlaps with the home bar at the bottom!

Whoops! My current layout does not respect the safe zones at all, and even overlaps with the home bar at the bottom!


Unity Layout Groups Explained

Are you confused about Unity’s Layout Groups? Specifically the mysterious “Child Controls Size” checkboxes? Then this article is for you! 

TL;DR: Unity’s Auto Layout system is confusing because it uses parameters to compute its layout that by default are hidden and can only be overridden by manually adding the “Layout Element” component to child ui elements. Also, Flexible Width/Height are not measured in units, but as ratio weights, and are applied on the unused space that is remaining after all preferred/min heights have been subtracted.


Working with Layout Groups in Unity, upon first (or second or third) encounter can be confusing, even frustrating at times. This is even stranger due to the fact that the rest of Unity’s UI system is very easy to use and understand. And since for Puzzle Pelago, I needed to be able to support various aspect ratios and orientations, I had to understand this system in detail. Systematically looking at isolated fields and Checkboxes, and reading the official documentation on this multiple times, I think I unwound my knot, and hopefully yours, too!

If you only care about the highly condensed learnings, just look for the “What we learn” sections.

In what follows, I will do a step by step exploration of Unity’s Vertical Layout Groups. Horizontal Layout Groups work analogously and are omitted here for brevity.


To start out, let’s create a new scene in any Unity project, and set the game view’s resolution to a custom 300x400 resolution. This will make it easier later to see how unity calculates layouts. Once this is set up, we can add a new Canvas, and to that Canvas, add a “Vertical Layout Group” component Lets also set both checkmarks for the Width-aspect of the layout. We are only focusing on the vertical aspects here, and so we will initially uncheck both Height-related checkmarks.

Now add three UI images into that canvas, and change only their colors to be able to tell them apart. I chose white, green and red.

Add new resolution
custom res
canvas settings

This is what the scene now looks like:

Screenshot 2018-10-16 at 11.42.15.png

The images have been stretched to width 300 to fit the whole canvas, since “Force Expand” is enabled for width. The height for each image is exactly 100, since that is the default height for images, and due to both checkmarks unchecked in the layout group for height, this was left untouched. 

Screenshot 2018-10-16 at 11.42.22.png


With this basic setup, lets go and try out some things.

  1. In the Vertical Layout Group on the Canvas, tick “Child Controls Size” for Height. 

    • All three images are gone now! What the hell?? (Explanation on that later)

    • I would have expected, since the checkbox says “Child Controls Size”, that the height value would remain as is. But nope. Child Controls Size => height=0. Hmmmm.

    • If you try and change the image’s height, you can’t! The controls are disabled. Very confusing! I thought the child controls its own size?

  2. Tick “Child Force Expand” for Height.

    • The images are back and now fill out the whole canvas. Makes more sense.

  3. Untick “Child Controls Size” for Height.

    • Nothing changes, really. 

    • But, now we can go into the images and manually control their height again. At least something!

  4. Re-tick “Child Controls Size” for Height.

    • Back to full screen usage.

What we learn

  • Setting “Controls Size” without “Force Expand” leads to height = 0

  • As explained in the docs, this is because the default preferred, minimal and flexible heights are all 0.

  • So what this means is that “Child Controls Size” actually means that hidden, by default implicit layout parameters of the child “Control Size” of the layout elements, and not the explicit height values! Since these hidden, default values are all 0, our images vanished once we let them control their height.

Now let’s say we want a fixed (i.e. “preferred”) height of 100 for the top header row, and below that, two flexible height containers, of which the first one is twice as large as the bottom one. 

  • For each image, in order, add a “Layout Element” Component, which allows us to override the default Auto Layout behaviours / measurements

  • For the first one, tick “Preferred Height” and enter 100

  • For the second and third one, tick “Flexible Height"

    • For the first one, enter 2

    • For the second one enter 1

  • Make sure that on the Canvas’ Layout Group, “Force Expand” is off for height, such that only “Child Controls Size” is on.

Screenshot 2018-10-16 at 11.51.22.png
Screenshot 2018-10-16 at 12.47.51.png

What we learn

  • Flexible Height parameters are not actually units, but weight values, of which ratios between the layout elements will be calculated to automatically calculate their relative use of space.

  • Since by default, Flexible height for the 1st image is 0, and the preferred size is set at 100, it means that the remaining space will be divided between the second and third element at 2:1 ratio!

  • From the docs: "If there is additional available space, flexible size is allocated."

Ok. But now, just out of curiosity. What happens if for the top image, we also tick “Flexible Height” and set its value to 1? I would expect that now the element height ratios are 1:2:1, i.e. the top element takes up exactly 100 units since it’s share of the height is 1/4*400 units, which is both its preferred and its flexible height.

But Nope! The height becomes 175. The math here seems to be as follows:

  • Top: 100 units preferred, leaves 300 units below empty; + weight of 1 to take from empty space (300/4 = 75; 100+75 = 175 observed height)

  • Middle: weight of 2, i.e. 300/2 = 150 (as expected)

  • Bottom: weight of 1, i.e. 300/5 = 75 (as expected)

Screenshot 2018-10-16 at 12.50.56.png

What we learn

  • The “flexible height” ratios apply after the min/preferred heights have been subtracted, if they are set, i.e. absolute and relative heights are additive!

So, lets have a look at our layout with the iPhone 5 16:9 resolutions in both portrait (i.e. 9:16) and landscape. We can switch between both screen orientation to check how our layout looks in both.

Lets say we want to use the bottom red portion for next / back buttons. In portrait, it could be convenient to expand this to have a size about 2x the header (i.e. 200 units). This gives the buttons some room to breathe and should be reachable more easily than cramming them in the bottom 100 units.

If we solve this by setting the Min Height to 200, this will look horrible when going to landscape orientation, since in landscape, 200 is way too much!

Turns out, what we want to do here is set the min height to 100, which is a value that looks good in landscape mode as well, and then also use the flexible height value of 1.

In addition, we must now tell the middle part to use flexible height, with a large value, like 8, to get it expand more than the bottom part.

By using both flexible and min height, we get to ensure a minimum height, but also have control over how the ratios between heights change in different aspect ratios.

Screenshot 2018-10-16 at 13.02.39.png
Screenshot 2018-10-16 at 13.02.24.png

It is a bit frustrating that we cannot use the flexible and min height together to create a region that e.g. uses 25% of the available height, but is also at minimum 100 units high. But alas we will have to use workarounds like the above.


I hope this has helped resolve confusion about AutoLayout and (Vertical) Layout Groups in Unity’s UI system a little bit. If there are more questions, please don’t hesitate to contact me via twitter @hallgrimgames or in the comments section below.