Possibly the biggest point of confusion with making an executable game with Buildbox is the difference between exporting and compiling. In general, when we're talking about exporting from Buildbox, we mean that Buildbox generates the projects needed for the Integrated Development Environment (IDE) for that platform (that is, Eclipse for Android, or xCode for Apple) to compile an executable code (the final program that runs on the platform). There are a few exceptions (Windows EXE and Steam needs compiling), where the final product is created from inside Buildbox.
If your brain just exploded, don't worry... by the end of this chapter, you'll understand exactly what all of this means.
Although Ramblin' Rover is conditionally (please check the EULA section) open source if you own this book; as there is already a Ramblin' Rover game on all of the app stores, you should not attempt to actually upload this game. You'll receive a lot of errors having to do with copyrights (and cause a lot of confusion in app stores, and possibly get inadvertently banned - as some app stores are more restrictive than others). What we present here is an example of exactly how it was uploaded to the app stores to educate you on how you can upload your own games.
Now that the obvious is out of the way...before we get started, there are a couple of things we need to do in order to prepare for export...
Remember, we want our game to be as resource-light as possible. Not only does this ensure that it'll run on most devices, but it makes our game run as fast as possible (in the hope to avoid any hiccups due to older devices). In the quest to make our game, it's virtually assured that we have a lot of duplicated graphics, some graphics that are no longer even used, and the same goes for our audio. Let's get started by opening up our game in Buildbox.
Let's also save a new copy of the game once it's opened. I'm always weary of automatic optimization processes (as it's entirely possible to have the software accidentally remove required graphics or audio). So, by saving a backup of the game, we know that we can always go back without painstakingly restoring assets.
Under the Tools menu (at the top of the interface), systematically go down and run every remove process offered:
- Remove Unused Level Objects
- Remove Unused Image Objects
- Remove Unused Sound Objects
- Remove Unused Scenes
- Remove Unused Components
Some of these may read as 0 Objects Removed, but you may be surprised with how many unused objects are removed from others.
Now we have to work with the Atlases. From the Edit menu, select Atlases. Buildbox works with large images that are broken up into a grid with each of our image files placed on those large images. This makes it easy for our game to quickly access a particular image (as it minimizes the number of files the program has to request). In the end, instead of referencing hundreds of image files, the game just grabs an Atlas, and shows one quadrant of it.
The problem is that if we have a ton of duplicated, or unused images, then the Atlas count can go up, and so does the overall size of the game. The following screenshot shows what the Atlas interface looks like:
As you can see, even our image sequences (such as our explosion animation, or our animation of the Rover's satellite dish rotating) have each individual frame as an entry on the Atlas. This is one of the reasons that we carefully consider the size of our images when we make them. We don't want a section of the Atlas to be bigger than necessary. Bigger images means bigger Atlases, which means less efficiency. We can also see why we're limited to background images no larger than 2,040 in either dimension. 2,048 is the dimension of our Atlas, and there are 4 pixels of padding on each side (8 pixels total... 2048-8=2040).
Optimizing is easy. Just click Optimize, wait for it (unfortunately, there is no progress bar to let you know how close it is, but there is a message to let you know it is completed), then click Rebuild.
And that's it! We're all optimized and ready to begin the process of exporting... almost.