Hello Wolfpack, this update comes to you from the Shiryo Team and our Lead Game Developer Rick. The first part of this update covers some of the latest progress over the last week, with the latter-half covering questions submitted by the Wolfpack.
Rick: In terms of AWS progress, I’ve been going through the logic flow (version 15b) and meticulously going through the code base to be sure the functions are correct and working as they should be. The vast majority of this double-checking has already been done, but like the carpenters code ‘Measure twice, cut once’, it’s imperative that all checks are thorough.
Since the last update I’m just over ⅓ of the way through the remaining AWS tasks, which is actually a little behind where I anticipated I would be. However, this is merely due to needing to assist our other developers more than what was foreseen this week and not due to any technical issue.
We’ve also been working on the UI (that is inseparable from AWS) such as login screen, lobby menu, etc to make sure the menu systems all work as they should. The UI has quite a lot of functionality to it, making this a relatively lengthy task.
For an overview of other tasks we’ve been working on throughout the week;
On Monday we began the weekly development team meeting, going over weekly tasks, dealing with any (low hanging fruit) issues and planning out dates and times for individual team member 1-to-1’s to address issues that need direct help.
After which I had a 1-to-1 with Connor. He’s one of our teams ‘generalists’ who has been working a lot on Shiryo’s design and art. His recent work has been assisting in creating additional animations for the game. This week he was able to begin upgrading our board design. Although the board aesthetically has received great feedback, in practical use there are various elements of the game that don’t quite sit right. Of course it’s essential that this is amended for a smooth gameplay experience (and to mitigate any potential ‘fud’ upon the launch of the Alpha Test Release).
An 8 page design document for new iterations and and layouts was completed for this task, so this coming monday we’ll be handing off the board to our designers.
After all meetings were completed. I carried on with my AWS work for the rest of the work day.
On Tuesday we had a quick morning team meeting. Then started my 1-to-1 with Tomat. He’s another one of the teams “generalists” (something of a pattern here at Shiryo — as the saying goes “A jack of all trades is a master of none, but oftentimes better than a master of one.”) this couldn’t be more applicable to the multidisciplinary industry that is game development.
Tomat has been further developing the complex animation systems for Shiryo. The 1-to-1 involved me assisting by helping to come up with plans for any ‘bugs’ or ‘haults’ he had during his work. He got the solutions he needed and work was able to continue smoothly for the week.
After which, I was able to continue working with the AWS for the majority of the day.
Mid week. We started the day with a comprehensive “design” meeting with a large portion of the game dev team. As a team we discussed and finalized any last minute necessary changes to the “initial” balancing of “basic” 50 card set (after a significant amount of internal testing and analysis) this also included some general needed refinements to some of the element type abilities that were brought to light during this internal testing. Of which the team were all very happy with the outcome of the meeting.
As usual once this was concluded, I continued work with the AWS for the rest of the day.
We’ve also identified 15/25 of the additional cards, we’re aware of a further 20 cards that are ‘suitable’ for the 30 person test, which we’ll be asking input from the community (as we wish them to have some personal involvement in this area of development) to finalize which 10 of those 20 we’ll put in the game likely using the Shiryo DAO or a poll voting system. Once this is done we’ll be expanding on deck creation, as of now we’ve constructed several decks from the basic set, however once we introduce the new cards we’ll have to be sure the decks are well balanced in order for us to be able to collect the highest quality information once testing begins.
Throughout the remainder of the week I’ve been continuing to make progress with our AWS server as touched on at the beginning of this post. Next week all being well we should be ready to test deployment of the servers using direct P2P and testing the basic matchmaking, which allows the game to connect you to the nearest available opponent.
We hope you’ve enjoyed reading this update, next we’ll be answering some of the questions submitted by the community. We intend to work through more questions from the list, for now we’ve selected 6 questions, so please expect more to come from this.
— — — — — — — — — — — — — — — — — — — — —
- “When did the dev team start the process of manually coding the game after the gameplay “theory” had been finalized? As an example: “2nd week of Oct 2022” “
We started coding prototyping for the core systems of the game, (not features) at the end of December 2021 (18 months ago). The core prototype takes a vast amount of time to build due to how large and complex of a system a trading card game is, it’s not as simple as creating something as simple as an FPS where the underlying systems have been tried and tested 100s and thousands of times. Whereas in a TCG, because of the huge amount of systematic variable and automated processes, it required substantial prototyping to get reliability and robustness of so many things interplaying with each other. This involved us creating basically every system from scratch, a huge amount of time is really just figuring out how to get what we want operating robustly. This was about a 6 month process to get to a core framework that we were happy with.
2. “Could you list some(or all) of the additional 25 cards that are being considered for alpha testing?”
As of the moment, our core design development members who themselves are experienced with TCG’s (active players), are in the process of hand-picking and building specific deck types that we believe will give the most fun whilst simultaneously providing us the best information for the first test. We would like to present to the community that they get to choose 10 of the 25 cards.
We’ve narrowed down 15 we’re happy with, we know there’s a range of around 20 more cards that will work well, so we thought we’d ask the community to see what they think the remaining 10 should be. To be clear, we’re quite capable of choosing these outright immediately, however we wanted the community to have some personal involvement in this aspect of development.
3. Have there been specific cards and their ability that have posed an “outsized” challenge to coding for gameplay?
There are some cards that in development and in practice are a challenge to make a game like Shiryo work smoothly, as almost all of the card interactions and systems have to run automatically.
So we have to create generic systems that will not only work with all 225 cards, but all future cards, so we have to essentially boil down what makes a card and its ability into ‘boxes’, so you can run any card that fits within the system. Of course there are always exceptions to a system, you can’t make all systems work for every possibility in a TCG, so because of this you end up with edge case or exception cards and have to manually go through and add exceptions or complete individual pieces to make the cards work within the system.
Because of that some cards are inherently difficult and require significant manual coding to integrate them into these generic systems.
For instance if you look at Gaia the Saviour, it’s ability is an upgraded earth 5, it has poison and it has defender, but even though it has these abilities — it can’t attack until it’s been attacked first. If there’s a card that has defender, other cards have to attack it first before attacking others on the board, however other cards with defender can attack <before> they’ve been attacked.
However Gaia specifically can’t attack until it’s been attacked first. So it needs specific inputs to check if it’s been attacked first before it can become a valid card to attack others with.
4. “Is Shiryo Studio a physical location? Or a theoretical framework for committing the entire gameplay development process “in house” with little to no “out-sourcing?”
Shiryo Studios is a remote network system of individuals from across the world, however a significant group of the development team (including our coders) are located reasonably near each other. The development team specifically will meet up as and when necessary, however Shiryo studios and the core Shiryo team meets in person around once every quarter.
As we upscale with more staff, if needed we’d be happy to acquire a solid physical location.
5. “Describe how blockchain integration has been part of your calculus while developing the Shiryo game. Have there been aspects to gameplay development that have been hindered or stalled because of this?”
Research and testing of how blockchain integration across industry has been imperative to how we’ve gone about integrating blockchain ourselves. Now due to the video game industry having already converged on many systems / ui and UX / and functionalities, integrating the blockchain to work seamlessly and robustly with these expected systems was a higher priority than simply integrating or adding blockchain functionality for the sake of it. A key aspect that we at Shriyo believe is missing from many of the other games and other applications / services that have been released already, is simply the lack of smooth implementation for both crypto and non crypto users (people new in space).
Because of this the way we’ve implemented the blockchain with the priority of making blockchain functionality as seamless and as painless for all of the user base, prioritizing non-crypto familiar folk (given crypto folk are already acquainted with the blockchain). The idea being that playing the game and enjoying Shiryo, requires zero crypto experience whilst still providing advanced and comprehensive crypto and blockchain functionalities for anyone who needs them.
6. Has gameplay development progressed to the extent that you can estimate the time interval from full game release to playing on mobile devices?
It would be irresponsible for me to estimate the timeframe from full release to mobile deployment due to there being so many variables and so many novel challenges (dragons that need to be slayed to get there), and would be irresponsible to realistically put out that time frame until more of that data has been collected. What I can say is it will be significantly faster than the original development because we don’t have to reinvent the wheel, the one-off process work has been completed, so again I can say it would be SIGNIFICANTLY FASTER than the initial. We do want to make it for all common devices (PC / Android / Apple) and we’ll be re-looking whether main consoles will support this kind of game again when the time is appropriate.
We’re aware Playstation has fairly recently released a patent that covers NFT cross-platform use. Though the process of releasing a game on those platforms can be quite arduous, especially with the constant changes in the sentiment of crypto.
