Hi, Rick here, (Lead UE4 Developer working on Shiryo)
I heard the community were wanting an update with regards to where we are at with the development of Shiryo, and so here I am to give you all a peek at the back end of what we’ve been up to.
In terms of completion of the overall code base, the main bulk of the system operational code has been completed, (by system operational code I mean the stuff that makes the game go brrr, so a loose breakdown of that would include things like.
User Entry Point Code – So menu systems, login, card collection, dashboard and news, settings menus and associated functionality
Game Play Environment – So from the board environment itself, the layout, UI/UX , visual indicators such as the energy and elemental systems, this also includes the card manipulation systems (cards in the hand and the players manipulation of those cards) as well as animation events.
Gameplay Mechanics – Now this includes the system of logic that processes how the game actually plays so, player turn operation, card selection authority, energy and elemental allocations, card spawning / destruction, all sorts of card transformations, attack phase systems, attack sequence and selection, graveyard system, player health and the end game conditions.
Framework Systems – Server authority management and player management, this Includes things like allocations, so spawning cards to either the players hand or to the board, energy and elemental values, player health, graveyard and end game conditions, including all things that the player needs either restricted or supervised access to.
Now due to needing to stay within the safety constraints, as well as targeting the desired design/user experience that we are striving towards, a significant amount of prototyping and testing is required for each and every game system / manager / function that we implement, to ensure that we will achieve the expected safety and design functions we envision. This is obviously time intensive but hugely necessary to ensure that Shiryo is as fun and issue free as we expect it to be when launched.
Issues & Previously Overcome Hurdles….
One of the more prominent issues that cropped up, which to be fair was hiding in plain sight, was the player dimension/space perspective issue.
You see:
When 2 players start a match, they both join the same game server “space” and are each allocated a player “camera”. This is the players viewpoint and dictates what the player sees and interacts with. (This includes things like the game board, the environment, hud, ui/ux and so forth).
Naturally, prototyping the game environment would mirror how an individual might play Shiryo in real life, with two players facing each other across the game board. This simple yet instinctive setup is how the “white boxing” (using primitive shapes and geometry to quickly get a rough prototype of the environment and layout) went along.
Now the keen eyed among you may have noticed a discrepancy between how the real world version and how the video game version of Shiryo would play. This would be seen in our previews of Shiryo or in other games such as Hearthstone, the 2 players aren’t mirrored how they would be if they were playing in person, instead there is a sort of shared space, as if both players are simultaneously in the same seat. (You can see the orientation of the cards, energy, text, elemental icons… are all prioritising a single view point for 1 player.)
During development this went unnoticed as the general systems and functionality took shape as small modular pieces of code (similar to if you were required to first make each lego block before you had enough to start assembling the whole lego set) and it wasn’t until enough of the “lego pieces’ ‘had been assembled within the engine with the associated Shiryo art assets, that this oversight became apparent.
So how do you make both players the viewing priority? Well, essentially by making both players occupy the same environmental space but operate in different dimensions.
Both players simultaneously occupy the same spatial position within the game, but visually are only shown their individual version of Shiryo. This also allows us to stay within the security framework by only representing the need to know information for each player within their own visual dimension space.
It may seem convoluted but by doing this we would be able to achieve our design and user experience requirements, while also being within the security framework as each player’s own dimension of the board is run solely on their own client, thus keeping the “need to know” information and functional code isolated solely running within the authoritative game server.
As Development Continues
Over the next few weeks I will be testing, tweaking and finalising many of the remaining loose ends of feature code that will bring us to the point of closed beta testing, while code feature review, additional testing and the second run through review of art / animations will give us the perspective to polish and finalise the overall art style and fundamental functional game play of Shiryo to the beta production level.
This is turning out to be an incredibly challenging yet hugely rewarding passion project and I can’t wait until you’re all testing, playing and feeding back information to us. The team as a whole would like to thank our loyal community for sticking by us (especially in these market conditions), your patience will be rewarded when you’re playing what we believe will be one of the highest quality games on the blockchain!
Thank you, Rick.
