Leges Motus Progress – Multiple Weapons, New Map Features

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.

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.

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

CitiBank (The Horror!)

I usually just post programming-related updates to this blog, but I can’t resist deviating a little bit from that for this post.

GSOC is nearly over, and I’ve enjoyed it greatly. I feel like it has been the best possible summer job I could have hoped for, and I feel like I made a difference to Thousand Parsec.

However, Google is paying its students this year through a CitiBank prepaid credit card. I don’t blame them for this, since it was the only option available to them at the time. I put all my blame on Citi for the following:

1. The card can only be used at ATMs or to buy things. This would be fine, except that I just want to transfer my money to a real bank account, which requires going to ATMs, withdrawing cash, and then depositing it into my account. Why don’t Citi let us transfer money through a cash advance or wire transfer? Makes no sense.

2. There is a fee on ANY ATM transaction, even on the ones Citi claims to have no fees on its website and when I call their support hotline. This fee is anywhere from $2.00, on the really low limit ATMs that it claims are fee-less, to $5.00 or so on the ones it doesn’t claim to be fee-less but that have higher per-transaction limits.

This means that I had the following choice: an ATM that charges $2.00 per $200.00, for 1% of my money in total (it’s my money – why do they get 1% of all of it?) or $5.00 per $800.00, which is a little better, but not great.

3. There is, by default, at $1000.00 per day limit on ATM withdrawals, so I would have to go 5 separate days to withdraw money on top of the huge fees.

4. Fortunately, I was able to get them to raise the limit to $2500 per day for a short time, but it’s still a huge hassle, because:

5. Their customer service line. Where do I begin?

5. a. It takes 10 minutes to go through the menu, because it reads everything slowly and you have to listen to a large amount of info before it gives you any real options.

5. b. When you go all the way through the menu to the very last option in the very last nested set of menus, it finally says, “To speak with an agent, press 0.” When you press 0, finally expecting to get through to a person, it kicks you right back to the same menu. You can’t ever get through to a person that way. Ever.

5. c. To actually talk to a person on Citi’s system, you have to choose the inaccurately named “Change your address” option, which took me about 6-10 tries (that’s like… 5-10 minutes per call, too) to figure out. Then it sends you to the actual help line, where you actually talk to a person (who, if you’re really lucky, might have an accent that doesn’t make them impossible to understand).

6. Finding every possible ATM and calling all these times and trying every possible option to get around this took me many hours (I would guess about 8-10, total) of my time, which could all have been saved if Citi just allowed fee-less money transfers to other bank accounts. Is it really that hard? Other banks do it.

7. I finally found an ATM that would do $1000.00 per transaction for $4.00 in fees, and Citi denied the withdrawal. I had to go back to the one that did $800.00 for $5.00 in fees. Argh.

I have never encountered customer service this bad, except when I tried to get an online store (they turned out to be a lot shadier than I first thought) to refund my headphones that had arrived non-functional. That’s another story, though.

The point is that Citi is going to force me to pay a total fee of about $27, if my calculations are correct, to withdraw my own money from my own account, which they had no real hand in other than to allow access to the money to be placed on a piece of plastic. I also hear they charged Google for these cards, so they’re getting money on both ends that they don’t deserve. Especially given their impenetrable customer service.

I will never bank with Citi. That’s the end of this story. The agents at Wells Fargo who did everything they could to help me get through this mess were just as appalled as I was. I very much hope Google can find a better solution for next year.

GSOC Day 76-78 – Copy/Paste, Testing

The past few days, I’ve been working on order copy/paste. I had thought I was done with it, but then Mithro showed me that my old method could lead to strange behaviour if an order was changed while it had been copied. So, back to the drawing board I went.

With a hint in the right direction by Mithro (man, that libtpproto-py stuff is complicated), I eventually managed to fix up the copy/paste. It now uses the __str__method of the order to serialize it, save it, and then reconstitutes it with the fromstr() method of the Header class, applying the __process__ method to get the rest of the order filled out. This is actually quite simple, even though it took me a long time to figure out how to do it.

I then merged in the changes from some previous code reviews, submitted some patches, and went back to Media downloading.

Mithro still isn’t completely satisfied with the way the media downloading works, so I’m going to look tomorrow at his comments and do my best to resolve the remaining questions. Once that’s done, I should be pretty much finished with coding, and I’ll start packaging the client up for release.

I’ve tested the client on Linux and Mac over the past few days, and I have set up a testing environment for Windows. I’ll test on Windows tomorrow.

GSOC Day 74-75 – Order Pasting

I’ve spent the past two days fixing order copy/paste functionality in the client. The copying has always worked, but there were major issues with pasting an order into the queue. The main problem revolved around two factors: 1. orders are not easily copied completely, and 2. order changes have to be synced over the network.

