Hammer of Code

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.

I’ve done it! I’ve rounded out my ruleset and implemented the last of the remaining critical functions required for a basic game. As it stands any number of players can partake in a game of Risk and perform attack moves, friendly moves, colonization moves and reinforcements. Those features all combined together equal a simple game of Risk. I was actually shocked at how quickly things came together. I have had to drop a few features I would have really liked, particularly drawing lines for adjacency, and postpone some other ones, such as bidding on empty planet’s, it is my opinion that having a basic ruleset at such an early time will give me a lot of time to refine on what I have. I know already there are a lot of little bigs to be worked out, and I don’t have any illusions to how much time I will be spending debugging, but it is hard to ignore the fact that I will have a lot of time to “upgrade” what I have to be something more. Being that I have a basic, yet buggy ruleset running at this point in time it is pertinent to reevaluate my scheduling for this term and the next.

I’d like to commit the remainder of the term to debugging and refining the existing basic ruleset. I’d like to see a relatively bug free ruleset by the time midterms roll around. As for extending the ruleset, I can imagine many tweaks to the game mechanics will occur in the next few weeks; Particularly the improvement of attack movements (conflict resolution, odds, etc.) I’ve already run into a few places where I’m not sure which mechanic is the best. I think it is my job as a developer to think long and hard about these mechanics, and pick what the best option is. Another important thing to note is I COULD turn “unsure” mechanics into options, and simply set the default as the most sensible mechanic.

As for the rest of my summer: Once a bug-free and mechanically robust game is ready then work will begin on map importing. As it stands my intention is to create an XML-based specification to import maps with, and give the user the option to specify a map to use. Since I have never dealt with parsing XML it is unclear what sort of timeline will be required to implement a robust import system: I might expect 2-3 weeks to get things nailed down. For the remainder of my time with Thousand Parsec I would like to contribute to Ruleset Development documentation, create shell rulesets for new developers to start with more quickly, learn as much as I can about C++ and programming in general, and apply said newly acquired knowledge to improve my my existing code (in readability, usability, performance and security.) Of course a lot of the scheduling for the last term will depend on what I exit the first term with, and I will be sure to specify what is going to happen closer to that time.

As my title suggest things start moving VERY quickly today. I’d finally gotten through with little things like OrderParameters and the like yesterday, and today I started on the orders themselves, more specifically their doTurn() methods. I have to say I was shocked at how quickly things started moving with Parameters out of the way; I mean, I would write 5, 10 lines of code, compile, get NO errors, then launch the server and see that already I had almost completely and correctly implemented the order. Hit the drawing board to tweak things up and half a day later I had my reinforce and move orders almost completely implemented. All I have left to do with those two orders is to tidy up player messaging and in the Move order, implement attack movement (colonize movement and reinforce movement work though.) For messaging I mainly need to figure out how to get a string out of a uint32_t and am drawing a blank on how ot do it properly. For Attack moves I just need to grab the code from RiskTurn that checks a planet’s OrderQueue, and then do some “rolls” for the actual attack.

If the rest of this week turns out to be as productive as today I can expect a basic ruleset inside of a week. No promises, I’m just very excited to be moving at such a great pace

Today turned out to be highly productive. I spent almost the entire day using TextMate’s TODO bundle to tie up loose ends. Consequently I don’t really have any big things to go on about in this post. I don’t want to subject you to a point form list of 15-25 little fixes I made, so I’ll keep it short:

• Fixed some bugs in my random planet assignment code that I knew were going to cause big problems.
• Fixed some bugs in my Turn code that caused things not to display.
• Added code to calculate players reinforcements

• For the rest of my little changes please see the commit log.

The time has come yet again for another weekly report. I have to admit I didn’t think time would fly by so quickly at the beginning of the week. But as they say, “time flies when your having fun.” It holds a lot of truth as I am really starting to enjoy myself this week. While last week, and the weeks earlier, were a monotonous “toe-dipping” into a frigid lake, this week is more like just diving in. While I can honestly say I made tonnes of mistakes (some I noticed, some I fixed, some I spent to long fixing, and others I have yet to discover,) I have also taken a tremendous amount of risks and chances; From trying things without aid, to creating more original code.

Even though at times the difficulties I’ve ran into have been trying I’m not without fault, and some of my more glaring deficincies have come to light. Thankfully these problem spots were identified by my mentors, and through some very constructive criticism I am now aware of them. If I could only take one thing away from GSoC I would hope that it might be the ability to either reflect and improve on my own flaws, or to learn how to take criticism effectively. I would hope other GSoC students have the opportunity to receive good criticism, and welcome it.

Shifting gears a little bit; Mithro anecdotaly shared with me that little things can often take far more time then you would like. I’ve seen a lot of that this week in dealing storing my graph and getting my orders to display properly. This week I largely tackled, wrestled, got pissed off at, and ultimately ditched boost graphs because of the level of complexity in using them. I opted instead to create a simple graph implementation using some STL containers; I think that things will be a lot easier now. With dropping boost graphs I am also dropping the ability to import graphviz graphs. In my opinion this is actually a gain for me because it gives me the opportunity to learn some file importing techniques, and while I may have saved time importing via graphviz, I would have spent a lot of time getting boost/graphs to work.

