Now that you know your way around the Buildbox interface and are familiar with how things are structured in Buildbox, let's dig into the meat of how a game is made. From here on in, we'll be going covering in great detail how we make a game, and the processes, methodologies, and philosophies to follow. Again, if you have not yet downloaded the content (the link is in the Preface of this book), please do so now. Let's begin...
The most important thing with developing a game is keeping track of your resources. Whether it's in Buildbox (by taking the time to properly name everything) or in your directory structures for assets and naming conventions for those assets, by keeping things organized as you go, you'll greatly minimize your frustration later.
Remember, you may want to update your game later, fix problems, or even make a sequel. Several months or years later, you won't remember that a button was placed in a character folder, or that an asset that should have been named boulder.png was named untitled_object_005 in Buildbox. Naming and organization are key.
Since we're developing (potentially) for multiple platforms, we have to keep in mind that different platforms handle some file and folder names differently. So, we're going to go old-school with naming conventions. This means we'll be using hump-back notation with no spaces, and we're going to pad any numbers to three spaces. What does this mean? Take a look:
- Hump-back notation: This is where the first letter of each word is capitalized and there are no spaces between the words. For example, if you had a star map for a background, the filename would be
StarMap.png. - Padding numbers: All this means is that if you have more than one image that is similar (or an image sequence for animation), instead of the numbers being 1, 2, 3, they would be 001, 002, 003. For instance, our rover at idle might be
RoverIdle001.png,RoverIdle002.png, and so on.
It's also important to remember to be as descriptive as possible in your naming. Again, you may come back to your project months or even years later. You should make your names so easy to understand that even if you suffer severe head trauma and lose all memory, you'll be able to pick up your project and run with it at a later date.
What good are the most descriptive names on your files if you can't find them? A good directory structure is paramount to good organization. We suggest that you set up your directories before beginning in Buildbox or creating any assets.
How you set up your directories is a matter of personal and professional preference. The following image shows the directory structure we've set up for Ramblin' Rover. The methodology we use for Ramblin' Rover is to simply put every type of asset in its own folder, then, within that folder to put raw files (such as Photoshop PSDs and illustrator AIs in their own folder). Furthermore, any image sequences for animation have their own folders as well:
Since 3D projects have their own plethora of asset files, we simply create a project folder for 3D projects (in Ramblin' Rover's case, we used LightWave, so we have a Lightwave folder). But 3D projects are rendered into the respective Buildbox project folders. For example, an animation of a rover's jump; the LightWave project would be kept in the Lightwave folder, but the final rendered images would go into Characters/Rover001-Jump folder.
As you can see from the previous image, we've followed our naming conventions, kept spaces out of names, and organized our files and folders into something that leads to an environment that is easy to navigate.