Welcome to all of you who are following the development of the decentralized version of Playkey!
This week we worked on the algorithm for deploying the Playkey infrastructure on miners’ servers. The infrastructure is what will make the Playkey application run on a miner’s computer. This includes the Linux operating system, the virtual machines (VMs) and the program for managing them, Playkey’s server software, and other auxiliary software.
We’re assuming the following deployment scenario…
● Installing a Linux image on the server: This operating system runs the virtual machine. The VM is the actual virtual computer that you rent for gaming. One server usually runs multiple virtual machines.
● Updating the Playkey software: First the server software will be installed along with the OS image, then the update will run automatically.
● Loading the image of the virtual machine where the games will launch.
● Configuring the components that control the VM’s operation, the user sessions, and the game itself: During configuration, the server is registered with the service, and its operating capacity is checked.
Also this week, we approved a scenario for the miners’ software, which we will implement later. The steps are as follows.
● Update disk snapshots of the virtual machines and games. A snapshot is a template copy for the files, from which each game session will start. Situations could come up where we might need to update a snapshot, for example to update a game or OS settings. These snapshots will be updated automatically.
● Create a clone. For each session, a snapshot is cloned so that gamers can’t accidentally or intentionally ruin a virtual machine and interfere with other players. After the session ends, the clone will be deleted.
● Start the VM. For each session, the VM on which a game is running is turned on. When the VM starts, a component also starts that will capture the game’s video and sound, transfers control, and controls the OS’s operation (connecting disks, launching games, working with game saves, etc.).
● Switch to session standby mode. In this state, the miner’s server is ready to start the game on his hardware. Keeping the miner’s computer “ready to jump into action” is a way to reduce launch time for the player.
● Start the game session. We’ve gone into this in detail in the Developer Log: Week Four.
● Stop the VM. After the session is finished, the VM needs to be stopped to delete the clone that was used and to launch the next session with a “clean” (reference) snapshot clone.
● Delete the clone. So miners will not run out of disk space from the many unneeded copies.
Well then, next week we plan to add gamepad support, and optimize video transmission speed from the virtual machine. Keep following the Log!