A comment on files:
With Bushfire and Bushfire Editor there are now two types of files involved: a game file and a map file. The first is the game files that Bushfire saves and which look like:
Only Bushfire works with these files, so with Bushfire Editor you don't need to worry about them. The files that Bushfire Editor works with look like:
Bushfire can also open and read these files, but once it has opened and read them Bushfire is unable to save to them. This is so that people who have edited their own maps can then distribute them and those maps can then be repeatably used by someone else without the original data being erased whenever a game is saved.
Sometimes fancy icons aren't enough for a user to tell the difference between files of different data types. That is why I have the odd convention of appending ".game" to the end of Bushfire's game files, and appending ".map" to the end of Bushfire Editor's map files. The two applications are clever enough to figure out what file types are what, so using this convention is utterly up to you.
One slight possibly of confusion could arise out the fact that I use the same file to contain both the "uncompiled source" of the map file, and the "compiled source" data. This coexistance will possibly be confusing because telling the difference between a compiled and an uncompiled map can only be determined by trying to play the game with Bushfire. A common example of what usually happens is in the field of C programming. Source files are typically of the form something.c while the object code appears as something.o. For Bushfire Editor everything is in the same file - and if this is confusing then I'd really like some feedback and ideas.
(This whole compile thing is a bit of experiment for me at the moment, as I'm presently working towards a more complex and more powerful form of map compiler for a future game that will really provide a wide range of possibilities to a person creating a scenario. I'm presently, trying to come up with a scriptable language for controlling the AI - a very difficult task! But there a difference between a vague dream and reality, so I'm working towards my ideas in a slow and additive process, which is why you're seeing my present embryonic efforts.)
At the moment, drag and drop is not supported, and if you want to open a Bushfire Editor map file you have to first have Bushfire Editor up and running. You then select the familar Open... menu item from the File menu. Sorry about not including this standard Mac interface feature - you can blame my laziness completely for this.
Getting Started:
To start Bushfire Editor, you start it like you would any other Mac application, in that you double-click on its icon:
Out of the application menu, the File menu is where we'll start looking:
Once you have started Bushfire Editor, you can create a random map by selecting New... from the File menu. When you see the New... dialog appear, you have a few decisions to make. The first have to do with the map dimensions. Unlike Bushfire which has a few fixed choices that always result in a square map, with Bushfire Editor you can make a map of any size that you want (provided your RAM holds out - of course - and that the map is always larger than 5 by 5 hexes).
The rest of the File menu behaves pretty much as any other standard Mac application.
What The Map Is Made Of:
Those who have played V4Victory or World At War will be familar with the look and feel of the graphics used for the maps. The first component of the map graphic are the terrain hexes:
Image: | Terrain Type: | of Fire-Fighters: |
of Fire Tiles: |
---|---|---|---|
![]() |
|||
![]() |
|||
![]() |
|||
![]() |
|||
![]() |
|||
![]() |
|||
![]() |
On top of the terrain, we add some details to the map:
![]() |
|
![]() |
|
![]() |
After the terrain, there are the units that get to move about the map:
![]() |
|
![]() |
Working With The Map Windows:
When Bushfire Editor opens up a new window in which it displays a map, it will try to make the window as big as possible and still fit in the main display area. If the monitor you are using is larger than the map, then the window is sized to fit. You cannot, at any time, resize the window for yourself - this arose out of consideration about how to keep with the Mac GUI guidelines and still locate the movement arrowpad in the lower right corner, with the Mac GUI losing out (the lower right hand corner is where the Mac resize square is meant to be located).
Like other familar Mac applications, the windows work just like any other windows that you are familar with. Clicking in the titlebar of a window and dragging will move the window about the screen. Clicking in a window's close box will cause the window to close (after doing the familar checking to see if the file needs saving). If a window is in the background, clicking on it will bring it to the foreground and cause it to be updated. Note that clicking on a background window won't result in any actions happening within that window - for example, clicking on a background window where the close box is located won't close the window, it will only bring the window to the foreground.
To help work with windows that might be hidden behind other windows, Bushfire Editor has a Window menu which can help you chose which window you want in the foreground. If you have only one window open, then it will be dimmed and you can't select anything from it. But once you do have 2 or more windows open, then you can select items from the Window menu. Basically, you have a list of open windows and you can either page through them one at a time by using the Next Map menu item, Or you can work your way backwards through the list by chosing the Previous Map menu item. If you have a lot of maps open, you can go directly to the map that you want by selecting the menu item from the list attached to the bottom of the Window menu. The tick tells you which window is currently in the foreground.
Navigating About The Map:
Navigation around the map is very simple, and is based completely on the movement arrowpad located in the lower right hand corner of the map window. There are two things that you can do with the arrowpads - you can either click quickly on one if the arrowpads which will cause the map (if it can move at all) to move one hex in the chosen direction, or you can hold down the mouse on a particular arrowpad and after a slight delay the map will move an entire screen size in the chosen direction.
Only Bushfire makes use of mouse clicks that occur in the center pad. Though the button will move in Bushfire Editor nothing happens as, in the editor, there is no such thing as an "active unit" as there is in Bushfire Editor. The only other thought would be to use the center button to center on compile errors, but since these can be scattered all about the map, it isn't exactly clear what attempting to center would mean.
Basic Map Editting:
When you first create a new map you will be confronted by a window with a region filled with the hex map - this map shall all be set to clear fields from the start as the map needs to be initialised to something. To the right of the window is a large graphic showing all the possible terrains that you can put on the hex map - this is refered to as the terrain pad:
If you click within this terrrain pad, you will notice that a black highlight will appear for as long as you hold the mouse down within a particular sub-rectangle of the terrain pad. This means that you are selecting a particular terrain element. But you need to do just a little bit more to get the item that you've clicked on to appear on the map. To get stuff appearing on the map you must first select the hexes in which you want your selection to appear. You do this by two methods - the first is to do a single click on the hex map over the hex that you wish to be selected. If there are any other hexes selected, then only just that hex that you've clicked in will be selected (even if the hex has previously been selected). The hex that you have selected will be marked by having a green border placed about it.
Making a map hex by hex would be rather slow, so the option of shift-clicking is included. To get this working, you first click once to select you first hex, and then hold down the shift key as you click on other hexes that you want selected. If you shift-click on a hex that has already been selected, then that hex will become unselected.
Once you have selected your hexes, you can then click on the terrain pad to make your choice appear on the map.
Working With The Map Menu:
After the basics of map editing, there are some further possibilities that are either added or enhanced by using the Map menu:
The first five choices are all concerned with the adjustment of the number of tiles that appear on the hex map. The first menu item is concerned with adding fire-fighters to the map. You first select those hexes in which you want the tiles to appear, before chosing the Add Fire-Fighter Tile menu item. Repeatedly selecting this menu item will keep adding one fire-fighter to the map each time, but after a maximum of four tiles is reached further attempts to add tiles will not work.
![]() |
Selected hexes highlighted, waiting for the user to add a fire-fighter. |
![]() |
Immediately after the user adds a fire-fighter, a single fire-fighter tile is added to each of the selected hexes. |
The second menu item is concerned with adding fire tiles to the map, and the function is just like that for the fire-fighters. You first select those hexes in which you want the tiles to appear, before chosing the Add Fire Tile menu item. Repeatedly selecting this menu item will keep adding one fire tile to the map each time, but after a maximum of four tiles is reached further attempts to add tiles will not work.
![]() |
Selected hexes highlighted, waiting for the user to add a fire tile. |
![]() |
Immediately after the user adds a fire tile, a single fire tile is added to each of the selected hexes. |
The next two menu items work similar to the adding tile menu items described above, but with the difference that for every time the menu item is selected one tile of that type is removed. Thus if you had selected a hex containing 3 fire-fighters, and then chose the Remove Fire-Fighter Tile menu item, you would then be left with only 2 fire-fighters in your selected hex. Naturally, once all the tiles in a hex have been deleted, further attempts to remove a tile will result in nothing happening. (I guess that a hex with more than 4 tiles can look a bit crowded, but what does a hex with a negative number of tiles mean?)
The fifth menu item is present to help out the person making maps. Because each hex has a different stacking limit for whatever terrain is present, it can be difficult for a person editing a map to adjust these levels correctly - especially when one is regularly changing the terrain that lies under various tiles. Thus the Adjust Tile Stack Stack Limits, when selected, will go through the map, and if it finds a stack of tiles that exceed a particular hex's stacking limit then it will drop the level down to the maximum level allowed. Notice that in the following graphic: that no tiles are allowed to stack in water; that for any terrain other than water, you can have a maximum of 4 fire-fighters per hex; while for fire you can have a variety of stack limits for the variety of terrains.
![]() |
Before the tile stacking is adjusted. |
![]() |
Immediately after the tile stacks are adjusted. |
Then comes a series of eight menu items that all begin with Random -. These are to help out in the appearance of the map that you are working on. Though the terrain pad allows you to individually select the particular hex terrain (ie lake, clear, forest, city, etc.) often, while making a map, you find yourself merely selecting the first terrain choice that your mouse reaches. These means that the early version of your map will fill up with the same terrain type (for example, all forests that you have on your map are the forests from the first column). To go through, by hand, and change all these images is a lot of work. To help out, you can select one of the Random - menu items to speed this part of your map making up.
The first option is to randomise only those hexes that you have Selected - that is only those hexes that you have clicked/shift-clicked in and are highlighted with a green border will be randomised. The next six only randomise terrains of a particular type - thus, if you wanted only your cities to be randomised, you 'd select Random - All Cities. Finally, to randomise the entire map, you can select Random - All Hexes and the editor will go through the entire map chosing one out of the six possibilities for whatever terrain you have chosen. In the following we see the results of shift-clicking and then selecting Random - Selected:
To help make the roads look more attractive to the player - beyond the six basic directions, there are six extras that cut "diagonally" across the hex. In the following image, you can see how the two sets of roads relate, with the top row showing images using the basic roads, while the lower row shows the results of using the neater, "diagonal" roads:
But going through your map and doing all these possible cases by hand can be rather dull and time consuming. So a menu option was provide to do all this for you. By selecting the Optimise - Roads menu item, the editor will go through the map and see if it can make the roads look neater by using the "diagonal" roads. The following is a before-and-after example to show what can happen:
![]() |
Before the roads are optimised. |
![]() |
Immediately after the roads are optimised. |
Often when you first define a hex map, you mightn't know the full size until late in the editing stage. To provide a means whereby you can add or delete columns or rows is what the Resize Map ... menu item is about. If you select this menu item, a dialog will appear that will ask you what changes you'd like made. (Ignore the graphic in the center of the dialog - it isn't a scaled version of you own map ... putting in some feature that will scale your map and then display it in the dialog box would really take some cpu time to display and would kill off the user experiance. The graphic is just a screenshot of a random graphic ... eye candy, if you must.) Typing in a positive number means that a row or column will be added to the side corresponding to the text field that you enter. Typing a negative number will delete rows or columns.
Numbers that are valid take the form of: 12, -012, -4, 34. Invalid enteries take the form of: ABC, 12+23, sin( 1.5708 ). The following is an example where 5 columns are added to the right of the map:
![]() |
Before resizing. |
![]() |
Specifying that we want 5 hex columns added to the right side of the map. |
![]() |
After resizing. |
Compiling The Map:
After you have edited the map, you need to compile it in order to both find invalid design choices and to provide a map in the form that somebody else can use and play. To do the compiling you use the Compile menu. If you are like me, then you'll just use the quick-key and hit cmd-F to do a full compile, which will go through all the aspects that need to be compiled and check them all in turn. But the rest of the Compile is left exposed so that you might know exactly what goes into making a map that is valid (that is, a map that is in a format that Bushfire can safely play - as Bushfire makes a number of asumptions about what the map will look like).
The compiler function is pretty basic, and represents only the first generation of my map compilers. The basic flow is that you select a particular compile option from the Compile menu; the compiler thinks for a moment; and if there are no faults found then a dialog pops up and tells you that everything is okay, otherwise little pink highlights appear on the problem hexes and a message appears in the empty region just under the hex map, with a description of the problem. If you click on the map the pink highlights disappear and the familar green highlight returns.
The first compiler test is to determine if the land is continuous. This means that from whatever non-lake terrain you select, you should be able to then find a path to every other non-lake hex by only crossing other non-lake hexes. This means that you can't use lakes to create islands. I forced this option onto the map maker in order that meaningful maps can be created (what does it mean to have some fire-fighters on one island and the fire on another, with no way for the two to meet).
![]() |
You cannot divide the map into segments using the lake terrain hexes. |
The next menu item, Border Overlays checks to see if there are any overlaps in the detailing that goes along the borders between hexes. The only details that matter, in this test, is whether or not hillside are on top of river segments. In the following picture, you can see that when a hillside does overlap a river segment that it is very hard to detect the river beneath it and that having a compiler to catch this problem is very useful.
![]() |
You cannot have a river segment overlapped by a hillside segment. |
River Symmetry is where both segments of a river are present along a hex border. If you look carefully, you will notice that rivers are made of two segments - and both need to be present for a map to compile.
![]() |
You must have both sides of a river present in order for the river to be valid. |
Roads provide a similar problem as the river did above in that it needs two parts - one part leaving a hex, and another part corresponding to entering a hex. The following picture shows two road segments where the one on the left is okay, but the one on the right is incomplete.
![]() |
You must have both sides of a road present in order for the river to be valid. The roading pairing on the right is incomplete. |
People who play V4Victory - Market Garden will remember the dirt walls that were scattered about the map and were made of two hill segments placed back to back. Bushfire doesn't allow this option and the compiler flags it as an error.
![]() |
Hillsides cannot join each other across a hex border. |
Then the compiler runs a whole series of related tests. The first is to check if there are any river segments lying on a lake hex (which is a useful test in that it is very hard to see the river segment when it does lie on top of a lake hex). The second is to test whether a hillside lies on top of a lake hex. The third is whether a road segment lies on a lake hex. The fourth is to determine if a river segment is place next to a lake hex. The fifth is to determine whether a hillside is adjacent to a lake hex. In the following picture we can see an example of each one of these problems that the compiler will flag.
![]() |
|
Finally, the compile finishes by doing a series a checks on the tiles. The first two are trivial and merely check to see that there actually are fire-fighters and fires present on the map - after all, it would be meaningless not to have them present. The third is to check if fire-fighter and fire tiles are not present in the same hex - this should never flag as the editor is set so that you can never do this anyway. The fourth test is to determine if any tiles are on a lake hex - after all, it is forbidden for any tile to be on a lake hex. The last two test are to determine if the fire-fighters and fire tiles are overstack - that is for the particular terrain of a hex in consideration, that there aren't too many tiles present. The following image is an example of the fault that you'd see with tiles being place of water:
![]() |
|