Good day Wolfpack, Rick and the Shiryo team here.
As you may recall last week there were a number of bugs that needed to be worked on, as such a lot of energy was put towards these issues and we’ve outlined the solutions Rick was able to work through, as well as of course giving a brief overview of tasks that have been worked on through the week — and answering some more questions from the community.
Over Monday and Tuesday, a lot of time was spent organizing animation assets in CSV file format, this requires us to have a ‘friendly’ and ‘engineering’ version of the CSV file.
To re-cap from last week: The CSV system is a large system that we attach all animations, textures and card info to — so instead of having to write individual code, it’s a generic system that all cards run through and operate there. Even the skeleton of the cards, how it moves in space, the delays involved and the order in which they fire is all controlled and works automatically and is always scalable with new cards as long as new cards are created in the same compatible format. This allows for easy scaling without having to do further huge updates to the system.
This is so we have an accessible and optimized workflow between the designers, artists and for the devs to integrate that into Shiryo.
So the process around this would be concepting and designing for animation, this is then brought to the artists who physically create the animations that we need. The assets, descriptions, I.D’s, time durations — basically any information that we need to fire off these animations is added to a ‘friendly’ CSV file by the designers.
The CSV format used by Unreal is significantly different (or abstract) compared to ‘friendly version’, making it difficult to work on if you’re not a developer. So with this we have a ‘friendly formatted’ and ‘engineers formatted’ (or developer formatted) versions that are dynamically linked together, this enables non developers to create adjust / edit and import new animations, that seamlessly convert into the engineering format, which when imported into Shiryo, this auto generates and drives the animation sequences automatically. Apart from the developers needing to create animation objects or new designs, or new sequences that the artists have created, the underlying system will simply work automatically.
To accomplish this I’ve spent the majority of Monday and Tuesday designing and testing these CSV file formats and ensuring they work smoothly with the current build of the animation system.
As well as this, I’ve gone through the current target animation sequences, as well as desired animation sequences — evaluating errors or issues that are to be amended in the CSV files — as well as identifying any missing or faulty animations. In general, I’ve assessed the completion stage of the animation systems, testing the current system that’s in place for its robustness. With this information I’ve been evaluating the remaining work in the system, and creating a work plan so that future tasks can be delegated appropriately.
On Wednesday we had a design meeting with our sound designer and our UI / UX engineer, the sound designer covered many aspects and started identifying the core gameplay sounds that we want to play with implementing into Shiryo.
Having both of those core members in the meeting enabled them to bounce back and forth off each other due to being two sides of the same coin in their knowledge base, this collaborative work effort enabled a much more productive workflow, as we were able to identify and dissect core sounds and the important tactile feedback that we were wanting to implement, both audibly and also visually with examples, sketches and experience provided by the UI engineer.
(Things like ‘feel’, the underlying theme of a sound (is it elemental based?), the tactile experience / the general player user experience whilst operating any of the interface or when playing the game).
After that meeting, the designers were able to be left without further supervision to get to work. I was able to make a bunch of reference material, including clips of gameplay, anything and everything that might be operated by the player on the board, for instance drawing a card, placing a card on the board, attacking, different individual animations, as each and every single one for these events while easy to overlook — greatly increase the user experience by engaging the player in a more comprehensive way.
I.e Imagine if you were playing another card game and there were no sounds when the cards moved, something would feel off. It’s easy to not realize how impactful and vital a lot of the ‘smaller sounds’ can be to creating a complete experience
Even with the 30 person alpha test due — to the fact the majority of the time will be spent by the player interacting with the board and the game itself, we deemed it a higher priority to direct our efforts at that user experience first.
Throughout the remainder of the week I continued working on my own developing work, specifically working on the bug problems that we covered in last week’s write up and continuing AWS coding.
To refer to the problems that bugs presented last week, please check out our previous weeks write up here; https://medium.com/@shiryo/weekly-shiryo-update-from-the-lead-game-dev-shiryo-team-11-ba7b59e1b38c
This is what I’ve managed to work through;
Bug 1: (Searching players would swap positions), I was able to solve this by creating the function that during the time period where this bug would occur — I would update the player session creation policy for the ‘owning players’ lobby game session and setting it to ‘deny all’, thus preventing a ‘double join’ event from occurring.
Bug 2: The majority of this issue has been solved. Now 99% of the time the client’s original lobby is protected from being terminated and the resources reallocated, only a few edge cases remain. I believe packet loss is still causing this issue. Fixing this last one percent requires identifying and being able to repeat the cause of the issue so that a fix can be found — which is still being worked on.
Bug 3: In some circumstances when a game had finished or end game conditions had occurred, the server game session wouldn’t terminate, i.e it would start to accumulate and pile up, essentially amassing a graveyard of games that can’t be used.
To solve this I created an internal checking function in the server, that checks whether the server’s game session has been used as designed (with two clients having joined), playing a game of Shiryo, reaching end game conditions, and then both clients having disconnected and returned to their lobbies.
In this circumstance, after a specified amount of time, the game session will now terminate itself. Some exceptions to this would be if an unexpected disconnect of a client, or error causing network issues occur, then an internal timer starts that will wait and allocate the amount of time for the disconnected client to return / or for the connection to establish, then if this timer is exceeded then the server terminates itself and reallocates the resources.
Now for some more of the communities questions:
Could you provide updated gameplay videos showing the progress on a more frequent basis?
With quite a lot of the areas either being updated or entirely replaced with updated features, (i.e our whole menu system is completely different to the original) while I would really like to show more, especially knowing our vision that we’re currently striving full speed to accomplish — to do that requires us to simultaneously be upgrading, replacing, because of that it leaves the state of the game in a condition that isn’t conducive to showing off how it looks.
When we showcase the game being played, we have to pause certain aspects of work to ‘set the stage’, and we need to make sure that no bugs interrupt that. We can’t have efficiency of working and keeping everything in a state ready to showcase at all times.
It’s like building a robot, people can build it and it can showcase a level of functionality, but if we want to modify the robot it needs to be pulled apart again so it can be upgraded and it isn’t in a ‘show off’ state during that time.
If we were to do things sequentially with one change at a time, it’d take significantly longer, but we’d have more opportunities to show off updates and progress in an attractive manner. It goes without saying that the speed of our progress is a much higher priority to us than ensuring that we can show off small but more consistent visual updates.
Normality when you see large companies, they’ll have a team specifically allocated just to keep a displayable build ready. Unfortunately we’re not that big (yet), but as mentioned, we look forward to being able to show off our hard work as soon as we can.
It’s something we’re aiming for though and there will be a point soon where it’ll be easier for us to showcase updates. Being able to share and show it is one of the reasons we do this, but we also want it to be right.
How many decks will be able to be stored for a given player?
The exact number has not been applied, instead through testing and community feedback, the users deck builder capacity will be set and adjusted based upon ‘demand’. The number is essentially arbitrary to us because if players want more space then they’ll get more space, whilst storage space is a resource that we are conscious of, we have optimized the game and the way we store the information to ensure ‘storage’ is a resource that we don’t have to worry about. (Rick says don’t quote him on it, but using back-of-the-napkin math — that around a terabyte of storage would allow a billion players to store a hundred decks).
To offer something of a more maybe useful comparison, it will be competitive or exceed other trading card games.
Will element cards — not exactly sure of the mechanics — need to be counted as cards that are included in the 30 card limit for individual decks?
Bear in mind that core mechanics we believe should be set by gathering and applying data, by actually testing the game and feeling out what makes the game engaging and enjoyable the most.
So with this, we currently have a range that different designers and developers are feeling for — with the number of cards that will be in a deck. This is still initially (before testing) up for debate for between 30 and 40 cards in a deck, and the number of element cards you have — the current plan for it’s to provide approximately 10 elemental cards.
Though during testing a selection of the pre-made decks will be applied to different testers that utilize a range of the number of elemental cards included. This will enable us to dial in a balanced quantity of element cards allowed per deck. During the alpha test, some of the data we’re wanting to acquire is actually figuring out the optimal number of cards within a deck (optimum min/max) as well as the quantity of element cards in a deck. This will be achieved by providing a range of different configurations and with testers providing both video captures of their gameplay and written feedback indicating their preferences, as well as in-game performance data.
Can you provided an insight into the background music during various stages of playing/interacting with the Shiryo game? Has this process been started yet? Willing to showcase some samples to the community? 🙂
This has been started, our sound designer has already begun concepting and playing around with in-game music, soundtracks and battle music. But to create something special, memorable and befitting of Shiryo, requires really fleshing out that process and getting to know what Shiryo ‘means’ through its sounds.
There’s a very large significant artistic aspect that is somewhat hard for ‘me’ to describe the process of — and currently we’ve prioritized in-game sound effects for the 30 person test (using the UI / board effects / samples and so fourth). However, these will be used in inspiring other audio.
The process of generating the overall audio space for Shiryo is that you have to create a huge model of ‘feelings’ — which personally as an engineer and having a technical function based mind set, the actual magic and wizardry of our audio designer is beyond me. I’m as excited as you guys are to experience what Shiryo will feel like through its sounds.
Previously used sound tracks we’ve used for promos, marketing and so fourth, while useful in giving a representation of the vision of Shiryo and what it’s becoming, the majority of these audio tracks were outsourced specifically for temporary testing, development and promo. They were useful in giving us examples and allowing an iterative workflow to ‘dial in’ the sounds we want, it’s quite a significant process (which is why we have someone we’ve brought on full time).
To further a previous paragraph, we’re presently prioritizing the in game sounds (i.e UI / UX / board sounds), they’re relatively short sound bites that compliment animations and aren’t as suitable to ‘show off’ (although they’re great), however they will inevitably lend itself into inspiring our final game sound tracks. As soon as we have the sound tracks are ready we’ll be sure to showcase them to the community.
