Package Name: Rotational Menu System (RMS) Current Version: v1.3 Availability: Asset Store Overview This system has two distinct managers that can be easily separated and used on their own, and as such it may be best to look at them as two separate entities in one bundle. The Rotational Screen Manager manages and manipulates world-space canvasses so that you can use 3D transitions from one menu to another (rotations being key among these), but still design your menus as if they're in screen-space using screen-size percentage UI element positioning and sizing and Canvas Scalar settings. The Rotational Menu Manager, on the other hand, organizes an 2D array of logical menus and provides you with several simple methods of navigation from one menu to the next. Please note that the only UI elements included are the ones absolutely necessary for making the demo scene. This package will not help you to build a graphical UI in any way at all, but rather it will help you to organize and transition between your menus in a fun way not normally possible with screen-space resolution-adaptive menus. *** Batteries and menus not included *** Features With the Rotational Screen Manager: Creates and adapts world-space canvasses to fit your screen resolution and aspect ratio automatically, mimicking screen-space canvasses Perfectly replicates Canvas Scalar settings (which normally do not work with world-space canvasses), so that the scale of your UI and text elements are consistent with your screen-space test canvas. Allows for interesting 3D world-space transitions between what were designed to be screen-space menus Adjusts the camera's field of view and the canvas' real-world dimensions dynamically to make next-screen positioning trivial, but keeping the canvas perfectly fit to the screen New transition types are easy to make and implement in the script (there are currently 10 distinct transition types with several sub-types for each). Can use easing equations to change the flow of transitions (there are six distinct easing types, and 4 sub-types for each) With the Rotational Menu Manager: Provides an easy method of organization and navigating through your menus Can handle mouse click-drags and finger swipes as navigational input right away Able to queue navigational inputs to be performed one after another Can wrap around menu and sub-menu index ranges, if desired (first to last and last to first) Choose from horizontal and vertical menu orientations Different default transition types can be set for different menu types in the nav system Can auto-navigate from one menu in the system to another in the shortest possible distance, passing through every menu in between Several events (such as "active menu changed", "transition started", "transition ended", etc...) can be subscribed to, making it easier to implement a clean context-based menu design How It Works: Screen Manager The Screen Manager creates two new world-space canvasses on Awake (the primary screen and the transition screen) and, using the referenced GUI Camera, will calculate the physical dimensions of an imaginary screen 100 units forward from the camera's position with the camera's current field of view, and apply these physical dimensions to the two canvasses. It does this again whenever the resolution/aspect ratio of the screen changes or the field of the view of the camera is altered, in order to keep the physical sizes of the canvasses perfectly matched to the visible area of the camera. Consider this mimicking the Screen-Space Camera canvas mode. Now that the physical size of the screens is settled on, there's the pixel density. Using the actual maths copied out of the Canvas Scalar script for screen-space canvasses (normally unusable for world-space canvasses), the system will use the scalar settings you've supplied and apply them to appropriately adapt the pixel density of the canvas. This perfectly replicates all canvas scalar settings, from "Constant Pixel Size" (the default- only the scale option is applied) to "Fit To Screen Height or Width" to "Constant Physical Size". Why would we want to go through all of this work to make one canvas type act like another canvas type? Isn't that what the overlay canvas types are there for, already? Well, world-space canvasses have one huge advantage over screen-space canvasses, in that they're actual objects that exist and can be moved around in the game world. This means we can apply all sorts of effects and transitions to the canvasses that were previously extremely difficult or downright impossible- the primary one we've advertised here being the ability to rotate from one menu to the next like you're moving from one inside wall of a box to another (you may remember this transition effect from the Ocarina of Time menu system). You can also easily do sliding transitions, flipping the screen around, tilt the menu slightly in various directions (like the Smash Bros. menus), or simply shake the screen- basically anything you can do to a physical object in the game. One of the things we initially struggled with was the ability to rotate both left/right AND up/down to another menu. It sounds simple- just put the menu in the proper position and rotate, right? However, screens aren't squares- they're rectangles, so careful managing of the camera's field of view is necessary. If you're going to be rotating left or right 90 degrees to a new menu, then to perform the task cleanly, the field of view needs to be 90 degrees horizontal, with the canvas dimensions scaling up or down to meet that demand and still stay in the same position. Once the camera's field of view is set and the canvas is properly scaled, you can simply "connect" the transition canvas to the primary canvas at the proper edge, rotating it 90 degrees so that it's like another side of a 'box' the camera is sitting inside of, then rotate the camera to look at the transitional canvas. When rotating up and down instead, the exact same method is used, but this time a 90 degree vertical field of view, with the canvasses adapted to that instead. When rotating to less extreme degrees, say 30 degrees instead of 90, you simply have to set the horizontal or vertical field of view to 30 instead and adapt the canvasses to that new view size. It's almost trivially easy now, and the calculations for field of view and canvas scaling is done so precisely that there isn't even a flicker when this occurs- the menu will look exactly the same on the screen down to the last pixel. This introduced a new difficulty though- if we're rotating left and right to new menus and then rotating up and down to other menus, the camera is going to get flipped upside down, sideways, and all around as we're navigating around. This means 2 things- first that the camera isn't going to be able to show anything except the menu (doing otherwise would get disorientating VERY quickly), and second that the Transitional Canvas positioning is going to get complicated with quirky transition types when we have to constantly adjust for the camera's current rotation and position. We solved this new difficulty by simplifying the equation. A transition is now a single animated sequence, and as soon as that sequence is over, the position and rotation of the camera is reset to its default state. We'll be looking at the primary screen again, instead of the transitional screen we were moving towards, but by re-assigning the "new menu" from the transitional screen to the primary screen in the same frame, it doesn't look like any swap took place at all- not even a flicker. Because the camera is always in its default state when a new transition is starting up, the maths for the camera field of view, transitional canvas placement, and camera animation are all now as simple as can be. How It Works: Menu Manager The menu manager allows you to set a list of "primary menus", and on each primary menu component you'll have the option for setting "sub menus", and in this way, the 2D array of menus is established. The Menu Manager will accept (or if you allow it, generate from click=>drags or finger swipes) simple directions like "Left, Right, Up, Down". These directions are given to the navigation controller, which processes and turns them into logical commands, such as "primary menu forward", "primary menu back", "sub menu forward", etc... These logical commands are then queued. When each item in the queue comes up, the system will check to see if the given logical command is valid (if there's a menu in that direction- this is where the "wrap around index ranges" comes into play, as you can optionally go from the last menu to the first and vice-versa). If the direction is valid, it will get the "next menu" in that direction, have the Screen Manager attach it to the Transitional Screen, and then start the process of animated transitioning between the current menu and the next. The Screen Manager handles the actual positioning and transitioning, while the Menu Manager says which menus get attached to which screens, which transition type to use, which direction the transition should be moving in, and how long the transition should take. These are all settings that can be changed in the inspector, quite easily. That's the basic of how navigation works, but the system also has all sorts of overrides if you need something to work in a special way in certain circumstances. You can go straight to a given menu in the system without moving between any of the menus in between, define your own transition type and/or direction that overrides the nav system, bring up an "extra menu" that doesn't exist in the navigation system (not a primary or a sub-menu), but which you want to be able to access by clicking a button or pressing a key on a keyboard only, etc... The Menu Manager really isn't that complex by nature- it started out as a very simple menu system to show off the capabilities of the Screen Manager and sort of grew from there as more and more features were added. Demos We've made several videos to demonstrate the system's current capabilities. One is a quick 2-minute silent demonstration. The second is an in-depth no-code walkthrough of the system (with my sultry voice to keep you company). The former only shows some of the transitions and navigational logic, while the latter shows what the system does, how it works, and what the inspector variables all do. Both were created for version 1.1, so there are some minor differences and a few missing features and transition types, but for the most part they are still quite accurate. Silent Quick Video Demonstration (v 1.1) In-depth No-Code Walkthrough Video Demonstration (v 1.1) In addition, there is a web demo we've put together that you can try out on your (non-Chrome) browser. We've included an "options" screen to the left that will allow you to try out most of the available transition types, change the menu orientation, and toggle many of the options available in the inspector for the Menu Manager. WebPlayer Playable Demo Scene (v 1.2) Documentation Documentation has been included that has script overviews and basic system usage, explanations of inspector-exposed members, and lists of all public methods and how they work. A copy of this documentation can be found in the Documentation directory in the package, or can be downloaded (for the most recent version) using the following link: PDF Download. A list of version changes is provided at the end of the documentation.