Hammer of Code

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.

In terms of cleanup and Lee’s email I fixed up a few things. I learned from Lee that I shouldn’t be statically setting the IDs for objects; But also that the IDs are given out in order. I removed the static declarations and did a little testing to confirm that universe was 0, then the constellations followed, and then star systems and planets alternated after that. I added a counter for the number of constellations and planets and came up with the following system:

• The Universe is always ID 0
• The Constellations fall on IDs 1 through num_constellations (S)
• Where k is Planet/System number
• The Star Systems fall on S+(2k-1)
• The Planets fall on S+(2k)

Lee also let me know I didn’t need to name my “galaxy” objects as galaxies, and as such they are all known as constellations in the code from this day forth! A simple Find-and-Replace, but it definitely gives everything the right feel. Aside from that nothing major changed due to Lee’s other comments. Lee did mention some changes to the server may be needed to accomodate for my current style of game startup. At present non-owned objects don’t display orders, and hence I can’t start a game with everyone bidding on territories. If for some reason Lee can’t do it, (he usually can ;)), then I will have to randomly assign territories. Both will work, in fact, I should code the latter as a setting this week.

I moved on to changing my generic turn processing, which would have just gone over every object and completely processed it’s OrderQueue, to reflect what the processing SHOULD be. That is to say:

• All Colonize orders in the front of all objects queue’s get processed
• All Reinforce orders in the front of all objects queue’s get processed
• All Move orders in the front of all objects queue’s get processed
• All remaining orders in the front of all objects queue’s get processed

I got things fairly compartmentalized; There is a single function, processOrdersOfGivenType, which processes orders…of a given type. If the order type isn’t specified then it just processes all the orders. I have almost got doTurn completely coded. I just need to implement distribution of reinforcements.

Unfortunately I haven’t so much been able to dive into Orders yet. I’m mainly being held back by A) storing/accessing reinforcements, and B) the graph.

For the reinforcements I’ve managed to create a variable and some accessors in the main Risk class. They don’t necessarily NEED to be there, but even if they are in a helper class of some sort I still run into the problem of accessing that class. Even with them in the Risk class I can’t quite figure out how to grab a reference to the object while things are in the air. This might be newbitude, or it might be me stretching things a little too far.

As for the graph; I successfully moved over from adjacencymatrix to adjacencylist and things seem to be working ok. I had some trouble creating lone vertices until I realized I could implicitly create vertices by creating edges between IDs. I.e. boost::addedge(22,52,graph) creates an edge between ID 22 and 52 in the graph. The problem I am having is justifying manually entering in every single edge, which I am guestimating is in the 100-200 range. I started looking a little more seriously at readgraphviz and the DOT language. I played with it a little, even went as far as to recreate the connectivity of my board in DOT, and found it quite easy to use. I didn’t manually pin each node to a position, and thats where I’m a little bit stuck. Do I embed the positional information in the DOT graph and then wrestle with trying to extract that information to create my objects? Or do I leave graphviz simply to represent the connectivity of the nodes, whose position is specified in some other file.

STOP, I just had a thought. Shame on llnz, mithro and xdotx for not stopping me and saying “Ryan, why the hell are you trying to get your graph and objects working with 42 objects? Why aren’t you playing with like 5-10 objects?” To which I might reply, “Your write guys, it is really stupid trying to deal with that many objects!” Really, why the heck have I been trying to wrangle 42 chickens into a barn to try and figure out if they can escape when even 2 or 3 chickens in the barn is all I need to test it? Tomorrow I will go ahead and extract all my hard coded declarations and replace them with 4 or 5 generic declarations, with one or two constellations for good measure. That way I can hard code some edges into the graph and start working on Orders.

Taking into consideration my scaling issue, I may as well sideline my fretting over map imports until later on. I can imagine myself being greatly delayed had I tried to get map imports going for almost 50 objects and over 200 edges before even starting turns, simply because I didn’t want to hard code my map. (I wasn’t stupid to want to skip on hardcoding my map, I was just stupid for thinking I had to hardcode the full map :P)

On a total change of subject. I had a brush with certain doom last night. I was playing Final Fantasy, My Life as a King yesterday for the first time in almost a week and I JUST so happened to leave my brand new plasma TV on all night. Now I don’t say brand new to brag, I say it because plasma TVs with under 200 hours of on-time are even more likely to burn-in than plasmas are in general. Needless to say I was freaked when I woke up to my TV sitting on with a big, bright menu smack dab in the middle of it. I was scared, and I got rid of the menu to assess the damages. Stunningly, after a whole 9 hours on, the TV had only the faintest residue of the menu left over. I ran the “burn-in fixer” (which just runs the spectrum of white to black across the screen) for an hour and afterwards there was zero trace of burn-in. A word to the wise, be careful with your Plasma TVs!