I think it would be a really good idea for you to formulate a policy on this. Currently, each Wiki page is converted into a single project. Take for example The Russian Campaign
The new project is owned by 5 users, some of which seem inactive at this point. Some of these owners seem to have no relation to each other, and it seems odd that they should collaborate.
To make a new package in this project it seems that one would need to get the OK from one of these owners.
On the other hand, if that cannot be obtained, possibly because the owners are no longer active, then a module developers only other option would be to start a new project. This has some consequences, unless projects are subordinate to some Game entry:
When a user searches for Russian Campaign, several pages will show up. The user is then left confused as to which page to visit.
The data which is common to the various projects of the game (e.g., playing time, number of players, publisher, etc.) is not shared among the various projects.
If you have a single project per Game and leave it up to the project owners, then I think you will quickly end up in a very difficult situation where you as administrators will need to intervene quite often.
I would recommend to make a policy that says
Each Game - defined by it’s corresponding BGG - can have several Projects. Registered users can make new projects under a Game more or less at will. A new Game is made by the site administrators on request. The Game page contains
Publisher
Year
Time-to-play
Number of players
A description
… and other tags
Owners of a project under a given game are contributors to a game, but does not own it.
Each Project is managed by one or more users. Managers of projects are silo’d to their project. Managers of projects can create new Packages within their project more or less at will. Perhaps third party registered users should be able to request a new package under a project. Each project has
A number of maintainers
various tags
a description
a summary description to show on the Game page
All Packages of a Project are managed by the maintainers of the project and possibly designated contributors. Packages has
Various tags
A summary description
A number of versioned files
The point is, that projects does not seem to map to what in the old system was called a Module or Game. Thus, you may end up in a situation where you will have several Projects that correspond to a single Game and they would all be shown as independent search results in the Game Library front-end. E.g., if I search “Russian Campaign”, I would get a list like
(TRC) 3rd Edition 2.3
(TRC) 4th Edition 1.3
TRC 4th Edition by Toze Santos
TRC 5th Edition by Joel Toppen
TRC5th 1.0
TRC_5_2 2.0
A Victory Lost
Fortress Europa
while I think most would expect to see a link to a single page named “The Russian Campaign” with various projects underneath it.
Again, I think you need to formulate a policy. There could very well be diverging opinions on what project owners want - in particular when seemly un-associated users are co-owners. I think if you want project owners to take more ownership (and responsibility) for their projects, you have to make the ownership much more explicit and fine-grained. Otherwise it may turn into the wild west, and you as administrators will have a lot to do.
Sorry if this wasn’t clear. At the moment, it seems that most Packages only contains a single file (with multiple versions). However, I think that could be a problem. As I see it, a Package is mainly a container of a module (.vmod). But a .vmod may well have associated files - in particular logs (.vmod), saves (.vsav), and extensions (.vdmx) which would in many cases naturally belong in the same Package (not least because they may depend on the version of the .vmod).
A Package could of course also be a (set of) extensions, auxiliary files, and so on.
BTW. Auxiliary files that are specific to a Game (current Files packages) should be it’s own project.
My aim is to be much less interventionist than we are presently. You describe something that to me appears to require much more admin effort but then you go on to say it would require less. I don’t understand this. Would you explain further, as it doesn’t make sense to me on that point.
This essentially amounts to “what ever people want”, which I fear will lead to chaos.
I get that, and I commend that goal.
In the current foreseen scheme it is not clear to me if there are two separate sets of developers (a and b) that work on the same Game - say game G.
If the two sets of developers cannot come together - for example because a is dormant or similar, then it seems to me that b would need to create a new project. Thus, you will end up with two projects a and bboth relating to game G.
Both projects a and b will have the same game information (publisher, duration, tags, …) but this information is not shared between them in the database. If you want these two projects to be somewhat in sync it will take a major effort on the admins part because the two projects are silo’d.
Furthermore, when a user searches for game G, the front-end will then present two choices a and b and the user will have no idea that these two are both implementing G and what is not implementing another game - say GG. This makes it very confusing for the users.
Note that this is not “academic” - in the current draft database you have two projects that implement the same game Samurai Battles
In fact, there are many more in the old (and presumably new) library:
94146 57th Panzer Korps
Winter Storm: 57th Pz Korps Attempt to Relieve Stalingrad
43691 Advanced Delve Dice
Delve: The Dice Game
3044 Air Assault on Crete
Invasion of Malta: 1942
271852 Apocalypse: World War II in Europe
Apocalypse Europe: WWII
4252 Arden
Bulge: The Battle for the Ardennes 16 Dec. '44-2 Jan. '45
8722 BAOR
Central Front Series
10641 Barbarossa: Army Group South, 1941
GMT East Front Series Volume I
225909 Burning Mountains
Inferno sugli Altipiani, 1916
2795 Car Wars
Car Wars Deluxe Edition
13532 Case Blue / Guderian's Blitzkrieg II
Guderian's Blitzkrieg II
97 Conquest of the Empire
Conquest of the Empire: Imperator
1506 Conquistador: The Age of Exploration
Consequential
22359 Das Boot: Der deutsche U-Bootkrieg, 1939-1943
Steel Wolves: The German Submarine Campaign Against Allied Shipping - Vol 1
122588 Dungeon Command
Dungeon Command: Sting of Lolth
220133 Endangered
Enemy Action:Ardennes
715 Escape From Colditz
La Fuga de Coldit
62291 Fatal Alliances: The Great War
Fatal Alliances III Dreadnoughts in Flames
277123 Fighter Duel
Fighter Duel Lite
376104 Firebirds: Huey
Firebirds: Huey (OH-6A)
202989 Flying Colors
Under the Southern Cross: The South American Republics in the Age of the Fighting Sail
23312 Free At Last
Free at Last
21551 GBoH Interactive Map
S.P.Q.R. Deluxe
6928 GMT East Front Series Volume II
Typhoon!
4364 Gaines Mill
The Battles of the Seven Days
6938 Global War
Global War: The War Against Germany and Japan, 1939-45
2932 Hnefatafl
King's Table
12002 Jambo
Jambo +1st/2nd expansions
2487 La Casa de los Fantasmas
Why
11512 Leipzig: The Battle of Nations – Napoleon vs. Europe
Lepanto
25727 Lock 'n Load: A Day of Heroes
Lock 'n Load Tactical: Day of Heroes
99573 Lock 'n Load: Heroes of the Pacific
Lock 'n Load Tactical: Heroes of the Pacific
168274 Mistfall
Mistsmall: Mistfall in Your Pocket
5035 PanzerArmee Afrika: Rommel in the Desert, April 1941 - November 1942
Panzer Armee Afrika
8329 Pegasus Bridge
Pegasus Bridge: The Beginning of D-Day - June 6, 1944
Pensacola, 1781
234259 Rommel
Rommel (2017)
60386 Tactiques Napoleon - Auerstadt
Tactiques Napoleon - Battle of Eckmuhl, April 21st 1809
Tactiques Napoleon - Raszyn
Tactiques Napoleon - Tamames
Tactiques Napoleon - Teugn-Hausen
4084 The Alamo
The Alamo: Victory in Death
8719 The Next War
The Next War: Modern Conflict in Europe
32234 The War At Sea (first edition)
War At Sea
20627 Warplan: Dropshot III - Endgames
Warplan: Dropshot II - The Turbulent '60s
6770 Yom Kippur
Yom Kippur (1983)
First number is BGG identifier. This is an auto-generated list, so it may be wrong in certain places. Nevertheless it illustrates the problem.
The point is that
There is a many-to-one relationship between developer (groups) and games
There is a one-to-one relationship between developer (groups) and projects
There is a many-to-one relationship between projects and games
(and a many-to-one relationship between packages and projects)
Another way to say this, is that games are not tied to a specific developer (group), but projects are. If you do not capture this in your database, I fear that it will become very confusing to the the users and will create additional work for admins to sort out the possible mess.
Thus, I propose
Create a Game table in the database. Entries into this are managed by the admins. Ideally, this could be based on a BGG look-up. E.g., a user requests a new game, enters the BGG identifier, and the front-end queries BGG for information (title, duration, players, year, publisher, …)
When a user searches for a game, then this page is what is presented. On that page is also a list of current projects under that game together will a summary text for each project (and possibly maintainers of the project).
On the game page, there’s a Add project button. When a user clicks that, the user is
expected to put in
The project title
Summary text of project
Possible additional users to register as maintainers of the project
The admins may then need to OK that project creation, or it could be left open.
Projects without packages could be deleted after some time.
Users that are registered as maintainers of a project are registered as contributors to the Game.
If a user (or developer) clicks the project title, then the front-end takes the user to a new project specific page. On this page, there’s a button labelled Add package. When the Package maintainer clicks that, the package maintainer will need to enter
Package title
Possibly a short summary
Possibly other users (except project maintainers) that may contribute to the project.
The package is made automatically without admin interference.
Packages with no files will be deleted after some time.
Under a package there’s a button Add file, and when the contributor clicks that, it will allow uploading of a file to the package. The user is expected to give
A file to upload
Possible target file name
File version or 0.0.0 for un-versioned files.
Project maintainers are notified and are expected to validate the upload. If project maintainers fails to reject harmful files (viruses and the like), then those maintainers will be sanctioned.
In this scheme, the admins need only create Game entries, and depending on your temperament, OK project creations or file uploads. Creation of Game entries can be vastly simplified and streamlined by querying BGG. In the case that the game does not have a BGG entry, then a bit more work has to be done, the user requesting the Game creation should provide sufficient information.
In the current proposed scheme, it seems to me that a developer could create a project - say My fantastic modules - with a bunch of packages underneath - say Napoleonic Wars, American Civil War, WWI, WWII, WWIII, Uno, Catan, Hearts, and so on, which will surely be somewhat confusing to the users. What I propose is, instead of one project, such a developer will have projects sub-ordinate to the games. A user page may of course give an overview of all the games and projects a user has contributed to, if that is desired.
You say “You describe something that to me appears to require much more admin effort”. Perhaps it would be good if you could outline (a la above) how exactly projects, packages, etc. are created and how users will be presented with the result of search queries. I think that could perhaps clear up any misunderstands on my part. Thanks.
I think that is extra workload on admins. How about making it possible for developers to create a game entry themselves by filling in a form that creates the entry on the basis of BGG? If the entry already exists, the new developer could be referred to the existing page - where she could create a new project.
Here are the T’s from “thi” to the end. @jrwatts How far have you got in the beginning of the T’s. The latest I could see is that you wanted to do from the beginning to “Terrible Swift Sword”…This leaves a hole from “ter” to “the”.
Thirty Years War Thirty Years War Quad
The same game as “Thirty Years Quad”, but the old entry contains modules for each individual game, including a 5th game “Breitenfeld”. However, all modules except the first is missing in the new entry. Old and new entries are missing a title image Thirty Years War: Europe in Agony, 1618 - 1648
The latest version 1.3b is labelled 0.0.0 and is placed at the bottom. This Accursed Civil War
The old entry consists of a module for each game in this box, but they are also at different versions. This has confused the conversion algorithm so that three game modules are missing, and they are arranged together under the version numbers, even though they are not descendants of each other This Guilty Land This Hallowed Ground This Terrible Sound Thoughtwave Three Battles of Manassas Three Days of Glory 1805
There are three individual modules here, but only one has made it into the new entry Throne of Allegoria Through the Ages: A Story of Civilization Through the Breach
The contact email at the end of the Comments (now Readme) has been lost Thud and Blunder Thud Ridge: A Solitaire Game of the Air War over North Vietnam Thunder Alley
v2.01 is called 2.1 but it probably does not matter. Thunder at Cassino Thunder at the Crossroads (2nd Edition) Thunder on the Mississippi: Grant’s Vicksburg Campaign Thunder Road: Vendetta
Large title image. Thunderbolt / Apache Leader Thunderstone
Has no module in the old entry, and there is no new entry. Probably right so. Tic Tac Chec
v1.0 is called 0.0 Tic-Tac-Toe
One module (TicTacToe.vmod) missing. Ticket to Ride Map Collection: Volume 3 – The Heart of Africa
The single player Ideocrat is missing- Ticket to Ride: Europe
The single player Ideocrat is missing. Tide Of Iron
The entire section “Module Information” is missing from the new entry. The many .vmdx files that are tied to two of the module versions, are as usual separated from the parent module. This problem exists practically with every game with other files than modules. Tigers In The Mist
The version number of v00b089 is set to 0.0.0 Tigris & Euphrates
The comments included in the “File Type” column have been lost (including the “Don’t use” for v4.1) Tiles and Figs
v1.0 is called 0.3.0 Time of Crisis
The version number have been slightly changed, e.g 1.02 is called 1.2. Timetripper Tinian: The Forgotten Battle Tiny Epic Galaxies
The single player Ideocrat is missing. TINYforming Mars
Package is empty: Both files have been lost in the new entry. Titan Titan Strike! Title Bout To Be King
This page should probably be deleted. There is no module in the old entry, and the website that is referred to has been discontinued. To Take Washington: Jubal Early’s Summer 1864 Campaign To The Far Shore To the Green Fields Beyond: The Battle of Cambrai, 1917 To The Last Man Tobruk: Tank Battles in North Africa 1942 Tokyo Express
Most modules have been lost: only v0.9 (called 0.0.0) and v0.95 present. V0.96, 0.97, 0.98, and 0.99 are missing. Tomb Raider Tomorrow the World Tonkin: The Indochina war 1950-54 (2nd edition) Tonnage War Solitaire Too many Bones Torch Torgau Torgau 1760 Total War
v05a is called 0.0.0 Totaler Krieg!
TotalerKrieg.zip that apparently contains v1.53 is here listed under files as v0.0.0 Totaler Krieg! (2nd Edition) / Dai Senso
Complicated structure in the old entry that has not converted well: Under "Earlier versions prior to Totaler Krieg! 2nd edition and Dai Senso (2010) " the modules TK2_no_maps.vmod and TK2_base_1_00.vmod are missing. The heading "Original Game Files for Totaler Krieg! 2nd Edition plus Dai Senso (2010) " is gone. V9.0.7 is now 0.0.0. The saved games have been detached from their modules. Toulon, 1793 Tourcoing 1794
The images are not fetched in either entry. Traces of Hubris Traces of War Trader
V1.0 is called 0.0.0. Trafalgar Trailblazer Starmap
V1.0 is called 0.2.0 Trajan: Ancient Wars Series Expansion Kit Transformers Trading Card Game
v1.0.1 called 1.1.0 Trenches of Valor
v1.0 called 0.1.0 Trenton 1776 Triomphe á Marengo Triple Topper
The old entry has 6 modules that are different games, all v1.0.2. The new entry has only three modules, with different versions (none of them 1.0.2) and they are arranged as if they are versions of the same game. However, the old entry may be in error with the versions, because the Comments section mentions a version 1.1 that exists in the new entry. Trireme: Tactical Game of Ancient Naval Warfare 494 BC-370 AD Triumph & Glory: Battles of the Napoleonic Wars 1796-1809
This game entry has no modules, and as the Comments say, the maintainer’s link is dead. Triumph & Tragedy
The title image has been lost. An unfortunate version numbering (the early versions have v35 and 36, whereas the latest versions have v1.0 and 2.0) has placed the latest versions as older ones. Triumph of Chaos Triumph of Chaos v.2 (Deluxe Edition)
The latest version (with Japanese letters in the version in the file name) has been lost. Triumph of the Will Trivial Wars
No modules in the old entry, but a link that is inactive. Trollland
v1.0 is called 0.0.0 Tsukuyumi:Full Moon Down
v1.0.3 is called 1.3 Tuf Tuf-abet TuiShou7 Tunisia
The usual conversion error of converting versions like 5.0.1 into 5.1.0. Tunisia II
v1.10 has converted to 1.1.0 and has therefore ended out of the sequence between 1.09 and 1.11. Tupamaro Turncoats Turning Point
v1.0 has been lost, and v1.01 has been called 1.0 Turning Point Stalingrad
v1.0 has been numbered 0.0.0 Turning Point: The Battle of Stalingrad Twilight Imperium (third Edition)
v1.02 has been numbered 0.0.0 Twilight Imperium (third Edition): Shards of the Throne
There are two different v1.12 in the old entry. The one called TI3_Shards_8p_1.12.vmod is missing Twilight Imperium (third Edition): Shattered Empire
v1.0 has been lost, whereas v0.99 has been numbered 0.0.0 Twilight Imperium: Fourth Edition
v1.42c has been numbered 4.0.0 Twilight Sparkle’s Secret Shipfic Folder
Lots of modules with many different groupings, all of which have been lost. For instance, three modules from “Beta versions” have been put together with the latest version 1.1.5a (put at the bottom) and v1.0.2, whereas another beta has got its own group. Among the groupings that have been lost are also the translations. Twilight Struggle
The sequencing is not good, and there are some misnumbered 0.0.0, but in general the conversion has succeeded. Twin Peaks
South Mountain 1.2 and 1.3 have been lost. There is an error in the old entry where what was supposed to be 2.21 is the same file as 2.20. This has been converted only once, which is fine. Twixt
v1.2a (the latest) has been numbered 0.0.0 Two Deck Siege
The title image has been lost. V2.0 has been named 1.0 Typhoon!
Nonexistent module. Has not converted. Tyros
The old entry has a note that v1.3 is unavailable. This has not gone into the conversion. Türkenkrieg (1737-1739)
That’s also a possibility - it all depends on how much control the admins want over the content of the game library. I assume they would like to have some control so as to not get swamped in content that has nothing to do with VASSAL.
A compromise would be that a user enters the BGG identifier into a form, and all the admins need to do is to OK that. Of course, if the game has no BGG entry, then additional information would need to be entered.
The main point, though, is that projects should be subordinate to a game as that’s what users search for and it minimises information duplication and thereby admin work and maintenance.
I totally agree with the identifier tag from BGG being the index we can use, however as you mentioned in defining the “Game” with the meta data you presented there will still be a conflict (which BGG has resolved/dismissed somehow) namely -the publisher…
Example Game - Up Front.
It has four publishers listed, none are wrong, and all are the same version. Obviously one is generally accepted as being the main source but that is no reason to dismiss the others.
How would this be resolved in your setup with regard to your meta data
I still like where you are going - I think it is the right approach to leverage BGG and their data and we do less
In the BGG database the Game to publisher relation is a one-to-many relation, while in the VASSAL (current and future) database the relation is one-to-one. That is, indeed, a difference that proves something of a challenge.
What I did here was to use the VASSAL provided publisher. Try for example
./search.py "The Russian Campaign"
It will only list “Avalon Hill” as the publisher even though BGG lists 5 publishers, try
from json import load
with open('pages_bgg.json','r') as inp:
j = load(inp)
for k,d in j.items():
if k == 'The Russian Campaign':
print('\n'.join([f'{p["objectid"]:6s} {p["text"]}'
for p in d['bgg']['boardgamepublisher']]))
break
Unlike the BGG title, which can also be multitude for each game, BGG does not mark one publisher as the primary.
from json import load
with open('pages_bgg.json','r') as inp:
j = load(inp)
for k,d in j.items():
if k == 'Up Front':
print('\n'.join([f'{p["objectid"]:6s} {p["text"]}'
for p in d['bgg']['boardgamepublisher']]))
break
gives
5 The Avalon Hill Game Co
1391 Hobby Japan
23951 Radiant Gaming
13 Wizards of the Coast
Here, The Avalon Hill Game Co is obviously the main one.
I think the best way to deal with this, is to have possibly multiple publishers for each VASSAL game. The game page will then present a list of publishers (in no particular) order.
Of course, VASSAL could mark one publisher as the main publisher, but I’m not sure what the users gain from that, and it will create extra work for admins and project maintainers.
If a user searches the game library by publisher, it will make sense The Russian Campaign shows up when searching for L2 Design Group. In so far as a project or package is specific to a given publisher, I think that would best be represented by a tag a lapublisher:L2 Design Group. Many modules (.vmod) does not necessarily use graphics from a specific publisher but use new graphics (which also gets you out of a copyright problem).
Perhaps some VASSAL admin should reach out to BGG and let them know that the VASSAL Game Library Service will like to use their data. Perhaps there’s an opportunitet to collaborate between the two platforms. For example, if BGG gets the VASSAL game identifier back, then BGG could add a link to the VASSAL GLS to the main page of the game
old lib has 2 modules with identical filenames, marked as version 1.0 & 1.5.1 according to section headings - only 1 module in new lib
1 extension is only compatible with the later module but this info is not transferred to the new lib
Readme: link image missing
Gaines Mill
old lib says this is included in “The Battles of the Seven Days” module & has link
not in new lib
Galactic Adventures
module version number wrong
Galactic Emperor
module version number missing
Galaxy of D
module version number missing
Galleys & Galleons
module “Galleys_and_Galleons1_0_Fulles_Dades.vmod” version number missing
The Game of Shakespeare
missing - (Other modules by brian448) link
A Game of Thrones: The Board Game (Second Edition)
many different modules are mixed up in 1 Package - all the section headers which separate them in the old lib are moved to Readme (where they make no sense)
old lib has 2 modules named “AGOT2ED.vmod”, marked as version 1.3 & 1.1 according to section headings - only 1 of these modules in new lib
module “Gettysburg-v3b02.vmod” is in separate Package & missing version number
Ghost Stories: B-Rice Lee,
Ghost Stories: Chuck No-Rice,
Ghost Stories: Jean-Claude Van Rice,
Ghost Stories: The Guardhouse Expansion,
Ghost Stories: The Village People Expansion &
Ghost Stories: White Moon
old lib says these are included in base module (Ghost Stories) & has link
not in new lib
GI: Anvil of Victory
old lib says these are included in base module (Squad Leader) & has link
not in new lib
Gladiator
module “Gladiator_draft.vmod” missing
module “Gladiator.vmod” version number wrong
Global War &
Global War: The War Against Germany and Japan, 1939-45
these appear to be the same game but have 2 entries in the old & new libs
1 of the modules (Global War_v30.vmod) appears in both entries in both libs
Gloomhaven
14 major module versions all have 0-7 extensions each, all these extensions are now together in one Files section - only the designers careful file naming and versioning make it possible to tell which goes with which
module “GTC_3_03_Beta.vmod” version number missing
Grav Armor
missing - (Other modules by Mycenae) link
Great Battles of Alexander: Deluxe Edition
modules “GBoADE1_2.vmod” & “GBoA.vmod” missing
module “GBoACollection(6.6).Vmod” version number missing
Readme: bold text is not rendered as bold in new lib
Great Battles of Julius Caesar: Deluxe Edition
Readme: bold text is not rendered as bold in new lib
The Great Heathen Army
module “TGHA v1,21.vmod” has wrong version number - Files section layout and dates in the old lib make this clear, but this information is not present in the new lib. Also, in the new lib, the latest version (1.3) is in the “Older releases” dropdown
Great Medieval Battles: Four Battles from the Middle Ages
The code in get_vmod_info.py (a slight misnomer) is not intended to be omnipotent. That’s why the code in get_vmod_info.py allows for an external file with overrides (e.g., files_override.json) to catch cases where the automatic parsing fails. The overrides file is automatically updated with entries when the code cannot parse a version string, and the user can then edit that file (search for unknown) to specify the correct version.
The file files_meta.json contains the result of the version and file parsing. To see the converted version strings, do
from json import load
with open('files_meta.json','r') as f:
j = load(f)
v = {f['version']: f['semVersion'] for f in j.values() if 'version' in f}
print(f'| {"From file":20s} {"Parsed":20s} '*2+'|')
print(f'|{"-"*43}'*2+'|\n|',end='',flush=True)
o=0
for i,(r,s) in enumerate(v.items()):
l = f' {r:20s} {s:20s} |'
if o+len(l) > 100:
print('\n|',end='',flush=True)
o = 0
o += len(l)
print(l,end='',flush=True)
Sure there are some problematic conversion, but it is easily fixable by adding entries to files_override.json. The point is to stage the conversion, so that the code - which cannot ever get it right all the time - can be assisted by a human in a simple and straight forward way