StarDestroyer.Net BBS

I've always liked playing boardgames, and war games in particular. There's something about moving physical pieces on a map that just can't be replicated on a desktop. I've spent plenty of hours/days with games like Risk and Axis and Allies.

The problem I've been having lately is that I find simple wargames like Risk too repetivie and boring, while few people are willing to learn a game like Axis and Allies (and even that is easy compared to a lot of wargames out there)! So I've decided I'm going to mash a bunch of game mechanics together and build my own.

My criteria:

1. It should be more in-depth than Risk, but less in-depth than Axis and Allies. I'm trying to stay within the range where casual gamers would be willing to play it.
2. The game should have more than one way to win - although it's a wargame, there should be different paths that players can take.
3. The length of the game should be variable e.g. setting # of victory points needed to win, number of cities/capitals needed to be captured etc. No need to for players to have to stay up all night if they don't want to.
4. The game map should be scaled according to the number of players (I'm aiming for a 2-4 player game, at least to start with).
5. The game map should be somewhat random, which would increase the replay value.
6. No playing cards, tech advances that people need to keep track of, culture, governments, multiple resources etc, to keep things relatively simple (for now).

Here is what I have come up with so far (in no particular order and with plenty of rambling):

Setting:

I've decided to set the game in the medieval era, so there will be plenty of knights in shining armour prancing around the battlefield. I could change the era, as it's not really important apart from flavour.


Map:

This is the are I am having the most trouble with. I was initially considering going with a hex-grid, but atm I've decided to go with a square grid because it is easier to deal with. This raised the issue of what to do with diagonals, since that is the most efficient way to move on a square-grid map. I decided that for now, units cannot travel diagonally.

Also, I want the map to be relatively random, and to scale up with the number of players (so that a 2-player game isn't stuck on a huge map). I stumbled across the design from the 2010 Civilization game, which I thought was pretty good in concept:




The biggest problem with this design is water tiles. It's very hard to come up with a randomized map where water tiles have a good chance of forming big lake / ocean. Plus as you can see, the water tiles look ugly as hell when they are on the edge of the map and joined by a land tile.

I'm still fiddling with the map design, maybe I'll go back to a hex-grid if I can find a way to keep it balanced whether its a 2, 3 or 4 player game and relatively easy to assemble. Also, unlike the map above there wouldn't be any tile orientation. Bonus points if it can be done in such a way as to make navies practical.

Not sure if I want exploration to be a part of the game or not.

There would be a limit of 5-10? units per tile, to limit Stack of Doom scenarios.

Terrain types:

Grassland:
Production: 1

Forest:
Production: 2
Notes - Units that move into a forest can still move out of the forest, but cannot go into a battle.

Mountain:
Production: 1
Notes: if you move a unit onto a mountain space, it’s done for the turn.
Towns may not be built on Mountains.

Water:
Production: 2
Notes: Units cannot move into water tiles.
Castles and Towns may not be built in the water.

Desert:
Production: 0
Notes: Towns may not be built in the desert.

Game Phases:

This was pretty easy:

1. Purchase units/buildings
2. Move units
3. Combat
4. Place new units / buildings
5. Collect production/revenue

Order of play: Players roll to see who goes first.

In a two players alternate turns.

In a 3-4 player game, the first player receives a token. Play proceeds clockwise. After every round of play, the token passes to the player on the left, and that player now goes first (to keep things balanced).

Combat Mechanics:

So far I'm going stick with the Axis and Allies combat mechanic, as it's a fairly straightforward system.

Each unit has an attack and defence value. The Attacker rolls a die for each unit that attacks at a value of 1; each 1 rolled is a hit. Next the Attacker rolls a die for each unit that attacks at a value of 2: each 1 or 2 rolled is a hit. This repeats for attack values of 3, 4, 5 etc. The Defender then assigns the hits to his troops. The Defender then goes through the same rolling routine as the attacker did, with the Attacker assigning the hits to his own troops. After the Defender has finished rolling, all troops that have been hit are removed from the game.

Combat rounds continue until either one (or both!) sides are wiped out, or the attacker calls a retreat.

As you can see, this is more involved than Risk, as the composition of units in a stack is just as important as the number of units in the stack. Under this system is quite possible for a smaller army to have better odds than the larger army, depending on the stack. However unlike some combat systems it still has an element of luck to it, which I prefer over systems where the superior strength always wins.

I'm sure there are other better combat mechanic systems out there, but a lot of them involve cards, which I'm trying to avoid atm.

Units

Crossbowman
Attack: 2
Defence: 2
Movement: 2
Cost: 4-6?

Pikeman:
Attack: 2
Defence: 3
Movement: 2
Cost: 6-8?

Swordsman:
Attack: 3
Defence: 2
Movement: 2
Cost: 6-8?

Knight:
Attack: 4
Defence: 3
Movement: 4
Cost: 7-10?

Trebuchet:
Attack: 5
Defence: 2
Movement: 2
Cost: 7-10?

Settler/Worker:
Attack: 0 (automatically destroyed if it is the only unit left in a battle), or 1 (not sure yet)
Defence: 0 (automatically destroyed if it is the only unit left in a battle), or 1 (not sure yet)
This would be done to avoid using the settlers to soak up damage (since the player gets to choose casualties)
Movement: 4
Cost: 8-12?
Used to build castles or towns.
The Settler/worker is consumed after building a castle or town.

No ships as of yet, until I can figure out a way to keep a board random and have water tiles sufficiently clumped together to make ships worth it.


Buildings:

Castle:
Cost: 12-15?
Abilities: Allows you to build units on (and/or?) adjacent to it. The Castle does not gather production points. They basically serve as a place for reinforcements.
Perhaps a limit of 2-5 units per turn can be built at a castle?
Victory Points: 1

Towns:
Cost: 15-30?
Abilities: Allows you to build units on (and/or?) adjacent to it. At the end of each turn cities gather resources/production points from the immediately adjacent tiles. Cities must be at least 3 tiles away from each other (to avoid production overlap)
Perhaps a limit of 5-10 units can be built per turn?
Victory Points: 2

Victory Conditions:

Players could choose how many of the conditions they want to use.


Capture the Capitals: Each player's starting town is a capital.

2 player:
Capture the other player's capital and hold it for at least 1 turn. You must still own your own capital in order to win.

3 player:
short game - capture 1 opposing team's capital and hold it for at least 1 turn.
full game - capture both opposing teams' capitals and hold them for at least one turn.
In both cases you must still own your capital in order to win.

4 player:
short game - capture 1 opposing team's capital and hold it for at least 1 turn
Mid game - capture 2 opposing teams' capitals and hold them for at least 1 turn
Full game - capture all 3 opposing teams' capitals and hold them for at least 1 turn
Again, you still have to have your own capital in possession.


Victory Points: Gain points by building and/or capturing X number of castles and towns. The number of points needed to win would depend on the number of players, and the size of the maps I ultimately decide upon.

An option for this could be a round limit: after X number of rounds, the player with the most victory points wins.


Battles: Every time an attacking player wins a battle, s/he scores a point. 1st player to X points wins.

Again, there could be a round limit, where after X number of rounds the player with the most points wins.


I was going to have some kind if option where a player can convert X number of production points into victory points, but I decided against that as I'm worried it would encourage turtling...


Well, those are my ideas thus far. Any thoughts? Particularly with the map, as I am having a hell of a time designing it?

I had a couple of thoughts on this. The first is for map construction, I'd recommend using hex tiles. Twilight Imperium for instance has several different spacings around the grid depending on how many people play.

I don't know if you've heard of Fortress America, but that game had limited stack sizes, which had interesting implications as to how armies advance and defend, you might consider checking the board game geek forums on that game. Also I'd recommend Axis and Allies D-Day, as another one of the limited stack size games, so you might consider checking the board game geek forums for that as well, axis and allies.org has a forum or two dedicated to the tactical series of A&A games that Larry Harris released, so I might give those places a look.

I agree with Gerald that a hex grid is likely going to be better for your purposes than a square grid. Square grids are only a must-have at scales where right angles are important - maps of rooms or of city blocks, for example. Scales dominated by natural phenomena work better in hex grids.

Hmm, is there a way to use the hex-grid the keep water more or less together while still be random?

Also, What should the size of each individual piece be? I'm thinking 7 hexes per piece so its fairly easy to setup...

I'm not sure you've succeeded in your goal of making this game simpler than Axis&Allies. You've retained most of the complexity of A&A (there's an economy with units that have costs, the battle system takes considerable time to resolve even if each individual operation is simple).

And you've added complexity by creating a map system that governs where units can and cannot go in a more complicated way- in A&A, movement is extremely simple because of the limited number of places you can go from any single point on the board. Whereas you have all kinds of weird stuff like "units can move into a forest and out of a forest but can't fight afterwards" and "tally up production value of terrain for each city" and so on.

Simon_Jester wrote:I'm not sure you've succeeded in your goal of making this game simpler than Axis&Allies. You've retained most of the complexity of A&A (there's an economy with units that have costs, the battle system takes considerable time to resolve even if each individual operation is simple).

YMMV, but in my experience large battles in Axis & Allies play out quicker than in Risk because you can use as many dice as needed for each roll. Barring home rules Risk caps out at 3 dice for the attacker and 2 for the defender, which can make for a long battle when there are dozens of units in play.

And you've added complexity by creating a map system that governs where units can and cannot go in a more complicated way- in A&A, movement is extremely simple because of the limited number of places you can go from any single point on the board. Whereas you have all kinds of weird stuff like "units can move into a forest and out of a forest but can't fight afterwards" and "tally up production value of terrain for each city" and so on.

Fair critique, I think I'll strip it down to land or water tiles. I think they'll still have a production value though "tally points around your cities" isn't that much more complicated than Risk - you might have to do a bit more adding, but you won't have to divide by three

Tribble wrote:Hmm, is there a way to use the hex-grid the keep water more or less together while still be random?

Also, What should the size of each individual piece be? I'm thinking 7 hexes per piece so its fairly easy to setup...

Two separate draw piles for terrain, using markov chains. So each tile is either water or land (with one stack being more water). Each tile also tells you which stack to take the next tile from with stacks mostly referencing themselves. A new tile has to be placed touching the last tile to be placed.
That should give you a reasonable shoreline generator. Empty spaces that got landlocked can be counted as impassable, unproductive mountain.



-
Also, welcome to the game development club!

Umm, sorry, non sciencey guy here, what is a markov chain? A little confused lol Is that 3 hexes together or something?

Also, welcome to the game development club!

And thanks!

nah. a markov chain is a particular type of probability engine for generating interesting sequences of things - I described the basic one for your purposes in the above post. There's a great wikipedia article available.
I started making one that included coastal tiles, but realised in hex layouts there's a LOT of possible coastlines needed Best to simplfy that out.

If you have an equal number of sea and land tiles and if each pile sends you to itself 50% of the time and the other pile 50% of the time you'd get a fairly broken up archipelago. Make it something like 70% self referential and 30% to get blocky continents. If you want more land tiles then sea tiles then just include some land tiles in the 'sea' pile too. Say 21 land tiles in the first pile (14 making next tile from first pile, 7 making next tile from second pile), and 16 sea tiles and 5 land tiles in the second pile (14 making next tile from first pile, 7 making next tile from second pile).