Hey Wolfpack, it’s Rick here. As per I’ll be updating you on our team meetings, team tasks and my own tasks for the week.
Our Monday started in our usual fashion, the Monday morning Game Development Team meeting.
We conducted a writing review which included evaluating; the updated card descriptions, pack descriptions and the emote systems written dialogue.
During this review, we realized we were going to need to have a more comprehensive design meeting to go over the expanded “emote system” (Design meeting planned for next week). This will include UI layout, theme, the style of operation, ‘depth’ of emote wheel expressions, and then use this to reduce down the comprehensive dialogue options to an initial set of written / voice lines.
We also discussed and evaluated the skeletal animations that are currently within Shiryo. Skeleton Animations are the transformation of 3d assets in the game, such as the card flipping/moving as if you actually drew a card, as opposed to 2d animations which are represented on a plane such as the image on your phone’s display — that’s separate to the phone itself.
The result of this discussion involved our lead animator who specializes in 2d anims, branching over his skill set and establishing a workflow that involves both 2d + 3d animation software. This combined with the technical knowledge of how it’s implemented within the engine — creates an optimized process that should result in future skeletal animations being produced more efficiently. This also includes re-optimizing the initial 3d anims that are already in place, ensuring consistency across visuals.
As the vast majority of the 2d animations (beast / spells and unique cards) have been completed (for 30 person Alpha Test), our animator is switching gears this week and is now going to be focusing heavily on the 3d animation side.
When the “dependency” of the UI system visuals are completed — this will establish a working platform for the UI animations and ‘glue animations’ to be identified, designed and created. Glue animations are what tie everything together, such as opening a side panel that fades in or scrolls out. These numerous small additions accumulate together to add ‘polish’ to the product.
This covers the majority of what we covered in our “start of week” meeting, which was followed by task allocation to the relevant team members.
My Tasks
For the remainder of the day — my task was continuing the implementation of the UI system.
One of the main aspects that I was working on over Monday + Tuesday was an intermediate ‘Save System’. Even though Shiryo will be an online dynamic system (every time you sign in it syncs the most relevant data from a server, it doesn’t store it locally on your machine), there are some parts of that system that do involve persistent local storage. For example, your display settings or sound settings are happy to be stored locally on your PC / device.
With that being said, during development, it would be a massive inconvenience to have to constantly sign in and sync the data down from AWS. Every single time I needed to test a new function, a new piece of code or diagnose a problem, it’d be an incredible time waste requiring me to log in hundreds of times over a day. So a workaround is to create a ‘local save system’ that mirrors the same functionality while removing the need to log in during development.
Now this local save system is formatted in the same way as our AWS system. This enables us to quickly swap from ‘local’ to ‘cloud’ as needed.
From Wednesday, my next task was to implement the deck element, editor, card element and minimized card elements, including ensuring that they were general enough when needed so the same element could be used across UI pages.
For example, the deck element being used both on your profile banner and shared in your deck collection. Intuitively being able to reuse functional elements and code is a simple way to optimize development. All of these individual elements have a multitude of individual dynamic components, of which need to automatically update and display the correct information.
For example, the deck element (destroyer deck) has 7 individual components that need to update appropriately.
These are;
– Deck image
– Flag Image
– 2x Element Icons
– The decks name
– Current quantity of cards in deck
– The state of ‘If deck has been selected’
Some of these components are user-selected such as the deck name or deck image, while the element icons, card quantity, selected state — all have to be internally driven by a system.
Once the deck is opened within the deck builder, you then realize that it itself is filled with further components (minimized card elements). These also have to automatically update systematically, or when updated due to player interaction such as adding or removing cards from the deck.
You end up with a situation akin to a ‘Russian Doll’, this influences not only the systematic design of how to reliably and robustly organize this compounded data but also how the visual representation is dynamically driven throughout the whole system.
So as you can imagine, a combination of a lot of trial and error, pre-planning and then code evaluation, was required to reach the desired outcome of this quite complex system — has kept me very busy this week.
I had planned to record some in-game footage this week to share with you, but some unforeseen logistics put a spanner in the works there. I was unhappy with the visual representation I was limited to. In hindsight, this was somewhat a blessing due to the aforementioned workload of the week, it also means we have something to look forward to — in presenting a nice visual of the game itself to the community next week!
While we’ve been hard at working trying to bring these visuals in, our back end engineer and our UI/UX designer have been making strong progress on the Portal side, so we’ll be aiming to share some updates from their side too!
