ADLG: Army List Database

If you're regular reader you'll have seen that 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 as I needed a decent army list database.   A database is essential to provide all the top level information in a display something like this:

Data structured this way also allows all sorts of automated checks to be carried out; on 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 for anyone to use^{3 4}, copy⁵ and explore.  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?

I'm still in the process of double checking the data so if you spot any errors please leave a comment below.

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.

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
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 eitehr "4" or "5".

Extent of Branching
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 seventy three split lists were split in two (54 of 73) with most coming from the Classical to Feudal periods.

End Result
The pattern of branching illustrated above meant I ended up with 383 lists rather than the 283 lists in the rule book.  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).

These figures may change as I am still checking, and cross-checking, the lists.

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.

Again; if you spot any errors leave a comment.

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. I hope it's resolved in V4.

Closing Remarks
Now the bulk of the work has been done I will be checking the data over the next couple of weeks.  I have asked a few people, more knowledgable than I, to comment and I'll wait and see what they come up with.  So far the reaction has been positive.

Finally, I'm gald to have decided on the structure of the database and completed the data entry before ADLG V4⁷ is published; even though I will undoubtedly have to spend more time updating the database with any changes.

Links

1. ADLG Army List Writer at http://blog,vexillia.me.uk ↩
2. ADLG Army List Form V3.2 at http://www.artdelaguerre.fr ↩
3. View & use shared version online: ADLG Army List Data V3.01.03 (via Google Sheets).  Google account not required. ↩
4. As the spreadsheet is a shared file, not a true multi-user database, you may run into problems if two or more people are trying to use it at the same time. ↩
5. Save a personal copy to your Google Drive: ADLG Army List Data V3.01.03 (Public).  You may be asked to log into your Google account first.  ↩
6. Command Points. ↩
7. Rumour has it that there will be 300 lists in the new version up from 283 with more specific dates for allies and lots of new strategists.  Looks like I'll be busy once the new version is finally published. ↩