Playkey DevLog. Issue Fourteen

We hope you’re having a warm and wonderful spring so far. For us, May has been governed by PKT. As you recall, the token will soon be used in a live working project. You’ll be able to use PKT to buy a subscription for the Playkey.net cloud gaming service. In the previous two weeks since our last issue, we’ve gotten four steps closer to start accepting PKT.

Buy It with PKT

Step 1. We finalized a feature that publishes smart contracts on the Ethereum network. Users can send tokens to those smart contracts. A special service monitors the number of addresses. If there aren’t enough available addresses in the database, the service will publish new ones and record them in the database.

Step 2. We’re now able to monitor whether a contract has been successfully published on blockchain. This is important since we can’t distribute wallet addresses to users to pay for subscriptions before the contract has been published on blockchain.

Step 3. Vladimir Kosov’s team implemented user accounts in PKT in the Playkey.net testing zone so that players can see how many tokens they have remaining. On our test servers, a PKT payment option has already appeared as an alternative to the usual bank card.

Step 4. We also configured automatic assembly and deployment for a service that will accept PKT. This will ensure automatic deployment of the new service on production servers, which will allow us to avoid mistakes that could happen if it were done manually.

Work-in-progress screenshot.

Onward to Decentralization

We’ve at last completed work on uploading saves after a game has been completed. Because of the new architecture, we had to revise how we process files. In the decentralized version, we don’t see all the files that the game writes to the disk of the virtual machine. Therefore, the uploading is done using a “white list” approach. This means that only files that need to be saved are processed. In the centralized version, the opposite “black list” approach is used. Black-list files are excluded from processing while all other files created by the game are saved.

We also improved sending user logs to a single repository. In the current centralized version, logs are saved on the game servers. In the decentralized version, that approach isn’t possible since the virtual machines roll back to their initial state after each session, and the logs are deleted.

Just a video for attraction of attention

In the meantime, testing and configuring the server side is going according to plan under the code name Desktop (remember that this is a key part of the decentralized version of Playkey). Here are examples of problems that we’ve solved in the past two weeks: a disappearing image in Overwatch, a game server error when restarting, slow disk performance, improper client shutdown when the server is disconnected. And most importantly, we found an elegant solution to the video card problem.

Do you remember the problem with desktop video cards that we told you about in the last issue? A black screen would be displayed instead of the game without a monitor connected to the video output. We solved this by putting a stub in the video output. It’s quick, inexpensive, and effective. We’ll continue looking for a software solution later, but for now we can move forward.

Catch up on our newest achievements and daring know-how in the next issue!

For more details visit Playkey.io.

Stay tuned, share opinion and ask any question regarding Playkey in our: