I’m thinking about creating a new game that would use a new map each time it was played. I know it’s possible to create a map covered with random terrain tiles, but I was wondering how far this basic idea could be pushed to create more interesting effects?
For instance instead of adding individual hex tiles would it be possible to add random oversized tiles that occupy the space of one single hex and it’s 6 adjacent hexes? This would allow greater flexibility and the creation of different sized features such as clearings in woods etc.
One potential problem would be the placing the centre of an oversized tile on the edge of the board which would mean some of it was beyond the edge of the map. Would this be likely to crash the game or cause other problems? If so would it be possible to avoid this by excluding placement from the boundary hexes of the board?
Slarty,
Yes, this is possible, but that doesn’t mean it will be easy. Here’s the sort of thing Vassal can do without much thought:
A) Send a piece to a specific location, defined either at design time or at run time through a property value.
B) Iterate through a stack of pieces and issue the same command to each of them
C) Make a decision based on the value of a property
Here’s the sort of thing that’s a bit hairy:
D) Deal pieces to the map until it is filled, respecting pieces of variable sizes, detecting possible overlaps.
So what I mean is you will ultimately have to convert item D into a bunch of little instructions like items A-C. Here’s a rough sketch of how you might do this if you have a fixed-size map:
A) Make a deck of cards, one for every single hex in your map. So you will need to identify each by name, say ‘A3’ or ‘F8’ - probably in the ‘Name’ field of the Basic Piece trait.
A1) Give each card a Layer trait for every size of terrain tile in your game. So for your 7-hex example, you might call one of your layers ‘small’ to represent a 1-hex tile, and one layer ‘medium’ to represent the 7-hex tile. The layers do not need to have any graphics. We’re using the layers to get some arrays, that’s all.
A2) For each Layer trait, define 1 layer for each hex that would be covered if you had a tile of the associated size center on the hex that the card represents. So say you have card C4, and you’re doing a ‘medium’ size tile - your layers would be called, maybe: A4,B3,B4,C4,D3,D4,E4
B) Give each terrain tile a property that states what size tile it is - again, something like ‘medium’, perhaps.
Now, to set up the board you could do something like:
Draw a terrain tile from a random deck of terrain tiles, and record its size in a global property.
Send a key command to the top hex in a random deck of unoccupied hex locations. That will become the center of the tile, if all goes well. Here’s what your key command would do:
2.1) Look at the relevant Layer trait for the terrain tile size (recorded in the global property, remember), and iterate through its layers. For each layer, you try to pull the associated hex - so, say, ‘A4’, out of the ‘unoccupied’ deck with another global key command. Send it to some temporary deck so you can return it to the ‘unoccupied’ deck if needed. The pulled hex should report back success somehow - the easiest way would be to monitor _numPieces. If your draw was unsuccessful, one of the hexes you’re trying to build on is occupied by another tile, or perhaps is off the edge of the board. Maybe throw out that terrain tile, or try again with a different center hex, or some combination of the two. Return the hexes you did draw back to the ‘unoccupied hexes’ deck.
If you were able to draw all the needed hexes out of the unoccupied deck, you have a green light for the terrain tile. Send the hexes from the temporary deck to an ‘occupied hexes’ deck, or delete them, whatever; send the terrain tile to the center hex (have the hex card copy its grid location to a global property, then have the terrain tile access the grid location in a Send to Location trait), and start over with a new terrain tile.
Once the unoccupied hex deck is empty, you’re done.
Now, I bet all that would be a royal pain to put together, especially considering all the surprising little things you’re likely to learn the hard way as you go along. Here’s another way to do it:
Make a board with all the terrain tiles on it, and tell the users to put them together however they like by moving them to the main map.
Seth, thanks for your very quick and thorough response.
You are right to say that your alternative method would be much easier and that the first way would be a royal pain. But it’s all the little things that I will learn on the way that interest me. If I can master this then perhaps I will have a good understanding of what is / is not possible concerning map building. So I will treat it as a learning exercise, but rather than construct a fully fledged game perhaps it would be better to make a proof of concept game on a smaller scale.
Couple of things to clarify I am not worried about detecting possible overlaps or avoiding edges unless this presents an issue for vassal. For instance would it cause a problem if I overlaid many layers of tiles on top of each other? if some tiles end up completely covered by others then I don’t mind. Similarly I don’t mind if a 7 hex tile ends up in a map corner provided any overhanging part of the tile is simply truncated and doesn’t mess up the appearance/alignment or crash the game.
Do you foresee any problem using large oversized tiles say 19 hexes/ 43 hexes? etc
I ‘m just trying to add a bit more interest to maps by making them look a bit more clumped/granular in places rather than ‘vanilla’ random distribution.
It’s useful to know that this sort of map building operation has to be split into the 3 basis operations you mentioned:
A) Send a piece to a specific location, defined either at design time or at run time through a property value.
B) Iterate through a stack of pieces and issue the same command to each of them
C) Make a decision based on the value of a property
I will use this as a future guide and will give this some further thought tonight.
To clarify, these are not the only atomic operations Vassal supports. What I mean is that the challenge will be reducing your task to some set of smaller operations. I recommend Mycenae’s excellent Designer’s Guide, available in the Docs tab of this site.
By the way, I don’t foresee any problems with crashing. If you don’t care about overlap, there are certainly easier ways to do this.
Something I did for Space Empires to generate random maps was to use a “placeholder” for the random hex. When a player activated that hex, either by revealing the piece or by peeking at it, the game would draw a random counter from the terrain stack and substitute it for the placeholder. This worked fairly well, dig around in the latest version of the module if you want.
Thanks - I will have a look at that later. I’m interested in any mechanism that can provide extra variety and interest in maps
It seems there are lots of different ways of doing things and huge potential with Vassal, although I had better familiarise myself with the basics before I get too carried away.