Coming soon : 1-Bit Hero




1-Bit Hero is a platform game with retro graphics. Very. Retro. Graphics. The game is pretty difficult, but that also makes it very rewarding. Almost done, should be released soon.

screen1 screen2

Physics outside of FixedUpdate

Unity’s physics are great. We get to chose between Physx (for 3D) and Box2D (for 2D), and they are integrated quite well.

However, real-world physics are not always what you want for games. For instance, making a platform game with Unity’s physics can be quite a challenge (but not impossible off course). You’ll most likely run into problems when dealing with slopes and moving platforms, among other things. Maybe even objects falling through other objects.

Here’s a good article on the subject :

Another problem you may run into is if you manually want to move an interpolated rigidbody around. In a game I did for a client some years ago (which is no longer available), the character needed to walk and jump around a tube (think old school Nebulus). I tried with constraints and joints, but it never worked right, so I had to move the character manually.
The problem with this is that if you do it in the FixedUpdate cycle, the interpolation will stop working, which can cause camera jitter. And the docs say “you have to do physics stuff during FixedUpdate”…

I’d like to bust that myth, that you should put all your physics code in FixedUpdate, and not in Update. Sure, that’s the best idea if you want physical reactions and forces, otherwise you’ll run into a lot of problems. But if you want to use the physics engine for just collision detection, that’s fine. So it’s perfectly safe to move your objects around in Update (make sure you make your code time-independent though), and use RayCasts (or even OnTriggerEnter) etc to detect collisions. I do it all the time, and so far haven’t run into any problems with it. Often it’s a far easier solution than trying to make it work with the physics engine(s).

BTW, I’ve so far made two platform game engines in Unity, and will be sharing my knowledge on the subject in future posts.

Creating resolution-independent 2D games

Creating a 2D game or UI that works across multiple devices can be a bit tricky. There are many approaches to this problem. I have a pretty neat one for y’all. It’s quite flexible and is pretty much a drop-in solution. But first, let me give a bit of background information. The solution only takes about a minute to set up, but I want to make sure you understand how to set it up.

Note : This article talks a lot about mobile, but the solution works for other platforms too.

Note 2 : This is focused on Unity. The same principles could be useful to other environments, but the code will obviously need to be changed.

As many of you probably already know – and if you don’t, hey, you’re already learning! – in Unity, to get a one pixel to one unit mapping, you set the camera to orthographic and set the orthographic size to half the screen’s height. Basically the orthographic size setting is how much of the scene your camera will show (divided by two – not sure why).

Back in the good old days, there was only one mobile device that mattered. Well, multiple devices, but only one screen size : 480×320 (or 320×480 off course). So to set things up so that one unit meant one pixel, you set the orthographic size to 160 or 240. Or, you could be a little smarter about it, and you could set it to Screen.height / 2. Off course not everybody wanted a 1 unit to 1 pixel mapping, you could divide / multiply that number any way you wanted, but let’s just stick with that for simplicity’s sake.

But as it turned out, that wasn’t so smart at all. What happened? iPads happened. Retina displays happened. Let’s just take a retina display iPhone screen as an example. If you set the orthographic size to half the screen size – ie in this case 320 or 480, one Unity unit now became a very small retina pixel on the screen, and the camera was now displaying a lot more of the game scene. You actually wanted the same orthographic size as the non-retina screens. So what I used to do – and I’m willing to bet a lot of other people as well – is hack in some conditions. If the screen is larger than a certain size, instead of dividing the screen height by 2, you divide it by 4. But off course, you had to take iPad retina into account as well. Blimey.

Well, that was not too bad actually, quite manageable. But then there’s also Android with it’s plethora of screen sizes. And now there’s an iPhone 6 and an iPhone6+ too. Needless to say, this solution doesn’t really cut it.

So what now?

Before I go into my solution, let me say that in many cases, you could just have a static orthosize. This would mean that the same amount of units are drawn vertically on any screen, and the horizontal part will vary. But sometimes you may wish to “lock” it in the horizontal direction, and let it vary vertically. Luckily all you need for this is some basic math. But what if you don’t want your graphics to be scaled too much? What if you want to achieve pixel perfectness (off course divided by two on some screens etc)? This is where my solution comes into play.

The way it works is this. You basically give it a minimum visible area and a maximum visible area, and the code will figure out an optimal orthographic size between those bounds. Obviously it may not always be possible to find a fit, so it’s good to have enough margin. Let me explain.

Note: I talk about iOS screen sizes a lot, but the same principles apply to Android. This is just to illustrate.

I personally like to work at “iPad retina” scales. So if we only do landscape, that would be a 2048×1536 area (shown here at 1/4th size).



Now let’s use the iPhone’s size as the minimum area. So that’s either 960×640 or 480×320 – but let’s supersize that to 1920×1280 and put it in our beautiful image.

But what about iPhone5(s)? Those devices have a 1136×640 resolution. Supersized x2, that would be 2272×1280. Our image is too small! So let’s resize it so it’s 2272×1536, and add borders for all the screens sizes.


Green is iPhone4, yellow is iPhone5, and red is iPad. The idea now is to find an orhtographic size (for any screen) that fits within the image, and that keeps the entire green part visible, and it should preferably be as pixel-perfect as possible.

All graphics should be designed while keeping in mind that the parts outside of the green border could get cut off. Off course things could still be anchored to the corners.

So we know that our minimum area is 1920×1280 (the green box), and the maximum area is 2272×1536. If we want to support both landscape and portrait, it will look like this :


So now our maximum area is 2272×2272, and our minimum area is 1280×1280. You can off course add some margins to it if you want to support screens with even bigger resolutions. You don’t have to use these numbers at all, but just decide on a minimum and a maximum size that work for your situation.

Now what you do is you add the code at the end of this post to a GameObject (possibly the camera), and enter the minimum and maximum areas. You can enter different areas for landscape and portrait, or enter just one of them if you only need one orientation. The script has a cameras array, in which you drop the cameras you which to affect. So it can work for multiple cameras, or you can have multiple instances of the script for different cameras that need to show different things.

So all you do is set up you areas and tell it which cameras to affect, and the script does the rest. It even shows some boxes in your game scene for reference.

Note: The area sizes can’t have decimals, so use integer values. However, since Unity’s default mapping for sprites is 1 unit = 100 pixels, you most likely will want to divide your area by 100. That’s why there’s a scale property. Just set it to 0.01 and presto.

In cases where you want to always show the same amount horizontally (for instance, if you have a couple of lanes on the screen and don’t want to show more or less than that), you can just set the minimum and maximum width to the same value, and set the min and max heights to extreme values.


And here’s the code

First, let me say that it works well, but it uses a bit of brute force because I couldn’t figure out a more elegant algorithm, but the brute force is really limited, and it only does it at the start and when changing orientation, and you won’t be able to notice it. Still, if anyone feels inclined to optimize it or clean it up, be my guest!

In a follow-up post I will share my solution for anchoring GameObjects to the sides or corners of the screen, which can be used together with this code (or separately).

I am the walrus.

I’m not really a walrus (at least not as far as I know), but what better way to start my new blog than with a line from a Beatles song?

Maybe I’ll make a game about a walrus at one point. Who knows.