Battlefield Services v1.2

Battlefield Services is a D&D 3E combat board, aimed at helping players visualize combat positions without reams of graph paper and/or expensive miniatures. The program is written in 100% pure Java, meaning that, theoretically, at least, it can be ported to and used on any system with the correct Java compiler.

This current version was written using JDK1.3. Please note that you must have the correct JDK version before attempting to run this program.

This version of Battlefield Services has the following features:

• Adding players (friends and foes), grenade-like and spell effects, light sources, and obstacles, to the combat board;
• Moving players around the board using a simple click-and-drag;
• Showing a player's normal movement range, double-move range, and run range;
• Showing a player's reach with a given weapon, or range with a ranged weapon;
• Showing the range of a player's carried light source;
• Showing an active spell on a character and its area of influence;
• Automatically sorting rolled initiatives;
• Displaying details about a player's active weapon;
• A jump calculator;
• A magic mishap generator;
• An XP calculator;
• Customization of magic mishaps, spells, and weapons; and
• Saving and loading unfinished/prepared combats.

Time allowing, there might be a more advanced version in the future.

The following are known issues and bugs:

• Occasionally, the program will crash, giving a strange error message about a Java internal error. The reason for this is unknown.
• Malformed input is simply ignored; if nothing happens after a button is pressed, check all inputs again.
• The program can get painfully slow if there are too many markers on screen at the same time. This is partly due to a recognized fault in intermediate compilers, and partly due to my sloppy code. Hopefully, the mistake on my part will be corrected sometime in the future.
• When the save/load dialogue window is activated, it sometimes does not appear correctly. There may be components missing, even if the mouse cursor is hovered above where you know a component to be. This is probably due to the way that Java handles painting of different layers, or it may be due to the way that I call the repaint() method in the program.
• Zooming the display while markers are already present on the board causes existing markers to displace. Without scrollability for the main combat board view, this is a fairly serious problem. I am still working on a fix for this, but until then, make sure that the zoom is set to your satisfaction before placing any markers.
• The range of the bullseye lantern is not correctly implemented - the current implementation is a 60' circle, but should be a 60' cone instead.
• Combat reach has not been fully implemented for creatures larger than medium size, e.g. the program will not show proper reach for a larger than medium size creature holding a reach weapon.
• Movement when move range is shown has not been properly implemented. A player may make several show-move-range-then-move-and-repeat attempts. The program does not take into consideration player turns.
• For simplicity of programming, certain spells which require cubic area-of-effects have been converted into circles. This was a purely technical consideration at this point in time. Players thus get an extra square of effect from these spells.
• Spell ranges have not been implemented. This has been left to the discretion of the user, since calculating spell ranges based on player level will require a change in the fundamental working classes. Generally, though, a short range spell will require some careful counting of the squares on screen to determine the exact valid ranges. A medium/long range spell will usually encompass everything on-screen if the default zoom is used.
• An obstacle marker is a solid marker - no other type of marker can be shifted on top of an obstacle. This prevents throwing a grenade at an obstacle, for instance. While this is not representative of a true game world, where players might want to drop a fireball at an obstacle, for example, this approach has been taken largely for technical reasons. I hope to have this fixed in the near future, thereby leaving targeting obstacles to the jurisdiction of the individual DM.

Please send notice of any more bugs to sb21@pacific.net.sg. I would greatly appreciate any ideas on solving the abovementioned bugs.

To run Battlefield Services, ensure that your classpath has been properly specified. A simple method of ensuring this is to open up a text editor, and create a new batch file (called setup.bat, in this example), and enter:

• SET PATH=%PATH%;.;..;C:\JDK1.3\BIN;C:\JDK1.3\LIB
• SET CLASSPATH=%CLASSPATH%;C:\JDK1.3\BIN;C:\JDK1.3\LIB;.;..

This assumes that JDK1.3 was installed into the JDK1.3 directory, of course.

To run the program:

• Open up the MS-DOS prompt;
• CD to wherever setup.bat is located, and run it.
• CD to wherever Battlefield Services was unzipped, and type in java Application.

Once the program is run, the main interface is presented.

• The extreme upper window bar contains the tabs that enable switching between the combat board and the XP calculator.
• The next layer on top contains the zoom and file input/out controls.
• The 'graph paper' in the center of the screen is the actual combat board.
• The left layer shows the calculated initiative sequence of registered players.
• The right layer shows the specific details of a player.
• The bottom layer shows the buttons required for micromanagement. These are divided into 2 tabbed panels holding different buttons:
  • The Player Panel shows the buttons dealing with player's markers; and
  • The Effects Panel shows buttons dealing with adding the various effects, like spells and grenades.

• To control the zoom, simply move the slider located on the left side of this bar.
• The Reset Display button shifts zoom back to its default value.
• The Clear Display button shifts zoom back to its default value, and wipes all data. Essentially, it gives you a clean slate to work on.

• The Save button enables you to save your battle progress. Clicking this button pops up a Windows-look-and-feel dialogue box. Type in the filename, including extension, then click the Save button in the dialogue box to save on-screen data.
• The Load button is the reverse of the above process. Once the dialogue box is up, highlight the file you wish to load, then click the Open button in the dialogue box.
• The Merge on-screen data button is similiar to the Load function, but it allows a user to add the data in a selected file to that which is already on-screen. Thus, it is useful for suddenly revealing assailants that players were not initially aware of, for instance.

• Type in the data as prompted by the labels alongside the textboxes. In some instances, you need to select an item from the drop-down boxes instead.
• When data entry has been completed to your satisfaction, click on the Add Friendly or Add Enemy button at the bottom of the screen, in the Player Panel. A green (friendly) or red (foe) marker should then appear on the upper left corner of the combat board.
• To move the markers around, click on a marker and drag it to the desired position.
• At any time, should any of a player's stats change (most probably the Wounds stat), simply update the data as required, then click on the Update Player Information button.
• Click on the New Player button to add another player.

N.B.: Players are identified uniquely, partially using their name. Make sure that all player names are unique, otherwise, the program treats it as an update instead of an add.

• Select a grenade from the Active Weapon drop-down box. Implemented grenades are Acid flask, Alchemist's Fire, Avienna's Fog, Holy Water, Stonetar, Tanglefoot Bag, and Thunderstone.
• Click on the Add Grenade Effect button on the bottom of the screen, in the Effects Panel.
• The grenade effect should have appeared on the upper left corner of the combat board.
• A similar process is required to add a light effect, selecting a light source from the Light Source drop-down box, and clicking the Add Light Source button, instead.
• Adding a spell effect is identical to the processes already described, but select from the Active Spell drop-down box instead. Click on the Add Spell button to complete the process.
• Similarly so for adding obstacles.
• Such markers can also be moved by clicking on them, and dragging them to the desired spot.

N.B.: Note that to move such a marker, you must click on the exact center of the ellipse. This area is shaded a tad deeper than the rest to make finding it easier. Note also that the current system of adding markers does not scale well. The more markers you have, the slower the program will respond. Again, this is due to the vagaries of interpretive-compiler types like Java.

• To kill any marker, click on the Kill Marker/Player button on the lower right corner of the screen.
• Now click on a marker. That marker should disappear, and its entry (if it was a player) disappear from the player list on the left.
• You can also kill a player by highlighting its entry in the player list, then clicking the Kill Marker/Player button. The corresponding marker will also disappear.

• Shift-left-click shows the player's hustle (double-move) range.
• Ctrl-left-click shows run range.
• Alt-left-click shows normal movement.

You can also move markers while showing the move/hustle range. However, in this mode, attempting to move the marker out of the visible range of movement results in an illegal move, and the program ignores you instead.

If a player is carrying a light source, or has an active spell:

• Double-right-click displays the range of his carried light source.
• Double-left-click displays the range of his active spell.

N.B.: You cannot show both light sources and active spells simultaneously.

• Right-clicking on a player will show the reach with a player's active weapon. If this is a reach weapon, then the reach is correspondingly increased. Remember that you cannot hit adjacent creatures when using a reach weapon!
• If the player is holding a ranged weapon, then a red-shaded area will appear. The intensity of the red decreases with range. This intensity difference is quite visible, and each such zone denotes a range increment. For example, a target standing in the first (most intense) zone is hit at point-blank range, the next zone is one range increment (-2 to hit), and so on.

The spells, weapons, and magic mishaps are stored in plain, ASCII text files. This means that with any editor, a user can open them up for editing. The files are:

• Spells.txt - the file holding the spells;
• Weapons.txt - the file holding weapon details; and
• MagicMishap.txt - the file holding all the magic mishap possibilities.

The program will read these using some very strict rules, so any changes must follow according to a pre-defined format. All changes must also take place between the "File Header" and "EOF" lines, with no more carriage returns after the latter.

The file formats are:

• Spells.txt
  • Name
  • Level
  • School
  • Components (V,S,F,DF,etc. as defined in the PHB)
  • Casting time
  • Range
  • Duration
  • Saving throw (Yes/No only)
  • Spell resistance (Yes/No only)
  • Effect (spell description - can be as verbose as you wish)
• Weapons.txt
  • Name
  • Damage range (dice range, e.g. 2d6)
  • Critical threat range (20, 19-20, etc.)
  • Critical damage modifier (x2, x3, etc.)
  • Damage type (piercing, slashing, bludgeoning, etc.)
• MagicMishap.txt
  • A single line description of the mishap. Can be as verbose as you wish.

Each field in the format must be separated by a tab return.

• Implemented most area-effect spells in the PHB. The program will now show the spread of a spell effect.
• Cleaned up the source code in the original classes, so now it looks a bit better. Not much, but an improvement.
• Set-up a file filter so that the save/load interface looks neater. By default, the program saves battles as object files, denoted by the extension *.OBJ. However, this is not a strict requirement: a file saved as BATTLE (without any extension) will load just as normally as a file saved as BATTLE.OBJ.
• Added a magic mishap generator that produces up to 10 mishaps whenever a mishap occurs, such as that produced when a spell misfires from reading a scroll.
• Added an automated jump calculator. Just key in the player height, base speed, and the jump check roll, and it will return the maximum jumpable distance as well as the actual distance jumped.
• Added the capability to place obstacles into the display panel.
• Changed the MagicMishapTable class so that it now reads from file. This allows user customization of any magic mishaps.