Download and open .unitypackage of the latest release.
We highly appreciate your feedback on any issues including (and not limited or course) documentation. Event the tighniest of typo will be happily addressed by our team.
After you get plugin files into your project you need to add initialization call.
GameBoostSDK.Initialize(APIKey);
It's strongly recommended to put this call as early as possible, i.e. right on your splash screen. Fancy that! In fact, we make our best to make sure your game isn't affected by our library. We use background threads, but keep their number short. We reuse TCP connections, relentlessly cache and do only what absolutely necessary.
Please do not hesitate to file an issue if your game performance is barbarously affected by this SDK.
If you're about to ask some help, please run your game with this line on and attach the logs.
GameBoostSDK.SetLoggingEnabled(true);
If you use #defines, flags or settings to detect development build call the following method as soon as you have detected that this flag, setting or #define is on.
GameBoostSDK.MarkAsDevelopment();
If you use development menu (e.g. 10 taps on left top corner) call this method as soon as this menu is open.
Note: It's safe to call it as many times as you need. It remembers the state inside and converts any subsequent calls after the first one to NoOp
SDK is trying to determine if the app running is a development build. I.e. a build which is run by a developer or a QA specialist. Although this kind of detection can't be done with 100% accuracy, the SDK does its best to achieve the result.
If you're interested in this value you can subscribe to an event that is fired when the SDK updates the value.
GameBoostSDK.Events.sandboxStatus += OnSandboxStatus;
Be aware:
- Detection could involve network calls. In that case the event could be called at any point after the app launch.
- Detection could happen several times per application launch. Expect the event could be fired multiple times as well.
- Consider subscribing to event before calling
Initialize. Some platforms fire the event during initialization.
SDK provides API to track revenue. SDK splits revenue into two big categories: in-app purchases and everything else. Everything else here is usually just ad clicks or views.
GameBoostSDK.TrackPurchase(1.99, "EUR", transactionId);
transactionId here is a unique identifier for a purchase. On iOS it's called Transaction ID, on Android it's called Order ID. Providing it helps SDK to deduplicate revenue events. It's highly recommended to provide such an ID generated by OS. If you don't have access to such an ID it's better to omit this parameter rather than send any custom id.
GameBoostSDK.TrackRevenue(0.01, "BYN");
As the very first thing you need to send any game related event you need to create IGame object.
IGame game = GameBoostSDK.CreateGame(balance);
This object will create a key for the given balance object. It's recommended to create only one such object for the whole application launch. Balance object should contain all information about game balance. Therefore it tents to be very big (some megabytes) and creating a key for it can take too much time (hundreds of milliseconds) to call it inside normal game loop.
balance is a Data Object the contains all global game design information about the game.
{
"data": {
"weaponData": {/* weapon json data */},
"enemiesData": {/* enemies data */},
... etc ...
}
}
There's no any requirements or restrictions to a format or structure of the data in this object. However, please concider the following recommendations:
- Rule number one is: do not modify the data. That is, put different files, table rows, etc. in exact way as you read them. If you have some JSON file to describe your room or just a part of the room (e.g. a certain trap in the room) it's recommended to just put it to this data object as is
- Be consistent in the data structures. do not modify, if possible, the data object for a given room if the room didn't change. However if you really have changed the format of files rule number one takes precedence.
- Assume some spare levels in JSON tree for files format modifications. Even if you have only one JSON describing the room, it's recommended to put it in the first or second tree level, e.g:
{
"files": {
"mainXML": ... /* actual data from that XML */
}
}
Later if you'll add some other file to the balance, you'll be able to
{
"files": {
"mainXML": ... /* actual data from that XML */,
"secondXML": ... /* actual data from second XML */
}
}
This approach is the opposite to:
# initial JSON contains just data of the first XML:
{
"startHealth": 1000,
"expPerLevel": 500,
...
}
# Then you added a second XLM:
{
"startHealth": 1000,
"expPerLevel": 500,
...
"secondXML": ... /* actual data from second XML */
}
In that case it's possible to have a name clash with keys in first XML and "secondXML" string.
After our system has acquired enough data it can suggest certain changes to the game flow as the player plays the game. Those changes are produced on the fly, i.e. as the player plays the game the game should as SDK for what to do next.
We respect each game's personality. Carefully harvesting each event and putting it in the right bucket. Different kind of Games need different treatment.
Here's the list of currently supported integrations:
Several APIs utilise concept of Data Object. Data Object is an object that contain any serializable data, including embedded Data Objects. In simple words it's the kind of data, that can be losslessly converted to JSON.
In Unity this object is a Dictionary<string, object>. Such as:
- All keys are
string-s. That means anyDictionaryon any level of data tree must have astringkey type - Supported number types are:
int,uint,sbyte,byte,short,ushort,long,ulongfloat,double,decimal
- Any
objectthat is not number and not a string will be calledToStringand treated as a string - Objects that implement
IListandIDictionarywill be treated as such collections