Adding structure to your working storage

Blitz3D Forums/Blitz3D Tutorials/Adding structure to your working storage

_33	(Posted 2007) [#1]

More than often when dealing with big projects, the code gets bloated, hard to read, alienating at moment, and disenchanting towards the programmer that has to put it's head at. So I'll present my approach at putting structure to your working storage!

A working storage, commonly known on the IBM mainframe and Cobol developper environment, is an area where you will hold data and working variable content, for the need of the task at hand. Cobol has an extremely nice approach into structuring your program data, as the creators of the language decided, at the time, to make levels, assisting the programmer into building a hierarchical working storage to facilitate it's understanding and manipulation.

Here's a Cobol Working Storage example:

WORKING-STORAGE SECTION. 
   03  MY-LONG-ARRAY10           OCCURS 10.                                   
      05  MY-LONGARRAY-ELEMENT  PIC S9(9) BINARY. 
        
   03  WS-SUB                    PIC S9(09) BINARY VALUE 0.

In Blitz3D, I've taken a similar approach, but I had to think a little bit about how clean I wanted the whole thing to be and I wanted a worry free system (approach) that is accompanied by the proper init/update/kill functions. I suppose, my approach is a little bit like object oriented. Let's begin!

First, you define a general type for your application. If you are making a game, then make a game type as follows:

Type game_info
End Type

Now, initialize it from program start as follows:

Global game.game_info = New game_info

In essence, you have just created a receptacle for all your global variables to be stored. You shouldn't have ANY other Globals to define except game as a game_info type! So, let's try some things out and add some meat to your working storage. By the way, if you really feel like a Cobol purist, you could call it ws_game, to identify it as a working storage.

So heres's a little something:

Type game_info
   Field status% ; 1 = playing, 2 = game over, 3 = paused ...
   Field timer%
   Field lives%
   Field score%
   Field mouseX%
   Field mouseY%
   Field playerX#
   Field playerY#
   Field playerZ#
End Type

Now that we defined our game data type, we can define the main functions that handle this type. Usually I create an init, update and kill function for every general type that I create, or info data type. Here's how it looks:

Function init_game(lives% = 3)
   game/lives = lives
   game/score = 0
end function

Of course I've set up a really simple example. But, hopefully you get the idea. from this way of working and on, you won't ever have to worry about your globals, as they should all be located in very specific types and allocated from the top of your program execution (not in a function) as a Global.

You can then apply this scheme with your camera, and entities as you should create an entity list with various status and let it get handled with specific general purpose functions. That way, you should have flexible functions at your disposal which can give you status on some entities and init/kill/update them as you would do for your game.

I can only wish you good luck on your endeavor.

Cheers.