I'm Mike Armbrust, the sole developer of VizionEck. Every week or so, I'll be posting about the game. Updates, technical details, peeks behind the scenes, design breakdowns, etc. For this week I'm revealing my horrible past attempts at making VizionEck's menus.
Leaving the camera free to rotate is crucial for VR so I tried to build the menu with that in mind. However I didn't embrace this "look mechanic" enough. The menu itself was still designed for a traditional static camera and couldn't be navigated by looking at elements. This resulted in a small workable area that needed large visible text. I had to choose words based off size, and even abbreviate at times.
Only a handful of information could fit on screen at a time, so most of the menu was comprised of buttons to deeper and deeper sub menus. Navigating was horribly slow and horribly confusing. I also laid out each sub menu physically so they could be visible by looking to the sides: you can see this as a glitch in the gif where the full array of sub menus is visible through the wall. This mechanic was done for appearance, with each sub menu fitting together like a puzzle piece. Later iterations of this menu had cool transitions with the sub menus sliding around, but the negatives far outweighed the positives.
Changing a single sub menu meant every other sub menu had to be rearranged and refit. It was super impractical for development and near impossible with my plans for free DLC. Every DLC release would need the entire menu to be reworked.
I also made a lot of technical mistakes. This was not just my first attempt at VizionEck's menu, but my first complex menu ever. Previous games I've worked on have only had simple menus with a handful of buttons. I hard coded everything in those menus, so that's what I tried to do here. The code became incredibly convoluted as I added more and more menu items, and every menu item was its own unique entity. Changes needed to be hand applied to every single one. Simply put, it was a mess I should have abandoned sooner.
In Feb 2015 I restarted the menu from scratch, this time focusing on the home menu instead of the pause menu.
I dropped camera rotation for non VR players, and I dropped the puzzle like nature of sub menus. They were still arranged physically but spread out as to not interfere with one another. Menu became much more "elegant" and could fit a lot of information on screen. The visual design is the one thing that this menu got right.
However it still failed to fix some crucial problems with the previous menu. I foo bared and completely forgot about a lot of very important things.
This menu supported longer words and text, but the menu was built around that exact text size. It was a single 3D model, text and all. For development it wasn't too bad editing the 3D file when text was changed, but down the road it meant every language would need its own full 3D model as well. It was also literally impossible to display custom text like a player's name seamlessly within the menu. Essentially I built more of a proof of concept than a realistic menu here.
Things worked out for the best though, because in March 2015 I needed to rebuild the menu for Unity 5 anyway.
I did a complete 180, going from static to procedural. The new menu only existed in code and was generated every time it was accessed in game. I created a custom menu class to define the menu's layout:
A generation algorithm parsed this like a hierarchy until it reached the specific menu being displayed, and then instantiated all the items and objects as listed. Text is not defined here, but rather in a separate language file. This way additional languages can be supported by simply adding additional language files, no menu changes required. I'm confident most games use a similar technique, but I couldn't find any tutorials online. Instead I discovered the method while doing website development.
It's such a great solution and I wish I discovered it sooner. Parameters can be passed with the text too, allowing player names to be seamlessly inserted. IE "welcome_back" in the menu class would be defined as "Welcome back {user_name}!" with "{user_name}" being parsed to the actual user's name. This is especially handy for different languages where the parameters might appear in different orders. It also works with numbers, IE "You have {number} minute{number_plural:s} remaining." If you're a menu novice like me and aren't already doing similar, I can't recommend this method enough. If you're not a menu novice, you're probably amused how happy I am over a standard technique.
Once again though, even this was still too static. Changes during development were fast and easy, but changes while playing were still hard. Just the other day I decided to touch up this menu again, hopefully for the last time. The text method I learned from web development worked so well that I decided to just flat out copy how most websites work. My fourth menu is just replicating PHP and HTML while using Unity 5's menu navigation system. Fast and easy to setup; no need to reinvent the wheel. Probably could have finished it in the time it took to write this article...
As always, feel free to ask any questions. I look forward to sharing another blog post with you in a couple weeks. Next week I'll probably be too busy playing The Witness.
(first menu)
Leaving the camera free to rotate is crucial for VR so I tried to build the menu with that in mind. However I didn't embrace this "look mechanic" enough. The menu itself was still designed for a traditional static camera and couldn't be navigated by looking at elements. This resulted in a small workable area that needed large visible text. I had to choose words based off size, and even abbreviate at times.
Only a handful of information could fit on screen at a time, so most of the menu was comprised of buttons to deeper and deeper sub menus. Navigating was horribly slow and horribly confusing. I also laid out each sub menu physically so they could be visible by looking to the sides: you can see this as a glitch in the gif where the full array of sub menus is visible through the wall. This mechanic was done for appearance, with each sub menu fitting together like a puzzle piece. Later iterations of this menu had cool transitions with the sub menus sliding around, but the negatives far outweighed the positives.
Changing a single sub menu meant every other sub menu had to be rearranged and refit. It was super impractical for development and near impossible with my plans for free DLC. Every DLC release would need the entire menu to be reworked.
I also made a lot of technical mistakes. This was not just my first attempt at VizionEck's menu, but my first complex menu ever. Previous games I've worked on have only had simple menus with a handful of buttons. I hard coded everything in those menus, so that's what I tried to do here. The code became incredibly convoluted as I added more and more menu items, and every menu item was its own unique entity. Changes needed to be hand applied to every single one. Simply put, it was a mess I should have abandoned sooner.
(second menu)
In Feb 2015 I restarted the menu from scratch, this time focusing on the home menu instead of the pause menu.
I dropped camera rotation for non VR players, and I dropped the puzzle like nature of sub menus. They were still arranged physically but spread out as to not interfere with one another. Menu became much more "elegant" and could fit a lot of information on screen. The visual design is the one thing that this menu got right.
However it still failed to fix some crucial problems with the previous menu. I foo bared and completely forgot about a lot of very important things.
This menu supported longer words and text, but the menu was built around that exact text size. It was a single 3D model, text and all. For development it wasn't too bad editing the 3D file when text was changed, but down the road it meant every language would need its own full 3D model as well. It was also literally impossible to display custom text like a player's name seamlessly within the menu. Essentially I built more of a proof of concept than a realistic menu here.
Things worked out for the best though, because in March 2015 I needed to rebuild the menu for Unity 5 anyway.
(third menu mockup)
I did a complete 180, going from static to procedural. The new menu only existed in code and was generated every time it was accessed in game. I created a custom menu class to define the menu's layout:
A generation algorithm parsed this like a hierarchy until it reached the specific menu being displayed, and then instantiated all the items and objects as listed. Text is not defined here, but rather in a separate language file. This way additional languages can be supported by simply adding additional language files, no menu changes required. I'm confident most games use a similar technique, but I couldn't find any tutorials online. Instead I discovered the method while doing website development.
It's such a great solution and I wish I discovered it sooner. Parameters can be passed with the text too, allowing player names to be seamlessly inserted. IE "welcome_back" in the menu class would be defined as "Welcome back {user_name}!" with "{user_name}" being parsed to the actual user's name. This is especially handy for different languages where the parameters might appear in different orders. It also works with numbers, IE "You have {number} minute{number_plural:s} remaining." If you're a menu novice like me and aren't already doing similar, I can't recommend this method enough. If you're not a menu novice, you're probably amused how happy I am over a standard technique.
Once again though, even this was still too static. Changes during development were fast and easy, but changes while playing were still hard. Just the other day I decided to touch up this menu again, hopefully for the last time. The text method I learned from web development worked so well that I decided to just flat out copy how most websites work. My fourth menu is just replicating PHP and HTML while using Unity 5's menu navigation system. Fast and easy to setup; no need to reinvent the wheel. Probably could have finished it in the time it took to write this article...
As always, feel free to ask any questions. I look forward to sharing another blog post with you in a couple weeks. Next week I'll probably be too busy playing The Witness.
