Struggling to Understand Piece Movement

Hi everyone,

I’m a VASSAL newbie, reading the Designers Manual and looking at how other modules were built. I’ve learned how to build a Main Map and the pieces for my game. But what confuses me at this state is this: How do I dictate how my pieces move?

If I were building a chess game, for example, I’d want to specify that a pawn can only move one square per turn. A rook, however, can move an unlimited number of squares per turn, but only in rows or columns. (My main map is in a rectangular grid) When I look through the Piece Traits, I only see “Move Fixed Distance” as an available option for dictating movement. For the pawn, I could presumably say:

     Distance to the right: 0
     Distance upward:  1

But what of the rook? This option doesn’t seem to be a good fit.

Or do I not really understand how players will move their pieces in a game?

Thanks,
-ROA

Rule enforcement is not really what Vassal is about.

Typically, you just provide the pieces and leave the rule enforcement up to the players.

That is extremely important information, thank you. I’m a little embarrassed for asking, LOL!

Much appreciated

Vassal’s design background is to provide a Virtual Boardgame environment where players play games as if they had the game components in front of them. Players move their pieces by manually clicking on them and dragging them to to their new location.

Over the years, various ‘automation’ features have been added which allow the module designer to manipulate the game components in various ways when different commands or triggers are seen. These can be initiated by right-click menu options on pieces, or by buttons or menus added to the main toolbar, or initiated automatically by pieces after moving.

The amount of automation you add is up to you, but there are overheads and the more automation you add, you eventually reach thresholds that result in performance issues and the more ‘fragile’ and less usable the module becomes. (e.g. house rules).

Vassal was not designed to be able to implement the full rules of the game you are implementing, though many modules do implement some rule control/checking to a lesser or greater degree.

With automation, aim for the things that are really painful to do manually, or are done often.

Hope that helps.

If you are after rules enforcement for abstract games, you may be more interested in Ludii. However that too has a steep learning curve.

@Brent_Easton

Yes, this helps a tremendous amount, thank you for taking the time to write. I’m curious about the automation features nonetheless. I’d like to take a look at them, if only to determine that they’re too advanced for me and/or not worth the trouble. Its great to know what buzzword to use in a Google search: “automation”

Thank you!

@slimy

Thanks Slimy!

I actually am a beginning Java and C programmer; do you think those skills might help me learn a Ludi type tool?

THank you!

Most automation that doesn’t involve actual custom coding tends to employ the following features, which you can learn more about by reading the documentation on them (note: this isn’t an exhaustive list):

Trigger Action: Very powerful piece trait that can set off one or more keystrokes in a sequence in response to an inbound keystroke, optionally with a matching expression to control precisely the set of circumstances in which the Trigger “fires”
Global Key Command: Broadcast a keystroke to apply to other pieces–either everything or using a property match expression to identify a subset of pieces that should “hear” it, either by numeric/text property and/or zone/grid location
Dynamic Property: Keep track of numeric values in a piece or set any kind of string value as a status by which other module logic can identify the piece in property match expressions for doing automated things
Send to Location: Like it sounds, move a piece somewhere, often chained together with Trigger Actions to send something to a location if condition(s) are satisfied in the Trigger
Keystrokes applied to all pieces ending movement on map: This is configured on maps, and is very handy for making things happen when players drag and drop things into various places where you want a report to print to the game log or some automated action to occur.

Also, it’s important to understand that there’s no automation “feature” in the sense of a preference you can enable or anything like that–the things you can do are ultimately built up from traits on pieces that interact together. As you ramp up the complexity of what you want to, the mental flowchart you have to retain (e.g. which things talk to which others and when) goes up at least as much.

3 Likes

Obviously a progammer’s mindset is essential.

The language looks more like Lisp or Prolog though it is not much like them. It is declarative. You say this is what the board is like, these are the pieces and how they move etc. So that’s a bit prolog-like but it is more direct than prolog.

The big downside is that the poorness of the documentation. It has improved since I first started playing with it.

There is an interesting point of contrast with VASSAL. VASSAL is entirely a community driven project. This has the advantage that as long as the project is healthy people will respond to your questions.

Ludii is an academic project - primarily funded to study traditional board games. Modern abstracts are the community payoff. This has the big downside is that there is a 1-1 mapping between who knows the answer and the part of the project. If that person is off on holiday you’re stuck. We did create a guild on BGG to get round that.

So what you really need on top of a programming sense, is patience, dedication and a sense of humour.

P.S. Also “Ludii” is spelt with two “i”.

@slimy Wow, thanks Slimy. I’m tempted to poke at Ludii, but I don’t know Lisp or Prolog. And the lack of documentation is a big drawback for me.

Thanks so much for the inside baseball! I’m really learning a lot from you. :slight_smile:

As I said the documentation has improved. The page is here. You would want to read them I think in the order:

  1. User Guide
  2. Game logic guide
  3. Reference Manual

And I would start by trying to understand a game that is somewhat similar to the one you want to code.

@slimy Actually, this documentation looks pretty detailed. Maybe when I get into the weeds, I’ll find it thinner than I’d like. But there’s more here then I expected.

Thank you, this is really great. I think I’ll build the manual version of the game in Vassal, walk a through friends through it when its done, then pivot to rebuild a computer game version in Ludii. You’re awesome, thank so much for taking the time to write!

Vassal is not built for that, the players must enforce the rules.

It looks like Ludii started only a few years after I left U of Amsterdam, and I know a few people at Maastricht, but not anybody involved in this. It reminds me of a thing I wrote a grant proposal for in 2010, though I was looking at mainly the representation of rules and not so much the AI.

1 Like

@ChuckS
Ah, thank you, I feel foolish for asking. Much appreciated!

@uckelman
Interesting. A tool that builds both the board game and enforces the rules in a clear, concise way would be a powerful thing, indeed.