Time has come to make sprites for UI. This involved me opening Photoshop and emerging 3 days later with a couple barely passable sprites. Anyway, here are all the sprites I will use (for now) in the primary UI elements:

The leftmost is a panel or button. Second one is a tab. Third and fourth are generic containers when I need to “group” or select elements. I will likely need more, but these are versatile enough for like 90% of cases. I can also always update UI with new sprites as they will share the same layout.

(For the sake of blogging sanity, I didn’t actually make them in this order or with those variations to begin with. I did some experiments and added new variants and types as I added features. But I am just leaving one preview here.)

As with everything, I want to be able to quickly adjust things. This includes my “art”. That means all the repeated graphics are Photoshop’s smart objects, which just means I am working with prefab-like logic.

Different variations are just adjustment layers, like brightness or hue:

The objects themselves are outlines of the desired shape with whatever effects I want, like linear vertical gradient:

And the cutouts are a mask that just “removes” that area:

In short, I can modify every part of the design. This is a very “programmer” approach to all of this, but it makes my changes fast. I can change the color or gradient direction or border thickness with a few quick edits.

In Unity, these get 9-sliced, so that they can resize nicely to any size and I don’t need to worry about them.

Now, before I can actually use these in-game, I have to make a serious UI decision about the UI canvas size I am using. The game is pixel art and my HUD is already 2×2 pixels for each pixel, so to speak. I mean it’s all 200% zoomed at the moment. So I might as well make that the default canvas size instead of manually drawing all items at 200%. This comes from my legacy canvas logic, where everything was 1:1.

First, I will set my reference resolution to 640×360, which is half the 1280×720 (my native one):

And then I need to make the canvas be rendered by a camera specifically for this size/resolution:

And that sort of works. Except all my sprites are double the size they ought to be. And I have so many of them (just the minimap is dozens) that I rather not rename them by hand. In fact, I made an editor tool for this:

I just drop my texture (atlas) and it will convert all sprite to be half the size. Super-easy and fast. (If you ignore the time to make it.)

Now I “just” have to fix every single panel. I will talk about modularity of my UI in the next post. For now, I will just show where I am heading with these and how they even look as a proof of concept.

Here’s the main menu:

Yeah, the screenshots are huge and I am not resizing them because they are at their native resolution that way and not resampled where they lose the sharpness.

Here are some tabs:

For instance, this is player’s info panel. It now has a specific “container” where the child panels go. So something like goal panel will then need to fit within it with all its elements:

Then I can start replacing each element with its appropriate sprites:

For example, the confirmation panel:

Or the loadout panel:

The work’s very slow and tedious. It’s visual, but it’s also sprites done by myself, so it’s hardly amazing. The time I spend moving and anchoring and shifting UI elements really adds up. But I’m slowly working through all the panels.

MicroRogue DevDiary #81 – UI Sprites
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *