Bricks Editor
Technical Notes, 2003 Martin Oehm


1. Introduction

In December 2003, I decided to publish the source code of the
Bricks Editor I had written earlier fo Andreas Rottler's Bricks
game (http://www.rottus.de). The Editor is not up to date, and
I lack the time to implement the recenlty introduced Bricks
features.

The source code is not (or little) commented. I believe that it
is still readable if one understands the general mechanisms of
how board data is stored. Thus, these technical notes are only
very brief, describing the basic concept of the Bricks editor.

Although I have officially abandoned this project, I encourage
the continuation and improvement of the Bricks Editor. Should
you decide to work on the Bricks Editor, go ahead, the source is
yours. Should you get stuck, feel free to contact me, although
replies may take some time. And bear in mind, that I haven't
worked on the Editor for quite a while now.


2. Platform

The Bricks Editor was written in Delphi. Originally, Delphi 1
was used, but then the Editor was recompiled with Delphi 5. The
source code should be compatible to Delphi 1 and later.

The package contains a Rich Text Format file which can be
converted into a Windows Help file using the adequate Delphi
utilities.


3. Data Structure

The data structure is not the same as the one used in the
Bricks game. Every Board is represented by a record:

    TBoard = record
        nTiles: byte;
        bForm, bID: Array [0..24, 0..24] of Byte;
        bType: Array [0..255] of Byte;
    end;

nTiles is the size of the board, there are only square boards,
although this could be changes easily. The maximum size is 25
tiles square.

The bID array saves the ID of the brick on square i, j or zero
if ...

The bForm array stores two pieces of information. In the lower
five bits, the shape of the brick's part covering tile i, j is
stored which is a binary combination of the following:

    1   brick continues north
    2   brick continues east
    4   brick continues south
    8   brick continues west
   16   brick is of an arbitrary shape

"Arbitrary shaped" bricks are bricks which are not rectangular
but shaggy like the "submarine" master brick. A brick can only
be arbitrary or regular, the editor cannot produce hybrid forms.
According to this, a single tile brick would have the form zero,
since it doesn't continue and is regularly shaped.

The top three bits of the bForm array represent any floor items
such as targets or traps. Currently, the following floor types
are used:

    flrTarget = 64;
    flrTrap = 128;
    flrHole = 192;

A zero value in the top bits means an empty floor. Since floor
items must be multiples of 32 (and not necessarily 64, as used
here), there is room for four more types of floor items.

The bType array stores the type of the bricks. Since the bID
array is a byte array, the maximum number of bricks is 255.

During editing, whether a tile is selected or not is stored in
the array sel[i, j].

Notes:
  * The frame is condidered as one single brick with ID 1.

  * Although water looks like a floor item, it is implemented as
    a brick of type brkWater which always has ID 4.

  * All bricks can spread arbitrarily over the board and do not
    necessarily be one continuous brick. Therefore, magic bricks
    are just regular bricks coloured purple.

  * Differently from the Bricks game, the Editor can start with
    bricks on top of floor items.

  * Currently, bricks and tiles can be cut and copied, but they
    cannot be pasted, making cpying and cutting somewhat useless
    features.

  * The bmp folder with icon/button images suggests that there
    used to be plans for further features I never finished.


4. Bricks Level File Format

The level files of bricks have the following sequential format:

  * The first byte cotains a one, maybe as a kind of "magic
    number", although a very dull one. Maybe this was used to
    keep track of (never implemented) future versions, I dunno.

  * Next, the title of the board is stored starting with the
    length of the name followed by the ASCII codes of the name's
    characters.

  * Next, the maximum id of all bricks is stored, followed by
    the entries from one to this numbber of nType.

  * Finally, nTiles is stored, followed by the entries bID and
    bForm stored in pairs and columnwise for all tiles.


5. Warranty

The source code is provided in the hope that it may be useful
but without any warranty. The original source code is copyright
(c) 2001 by Martin Oehm.


München, 13-12-2003
Martin Oehm
martin.oehm@gmx.de