BlitzCoder - Blitz Basic Game Development Resources

Blitz2D Newbies: Programmer, Organise Yourself! by Ted Jackson

Introduction:

One of the failings of an otherwise excellent product is the lack of Project Control in Blitz. This article aims to provide the reader with a basic set of working practices to offset that lack. These practices can easily be adapted to suit individual circumstances

A long time ago, in a galaxy far away, a solitary programmer spent his leisure hours bashing away at an Amiga keyboard. The subject of his endeavours was an all-singing, all-dancing RPG in the style of Ultima III. The tool he chose to perform this mighty task was... BlitzBasic, of course. .

Although this mighty epic never saw the light of day, there were several important lessons learnt along the way. Probably the most important was "You Shall Keep Your Data Organised and Safe". Computers in those days were even more liable to throw their toys out of the pram at the slightest provocation. A strict organisation (and backup routine) was essential. Woe betide those who suffered a visit from the 'Hard Disk Fairy', whose sole purpose in life seemed to be to destroy the lovingly crafted work of the author.

This article is aimed at newbies and seasoned programmers alike. I'm certain that most old hands will be using techniques along these lines because they will have had to use similar before the advent of the modern IDE (Integrated Development Environment) with all it's multi-file project support. However there will be those who have forgotten some of these tricks and will shake their heads and wonder why they hadn't thought of this earlier.

Back to Basics:

I would think that most of us, as programmers, are familiar with the concept of modularisation. Many of us will already apply the same thinking to the way we organise our project files. Perhaps a main directory (\MyProject) containing subdirectories for images (\MyProject\Images), audio (\MyProject\Audio) and perhaps for maps/levels (\MyProject\Maps).

This structure, while satisfactory for a single project, struggles once we introduce more projects. How are we going to deal with code reuse? Wouldn't it be nice to have that huge list of Keycode constants available for our new project? Or that Screenmode detection function. Some people will just copy the necessary files from one project directory to another, but this can introduce versioning problems - we modify the code to suit our new projects needs and lose track of the changes.

A better way is to step back a pace and introduce a higher level of organisation. We could create a 'Top Level' directory to hold all our Blitz projects (\MyBlitz). Create a new directory (\MyBlitz\Projects), each project should then have a subdirectory (\MyBlitz\Projects\MyProject) containing all the necessary data directories (see figure below).

"But where does the code reuse come in?" I hear you ask. If we create a library directory (\MyBlitz\Lib) and an include directory (\MyBlitz\Inc) under this 'Top Level' then we can use a nifty little trick or two to consistently access these libraries and includes.

Benefits:

The benefits of this approach are many. Your project files will be grouped together, your libraries and common includes will be grouped together. This will make backing up your precious data simpler. If you are involved in a team project then you could create a folder for updates to be stored awaiting testing/verification before they are added to the live code pool. Thus avoiding overwrites of known code. These are just a few examples, I'm sure you'll find many more uses amongst yourselves.

The only drawback is that you will initially have to be a little more disciplined in the way you work. A small price to pay. Now on to the little trick I mentioned earlier

The Humble Include File:

I am assuming that we are all familiar with the use of the include command. This simple command can have a powerful influence on the way we organise our projects. Consider:

This command inserts the contents of the named file (MyConstants.bb in the current directory) into our source file at compile time. Simple enough I hear you say. Well, consider this:

The ..\ is shorthand for the parent directory - ie if our source file is in \MyBlitz\Projects\Project2 then after the first ..\ the our path will point to \MyBlitz\Projects after ..\..\ the path will point to \Myblitz. From this point on things proceed as normal and we will move down the tree to \Myblitz\Inc and select MyConstants.bbs (providing that the file exists ;-}).

So we could deal with our constant and function library includes along the lines of:

Loading constants from \MyBlitz\Inc and libraries from \MyBlitz\Lib.

This gives us a standard way to reference and reuse our code. A major step forward. If you don't understand my explanation, don't worry. Just try it for yourself. I would hope that a silly grin appears on your face as the penny drops. This is so simple yet so powerful, one of my favourite combinations But I haven't finished yet! I've saved the best part for last, as all good storytellers should :-).

Making a Project File:

We can further extend the usefulness of the Include command to create a 'Project' file. If we move all our Include commands into a file in our current project directory and save it as Project.bb then we can have a single Include command in our source file thus:

which will load Project.bb and process any additional includes it contains, thus giving us a single point of change if we wish to test new versions of libraries or add more common code to our project. A boon for multi-programmer environments in particular.

There is scope for further use of the Include command - e.g. breaking function libraries down into more manageable chunks or switching between different library versions... but that would be another article ;-}.

The principles and procedures presented here are neither new nor complicated. You would be doing yourself a disservice if you don't at least try them out. They won't necessarily make you a better programmer but they sure will make you better organised.

I hope you have found this article useful or interesting and that it will give you some food for thought as you plan your next Blitz project(s). If you wish to comment on this article then please send me an e-mail at blitz.guru@lejen.co.uk.

For a printable copy of this article, please click HERE.