The following article covers meetings for Shiryo’s writing style and how it affects different aspects of the game, meetings around our board design and its functionality, game mechanics and a touch on AWS, all taken from the words of our Lead Game Developer — Rick.
Further In depth meetings around the writing style of Shiryo and how it impacts various aspects of the game.
Earlier this week we had a team meeting with the game development team, our core designers and our new writer.
We were discussing writing language and style and getting overall team feedback for the direction of this workflow. Our writer is excellent, but even with their own research into our project, they’ll still need assistance in realizing the particular theme and writing style we want. Normally for writing anime, shows or for script writing, you’d have a team working together to create the content — and of course each member would have different personalities, so a unified style has to be agreed upon.
We’ve been actively creating more content, whilst also doing a lot of the initial style and thematic feature discovery of what we want Shiryo to be based on. This is a deeper process than you may think to make a truly connected universe.
It’s a multi-modal process, including references to Shiryos entire lore and not just ‘unreleased lore’ that we hold internally. Reviewing promo videos, our manga — and looking towards future content mediums. From the get go with our writing and our lore — we’ve had a strong presence of mind to create this lore as an underlying framework for a truly connected universe and not isolated islands.
For example the descriptions of the cards — the first 10 or 15 descriptions involved our writer reviewing original descriptions, then coming up with 2–3 separate ones coming from different angles and perspectives, for example first and third person, or as an account / memory from someone else, a story or a factual event, how do we want to present this information.
The wording, the syntax, it’s important, for example you can tell if someone is speaking like a pirate, why? Because in a book the wording is so obvious.
Or in the same way when you read someone speaking ‘formally’, it’s an easy style to pick up on as not many people ACTUALLY speak that way on a day to day basis.
The conclusion of this meeting is that we’re all very pleased with the writing and the style, to the point where the feedback and review steps can be reduced down to a more productive single meeting at the beginning of the week, meaning it won’t take up too much resource time to produce quality work.
This was worth spending time to be sure it was right, our writer has been really able to grab what we’ve wanted and work with us with the style we’re trying to capture.
After this meeting I also had a catch up with one of our coders. Connor continued doing his internal testing of the selection of the additional cards (that will be part of the basic set) for use in the Alpha 30 person test. The team will be in discussion this week to get the community vote ongoing for this.
Reviewing new board designs for functionality and compatibility.
We had another design and review meeting with our UI designer and our other coder to provide feedback and overview of the new designs for the board. Honestly, considering I can do technical art (think cad modeling as opposed to real art), seeing an actual artist work their magic and create something from nothing, will always be a privilege to see that workflow occur.
To provide more context, Shiryo uses a hybrid approach of leveraging both 2d and 3d art. Typically you wouldn’t want to do that, you’d want to pick one domain and stick to it because there’s optimizations in doing that. In previous write ups I believe we’ve briefly gone over some of the issues that have emerged whilst trying to combine both of these technologies working at their ‘best potential’ simultaneously.
Some have questioned in the past, why are we combining these together? 2d and 3d have their strengths and weaknesses, to make something feel it’s best — you need to know when to leverage 2d or 3d accordingly.
The screen displays for the average person — may not matter, as some people can’t go too many layers deep, but a lot of thought goes into this.
For us, using both 2d and 3d allows us to create the best cross-device-compatible layouts.
If you’re on a console, you’re in the comfort of your couch with a big tv VS on a mobile — it’s a small screen — but the real difference is how the person ‘interacts’ with the game. Because the interaction is different, though it may seem one dimensional… it can change how the output of the game will be.
For example, mobile gaming typically it’s you holding the phone horizontally using your thumbs to interact with a touch screen. The constraints of touch screens drastically change how the person interacts with all the user interface (UI).
Such as — you can’t use a mouse on a phone, so you don’t ‘hover’, the hovering functionality in games is typically to indicate to the user what they’re about to do (like a check).
On a phone you don’t have this — and you’ll find the layouts of inputs across all mobile devices are relatively similar. As designers we can’t choose how you’ll interact with the device, the UI has been best designed to fit human hands and natural movement.
With a keyboard and mouse, everyone has virtually all agreed on the layout, though there is an incalculable amount of variations that people set up (i.e different keyboard shortcuts), which is a total opposite to mobile phones.
This would require us to be aware about the elements that they interact with (buttons, window panels), do we design them to be repositionable? I.e a text chat box, do we want to give the user the ability to move it?
The combination of these is important because by having crossover, we don’t have to fundamentally change the game when we import it to mobile / console / vr, the inherent framework is compatible. The animations that need to be represented in V.R are there, and also things that need to be in 2 dimensions to be optimal for mobiles are there.
If we didn’t take this into account (the need for 2d and 3d), then virtually all the elements would likely need to be altered for an optimal user experience as the game was imported from mobile, to console, to v.r etc.
By doing both 2d and 3d from the get go, we’re as prepared as we can possibly be for the future, allowing us to be able to continue an efficient work flow and not need to ‘reimagine’ any working parts for the future.
It simplifies and expedites our future plans of porting to other devices, not just buttons and UI, but the underlying code, structures and framework — all working smoothly across all ports and devices. It will save a tremendous amount of development time in the future.
The old board game provided us a brilliant framework to be able to work from, it allowed us to conduct a lot of prototyping and testing of different 2d and 3d elements, which has resulted in our latest iterations of the board being visually sound With a functional framework across all devices.
Further design meetings around game mechanics.
Then we had another design meeting between myself, Connor and Marcin to discuss optimal numbers of cards and reviewing game mechanics.
We’d observed in other TCG’s that with each turn that goes by — your hero takes x amount of damage which increases each turn until you die — and it raised some questions for us.
Did we want to use that, or use our own? Did we want a way you could exchange X for a card in your hand?
We came to the conclusion that elemental cards will not be counted towards your main cards. With elemental cards you’ll always have 10 — but the combination of what makes those 10 can always be varied. You can also whenever you want, discard an elemental card to draw another card.
And due to our previous meetings — we’ve been able to extrapolate further in the underlying game mechanics that link together different aspects that build up into a play style.
On the surface having a variety of different playstyle elements available to be used (or discovered) by the player base is vitally important to ensure the game has a rich depth to it.
That depth needs to span a welcoming skill floor all the way up to a competitive skill ceiling.
I have to say that in this most recent meeting it was awesome watching the designers in their element, coming up with ways to tie in previous unknown lore, other already initiated ideas, together with future planned mechanics that I’d heard of but wasn’t even immediately aware was there (designers, crafty bunch).
For some of the astute of you (not including myself), you may have noticed patterns in even the basic set card names words like ‘Redtail’ or ‘Palemane’ — this was not a mistake. This was intended by our designers for when an appropriate time arose — they would be able to build on top of these ‘pack names’, enabling us to deploy a game mechanic that tied individual cards into a group dynamic for collecting animations, visuals, lore and within itself have its own gameplay mechanic.
Hearing the underlying premise of how these mechanics would work across multiple dimensions of play and how they tied into the initial card game (which I hadn’t even noticed a connection to), generated an excitement in me.
I’m not sure how much of the pack mechanics I’m able to tell you, but the impact of this mechanic and the way that it’s utilized whilst simple to understand — has wide reaching effects across the game. I think it’ll be a real staple mechanic across our player demographic from both the hyper-competitive, to casual, to active collectors and everyone in between.
The AWS Server
After that for the rest of the week I continued my grind on the AWS implementation, things are going excellently. We’ve reached a point now where the number of ‘large pieces’ have been taken care of, and what remains is a number of small glue tasks that need to be taken care of to tie it all together.
I.e if you could imagine tasks in a jar, you can fill a jar with pebbles (these are your large tasks), and there will still be some spaces in between. In those spaces you can put gravel (your medium sized tasks), though there will still be some spaces in between. In those spaces you can put sand (your small tasks), and the sand is what I’m working through now.
I appreciate the write ups because I get to share a lot of the engineering side and I appreciate the patience people have to read through it as I know it can be dry. Though I’ll save the details of these smaller glue tasks on this update, as even for a technically enthusiastic man, it’s relatively tedious.
What happens after this? We’ve had some high spec dedicated hardware arrive that I’m currently setting up now.
As individual areas we’ve been working on (components we’ve been refining separately such as animations, UI, AWS, etc) start converging into the main build of Shiryo — the newly arrived hardware will enable us to do some serious stress testing.
Stress testing of the internal systems, as well as in game analysis and refinement of our balancing models (that will be used concurrently with player feedback, the upcoming Alpha Tests and subsequent community involvement).
As such I’m excited for the updates we’ll be able to share next week, every week we’re that bit closer to the Alpha Test release.
