Leges Motus Progress: More on Guns and Graphics

In our last update, we discussed the progress we’ve been making on the refactor in terms of guns, graphics, and gameplay.

We haven’t been idle since then! All of the gun types are now fully implemented, including area-of-effect weapons (I might post a more technical entry about exactly how I made area of effect weapons work, because it’s an interesting topic for Box2D development). This means that the gameplay (minus graphics and statistics and HUD and such) is essentially complete, at this point, aside from a few minor changes (notably, game parameters sent from the server are not yet fully taken into account, but that should happen fairly soon).

Archaemic has been hard at work on weapons graphics, and guns now show up with the player sprite. They’re not quite all positioned properly yet, but that should be done very soon. I’m excited to start working on weapons effects, but I’m not sure exactly when we’ll get to that.

Additionally, I’m pretty sure we hadn’t finished all the map object types last time we posted, but we have now. Even force fields are fully implemented and working.

In any case, playability is definitely coming along, and aside from visual feedback, there’s nothing stopping us from playing a real game on the test server again!

We’ll keep posting updates as progress continues unabated, hopefully with more screenshots coming your way soon.

Leges Motus Progress: Guns, Gates, and Gameplay

Greetings! Goodness – gigantic gobs of time go galloping by as I greatly neglect to give good glimpses into the game’s growing completion. Today, I’d like to update you on what we’ve been working on with Leges Motus, focusing on guns, gates, and gameplay.

Gates are mostly done being ported to the new version now, aside from the graphics. We can sit on them, lower them, and win the round!

Gun functionality is also nearing completion. We have all but area-of-effect guns in place (again, except for graphics). So we can once again freeze our opponents as they make their futile attempts to sit on our gates!

Guns are actually implemented in a much more intelligent fashion, now – whereas before, separate gun types (such as spread, penetration, and thaw guns) could not be mixed, so their features were limited, they are now all part of a unified standard gun framework. This means that you can add thawing parameters to shotguns, or whatever your crazy gun design happens to be.

Gameplay is coming along, and with freezing, unfreezing, gate lowering, and all related physics in place, a basic game of Leges Motus is nearly fully playable in the new client!

So where are we going from here?

1. Finishing guns and map object types, and other remaining gameplay features: We need to complete the map hazards, forces, and other special map objects before we can equal our old feature set, and we need area-of-effect guns as well. Then, we need to round out the remaining minor gameplay features to approximately the same state they were at in the old client.

2. Graphics: We need to add gate graphics, gun/firing graphics, and frozen player graphics. This includes animations.

3. Interface: We need the HUD, chat, player names, stats, etc. to be re-implemented with our new graphics setup.

4. Menus: We will need menus to be finished before the next version can finally be released.

5. AI: Somewhere between 2 and 4 above, we’ll need to implement AI players. We will start on the AI around the end of January, so we’ll see what we have done by then. Theoretically, the AI could be started any time after #1 is complete, but I’d really love to have some of #2 and #3 done before it if possible.

As my final tidbit of news, we have an artist starting to draw up some concepts for new player graphics for Leges Motus. We’re very excited about the possibilities, and I’ll try to get his permission to show some of his ideas on here in the future.

We’ll keep you posted.

Leges Motus Progress: Refactor, Physics

Well, it’s been quite a long time since I last posted. My apologies.

But the good news is, the lack of posts doesn’t have anything to do with a lack of progress on Leges Motus!

We’ve been hard at work since v.0.4.0, and I’m very excited by the cool stuff we’re working on. First of all, it’s all part of a gigantic refactor that involves rewriting almost the entire client. In simple terms, this means we’re fixing all the bad design decisions we made the first time around, separating out the graphics code from the game logic and physics, and from the networking, etc. This will make many new things possible: AI clients, shaders, better GUI elements, better physics, moving obstacles, and so forth.

We’re already moving forward on making several of these new, cool things:

1. We’ve switched to the open-source Box2D library for physics. It’s the same physics library used in Crayon Physics, among many other games. We’re amazed at how much more interesting we can make the gameplay with a full physics engine, rather than our own simple collision code. Here’s a screenshot of the game with the debug drawing for Box2D enabled, so you can see the bounding boxes:

Debug drawing for the Box2D physics in the new Leges Motus revamp. Replacing the physics code with Box2D provides a lot of cool possibilities.

Really, though, it’s hard to get the full sense of how many cool possibilities there are with Box2D until you see a video. I don’t have one for Leges Motus, but there are other Box2D demo videos on youtube you can watch to get a feel for it. As for the current state of physics in Leges Motus, we’ve got jumping and attaching to walls working better than ever, and a bunch of other cool physics should be possible as a side-effect (such as player on player collisions).

2. We are now able to attach shaders to the graphics in the game, which means we can start adding some really cool visual effects. We’re already working on a ripple effect for the impact cannon, which will be much cooler to see than the little dots we had before.

3. Once all the gameplay is re-implemented, we will be starting on an AI client. This is more of a long-term goal, but it’s something we’ve wanted to do for a while now. We feel that, without AI, it’s hard for players to find out how fun Leges Motus is unless they have a bunch of friends playing at the same time. Empty servers are self-perpetuating, so having AI opponents would hopefully allow us to break this trend.

4. As a slightly less earthshaking, but still useful, feature (and one we could not do before), we have made it so that the game scales to fit the display window. This means that players with larger screens will no longer have an automatic advantage, because they will see no more of the game than anyone else.

I’ll try to make it a habit to post a lot more updates in the coming months.

What’s on tap for Leges Motus?

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.

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.