Each of the games has been revised since its original release. DBM has had issued rulebooks for versions 1.0, 1.1, 1.3, 2.0 and 3.0. The current version 3.1 is available as errata to version 3.0. In addition version 2.1 was available as errata to version 2.0. Because some people do not use the latest version, for economic or other reasons, all significant versions are considered. Note that version 1.2 was effectively replaced by version 1.3 and is not considered. DBR has had issued rulebooks for versions 1.0, 1.1 and 2.0.
A DBM or DBR army is built out of a variety of troop types, further divided by grade (superior, ordinary and so on) and for DBM whether they are regular or irregular and other details. Armies are further divided into commands, each with a general and baggage. Each troop type, plus additional features such as fortifications, has an army points (AP) cost. Unless running a campaign an army is usually built to a fixed overall points cost, and usually constructed from an army list, usually from books by the same authors (also published by the Wargames Research Group). These attempt to allow the construction of historically realistic armies (within the constraints of the rules systems and historical and archaeological doubt and debate). The Wargames Research Group publishes four volumes of DBM army lists (all now replaced by a second edition) and three volumes of DBR army lists.
Note that previously two spreadsheets were provided, the first a simplere version for DBM only and the second a more complicated version for DBM and DBR. Only the latter is now included, to avoid multiplying versions. It is however larger and slower than the former was, and an updated version of the former may be provided later. (If interested, contact the author.)
The choice of the Psion 5 is obviously because I own one. However that decision made at least partly so that I could produce applications such as these spreadsheets, in particular for portable use, such as the intended use to check an opponent's army. Personally I find a palmtop a better solution than a laptop for such situations.
The drawback of the Psion 5 is speed, at least for complex spreadsheets, such as the second spreadsheet in particular. If you open the spreadsheet it takes a minute or two to sort itself out once opened. Give it this much time after opening, either before entering anything, or being prepared to wait for results to show up, and responses are reasonably prompt thereafter.
I have since converted an earlier version of spreadsheet to MS Excel. This conversion was partially automatic, using PsiWin 2.1, but has had to be completed by hand. Since then changes to each have been made in parallel.
Testing of both versions (and of their equivalence) is currently incomplete. If you find any problems, please let me know.
The remaining notes below describe the spreadsheets running on a Psion 5. There are no significant differences using Excel. (Modifiable cells in the Excel version are lighly coloured.)
Some additional features, which are not described in rows 1 to 10, are summarised later below, as is how to use the spreadsheet for DBR, and earlier versions of DBM.
Each element (or fortification, see below) type is allocated a row, one of rows 16 to 60 (60 is an arbitrary guess as to a value big enough for most purposes, see also some comments below). To define an element type enter:
Some troop type suffices are permitted:
All the above, in all of columns A to D, are case insensitive. If you want to type CV instead of Cv that is up to you. If you want to type cV so is that - but I do not think much of your choice. This case insensitivity applies also to suffices, so you can use mtd rather than Mtd and so on.
Having completed columns A to D (possibly leaving some blank) column E will be filled in by the spreadsheet, as described below. Then, having picked your element or fortification type, columns F, G, H and I are used (in that order) for up to four commands (leave unused columns blank). Put the number of each element or fortification type in each command in the appropriate column. Note that while entries are incomplete, some errors may be indicated.
The spreadsheet will now calculate:
Before the special cases and the warnings, described below, here is an example. Enter:
Irr Cv S C 1 Irr LH S S 1 1 Irr Cv S 3 Irr LH S 12 9 9 TFCa 5 Irr Bg O 6in rows 16 to 21 and columns A to D and F to H and the spreadsheet will update to look something like:
AP Cmd 1 Cmd 2 Cmd 3 Cmd 4 Total Army Points 135 80 80 295 Elements 22 10 10 42 Element Equivalents 16 10 10 36 Demoralisation Level 6 4 4 18 Irr Cv S C 19 1 1 Irr LH S S 17 1 1 2 Irr Cv S 9 3 3 Irr LH S 7 12 9 9 30 TFCa 1 5 5 Irr Bg O 0 6 6If you play DBM you can probably work out what all the above numbers mean. Note that the spreadsheet uses some thick vertical lines to separate columns appropriately.
The spreadsheets trap various errors. If lots of # values sprout all over the place you have probably entered an invalid troop type, like Cv(X), or number, like -1 or 0.5. If you really cannot work out what is wrong then contact the author.
There are lots of hidden cells with various formulae in, as far as I know all essential. There is also formatting (alignment in particular) of even some empty cells, so I do not recomment cutting out numbers in columns Q/F to T/I for example. Instead I suggest copying some blank cells and pasting them over corresponding cells in the same column, or going back to a blank spreadsheet. On the Psion 5 versions of the spreadsheets I have taken some care over column widths and row heights, so I do not suggest changing those (or the font size) however you may want to freeze some panes - which I have not done as opinions may differ on which ones - but see the formal bit comments below.
DBR is actually simpler than DBM as far as the spreadsheet is concerned. Column A should be left blank (if not an error will result) since the regular/irregular distinction has disappeared. DBR version 1.0 armies may only have three commands, so column I should be left blank (again if not an error will result). Later DBR version armies may have four commands and use column I. Obviously the list of element and fortification (it is convenient to use the DBM term in this description) types is different. Note that F3 and F4 have been used for three and four sided redoubts. An error will result if a DBM type is used (or a DBR type if DBM is selected). There are no suffices for DBR troop types (no chariots, compulsory double basing or mounted infantry) except for ShpBg. The DBM notation Bg is used for DBR land baggage (the DBR army lists use Bge).
Some DBM terminology has been retained on the spreadsheet even in DBR mode. In particular "Demoralisation level" (DBR actually uses "broken" rather than "demoralised") and "Element equivalent". In DBR terms up to version 1.1 the latter means "Non-baggage element", while in version 2.0 this is "Morale Equivalents". This should not cause a problem. (Note that the different DBR formula for overall loss has been implemented.)
There are four columns in the second set of columns. The first two (K and L) may be used to define maxima and minima for each element or fortification row. An army will be determined to be invalid if the total number of any element or fortification row is less than the indicated minimum, or greater than the indicated maximum. Note that a blank minimum or maximum indicates that there is no constraint. A total less than the minimum is indicated by a negative number in the errors column, a total more than the maximum by a positive number in the errors column. If neither constraint is violated then the errors column is left blank. Note that a maximum of zero is permitted; this is to permit the full use of the feature as described in the second example below.
If either constraint (minimum or maximum) is violated then, in addition to error indication described, the overall army validation fails.
A simple example of the use of a minimum and a maximum is provided by the Hunnic army list (Book 2, 2nd Edition, List 80) where
Huns - Irr LH(S) @ 7AP 20-80may be indicated by Irr, LH and S in columns A, B and C respectively and 20 and 80 in columns K and L respectively.
A more complex example is provided by the Seleucid army list (Book 2, 2nd Edition, List 19) where
Asiatic archers and slingers - Up to 1/2 Irr Bw(I) @ 3AP, rest Ps(O) @ 2AP 6-20may be implemented using two rows, taken here for example to be rows 16 and 17, although in practice they would probably be lower down. In columns A, B and C put Irr, Bw and I, respectively in row 16 and put Irr, Ps and O, respectively in row 17. Noting that J16 and J17 contain the total numbers of these two element types, and are set to zero as soon as columns A, B and C are set (a change from the first spreadsheet, for precisely this reason) the minima and maxima may be set:
In addition to the various element or fortification types in rows 16 to 60 which may be constrained by a minimum or maximum, the army points in row 12 and the number of elements in row 13 may also by constrained by a minimum or maximum (also in columns K and L). The former is usual, the latter less so.
Maxima and minima formulae may use cells from column J freely, as above. They are not intended to have to use any other values.
Army lists contain other constraints than simple minima and maxima. The second example above shows a case which can nevertheless be straightforwardly handled by using the minima and maxima. Some examples are less straightforward. From the same army list (only after 167 BC)
Argyraspids - Reg Pk(S) @ 5AP 3-12 Upgrade argyraspids to "Roman Argyraspids" - Reg Bd(O) @ 7AP Half/0It is possible to handle this case using the minima and maxima only, but it is not very satisfactory. For cases such as this the spreadsheet provides an additional constraint option. Column N may be used for general free text comments (e.g "Roman argyraspids" or "must be in ambush") but if a logical expression is put in any unlocked cell in column N, and if that logical expression is FALSE, then the consistency check fails. Considering the above example and again using rows 16 and 17 (note that the consistency check does not need to be in either of the same rows, but this is convenient) an implementation is to set A16, B16, C16, A17, B17 and C17 to Reg, Pk, S, Reg, Bd and O, respectively, and to set:
If such a consistency check fails then the visible sign is the occurrence of FALSE in a cell in column N. The overall army validation also fails.
The consistency check options are limited only by the spreadsheet formula maximum length, which should be sufficient for any reasonable constraint. Also note that constraints may use any other visible cells in rows 12 to 60, but to use any cells other than those in column J care must be taken, for example cells in columns F to I may be blank rather than zero; note that the SUM function can successfully handle blank cells.
Two suggested particular uses of the consistency check are to ensure that all appropriate naval elements have landing forces and for validation of allies. The latter may include ensuring that ally generals use only troops of their own nation, and that these are not incorrectly used by other generals, or if of the same nation that they have the required minimum number of elements of each compulsory type. This may require setting up a spreadsheet for a specific combination of allies, with ally generals pre-entered in order to define which columns to use in constraints.
You must own the appropriate DBM or DBR rulebook(s) to use this spreadsheet, and own any army list book you enter material from. (No, I cannot enforce this in practice, it's an honesty thing. I agreed this one with RBS.)
You may distribute either spreadsheet further, but only in its original form. (I do not want the blame for any faults introduced, or "credit" for any "improvements", I like it as it is, and I also do not want it distributed with bits of army lists in it - this would also violate the paragraph above.) I also suggest checking my website before distributing what might be an old copy. Better still would be just to pass on the URL.
I am not even going to suggest you do not hack around inside the spreadsheets. (If you really feel like doing this I have a few programmers' notes.) If and when you spot an improvement over one of my kludges let me know and I will think about incorporating it, especially if it speeds things up whilst leaving it easy to test and debug. Please don't distribute it however.
Faults (now corrected) identified by: Alan Montgomery. (Your name here if you find another one first.)
Currently I am christopher.dearlove@gmail.com. My web site is at http://www.mnemosyne.uk.
If you play DBM and/or DBR or any other games (not just wargames, board games are actually more my thing) and live (or work) in Essex, especially Chelmsford, England, drop me a line.
Last modified: 2nd October 2020 (updated contact information).