After you took the first steps with the Cafu source code, you're ready to use it to develop your own game or application.
This section lists the most commonly used methods for starting new projects and explains the required steps to give you a good start.
The “normal” and recommended way to start a new game is to create a copy of the example game DeathMatch under a different name. This is useful because it immediately provides you with the proper directory structure, working code, and example files.
Creating the copy is straightforward:
Games
, duplicate the directory DeathMatch
and name the resulting copy as desired, e.g. MyGame
.build
in Games/MyGame/Code
.
The second step is necessary because previous builds of DeathMatch may have created files whose copy can confuse the linker when it is creating the program library for MyGame
for the first time.
To implement these steps, you can use any method you like, for example a file manager like Windows Explorer, or the command-line. This example shows how you can do it under Linux:
$ cp -r Games/DeathMatch/ Games/MyGame/ $ rm -rf Games/MyGame/Code/build
Technically, the above steps are all that is required to create the basis for your new game:
-svGame MyGame
to the command-line (see below how to get rid of it again).
-svGame
), see the section about the variable GameLibs
in file CompilerSetup.py
:# When you're developing your own game, you might want to keep game DeathMatch # for reference. Cafu should run your game by default (first in list), whereas # DeathMatch would be readily available via the -svGame command-line option: GameLibs = ["MyGame", "DeathMatch"]
Note that you have to re-run SCons in order for changes to take effect.
MyGame
, some paths in the code and scripts still point to Games/DeathMatch/…
. For the beginning, that's ok – your game will find some of its resources in game DeathMatch, and you can update these occurrences step by step at any later time (or even intentionally keep things like this).Here is a list of alternative courses of action that you may want to consider in order to start a new game:
Working directly with the DeathMatch game “in situ” may seem like a totally silly idea to you, but in some cases it can be a worthwhile consideration nevertheless:
If you want to quickly try something out (e.g. a new entity class), or if you work on something that is not directly or entirely a completely new game (for example, any changes to the core engine), the game DeathMatch might be a welcome testbed.
Also, if you wish to communicate and collaborate with people who are not directly involved with your game code, the DeathMatch code can be a good common ground.
Renaming DeathMatch, instead of properly copying it, would principally work, if it was not for these factors:
Games/DeathMatch/…
. If you rename DeathMatch, all these paths are broken, and your game will not work without fixing them first. If you instead copy DeathMatch, your game will find some of its resources in game DeathMatch, and you can update these occurrences step by step at any later time (or even intentionally keep things like this).Overall, we recommend not to rename DeathMatch. Better clone it as explained above.
Creating a new, empty directory in Games/
in order to start from scratch, then fill it with contents as required, is certainly possible.
Doing this can be a very good choice if your main goal is to learn and understand the technical details from the ground up, or if you only want to have original content in your game right from the start.
In fact, we're considering complementing the DeathMatch example game with another “Minimal” example game that comes closer to these goals.
If you start with an empty directory,
The VSWM MOD is old, obsolete, dysfunctional, and a candidate for removal. Not a good basis for a new game. Don't use it.