Hammer of Code

After yesterdays game of minisec and upon further review of some documentation I have enough of an idea now to begin thinking about how my ruleset will need to constrain itself to fit into the TP framework. As you might already know my intention isn’t to create a faithful transcription of the Risk rule book, but rather to create an adaptation of the rules that creates a 4X-experience akin to Risk. One of my primary adaptations is the inclusion of all-at-once gameplay instead of player-by-player gameplay. This makes for quite a few changes to game mechanics:

• Instead of each player making an infinite amount of movements during their solitary turn every player makes one movement during a ~30 second turn.
• Since players make moves at the same time there needs to be conflict resolution for instances such as P1 and P2 attacking each other at the same time, or P1 attacking P2 who is retreating. These types of conflicts are resolved by increasing/decreasing odds depending on the situation
• Since players don’t have solitary turns there exists a reinforcement phase (represented internally as a state) every x turns where players receive appropriate reinforcements and get to place say 10%-25% of their reinforcements per reinforcement turn. Say for 20% reinforcements per turn there would be 5 turns of reinforcements (5*20 = 100), after which the game would transition back to normal play.
  • The x turns can be kept track of easily enough with a counter for years since last transition to normal state.
  • On how to limit the number of units built: It may be possible to send a message to the player letting them know they can place x reinforcements that turn, let them go nuts on issuing build orders, then only process x orders from the OrdersQueue if I understand the framework correctly. This may be the most elegant solution, as it doesn’t create the need for a swath of error messages and pop-ups to inform the user they have gone over. It sort of correlates to how things IRL would work: You are told you have enough resources to build 5 things, you want to build 6 things in some order, you build the first 5 then you can’t build the 6th since you ran out of resources.
• It also becomes interesting in the beginning of the game, when players are claiming territories. While it seems easy enough to allow players to go one-by-one its really just the fools way out. This method would make for slower games, a more difficult time restricting movements and in general a very non-4X feel. I’ve opted instead to perform territory claiming in an all-at-once fashion. As I see it the implementation will go as follows:
  • Players all choose to build a single unit on any unclaimed system. As mentioned earlier the player can try to build as many as they want, but will only finish the first build order in the queue. Movement orders will also be ignored/removed
  • If the system is being claimed by only one person then the unit is built and the system becomes property of the player. Otherwise, in case of conflict, a random number will be drawn for each player in conflict and the highest will claim the conflicted territory. A special conflict resolution state will be switched and in the next turn only losing players of the conflict will get to claim a territory.
  • This will continue until all territories are claimed, and then a reinforcement phase will be initiated.

That pretty much sums up major changes to the Risk rules. Anything I haven’t mentioned most likely follows Risk rules to the letter or is negligible to implement. There is one game mechanic that I still need to address though, and that is movement. I’m confronted with the problem of restricting movement to the connectivity of the Risk board, which I plan to replicate for my first map. While existing TP games allow players to move through space freely I am left wondering: Do I restrict movement to the Risk “graph”, or do I allow free movement. I can see a significant pain in the arse trying to restrict unit movement. I did notice in the documentation some mention of wormholes, while that may encourage movement via paths I am left with trying to restrict movement to one star system jump at a time. I’ve tossed around in my head the idea of giving players free roam to move as they want, but that drastically changes the game. I did ask llnz though and I was told:

llnz: what ever fits really

So it may be an option. If I did go down that path I would need to be really careful about position of star systems, as the physical position should reflect the ease of access on the true board (more entry points means closer to more systems.) This could be really interesting though; Having units floating about in space. It certainly unlocks the restriction a board game has, and allows for more interesting standoffs. It would negate Risk’s free-move mechanic, and also call for extending turn lengths, as a player should theoretically be able to make as many movements as they want in a given turn. Less restriction == easier to program as well. I would be left only to try and restrict unit building, which is not as difficult, since construction requires resources, and resources are easier to control then move orders/pathing (resources are more of a “back-end” property.) Since not much extra work is required to make an unrestricted movement mechanic I may implement it first, then play test, and decide if it can/is be balanced.

(I’m going to go ahead an put this up in its more or less raw format, it really captures whats going through my head trying to figure out how to make the ruleset.)