Fun with game character movement (1920s automobile)

This is my first blog post in almost a year!  Let me introduce, very briefly the current experimental game I’m working on. This is a card+board+actionfigure game, themed on the italian mafia of the 1920s.  I will remove this paragraph here, when I’ve got a better introductory blog post written.

Last night the cars were functioning like busses or taxis. Public transit, anyway.

The valuable point and planned mechanic is to prevent a game player from attacking too early. In Risk, a player can attack quickly by adding all his/her new bonus armies to a single space and attack during round 2. That often fails so people often bulk up an offensive force, but neighbouring opponents always see that and bulk up their defence of adjacent regions with their own bonus armies.

Likewise in this game, attacking could possibly take place early, but the following idea came up in brainstorming: let’s prevent early attacks by limiting the access to vulnerable opponents too early, by requiring a car for one-or-more associates to travel together, and form a decent attack force.  Thus, is the inclusion of stylish 1920s automobiles. Currently 3D modelled is the Studebaker Erskine.  This restriction of attack rule is applied even if the target location is just across the street, or against a next-door neighbour (same side of street).

The development of the cars was a challenge at first, because of the conditions to check for the appropriateness of the game space it was traveling to. Actually, that’s because of the placement of playable characters was done earlier, and I was using the same logic and UI control for drag-drop, and so I copy-pasted the if-statement conditions.  All conditions for if a character (and/or car) should be put onto a game space were amalgamated into a single gigantic, horrible, unreadable condition:

        if (gamespace.iscontrollable == true &&
            (
            (gamespace.playerturf == this.currentplayer && (gamespace.playerowner == -1 
||gamespace.playerowner == this.currentplayer))
            || (gamespace.buildingtype == building.buildingtype.park && 
(gamespace.playerowner == -1 
|| gamespace.playerowner == this.currentplayer))
            ) &&
    gamespace.associatescount <gamespace.associatesmax
            ) {
             // gamespace is accessible and isn't overloaded and can receive new playable character so do that here
}

I broke up the multi-level nested if-statements early in the car development, to make progress easy and rateable.

During development I’ve disabled the maximum-per-space limit on cars and playable characters, so the following is missing that point.  It eventually came down to this:

1. Is the space controllable? (any home-turf buildings , and parks)
   1. Is this a car being moved?
      1. is this game space within the current player’s home turf?
         1. is this game space owned by no one?
            1. ALL GOOD, not owned by anyone, move the car
         2. is this game space owned by the current player?
            1. ALL GOOD, move the car
         3. is this game space owned by some other player?
            1. BATTLE MODE
      2. is this game space within any other player’s home turf?
         1. is this game space owned by no one?
            1. ALL GOOD, not owned by anyone, move the car
         2. is this game space owned by the current player?
            1. ALL GOOD, move the car
         3. is this game space owned by some other player?
            1. BATTLE MODE
      3. is this a neutral area like a park (the only alternate to home turf regions)?
         1. is this game space owned by no one?
            1. ALL GOOD, not owned by anyone, move the car
         2. is this game space owned by the current player?
            1. ALL GOOD, move the car
         3. is this game space owned by some other player?
            1. BATTLE MODE

The separation of conditions made this so easy to manage, I immediately migrated the code back into the character-movement decision making, to replace the single gigantic, horrible, unreadable condition previously above, but changing the ALL GOOD bits according to the rule restricting game players to move single characters into opponent turf or any other area occupied by an opponent.

All-in-all, it worked out very well.  During construction, it was fun to break rules, find myself driving a car to an opponent game space where an opponent character was standing, and loading that enemy into the car and driving it back to my own home turf, just because the code allowed for it.  Like a taxi rather than a practical game element, it was just a bit of fun messing around with rules during development.