I’ve been talking a lot about less technical stuff recently. Let’s mix it up – today, I’m gonna talk all about the design and implementation of an important part of our game. If you couldn’t guess from the title, today we’re gonna talk about menus!

Design

Menus are a pretty important part of your game. Most people make a game and then just “slap” a menu down on top of it. Since the menu is the first thing users will see, it can be pretty make-or-break, so it seems like poor form to spend the least amount of time on it! That’s why it’s so important to actually put some thought into your menu design.

Early on, Frank and I decided that we wanted to have as little text in Where Shadows Slumber as possible. There were a number of reasons for this, the most obvious being:

• We have to do less work to translate the game into other languages
• It adds to the “mysterious” vibe we’ve been going for
• The user isn’t burdened with a bunch of text they have to read
• The text-based menus were possibly the worst part of SkyRunner (our previous game)

To go along with this choice, we also aimed to make the menus as transient as possible – rather than opening to a menu, where the player must choose to start playing, the game itself would just start playing immediately. That’s what the user is here for, after all! This “game-focused” menu model is an attempt to reduce the user’s barrier to entry, making it as easy as possible to actually start playing the game.

So what does that look like? Our menu design breaks down into four small parts:

1. The first thing the user will see is the splash screen. This is just a quick little screen that shows the Where Shadows Slumber logo. It’s not really a menu, since it doesn’t do anything, but it’s worth mentioning (and it’s important for implementation purposes).
2. Before starting a level, the user is met with a level title card. This tells the user what level they’re on, which provides important context, as it’s the only menu interaction they’ll have before they get to the game itself. After tapping through this menu, the user is dropped right into the game.
3. During the game, the user can press the pause button, which will bring them to the pause menu. This is where most of the interaction is – you can restart the level, mess with the settings, etc. In order to move from “menu-focused” to “game-focused”, we’ve moved everything you would see in a “main menu” into the pause menu.
4. The only exception to the “game-focused” menu design is our level select menu. Coming here will actually take you out of the game – but for good reason. This menu is by far the most complex, as the user can choose from any of our levels or cutscenes.

After textlessness and transience, a big driving force behind our menu design was incorporating game elements. For example, a quick description of our game’s mechanics might read like “things change when they’re in shadow”. So, wherever possible, we wanted to have a menu where things changed in shadow. The only place where we had the freedom to do something like this was in the level select menu. We thought about it a bit, and ended up with this beauty:

This idea came up after about a million attempts at a menu design that showed off our mechanics a bit, but I think it was worth it. It’s pretty subtle, and uses a relatively standard swiping interaction.

Implementation

For those of you looking to make your own games, or just curious what our process was, lets take a look at how we actually brought these menus to life.

This is an area of development that really benefited from our three-phase process, in which we made a demo version of the game, and then started over when we began on the full game. This allowed us to iterate on our first approach to implementing the menus, without having to go through and update the existing menus. There are three interesting things that we did to create these menus.

Splash Screen and Pause Menu

In the demo version of the game, we created a pause menu prefab, and made an instance of it in each level. That way, we could update the prefab, and it would apply to every level. Seems pretty cool, right?

While this is a pretty good pattern, and we’ve used it for a lot of other things, it didn’t really work for menus. The biggest reason for this was that we found ourselves going through every single level to update the individual menu objects with small, level-specific changes. While this might work for the demo, which only had ten levels, it’s a lot more work for the final game, which will have 38 levels.

Rather than have a menu object in each level, we decided to have a single menu object that persists throughout the entire game. After all, the menus themselves don’t change much from level to level. This is where the splash screen comes in – when the game loads up, the first scene is always the splash screen. This scene has the single menu object, and we simply tell Unity to allow it to persist from scene to scene (using DontDestroyOnLoad()). Any changes that need to be made to the overall menu text are made per level, as the level is loaded.

Level Title Cards and Translation

One part of the menu system that often gets overlooked during design is translation. For example, we decided to provide different languages for the demo, but we didn’t consider it or add it in until close to the release. This left us with a half-hearted translation system that was hard to update.

The second time around, we decided to think about translation from the beginning of menu implementation, and we were determined to come up with something easy to work with. What we realized was that, for a foreign language, all text should be loaded from somewhere else – why should English be any different? Instead of creating an English menu and then applying translations, we started with an “empty” menu, and used our translation system to populate it with whatever language we wanted, English included! This forced us to take translation into account much earlier – so we can be much more sure that our translation system will work nicely with our menus.

But what does that translation system look like? Pretty much all of our other scripts are given values through the Unity editor. We did this for translation as well in the demo, and it was a complete disaster – even with our low-text menus, there was still a lot to add! We realized pretty quickly that we didn’t want to include the translations as part of the Unity scenes – we decided to have them loaded in separately, using JSON.

JSON, or JavaScript Object Notation, is a pretty cool file format used to organize values into a set structure. By storing all of our menu text (and translations of that text) in a JSON file, we can pretty easily read it into the game as it’s loading, thus allowing us to populate menu text objects with the correct language. It’s easy to read, easy to backup, and easy to update (unlike the Unity editor script fields), which makes it perfectly suited to this type of use-case.

The end process is pretty simple – when the game loads, parse the JSON file (which has all of the game’s text in “every” language). During the splash screen, where the menus are created, populate their text fields with the correct text from the JSON file. If we need to update the text, it’s as simple as changing the text in the JSON file, and everything just works!

The Level Select Menu

While the other subsections here describe ways that we learned from a bad implementation to make a good one, the level select menu is just a cool menu design.

Whille toying with menu ideas, Frank created a few of these “world tableaus”, and we knew that we wanted to have them in the level select menu. The coolest thing about them is that they aren’t just textures – they’re 3D scenes, which allows us to give them subtle movement (this kind of effect really helps make a game look “polished”). The question becomes – how can we display these scenes in such a way that they can interact with each other in two dimensions, while acting as completely separate scenes?

Unity has a pretty awesome feature called a RenderTexture, which allows a texture to display the live view of a Camera object (for the curious among you, that’s how you could make a CCTV screen or a mirror in a Unity game). Using a RenderTexture basically allows us to “flatten” the moving tableau scene into a moving texture, which we can then manipulate as we please. And, as it turns out, it pleases us to use math and angles to create the “sweeping shadow” effect.

You see, I’m a pretty big fan of math on the whole, and this was a perfect place to apply some trigonometry. Using complicated concepts (like “sinusoidal”, and “minus”), I came up with an algorithm that  would put two RenderTextures and a shadow triangle together in such a way that it created the desired effect:

What you’re seeing here is that each RenderTexture is angled (and stretched appropriately), and then positioned in such a way that the line where they cross is exactly covered by the moving shadow. This gives the illusion of the menu behind the shadow magically changing from one image to the other.

This menu is my favorite part of the menu system, because it’s the most interesting, both from a technical, implementation perspective, and from an outside, aesthetic perspective. That said, I think we ended up with a pretty sweet menu system all around, thanks in no small part to our past failures in this area.

Looking Ahead

Unfortunately, no part of the game is ever really done. The menus are in pretty good shape, but there’s still some polish we need to do, and I’m sure there will be small changes we want to make as we move forward. In fact, this was one of the more important concepts behind a lot of our decisions – any changes we want to make should be pretty easy!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Hopefully you enjoyed this peek at the menus for Where Shadows Slumber! If you have any questions about our menus, or if you have any other questions about Where Shadows Slumber, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.