How to monetize your games using Virtual Goods
In this tutorial, we’re going to look at how to create and use Virtual Goods (VGs) in order to be able to monetize our HTML5 games with in-app purchases.
To do this, we’ll take a look at the possibilities WiMi5 offers for making in-app purchases and we’ll show you a basic example in which we’ll create different virtual goods.
Creation of Virtual Goods
The first thing you have to do is decide what you want to sell. You could say anything could be sold. Here are a few examples:
- Extra levels.
- Objects that improve the gaming experience (more powerful weapons or armor, immunity, an extra power…)
- Consumable objects that give one-time advantages in the game (bombs, extra lives, jewels/coins, etc.).
- Donations to the developer.
- And more!
Once you’ve decided what elements you wish to monetize in your game, you need to create the virtual goods in your project. Use the dashboard tool for managing virtual goods.
To get to this tool, you need to go to the settings of the project you’re working on (gear icon > settings). Inside the project settings, select the virtual goods tab:
In the lower right-hand corner, you’ll find the button that allows you to create new Virtual Goods to the current version of the project. Later, we’ll explain how to manage versions and how they affect virtual goods. When a new Virtual Good is created, a line will appear in the list of Virtual Goods:
In the image, you can see the basic properties that can be changed for each virtual good you create:
- The icon for the Virtual Good. This is the icon that will appear in the shopping cart. Clicking on it will let us choose an image from our image repository.
- The name of the virtual good. This name is internal and will not be shown in the shopping cart. It serves to identify the virtual good in the project and must be unique in each project. It affects all the versions of the Virtual Good.
- The price at which you wish to sell the virtual good. A price change will only affect the current version of the virtual good.
- Visible in cart. This checkbox allows us to choose whether the virtual good is or is not visible in the shopping cart. This is useful for when we would like to launch a promotion or to stop selling a virtual good.
- Delete button. Only available if there are no other versions of the virtual good.
- Extra options. Clicking on this button will open up a series of further properties for the virtual good:
- Promotional name. This is the name of the virtual good as it will appear in the shopping cart.
- Promotional description. This is the description of the virtual good as it will appear in the shopping cart.
- This indicates that the product can be consumed, subtracting one from the available amount. This is the typical case for extra lives, coins, timed immunity, bombs, etc. A non-consumable virtual good would be one that once it’s purchased, it’s always available. For example, an extra level, a unique object, or some special ability acquired by the character.
- Max instances to buy. This is the maximum number of times a virtual good can be bought in the whole life of the game. This can be used mainly to limit the purchasing power of a virtual good that could make the game too easy. For example, imagine you sell “nuclear bombs”. If you allow too many to be sold, it could make the game too easy. This value cannot be greater than that set for the next point.
- Max instances to have. This is the maximum number of times a player can have a virtual good at any one time.
Versions of Virtual Goods
In order to publish the game to Labs, the Chrome Web Store, etc., first you have to create a version of the game. This is done in the game editor using the menu option tools > deploy. Clicking that option will generate a version of the game with a specific identifier, and a version of each of the virtual goods contained in the game at that moment will be created. That way, a virtual good can have different versions, where each version is a setting of that virtual good for that specific deployment.
The purpose of the versioning of virtual goods is to allow you to be able to modify some of the properties of a virtual good, such as the price or whether it’s visible in the shopping cart, for a specific version of the game. For example, we could have version 0.1.10 of the game published in the Chrome Web Store and be working on version 0.1.20 and change the price of the virtual goods in version 0.1.10 for the sake of a promotion in the Chrome Web Store.
You can make these changes in the virtual goods control panel on the dashboard. If you have any generated versions, the following drop-down will appear in the lower part:
When you select a version, you’ll see how each of the virtual goods is configured in that specific version:
All the properties of a virtual good can be changed, except the consumable field, which must be set before creating the first version of the VG.
Whenever any of the properties of a VG is modified, the buttons Apply and Discard will appear; they will simply make the changes permanent or will ignore them, respectively.
Working with Virtual Goods
Once the Virtual Goods have been created in the dashboard, you can start using them in the editor. To do so, select the Virtual Goods option in the selector of any panel:
Once you’ve clicked on it, you’ll see the VGs that have been created from the dashboard and some of their properties:
In addition to the image and the name of the virtual good, each of the icons indicates:
- Battery: Consumable or Not Consumable
- Shopping cart: Whether it’s visible there or not.
- Infinity symbol: Maximum number of instances the virtual good can be had.
- Current instances: This value serves to simulate the number of instance you have to use when previewing the game. We can change it during the execution of the preview, and upon stopping, the game will go back to the value that it had just before pushing the play This allows you to simulate different states of virtual goods, as well as purchases and times consumed.
In order to use virtual goods within the game, you have a series of blackboxes grouped under the Virtual Goods category available:
You have four different blackboxes available to manage the virtual goods within the game:
- ShowShoppingCart: this shows the shopping cart and notifies, via the closed output, the closure of the shopping cart. It also notifies that the cart has been shown. In the editor, when the preview is run, a simulation of the shopping cart will be shown and in the final game (once you’ve clicked on deploy + test/publish), the definitive cart will be seen.
- GetVirtualGoodAmount. This gets the amount that the user has of a specific virtual good, leaving the number-type value in the amount output parameter. The done connector will be triggered when the value is available. In the case that the player hasn’t started a session or there’s been any other type of error in the petition, the error output will be triggered.
- ConsumeVirtualGood. This consumes the number of instances specified in the outlay input parameter of the virtual good indicated in the virtualGood parameter, and returns the number of units the player has left in the amountLeft output parameter. Four different output connectors can be triggered by running this blackbox, depending on the result of the operation. Done is triggered when the consumable has been consumed correctly. If the notEnough connector is triggered, the operation of consuming could not be done because the player doesn’t have a large enough amount of the virtual good. In both cases, when these outputs are triggered, the amountLeft output parameter is available. Just like with the first blackbox, the error output is triggered if the player hasn’t logged in or there’s been any other type of error in the petition.
- VirtualGoodListener. This blackbox has two states, active and inactive. To activate it, you have to run the on input connector. Once it’s activated, it listens to all the changes in amount of a specified virtual good in the virtualGood input parameter. When a change is detected (consumed or purchased) in that virtual good, the updated output connector is triggered, saving the updated number of instances of that virtual good in the remaningAmount
As you can see, in some of the platform’s blackboxes (in addition to GetVirtualAmount and ConsumeVirtualGood), there is the onPrevious output connector. This connector appears in asynchronous blackboxes (more on that later) and in the blackboxes that have the secure setup parameter available:
The secure property is used to avoid overlapping several operations on one VG. If you set secure to true, this means that you don’t want to start a new operation until the previous one has finished. If this happened, the onPrevious output connector would be activated.
This can happen if we make two consecutive petitions very quickly. If secure is false, then all the petitions will be carried out regardless of whether or not there has been a reply to the previous petition.
Note: an asynchronous blackbox is one whose output connectors are not run instantaneously but rather at some undetermined moment. These blackboxes are marked with a blue triangle in the upper left corner of the blackbox, and the asynchronous connectors are also blue. Their connections with other blackboxes are discontinuous.
A Practical Case
To illustrate the use of virtual goods, we’re going to create a small practical example. In the example, this is how we want to monetize:
- The player can buy a t-shirt. This shirt can be bought only once.
- There is a second blocked level, which can be unblocked when purchased.
- The player can buy paint bombs to mark his enemies, though he can never have more than three bombs available.
So we create the 3 virtual goods as follows:
As can be seen in the image, the settings for the virtual good called level and those for the t-shirt are exactly the same. These two virtual goods are not consumable, and can only be had one time each. On the other hand, the paintBomb goods are consumable, but we’ve limited their maximum number of instances to three. The number that can be bought is unlimited, which means we leave open the door to buy more when we’ve consumed the ones we have.
The game begins with a scene to select the level by pressing the corresponding buttons, and another that opens up the shopping cart:
When you enter the game, the scene is activated by default and we’ll create the following script:
- The first thing we should do when running the game is assign the behaviors to the buttons (sprites) using the SpriteAsButton We need to establish the disabling animation (OnDisableAnim) for the second level’s button, to which we’ve assigned an animation frame with a padlock indicating that this level is blocked. With this, we initialize the buttons for level 1 with the activate input and the level 2 one with the disable input. We’ve created a Level called “play”, which is in charge of managing the game itself starting once we’ve passed through a scene. When we press one of the buttons, we’ll copy a reference to the scene we want to load to a Scene-type input parameter we’ve created in this “play” Level.
- Next, we’ll ask about the Level 2 virtual good, and if we have purchased one instance of it in this case, we’ll enable the button that allows access to the second level. We will also activate the VirtualGoodListener blackbox which will notify us of any changes with the Level 2 virtual good. You need to keep in mind that for the comparison to be carried out correctly, the amount variable used as a parameter in the three blackboxes has to be the same.
- When you click on the shopping cart button, you’ll open a shopping cart using the ShowShoppingCart
The game basically listens for the B key to be pressed, and when it is, if any paint bombs are available, it runs the explosion animation on the one bureaucrat (2) that there is on screen. It also reports the number of bombs available via a text (1) and it gives the option to get out the shopping cart to make another purchase (4). If the player has already bought the t-shirt, the character (3) will be shown with a t-shirt that is different to the default one.
The script that handles this game logic is the following:
- In this part, we’ll create a button to show the shopping cart, exactly the same as in the previous level.
- We need to ask, at the beginning (GetVirtualAmount), for the number of bombs available in order to show them to the player via on-screen text. We’ll also be listening for changes in the number of bombs the player has (VirtualGoodListener).
- We also need to do the same for the player’s t-shirt, asking if she has it and subscribing to changes in the amount. We could also have done this last one in the unique case that the reply to the GetVirtualGoodAmount blackbox were 0, but for the sake of clarity of the script, it’s been done this way. Should we have a t-shirt available, we’ll make the t-shirt visible on the character, and should we not have it, we’ll make the default t-shirt visible (note that the bit about making the default t-shirt visible we could have saved by establishing the default shirt in the editor, but is always a good idea to initialize the elements within the scene).
- We add a KeyListener in order to listen for presses of the B key. Should it be pressed, we’ll check to see if there are any bombs available, and if we get an affirmative, we’ll tell the bomb to be consumed and we’ll trigger the explosion animation.
The second level will be nothing more than the same scene with a different background. We can create a shared Layer between both scenes to place all the common elements (character, marker, buttons, etc.) and thereby make the script logic much simpler.
In the dashboard, there is a tool for keeping control of the income generated by the games that use virtual goods. To use this tool, we have to have a game which uses virtual goods and which has been published (which has been deployed in the editor). To see the virtual goods’ statistics, you need to go to the project’s settings in the dashboard and choose the virtual goods tab in the statistics section.
You’ll find in this tab a list of all the virtual goods that the project contains and the income they have produced:
- Sold Items: this is the number of virtual goods that have been sold.
- Revenue: this is the total income generated by this virtual good.
- Profit: each of the publication platforms has its own rules and commissions on the sales generated by the apps. This value indicated the final profit for the user on the sale of that virtual good. You must keep in mind that this number is approximate.
There’s also a date selector that allows you to see the income generated by the virtual goods in different periods of time:14/04/2015 / No Comments
- How to Integrate a Game into Your Website
- How to integrate a WiMi5 game in Moodle
- How to create texts from sprites using a SpriteText Blackbox
- How to clone a project
- New ways of interacting in wimi5
- How to easily adapt WiMi5 game templates to create your own games
- How to monetize your games using Virtual Goods
- How to use the CodeRunner blackbox
- How to use Game Session Storage
- How to Use Rankings
- How to publish your HTML5 game to other game platforms
- How to publish your HTML5 game on the Google Chrome Web Store
- How to set up game levels based on data from a text file: using the ParamMap.
- How to create a scoreboard for lives, time, and points
- How to Make a Scroll and a Parallax Scroll in 2D Games
- How to create collisions
- How to debug in WiMi5