Just a question about the best approach to take for development of a five player version of the GMT Games Sword of Rome module?
With a friend of mine we have the OK from the game manufacturer to work on this, but wanting to make the existing 2-4 player module expanded to handle the 5 players expansion and also gradually implement a sensible number of rules/gameplay into the module itself.
Any suggestions from developers that have been down a similar path in the past would be appreciated.
I’m not very familiar with Sword of Rome (never having played it), but from what little I gleaned in a couple minutes of searching about what the 5th player expansion consisted of, I think you’d need a minimum of the following:
Adding the 55 Carthaginian cards
Adding whatever playing pieces are missing
Creating a “Carthage” player side and hand window
Touching up the existing module map to add a Carthaginian unrest track
Honestly, I looked at the Sword of Rome module and it’s really a bit of a dog’s breakfast compared to some of the better modules out there these days. If it was me and GMT was supplying me with some quality graphics, I’d just start over from scratch.
Thanks for the advice. I agree the module is showing its age. I play a fair bit of TS on VASSAL and am so impressed by the ease and function of the module. It is easier to play than face to face in real cardboard - perhaps the real test of the qualities of any module. I’m inspired by it, but don’t want or expect to achieve a similar result.
Starting from scratch sounds OK in theory, but being in software development myself, I wonder about the amount of effort required in the design phase to get this all right myself.
Do you or any one have any design artifacts for a start from scratch project like this? What sort of documentation or models would you keep to create a good design that is maintainable and extensible for incremental improvements?
Maybe a bit of an open ended question - but if you never ask, you never find out!
They’re good questions. First I’d recommend the Module Designer’s Guide. It pre-dates VASSAL 3.2, but still has great content that’s very relevant and applicable.
Generally, I think it’s worth putting in time up front on getting your graphics done the way you want. For example, the current module’s PC markers would look a lot better as PNGs with a transparent background so they actually look round, instead of round against a square white backdrop.
Then I’d spend some time thinking about how you’d like the experience of actually using the module to work. Right now it seems like there’s a lot of window fussiness–each player has a window just for his draw pile, and a separate window for his hand. Maybe the player decks can go on the map window off to the side, similar to how the discard piles are. Then instead of having people literally draw their own cards by dragging them around one by one, set up a toolbar menu-driven system to deal them. This really speeds things up. Does each player have a fixed force pool? You might take all their units out of piece palettes (which allow creation of unlimited numbers of pieces) and put them in At-Start Stacks somewhere and prevent their deletion. It looks like PC markers currently stack with units, which is usually really obnoxious for a user. Employ Game Piece Layers to regulate the top-to-bottom drawing order and what types of pieces can and cannot stack with each other–e.g., PC markers should always draw beneath land units and never stack with them. How much reporting do you want to do? I like to put in quite a bit, so a user gets feedback on something they (or someone else) just did. Piece elimination, movement of a marker on a game track, card plays, etc.
You can go in a lot of directions if you have the motivation to try experimenting. I’ve spent an inordinate amount of time on my modules (also CDGs) and I can’t seem to stop fiddling with them–I’ve implemented card dealing and now a fair amount of information tracking, including VPs. Things can get pretty elaborate behind the scenes, but the ability to use Named Keystrokes now has really helped keep things straight, since you can assign human readable unique “keystrokes” to things, helping you avoid getting lost in a morass of similar-looking things like Ctrl-D, Ctrl-Alt-D, Ctrl-Shift-D, Alt-Shift-D, Ctrl-Alt-Shift-D, and so on.
Thanks for some more great advice. Especially the ideas around PC markers. This is a real hassle when playing with the current module. As PC markers ‘change the map’ another good feature would to be able to show the ‘map’ with the PC markers in place - i.e. just hide the units and leaders. What approach would you use for this?
Reporting is a key feature and is great to check back on the action, but also in tracing what the VASSAL module is doing in the case of debugging. Is there a way to have a debug level set to enable more detailed tracing during development and testing only?
Another feature i want to implement is the play of events to reflect placement of various markers on the map ‘e.g. Wild Beasts, etc’. TS does this well with its [semi-]permanent event affects. Not sure how to go about this, perhaps the Named Keystrokes come into play here … and thanks for the tip on the Named Keystrokes - this must be a new feature of 3.2? Does anyone know if the designers guide is due for a refresh, or where I can find a summary of new features?
Joel - would you be OK if I PM’ed you with further questions - otherwise, more than OK to continue to explore design approaches here.
I’m thinking an incremental approach is probably best here. Am thinking about planning out a series of sprints (agile style) to implement feature sets in small increments.
I’m the author of the TS module. I thought I’d jump in to warn you that
you’re not going to be able to do a lot of the things that that particular
module does as it uses custom code rather heavily. Persistent effects can
be done with Global Attributes, but at a considerable cost in performance
depending on how many persistent effects you’d have. I attempted to do
this in TS using basic traits, but it was pretty tough.
You can open up the TS module in the module editor and gasp at the horror.
Many lose their sanity at that point.
Thanks for some more great advice. Especially the ideas around PC
markers. This is a real hassle when playing with the current module. As
PC markers ‘change the map’ another good feature would to be able to
show the ‘map’ with the PC markers in place - i.e. just hide the units
and leaders. What approach would you use for this?
Reporting is a key feature and is great to check back on the action, but
also in tracing what the VASSAL module is doing in the case of
debugging. Is there a way to have a debug level set to enable more
detailed tracing during development and testing only?
Another feature i want to implement is the play of events to reflect
placement of various markers on the map ‘e.g. Wild Beasts, etc’. TS does
this well with its [semi-]permanent event affects. Not sure how to go
about this, perhaps the Named Keystrokes come into play here … and
thanks for the tip on the Named Keystrokes - this must be a new feature
of 3.2? Does anyone know if the designers guide is due for a refresh, or
where I can find a summary of new features?
Joel - would you be OK if I PM’ed you with further questions -
otherwise, more than OK to continue to explore design approaches here.
I’m thinking an incremental approach is probably best here. Am thinking
about planning out a series of sprints (agile style) to implement
feature sets in small increments.
You can lift this technique from either my Here I Stand or Virgin Queen modules (though I’m sure plenty other modules do this). You need to be using the Map Window-level feature called Game Piece Layers to do this. PC markers, units, and leaders (at a minimum) will need to have a Marker trait that specifies which Game Piece Layer they belong to. Then you can add a control within the Game Piece Layer node in the Editor to toggle the visibility of one or more layers.
Since I don’t know the game, I’m not entirely sure what you mean by this. If you’re talking about markers that are simply placed somewhere to denote that “Event X happened at some point”, this would be pretty easy. If you’re talking about new game units that get added to the map (and the player has some choices in where they go), it would be considerably harder.
I think you could make the “wild beasts” marker an at-start-stack with two layers, one being a blank layer and the other using a scan of the marker. Have the card event set off a global key command and use a trigger on the at-start-stack wild beast pieces that increments the layer. This would of course just be a visual marker and not actually have any enforcement.
If you guys keep your discussion public, I’m sure it will only help other designers who come across the same issues and are looking for answers. There’s a lot you can do with vassal but not a whole lot of (up-to-date) guidance on how to get it done. I’m sure folks would appreciate whatever info they can glean from this thread.
This is really assisting with my understanding about how to go about building the module.
Will also keep the discussion online!
Are ‘At-Start-Stacks’ also the best way to manage the action round and turn markers i.e. one stack per round/turn? And then use global key commands in conjunction with the turn controller to trigger updates to the active layers in the stacks? I see this or something like it in the TS module.
I am i there now … and it is not too scary - just big! I can’t figure out though, how you display the count of the cards in each hand in the toolbar of the main window. Is this supported by the engine, or one of your customisations?
You can open up the TS module in the module editor and gasp at the
horror.
Many lose their sanity at that point.
The next version of VASSAL will make this easier.
M.
I am i there now … and it is not too scary - just big! I can’t figure
out though, how you display the count of the cards in each hand in the
toolbar of the main window. Is this supported by the engine, or one of
your customisations?
I’m having difficulty with Game Piece Layers and At Start Stacks. I’m pretty sure I am doing the right thing, but not getting the right outcome. My At-Start-Stacks do not seem to work - i.e. they do not display at all, no matter how simple I make them (including counters with just a basic piece trait with image and no layers). Is there a trap here for newbies? Any common faults I should look for?
Are you entering XY coordinates for the At-Start Stacks, or moving them where you intend for them to appear? Can you post the module you’re working on to Dropbox or some other place where I could download and take a look?
Most modules don’t do this. It’s far more common to simply create a zone (Turn track) and within that zone have a grid (turn 1, turn 2, turn 3, etc). As each player takes his turn they can drag their turn marker into the next region of the grid and it will report it. I can’t comment on the turn controller / at-start-stack combo as I haven’t messed with the turn controller myself. It sounds like it would work but it’s certainly a lot more labor intensive with making all those stacks.
I would caution you on using the TS module as your template though. It’s certainly a fantastic module, easily the nicest one I’ve seen, but it’s designed from the ground up with custom classes in mind. If you’re not willing to go to the same lengths, you might find that the lessons it teaches won’t carry you very far.
I have uncovered my mistake (at least one of them). I was using the layer trait in the counter in the at start stack, and the first layer was blank (no image). So I could not select it at all, thus could not see it, or adjust the layers via menu commands. Once I set this to be a real image, it displayed and could manipulate it. I am using an irregular grid on the map with locations and setting the at-start-stack to be at these locations.
I have also decided to start from scratch with a new module so I can go step by step and know what I have done and what works and when I stuff up!
So I now have the basics covered for PC and Loyalty control markers. I’ve use a prototype so I can re-use a common counter definition/behaviour. Also used do not stack as these will need to be operated separately from unit counters.
Next step is to establish game piece layers to support a display button which shows the control markers, but hides units and leaders.
