Contrary to what I expected I ended up spending the day looking into XML, xml-parsers and map importing. I kicked things off by familiarizing myself with XML; turns out I had a decent grasp on how XML worked already. I did, however, learn that it was possible to define a “Document Type Definition” or DTD to specify which tags have what, which attributes exist of tags, and the like. I threw together a simple DTD for the map metalanguage; It allows the map to have multiple constellations, each with a name attribute. Those constellations can then have multiple planets. Each planet has a name, id, x, y attribute, as well as any number of “id”s of adjacent planets.

Read more »

You may have been wondering where I disappeared to the last two days. The combination of a slow Monday and family visiting on Tuesday made for little to write about, and consequently I forgot to write, about anything! Rest assured I have been working. The start of my week has been occupied largely by reading, and I can gladly announce that I finished reading (for the first time :P) Effective C++ by Scott Meyers.

Read more »

Contrary to my previous belief I did actually end up having a week where I spent less than full time working :P. This is a result of a trip to Winnipeg to attend my sister’s high school graduation. Things went well, and I’m sure my sister will appreciate entering a Digital Arts program with a great big Wacom tablet and a new flatscreen monitor.

Coming back to WORK work, my weeks work has largely diverged from the realm of coding and dived head first into debugging. I was a little discouraged when I kicked things off because no bugs seemed to show up. Bu as I played on I began to notice little bugs and inconsistencies that I have since begun tracking. I nipped a few bugs, particularly a bug that let people create units out of thin air , and am now starting to pay close attention to another few.

An unfortunate side effect of spending lots of time playing, and not much time coding, is I can’t really give a day-by-day account of what I accomplished. I’ll indulge tradition with a bullet point list, to keep consistent:

This Week

• Added Colonization messaging to the Colonize order. commit.

• Began more intensive playtesting. Some interesting bugs cropped up:

• Player could abuse the Colonize order to “create” extra units that shouldn’t exist. This problem was fixed by removed an unnecessary test in the code. commit.

• Some times when a player joins a game they can’t see any of the objects they own as “theirs.” This compounds to cause other players planets to appear as their own, and their own planet to appear as someone elses. Ultimately the player can still issue orders on their own planets. This bug seems to also cause a server crash when the game is finished. The procedure to recreate the bug has been noted, but upon using gdb the crash cannot be recreated. Strangely enough this bug only occurs with names like test & test2, but not with test & “afjjlsfd.”

• Read 12 items of Effective C++’s 55 items.

• Rewrote the Risk ruleset wiki entry on the Thousand Parsec Wiki. link. As well I created a “getting started” page on the wiki. link.

As for next week I’ll be continuing down the same path, debugging, playtesting, and other administrative work (such as reading about C++, website work, etc.)

Well I’m afraid I have very little to talk about, even after missing out on a day of blogging. Today and yesterday I spent a good deal of time working on things alternate to debugging. Yesterday I completely rewrote the Thousand Parsec wiki entry on Risk, and created a new “Getting_Started” page on the wiki as well. Today I finally got around to a heavy dose of reading; spending a good deal of the day greatly extending my knowledge of C++ with the book Effective C++. All this alternate work makes for very boring writing, and I don’t really have much to say other than this: Writing documentation helps in understanding how your own product works, and Effective C++ is a really good book.

Tomorrow sees me travelling 150km to Winnipeg to go to my twin sisters High school graduation. Ok, she isn’t my TWIN TWIN, but we can easily call ourselves twins, we look almost exactly the same and share tonnes of the same interests; We hang out a lot when I am in the city during the school term. When fall rolls around she will be attending a somewhat prestigious digital art program in town.

Farewell for now and I’ll speak to you again on Friday.

Today marked what was probably the first more serious bout at testing the ruleset. While I had played a little last week it wasn’t with much attention to detail. Today, however, I took care to think about things that might go wrong, and more systematically test actions that might cause errors. Since I feel the majority of my errors (and the worst code of the ruleset) lies in movement (particularly attacks/collisions) and colonization my focus has been on combining the latter in potentially abusive ways. It seems to be well established (and correct me if I’m wrong) that individual moves occur without error; Hence I’ve been stringing together attack and colonize movements to cause errors (logical or otherwise.)
Testing for the day didn’t uncover any move related bugs. I did make note of one bug though. Here’s a quick run down:

