You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the help of my amigo Vinsch (@VincentTheDutchDude), I playtested this game on a physical board to see how it holds up when played by two average humans.
It seems that the current codebase of the game does support different unit types, but that the actual game only uses one unit type. Naturally, we started with a test of the variant with only one unit type.
Such a single unit type variant proved to be rather one-dimensional. We didn't quite find the perfect strategy right away, but we do feel like such a strategy exists and anyone who plays the game for a while would find it. The single unit type variant is a bit like an adult tic-tac-toe in that regard.
The second variant included rock-paper-scissors unit types. We chose a variant where an army can only consist of units of the same type.
As mentioned in #1, such a restriction makes the game less cluttered, but also creates problems. What happens if an army of one type tries to move into the same tile as an allied army of another type? And what happens if an army of one type captures a spawn point of another type (which is very common)?
Our answers:
An army of one type moving into the same tile as an allied army of another type is illegal. Yes, this makes pathfinding more difficult (and we should probably include the difficult part outside of the AIs rather than implement it inside everyone of them).
The units in an army capturing a spawn point become of the same type as the spawn point. This means rocks turn into paper when they capture a paper spawn point. It means tank drivers step out of their tank and into an aeroplane when they capture an air spawn point.
We found that Lanchaster's law with it's current constants works quite well. Sometimes, adding one extra unit can completely turn a battle around. Which is nice. It adds depth.
Changing the type of units as they move onto a spawn point turns out to be pretty cool. In some situations you can take advantage of it: you can move an army onto a spawn point not to capture it, but rather to gain some extra units of that type. In other situations you have to move over a spawn point to get to the other side, and having the types changed is an interesting side-effect.
As a third variant, we capped the number of units that can spawn to 2. Every move is two phases: one in which you decide on which spawn points to spawn and one in which you decide which units to move where. (This would likely mean AI is defined in two functions instead of one.)
A spawn cap makes flanking much more realistic, we found. Normally, each player controls three spawn points which automatically guard themselves (as new units constantly spawn there). The spawn cap forces the player to leave one of those three spawn points a bit vulnerable. And as flanking becomes more realistic, watching the opponent's moves becomes more important.
In all three variants above, the player to move first is at an advantage. As a fourth variant, we tried an asymmetrical board in which one player moves first; but the other player starts with a spawn point strong against the other player's spawn point.
This variant has rock spawn points at 0, 0 and 3, 1; paper spawn points at 4, 4 and 0, 4; and scissors spawn points at 1, 3 and 4, 0. One player starts at 0, 0 (rock) and moves first; the other starts at 4, 4 (paper).
This last variant we tested seems to be quite balanced so far. From what we have learned, actually more balanced than the symmetrical one.
The asymmetrical board could make it more challenging to write AI. However, the spawn points are still located in a symmetrical way. The only thing that is asymmetrical is the typing.
The text was updated successfully, but these errors were encountered:
As I mentioned, we didn't find the perfect strategy for the single unit type variant yet (and didn't really want to: it's boring). But we did find that only two openings are viable.
Both players rush to the same corner spawn point. In this case, a livelock occurs. Both players continue moving units towards that spawn point. The first player to "back off" and let the other player have the spawn point, will lose shortly after.
Each player rushes to a different corner spawn point. Capturing the spawn point close to that corner spawn point is step 2. Both players control three spawn points at that point. It is possible to attack the other player's initial spawn point after that. Attacking that spawn point becomes more realistic as the match progresses. However, to actually win that way, you would have to take that spawn point without the opponent taking yours. That can only happen if the opponent makes a mistake. Otherwise, a stalemate in the middle of the board is the likely end result.
With the help of my amigo Vinsch (@VincentTheDutchDude), I playtested this game on a physical board to see how it holds up when played by two average humans.
It seems that the current codebase of the game does support different unit types, but that the actual game only uses one unit type. Naturally, we started with a test of the variant with only one unit type.
Such a single unit type variant proved to be rather one-dimensional. We didn't quite find the perfect strategy right away, but we do feel like such a strategy exists and anyone who plays the game for a while would find it. The single unit type variant is a bit like an adult tic-tac-toe in that regard.
The second variant included rock-paper-scissors unit types. We chose a variant where an army can only consist of units of the same type.
As mentioned in #1, such a restriction makes the game less cluttered, but also creates problems. What happens if an army of one type tries to move into the same tile as an allied army of another type? And what happens if an army of one type captures a spawn point of another type (which is very common)?
Our answers:
We found that Lanchaster's law with it's current constants works quite well. Sometimes, adding one extra unit can completely turn a battle around. Which is nice. It adds depth.
Changing the type of units as they move onto a spawn point turns out to be pretty cool. In some situations you can take advantage of it: you can move an army onto a spawn point not to capture it, but rather to gain some extra units of that type. In other situations you have to move over a spawn point to get to the other side, and having the types changed is an interesting side-effect.
As a third variant, we capped the number of units that can spawn to 2. Every move is two phases: one in which you decide on which spawn points to spawn and one in which you decide which units to move where. (This would likely mean AI is defined in two functions instead of one.)
A spawn cap makes flanking much more realistic, we found. Normally, each player controls three spawn points which automatically guard themselves (as new units constantly spawn there). The spawn cap forces the player to leave one of those three spawn points a bit vulnerable. And as flanking becomes more realistic, watching the opponent's moves becomes more important.
In all three variants above, the player to move first is at an advantage. As a fourth variant, we tried an asymmetrical board in which one player moves first; but the other player starts with a spawn point strong against the other player's spawn point.
This variant has rock spawn points at
0, 0
and3, 1
; paper spawn points at4, 4
and0, 4
; and scissors spawn points at1, 3
and4, 0
. One player starts at0, 0
(rock) and moves first; the other starts at4, 4
(paper).This last variant we tested seems to be quite balanced so far. From what we have learned, actually more balanced than the symmetrical one.
The asymmetrical board could make it more challenging to write AI. However, the spawn points are still located in a symmetrical way. The only thing that is asymmetrical is the typing.
The text was updated successfully, but these errors were encountered: