Tigris and Euphartes on Thousand Parsec

This was the final week of GSoC. I was out of town for most of the week with limited internet access, so I don't have a ton of updates. I spent the week cleaning up and commenting code. I also did some more testing as I went.

Even though GSoC is ending, I plan to continue to test the game and I may add some new features too. Overall, I had a great time coding this summer. Hopefully I made a worthwhile contribution to TP!

This week I worked on testing and documentation. I completely revamped the wiki page for Tigris and Euphrates into a much shorter and clearer walkthrough of the rules with screenshots. I removed a few of the sections in the wiki because I felt that they were excessive and didn't really help the reader understand the game.

I also continued to test the game, and fixed bugs as I found them. Most of the bugs were relatively minor. I fixed a bug where regions were not being correctly merged if they were joined but no combat occured. I also fixed a bug where leaders were not being removed when they no longer border a scientist colony. And I fixed a bug where colonist ships which were generated the previous turn were not being flagged for combat.

Next week I'll be doing final testing and bug fixes.

This week I completed the combat turn. This means that TaE is now fully playable from start to finish. All the features that were originally planned at the beginning of the summer are now implemented.

Here is an overview of my commits for this week: I completed the final cleanup for external combat which removes all the losing combatants and awards points to the winner. I added a function to look over the regions after all the losing combatants have been removed and make sure that it is still a region. If it is not still one region, the function rebuilds it into multiple regions. I added code to check for any more instances of combat after the current combat is resolved. Finally, I added the code executed when a game ending condition is reached. It tallies the points and announces the winner to all the players.

Later today (hopefully) (UPDATE: The combat overview is up! you can see it here) I will be adding a writeup explaining exactly how combat works in the game. It will be done in the same style as the "Tour of TaE" post.

Next week I plan to work on testing and documentation. My goal is to make sure there aren't any lingering bugs in the game and to make the documentation good enough so that anyone who can install TP can play TaE.

Now that combat is implemented into TaE, I'm going to run through the rules behind it and what it looks like both in TP and on the physical board.

First off, there are two different types of combat in TaE: Internal and External.

Internal combat is when there are two or more leaders of the same type in a single region, as shown below:



Physical Board


TP: Normal View


TP: Resource View


External combat is when there are two or more regions which have just been connected and contain leaders of the same type, as shown below:


Physical Board. The different regions are highlighted in red and green.


TP: Normal View


TP: Resource View


Once combat is initiated, each side's initial strength is calculated. For internal combat the initial strength is the number of scientist colonies bordering your leader. For external combat the initial strength is the number of colonies of the same type as your leader in your region. For the internal example above, the "pot" has an initial strength of 1 and the "bow" has an initial strength of 2 (the red tiles are represent the scientist colonies). In the external example above, the "pot" has an initial strength of 1 (one green tile) and the "bow" has an initial strength of 0.

During the next turn (the combat turn) each player involved in the combat my "reinforce" their leaders. To do this they select an appropriate colonist ship (scientist for internal, the same type as the leader for external) and select "Reinforce" as shown below:




For each reinforcement added, the strength of that side increases by one. After the turn is over, the side with the highest strength is declared the winner.

For internal combat, the losing leader is removed from the board and the winner is awarded one technology point. If in the example above, no reinforcements were added, then the "bow" would win and the board would look like this after combat:


Physical Board


TP: Normal View


TP:Resource View


For external combat, the losing leader is removed, and all of the colonies of the same type as the losing leader in the losing leader's region are removed. In the example above, let's say the "bow" adds two reinforcements and the "pot" adds no reinforcements. This makes the final strength 2 to 1 with the "bow" winning. The "pot" leader is removed as well as the green tile in his region. The "bow" player receives 2 points of the same type as the leader (green). The board looks like this after combat:


Physical Board. After removing the losers, the area is split into two regions, outlined in black.


TP: Normal View


TP: Resource View


That's all there is to combat in TaE. After the combat turn is complete, if there are still two or more leaders of the same type in one region, another combat turn will occur. Otherwise, the game resumes with normal turns.

This week I worked on getting the combat turn system implemented. I planned to have a fully playable version of the game done today, but unfortunately I wasn't able to meet that goal. I ran into several bugs as I worked on the combat turn which slowed my work. A couple of these bugs were in previously written code but just didn't surface until I had written the combat code. The other thing that slowed down my progress was the time it took to setup each combat test case. I had to go through a couple turns of the game just to get to the point where I could test out each new feature. This caused significant slowdowns when hunting down a segfault.

I started this week by finishing work on the fleet object so that it holds a set of normal orders and combat orders. I added a toggle which sets whether the fleet is a combatant in the combat turn (and should have combat orders enabled). I then added the reinforce order which is the only order used in combat.

Then I began work on implementing the combat turn into taeturn. It first determines which fleets should have their combat orders enabled. Then it determines the initial strength of each side. Then processes all of the orders. Then determines the winner of the combat and awards points to the winner.

What I have left to do is award points for the winner of external combat. Remove the losing side of external combat. Rebuild the region after removing the losing fleets, and then doing one final check to see if there needs to be another turn of combat to resolve all the conflicts. I'm going to try to get some work done on this during the weekend, and I should have it done early next week. After that I will do a writeup with screenshots to show how the combat works, and then start cleaning up and testing everything in the game.

I started off this week by taking a look at the TaE wiki page. I wrote up a getting started guide for people who want to try out TaE. I'll be making improvements to both pages soon.

I then began planning everything out for the second half of the summer. I think the comparison photos between the actual board and it's implementation went well so I will continue to post those as the project continues. I will incorporate these photos into the wiki page and make sure that anyone who wants to play the game needs to only visit the wiki to get all the info they need.

For the combat phase here is what I have planned: I will use a multi-turn structure similar to RFTS. If combat is triggered, then a message will go out to all players and the next turn will be a "combat turn." The players who are involved in the combat will have the applicable orders enabled for their fleets, everyone else will not be able to perform orders until the combat is over. At the end of each combat turn, the board will be checked again to make sure that no further combat needs to occur and then the game will return to normal turns.

To do all of this I will create a function (maybe two: internal and exteral combat) within taeturn which takes the combatants as input and then handles switching the orders on all the fleets and continuing with the combat turn. This function will be called from the move or colonize order after gathering the combatants. I implemented the code to find the combatants this week. I also went ahead added some code to the fleet object which lets them keep two sets of allowed orders, combat and normal. This lets me set up the orders at the beginning of the game and all taeturn has to do is tell the fleet to switch orders.

Next week I am going to be working hard on implementing the combat turn and I'll hopefully have a first fully playable version of the game ready by next weekend!

The Board:
Here is a picture of the physical board from the game this ruleset is based off of (click on the pictures for a larger view):


The board is composed of 3 different spaces: blank tiles, river tiles, and artifact tiles (marked by the winged creatures).

Here are a couple screenshots of the board in thousand parsec:

In this screenshot, each of the "tiles" of the board is represented as a system. The green and red systems at the bottom of the screen are each of the player's systems. They are used as a spot to hold each player's fleets when they are not in play on the board.

To see the three different tile types represented, we switch to resource view:

Here you can see the "river tiles" represented as small red circles. The "artifact tiles" are the larger red and blue circles. Since this adaptation is set in space, the river tiles are uninhabitable systems which can only be colonized by mining robots, and the artifact tiles are star systems which contain ancient alien artifacts.

Players may also create their own maps.

The Game Pieces:
Each player has a "hand" of 6 random building pieces, 4 leaders (one for each type of colonist), and 2 destruction tiles.

Here are what they look like in the real game:

The building pieces: Temple (red), Settlement (black), Farm (blue), and Market (green).


The leaders: 1 set of 4 for each player. Each set contains 1 leader per building type: Priest (red/temple), Merchant (green/market), Farmer (blue/farm), King (black/settlement).


