Hey Wolfpack, it’s Rick here, I hope you’re all doing well! Here’s a run down of what we’ve been up to this week;
At the beginning of this week, we started as we always do with our dev team meeting on Monday morning.
This meeting had our writer, our ui designer/artist and our lead animator, with a lot of the design for their areas having been completed, we’re now deep into the more brick-and-mortar phases of the work. It’s less glamorous, less theoretical, more actual building.
As an analogy, the architecture and the structural design of the house is figured out, now we’re putting the bricks down, making the building, doing the electrics etc
While it may be slightly frustrating to all (including us) that the community write-ups presented will potentially be more ‘dry’ — it is directly due to us moving into the construction phase. It won’t be as glamorous or easy to show what it will look like while we’re actually building things.
Please bear with us, we’ll still continue to provide as aesthetically pleasing updates as we possibly can, so do our best to appeal to the majority of our community and not just our happy tech enthusiasts who’re happy to read about the tiny details (that aren’t as fun, but essential).
As you can understand, building a house isn’t an interesting process, it’s repetitive to the masses, and it is difficult but we’ll try our best to balance between being dry and entertaining.
For me personally, my tasks for this week have involved implementing all the UI systems going from the wireframes and UI workflows that our designer uses — and building the hierarchy and layer stack to be able to display all of those assets and individual elements that make the design so good.
Here’s a screenshot of me working, building and implementing the front lobby layout in Unreal Engine in our build.
Assuming most are unfamiliar with the editor, you can see how there are many individual white boxes and dashed lines.
These highlight many different elements that themselves contain many components and ‘children’ that contain the assets (images, buttons, text), anything that we want to display or allow the user to interact with.
You’re not able (as much as we’d like) to just throw these on in any order and without any constraints because you need each element to have a relationship with it’s neighbor. This enables the UI to dynamically scale and orient itself depending on different screen sizes or platforms.
Look to our images above. Even when in the lobby screen, when resizing the window you can see how the elements reorganized themselves and kept their respective positioning relative to what our design looks like.
As well as this, the hierarchy of how we layer these hundreds of individual elements dictates the presentation and the resulting functionality.
Now while the designing process of creating a unique yet up-to-date UI system requires many iterations, heated discussions, fighting for and against the inclusion of certain elements, moving from the design phase into the construction phase typically exposes further necessary work.
Unlike the design phase, as we’ve now moved into the construction (implementation) phase of the UI/UX and bringing it to life in the actual build of Shiryo — certain areas of optimisation that we could leave out during the design phase now can not be left out.
The accumulation of the many many individual things we’ve been able to skip during the construction phase and not visually represent, now actually have to be constructed — and therefore the construction phase takes longer to complete.
Though due to the fact that this is actually the build level of this system, we can exploit our own optimizations. One of those optimizations is the top navigation bar and Shiryo logo panel.
For our design throughout the entire lobby system (the menu system), we wanted to include the ability for a player to navigate through anywhere in the menu screen using a ‘persistent’ navigation bar. This enables us to create, destroy and stack the different user tabs (play/collection/quest) in a layer hierarchy that is separate to this navigation bar.
Persistent — is the optimized word. Not having to constantly create and destroy the navigation panel allows a much simpler and efficient operation of the menu system itself.
If we were to create and destroy the full display when navigating through the tabs, we would also have to consistently pass information from one tab, to the next, to the next and so forth. By having a persistent navigation panel, this allows us to hold and keep dynamic information without losing it, whilst navigating through different areas of the menu system in a more optimized way.
A ‘sister’ functionality to this incorporates the minimized social overlay and the top right settings button. Unlike the menu system, these two elements are shared across the entire menu system, including retaining functionality going into a match. Not only does this retain community functionality across into a match, the layout and positioning also provides an optimal user experience as the functionality remains consistent.
It’s key that the settings button needs to remain available from any position when playing Shiryo.
As you can imagine, we’ve only briefly covered some of the processes, systems and tasks that are wielded to create something as overlooked as a menu system. So next time you’re there navigating through a game, you may have a higher appreciation of how much time and effort goes into making that ‘effortless experience’ that is easily taken for granted.
A necessary part of the workflow required to implement this involves consistent back and forth between myself and our UI/UX engineer. There are literally thousands of individual assets and elements that come together to create the full lobby system — and of course there will be some discrepancy between the designed assets and how they’ve been exported and implemented into a completely different software (i.e the unreal engine itself). Due to this it requires the constant backwards and forwards where I complain about something not working, talk to our UI/UX engineer, he quickly solves the problem and exports it back so we can solve any emerging issues as they occur.
Now I’m hoping I’m starting to convey the work involving the sheer quantity of the number of individual elements, bringing them in and making sure they work. Not just in a way that we desire, but also a way that makes sense for future expansions and developments of Shiryo.
Perhaps we’ve provided a clearer understanding of why some of these (and future) write ups will indeed be drier (like this one) as we ‘build the house’ and implement this stuff into the game. In comparison to previous write ups that have occurred during a lot more of the designing phases, therefore a part of our workflow and process created a lot of design documentation and visuals that are easy to share. This phase is much more ‘graft’ and work heavy, it will produce a great final result, but not ‘visually appealing’ documents.
We’re going to do our best to make these entertaining, but it’s a good idea to prepare your bootstraps now that we’re in a very heavy production zone for more write ups like this (step by step plays of how we’re implementing, more minutiae details, because that’s the truth of our work right now.
Each passing week – we’re striving forward through this construction phase, we’re placing more bricks down in the house and as each layer of those bricks is completed — it makes available more features for us to share.
This week we’ve covered more of the thought processes behind the UI system as we implement it, next week I’ll be going over a specific element itself (the collection system).
