Playkey DevLog. Issue Twenty Nine. Plans for 2019–2020!
Hello, Merry Christmass and Happy New Year! In this year’s last issue we share the quarterly plan 2019 and even some groundwork for 2020!
Cryptocurrencies in the outgoing year give it hot and throw in the cold. If the stress level was measured by thermometers, they would have exploded long ago. Building plans for 2019, we have taken into account the disgrace with the course. The fall of all major cryptocurrencies means that in order to implement a decentralized platform, we need to increase the revenue of the current version of Playkey. This will provide additional capital for marketing and ecosystem development.
For the first two quarters of the next year we plan to develop European expansion in 2018 and bring the number of paying users exclusively from Europe to 30000 per month. The time of the game for the user at the same time will reach 400 minutes per month — this will be a good indicator of the relevance and stability of the service.
At the same time, the decentralization team will continue to address technical challenges for the platform. For Q1 2019, we plan to develop a new method for capturing a picture and a new way to display the cursor.
With the new capture, we will take the frames directly from the game, without “intermediaries”. Now for the capture we use Desktop Window Manager (DWM). The frames are requested from the server OS, which sends them with a delay. As a result, the seizure may lag behind the game. This is especially noticeable on medium power servers, which is unacceptable for a decentralized ecosystem with its endless “zoo” of devices. In order for miners to provide a high quality of games and earn money, we must provide them with the appropriate technology. In the new capture frames are transmitted directly to the client application, which significantly reduces the time to transfer the picture.
The situation is similar with the cursor. Now a simple mouse movement starts the infernal chain of events:
1. The Playkey client application captures the cursor coordinates and sends them to the server;
2. The server side of Playkey (desktop) emulates input, which is then processed by the OS and the game;
3. The server side of Playkey (desktop) waits until the OS returns the next frame, draws a cursor on it and encodes it;
4. Finally, the data is sent back to the client application, decoded and displayed to the player.
On such a long path lags will inevitably arise. To get rid of them and shorten the path, we will draw the cursor locally in the client application. This will eliminate the delay between the mouse movement and the cursor display.
A detailed plan for 2019 is presented below. For the convenience of perception, on the infographics it is indicated how tasks were decomposed quarterly, what and where was added. See you next year!
