Tabletop Spaceship Game Part 5, Iterations!

Now that a ship's displacement of theory has been spun, let's get to the base model of the game. In order to test systems in a productive manner, I need a functional core set of mechanics. I've seen that starting with anything more than a base set of mechanics causes confusion and misleads priorities.

With that in mind, and what we've covered before, what does a wargame need?
1. Victory Conditions
2. Movement
3. Attacking

Solid. Let's expand these, to minimum functionality. Each of these iterations is going to be painfully basic, but this process is important to actually 'figure' the game out.

0.01:
Victory Conditions:

• you win when the other player's ship is destroyed.

Movement:

• Your ship can move anywhere on the play space.
• The play space is infinite size.
• Your ship may move at any time

Shooting

• Your ship can shoot any number of times
• Your ship deals 1 damage per shot
• Your ship hits automatically
• Your ship damages targets automatically
• Your ship can take 1 hit before being destroyed

This version is unplayable. Why it's unplayable is important for putting barriers in place. This ruleset results in both players ships exploding instantly since ships can shoot infinite times at any point in the game, automatically hits, and automatically damages the target. There is no meaningful choice, and no reasonable way for the game to provide satisfactory play.

The first step I'm taking is to introduce a 'turn' mechanic. 

------------------------------------------

Turns:

• Players alternate turns. 
• A player can [only] act on their turn. 
• Flip a coin. The winner of the toss gets the first turn.

Good. Where earlier both sides would blast each other simultaneously, Turns ensure that only one player will be able to act at a time. But there is still the problem of movement and Attacking happening at any time in the turn - let's regiment that a bit. Also Attacking should happen only once per turn. And let's restrict it to a single target while we are at it. Let's see what we've got here:

[brackets] fence in variables that may change later. This helps keep eyes on the prize

Capital letters highlight important game concepts, such as Victory Conditions.

Each player controls [1] Ship

Turns:

• Players alternate turns. 
• A player can [only] act on their turn.
• On their turn, a player [Moves] and then [Attacks] 
• Flip a coin. The winner of the toss gets the first turn.

Movement:

• Your ship can move [anywhere] on the play space.
• The play space is [infinite] size.
• Your ship may move at [any] time

Attacking

• Your ship can shoot [Once] per Turn
• Your ship deals [1] damage per shot
• Your ship hits [automatically]
• Your ship damages targets [automatically]
• Your ship can take [1] damage before being destroyed

This is better. But still inadequate. The first player will win every match guaranteed. The restrictions added previously help lay the foundation for future rule systems required to make this game more interesting.

So what's next. The current problem is that the first player wins, guaranteed. This is not fun, it's not a game at this point. So there needs to be some additional factors to add complexity, depth, and choice to this prototype.

The most direct way to make sure the first player doesn't always win is to introduce chance. 

Attacking

• Your ship can shoot [Once] per Turn
• Your ship deals [1] damage per shot
• Your ship hits [on a D6 roll of 4, 5, or 6]
• Your ship damages targets [automatically]
• Your ship can take [1] damage before being destroyed

Ok. With this setup, any player has a 50% chance of missing. This allows the second player to win, while also allowing the possibility for the first player to win. However, this introduces a new problem specific to this mechanic: The game could last infinite turns if players keep rolling below 4 on their Attack Die.
Time to solve that with a turn limit! Each player gets 6 turns. If a ship isn't destroyed by Round 6, the game is a Draw.

Alright. This is quite crude,  but it's a start. Further posts will detail further revisions and development.