Destruction pieces: Each player gets two of these. Each can be used once to destroy a tile and render it unusable for the rest of the game.

In the TP adaptation, the game pieces are fleets of ships. Each fleet represents a single game piece. All of your fleets are kept in your home system until you issue an order to them. Here is a sample home system:

Here you can see the player's hand of 6 Colonist fleets (building tiles), set of 4 leaders, and 2 bombers (destruction tiles). To match the setting, the leader's names have changed: Priest is now Scientist Leader, King is now Settler Leader, Farmer is now Mining Leader, and Merchant is now Merchant Leader.

Each colonists' type is hidden from other players, to find out the type of one of your colonists, you click on it and look at the type of ship in the fleet:

The four types of colonists are: Settler (Settlement), Mining (Farm), Merchant (Market), Scientist (Temple).


Orders:

Each fleet has an order associated with it:

• Colonists may colonize a system: this consumes the colonist and generates a resource of the colonist type on the system.
• Leaders may move to occupy a system: this does not consume the leader. This order is used to harvest resources for points.
• Bombers may destroy a star system. This removes all resources, leaders, and anything else in the system and prevents any further orders from being executed on that system.

All of these orders are performed by clicking on the fleet, selecting new order, and then selecting the star system you wish to perform the order on. If the system is not valid, then it will reset the input dialog and you must choose a different system. Here is a screenshot of the order dialog:


The game board, pieces, and orders are relatively simple. The real meat of the game comes in the rules to when and where you can execute the orders. But first, you have to understand regions...


Regions:

Regions are a group of colonized or occupied (by a leader) systems. Each system in the region must be adjacent (north, south, east, or west... NOT diagonal) to at least one other system in the region. Here is an example:

Resource View:

Normal view:

In resource view, the red circles are colonized systems (the one with red/blue has an alien artifact). In the normal view, there is a leader in the upper right corner (marked in red). So all of the systems except the one in the bottom left corner are in the same region.

Brief overview of the rules:

• Each player may execute 2 orders per turn.
• A system may only be colonized if it is not occupied by a leader and has not yet been colonized.
  
• Mining ships may ONLY colonize uninhabitable systems and these systems may not be colonized by any other type of ship.
• Leaders may only be moved into an unoccupied, uncolonized, inhabitable system which is directly adjacent to a science colony.
• There are 4 different "points" which each player can receive; one for each of the colonist types.
  
• When a system is colonized, the player who owns the leader of the same type in the region of the new colony receives one point of that type. If there is no leader of the correct type then the owner of the Settler leader in that region gets the point. If there is no settler leader, then no one gets the point.
• If there are two or more alien artifacts in the same region at the end of a turn, then the person with the Merchant leader in that region gets to take one of the artifacts. An alien artifact acts 1 point of a type of the player's choosing.
• Leaders may not join two regions together.
• If a leader is placed in a region which already contains a leader of the same type, internal combat is initiated (not yet implemented).
• If two or more regions are joined and they contain leaders of the same type, then external combat is initiated (not yet implemented).
• Combat is not yet implemented and is not covered in this rules overview.
  
• At the end of each turn, each player's reserve of colonist ships is refilled to 6 randomly from a pool of ships.
• When the pool of colonist ships is empty, the game is over.
• When there are 2 or fewer alien artifacts left on the board, the game is over.
• Each player's score is equivalent to the number of points in the type which they have the fewest points in. (the final score tally is not yet implemented).
  

This week I focused on getting all my goals completed for the midterm evaluations. I added a restriction to the move order which I had forgotten before: leaders can only be moved to star systems which border a scientist colony.

I also added code which awards alien artifacts to players at the end of each turn. This ended up taking a bit longer than expected and I'm not able to fully test it out until I get combat implemented. It looks for regions which have more than one alien artifact in it. For each of these regions, one of the artifacts is awarded to the player who owns the merchant leader in that region. If no merchant leader exists in the region, then no artifact is awarded.

