Planet SoC -

== July 4 == Ye Famous Travelling StarFleet Problem :)

vi1985 — Sat, 05 Jul 2008 02:19:00 +0200

It’s that time ‘o week again for me to write about my progress. The previous post is only three days old, but I got some stuff to blah about ;].

So, for the most part I’ve been splitting my time between getting the client ready, and preparing the actual robot for some action. I’ve been having some issues with the ruleset and the low-level library (see last post), but mostly they’ve been resolved (except for the annoying bug of being unable to colonize!), and now it’s a matter of some time until the client gains complete functionality.

In parallel to that, I’ve started to work on the actual AI mechanism and infrastructure (by infrastructure, I mean creating the necessary framework for the robot to function). I have decided to forgo the original plan of running a natural-selection mechanism for actions on each and every move for the sake of a simpler, more conventional, but still (I think) very elegant solution (which still implements a genetic selection process, only this time during its creation).

The reason for this was twofold: first of all, I discovered a couple of problems in the design that were hard to overcome; the simulation of each move would’ve been a real issue, and the mechanism for illegal-move sifting would not have been very difficult to implement, due to “hypothesizing” game-eventualities many moves ahead. Another, equally important reason for me to change the plan, is that this was really a two-fold project, as I had to spend (and still do, to some extent) an incredible amount of work on getting the Java client started, even before getting started on the robot. Hence, de-facto I’ve only started work on the robot almost at the midterm-point, and I need to simplify the design a bit to get it in good shape before the fat lady sings! ;].

I’ll have much more to say on the alternative solution by next Friday, but in short it will be a four-part project: a) the client and game library, b) robot logic, c) a robot-factory for creating new robots, and d) an evolutionary framework for optimizing them. Each robot will have ‘behavioural characteristics’, by which its behavior will be guided, and which will be susceptible to mutation in the evolution-simulator.

Here, I guess that’s it for this week.

PS - Do check out the code in the repo in the “ActionMethods” class for a home-brewed solution of Ye Famous Travelling StarFleet Problem + some mathematical analysis on it! (It’s not very tested yet, but I’ve got faith in it).

Till the dolphins leave,
____________________

Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO

Weekly Report (June 30 - July 4)

Nuleren — Fri, 04 Jul 2008 23:03:00 +0200

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.

Weekly Report 8

jphr — Fri, 04 Jul 2008 22:08:50 +0200

Seeing that midterms evaluations lay so near things have started to get exciting again! This week saw the transition from private alpha testing to actual player testing, a good deal of C++ reading, and the start of planning for the second half of the term. I have to say my spirits were starting to wane, alpha testing was getting very dull and dreary. I wasn’t quite sure if I was testing wrong, if the stage of testing was nearing an end, or if I was just running out of ideas.

A brief letter to Tyler (my mentor - have to say it :P) and a break to finish reading the last 2/3rds of Effective C++ revitalized my spirits while I awaited Tyler’s reply. Tyler informed me I was most likely ready to start having other players test the game and my feelings weren’t unusual. Soon after I recruited my wife to help me playtest. Once I got Jackie (my wife) rolling, and introduced to Thousand Parsec in general, things started going really well. Playing with someone else almost instantly illuminated quite a few more glaring bugs and errors I didn’t notice before. The two games we played helped me fix up some message formatting, improve the accuracy of Attack moves (particularly conquering planets,) gain more information on my “view” bugs and finally, revealed a SUPER BUG I’m calling “Phantom Ownership.” Jackie also helped me to notice parts of my documentation that could be less ambiguous, and other areas that need work. She also noted the disappointing lack a connectivity map, something I need to work on next half-term.
As for how I’m actually FEELING about GSoC this week… better, much better. Testing was/is pretty hard; I found myself getting bored of playing Risk and running out of things to test for (as well as becoming “blind” to errors I should have noticed.) My time spent reading Effective C++ was excellent, and I’d like to continue reading bits and pieces of various C++/programming books as I keep working on my project. The benefit have been noticeable, and I should be able to improve my coding in the rest of GSoC, as well as fixing/revising older code. I’m excited that next week marks the start of mid-term evaluations; I feel as if I underestimated myself when I initially scoped out my project. As a result I’m a bit ahead of schedule: I have a fairly stable game, needing only a few more features to be complete. The focus of the second half of my term will be on XML map import, increased clarity in the visual presentation, and improving documentation.
Now for the week:
Monday:

Read the middle ~1/3 of Effective C++. Monday was a shorter day due to a family visit.
A bit of testing. No new bugs discovered, documented more on “view” bugs in bugs.txt. commit.

Tuesday:

Family visit + Canada day.

Wednesday:

Finished Effective C++. Otherwise a very slow day (spoke with Tyler about testing, post.)

Thursday:

Did a lot of research and thinking about XML and Map import. See post.

Friday:

Did play testing with wife:

Fixed bug where player created extra units when conquering a planet. commit.
Fixed formatting issue for origin player on Move order. commit.
Fixed logical error where player could receive better odds by attacking as a “last stand”. commit.
Added more info on Bug. 1 - “View” bug -> Will be putting together Mailing list post to ask for help.
Discovered “Phantom Ownership”: A player retains the ability to issue orders on a planet after it has been captured. Also asking for help with this on the ML.

Next Week:
Seeing as next week marks the beginning of midterm evaluations it seems appropriate to start work on XML map importing. After an excellent comment from Boris Kolpackov I have good insight into what parser I will be using, and as such can develop an XML Schema for the map specifications and evaluate the suitability of CodeSynthesis’ XSD. I will also continue testing with my wife, and anyone who cares to give me their time to playtest with! In addition I will enhance Getting_Started documentation to be more clear and unambiguous.

xml and the like

jphr — Fri, 04 Jul 2008 00:13:40 +0200

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.

Here is the DTD for those versed in XML:

