Weekly Shiryo Update from the Lead Game Dev & Shiryo Team #9

Dear Wolfpack, as you’ll know we’ve been wanting to get a more complete and coherent update to you for the last 2 weeks as we were aware there were various specific questions from the community that hadn’t yet been answered.

What we aimed to find out was how far along progress is to the Alpha Test phase, what tasks, in summary, remained and clarifying some confusion about card selections and balancing for the Alpha test.

We’re hoping this week’s update delivers on providing the information you’re after. We’ve spoken heavily with our lead game developer Rick — to bring you this information and give the community a clearer message. If you still have any questions remaining after this update, we’ll be putting a form into our main chat to take in questions from the community directly for the Shiryo game team.

Can you give us a percentage of how far along progress is to the alpha testing phase / Can you give us a summary of the main tasks to be completed?

We’re able to give an answer to this with fairly decent detail. The first thing we’d like to out-lie is that we’ve recently changed our workflow slightly to hopefully be able to give the community more regular ‘tasks completed’ updates.

As you may recall when we first posted about our delays with the AWS server, that we used this time to bring up other aspects of the game itself to continue development there, as the original Alpha test version of the game would look fairly basic compared to how we’ll present it (which is still not the final version).

This will make the game more fun to play for our testers and means it’s overall further along completion, however it still means some time has been added onto development. This is because we wish to finish the minimum amount of work that brings everything to a level standard that’s required for the Alpha Test release (i.e giving all the cards used in testing updated animations from the ‘placeholders’ — and not having random cards without it).

We’re going to tell you an estimated percentage that we’re completed, the remaining tasks, context for each task and time estimations for each task.

The Alpha testing process is conservatively 75% completion, the scale and expectations for the Alpha test release have had to be frequently adjusted as a natural part of development, especially given the scope of what we’re trying to achieve with a relatively small game development team. The 4 major components needed to be completed include:

AWS Server set up (Around 85% completed)
Finishing ability system coding (for an additional 25 cards that have been added to the Alpha Test release)
Finishing spell system coding
Finishing new animation system coding
UI / UX Final testing

AWS Server Set Up

AWS specifically is about 85% done. We’ve just recently re-organised our workflow so I can spend more time specifically finishing this task, we’re estimating 2 weeks for its completion.

Remaining on AWS is to completely migrate from abstract version to coded version in the game, add all extra small pieces that complete it as a whole, then deploy and ‘in house’ test it with people around the world. If it works for us, then it should work for the whole community.

The largest delays with the AWS server setup have come from 2 things. 1 — the actual physical problems we had with the Shiryo Servers as per 3 weeks ago, 2 — the other has also been how we’ve managed workflow. Many of the other development tasks required a lot of monitoring from Rick, however our interns have improved vastly and the team’s direction is quite clear for the remaining tasks, meaning less aspects need persistent monitoring from Rick, meaning more time to finish this AWS server set up.

The Ability system, Spell system & Animation systems

The main code base for the Ability system is operational and working correctly for the “alpha stage”, Including scaling to new cards as designed.

The holdup is that even though systematically it is operational, a TCG with as many layers of complexity as Shiryo, that includes the wide spectrum range of both an accessible skill floor for new players to learn the game, while still retaining a sufficiently advanced and satisfying skill ceiling, requires quite a few exception cards to facilitate the whole system balance. (Think much more convoluted rock, paper, scissors).

These card abilities (Typically) being unique to solve “edge” case situations, don’t often work “automatically” within the constraints of the ability system, Requiring its ability, exceptions and layered interactions to essentially be estimated, individually programmed, tested, refined and then that exception added to the whole “ability system” to integrate that single ability.

It is the kind of work that is inherently difficult to optimize

The spell system is easier to explain as it’s a repeat of the above. The spell system is a derivative of the ability system, its fed forward, utilizing the same “generalized and scalable” codebase for efficiency and performance optimization. This does result in the same exceptions that too need to be designed, individually programmed, tested, refined….. Etc.

So with this I actually place the (Ability & Spell) system within the same “major” component task that needs to be completed and signed off.

The Animation system (Gameplay event based) is once again a derivative of a multi component system like the above 2.

When a gameplay event such as an ability use, attack, spell, elemental card… etc event “occurs” a generalized sequence of functions occur, with one of those functions being the (Gameplay event anim system). This system involves the selection, blending, timing, spawning (Including location, rotation, scale) when not attached directly to a target object (like a card on the board for example) and termination or each and every individual gameplay animation sequence.

This combined with the constant refinement, polish, replacement, removal or just the addition of more unique animation sequences require constant testing, integration, scaling the animation systems code base, more testing, more refinement….etc and so on.

You may recall we spent a long time looking for intern developers, one of our interns (Tomat) was brought on-board in Shiyos Game Development (In december) to work specifically on this area due to its scale and the maintenance requirements of a visual system like this.

The ability system, spell system and animation system remaining coding will still be in development after the AWS server task is completed. We estimate this to be a matter of a few weeks, but will be able to provide a more accurate time scale after the AWS server task is completed.

UI / UX Final Testing

The UI is at a point we’re really happy with, we’ve spent a lot of time bringing it up to a great standard. In regards to the final testing, there isn’t much information to cover here, this is just our final task making sure that our user-Interface all works as it should which we estimate will take 1–2 weeks to complete.

Can you clarify for us any confusion around the finalized cards and balancing for the Alpha Test release?

The Initial 50 cards are the ‘Basic set’, which are all chosen and all have had initial balancing. However, we’re adding a selection of 25 more cards (chosen for how well they’re already balanced into the game), then we’ll be providing pre-made decks built from the 75 cards.

We’ve added these cards for both more fun for the testers, for seeing how the additional 25 will enhance the base 50 in action — and for receiving more quality information when it comes to our testing phase.

We’d like to clarify that as we’re trying to limit testing variables — we do not wish to overload the testing phase with the full selection of cards. We’re looking to test all the ‘core components’, such as making sure the servers work well (i.e internationals play each other with no problems). As we advance through the testing phases we’ll be adding more functionality (i.e deck builder & full card selection).

To control the variables of testing, we will be offering carefully thought out pre-made decks from the 75 cards. The reason for this decision is in the short term it will allow us higher quality, more measurable testing. As we advance to further testing phases we will look to have the deck builder live for the community.

All of the chosen cards need further balancing, however we are not ‘still choosing what cards to use’ or anything such.