I had two very specific ideas for the menus in my game. First, I wanted everything to be set up like the player was looking at a computer screen. The different buttons would act like shortcuts to launch the next screen, which would grow out of them and expand to fill the whole area. Similarly, going back would cause the current menu to shrink back to its origin as the previous one became visible again. My second idea was to start with all the button text in something other than English, which would flicker a few times and then come back readable. Both of these effects would serve to lean into the alien theme, and the easiest way to accomplish them was to use animations.
But before I get into the complexities of that (which will take an entire post of its own), I wanted to talk about setting up the assets first. Unity is often very highly praised for its ability to allow development of code and assets simultaneously, then link them together in the editor. I can use as much placeholder stuff as I want while I'm designing the game and testing it, then I can swap in the real thing as soon as the artists are finished with it. Now, this is fantastic in theory, but in practice I've seen enough things go wrong that I know what I need to watch out for in that workflow: things like unexpected resizing, collider positioning errors, and anything that relies on hardcoded values for positioning or speed. Some of this can be mitigated by having explicit rules for setting up your hierarchy, but the point I'm making here is that for once, I have the ability to ensure the art is done before the coding starts...because I'm doing all of it myself.
I started with some mock-ups in Photoshop. I knew I wanted a dark screen background, which also meant dark buttons to make the expansion effect work. But then I needed a way to make said buttons stand out from the background, so I added a lighter "panel" object to hold them all. I kept with the heavy border motif that my UFOs share. The last thing I needed was some way to indicate that the buttons were selected - selected as in "hovered over", not as in "clicked". This can be confusing, especially since I'm making a dual-stick game, so there is no concept of mouse hovering...maybe "highlighted" is a better word. There are a lot of different ways to do this, and I've used many of them in previous projects. Usually, the highlight is accomplished by either using a color tint or a full-out sprite swap, and one of the differences between the two methods is how your normal buttons are set up. For instance, you could either have a generic, blank button asset with all text added in Unity, or bring in each button individually with text as part of its sprite. It's really a toss-up; blank buttons are maybe better for coders, because if they need to make changes, they don't need to bother the artists to create a whole new one. But I've also run into problems with text scaling and clarity when it's a separate thing. Sprite swap allows for more effects more easily, like italicizing or scaling the text as part of the "highlight", but it also means the number of button assets needed for your project goes up exponentially. I got hit with that hard here, because my translating effect meant I needed several different versions of each button already. To handle the highlight, I used a clever trick with transparency in Photoshop. I applied a mask to the different text layers to make them "cut-out" the button below them. This means that normally, you'll see through to the panel. When in the highlighted state, I turn on a second sprite, a white glow effect, which not only appears around the edge of the button but behind it as well, so that now that's what you see through the letters. Take a look:
So the act of highlighting a button just turns on the glow effect, which appears to change the text color as well. Pretty cool, huh?
The next biggest hurdle was picking a font. You may not realize it (because I didn't), but fonts are just as restricted and copyrighted as anything else: you can't use them in your commercial games without owning the right license for them. This means that as you're searching one of the dozens of "free font" websites, you need to look for phrases like "free for commercial use"...but even that isn't foolproof. I read that the Adobe fonts have all been cleared - it says so right when you launch their website - but if you go read the fine print, this doesn't include use in "applications". I was lucky to find fonts protected by OFL licenses for my main and alien variants. OFL truly does mean "free for anything", including modification...and that's good, because I didn't like the number "1", and after trying a few things, I decided that the best option would be to literally change the font itself. There are plenty of tools out there to do this. I went with Glyphr Studio because it was online, free, and allowed me to upload a font file to start with. I only wanted to make the one small change, and I can't imagine how hard it would be to create a font from scratch, especially with kerning and other settings that would drive a perfectionist like me crazy.
To wrap this entry up, I wanted to mention another integral part of the menu: the legend, a.k.a. how you control it. For S.P.A.R.K., we went through the hell of determining whether the connected dual-stick controller was X-BOX or PS (completely ignoring generic, because we had no way to do anything with that), and after doing so, I came up with the idea to use generic graphics for Trials of the Rift. It was an easy and clean solution, so I reproduced it here.
Next time: the player select menus.