GSOC 2009 Final Report


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.

Several uses of media..

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.

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.

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.

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

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

Advertisements

~ by greywhind on August 19, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: