So I've been doing lots of reading up on Unity & tutorials to get a grip on how it works. I felt like rambling about a few thoughts and observations about Unity in the process of doing this, so here goes.

When a pixel isn't a pixel

Although I've worked in a 3D pipeline, my skillset is 2D art. If I'm making a game, it's going to use 2D art. Here's the thing - let's throw a texture into a default Unity setup for a 2D. Texture:

Here it's dropped into Unity - an admirably simple process! - and I hit "go".

I've taken a screenshot and put it into Photoshop to show that the texture now appears to be 360x360 rather than 512x512.

And oh man does the simple fact that a pixel isn't a pixel by default ever drive me crazy. After some calm breathing and doing a bit of reading, I did figure it out. Given context, what is going on here makes sense: Unity was built from the ground-up as a 3D engine, its underlying assumptions work on those principles. The game is based on arbitrary units of measurement, let's call them Unity Units or UU. You must set the number of UUs to a measure of half your vertical screenspace. So by default it's something like this:

That's a "Size" setting of 5 on the default orthographic camera which sets the vertical distance from center to edge to 5uu. I'm assuming here that the screen is of 16:9 ratio, the most common desktop monitor ratio. I cannot assume that this will be 1920x1080 like my monitor and that most used for PC gaming. Maybe it'll be 1366x768 -- super common -- who knows!

What's a 2D game-maker who wants control of pixels to do? First: come up with a standard pixels-per-uu when importing art. Second, set your camera size up so that one pixel is one pixel. Third, you're going to have to write a script that changes your camera size setting based on what resolution the game is initialized with. Thankfully like a million people have solved this problem already and solutions are easily discovered via search. Plus any artist worth their pixels should know the theory required to make this happen anyway, so it's a worthwhile cause.

There's also a question of figuring out what you want the game to do when it hits an unexpected width:height ratio. You may end up shows more or less of the gameplay area than intended...

Anyway that was fun.

(Aside, I was discussing the animation system with my former animator. He observed that it's pretty clearly a 3D animation system being adapted to handle 2D animations. Just so with everything here!)

Edit: A 2D game can of course be made without 1:1 pixel ratio between art and display. (It just bothers me.)

Tutorials

I've been doing tutorials! Not only for Unity, but for C#. Much of my experience has been with pretty free-wheeling languages like Python and Lua so it's educational to move to C#. Anyway, been doing pretty well with that, now working more on applying it via Unity.

I appreciate what a pain it is to keep tutorials up-to-date with the latest version of the engine. It's also an unfortunate experience to be doing a tutorial and discovering that something isn't working as intended due to version differences. On the upside, you can usually count on lots of other people running into such problems and complaining about it online, sometimes with constructive results.

The official 2D roguelike tutorial was particularly applicable to the 'learning project' I'm planning to undertake (more on that in another post - it's not a roguelike!). It feels .. overwrought? to use raycasting and rigid body colliders to do collision detection in a simple step-based 2D grid world game, but I think the point is to demonstrate working with Unity's built-in components.

Few more thoughts

Following up on that, wow does Unity come with a lot of neat stuff! It makes it deceptively easy, perhaps, to make a shooter or platformer (with physics and all that fun!). And a bit harder to make the sort of thing I tend to be interested in. I should emphasize that this isn't meant as a disparaging comment; it's a great toolset. Just that there is a clear path of least resistance. Still, even the path of greater resistance in Unity is a heck of a lot easier than the easiest of some of the alternatives I've used.

In particular, I love the UI system. It's so liberating compared to my experience coding my own from scratch and using a very limited custom system in the last few years. I'm finding it easier to dump debug info to an output on the screen than using the debug console output (which I concede contains vastly more information than the string logged).

I'm excited to carry on with this. The learning project is proceeding apace, but I'll leave it with "don't hype until you've got a working prototype".