# action 701 indie 638 adventure 601 singleplayer 336 rpg 296 multiplayer 277 fantasy 198 strategy 196 story 193 sci-fi 178 platformer 178 co-op 173 puzzle 172 atmospheric 157 shooter 156 casual 154 simulation 117 role-playing 109 horror 109 survival 108 dark 105 arcade 93 open world 92 funny 85 2d 81 space 81 anime 73 fps 70 stealth 68 mystery 66

API for Playable Browser Version

Before you start reading into the API documentation, I would like to briefly explain, why your game needs a playable browser version, even if it is an AAA title or hypercasual game. The answer is Marketing! Instant experience is already popular on Google Play and many messengers, and is the reason why browser games still retain popularity. While mobile games with their low size builds can make a full browser version for their apps, PC and Console games can successfully develop playable browser demo-versions, to attract potential customers. Screenshots and videos will not have as big impact on decision nowadays as playable demo could. This might be a single playable level, or even an entire game. Besides that, you can and should use our authorization and payment API, to detect internal user id and save his progress and to sell your content from inside your browser version. As you can see in the iframe above, you can sell in-app currency, access to full content, extra levels, or even physical items, it depends on your creativity and goals.

Integrity guideline

First of all, we would like to keep Play Best Games clean and beautiful and retain similar user experience across all the apps. This means your playable version:
  • Should NOT have 3rd party website attributes, e.g. header/footer/login or payment system.
  • Should NOT have any ads, concentrate on promoting your own content.
  • Should correctly authorize logged in users, while still remain playable for guests as well.
  • Should be hosted on your own domain with a unique path containing PBG build.
  • Should only use our payment solution.
  • Should be adaptive to PBG container sizes.

Authorization process

Authorization is done purely on client-side. We are using javascript to communicate between iframe and parent. Your app should send a postmessage to parent, and expect a repsonse with a "message" event listener. If a user is not logged-in, this function will open a login window.
//javascript

//function that sends a post message to parent page should have 2 arguments - object with user: 'request' pair and document.refferer as event.target.

function requestUser() {
	parent.postMessage(
	{
		user: 'request',
	},
	document.referrer);	
};

//event listener for incoming messages and the callback function

if (window.addEventListener) {
	window.addEventListener("message", useridMessage);
} else {
	window.attachEvent("onmessage", useridMessage);
};

//your iframe might receive lots of messages from various sources, make sure to validate that event.origin is same as parent domain & event.data.user is not null.


function useridMessage(event) {
	var m = event.data;	
	if(event.origin == getHostName(document.referrer) && m.user != null) {
	user.innerHTML = m.user;
	}
}

//helper function to extract domain name with scheme from current document.referrer url.

function getHostName(url) {
    var match = url.match(/(https:\/\/)[a-z0-9.\-]+(\/)/i);
    if (match != null) {
	m = match[0].slice(0, -1);
    return m;
    }
    else {
        return null;
    }
}
After you receive the user id, code your own solution to load user progress from your database or save the user profile id to your base, if it is not there yet. If user wasn't logged in, authorization screen will popup and a page will be reloaded upon login or authorization.

Payment Processing

Payment processing involves both server-side and client-side code. Again you start with a postmessage to parent, parent page will open a new iframe with a payment page and pass the data you sent to it. End user, will see his balance, the item he is purchasing and options to buy additional currency if he needs it to complete purchase.
//javascript

//function that has two arguments - object with amount (should be integer) and title (string) and document.referrer as event.target.

function startPayment() {
	parent.postMessage(
	{
		amount: amount,
		title: title,
	},
	document.referrer);
}
We will send a POST request to your callback url, which you set up on game page, if you respond with a code 200, user's currency will be transfered to game authors account. Besides, you should validate our POST request by calculating sha1 hash from a string explained below, here is how:
//php

//add a secret word to your user profile and use it to validate our POST request on your server.

$secret = 'XXXXXXXXXX';

//Build a string which will look contain userid, game, title, amount and secret separated by & and calculate sha1 hash of that string.

$validity  = strip_tags($request['userid']);
$validity .= '&'.strip_tags($request['game']);
$validity .= '&'.strip_tags($request['title']);
$validity .= '&'.strip_tags($request['amount']);
$validity .= '&'.$secret;
$shalocal = sha1($validity);

//if your calculated string is equal to sha from request - the request is valid, add purchased item to user account.

if ($shalocal === $request['sha']) {
//your code
} else {
//your code
};

If a purchase button is clicked, there are few scenarios:
  • User gets error if he doesn't have enough currency to complete purchase
  • User gets error if the payment page was called not from the game page on this site.
  • User gets error if your server response code is not 200, balance not affected.
  • User gets a success message if your response code is 200, currency transferred, purchased item should be added.

Container Details

There are few notes, that you should consider before creating a playable browser version about the container.
  • If your frame link ends with an .swf, embed will be created instead of iframe.
  • If exists - Iframe/Embed replaces video and screenshots container.
  • The above only happens on desktop, mobile users will still see video and screenshots always.
  • Iframe/Embed maximum dimensions might be 1600x740 px, minimum dimensions might be 1024x670 px.
  • Iframe/Embed will have fixed 670px height at screens with up to 1649px width.
  • Iframe/Embed will have fixed 740px height at screens starting from 1650px width.

Revenue Share

At this point to keep website running, we are offering an exchange rate of 140G into 1$, payouts starting from 14000G, which are 100$. Payouts currently done to Yandex Money Wallets. Exchange rate might change when website reaches notable scale, also we will eventually add more payment methods. You can contact me in any social network or via email at [email protected]