ADLG: Army List Database

Introduction

I'm in the process of writing my own army list spreadsheet for Art de la Guerre (ADLG).  There's a free spreadsheet online but it doesn't really suit how I write lists.

Ideally, I wanted more than a form to fill in. I wanted information about the list highlighting the options available and more built in list checking. My list sheet is nearly finished but to make it work I needed a databse of army lists.

The database described below was later used to build a search tool. With this lists can be sorted by terrain, date, period and sub-period as well as fine tuned for tournament themes.

Data structure

A database is essential to provide all the top level army information in a display something like this:

Data structured this way also allows all sorts of automated checks; command points used; the legal inclusion of a strategist; and the use of allies amongst others.

In the end I added the following fields to the basic list of army numbers and list descriptions:

• Terrain
• Command value
• Army Dates (as separate from and to dates)
• Strategist & dates
• Allies & dates

The results of my labours are now available online.  There's a date search that should really help those organising tournaments.  Perhaps you'd like to use it to write your own list spreadsheet?

If you'd like to know more about the database structure, how it was built, and the various issues I encountered then read on.

Rationale & advantages

When I've written lists in the past I've never paid more than cursory attention to things like command points or terrain options: I mainly focused on the number of units and the points total.

Coming back to list writing after an unenforced break I realised I was in danger of not maximizing the potential of the lists. So I wanted all the top level options visible on screen whilst I was writing my lists. I know they're all in the book but read on.

Lists for competitions are checked so it makes sense to use the top level information to check as much of the list as possible before it's submitted. Even better if some of the checks can be automated.

Dates (an aside)

One infuriating thing I noticed: the use of after and from when specifying dates. Their use appears random. This is important because "after 1150 AD" is not the same as "from 1150 AD" and could lead to strange one year gaps in the dates. It's sloppy and unnecessarily confusing.

List complexity

At first sight adding the extra data seemed an easy task if onerous. Alas it wasn't even that easy. To work as a database each line in a table must be unique. For a lot of lists this isn't a problem but for some the list branches repeatedly.

Eventually I ended up parsing each list, just as a list checker would, and I have tried to ensure that every branch within a list has it's own entry in the database.

A new record (line) was created where each branch had either a different set of terrain options, army dates, command value, strategist(s), or set of allies.  Branches which did not affect these values were ignored.

Examples (V3 lists)

Take terrain. For most lists there's one list of terrain options; except when there isn't. With list 46 (Graeco-Bactrian & Indian) the list is actually two lists but the Bactrian terrain differs from the Indian terrain. To deal with this issue I created two entries for list 46 (46 & 46.1).

Five lists were split because there were two non-contiguous pairs of dates. This split was necessary to give unique "from" and "to" dates for each list; which is essential if you're checking date restricted lists.

This pattern of exceptions continued throughout the lists. I assume the list writers compressed many lists into one to save space in the printed book.

Here's another example. With list 61 (Hellenistic Greek) two lists were required because one nation (Sparta) had a different command value to all the others.

Such issues with "simple" parameters such as list dates, terrain choice and command values, where you would expect only one parameter for each list, were nothing compared to the situation with allies.

With List 41 (Early Successors) the list had to be split into three because of the list of allies. This time it was because one strategist was associated with a specific ally and one nationality (Macedonian) was associated with another (under certain leaders - not strategists). The third list covers everything else.

Of course it would have been possible to deal with some of the above by entering the data from the list as written. With list 61 above the command value could have been "4 or 5 (Sparta)". However, this has a major disadvantage: you can't write a simple, automated test using the text but you can with either "4" or "5".

Extent of branching (V3 lists)

This table shows why the lists were split and how many subdivided lists were generated:

	Reasons For Spilt Lists
Period	None	Allies	CP6	Terrain	Dates	Total
Ancients	36		2			38
Classical	31	18	10	2	1	62
Roman	24	25	6	10		65
Dark Ages	29	23	2	18	2	74
Feudal	34	23	3	2	2	64
Late Middle Ages	39	16	2	2	4	63
Americas	17					17
Grand Total	210	105	25	34	9	383

Most of the split lists were due to the inclusion of allies in the database. The next table shows the number of lists that required splitting and to what extent:

	Lists Split
Period	2	3	4	5	Total
Ancient period	1				1
Classical period	9	3	1		13
Roman period	17	1	1		19
Dark Ages	10	7	1		18
Feudal Age	10	2	1		13
Late Middle Ages	7			2	9
Americas					0
Grand Total	54	13	4	2	73

Most of the 73 split lists were split in two (54 of 73) with most coming from the Classical to Feudal periods.

End result (V3 lists)

The pattern of branching illustrated above meant I ended up with 383 lists rather than the 283 lists in V3. 210 (of 283) were unchanged and the remaining 73 lists were split to produce 173 sub-lists (an average of 2.37 lists per split).

The list branching is the biggest potential weakness of the database. It is impossible to know if I have parsed every list correctly and in the same way that a list checker would when lists have been submitted for a competition.

Postscript

Following the release of ADLG V4 the database was updated to to include the new lists (checking for branching) and all lists were renumbered accordingly.

Document history

• Created: Fri 19 March, 2021
• Updated: Sat 17 January, 2026