Hammer of Code

My adventures in GSoC 2008 working on Thousand Parsec, among other things

12  05 2008

solidifying turn order

Mithro and I had a really good chat on IRC about turn order. The conversations is availible on Thousand Parsec’s IRC log starting here.

What I know so far:

  • Units won’t exist as IGObjects per se. But will rather be properties of particular territories.
  • Units will move in an order made up as: move “range value”(# of units) to “choice value”(adjacent territory). choice values will only be neighboring territories. While I did consider “free movements” I don’t believe it is really conducive to allow a player to potentially completely redistribute their units across their territory. It just doesn’t really make a lot of sense (realism-wise)
  • Turn order will go as follows. Territories will be processed in a fixed order: by constellations, then by planets within constellation. The order of constellations may be specified in the .conf, that is yet to come.
    1. Number of available units for each player are calculated, stored.
    2. Initial Reinforce Orders are processed until player has no more units.
    3. Movement orders issued to friendly territories will be processed.
    4. Attack orders are then processed. A check needs to be done for conflicts (running away units lose some units, units attacking each other get even odds). If the attacked territory no longer has units on it ownership changes and remaining units from the battle are transferred to it.
    5. At this point all remaining orders should be processed until Nop is reached. (This might not be the right thing to do, but it may allow for alternate advanced strategies that would allow attacks to be delayed)

I will be doing some scenarios on paper, and hashing out more of the nitty gritty of the turn ordering this week. Next week I will switch gears into some coding and getting myself a shell ruleset running. More after the jump on what it is to be a coder, ruleset variations, and how awesome TextMate is.

Coder’s Inadequacy
As a bit of an aside Mithro did a good job today putting me at ease with my coding skills. Since I haven’t reached the point creatively where I code (other projects) on my own, I am inclined to feel a little bit of “coder’s inadequacy,” if you know what I mean? When Mithro said “h[e has] very little idea how the internals of tpserver-cpp actually work[,]” it made me realize how much of a coder I already was. I had strangely felt that things like being able to run code in your head and memorization of existing code were what it was to be a coder. I have been learning, however, that crafting source code is actually quite a small part of what being a coder is. It seems apparent now that if you can accurately and unambiguously describe WHAT and HOW you want to do something then writing the code for that is simply a matter of translation to source code, not creation of it. This discussion will of course lead to talk about development methods and programming styles, so I’ll cut it off here and continue on about Risk.

Ruleset Variations
Mithro and I also spoke about variations to the Ruleset that could be included in the Ruleset. These would be little things that could drastically change the way the game played out. One such idea I had was attaching weights to # of connected territories. A territory with less connections would fight more strongly than a more “divided” territory.

It was also suggested that altering the ordering of which constellation/territory gets “first dibs” on moving might give what mithro called a “higher ground advantage[.]”

These variations will certainly be close in my mind at all times during coding, but by no means will I be spending all my time on variations. I figure my primary goal once coding begins is to get the basic Ruleset running (and by basic I mean complete). If that process takes the whole summer so be it; I’m optimistic, however, that I can complete this basic game in good time and have plenty of time to (and i know this is so cliche because I say it often) put lots of polish into available variations and game balance.

TextMate is better than you are
As a finale, I just have to make a comment or two about TextMate. I intended to start using textmate for coding my Ruleset, as I had heard rave reviews from friends and the like. Well I haven’t started actively coding, but I have started actively using textmate to blog. I was really surprised to learn that in addition to all its coding bundles it also has a blogging bundle. I am able to user shortcuts to insert markdown elements I use for blogging, grab posts, and even post to the web straight from textmate.


3 Responses to “solidifying turn order”

  1. re: Coder’s Inadequacy
    No coder could understand all the intimate details of a project as large as Thousand Parsec. You will definitely understand tpserver-cpp much better then I do by the end of this summer :)

    re: Ruleset Variations
    Don’t forget that a huge amount of time will be taken up by play testing. Those small variations I mentioned above may make the game unplayable in some circumstances.

    You will need to actually play many games of risk before you have a good idea of which things work.

  2. [...] solidifying turn order [...]

  3. [...] solidifying turn order [...]

Leave a Reply

« more on compiling issues almost there »