Ready, Fire, Aim (Oops)

I'm working on the fire combat model for the PIC-Guam prototype. I added a FireCombat class to contain the information about the combat. I added a Turn class with lists of FireCombats for the US and Japanese fire phases, and added a list of Turns to the Game class. Then I got down to work. I added a bunch of code to support combat results table (CRT) processing. FireCombatResolution, OddsRatio and FireDieRollModifier are all enums. I also added FireCombatCRT and FireModifier classes, and nonserializable static lists of same to the main FireCombat class. Finally, I added a constructor to FireCombat and a couple of methods to setup the lists of FireCombatCRTs and FireModifiers.

And that was my 49 minutes for today.

Fun with Zones of Control

I'm working on elaborating the movement rules by including an awareness of Zones of Control (ZOC). Every unit exerts a zone of control into the surrounding hexes. This has the effect of stopping movement, and triggers Defensive First Fire. I'm implementing movement in the prototype so that entering into movement mode identifies all hexes the unit can move to by highlighting those hexes. It's important to take ZOC's into account, especially since ZOC's stop movement and the rules do not permit movement from one ZOC to another.

This is what I had earlier today. There was a problem in the adjacent hex code...it did not always generate a list of adjacent hexes, resulting in the "jump" over the enemy units shown here.



I fixed the adjacent hex code by providing the proper offsets and better controlling code:

public static List<Hex> AdjacentHexes(int x, int y)
{
    List<Hex> adjacentHexes = new List<Hex>();

    int[] XOffsets = { 1, 0, -1, -1, 0, 1 };
    int[] evenYOffsets = { 1, 1, 1, 0, -1, 0 };
    int[] oddYOffsets = { 0, 1, 0, -1, -1, -1 };

    int[] YOffsets = (x % 2) == 0 ? evenYOffsets : oddYOffsets;

    for (int offset = 0; offset < 6; offset++)
    {
       adjacentHexes.Add(Hexes.Where(h => h.X == x + XOffsets[offset] && h.Y == y + YOffsets[offset]).First());
    }

    List<Hex> adjacentHexesOnMap = new List<Hex>();

    foreach (Hex h in adjacentHexes)
    {
       if (IsOnMap(h.Y, h.X))
       {
           adjacentHexesOnMap.Add(h);
       }
    }

    return adjacentHexesOnMap;
}

This resulted in the following improvement in testing.



I did some more testing, setting up a situation in which hex 1806 should not be in the movement footprint due to the ZOC code. I still had some work to do:



I had added the ZOC logic initially to the first set of adjacent hexes originating from the unit's starting location. I wondered whether I needed to also add that logic to the code that evaluated subsequent hexes further away from the starting point. This proved to be the case:



This finishes off the things on my list now for movement. I'm sure I've forgotten something, even cutting corners as I am for this prototype. Still, I think I have enough for now.

The next task I have is fire combat. This encompases Defensive First Fire, Offensive Fire, and Defensive Fire. This will take some doing.

Rolling Along...

I put in another hour and a half on the PIC-Guam prototype today. I am finishing up some additional features for movement. Today I was working on the rule that says a unit can't move from one Zone of Control (ZOC) directly to another. I moved the Hexes from the Game class to be a static member of the Hex class...this makes it easier to access everywhere I need it, and it turns out I need it everywhere. No problem: I relocated the declaration and "rode the compiler" to fix all references.

I'm very pleased with how quickly I can put together meaningful features using C# and LINQ techniques. Using extension methods and lambda expressions, I write terse code with minimal ceremony that is relevant to the requirements.

I like my chances of completing this game in 1000 hours (of effort).

Game Development Status 6/11/10

I spent only a few minutes working at lunch today, but I got the stacking code working. Movement now takes into account stacking limitations. Effort to date for the month is 4 hours 17 minutes.

PIC-Guam Game Development Status 6/5/10

This is my first blog post using Windows Live Writer.  It may take me a while to get the formatting right…

I’m continuing to make progress on the prototype for PIC-Guam.  In May I spent over 26 hours working on the game.  I have better momentum now that I’ve had since the last Origins trip for PC Eylau in 2005.

My post last October was quite optimistic in a couple of areas.  I underestimated the amount of work to be done to produce a viable prototype, and I overestimated the amount of time I would have over the 2009 holiday season to work on the game.

I only really got a clue when I finally created a coordinating task for the prototype that listed everything I wanted to accomplish.  Here’s the text from my notes:

a    perform task PG-100515=1:
        Guam Prototype Coordinating Task

        this sets the agenda for completing the Guam prototype

        notes 5/15/10: 0810..0842
            planning
done            figure out what is missing
done            mark as P3I tasks not part of the prototype
done            add P3I's to P3I list
done            derive or locate a task for each missing item

        plan
            what is missing from the prototype (Orote scenario)
PG-100515=2     movement (UI, DB, game system)
PG-100528=1:    turn sequence
PG-100515=3     fire combat 
                     defensive (UI, DB, game system)
                     offensive (UI, DB, game system)
PG-100515=4     assault (UI, DB, game system)
                     P3I: movement after assault
PG-100515=5     complete the Orote data
PG-100515=6     head to head play mode
PG-100515=7     AI play mode 
                     P3I: AI plays both sides
PG-100515=8     UI hex window
PG-100515=9     UI unit window
PG-100515=10    UI fire attack window
PG-100515=11    UI assault attack window
PG-100528=2     Game Status window
PG-100515=12    UI game messages window
PG-100515=13    victory conditions - no NME units left
PG-100515=14    present the prototype to Chris
PG-100515=16    release the game as a CTP to the Beta group
PG-100515=17    make a Guam Release Coordinating Task 
                    

So far I have completed most of movement and enough of the turn sequence to move forward.  I documented my progress in the recent demonstration video posts.  I’ll continue to do so as I complete new features.  The tasks above fall into 4 categories: game system, AI, UI, and coordinate (with Chris and the Beta group).  I plan to do them in roughly that order.  I estimate this will take 100-200 hours to complete, or 4-8 months of notional calendar time.  Assuming my estimate is not too far off (yeah, right!), I think the prototype may be complete by Christmas and available to the Beta group in early 2011.

PIC-Guam Movement Demo Video