Continuing from last week’s update, which concluded with Me beginning to iteratively add the“proven base functionality” in “Shiryo_Core” into the latest build of Shiryo. The first stage of implementation was to break apart each high-level “function” and to figure out where in Shiryo’s game framework that function belongs. I personally use a “bottom-up” process so that’s where I start.
The first stage in the process is “On opening the game” and opens the “On_Entry_Map”
The first “Server” implementation is for the player to be able to “create an account” / “Login”. This involves communicating with the secure “Portal” and is the interface between the Game Client, Database, Socials (adding friends, inviting to game…etc), and the Blockchain. When a new player creates an account, this process creates a secure location to hold the player’s relevant “Game” information that needs to persist after they have logged out or closed the game client. Information such as their NFT collection, Story Progress, Decks built, Game stats (Wins losses… etc) Events entered…..etc.
As well as this, the portal is responsible for interfacing with the blockchain, authentication, the creation and allocation of a default Shiryo wallet, the importation of a player’s pre-existing wallet, managing play to earn functions, the wagering of cards…etc)
With all of this, security is paramount. This is why all of this functionality is not held on the game client itself but is the responsibility of the portal. This ensures that we do not need to validate the whole engine itself and instead use the worlds converged upon, tried, and tested security methods used by the leading Dapps in today’s crypto space.
The Portal is being diligently worked on as we speak by our Dapp engineers, and while it would be great to share with you all this functionality in the (30PersonAlphaTest), I have decided to hold off on its inclusion to tunnel in on expediting the (30PersonAlphaTest).
The second stage “Post_Login_Success” opens “Main_Menu_Map”.
From here the player can navigate through all the available UI, Options, and Gamemodes. We will focus here on the player selecting through the UI to the Verses (Friendly) button and the functions this button executes.
The desired result when the player presses this button is to “Search” for an available game and then “Join”. Now, this is obviously more involved than that sentence would indicate, but the majority of my time this week has been spent creating and testing the system that handles the variety of “conditions” of this process. Such as. Are there any game sessions available in the player’s server region?, if there is, are any actually ready (1of2 players) and available to join? Are any of those sessions suitable for that player (SBMM — Skill-based matchmaking)…. The list goes on.
Due to the (30PersonAlphaTest), I have reduced the necessary functionality down to the bare essentials and have made my way through the majority of them. I am happy to say that, barring any unexpected holdups, I believe I should have a minimal AWS deployed multiplayer system, operating in the next few days. This will still require 1st order stress testing and additional work to ensure it is robust enough and a whole other list of preferential steps before I would be comfortable releasing it out into the wild. But I am personally rather excited about next week.
Until then I hope this behind-the-scenes peek, portrays to you some interesting perspectives and the vision that we the developers are trying to create with Shiryo.