!DOCTYPE MAP [
!ELEMENT MAP (CNST)>
!ELEMENT CNST (PLNT)>
    !ATTLIST CNST name CDATA #REQUIRED>
!ELEMENT PLNT (ID*)>
    !ATTLIST PLNT name CDATA #REQUIRED>
    !ATTLIST PLNT id CDATA #REQUIRED>
    !ATTLIST PLNT x CDATA #REQUIRED>
    !ATTLIST PLNT y CDATA #REQUIRED>
!ELEMENT ID (#PCDATA)>
]>

(I had to remove the beginning braces because of display issues)
The only issue a predefined DTD raises is that it creates the need for a more sophisticated xml parser. My original intention was to use the TinyXml parser, but in its frugality it omits DTD validation of XML. DTD is a feature I think is fairly important for a map import class, primarily because a validated XML doc should THEORETICALLY contain a valid map (if my DTD does the job correctly.) That valid XML could then be imported via DOM, possibly directly, into the game. While a DOM import would be nice, it may not be possible. My backup plan would be the following:

Do a pass over all constellations. Create each one (using name), and add a pointer to it to a set.
Do a pass through each constellation, over all planets. Create each planet (using name, x, y and parent constellation) and map the specified id to the planets TRUE in-game ID.
Do another pass. This time adding adjacencies from the parsed XML to the game. This can be accomplished by using the ID map to relate xml IDs to true IDs.
Done. At this point a valid map should have been created

Going back to choosing an XML parser; My next candidate to investigate, and the #1 result when you search for “XML C++ Parser” is the Xerces C++ Parser. From what I understand, Xerces is a little bit more robust XML parser. While TinyXML is under a fairly loose license, Xerces is under the Apache General License, so I’m not entirely sure about its usability.
In other news: I just received an EZFLASH 3-in-1 GBA cart for my Nintendo DS, and so I will be bidding you all adieu to muck around with all the GBA homebrew (and other stuff) I can!

Have you got a 27B/6?

ezod — Thu, 03 Jul 2008 20:15:55 +0200

I think the first half of my GSoC project, comprising the administration protocol, the modifications to tpserver-cpp and libtpproto-cpp to support it, and the standalone tpadmin-cpp administration client, is ready for prime time, or at least a half-hour spot at 3:00 AM on the public access channel.

I’ll still be hammering it for bugs over the next day or two, but fingers crossed, it looks good right now. There are still a few gaps in functionality that will probably be added at some point; notably, the local command set is only updated at login currently, but eventually the client may want to watch for changes in the server-side list and update.

If you’d like to try it out, compile the config branches of tpserver-cpp and libtpproto-cpp, as well as tpadmin-cpp. Note that this version of tpserver-cpp runs as a daemon, but you can disable that behavior with the -d switch. Issuing open localhost and login admin admin to tpadmin-cpp should give you access to a set of commands on the server (type help to see them all).

I’ll greatly appreciate any feedback, especially suggestions and bug reports.

canada day

jphr — Wed, 02 Jul 2008 22:50:46 +0200

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.
As Tyler told me when he recommended the book, “it will transform a novice/intermediate C++ programmer into an advanced one,” something I can now retrospectively agree with. While a single read through hasn’t necessarily transformed me into a C++ guru, it has certainly made it very clear to me HOW I will program when I reach C++ nirvana. I learned a lot from the book and I am sure when I consistently and constantly apply all that knowledge I will truly be, a C++ master :P.
Another semi-milestone of my week is that I believe I am nearing the completion of my personal “alpha” testing (if thats the correct word for it.) At present I am more and more feeling like I have depleted my store of “nastiness” to throw at my ruleset to try and break it/bend the rules. Since private testing is a very…private matter, I’ll try and outline the what and how of my testing:

Initial Testing: Treat the game “normally” and ensure that Orders/game works in the simplest flavor. This stage more or less ensured that the game “worked” in its most basic playable form. This testing occurred mostly during development, in my case (even though I did play a simple game or two upon completing the “basic” game).
Full game testing: This stage of testing saw me playing a few complete games of Risk, both in “random planet assignment” mode and “bidding mode”. I didn’t strive to push the orders particularly hard; I merely played some games to completion.
Abusive testing: This stage of testing saw me “beating the crap” out of orders using the white-box approach; I knew how my orders worked, particularly their weak/less-thought-out points, and I utilized those to either abuse or break the game. This stage helped me to eliminate a few potential “cheating” locations, where users could create new units, etc. Particular attention was payed to the Colonize and Move orders, as they represented the most complex and fragile orders.

At present I believe I have rounded out the frailty of my complex orders, and am confident that all orders work correctly when used in (almost) any combination. From guessing, and an email to my mentor, Tyler, the next logic step appears to be peer/player-testing. I’m now tasked with having other people play my game in an attempt to locate further inadequacies/deficiencies. The most obvious candidate for this is Tyler, but seeing as he is under a fairly heavy load at the moment testing with him may have to wait. There is the possibly infinitely more discriminate candidate known as “a wife.” I believe my “wife” will be able to really do some damage to my game, both aesthetically and mechanically; I will enlist her aid this week to let loose on my ruleset. As for my time between peer testing, I plan on furthering my C++ knowledge further, and going over old code to clean things up. I may begin THINKING about XML parsing for map imports, but I am going to go out on a whim and restrict myself from coding that until after midterms (which is quite soon anyways.)

canada day

jphr — Wed, 02 Jul 2008 16:50:46 +0200

As Tyler told me when he recommended the book, “it will transform a novice/intermediate C++ programmer into an advanced one,” something I can now retrospectively agree with. While a single read through hasn’t necessarily transformed me into a C++ guru, it has certainly made it very clear to me HOW I will program when I reach C++ nirvana. I learned a lot from the book and I am sure when I consistently and constantly apply all that knowledge I will truly be, a C++ master :P.
Another semi-milestone of my week is that I believe I am nearing the completion of my personal “alpha” testing (if thats the correct word for it.) At present I am more and more feeling like I have depleted my store of “nastiness” to throw at my ruleset to try and break it/bend the rules. Since private testing is a very…private matter, I’ll try and outline the what and how of my testing:

Initial Testing: Treat the game “normally” and ensure that Orders/game works in the simplest flavor. This stage more or less ensured that the game “worked” in its most basic playable form. This testing occurred mostly during development, in my case (even though I did play a simple game or two upon completing the “basic” game).
Full game testing: This stage of testing saw me playing a few complete games of Risk, both in “random planet assignment” mode and “bidding mode”. I didn’t strive to push the orders particularly hard; I merely played some games to completion.
Abusive testing: This stage of testing saw me “beating the crap” out of orders using the white-box approach; I knew how my orders worked, particularly their weak/less-thought-out points, and I utilized those to either abuse or break the game. This stage helped me to eliminate a few potential “cheating” locations, where users could create new units, etc. Particular attention was payed to the Colonize and Move orders, as they represented the most complex and fragile orders.

== July 1 == Problems, Solutions & Starting the fun part

vi1985 — Wed, 02 Jul 2008 04:31:00 +0200

Ahoy. I wanted to post this report on Friday, as usual, but due to some extraneous circumstances (coupled with a 3-day wilderness trip Saturday-Monday) I was only able to get one out today.

In the past week of coding I have encountered several problems. First of all, there are a couple of issues related to the ruleset, which are still standing. First of all, there is the issue of mapping numeric-to-actual ship-types. I was hoping that it would be hard coded (e.g. scout is always 1, Mk.1 destroyer is always 3, etc) , but nash suggested that it might be determined by the server at runtime. I’m still waiting for the final word from xdotx on that.

Another issue with the ruleset I encountered, was the complete inability to produce anything on newly colonized planets, since any amount of colonists magically disappears from the surface, and no resource-points are being generated thereafter (although I still apparently own the planet). This observation was made on tpclient-pywx, and confirmed by my own client. I’m still waiting for word from xdotx for what this might be. (Smells like a bug, but perhaps I’m missing something?)

Finally, there was an issue with sending orders, that was related to the proto-library, which jezuch quickly remedied, and now I’m able to successfully pass orders to my assets in the game-world. I proved this by implementing the “fleet-move” order, and successfully moved my fleet around the universe.

So, what is still missing in terms of client functionality (out of the stuff that I really need, that is), is production, fleet merge, fleet split orders, and numeric-to-actual ship mapping. What I want to concentrate now on, is the actual logic and overall architecture of the bot. I already introduced some convenient algorithms into my representation of the universe map (get n-closest star systems, get contents of star system, get distance). I will be adding to these as I go along developing the robot logic, and hopefully by the end of the week I’ll have a good skeleton to build on, and some concrete algorithms to control the behavior of the bot.

Later,
Victor.

____________________

Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO

Very Clever Mistakes

ezod — Tue, 01 Jul 2008 16:16:32 +0200

Well, tpadmin-cpp almost works properly now.

The connection problem was due to the console input loop monopolizing the single-threaded event loop, so that the sockets never got checked for data. On Lee’s suggestion, this was fixed by making the console a TPSocket that would be scheduled by the event loop.

Another pair of problems in libtpproto-cpp were giving me trouble. The first was an incorrect delete statement that was causing segfaults, the other an incorrect packInt call before packing a string command parameter (I have no idea why I put that in there originally).

Now I just need to figure out why I get a SIGILL every time I try to use the same server command twice…

Weekly Report June 22 - June 28

JLafont — Sat, 28 Jun 2008 19:59:00 +0200

I learned a lot about Python and tpserver-py this week. Mostly about shelves and some of the inner workings of the SQL system in tpserver-py.

Basic Research implementation is up!

It was fun. Most of what needs to be done now should be simple to implement.
I have to refactor it out of using shelve and into tpserver-py’s normal database.
Shelve helped me get the basic design pattern of the research done which was essential to figuring out how I wanted to implement it. It should make next week simpler as I can concentrate on learning the SQL part of tpserver-py.

Each player now uses their own Drone list when producing drones
Players can now research new drones
Found a bug with Order Packets and fixed it.

This was technically my first real (and I’d say impacting) fix to tpserver-py. It allows protected attribute functions for orders to access their object ids. Fixing this will allow me to know which player is the one researching or building drones so I can provide them with their own list of options.

I wasn’t able to look into Time Frames much since I decided to focus more on research as it is the last major milestone I’ve set to achieve before the mid-term evaluations.

Next Week:

Going to refactor Research into the tpserver-py’s database using the SQLType.
Going to add some more Research options and types
Implement those types into the actual game so they have an impact
If time permits, I’ll try to look into the Time Remaining Frames.