Its about time to move onto a recap of what I accomplished this week:

Monday

• Submitted first bug report. here.

• Statically ID’d all elements, which I learned from llnz is a very bad practice and have since undone. It was nice to find out, however, that IDs for objects are allocated first-come, first-server, and in order.

• Struggling with how to represent adjacent planets. Started looking into boost::adjacency_list. boost graphs.

• Reordered map to make it more visible between constellations. Unfortunately I didn’t snap a picture and the map has since changed. Here’s a link to the commit.

Tuesday

• Added general turn processing, and pseudocode of code to be implemented, to the RiskTurn class. This code wasn’t what I intended for turn order, but got me going with my own turn order. commit.

• I started using a few more tags like CHECK, FIXME, TODO, LATER to my code. TextMate has a TODO bundle that wrangles up any tags I specify and puts them in a list with links to code, etc. It’s been very helpful for jotting down a quick TODO or FIXME for things I know are wrong or need to be implemented.

• Added shell code to all 3 orders, move, reinforce, and colonize. A few of the mechanics of the risk game will require change to tpserver-cpp. For instance colonize orders currently will not show up on an unowned planet. As well some fiddling will need to be done to have order’s display properly with a list of adjacent planets populating it. Llnz has said he will help here. commit.
• Read existing turn/order code from other rulesets. Unfortunately the development of my own moves has been hindered by representing adjacency internally.

Wednesday

• Removed static ID setting. Llnz informed me this was a bad practice, I did nail down the ID layout for my objects though, it’s currently listed in comments above Risk::createUniverse(). commit.
• Switched over from Galaxy to Constellation. A bit of an exercise in mass find and replace, mainly I was glad to switch over to the more context specific name “Constellation.” commit.
• Finally settled on storing a players reinforcement total in a std::map in Risk. Also added some code to Planet::doOnceATurn that updates the current “minable” Armies as the players reinforcement total. commit.
• Implemented what I believe to be proper turn structure for Turn::doTurn. At the moment I haven’t tested the code due to the lack of doOrder code for my orders. commit.

Thursday

• Finally removed my default map (of 42 objects) with a smaller test map with only 4 objects. Things should hopefully be easier to test now. commit.
• Created some settings that give the player a little more control over reinforcements and how the game starts. commit.

Friday

• Finally got Risk::randomlyAssignPlanets working. I am now able to actually OWN some planets and start to work/test Orders. From what it looks like quite a bit of work will be needed to get orders displaying properly. commit.
• Ditched boost/graphs in favor of implementing my own graph. The graph I developed is internally a map of ID to a Node. Each node has its ID and a list of node pointers to its neighbours. commit.

Next Week:

My sole purpose next week is to implement Orders. I believe I’ve gotten through enough of the little things, particularly graphs, that I will be able to complete the actual Orders.

Since it would be criminal for me to be highly productive and successful for any more than a day or two at a time I (or my code maybe) decided today was as good a day as any for a segfault. To make matters worse for some reason “make && sudo make install” wasn’t good enough and the error didn’t crop up until after I had made about 5 different git commits. More on the segfault and how I found it after the jump.

Continue Reading »

Well that was a lot better than yesterday. In stead of hardly being able to code for half the day I had to pull myself away from coding today. I got a variety of little things taken care of today, some from Lee’s email, some from my list of things to do this week, and the odd other one, including some graphviz stuff. More on all that after the jump.

Continue Reading »

Well today wasn’t exactly what I expected. I had high hopes to go hard and build the frame for my turns and orders but I mainly ran into little brick walls. It wasn’t that I broke anything, I just ran into a bunch of little questions that I needed answered before I could go on. I was fortunate enough to receive an unsolicited email from llnz (Lee) answering many of my questions. I’m a little tired atm, so I won’t go into details, but I will let you know about the changes and development I make tomorrow.

In other news I got a pointer for a book Tyler thinks I should read after uncovering many of my deficiencies in C++ (from both lack of experience and too much time doing Java at school.) The books called Effective C++ and apparently I should read it like my life depends on it. Thanks tyler . I did read through the preface and skimmed a chapter or two and it seems like a lot of good info. Unfortunately I didn’t get to dig into it last night as I was helping my wife with her computer science coursework. I convinced her to take Comp. Sci. 101 through distance education and luckily for her our wedding band came with all inclusive tutoring for all the computer science courses she would care to take. Its to bad this university does introductory work in Java. For those learning only basic computer science I can see something like Ruby or Python as much easier. While I personally believe all Comp. Sci. majors should start out in C++ (as I did, at the university I began my degree at,) Python and Ruby could also be a decent stepping stone to curb interest and increase accessibility of programming.