• Test1 fights and conquers test2 - no problems
• Close test2’s client and relogon as test3
• Test3’s client shows Sadr as owned by test3, but the client gives the “you own no objects” window
• Reloading the universe and advancing a turn both do not fix the display.
• Test3 conquers 3 territories. No change.
• Test1 conquers test1.
• Test1 loads next turn properly, receives “Winner” message
• Test3 client causes the server to crash when loading universe
• Server crashed on a Bus Error during “Get Message frame”

I can’t really say much else about that bug other than I will try and replicate it with a gdb’d tpserver tomorrow.

What I did this weekend:
After months, if not years, of anticipation I finally caved and started playing a semi-translated version of Mother 3. For anyone who doesn’t know about Mother 3 it is what would be Earthbound 2 in North America had it been translated or released outside of Japan. My interest has recently been sparked by the recent activity of the god among men “tomato.” With tomato’s menu translation and a game script at my side the experience has been almost the same as playing the original Earthbound, which I might add I am also currently playing. Tomato is currently working on a full translation for Mother 3, and has been for over a year now I believe. Speculation has been that he will be complete in little under half a year, at which point North America will collapse under the glory of an English Mother 3.

Well I have to say the weeks are flying by more quickly each week. Not so much in a “oh my god I’ll never get done” way, more of a “I’m enjoying my job and the time spent working goes quickly” way. This week started off a little rough, some (or maybe just one?) migraine made Monday and Tuesday sort of awash, compounded by being daunted by starting testing. I got some good feedback on HOW I can actually test, and unfortunatly spent all but today on rounding out some features, namely Colonize. That isn’t to say bugs weren’t squashed, nor that they weren’t big, I assure you some of them made the game unplayable, but I consider those bugs a part of implementing those features.

Like I said, I did actually get to hunt bugs today, in fact, I did my first “full game” playing the ruleset with myself. I’ve started to keep a text file for myself of bugs, logical errors, and oddities for myself to work off of. I’m not sure if the mentors would like this “git”ified so they can see bugs, but I largely (and possibly wrongly) have been writing bugs down, finding the problem, fixing it, confirming the bug is gone, and then erasing the bug in the file. Let me know gentlemen.

Having completed a playthrough I do have a few concerns I’ve noted:

• You need to actually enter a Move order to see adjacencies. Therefore if you don’t know the board you are a large disadvantage.
• Some of the game logic can be manipulated (cheating? or clever play?)
• Firstly players can issue multiple Move orders from one planet to absolutely hammer another planet until the player wins. This may not be cheating simply because the player risks losing a lot of units if they try too many times and lose rolls.
• Secondly an almost dead player (1 unit/damage worth of units left) can increase his odds against an attacker by trying to attack his opponents (an attack conflict arises, defender gets bonus roll, but since they only have 1 dice they get no rolls, and thus can’t die.) This one probably IS cheating, I might change the logic to let a player attack with 1 unit remaining simply so he has to take damage.

I’ve also received some conflicting advise from different mentors about whether or not to produce an AI. I’m not going to name names but I think ultimately I will produce an AI if time permits or if it seems necessary to test more properly with one. At present my testing goal is to eliminate errors during “regular” play, namely errors in Attack Move conflicts and Colonization bidding. My secondary testing goal is to eliminate or at least take note of abusive play methods. It’s my opinion that if I did produce a simple AI it may not push the limits of attack movements, colonization and fair play as well as a human player could do (at such an early stage.)

Well its probably about time to move on to my weekly accomplishments:

Tuesday:

• Migrated from the 4 planet “test” map to a 2 full-size constellation “testing” map. commit. picture.
• Changed Move::doOrder so conquerred planets clear orders when ownership transfers. commit.
• Created config option to disable colonize orders. I’m not really sure if the option will even be settable from the config file. At present the option gets defaulted to the opposite of the random assignment option. commit.

