Tigris and Euphartes on Thousand Parsec

Accomplishments for this week:

• Created the following objects:
  • Universe. Generic universe container.
  • Pulled emptyobject, ownedobject, and spaceobject from minisec.
  • Star System. Added a couple parameters (destroyed, inhabitable) which I may or may not use for future game logic.
  • Planet.
    
• Implemented the following resources:
  • Uninhabitable. Used to mark planets which can only be colonized by mining robots.
  • Destroyed. Used to mark destroyed planets.
  • Alien Artifact. Special artifact resource gathered by merchants
  • Technology. Generated by scientist colonies.
  • People. Generated by settler colonies.
  • Money. Generated by merchant colonies.
  • Raw Materials. Generated by mining colonies.
    
• Added code to generate the systems and planets to form the game board. The board is laid out as a rectangular grid of solar systems, each with one planet.
  
• Put some thought into simultaneous turns (see post below)
• Got all the above code working and testable in tpclient-pywx

For next week:

I would like to continue to build all the objects I need. So for next week my main goal will be to create a fleet object and all the ships that I need (4 leader ship types, 4 colonist ship types, 1 weapon ship type).

I'm not sure how long that will take me, so if I have extra time here are the next goals I will work on: Giving the player the correct objects when the game starts. Start work on ship orders.

I was initially steadfast in wanting turns for TaE to be done in order one player at a time as they are done in the board game. However I've been doing some thinking about simultaneous turns, and I think the rules could be adapted to fit a simultaneous turn structure.

The biggest problem of a simultaneous rule structure with a board game style game is the possibility of two people acting on the same spot or tile or, in this case, solar system at the same time. The first solution that comes to mind is to have each player's actions resolved in some sort of order and any illegal actions will be rejected. This isn't the prettiest solution because it means that it's possible for a player to take an action that looks legal at the time, and then to have that action denied because another player's turn was processed before them. In an effort to make this fair, I've come up with two solutions:

• Randomize the order that the turns are processed. This leaves it up to chance as to which player's order is accepted when there are conflicting orders.
• Cycle the player order (i.e. if your orders were processed first this round, they're processed second next round). As long as players know the turn order, this could add an extra bit of strategy to the game. An order may become more risky for a player if they think another player which is ahead of them in the queue may make a conflicting order. This is the idea I'm leaning towards, but I may change my mind as I implement and test it.

Another thing to think about is the possibility of consolations to a player whose move has been rejected. This could be something like letting them perform an extra order the next turn. This is something that I'll think about adding if the game needs it.

The final possibility for simultaneous turns is to change the rules so that there are no conflicting orders. This is something that I may think about, but I think the change will have to be drastic. I'm not leaning towards this solution at the moment.

I was visiting with my family this week so I didn't get much actual coding done. What I did with my time instead was read through some the code of minisec, mtsec, and rfts to get a feel for how the objects work. I was specifically interested in seeing some examples of different properties and how to use them, and also how to initially setup the objects in the game.

For this next week I will focus on getting what I've learned about these objects into code. I want to have a basic implementation of my solar system object. The solar systems will make up the "game board" so having them up and running will provide a good foundation for much of the game logic. If I have time I would like to start designing the region detection algorithm.

Tomorrow marks the official start of coding! According to my original schedule estimates I'm about a week and a half ahead of schedule. Hopefully that will help offset any unforeseen (yet probably inevitable) problems ;)

Here are my accomplishments for this week:

• Created a small working ruleset (runs, but doesnt have any objects in it)
• Created a wiki page for players of my ruleset. Right now all it has is a first draft of the rules from my proposal.
• Continued to explore the tpserver-cpp code.

Goals for next week:

• Start work on creating objects for the ruleset. Focus on the solar system objects to form the "board"
• Come up with some possible solutions for the board layout and region detection.

This weekend, my TP work has mostly been getting things set up for this summer and getting a grasp on the framework as a whole:

• I've got a clean Ubuntu build on my laptop (Hardy Heron is excellent btw).
• As far as I know, I have git up and running pointing to my branch of the tpserver-cpp project.
• I compiled a basic tpserver-cpp and started up a local game of minisec just to make sure everything was running smoothly on my side.
• I've been reading through llnz's Ruleset Development Book.
• I've also just been poking around in the code, trying to get a feel for how everything works.

Things to do next:

• Setup a basic buildable ruleset to work off of as outlined in the ruleset book.
• Start developing a document (possibly on the TP wiki) for the TaE rules which I can modify as the project progresses.
• As I get more familiar with the code, work on developing solutions for some of the obvious obsticles I'm going to face in this project such as:
  
  • Non-simultaneous turns. What is the best way to accomplish this? Do I need to compromise the TaE rules to make it work?
  
  
  • Conflict phase. What's the best way to implement a "phase" which only occurs in special circumstances? Should this be a separate phase of turns or should this be handled as a part of the current turn cycle?
  
  
  • Layout of the universe and interconnected solar systems. How do I represent connectivity of neighboring systems in order to calculated "regions" of controlled space? This seems similar to the graph issue jphr is contemplating in his Risk implementation.

So that is what's on my plate right now. I'll post more updates as they come.

Finally done with all my exams!

GSoC here I come!