Creating a roster spreadsheet that saves between sessions (Up Front campaign)

Module Design
1

I’m attempting to incorporate the campaign system into the Up Front module. it requires keeping track of individual soldier’s stats as seen in the image.

20241120_192610
20241120_1926101920×1080 125 KB

I tried attaching the spreadsheet trait to a game piece and it worked to fill out the static info. That is the info put in by the module creator continued to appear between sessions. However testing it out as a player the info I put in for the soldier’s new stats didn’t last between sessions.

Any ideas on what I can do?

Here’s a thought I have. What if I make each roster sheet basically into a map? Each cell (spreadsheet language) would be a zone on the map where pre-placed (at start right) counters would exist. These counters would be simple VP like counters where they could adjust the number or image layers for stats that aren’t a number (rank). The names I might go with the actually card or make game pieces that show their name. Is there a way to make game pieces unmovable? Certainly the info put in this way by players would persist across sessions right?

2

Hi,

I hope you mean one map? If so, yes, that makes sense. If you mean one map per piece, I would be weary. See for example Battle of the Bulge - Smithsonian Edition. There I have a map with each and every counter in the game as rows, and columns with a check-button if the unit has been broken down into it detachments. In this case, it is mainly used for book-keeping (It’s in the OOB window - short-cut Alt-B - as Allied/German Detachments

To make pieces “immovable”, you would typically use a RestrictAccessTrait. That means that the pieces can only be manipulated through GlobabHotKeys and the user (possibly limited tto a side) cannot interact with the piece. Probably not what you want.

You still need the data to persist over sessions. For that, it probably means you have to store the data in GlobalPropertys.

However, I think that approach might become very hard to maintain. As I mentioned in another thread, I would make these stats Propertys of the pieces themselves. This should be implemented as a Prototype with properties Rank, KIA, Replaced, Morale, Panic, Rout, ELan, Survival, and Promotion.

Morale: 0-7
Panic: 1-7
Kia: 6-8
Rank: 1-3

I guess Promotion is really a function of some of the other properties.

This also has the benefit that the pieces themselves can use the information as needed. For example, your LayerTrait could follow these properties to show the correct image - or you can put LabelTraits on your piece that shows the information - as discussed in the references thread.

If you still want an overview table, that can be done too. In that case, when a piece has one of the properties changed (via a TriggerTrait), then that change is sent to a specific piece on the spreadsheet map too. For example, if the main piece’s name is Hessel_MP, and Rank is changed, then a key command is sent to Hessel_MP_Rank piece. It’s a little tricky, but it can be done.

Incidentally, for these kinds of things, I like to use my pywargame Python module to make the various pieces and command, because it allows me to program the behaviour making sure names are consistent and so on. I find that a pain to do in the Editor.

Hope that helps.

Yours,
Christian

3

Your map idea can work. To make pieces immobile though, the “does not stack” trait is more what you want. “Does not stack” is a poor name in my opinion because it has several functions besides stacking, primarily controlling movement. You can use it to lock down a piece or to move it only through special key commands. You can then change the values of these immobile pieces with right-click commands or even make them into buttons.

I think restricted access is designed to control who can manipulate a piece rather than controlling its movement in general, but if It can control movement, that’s something I didn’t know.

1 Like