Finally, I implemented a new way of generating maps for TaE. Players can now make their own maps by creating a text file where '.' is a normal system 'A' is a system with an alien artifact and 'M' is a system which can only be colonized by mining robots. For example, if the player wanted to create a 4x4 map with Artifacts on the corners and a 2x2 mining area in the middle, it would look like this:

A..A
.MM.
.MM.
A..A

The player then specifies the path to the file in the .conf file as "board_path=/path/to/map.txt" If a file is not specified or cannot be found, then a default map based on the original TaE board is produced.

In addition to all this, I've also been working on the midterm evaluation and the midterm report for Mithro.

I definitely need to start showing off some all the stuff that I've been working on. Later today I'll be posting a screenshot tour of the ruleset so far. I'm also going to be revamping the TaE wiki page to provide some direction for people who want to play the game. I'll be working on that this weekend and next week. After I get a good bit of stuff posted, I'll begin work on coding the combat side of the game.

This week I got the turn structure finalized by processing orders one player at a time and rotating that order each turn. You can read more about my reasoning to do this in this blog post. I also fixed a couple bugs which arose from processing orders in this way.

Each player should have 6 colonist ships at the beginning of each turn. I implemented the code to replenish these ships as they are used. While doing this I also moved the fleet creation code into its own class. This helped to make the code more readable, easier to modify and easier to extend.

I have almost everything done for the midterm. I would like to add a message when the game over conditions are reached. I would also like to create a better default map for the game. I should have this done early next week. In addition to this I will be finishing anything else that crops up and submitting my midterm evaluation.

I spent this week working on my goals for the midterm. I implemented an algorithm which sorts all the orders by player (this will be used to implement the ordered turn system next week). I used the region system created last week to add code which finds a specific leader in a given region. This allowed me to implement the code which adds points to a player's score.

The way the scoring works is: when a system is colonized, the game searches for the leader of the type of colonist which just colonized the world (i.e. a merchant leader for ship of merchants). If a leader of the correct type is found in the region which the newly colonized system is in, then the owner of that leader gets 1 point of the same type as the colonist (i.e. 1 point in the "money" score for a merchant). If no leader of the correct type is found, but a settler leader is found in the region, then the point goes to the owner of the settler leader.

So far everything is on track for the midterm. Next week I will be working on getting everything finished for the midterm. The biggest things left are getting the ordered simultaneous turn finished and implementing the end game conditions.

This week I did a lot of small behind the scenes stuff which helped to develop the rules for the game, but they didn't make much of an observable difference to the player.

I introduced a layer of inheritance to the fleet orders since they all needed to check for the same conditions before for they performed the order. Namely, they need to check to make sure the system is not colonized, is not occupied by a leader, and is not destroyed. I added a check to make sure that each system only accepts one order per player per turn. I also made sure mining ships can only colonize uninhabitable planets and all other ships can never colonize uninhabitable planets.

The biggest change I made this week was introducing a region detection system. A region in this game is a group of colonized or occupied systems which are connected adjacently to each other. This information is used to determine which player gets the points for colonizing a system, when to initiate combat, and the resolution of combat.

The week went well, and I feel like got a good amount of solid code done. The region detection is going to help a lot in the next couple weeks as it forms the foundation for most of the rules. I also laid out the goals for midterm which will help guide me as the midterm approaches.

For next week: I will focus on finishing the non-combat orders. I will use the region detection system I implemented this week to implement scoring.

As the GSoC midterm approaches, I've decided on a few goals to attain by midterm. In general, I would like to have a playable demonstration of the non-combat parts of the game. So the goal is for the player to be able to see and interact with the board and their fleets and see the expected result except where combat would occur. To accomplish this, I need to complete the following things before midterm:

• finish up the orders
• implement scoring
• implement end-game conditions (although they probably wont be reached without combat)
• make sure orders are processed in the correct order (see: http://nuleren.blogspot.com/2008/05/thoughts-on-simultaneous-turns.html)
  

This week I began work on orders and the turn sequence. I developed a very simple turn sequence to simply perform the orders in the order queue. This was mostly to test out the orders. I implemented the first version of three orders:

• The colonize order can be issued by any colonist type ship (merchants, scientists, settlers, mining robots). It consumes the ship/fleet and generates a resource which corresponds to the passengers the ship was carrying.
• The move order can be issued by any colonist leader. It moves the leader to the specified system and puts the leader's fleet in orbit.
• The attack order can be issued by a bomber. This order consumes the bomber's fleet. It adds the destroyed resource to the specified system and sets the destroyed flag in the system.

In addition to the orders and the turn sequence, I added a good bit of supporting code to generate starting fleets, planets, star systems, etc (See: 1, 2, 3). This extra code allowed me to fully test the orders.

I also merged my tae branch with the master tpserver-cpp branch which was a little tricky to do in cogito, but I think I managed to do it properly.

Overall the week went quite smoothly. No significant bugs or obstacles.

For next week: The orders I've implemented right now are not restricted at all, so I need to add some restrictions to prevent illegal moves. To do this I'm going to need to begin implementing the code to detect regions of colonized space. I also need to nail down what I want to have complete by the midterm as it is fast approaching.

This week I focused on ships and fleets.

I had a slow start to the week as I was trying to decide how I wanted to implement ships and fleets. Ships are a very important part of this ruleset. They represent the "playing pieces" of the game and will most likely be the only objects to receive any orders. When I was initially planning the game, the ships seemed to be logically divided into different fleets: a fleet of colonists, a fleet of leaders, and a military fleet. So, I originally thought to split them into these three fleets and send orders to specific ships within each fleet. However, when I started to look at the implementation of ships, I realized it may not be possible to send an order to a specific ship within a fleet. I inquired about it in the tp-devel mailing list and found out that this was only possible in TP04. So I spent time planning out how I wanted to handle this and also how each ship type should be organized. I settled on having one ship per fleet to support TP03, and maybe later breaking it out into a separate TP04 implementation.

I started the coding by implementing a property, some components, and a ship. The property, passengers, has 8 possible values and handles the 4 colonist types and 4 leader types. The components, cargo bays, each had a different value of the passengers property. The ship, a transport ship, has a cargo bay outfitted to carry one type of passenger.

To test all this code this I added a couple functions to create fleets, and added code to create a simple test fleet with one passenger ship in it.

I ran into my first big bug here. I tried running the game and I would get a seg fault after joining the game. I spent some time enabling debugging on both the client and server, and adding debug statements to the server. I discovered the problem was that I had removed the "damage" parameter from the fleet object, but hadn't removed all the references to it. I finished removing it, which fixed the seg fault, but then the client yelled at me. So I ended up just adding damage back into the fleet object, which caused the fleet to be created successfully.

This is where I hit my second bug. The sample fleet was created, but it didn't have the ship I made in it. You can read about the problem and my solution in this thread.

While I was working on the missing ship problem, I went ahead and implemented the remaining properties, components, and ships (here and here).

Overall, this week went well. It wasn't as smooth as the past couple weeks. I felt like I didn't get as much done, but I did learn a lot and working through those first couple bugs will definitely help in the future.

For next week:
Start working on orders and maybe a basic turn structure. Some of these orders may require a good bit of extra code to check to make sure they're legal moves. So, I probably won't finish implementing all the orders by the end of next week, but it should be a good start.

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!

So my Google Summer of Code project was just accepted! I'll be working with the folks over at Thousand Parsec (my mentor: Lee Begg) to create a new ruleset based on the board game Tigris and Eupharates. You can check out my unabridged proposal here.

I've set up this blog both as a place for me to jot down ideas as I go, and to chronicle my progress for anyone interested.

For the next two weeks, I'll be focusing on finishing up classes (I'm swamped with projects and exams right now...), but after that I'll be posting much more often.

I'm looking forward to an excellent summer!