Cogmind will undergo some revisions so as to enable its windows to fit more comfortably within its semi-modal user interface layout, thus decreasing rows required.
Last time was focused on exploring Cogmind's shift toward supporting larger interface fonts and tiles by decreasing available display area - particularly within map view. Now is time to develop concrete plans to determine what can fit within 45 row terminal terminal. That will require mockups! A lot and lot of mockups.
As part of my Year 10 of Cogmind post, I shared an initial collection of mockups created in November - today let's revisit them individually to examine what needs to happen for us to craft this new user interface (UI) layout.
Now we work under the assumption that almost everyone uses widescreen aspect ratio displays, yet over a decade ago I didn't go that far, instead supporting 4:3 by default and permitting dynamic windows to fill any remaining width. While 4:3 players will still be able to play, there might be letterboxing at top and bottom (but there may eventually be plans to make height dynamic as well, just like width).
Before moving forward, keep in mind that mockups are designed in size 12 for easy inspection if desired and may sometimes include items and hint at mechanics that don't actually exist (these details don't matter for layout purposes ;). Also remember that mockups don't need to be completely accurate representations if necessary!
Time for mockups! It is now mockup season!
Cogmind's main UI is where players spend most of their time, so its original goal was to provide easy visual access to anything an experienced player might require without opening additional windows. Transitioning from 60 rows to 45 will necessitate some adjustments here; just select what elements and remove those which no longer serve that requirement!
Remember from Part 1, where I presented a diagram outlining all of the absolutely essential parts of an operating interface? My highlighted area did not include stored inventory as one subsection on right-side HUD display screen.
Modal Inventory
While having a visible inventory can be beneficial, I wouldn't necessarily consider it essential.
So I wouldn't say this many years ago in early Cogmind development; since then we've gained many inventory-related QoL features which reduce reliance on the inventory window itself in general; for instance slot-specific type swapping menu or part auto-replacement which enables some common inventory management without even viewing or touching directly with it.
Just by itself, our inventory saves 14 lines of height - exactly one under what is needed :D
One other regained line comes from my notes on the mockup's removal of an empty line from the upper area, marked in blue on my mockup. With data becoming even denser there, order was altered on two bottom lines and any optional ones (if visible at all) darkened slightly to restore some visual differentiation between important data elements and optionals (which might otherwise become indistinct).
Accessing inventory can be done from a button located near the bottom of a parts list (and, depending on circumstances, simply moving over that button will also display it and allow interactivity without clicking).
Pure keyboard players would be able to toggle the inventory window using the 'i' key, now freed of its previous functionality as discussed during map zoom polishing stage. Furthermore, it should appear/disappear automatically with related "modal part commands" ('p' menu) within game.
Note: My writing here should be taken with caution as these plans remain only hypothetical for now; any issues or alternatives needed depending on how these play out in practice could crop up as I discuss various UI layout interactions in this piece.
Another idea for supporting this new modal inventory would be a bottom-right indicator that appears whenever an action adds something (such as picking it up when hidden) into inventory; these indicators would stack if more than one occurs quickly before eventually disappearing after some period - this feature being both optional and adjustable.
Experienced players familiar with Cogmind's inventory-related QoL features and parts/mechanics/strategies shouldn't find much difficulty managing an inventory should that become necessary; however, doing so might interfere with its highly accessible drag-drop interface; combined with hiding its existence by default this shouldn't present too many difficulties for newcomers.
Does inventory need to always remain hidden? No! And rejoice!
Cogmind can expand to eventually hold 26 item slots; however, we start out with only seven item slots; therefore we start out with 19 empty lines which could potentially become inventory spaces... This shows where this could go...
Once parts lists can be presented in an efficient, concise format while still showing all relevant data (vital to their success), inventories can remain visible! When starting up new runs with visible inventorys there will still be 5 lines extra space for slots going forward; therefore Cogmind only needs to enter its third evolution state or enter -7/Factory before entering this state mode.
Technically speaking, we could also reduce and reveal your inventory again should your total slot count drop below its threshold (such as due to host switching in Polymind or for any number of other reasons known to some ;)).
As I considered ways to save space, I came up with another extreme version of a dynamic parts list - one which would only be optional and definitely off by default. Although not implemented right away as part of an initial iteration cycle, given how inexpensive mockups are we may as well take a look - after all they don't cost anything
Removing headers and separators between slot types from our parts list would add four lines back, equivalent to two more evolutions, so our inventory wouldn't become modal until reaching level -5/Factory; which would bring it half way towards surface level.
At first glance, this may make it harder to digest, but does save space while maintaining essential content - with categories reflected with light/dark bars along the side instead of traditional separator lines (and these would double up nicely as cycle buttons for mouse users who utilise those).
Now our main UI has been effectively taken care of! I was initially focused on keeping our main UI highly playable; these changes should keep it that way with regards to 45-row interface. Overall I was quite satisfied with how these changes should produce results, though in practice many more things still need tweaking due to being so central! xD
Info Windows
In order to properly address our secondary info windows, which have often proven challenging. These include items/robot/machine/status information as well as machine hacking windows.
What unifies all these apps together as part of one group is that they share similar dimensions and appear over a map view, all designed around an original assumption that required at least 50x50 map view with 50 rows height in total. Now when this area no longer contains them all, 45-row interface is no longer sufficient enough.
Items are the biggest source of concern when it comes to information display. While in most instances this works perfectly well with enough room left over for other content, certain products tend to push against their height limits, forcing us to scroll for stats instead of making full use of all available space.
Potentially helpful is an idea I conceived and implemented long before considering any redesign: adding the ability for items with special mechanical details (usually utility items or effects descriptions containing this info ) to have their own button for opening additional mechanical information unique to that item. Item descriptions usually provide this detail, yet there were weapons (which mostly contained stats and abilities but had limited room to display these features) with special abilities which had difficulty being explained properly due to limited room.
As more unique items enter our product line, this approach will become especially helpful as more are added to it. Unfortunately, our new layout doesn't accommodate this approach well and doesn't meet requirements since these parts represent exceptions rather than norms. What used to require up to 50 lines now only needs 45. In any event, the solution to our dilemma seems obvious:
Status information may sometimes exceed 45 lines, so I plan to alleviate some of that pressure by eliminating two low priority lines and possibly creating a pop up with all damage resistances and modifiers displayed as we play through this game. Once again, we'll wait and see how things evolve before taking any definitive actions.
Escape Menu Succinct The multipage Escape menu can be tricky.
Design of our current app was built around a 50-row map view, enabling us to display individual page information over the map while at the same time showing all commands directly in their respective main UI windows. Redesigning it all to change this behavior would require extensive work; plus I enjoy its immersive feel when integrated directly with main UI. Therefore, alternative solutions must be found if any problems arise... which they likely will - given we reduced available space from 50 rows down to 35 rows (30% loss xD).
The Game Menu and Basic Commands Page (1) is ideal, since its simple approach keeps newcomers from becoming overwhelmed too quickly with too much information at once.
On the other hand, no way could advanced commands (2) ever fit. They fill all available space within map view and I had to include only some of the more obscure commands, relegating others back into manual list for now - meaning what appears with 50 lines is already somewhat reduced version; although two column approach might fit. Unfortunately width limitations prevented that possibility.
Subpages could be the solution. Advanced commands in the map area just need a separate page accessible via Left/Right buttons on either side or buttons at the bottom.
As seen below, with our dynamic parts list height the loss of rows also reduced the space available to display its commands, but many weren't really utilized or already included within basic commands so I reduced its size just enough for it to fit within our list size constraints.
Manual access (3) in-game is fairly dynamic as it only comprises topics and blocks of text; so no issues arise there.
The options menu (4) is already organized into two columns that comfortably fill a 35-row area (in fact 33 since we need space for menu bars as well). We attribute this beneficial result to its interactive nature - keyboard players need access as well. Thus, lowercase options on one side and uppercase on another (with 26 options each on either side, plus spacer lines between headers and categories for category spacing) make up this window.
Due to our page resize, what no longer fits due to option descriptions doesn't display when hovering the cursor over an option in the options list; these descriptions should instead display in another temporary popup window instead of appearing below them when hovered upon. With that taken care of we can finish off this page!
Credits (6) does not contain much in terms of information; however, I felt as if too much space had been taken up when writing them previously. But for the purpose of finishing Cogmind this century and in time to publish its sequel(s), this tradeoff would suffice ;)
Records (7) page itself is simply a menu to access more windows; therefore there should be no issue there; however the windows it opens do pose some challenges: Lore Collection, Gallery Collection and Achievements were each built according to 55 rows; therefore we need to trim at least 10 from each...
Here is the original Achievements mockup used to construct the one currently housed within Cogmind:
To achieve 45 rows in our interactive records interfaces, it will require us to reduce the number of achievements displayed simultaneously, merge and align menus on the left, and find another way of displaying secondary windows below main ones. This last point is particularly crucial; all three interactive records interfaces utilize that format so any solution must work for all.
As it happens, there's just enough width available to move those pieces off to one side, and then our new height comes out almost exactly where we wanted it.
My preference would be the original layout with its spaciousness and better delineated areas; however, our current restrictions require we conform with them, which thankfully it did without needing further hacks to fit within.
Lore Collection is one of the easier projects, since like the manual it consists of just topic lists and associated text blocks. We can lower its height without experiencing any real negative ramifications from functionality standpoint and it should be fairly easy to implement this change.
The Gallery Collection becomes quite cramped now, having lost most of the extra spacing that had existed previously and several lines dedicated to providing information for alpha supporters who may have their name associated with an item (this was once intended as the primary purpose for creating the gallery). I will have to find another means of providing this data.
Although space may be tight, I still manage to fit everything on. Unlike with Achievements, where only nine objects were visible at any one time...
World Map Its The world map was also designed to fit within its map view area, requiring at least 50 rows. While we could provide full vertical space of 45 lines for its current layout, that simply isn't sufficient.
Cogmind's world has expanded greatly over time and routes can now take time to trace through. Furthermore, due to architecture limitations it actually needs to animate in order to display anything; therefore something must be done about that aspect as well.
Turns out the original style still works just fine and I actually quite prefer it as it provides an efficient yet condensed way of reflecting various types of movements, transitions and maps. Simply by taking out one extra line between depths we reach 41 rows interface which fits! Like some previous changes it might feel cramped but works just as intended.
Rebuilding it may still be required, but at least its design is familiar and efficient.
After creating all my mockups and taking copious notes, when it came time to review everything for errors or gaps in understanding, it dawned upon me there is one major obstacle: intro/ending animations - especially their latter counterpart. Many were specifically created with 60 rows in mind so as not to disrupt anything shorter in length - no adjustment possible unfortunately!
As such, I came up with an unconventional solution - something which will be explored next time in another engine-related detour...