Yesterday, I tried to go with the approach of writing a __deepcopy__() method in the DynamicOrder class. After some work, I was able to make a full copy of an order. The problem was that when it was returned to the original function, it couldn’t be sent over the network because DynamicOrder stuff is client-specific. So that wasn’t the right way to go, even though it was what I’d been working on all afternoon.

Fortunately, I finally came up with a solution today. I realized that I could use a similar process to that used to build new orders from given parameters, copying the data from one order into another and sending that across the network. This time, I was building the class that could be transmitted, so everything was much smoother. Finally, we have the ability to copy and paste orders.

That means that tomorrow, I’ll be looking into testing the new client on Mac and Windows, trying to get it ready for the final push towards the release.

GSOC Week 11 Summary

This week, on GSOC Weekly:

Media Refactor Nears Completion

Washington, DC: The White House was abuzz this week with Greywhind’s nearly finished media code refactor. The work has been in progress for weeks, nearly expending the full $80 million budget, and it was feared that cost overruns might occur. However, with a re-designed mixin class for tracking URL downloading, code repetition was minimized and costs were cut. Another cost-saving measure was taken in the libtpclient-py code, checking a simple file-size comparison before doing expensive hashing operations. Then, Greywhind created a new way to specify which file types were wanted, which was an extra feature not originally in the plan. President Obama said of the project, “We all have a new hope for a better media handling system, and it’s just this kind of extra bump that can get people motivated.”

TP04 Nears Release – Final Testing Underway

Silicon Valley, CA: At a press conference this week, Greywhind revealed that the TP04 client is nearing an initial release. He said, “After months of work, the TP04 version of Thousand Parsec’s pywx client is undergoing final testing against AI bots, ensuring that a full game can be played through without incident. A full game of Risk has been completed, and basic, multi-turn tests of Minisec, RFTS, and MTsec have been finished without major incident.” This came after news that RFTS and Risk were plagued by a few minor problems. RFTS was affected by a bug that prevented orders from being added, but Llnz, the server developer, was able to step in and solve it, reportedly just in time for a brief test. Risk was at first unable to show any visual representation of the starmap, but a quick patch to the top-level object determination function solved this. The release of the client is expected in less than two weeks, if everything goes according to schedule.

GSOC Day 70-72 – Perspective and AI

I have been working in the past few days on two different things, both with, unfortunately, too little success.

I have been trying to get an AI to run a good game on at least one of the rulesets, the best supported at the moment being mtsec and minisec. At first, I couldn’t get daneel-AI to compile. Eventually I got it, though, and after some fiddling with xml scripts and install locations I got it to run. However, it only works with risk and rfts, which aren’t completely working with the tp04 client. I’ll see if I can patch it up tomorrow to work with one of them.

I also have been trying to fix window perspective saving, also with little success. I have it saving the output of the correct function for saving the windows and loading it on login, but it always seems to load the same blank window at the same size. I don’t know what’s wrong, unless there’s something wrong internally in the config code, but it’s not going to be easy to figure out if that’s the case.

That’s it.

GSOC Day 68-69 – Media Polish Nears Completion

I’m too tired to write a long post today, but the basics of what I’ve done today and yesterday is this:

Mithro had made a lot of comments about how to improve the media code, and I went through and tried to do as many as possible.

I did things like remove wx as a requirement for the libtpclient-py media code, fix style, and allow for the specification of certain file endings to return rather than “everything.”

That’s it for tonight – I will try to play a game all the way through soon, to get ready for release.

GSOC Week 10 Summary

This week, I tried to finish up as much of the media stuff as possible. I updated the style of the media code significantly, removing unnecessary threading features and separating the threading out into a separate class.

I also moved the MediaLibrary code into threads.py, inside libtpclient-py. This was a good way to reduce the total number of necessary files and to keep all the relevant code in the same place.

Tracking media downloads has also been updated, so that a mix-in class does the tracking. This also centralizes code.

I spent some time this week discussing with Mithro and Llnz the various options for making multiple clients downloading the same file safe, but I decided to let someone else take care of it at another time, ultimately, because the best solution appears to be some sort of proxy server.

Also, away from media, I moved the panelPicture popup on the starmap to the corners, instead of right under your mouse. This looks much better.

GSOC Day 65-66 – Media and More Media

Today and yesterday have been a continuation of the media work I’ve been doing. Yesterday, I improved the tracking of which files were downloading for which panels, which had to be re-done due to the new downloading system (everything is centralized, so the tracking had to come from the centralized code as well). Mithro suggested today that I create a mix-in class to help decrease the code reuse, and I might try to do that tomorrow.

Today, I moved the panelPicture popup I’d worked on a while back to keep it out of the way of the user’s mouse and to keep it from covering important areas of the starmap. That went well.

There are still quite a few suggestions Mithro has made for the media stuff that I haven’t had time to deal with, but I’ll try to get to as many as I can tomorrow. After that, I’ll re-evaluate whether there’s time to continue on this kind of thing or whether I need to start switching gears for getting the release ready.