Prologue:
Too many times I would start a BGE project, only to see it crumble into failure. I would get to the point where I would have most of the game complete, but then I would find a bunch of bugs, inconsistencies, unoptimized game resources, unstable game play and just overall bad development choices. Since I just kinda “jumped” into the development process my framework was very unorganized, and generally very messy. Some of the problems I would find later in the game would be so deeply rooted, that changing/removing/fixing them would mean rebuilding the whole game from scratch anyway. Long story short, I would become frustrated, and the project would soon be abandoned. The problem became obvious:
I didn’t think things trough at the beginning
I’m writing this “Pre-development” tutorial in hopes that it will encourage/help others to once again take up the seemingly dying art of solid planing prior to development.
!PLEASE NOTE!
Even though the theory behind the efficiency of this planning method seems to be logically sound for anyone, I by no means claim it to be the “best” method for everyone. It is simply my method, and as such it’s far from perfect.
Pre-development Planning
Organization:
Usually everyone has a vague idea of what kind of game they want to make. However, this vague idea alone isn’t enough to actually fire up blender and start work (for us ordinary humans at least), but it’s just enough to think up a relevant project name and create a working directory tree, under which you can organize all your game related resources.
IE: If I was working on an asteroids clone with the BGE, I would probably name it “Blenderoids” (I know, it’s corny, but this is just for the sake of the argument, so bear with me). Then I would pick a place somewhere on my system (desktop for example) and I would create a new directory called “Blenderoids”. In this directory I would create 3 very important files: “Mission”, “Technical” and “Resource_List”, along with separate sub-directories for my textures, sounds, .blend files, executables/binaries, scripts etc. In general your working directory tree would look something like this:
Now I’m not saying that your directory tree has to look “exactly” like the one above (because different projects will probably require slightly different resource groups), but some sort of an organizational structure should be implemented, regardless of the project at hand. This will keep your work centralized, which will make finding/handling things much easier.
Mission:
The “Mission” file would be a document where your “vague idea” would became described in further detail, therefore becoming a “clear idea”. Basically you would type out what you already know, so as to establish a crystal clear sense of what your trying to accomplish.
IE: Blenderoids is a 2d game in which the player controls a ship with arrow keys, and shoots projectiles with the space bar at asteroids which randomly float about. When an asteroid is shot it splits into 2 smaller asteroids, when one of the split asteroids is hit it explodes and it is destroyed. Each time any asteroid is hit, the player scores 100 points. The player has 3 lives. Each time an asteroid hits the player ship, the player will lose a life, and the ship will explode. Then the ship will appear in the center of the screen, and the game will continue on. When the player destroys all the asteroids he/she moves on to a new level. In each new level the asteroids velocity will be incremented.
…And so on. As I said, a detailed description of your game, and what happens in it.
Technical:
The “Technical” file would be a document in which you describe the means and techniques to be used in order to make the game. Questions like: What logic bricks to use and in which situations? Where would a script do better? What to link with what? etc would be answered here. This is where you take the statements from the “Mission” file and translate them into technical documentation that describes exactly how to make them work within the BGE.
IE: The ship movement in Blenderoids will be handled by a script. The logic brick setup:
Up
Down
Left
Right
v
v
Python Script
v
v
Movement
…And so forth. For each statement in the “Mission” file, you would make a technical statement in the “Technical” file. (You can name these files anything you want, you don’t have to use the overly serious filenames that I am using here. I realize that some of this can sound a little silly, but again, it’s for the sake of the argument)
Resource_List:
The “Resource_List” file almost explains itself: It’s a list of resources that will make up your game. Resources (in the general game development sense) are things like meshes, textures, sounds, scripts etc. It’s pretty much everything you can see and hear in your game (along with some things you can’t). Weather you make all these resources by yourself, or simply gather them for your use is completely up to you. Either way this list is something you should make before starting anything.
IE:
64x64 asteroid texture, to be mapped to the asteroid mesh object.
An explosion sound for the asteroid destruction sequence.
Also, it’s a good idea to enforce some sort of a naming standard when storing resources in their respective groupings (organizational directories that we created before). For example: I would name the previously described asteroid texture asteroid_0, or asteroid_brown, or asteroid_silver depending on the situation. In any case a naming standard that can help you efficiently classify and differentiate resources will keep things neat, which can only help.
Resource Gathering/Creation:
Just like the “Mission” file is satisfied by the “Technical” file, so must the “Resource_List” be satisfied with actual resources. This is where you start hacking things off the list by either making them or getting them. You want to have “all” the resources on the list stored in their respective directories before you move on.
Conclusion:
Now that you have all of this completed, you are much better prepared because:
*You know what you want to do
*You know how to actually do it
*You already have all the resources gathered
…Which means: You’ll go into blender knowing “exactly” what to do, instead of starring off into the screen for half an hour, trying to figure out where to start (I call that “zombie mode”).
Pre-development planning provides more than just a project road map. It segments your project into very manageable blocks which you can fit into any schedule. This results in your development time being cut in half (if not more).
Epilogue:
Do you have to do this in order to make a good game? Is this all it takes? The answer to both of those questions is absolutely not. I mean it will definitely increase your chances of success, but this method of somewhat “excessive” planning is not the end all solution. Actually it’s not even the key.
The key here is “discipline”. You can have the best laid plans and still fail miserably if you don’t have the discipline to enforce the plan you set (and vice versa). You have to be driven and determined.
With that said, this tutorial would probably work best with a development project that you are truly passionate about.
I hope you find some of theese tips useful in your future endeavors.
Social.