I've spent far to much of my time developing games for blender, many unsucessful, and some sucessful. Over this time I've developed a toolset that help me to achieve what I set out to do. So here it is, yet another entry on how to make a game.
One thing I am expecting readers to understand is that creating a game in blender will require programming. In my early days once argued that logic bricks should be sufficient to make a game, and they were. But as soon as I learned python, suddenly things became easier, and games could be made faster, simpler and the actual games more complex.
Planning your Game[]
While some good ideas will present themselves during development, it is advisable to have hte main points of hte game laid out beforew development starts. If you are simple cloning an existing game (like depressingly many blender users), then this has already been done for you in the other game itself. But when you are coming up with your own game idea, the creation of a Game Design Document (GDD) is a good idea. There are many other places on the web that talk about these specifically, but I've found that sitting at a desk, and just writing lots is a fairly good method for me. I mention things like:
- How the game feels to the player
- The point of the game
- What the player will learn
- The artistic style of the game
- Specifics on weapons/player statistics/any other important details
For small games, the GDD is quite small, and two of my games (Neon Ball and Evasive ) were only a page or two. My bigger projects, like DEEP Space was 20-30 pages by the end. Most of it was computer based, but I now prefer real paper which I can shuffle and have next to the computer to refer to.
I also tend to write some more technical documentation, outlining how some of the code will work. DEEP Space had quite a few flowcharts outlining how levels would be loaded, how the player death/respawn would work and so on. These were very useful in designing and debugging these structures. (though DEEP Space was never bug free by any means).
File Structure[]
As games get larger, they get more complex, and there are more assets to manage. For small games, you can cram everything into a single file. For medium sized games, you may shunt images and sounds to external files, and for large games, entire levels, characters, props, and nearly everything has to be external to the game itself.
And so, without some planning, you end up with a maze of files that no-one can understand. As such, I've developed a standard file structure that suits most games, and can be modified to suit other ones. It goes something like this:
Game Folder
- data
- blends
- characters (Any character, player or NPC or vehicle goes here)
- levels (Levels go in here)
- placables (Objects that make up levels go in here)
- textures
- sounds
- game.blend
- menu.blend
- blends
- starter.blend (later game.exe. This simply links to the menu blend to avoid GPL issues. I also include various resolution and patch utilities in here, which I don't mind releasing)
I have a fairly standard starter.blend, and a basic form of this template can be downloaded from the Generic Game Template Thread.
But filing is only part of the problem. Here are some more things that need to be decided on:
- image formats (I use .jpg and .png, though others swear by .dds)
- sound formats (I use .mp3 for music and .wav for effects)
- naming system (Keep all names consistent. I use lower cases with spaces between words)
And of course this isn't exhaustive, there is way more that needs to be decided on for the file structure. Monster goes over a little more of it in his library tutorials on this site
Coding[]
For a while, your entire project can be contained in your head, meaning that you don't have to maintain any documentation. But as a project get's larger, you begin to forget how things work, and when you come back to them a week later, you've forgotten what you've done an what you've not, and you've forgotten how they work. As such, the structure of code is important.
Many people say 'put in lots of comments' but comments get out of date fast, and instead it is better to use better code layout, and proper docstrings. If you can, take a course on programming at your local university. It will give you a good idea about what you should be doing in terms of style. Also worth reading are the PEP008 guidelines
A large part of programming is deciding how to split things into functions. If you make sure that functions are properly named, then things get a lot easier, and you don't have to go back to fix them. The key words are 'divide and conquer.'
Naming[]
Let's say I have a function called get_objects(). It's pretty clear what it does, but it's also not clear how it gets an object. A better name is get_objects_by_property() or get_object_by_name().
Property names are important, as they have to represent what they are. a property called 'vect' is pretty useless. Sure, we know it's a vector, but what for? It could be movement, rotation, a ray, anything. So something like 'player_move_vect' is a lot more clear
Object Oriented Programming (OOP)[]
You can devote whole books to OOP, so I'll try to be brief. OOP is where each object knows only about itself. So the player object deals only with itself. It moves itself, it manages it's own health, it knows nothing about anything else, except maybe the name of what it's interacting with.
One way to deal with OOP is is to create classes. In python, these are a way of organising things into objects. There is a process called mutation documented in the blender API that turns a KX_GameObject into a class of your choice (eg a Player Class). In short, you simple make the class like:
class Player(bge.types.KX_GameObject):
def __init__(self, old_object):
It is worth noting that there can be no other inputs into the init function, which is a pity.
I was involved in a short discussion on this in the blenderartists forum about this, in which you can find a demo file. Try this post.
I tend to use OO a lot, even outside of programming. Each object in library files is complete. It has it's logic, it has it's textures and eveything. Thus when it's imported into a level, nothing more needs to be done.
Keeping Motivation[]
It is so easy to create a project, and then abandon it a week later. This happens because the developer gets bored. So we can stop being bored by splitting up what we do.
Anyone will get bored when they have to do 100+ hours planning, followed by 200+ hours of modelling, followed by 400+ hours coding.
But if one splits things differently, and does a couple hours of each thing a day, then it's more interesting. So if you do an hour of modelling, followed by an hour of coding, things are a lot less boring. Interestingly, this is what causes the downfall of most of my projects. I finish the coding, texturing and modelling, and then get left with the drudgery of making levels, which to me is endlessly repetitive. So if you properly prepare a level construction library, during the interesting times, then it is much easier later on.
Let dead men do the work for you[]
This is a saying by one of my old maths teachers. His theory was that many things have already been done, and so theres no reason to redo them. So instead of writing your own menu/GUI system, use BGUI. Instead of writing your own system for handling control input, perhaps try SolarLunes BGInput. This way you can spend your time developing your game, rather than developing tools to make your game.
Or, if you have time, develop your own system. I have my own box of tools drifting around my hard drive, with systems for keymappers, reading/writing options, patching games without having to completely re-download them, and so on. They are slowly being cleaned up and released on the web.