Lisa's Menu- I mean- Dev Blog

When I joined Massive Shrimp Games, I was interested in expanding on the aesthetics for the game. I had been thinking of several games and real-life projects that had capitalized on the toybox aesthetic before, like Yoshi’s Crafted World and Toy Story Land, and wanted to try and bring some of their flourish into Ragball. The two main ideas I had to accomplish this in 10 weeks was post-process implementation, and a fully 3D menu for players to explore. I’ll briefly talk about post-process, and then move into the real meat-and-potatoes of the menus.

Step 0: Postprocess and the desire to make pretty thing

During the first few weeks, I wanted to try and implement a tilt shift shader on the camera, which is a photography technique where the top and bottom of an image are blurred to make the subjects of the photograph appear to be miniature toys. After stumbling my way through Unity’s documentation, I unearthed a free to use tilt shift shader, and Unity’s Post Processing package, which allowed artists to create PostProcess profiles (which could feature any number of effects) and apply them to their real-time rendering. After testing the two in combination, I was able to greatly enhance the perceived reality of our game scenes. Much later on in the process, I did this in Rag Of The Hill as well.

Part one: what if menu was real?

The source of my next task came out of hubris – now that I knew that the game scene could look visually realer, I wanted to try to make everything in the game seem diegetic.

Diegesis is, in short, the concept of things existing in the reality of the media. Diegetic things exist in the world, and non-diegetic things only exist for the audience – the camera in most movies, for example, is non-diegetic; it only exists for the audience. The same could, in my mind, be said of menus. I wanted to take Ragball’s menus away from the 2d, non-diegetic setup, and create a 3d environment a camera moved through to access the menu options, making it more like a real world the ragdolls could possibly run around in and interact with. I asked the programmers if this could be done, and was told:

“The menus all have to be separate scenes, because of the controller input system.”

After thinking for a while and doing some careful googling, I discovered that several Unity scenes could be loaded and unloaded at the same time, and that they could even be active at the same time. I devised a plan to create a loading-unloading system, with one main scene that held the geometry and camera. The menu scenes would be loaded and unloaded into specific spots of this scene. I created a greybox scene and several fake menus and prototyped it successfully, using a variable on the camera animator as a way to track which menu was currently active and loading the scenes accordingly. While I was worried that it wasn’t going to be seen as feasible at first, everyone else got on board when they saw the greybox, which I am incredibly thankful for.

After this, I started adding more and more models to the scene, and also added in the post-processing package.

Part Two: What If Menu Worked?

Eventually, I had to get this to work with the real game. I worked with Jake to rewrite much of the code I had set up for the menus to work best with Ragball’s menu system, swapping out additive load for enabling and disabling prefabs, and just generally making it function better. This also included creating a second camera that would solely render UI, so the UI elements wouldn’t get blurred by the post-processing system. Eventually, it WORKED! With the real menus! And we didn’t have to completely redo the real menu code for it to happen!

Part Three: What if menu was real, but more?

At this point, the menus themselves were still 2D, just in a 3D environment. The next goal for the menus was making all the elements the user was interacting with 3d! I handled the implementation of the models my other teammates created. I was most concerned with making sure that whatever strange contraption I made didn’t interfere with the real menus, which had to operate in specific ways to handle controller input (plus, they were scripted in ways my artist addled mind couldn’t comprehend.) The solution I came up with was creating a fake menu script that would read the values of the real menus, and update the fake menu (UI text and images planted on top of 3D objects) to match. It was a messy script, but it worked, and the menu finally leaped into (mostly) 3D!

Everything else that came after that was smaller polish – adding in more and more 3D models to replace 2D elements, adding in an animated cursor to show the user what part of the menu they were changing, drawing fun and silly images to represent different courts for the level select, and adjusting the position of everything for legibility. The final result is a nice-looking scene that also works as a great menu, and as an introduction to the setting and tone of the game ahead!

Conclusions

Without a team that was so willing to roll with my strange schemes, I wouldn't have even been able to get even close to creating this menu system. It certainly isn't revolutionary in its own right, but considering the little I knew of Unity before, I consider it a complete and noteworthy success, and a sign that some of my ideas might be good ones.

Take a look below of some of the progress shots of the post-processing and the menu: