SDK Script First in the Head and Relative Asset Paths

The SDK guidelines contain a line that sounds trivial: "Load https://playkovo.com/sdk/playkovo-sdk.js as the first script in your document head." Another says to keep assets inside the ZIP and use relative paths where possible. Together they describe how a PlayKovo game should be put together. This post explains why the order and the paths matter and how to check your build.

<head>
  <meta charset="utf-8">
  <script src="https://playkovo.com/sdk/playkovo-sdk.js"></script>
  <!-- your other scripts after this -->
</head>

Why first? Your own code is likely to call window.PlayKovoSDK as soon as it runs: to listen for pause, to call init() or to hook the loading screen. If your game script loads before the SDK, those calls run against something that does not exist yet. The guideline is a simple way to guarantee that the object is there before anything touches it.

Notice that the address is absolute and points to PlayKovo, not to a copy in your ZIP. Engine exports and bundlers sometimes move scripts to the end of the body or give them defer or async. Open the final exported HTML and check the order yourself.

The SDK is loaded from PlayKovo's address so that fixes and new features reach every game. A copy in your ZIP would freeze your game at the version you copied. Our post on SDK 1 or SDK 2 explains what happens to games that carry older code.

The other guideline says to keep assets inside the ZIP and use relative paths where possible. A game is served from a PlayKovo address, not from the place where you built it, so any path that assumed another location breaks.

Path style	Works?	Why
assets/player.png	Yes	Resolved against the game's own folder
./assets/player.png	Yes	Same, explicit
/assets/player.png	Usually not	Root-relative: points at the root of the host, not your folder
C:\\Users\\me\\game\\player.png	No	A path on your computer
http://localhost:3000/player.png	No	Your dev server does not exist for players
https://some-cdn.example/player.png	Risky	An outside dependency; the file can vanish, and external calls may be flagged

The root-relative case catches many people. A leading slash is fine on your own domain, but here the game lives in a subfolder, so the file is not found. Set your tool's base path to a relative form (many bundlers have an option for this) before you export.

PlayKovo scans uploaded ZIPs and rejects some content; see what the automated checks do and files that are ignored or rejected. A build that contains everything it needs is easy to check and easy to reproduce. A build that fetches code or data from other servers at runtime is harder to trust, and calls to outside servers can look like trackers; see trackers and network calls.

1. Unzip it into a new folder and open index.html through a plain static server (not your dev server). If anything is missing, you will see it.
2. Open the network panel. Every request should go to your own folder or to the SDK script. Anything else needs a reason.
3. Search the output for localhost, 127.0.0.1 and drive letters. Dev leftovers hide in generated files.
4. Check the case of file names. A path that works on a case-insensitive file system can fail on a server that treats Player.png and player.png as different files.
5. Check the console for failed loads (404) and blocked requests.

Unity, Godot, Construct, GDevelop, Cocos and GameMaker each have their own export settings. Read the guide for your engine, such as Unity WebGL or Godot 4, and then verify the final index.html, since templates can change the script order.

The guidelines are in the SDK guidelines page of the portal.