by dutchmogul Mar 17, 2015
Download All Files

Thing Apps Enabled

Please Login to Comment

I was Looking over the rules, and it said to turn the compass one "pip" every turn.

What in the heck is a pip?

Hello! My kids and I printed this (Will post pictures of the Make later) and we have a question on the rules. Did you intend that a pawn could be deployed and then move/attack? Technically the rules do not specify, other than once per pawn. Since a the pawn deploying is separate from the one deployed... I'm sure you see why it's a question.

Arian, we play-tested this game in our hotel room on my visit to GenCon. I would recommend creating some blinds to hide the number of tokens used from the other player until both players are ready to reveal. Also, return all tokens to each player after 3 or so rounds. I recorded our session, and the video should pop up on youtube in an hour.


I would recommend making the engravings in the counters a bit deeper. It is difficult to tell which is which.

When activating three pawns, are you allowed to activate the same pawn more than once a turn? (ie; a pirate has a single empty square between it and the settlement. It moves then attacks in the same turn)

No, only one activation per pawn, and three pawns per turn total. Good question though.

How many pawns can you deploy in one turn? I can't find it in the rules.

That's an excellent question. Each player can use up to three different pawns per turn. That can be for moving, attacking, or deployment. So, up to 3, if all you did was deploy 3 pawns for that whole turn.

Like the Pocket Tactics prints, there needs to be the OFF/DEF stats on the model itself. I realize the PT pieces are smaller and more complex, but these units seem bigger and only have the 2 stats.

Either on the base at 45 degrees or underneath the unit (embossed). It would help out not having to keep flimsy, home-printed stat cards around.

conversely, making your tiles (for PT, particularly) mate to lego studs would solve the other issue with scatter during play or trying to print enough 'holders' that interlock. Adequate bridging for the 5mm span shouldn't be an issue to most given the intricate detail of your models.

Haha, I don't know about that. These are actually smaller than PT models. Not to mention, I can't think of a lot of tabletop games that bother with printing the stats onto the models themselves (maybe a handful), and they're all on one easy reference sheet. The stats are simple enough to write onto a reference card if you want.

As for Lego-ish studs, I've played with similar methods, but it adds a lot of bulk to the tiles (plus you end up needing a surface with studs anyway), and part of the whole thing is that they need to fit in a tiny bag/travel and take up less space. The trays work well for keeping them together with organized games, and keep everything standardized, (you should be able to just bring your set to anyone's game and have the pieces be compatible), and you only need about three or four trays for a standard game, as pieces can be placed on the outside.. To be fair, we really don't have much trouble with tiles moving when we play anyway, but you can mitigate it entirely by playing on a less slippery surface. Thanks for the suggestions, though.

If I may comment here, I have a great solution for the problem of flimsy home printed cards.

I do a lot of print and play games and the best way to do something like this would be to buy some card collector plastic binder sleeves, and place your printed cards into the sleeves. The sheets of sleeves hold 9 cards. Also another trick is to use gluestick on an existing card and sticking your printed paper card onto the real card (like a spare MTG common card) and placing them into individual card sleeve protectors.

I hope that helps.

A maker could also print them on heavy cardstock, use single sleeve cardholders (which take less area then the 9 card sheets), or glue them to some thin plastic, as well.

Yeah, thank you, that's super helpful. I'll give that a shot.

For the islands, how about just merging the two objects into one file and programming in a @pause for a filament change?

Obviously this would have to be done by the end user, not in the STL, but it's a solution. :)

Oh, duh... haha, good call. I'll upload a merged version of the boards in a bit. Thanks for the pointer.

The merged boards are great. I'm painting mine. :)

another outstanding idea guys.