Playkey DevLog. Issue Twelve
Hi, everyone! The week’s main event: We wrote two smart contracts for accepting payment in PKT for the current version of Playkey. For details about paying for subscriptions with tokens, see Issue 9 and a separate article.
Accepting PKT
The first smart contract (see contract #1 on GitHub) supports publishing unique smart contracts on the Ethereum network. Users will be able to send PKT to those contracts. The second smart contract (see contract #2 on GitHub) is a unique smart contract for each player. The contract accepts PKT to pay for subscriptions. To start accepting PKT, we just need to:
● Improve the database to keep track of the user’s PKT balance
● Create a new service that provides:
○ Monitoring inbound transactions to the address
○ Publishing new smart contracts that can receive PKT from users and verify that the smart contract was registered on blockchain
○ Collecting PKT from these contracts
● Add address generation for PKT payments to the website
● Add PKT to the payment option interface and implement the corresponding functionality
● Implement a method for calculating subscription costs in user currency, based on the current PKT exchange rate
● Test everything thoroughly (loyal readers have undoubtedly noticed how much we love tests)
We plan to do all this by the end of May. PKT is soon going to be used in an actual product.
Conquering the Desktop
At the same time, a team led by Alexey Pronichev will complete development on a project under the code name of Desktop. This week, we began closed internal beta-testing. Desktop is a fundamentally new functionality for our platform and is vital for launching a decentralized solution.
The current version of Playkey works at the game level. It takes over the process and isolates it from the system, intercepting system function calls (WinAPI). There are more than 1,000 of those calls, by the way. This kind of architecture, however, is difficult and costly to support. In particular, there are often errors when connecting new games. For example, a recent case with Far Cry 5: everything was working fine except for being able to control transport from the keyboard. Searching for one problematic function call is like that old story of the needle and the haystack. It’s a problem even now, while the platform is still centralized. For decentralized architecture, this approach would be a dead end. Miners would have to ensure that their systems work properly, and those systems would inevitably fail once in a while.
And this is where Desktop comes in. In this approach, we take over the entire system instead of just a game. That is to say, the entire desktop. We provide the game and the user with full access to the booted-up system (VM). After the game, we return it to its original state. That architecture provides a simpler, more reliable way of streaming games and a new level of service security. When servers are in a protected data center, upholding security protocols takes less effort and fewer solutions. In the decentralized platform, software is installed on miners’ computers, including computers in a domestic setting. In the new implementation, if the player installs any malware, it’ll be removed the next time it launches.
Anti-cheat problems also can be solved with architecture. One of the most important and complex questions when including new games on the streaming service is the interaction with the software that protects players from cheats. Many anti-cheats by default take our software’s attempts to intercept data flows for streaming to be interference with the game code and interrupt its operation. We are now working with the largest anti-cheat providers, and our platform is listed on their “white lists,” which means that the anti-cheats recognize Playkey and don’t react to it. But one of the conditions of this cooperation is the absence of third-party access to game files. In a decentralized platform, it would be difficult to meet this condition. But when we take over the entire desktop, anti-cheats don’t trigger because nothing is happening at the game level.
All these improvements are part of the Playkey infrastructure. They are necessary to support decentralization. At the same time, any changes to the client Playkey app itself, which the player installs once on their computer to use the platform, aren’t required. The current version of the client app works the same in both centralized and decentralized versions. This saves months of development work. On this high note, we bid you farewell until the next issue. The next two weeks will surely fly by.
For more details visit Playkey.io.
Stay tuned, share opinion and ask any question regarding Playkey in our:
