Sword of Rome (GMT) - Planning 5 Player Rework

Hi Joel

  • Establishing/renewing alliances
    For alliances, I think I will have an at start stack at each alliance box, and allow players to simply click them on and off. Further controls could be added in terms of when a player should be able to make alliances, and also have the rest of the game understand this through a set of global properties - but this is probably not mandatory for the first working version

  • Everything Units and Leaders
    For Units and Leaders, this is a bit more complex. Simplest is to have a vsav for each setup, and counter tabs to hold pieces to add during the game. I am considering having this all driven from a set of menus to allow units and leaders to be added via right click - not sure whether this is the best way. As for leaders, some special handling is required to allow for arrival of leaders via card events, displacement, etc. Also, I need to replicate the randomisation of Roman Consuls in the reinforcement phase. So this is a bit trickier.

  • Everything Cards – ideas about how to structure this is welcome
    For Cards I was thinking of a single mapboard with all the card decks and discard and remove piles. Hoping to have the game manage the deck dealing, shuffling and right click to play card (to the mapboard) then allow player to play for ops etc from there. As per TS then have the advance the turn counter to then send the card(s) in play automatically to the correct pile. Some card events will result in arrival of units and leaders, effect events (with associated game status and markers). There is much possible here, but you get the idea I’m sure. Oh and each player has a private hand or hands. Card design will be layered using prototypes as per TS example which is an excellent example of re-use and is a way to build each card both visually and behaviourally with the visuals confirming the definition of each card, i.e. the stuff you can’t see easily!

  • Managing differences due to different number of players in game
    Different number of players in the game imply different setup, and restrictions. e.g. 5P game has Carthage as a player and additional cards, VP spaces etc. Need to determine a mechanism to effect these differences dependent upon the number of players (game type) selected. This is the one that scares me the most as I am concerned this will break some of the work done to date which is aimed at the 5P version. I guess its hard to plan for this and know which techniques will work ok in these situations and which ones will generate a bunch of rework! This will be another VASSAL Learning experience!

I guess I am after some guidance here rather than specifics (they will be needed :confused: ), but whatever you feel you would like to contribute will be taken on board.

Thanks again for your interest and support,

Com

thanks. its slow going at times, but there has been the occasional ‘Yes’ moment with a fist pump! :smiley:

Just checking in. How goes the grand experiment?

Things have been a bit slow of late.

Work and life in general has been very busy, and focusing on some other gaming projects.

Unfortunately, one of our gaming group involved with our regular VASSAL gaming events recently died unexpectedly and so has reduced my enthusiasm for the task. However I will get back to it soon.

Thanks for checking in and look out for some progress soon.

comdotski

When you get back to the SoR project I’d love to see how it turns out but I can understand taking a break from it. I’m sorry to hear about your friend. A tragedy like that can understandably take the energy out of a project.

Well, its been a while, but I’m now back to the task. I’ve decided to focus on the graphics first and have used GIMP and the files supplied by the friendly and cooperative guys at GMT to generate the layer artwork for the counters and cards. No small task!

My question is what format to save the graphics in?

Are there better formats for quality vs saving space?

I am using the layering technique for the cards (and associated use of markers and prototypes) used in the the TS module to minimise the amount of graphics in the module while still achieving some reasonably faithful graphics.

Thoughts and suggestions?

Thus spake comdotski:

Well, its been a while, but I’m now back to the task. I’ve decided to
focus on the graphics first and have used GIMP and the files supplied by
the friendly and cooperative guys at GMT to generate the layer artwork
for the counters and cards. No small task!

My question is what format to save the graphics in?

In what format are you receiving the artwork?


J.

Hi Joel

Original artwork is in jpg format.

Tim

Thus spake comdotski:

Hi Joel

Original artwork is in jpg format.

That’s too bad. I was hoping you were getting it in a vector format
(SVG or PDF) instead of as a bitmap.

What are the dimensions like? E.g., how many pixels on a side is a
card in the artwork you have?


J.

J.

Card size is 360x505 px

Tim

Thus spake comdotski:

J.

Card size is 360x505 px

My recommendation is that you do not scale the JPEGs you have yourself.
If they’re too large for normal play, then set the default zoom level in
your module to something smaller than 100%.

IIRC, the cards in TS were done using SVG, with some embedded bitmaps.
The prototypes etc. used by the cards have to do with card behavior,
not display.

Can you describe a bit more what you’re trying to do?


J.

OK - will try not to scale the card image itself - yet to see how the cards themselves at this size look on the map size I have.

Yes i think all the TS graphics are SVG. The prototypes are employed (at least in part) to create re-usable graphics layers for the common elements, e.g. American/Russian/Both Card Types, Early/Mid/Late War Card Types and so on. I have similar problems to solve in terms of common card attributes which are the same across many cards, and I plan to use layers to build up the card from a background (all cards), card owner (i.e. Gaul/Roman/etc), Ops Value, and so on. I am trying to:

  • mimimise my work (and rework) by using prototypes to build up common card attributes, and graphics layers
  • align card graphics to card attributes within the prototypes to improve visibility of the accuracy of final product (expose/avoid bugs more easily as the card attributes and visuals are aligned)
  • minimise the size of the graphics required to have a rich display of card information close to the original game
  • create a structure that form the basis of further automations in the game play via VASSAL (focusing on facilitating the game mechanics rather than rules enforcement)

Its a bit hard to explain the details I guess - in part its a nice problem solving activity and I am keen to learn what of the good work in TS is usable across other CDGs (at least the non-coding parts).

I will be offline for a few weeks while on holidays - no laptop going with me.

Feel free to reply - I will be on this regularly when I’m back. Thanks for the guidance, questioning and prodding to date.

Tim

Just a quick update on the cards …

I am using GIMP and have noted that the output card size is too large for the map, not greatly, but if I decide to allow card play to display onto the map, I think I will need to reduce the image size at some point in the process.

I have also noticed that if final images are exported as JPG then the transparency area of the images do not work too well, i.e. the transparent part of the image displays as white when displayed on the map in VASSAL. I have discovered that if I export as PNG then the transparent part of the images do appear transparent on the map in VASSAL.

As such I think that I will be using PNG as the final format imported to the VASSAL module.

Do you forsee any issues?

Thanks

Tim

Thus spake comdotski:

I have also noticed that if final images are exported as JPG then the
transparency area of the images do not work too well, i.e. the
transparent part of the image displays as white when displayed on the
map in VASSAL. I have discovered that if I export as PNG then the
transparent part of the images do appear transparent on the map in
VASSAL.

This is because the JPEG format does not support transparency.


J.

Err … OK :blush:

This is an educational activity.

Thanks again.

Tim

Just thought I would let you all know that development has recommenced in earnest.

After much toil, the artwork is now complete, including extensive use of layers to create the card artwork (thanks to the creators of GIMP). The card artwork layering is aligned to the use of prototypes to also build up card display and behaviour. For those who are interested, I have included an image of the hierarchy of prototypes implemented. This approach and work is largely influenced by the work done in the current TS module (if you see this Mike you will instantly recognise the structure). I have chosen this approach as these are both card driven games with very common card mechanics. As such the below is a guide that could be used and modified for many card driven games. Using this approach I am able to incrementally add functionality to the module and avoid extensive rework at each stage.

[attachment=0]Card Prototype.PNG[/attachment]

A quick update on progress …

The Decks are now complete, and all card management for the 5P game is done including:

  • 5 Decks and 5 hands for each player (private)
  • At Start Stacks for Desperate Times Cards in each Hand
  • Standard multi and specific card selection for Drag and drop from decks to hands
  • Command driven menu for play of cards to map area with auto reporting and send to location
  • Context sensitive Command Restrictions, e.g. Plebeian Event cannot be played after Licinian-Sextian Laws Event played, Reinforcement only allowed for 3 Ops value card, etc
  • Out of sequence cards, i.e. Response, Bribes, etc played to alternate space on map, again automatically
  • At switch of active player or end of action rounds (driven by turn counter), cards sent to appropriate discard or remove pile automatically
  • At end of turn (driven by turn counter) a discard pile with a Reshuffle Card is sent to the appropriate deck
  • SPECIAL (Neutral Power Activates) Cards automatically set the indicators for Power Activated/Unrest Track Increased, and disables further activation by NPA card play - resets each action round start

Now working on making sure all the events for each of the cards that can reasonably be automated is automated (e.g. Event Markers, leaders and reinforcement placed on the map).

Many features possible, just have to decide how far to take it - pushing the envelope now I think!

Near horizon activities include the unit counters themselves, and completing the implementation of the ‘space’ behaviour (PC and Loyalty markers - nothing to do with ‘Ground Control to Major Tom!’).

The end is in sight, but a lot of ground to cover yet.

OK - so I need some help with designing the following feature. Hoping someone can provide some insights!

Many Sword of Rome cards have events that bring leaders and / or reinforcements into play. For most of these reinforcements strength of Combat Units (CUs) is known, so I want to automatically bring these new counters into the play area to speed up play.

I am struggling with the the best way to do this.

For Leader counters, this is fairly easy, as there is a fixed number and type of counters. Here it is just a matter of using Global Key Commands from the cards and Triggers watching for the GKC on the counters, to enable sending the Leaders from at start stacks to a reinforcement zone on the main map. These at start stacks would be on a separate map.

The same technique doesn’t really work for CUs, as CUs of the same side and strength can be brought into play for many different events, i.e. they are not really unique like leaders. Also, some of these events can occur multiple times through repeated play of the same card during play (the ones that bring CU only into the game). As such use of at start stacks as per the above description for leaders does not work that well. I have thought about maybe trying to clone a piece before sending it to the reinforcement zone (to enable later clones and sending to occur), but not sure how this will work.

Ideally I would also like to use a similar approach for the reinforcement phase of each round to bring the right number of CU into play for each side into the same zone.

If you have any good ideas please let me know.

TIA.

So I’ve been trying to use the clone approach from pieces in at start stack, but the clone seems to only work once. Do I have a bug in my module or are there restrictions on use of clone command for pieces in an at start stack??

Help! I have been debugging for about 1 hour without luck.

More data on the above problem - note that the clone approach seems to work well except for this one problem.

Any immediately following activity (move, click) on the card - which initiated the clone and send to location behaviour on the piece in the at start stack - causes the clone to be moved as well. It gets moved to a different location, to the nearest location (irregular grid used with snap to grid on) in the top left hand corner of the map.

Alternatively, if the card is not the subject of the next activity (e.g. click or move another piece) then the cloned piece stays in the at start stack it was created in.

Struggling with this one. Any help appreciated. If I need to post vmod and vlog files please let me know.