Wednesday:

• Spent far more time than I should have muddling with tpsai-py and the text-based tpclient.

Thursday:

• Implemented the Colonize::doOrder. This ended up taking longer than I anticipated. As of now the bidding process should be correct in most cases, playtesting will be required to weed out any bugs. commit.
• Fixed various bugs that cropped up. I’m contemplating labelling small bug fix commits with a “bugfix:” tag. Feedback mentors?

Friday:

• Worked on fixing bugs. These bug fixes generally have their own commits for each bug. As mentioned above I may start labelling bugfix commits to set them apart; since its not so much useful to link to 5-10 commits on minor fixes.

Next Week:

• Focus will mainly be on testing, playtesting, and code refinement.
• As with this last week, time (more time hopefully :P) will be spent educating myself in C++ and other proper coding techniques.
• Add messaging to Colonize order.

Well I had an interesting time today implementing my Colonize doOrder. What can I say other than that I learned a minor lesson in “10% of the work takes 90% of the time.” I honestly expected implementing Colonize to take less than a day, but I ended up wrapping up today with a Colonize order that may or may not even work correctly. In my opinion the Colonize::doOrder has turned out to be one of the most complex parts of the Risk ruleset, simply because of how messy it is to poll other OrderQueues for orders. It was good though because I found a logic error in my OrderQueue polling where the correct queue wasn’t being polled. This same code is being used to resolve attack conflicts, so two birds with one stone.

From the looks of thing I will be spending tomorrow debugging Attack moves and Colonize orders.

Well I expected debugging and testing to be a bit of a drag, but I didn’t realize how hard it would hit me. The relative “high” of pushing out a basic game was quickly squashed by the daunting task of making sure things worked properly. Being that I am relatively new to development in general testing on this scale is quite a shocker. It isn’t like school algorithms and programs, where the answer is either right or wrong, with some boundary checks sprinkled in to ensure users can’t screw around. No, this is far more deep and complex, I don’t even think I could imagine up all the little ways someone could screw up my ruleset.

I’m frankly quite a bit lost. It was easy enough to say that I would be debugging and testing until evaluations, but I don’t really know what, or how to do that. Be gentle on me here, but what sort of tests/playtests should I be doing? Do I just play the ruleset a bunch with myself, trying out little things? Do I come up with a whole bunch of “things to try” and do those in some playtests? Do I write methodical unit tests to do every single thing in every combination?

Mithro mentioned in a comment on yesterdays post that I COULD script the text client, but I that I can also look into creating an AI. I decided to start playing around with the AI and consequently spent/wasted almost my entire day trying to get it up and running (not MY ai, just an AI in general.) I also spent a little while playing with the text based client. Its not entirely clear to me HOW to use the client, any pointers on that would be appreciated. (I’ve connected, logged in, even selected objects, but I haven’t been able to “play” with the client yet.)

UPDATE: Well shucks (yeah I said that) I got tpsai-py working with the version 0.2.x branch of libtpclient-py. Someone let me know if that is too far back. I’m thinking Risk is simple enough I can throw together an AI in a day or two.

As far as this week has been going in general it hasn’t been as bad as it feels. I did make a lot of small fixes yesterday, and any bugs I’ve ran into I’ve been able to fix. As bad as I feel having “wasted” time failing, if I can drudge through and get a system going for testing things will be far easier in the long run. At present I am not completely satisfied with display, and am hard pressed to find a way to show users connectivity more readily.

After missing out on blogging monday I was really looking forward to a longer blog today. Unfortunately I can hardly see straight for some reason or another, so this won’t be terribly long.

I was really happy to notice yesterday evening that one of my fellow Thousand Parsec GSoC students gave Risk a whirl. Things didn’t quite get going for him, but he gave it a try; In retrospect I think the reason things didn’t work was because the quickstart-risk config file doesn’t really get things rolling, especially on the smaller map (as of yesterday.) Until an official release anyone wanting to try out risk should use the “testing-risk.conf” file located in modules/games/risk (from your main git folder.) Reason being, I haven’t set up the default config to launch a suitable game. At present that config will launch a game where no one gets any objects. To rectify that my testing config turns on the “random assignment” option that gives out planets in a pretty high proportion (again, because of the testing config.) I should REALLY get around to changing that quickstart config file

Other than that the week sort of kicked off to a slow start. I spent yesterday incapacited by a migraine and only got around to real work today. Today was spent tidying up, implementing little features, and a lot of bug testing. I have to say I didn’t have very high expectations for bug testing, and I haven’t been let down. While the guys on the mailing list got me set up with a lot of great tools, the one thing I am missing is something to automate client testing. It gets tedious launching a server, 2 clients, connecting with the clients, issuing a bunch of orders via mouse, and then repeating after a recompile. I know there is a text-based client and maybe that can simplify my woes. If anyone has any suggestions or anecdotes as to how they tested their rulesets, please let me know.

This week was a big week for me and Risk. At the close of last week I had a ruleset that just barely displayed in a client, and had a few moves that did nothing. Today, one week later, I have a fully playable ruleset with unit movement and reinforcement move “fully” implemented in their basic state and player messaging for all currently implemented features. Obviously I’m coming out of this week feeling really good about the way things are going. Its about 3 weeks before midterm evaluations, I have a basic ruleset, a few options, and time to work out bugs/increase polish. It doesn’t so much excite me that I am where I am, as Risk is pretty simple; I’m more excited that I didn’t get stuck somewhere along the way to creating a ruleset and fail. I’ve gotten past what I think is the hardest, and most uncertain part, and now I have a solid(?) base to build on.

Informatively speaking, I managed to work full time this week again. Having done so 5 weeks in a row I think I will be able to manage to continue as such for the remainder of the summer; From now on I’ll probably only report if I didn’t work full time for some reason.

Monday:

• Implemented a getAdjacent method for planets that returns a list of neighbour planets in the graph. commit.
• Implemented the RiskTurn::calculateReinforcements() function. The function rewards players reinforcements based on a few user set game-options. commit.
• Implemented a check for a fully claimed board in risk.cpp. This function is used to determine if spaces are availible on the board. commit.
• Fixed the onAddPlayer function in Risk to properly filter out players if the board is full or options restrict players joining. commit.
• I started added more logger calls for quick debugging of logic errors.
• Added miscellaneous checks and messaging throughout the ruleset.

Tuesday:

• Properly populated the Move order’s list of adjacent planets. commit.
• Implemented the Move order. Players can now move armies onto adjacent friendly and unowned territories. commit.
• Implemented the Reinforce order. commit.
• Started working on messaging in Move::doTurn. It was particularly challenging to do so until I found out about boost::format for making messages with uint32_ts.

Wednesday:

• Implemented attack moves and restrictions on the number of units being moved based on a planets current state. Also implemented various fixes and modifications on how Move orders work. commit.
• Implemented a dice roll system that takes attacker and defender odds, roll dice for the players, and returns a pair indicating how many units each player will lose based on that roll. commit.

Thursday:

• Added a system for sending messages to all players involved in a Move order. This includes the attacker/originating planet owner and defending players. In the case of attack moves defending players are informed about the attack, whom is attacking, and the results. commit.

Friday:

• Implemented odds restrictions. This ensures the attacker/defender doesn’t get more rolls than they have units to support. commit.
• Added generateListOptions for Colonize. When enabled, the order can be applied to any planet. commit.
• Added reinforcement messaging. commit.
• Added messaging to announce a game winner. commit.

Next Week:

• I’d like too spend a day or two next week buffing up my knowledge on C++. In particular I’d like to read Effective C++, as well as some other web resources I’ve been pointed to.
• Implement clearing of OrderQueues on conquerred planets.
• Create a slightly larger static map to facilitate testing and debugging of the ruleset now that it is playable.
• Implement a bonus for owning whole constellation.
• Implement the colonize order. I’d like to tie the order to the current risk_randomly_assign_planets flag. When false, players will start with a single home planet, and will be capable of bidding on planets with the colonize order. When true, players will be randomly assigned planets and will be unable to colonize any open space on the map; Players will still be able to colonize adjacent planets via the move order.