We will begin by explaining how games are published and accessed on heyVR along with the additional features provided by heyVR and possible differences from other platforms.
On heyVR, a game project itself is simply a collection of details about your video game. A game project has some informations attached to it such as a name, description, category, thumbnail, some tags and so on. A game project itself is not playable (also not publicly visible) unless there is a build (html, js, css, bin, wasm...) attached to it. We call this a Game Build.
Remember, a game is not publicly visible unless there is a build attached to it. These files will be reviewed by the administrators before they're publicly accessible.
As mentioned above, a game needs a series of files to be playable. We'll call these files that are uploaded by developer the Game Build. Once you create a game project, you can upload a zip archive that contains the files for this game.
To check the requirements for a game build, check out the Requirements section.
Why would you bother with all the build upload when you can simply upload a zip file once and be done?
Why: Versioning.
Each game build will be semantically versioned. Developers can test the game before submitting it for review, allowing them to catch any potential issue. This also gives you access to all of your previously uploaded builds.
This approach also fixes any caching issues, removing the need for other anti-caching measures.
For more information about versioning, check Semantic Versioning's website or the Software Versioning page on Wikipedia.
We do not use an actual version control system, we rather use the build's version as a tag. Here's how:
Let's assume you have a game named MyGame. Your game will be assigned a dedicated directory with a randomly generated name. This directory will include everything you upload for this game.
Now let's assume you just uploaded your first game build. A new sub-directory will be assigned to your game build and it also has a randomly generated name. This is to prevent caching problems.
So for example, your fancy build's final directory will be something like the following:
/j1k8znqpl4/tl4x/
The content of your uploaded build will sit at the root of this directory, meaning that /j1k8znqpl4/tl4x/index.html will resolve to your game's index.html file.
Now you've found a bug in your game and decided to patch it. You upload a new build, which will be deployed to a new directory:
/j1k8znqpl4/n1ql/
Again, the new directory will hold your new build's files and not connected to your previous version in any way.
Remember, the games will share server-side data, such as leaderboard data. This is not related to the game files and will be available to all the game builds.
Since the games on heyVR are web games, it means they will include web-related files (such as HTML, JavaScript, CSS and so on). heyVR loads each game inside an iframe element. This ensures that your game is isolated from the website itself.
In our previous example, the game page will include an iframe element that looks like the following:
<iframe
src="https://games.heyvr.io/j1k8znqpl4/n1ql"
data-sdk-urls="..."
data-game-slug="mygame">
</iframe>
Which will automatically load the index.html file at the root of your active build.
Did
"data-sdk-urls"catch your attention? That's because on heyVR each game is provided with an exclusive SDK. You can use this SDK to manage leaderboards, inventory and more. To learn more, head over to our Gameplay SDK Documentation
If you're publishing a game for the first time, here's what the overall flow will look like:
For an existing game, the flow will be almost identical, starting from 'Upload New Build'.