Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[DEPRECATED] Rotational Menu System

Discussion in 'Assets and Asset Store' started by DonLoquacious, Apr 13, 2016.

  1. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    Banner_Large.png
    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.
     
    Last edited: Dec 7, 2016
    Fronne likes this.
  2. Fronne

    Fronne

    Joined:
    Sep 25, 2014
    Posts:
    112
    COWABUNGA! This Asset Rocks!

    I played with the web-demo for a few minutes, fell in love and had to buy it immediately...
    The first impression is great, Code Readability & Documentation is well organized, great transitions and performance on mobile seems to be good. I had a question and received an answer within one hour, great support too...

    This is a winner, Great Job!

    Cheers,
    Franco Palmieri - Fronne
     
  3. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    @Fronne Thanks for the kind words, and for the bug report! I'm embarrassed that such a simple mistake was overlooked when I submitted the latest version.

    @Everyone else: there's a bug in v1.2 where the screen directions (left, right, up, down) aren't being properly converted into logical directions (forward and back) for the vertical menu orientation. This has been fixed in the next version, but will take several days to post on the AssetStore. In the meantime, you can fix it by opening "RHelperFunctions.cs" in the Core/Helpers directory, and editing the DirectionToNavigation function so that both of the returns in the first IF block are " == ScreenDirections.Right" and both of the returns in the second block are " == ScreenDirections.Down" (lines 85 and 92 specifically).

    The screenshot below shows what the corrected function should look like:
    upload_2016-4-18_17-38-38.png
     
  4. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    New version 1.21 submitted with a couple of bugfixes and support for Unity versions 4.6, 5.0, 5.2, and 5.3.2.

    The sample scene / demo menus that I included in the last version were made in 5.3.2 and they worked down to 5.2, but not earlier (the way that GameObjects / Prefabs were constructed was changed at that point, I'm guessing), so I had to completely reconstruct the scene from scratch for 4.6. Some changes were necessary, as the Dropdown class was not included until 5.2, which means the 4.6 and 5.0 versions couldn't have dropdowns for the orientation and transition types in the Options test menu screen. That being the case, I just dropped the Options screen entirely from those versions. You can still access all of the options in the inspector- this only affects the demo scene.

    5.2 doesn't have a few of the dropdown class functions I used in the Options test menu script, so those were changed to be compatible with that version.

    Two bugs were fixed- one (as mentioned previously here) kept the screen directions from being properly converted to navigation instructions. The second was less a bug and more a reorganization- the events for "Transition Ended" and "Menu Changed" were fired near-simultaneously for most menu changes, but in an inconsistent order (sometimes one would fire first, sometimes the other- depending on the navigation coroutine being called). This led to some funky behaviour in some scripts that relied on those events for status updates (namely, the navigation arrows after forcing a menu change). Now, the "menu changed" event will always fire before the "transition ended" event.

    * As always- it may take several days for the submission to be approved.

    UPDATE 5/4/16: Approval took a little longer than normal, but it HAS now been approved and the new version is available on the asset store as promised.
     
    Last edited: May 4, 2016
  5. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    A new bug has come to my attention in which the resolution change isn't reflected properly in real-time and only fixes itself when navigation occurs. This may have something to do with the script execution order or some other late-stage adjustments I made (otherwise I'm not sure how I overlooked it), but I haven't rooted out the exact source of the bug yet. It appears that some scripts see the updated screen size information and some still see the old screen size until the following frame- it's absolutely bizarre.

    The fix for it, however, is quite simple- you just have to delay running the resolution adjustment function in Update until the frame AFTER the one in which the resolution changed. You can do that simply enough by making this change to the update function:
    Code (CSharp):
    1. private bool resolutionChanged = false;
    2.  
    3. private void Update()
    4. {
    5.     if (resolutionChanged)
    6.     {
    7.         UpdateScreenData();
    8.  
    9.         resolutionChanged = false;
    10.     }
    11.  
    12.     if ((Screen.height != lastResolutionHeight) || (Screen.width != lastResolutionWidth))
    13.     {
    14.         resolutionChanged = true;
    15.  
    16.         lastResolutionWidth = Screen.width;
    17.         lastResolutionHeight = Screen.height;
    18.     }
    19. }
    This creates a single-frame delay between the resolution change being detected and it being adjusted for- this can also be easily accomplished with a coroutine or an invoke method instead, if so desired.

    UPDATE: Worth noting that I checked my builds, and this issue appears to be limited to in-editor resolution changes. The fix doesn't hurt anything though, so if you want to do real-time updates in the editor without hitting the navigation arrows to force-fix the resolution problem, then feel free to implement the above code. I'll be including the change in the next version release.
     
    Last edited: Aug 18, 2016
  6. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    1.3 submitted to the Asset Store- just awaiting approval.

    Here's the change-log for 1.3:
    • Dropped compatibility versions for 5.0, and 5.2 because the number of users actively using anything below 5.3 has dropped below 5%. Compatibility versions for 5.3 and 5.5 being added instead. Unity 4.6 will still be supported, so that version will be used for anyone running up to and including 5.2. Keep in mind that the drop-down boxes seen in the demo aren't available pre-5.2, so the options menu is missing from the demo in the 4.6 version.

    • Added new transitions- "Convex Rotation" and "Diagonal".

    • Added "skip" transition versions of Linear, Rotation, Convex Rotation, and Diagonal transitions. A skip version will essentially double the distance to travel/rotate, so it's as if there's a blank spot in the menu array that will get passed over. In other words, it creates a screen-size gap between the current screen and the next screen when transitioning.

    • Removed specific transition type options from the TransitionTypes list (Rotate30, Rotate45, etc) and it now reflects only the broader categories of transition types (Linear, Rotation, Flip, etc).

    • Created two new enums, RotationalTransitionOptions and FlipTransitionOptions, to select the specific options for those transition types. These options are passed as arguments into the screen transition function, when needed.
    Screen Manager
    • Moved screen object initialization process into its own function to clean up the Awake function.

    • Straight and diagonal transition types no longer bother adjusting the camera or screen size, since normalizing them isn't really necessary.

    • Rewrote all of the transition functions to be more efficient and handle a greater range of options. The rotation coroutine now supports convex rotation math (screen's positioned around a circle that doesn't have its origin at the camera's position), and creating gaps between the primary and transition screens rather than butting them up to one-another side-by-side. Similar changes have been made to all of the other transition coroutines.
    Menu Manager
    • Added several new functions for finding sets of menus (primary, sub, or both) by GroupID or GroupName- GetPrimaryMenus, GetSubMenus, and GetMenus.

    • Added support for RotationalTransitionOptions and FlipTransitionOptions set in the inspector for default primary, sub, and extra menu transitions.

    • Moved all general menu settings in the inspector into one sub-object for organizational reasons.

    • Now that there are three different selections that potentially need to be chosen per transition type (TransitionTypes, RotationalTransitionOptions, and FlipTransitionOptions), a new class object for "TransitionOptions" was created to encapsulate those values, for organizational reasons, and are now used for primary, sub, and extra menu default transition types in the inspector.

      NOTE: All organizational changes were done to prevent the need for custom editor scripts. Please let me know if custom editor scripts would be preferable to how things are now set up (keeping in mind that it makes adding new inspector values to your specific implementation annoying).
     
  7. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    1.3 now approved and available on the Asset Store. ^_^

    The next big update will change the way that transitions are handled. Currently each transition type is a coroutine in the Screen Manager script, and that was fine when we only had 3 transition types, but it's making things a big heavy there now (and heavier in the Menu Manager as well, now that it has to support the RotationOptions and FlipOptions in navigation functions, to pass them on to the Screen Manager for the transitions). I'd like to, at the very least, get those transitions, and their accompanying options, moved out into their own script(s), but which way I'll choose to accomplish this is still up in the air.

    I'm still against making custom inspector scripts at this time, as I believe the trade-off between visual organization of the inspector fields and the added annoyance when trying to add/change those settings for your specific implementation, hasn't yet shifted toward the former being more important. This isn't a closed system like PopcornFX where you couldn't change the source even if you wanted to, and isn't so inherently complex like A* Pathfinding Project that the relative increase in complexity when adding custom inspectors is insignificant to the total. This is made for you to make changes, if needed- to add new transition types and commands and play around with it to get it working exactly how you want.

    Depending on how things evolve for 1.4, that equation may come out differently though.

    And on that note, if anyone has any ideas on things to add for 1.4, please let me know here. My only current future plans involve reorganizing things and not really adding any additional functionality, not because I don't want to add anything, but rather because I can't really think of anything else to add. Input would be greatly appreciated.

    Lastly, here's a preview of the transition types currently available. There are further options such as selecting the angle of the rotational transitions (30/45/60/75/90), easing equations to make the transitions start/end slower/faster, and more, but that's a bit more than I want to cram in here.






     
    Last edited: Apr 7, 2017
    Fronne likes this.
  8. Asset_Store_Deals

    Asset_Store_Deals

    Joined:
    May 2, 2016
    Posts:
    335
    Just to let you know we are adding Rotational Menu System to AssetStoreDeals.com.

    If you have other sales in the future, you can add them to this website yourself simply by pasting the link to your asset in the designated area.

    Best of luck to you with this sale!
     
    Fronne likes this.
  9. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
  10. Fronne

    Fronne

    Joined:
    Sep 25, 2014
    Posts:
    112
    Too Bad, it's worth double price and more...
    Hope the new price will give you the 5 star rating it deserves...

    Cheers!
     
  11. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    @Fronne Thanks for the kind words, as always. Marketing has been a real problem, given the complexity of explaining what the asset is and why it's useful. That's my fault really- I can't give it the attention it really deserves with how busy we are with game development right now. As a result, even the people who are running face-first into the limitations of overlay canvasses, who would really benefit from this system just for that, probably can't find it in searches very easily. I'll try and do better once I have some breathing room.

    If you'd like to see anything in future versions, please let me know!
     
  12. yormanh

    yormanh

    Joined:
    Jun 26, 2014
    Posts:
    3
    Hello

    I have this error.

    Assets/RotationalMenuSystem/Scripts/Commands/RNC_ButtonStatusFromGroupIDStatus.cs(40,28): error CS1061: Type `Button' does not contain a definition for `interactable' and no extension method `interactable' of type `Button' could be found. Are you missing an assembly reference?
     
  13. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    Hello!

    I've never seen an error like that, but my first guess is that either you're using a version of Unity after the Button class was introduced but before the Selectable class (which it derives from) got the "interactable" property (although I'm about 90% certain it had that property right from the start), or you've got a custom class called Button in your project somewhere that's being used instead of the UnityEngine.UI.Button class, and which doesn't derive from Selectable.

    If it's the former problem, I'll need to know exactly what version of Unity you're using and try to think up an alternative. If it's the latter, just put the custom Button class in a different namespace and the error(s) will disappear, or specify "using Button = UnityEngine.UI.Button;" at the top of the affected scripts... but note that you'll have to do this for every script that uses the UnityEngine.UI.Button class, so it's far easier to just wrap your own Button implementation in a different namespace.
     
    Last edited: Jan 30, 2017
  14. yormanh

    yormanh

    Joined:
    Jun 26, 2014
    Posts:
    3
    Hi

    Is the last version, Unity 5.5.1f1 (64-bit)
     
  15. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    I can't reproduce the error, so can you please check to see if you have a custom class in your project named "Button"? If you do, please put it in a different namespace or rename it.
     
  16. yormanh

    yormanh

    Joined:
    Jun 26, 2014
    Posts:
    3
    In a new project works perfectly. I think I have something wrong, I'll check it out. Thank you
     
  17. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    New version 1.31 has been submitted to the Asset Store for review.

    Not a massive update, but a few small but critical changes. All scripts have been pushed into a library (DLL), so if you're currently using RMS in a project it's recommended that you do NOT update directly, as it will break any existing references to RMS scripts in your scenes and prefabs. If you wish to update safely, download the Source only, then unpack that into your project- it should overwrite the existing scripts this way and maintain references, but this is not absolutely guaranteed. If you want to be completely sure, you'll need to unpack the source into a separate project, then copy over the CS files (but NOT the .meta files) into your existing project and overwrite them. Please be sure to back up your projects before attempting anything.

    A few other things have changed too. I've moved all of the "transition options" into their own separate struct, so it's usable and readable equally by everything in the project. The new struct contains the transition type (linear, rotation, swap, etc), the time the transition should take, the specific options for rotations, swaps, etc, and finally the easing functions. Due to this, you can now define all of these on a per-transition basis, rather than having to edit the settings of the menu or screen managers, giving you much more freedom. As far as the existing Navigational Command scripts go, the biggest impact this had was on the GoToMenu_Fixed script, which if you've used in your own projects will need to be updated to fill in the additional information.

    Be careful not to set the "transition time" to zero- it should automatically set to 1 second in circumstances where a value isn't provided, but if you explicitly set it to a negative number, or zero, then it may cause issues/crashes during transitions.

    I've also sent a new asset to the UAS for review called "RMS Lite", which will be available for free. This version is lacking the flip and swap transitions, containing only linear and rotational variants, and doesn't have easing functionality built-in for transitions at all. It also will not be updated except for critical bugfixes, if any are found- all new features will be added only to the full RMS version as they're developed. Both versions are built around an included library, but both have source code available.

    As always, if you have any questions or suggestions for features, please let me know.
     
  18. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    When I updated to using a library instead of loose scripts, I forgot to update the Script Execution Order settings. If you run into an error, probably a Null Reference Exception in the RScreenManager script, then it's likely because the RMenuManager's OnEnable function is running before the RScreenManager's Awake function.

    The error is very easy to fix- simply add the RScreenManager to the Script Execution Order manager at -100. If you're still getting an issue, add the RMenuManager there as well, at -50.

    I don't think is quite a large enough issue to be worth re-submitting the asset again, but it'll be fixed when the next version comes out (likely not for a couple of months, unless someone submits a bug report or asks for a new feature).

    Cheers!
     
  19. DonLoquacious

    DonLoquacious

    Joined:
    Feb 24, 2013
    Posts:
    1,667
    Packages for RMS and RMS Lite (free) have been deprecated on the Unity Asset Store. Parnassian Studios will no longer be using the Unity Asset Store to distribute our assets, but rather, all tools that we make available for use in Unity will be under MIT or similar open-source license to fork, edit, and distribute as you like in your own projects.

    In a couple of weeks once I have the time, I'll be posting several repositories for tools like this one, both with integrations into our Unity Services Framework, and standalone to integrate into your own systems.