Well today was a rather frustrating today spent trying to find SOME way to represent territories and their connectivity internally. My first instinct was to use a 2d array to create an adjacency matrix from scratch. While a valiant effort, it was ultimately futile, and I began searching for some STL way of representing my adjacencies. Well STL is great and all, but I don’t really need to be doing a whole bunch of “data structure”-smithing, and hence I found boost’s rendition of adjacency matrices, aptly called… adjacency matrices. Yes, as it turns out boost has a ready to use adjacency matrix. With that problem solved I have only left to implement the use said matrices. In another turn of events, I happened to click through a link to something call “graphviz”, which, APPARENTLY, the boost/graphs library can parse directly. This may make the transition/inclusion of a map importing ability easier than it at first seemed.



As stressful and consuming as it was, I didn’t spend my entire day fretting over adjacencies and the like. Among other things I managed to submit my first bug report, grant planets static and sequential IDs (in preparation for adjacency matrices,) and rearranged the map layout a little so it is easier to tell where constellations end and begin.



I also wanted to rewind to last friday. I’ve been trying really hard to get a nail on my formatting and content for those weekly reports, and mithro informed me of one last thing I forgot. As silly as it is I haven’t really spoken in the reports about how I feel about things. I.e. how I felt the week went, did I spend enough time on things, what can I do to improve things next week, etc… Since I am running a little behind schedule on posting about it I have to resort to bullet points:

• I worked ~35 hours last week. That is pretty much full-time, and I am quite proud of that and hope my dedication doesn’t wain.
• It made me feel very accomplished to get a star map displaying properly. It’s always nice to have a visual product to hinge satisfaction on; and the star map is probably the biggest satisfaction I will get from visual changes. I would hope this coming week I can visually see some of my turns logic and orders come to fruition.
• I am satisfied with the difficulty of my project thus far. At first things seemed a little too easy but I am now seeing places where the difficulty and learning curve will be ramping up. It seems manageable but I will definitely need guidance here and there.
• I would like the pace to pick up a little bit in regards to coding. The first week was good, but I know I feel I should be putting out more work in the week. Mithro did tell me, in a round about way, that “administrative” style work like editing blog, etc, does count as work none-the-less

An Aside: What I did on the weekend:
I pretty much spent all the time I could (when I escaped from gardenning and yardwork) reading:

• TextMate: Power Editing for the Mac
• and Programming Ruby

I just have to say: The more I learn about TextMate, Ruby, TextMate and Ruby together, or TextMate + Anything (Blogging for example), the more it blows my mind. I’ve picked up at least 10-20 keystrokes over the weekend that I am using today to save time coding and writing this blog. There are even more shortcuts I can’t remember that I know will also save me time and energy. And then, Ruby, is just pushing my mind into some fascinating new paradigms about programming. Its scary going away for the weekend, learning some Ruby, and coming back to my C++ code and just thinking all day, “I could do this in Ruby like this, but how do I do it easily in C++?”

Hopefully this is more to mithro’s liking I did my best to at least link to one or two of the products of my work for each day.



This Week

• Monday:
• “Shelled out” the ruleset a little more by adding all create* classes. diff.
• Converted from basic Galaxy type to a class with a bonus integer that indicates the bonus garnered for owning the entire constellation/galaxy. commit.
• Added “Armies” Integer to the Planet class. (Later removed)
• Encounter a Bus Error when launching the server in a certain way - filing a bug report next monday. archives.
• Tuesday:
• A large portion of the day was spent trying to debug the bus error using gdb and ddd.
• Mithro taught me some good methods for asking for help/filing bug reports. instructions. help post.
• Wednesday:
• Added code to ensure all objects are visible. commit.
• Made note of a bug wherein client would not download objects. I later found that the Planet’s Frame was not being packed with enough data.
• Thursday:
• Converted “Armies” Integer to a Resource; Reinserted resource setters/getters and Frame packing code. Client now loads and displays universe properly. commit. results (really low res).
• Attempted to phase out Star Systems with Planets and in its stead implement lone Planets. It turns out there is a bug where lone Planets do not display in the client. Reverted the change.
• Did research and gave names to all stars corresponding to their relative positions in their constellations. names.
• Friday:
• Plotted all stars on a measured grid. pic.
• Hard coded those positions into the ruleset. Client now displays constellations in proper configuration. diff.

Next Week:

• Spread out star positions to make it more clear the boundary between constellations.
• Implement an adjacency matrix to represent connectivity between stars. This will provide a 2D-array to iterate down a row to discover a star’s neighbors.
• File bug reports on both:
• The Bus Error I discovered and,
• Planets not displaying without a star system parent.
• Begin implementing basic turn structure (before individual orders.) I believe this top down approach will more properly acquaint me with OrdersQueues and make it easier to implement the individual orders.
• Investigate the drawing of lines while issuing orders. This would allow adjacency lines to be drawn to make it more clear which territories neighbor the selected territory.