Animated camera

This week, added some animation to the camera movement to make it more smooth. When zooming in or out, it will move gradually instead of instant 'steps' like before. In addition, there will be animated panning when a system is double-clicked on the system list, or when pressing 'c' to center on the selected object, or when pressing "goto" in the message window. Since it will move in steps every frame, it is somewhat slow when the frame rate is low. This could be solved by having calculating the step size based on the frame rate. A harder problem is how to rotate a camera in a spherical manner around an object, which is probably a staple of most 3d games.

I also added some movement for the ships which will occur after a turn update. This allows you to roughly see where they are going, particularly for enemy fleets.

I guess this week's changes are mostly animation based, so it's a little hard to take screenshots.

Some additional minor fixes
Message window parses html messages now. This was largely thanks to Tim Ansell's suggestion to look at the htmllib and formatter library that comes with python, which saved me from having to strip out the tags manually. I still can't believe the breadth of python's built-in libraries sometimes. Batteries included indeed. One possible addition is to add additional formatting according to the html tags, right now I'm just stripping them out adding line breaks appropriately:



The keyboard shortcuts for zooming in and out (the plus and minus key next to the backspace) is fixed now. Previously, it was stuck in 'icon view' all the time.

Some interface changes

This week, I have added some additional elements to the user interface in order to make it more user-friendly.


The first would be the turn counter in the top-left hand corner, which is handy for knowing how long the game has been progressing for someone who is joining in half-way, and for knowing the current 'phase' in rulesets like Reach for The Stars, where there are three phases and certain orders are possible depending on the phase. However, it does not actually show the phase - the user will currently have to calculate it on his own.

Another difference is the End of Turn timer in the bottom bar, showing how many seconds are left until the turn is over. The 'End' button next to it is used to tell the server that you are done with your current turn, although this step must usually be taken by the majority of players before the server actually finishes the turn.

Next, when the user hovers the mouse cursor over any object on the starmap, a popup will display with some information about that object such as their name and owner (if any). In addition for fleets, the composition of the fleet will be shown, while planets will display their resources and star systems will just show how many planets they contain. One thing I'm trying to figure out is how to dynamically resize the popup in accordance to the text contained, to prevent text overrun such as in this case:

etower333's home planet - In the minisec ruleset, the home planet of a player is defined by having "Home Planets" in their list of planetary resources.

Another change made is to tweak the icon view so that it colours the icons according to their owner:


This makes icon view a lot more useful, especially as I'm still working out how to show ownership of planets in 3d view without colouring the entire planet.

A common issue with network applications is having the server down, or providing incorrect credentials, so an error message will be displayed when this situation occurs.

I'll be looking out for more areas where I can put information or error messages, but I probably won't post about it again as it's quite minor in implementation (though important).

One suggestion was to have a way of selecting between objects that are clustered closely together when the view is zoomed out. In the wxwidgets client, clicking on a star system will cycle through all the objects in orbit around that system, so I have attempted to make something similar - when clicking multiple times on the same spot, the client will cycle through objects overlapping that area.

Issues encountered this week
A new version of python-ogre was recently released (1.2 RC2), and contains a huge amount of changes from RC1. After downloading the windows build, I found that it wraps versions of ogre that I had never even heard of! (1.7 in this case - the latest stable version is 1.4.9 and the next slated release is 1.6, codenamed Shoggoth. Talk about bleeding edge. :)) Needless to say, it brought a few interface-breaking changes with it and I was considering whether to port the project over or not. One desirable thing about RC2 is that it supports CEGUI 0.60 which comes with a brand new tree widget - something which I'm sure would be very useful. One course of action might be to compile a custom version of python-ogre with just the new stuff that I need - something quite easy to do on linux as I just have to change some version numbers in the build scripts. On the other hand, that would make it more difficult for people to just download the source and run it when they already have python-ogre installed. I think that for now, the client will continue to target the previous version of python-ogre (1.1 since 1.2 RC1 has disappeared) until I can wrap my head around all the new stuff that's just come in.

Things to come next week
I will be working on animating the camera view to make it smoother (for instance, zooming in and out should be gradual and not abrupt) while making it possible to rotate around an object.

Also, I want to revamp the messages window to implement the great suggestion of having a two-paned system, and to handle messages with html tags in them, although I'm not very sure how I'm going to do that at this point.

Thirdly, I want to squish all of the bugs I've found so far. :)

Just playing around

Today, I decided to take a little break from coding and explore some of the other projects in the Thousand Parsec universe.

Quite a few of the GSOC projects (the two AI projects and the server configuration project) focus on allowing TP to be played by a single player. This is very exciting and I'm already envisioning creating a coffee-break ruleset similar to strange adventures in infinite space. :)

After reading through the list, I wanted to try out some of the rulesets, particularly Risk as it has a playable version available already. Unfortunately, due to my noobishness in gcc compilation I was unable to get the git version of tpserver-cpp (where all the rulesets are stored) working. What I tried instead was to copy the risk folder over to my working tpserver 0.5 directory and compile it instead. This seemed to work at first:

The screenshot shows the client connected to a server running the risk ruleset. Unfortunately, I could not seem to get the game working properly, as it did not assign me any planets or ships to start with. This problem also existed in the tpwx client, so I suppose the ruleset requires the latest tpserver in some manner.

Slight disappointment aside, I spent the latter part of the day looking at how I could improve the frame rate of the client somehow. The base fps on the client is very low, and even when the screen is not showing anything (all objects are culled) the framerate is clipped at around 40 fps. I found the bottleneck to be the starry background code, once I commented it out the framerate became about 99 fps (still without looking at anything).

Level of detail, in which objects reduce their polygon count as the camera becomes further, was another technique I wanted to apply. Thankfully, this turned out to be easy as I simply had to run OgreMeshUpdate (a program bundled with Ogre) on the models I wanted. After trying a few options, the framerate went up to about 15-16 fps. After a while I noticed some corruption in the model skin due to polygon reduction.

What I did was to tweak the distance levels so it only reduces when really far. I guess someone who can see at the pixel level might still notice it though.

After that, I rebooted in Windows to try creating a binary using py2exe. Since the script was already written, packaging it was not difficult but what I did notice was a tremendous boost in fps when I ran the client.

Here's a "action-packed" shot of the client connected to the demo tp server. With 6x anti-aliasing and 1280x1024 resolution, it still has better fps than the linux version. Wow, windows is great! Actually, the cause of the difference is probably my linux drivers. Since ATI has abysmal driver support, I'm running the open-source drivers which are slower in 3d performance but at least they work. (ATI drivers give me graphical corruption even when browsing the net or openoffice)

Here are my relevant system specs consisting pretty much of last-gen hardware.

Processor: Can't remember the model, but windows reports it as a 1.3 ghz Athlon.
RAM: 1 gig. I thought it was overkill when I first bought it.
Video card: Radeon 9800 Pro. I'll get Nvidia next time.
Motherboard: Nvidia nForce-2. Irony?

Status Report

This one is a little late, but anyway here is a recap of what I did last week.

Fixed the goto button for the messages window thanks to lots of help from mithro and greywhind in irc. Now clicking on it will cycle through all the objects specified in the message. Still not too ideal though. There was also a suggestion to make the message window into a two-pane reader similar to e-mail clients like Thunderbird. I really like the idea and it's definitely on my list of goals.

Fixed the move order in TP's Reach for the Stars (RFTS) ruleset. The problem was that move orders are implemented differently in Minisec and RFTS, one uses absolute coordinates while the other uses object ids. Order parameters are something I will be talking more about later.

Display a radial menu using CEGUI widgets. The circular background is a static image, while the buttons are created in code and arranged in a circular pattern around the center. The menu is currently toggled with the spacebar, and I shall have to find a way to activate it via the mouse. Also, it does not follow the object when the screen is moved around, which is something I actually intended but looks a little weird in practice.

Handling order parameters when sending new orders was pretty much the focus of the latter part of my week. Thousand Parsec has quite a few order parameter types, and rulesets can mix and match them up however they like, so parameters have to be handled in as generic a way as possible. Thus far, I have handled the following order parameters:

• Time
• Object
• List
• Absolute coordinates
• String

I haven't done the rest because I've not been able to find orders which use those parameters yet. Anyway, to implement these parameters, I had to create a new widget for each new parameter I found. I first drew up the widget layout to act as a template and hid the widget upon runtime. Then, I made a copy of the widget as needed and placed them inside a ScrollablePane, a useful CEGUI widget which allows it's content to be scrolled.

Finally, handling list parameters is a little different from the other parameters. This is because while other parameters can take in a generic set of values, lists only take in values from a limited set of options which are defined by the type of object selected. This requires creating the order first using some default parameters and sending it to the server. After that, the server will return the order populated with the options, which I can then use to show the user. After selection, the order with the user's selections is sent to the server to "overwrite" the initial order. This has the habit of creating "phantom" orders filled with default options when the client updates while the user is still filling in the order.

Now it's time for the strange problems section. :)


Some messages use html tags which are not supported at the moment. There's also a unwelcome gradient in the horizontal scrollbar now that I look at it.

RFTS is still not playable yet. The problem is mainly with the lack of ship design support, which RFTS requires to build even your first fleet, but there are also some usability issues such as not showing which turn it is as RFTS allows different kinds of orders depending on the current turn.

Still no nice way to colour the fleets and indicate which planets are your own. I might go with some kind of overlay over the objects containing the player's name.

Code structure. Under the hood, the code contains a lot of method calls which violate the Law of Demeter, in other words many classes have intimate knowledge of the structure of other classes and "reach through" them to get the things they need. I'm not sure if this is actually something particularly bad, but it is an eyesore. Also, there is a small amount of duplicated code which I have to remove as well.

Some updates

Here are the changes I have made to the thousand parsec client this week.

Movement orders possible by selecting a fleet and right-clicking the destination. Finding out how to send orders in thousand parsec was an important milestone for me.


Movement paths are indicated by a line. However, this does not remain when the turn updates. In addition, changing the destination will leave the old line behind. :( I will be getting to that shortly...


Able to delete messages. I would like the "Goto" button to center the map on the source of the event. For instance, a battle report message would go to the combat location. However I could not find any information in the message object passed by the server that might help. Currently, the message object has id, slot, type, subject, body, turn number and references as it's attributes, and clearly "references" would be a good place to look, but I found it empty no matter what the message. So, "goto" is still in progress. Also, I think a message count in the window title would be useful.

Able to exit to the login screen and re-enter the same game. This was done by clearing all the resources and loading them upon re-entry. However, tpserver logs do not report a client disconnect, so I have find out how to do that before entering another game.

Some bugs I have encountered:

The mouse cursor is hovering over what is called a "CEGUI listbox" object. Since I am using it to show available orders for the selected object, it required removing the list and repopulating it whenever a new object was selected. However I found that it would segfault immediately upon removal of an object. Finally saw a method called "setAutoDeleted(boolean)" for listbox items in the api, which deletes the item automatically when it is removed from a list. After setting it to False I could then remove items without crashing. Hope that this helps other python-ogre cegui users out there, since the setting is on by default. My unqualified guess is that python's gc does not like objects deleting themselves automatically.

What's next
I have been giving some thought to improving the look of the client. I think it should be pretty clear that the current 3d models are all placeholder objects. I've found Vega Strike to be a rich source of 3d models, although I have only played the game a couple of times. Ideally, I would like to have different models for each ship class, but this might become ruleset-specific. So right now I would assign a ship model type to each player, so "Player 1" would always get a certain model and so on.

Planet models should have a texture to them as well, but I'm wondering how to distinguish planets from one another. For instance, some planets could be "Terran" type, "Arid" type, "Acid" type and so on. In rulesets which don't supply such information, I would apply a generic planet type to prevent confusion.

For stars, they ought to have a glow in addition to their texture. Actually mithro, who created the client, has already put in "glow" billboards, but they are not visible as I think I forgot to resize them.

Currently it's not clear which ships and planets belong to each player, so they have to be differentiated somehow. I guess I could change the material settings for each fleet to colour them, but colouring planets would be weird. Perhaps I could change the colour of their text label, but I've already found some colours to be barely visible against the background. A better way would be to surround the planet with a coloured halo, because at least the player won't have to read it.

The skybox currently being used for the background has to go as well. I will try a particle system of white dots with billboarded nebulae. Hope it looks better than it sounds. :)

A status report

Yesterday marked the official start for coding. Following my schedule, these are my features for this week:

- Starmap will represent objects with different models
* Stars, fleets and planets can be distinguished from one another

This is where the coding I've done beforehand comes in handy. Stars, fleets and planets can be distinguished already, using some extremely primitive models.

If you squint, you can still see the blueprint lines on those ships :). Those are my three fleets orbiting around the home star system. It is a bit close to the other star for my liking, but I'm not sure what to do about that. I guess I will add some colour tinting to distinguish friendly assets from the enemies (which is everyone else).

- Client will show a message window
* Able to scroll, flip through messages and delete them.
* A Goto button will center the map on the object related to the message.

So far, I have implemented some of the windows already, based on how the existing tpwx client works. Since the messages window can flip through messages using "Next" and "Prev", I will be adding a goto button and delete button as well. I guess I'll have to resize those existing ones.

Taking a little break

Right now, I'm on a rather impromptu vacation in Sydney. I'll be back on Sunday.

Thinking I could make commits on the go, I copied my ssh keys over to the laptop which I lugged all the way here. Unfortunately, it seems that the tp server rejects any commits not from the original machine? I'm not too familiar with ssh I'm afraid.

Currently, I'm trying to send orders to move the fleets around, but how to do that is still not obvious to me. I've read the tp03 protocol and skimmed through the tpwx client code already, but the real problem is that the weather is really great for sightseeing, even at night (which starts at 5+ p.m.). Internet access around here is a little hard to come by as well. What I wouldn't give for some of Singapore's island-wide wifi right now :)

On the GSOC front, it seems that Google has now sent out the mystery book via Fedex to all the students. I haven't read any blog posts since then for fear of spoiling myself.

On one hand, I can't wait to get back to Singapore and code, on the other, it really is rather nice here...

SleekSpace

Over the weekend, I found a nice CEGUI skin for the client. When I first downloaded it, it was strangely missing a lot of property tags needed to work correctly, such as text colours and one of the frame borders not showing up. Not sure if I managed to get the same look as the original, but at least I learned a little about the Falagard skinning system in the process. I'm guessing there are still missing property tags since I haven't tried all the widgets.

I thought I would try some simple layouts to see how the main gui might look, then I ran into some problems with the star system labels.

Looks like the GUI blocks out the star objects correctly but not the text overlays. I'll have to look into how OGRE's overlays work. Once the rendering order is sorted out, I'll start to look into how I can retrieve information(messages, system information, etc) using the tpclient library.

edit: Looks like I just had to change one parameter from False to True when creating the CEGUI renderer.

I got accepted!

Looks like once you get into the Google Summer of Code, your e-mail is added to a private student's mailing list, where a few hundred students are currently making their introductions...

So, after an hour of reading and clearing e-mails, I wondered whether anyone from my university also joined in. Nope, perhaps no one applied in the first place?

Anyway, I'm gonna list a few things on my todo so I don't forget when exams are over:

1. Replace the Taharez look in the GUI.
   
2. Create layouts of all the gui elements.
   
3. Document the class structure of the current client and the client library, so I can get an overview and some idea of how to proceed.
4. Explore ways of making the universe look prettier. I want to look into writing shaders and particle effects. Make the GUI look good as well. Transparency and animation?
5. Explore how Python-Ogre wraps libraries, in case I need to wrap something e.g. update CEGUI to 0.6
6. Add an in-game console. I'll figure out why later :)
   

Well, it's been the end of a really busy week for me. I've submitted 5 assignments this week, and I don't think I've had a decent nights rest yet. At least I had some fun fooling around with the Thousand Parsec source code and Python-Ogre. One of the devs suggested that for a good GSOC application, I should write a basic 3d client to accomplish the first two of my milestones. Well, I did do something like that. First, I ported the old pyogre client over, then I made it lose some of it's functionality. :) What I mean is, the starmap looks really empty, with only two objects: The Universe and the Milky Way. Heres hoping I can make it look more like the original this weekend. If so, at least I will have something to contribute even if I don't get the nod.

Mechanical process of porting:

1. Change import statements to direct to python-ogre modules instead of pyogre.
2. Fix the errors that crop up. For instance, pyogre uses a lot of attributes, whereas python-ogre provides set/get methods.
3. New OIS system for input, no more ogre.EventProcessor
4. CEGUI works about the same, just remember to use the set/get methods instead of direct attributes. It won't work and there won't be an error to tell you what went wrong.
   
5. When things run, but don't look right... I'm still working on this.
   

In other news, tpclient-wx just had a new point release, with lots of UI improvements, such as a cleaner toolbar and more display options.

First Post!

I'm starting this blog to write about my hobbies, specifically software development. The other blog is more for complaints about my life, so I decided to split the two.

Firstly, this is partly, or maybe wholly, motivated by my attempt to enter the Google Summer of Code, where I'm going to be applying for a student position in Thousand Parsec, a game-framework for making 4x space strategy games. Having a blog would be useful for making weekly updates about my progress, you see.

One curious thing about Thousand Parsec is that I've not even heard about it before, and judging from the responses of other student applicants, it looks like I'm not alone. I've been depending on blogs like TIGSource to keep myself abreast of the indie scene, but perhaps the fact that it is not an actual game makes it fall into obscurity. Or maybe... I'm not spending enough time on the Internet?

Well, it's on the Big and Famous Google's page now, and hopefully my duty will be to promote it even more by creating a new client that looks good and is easy to use, similar to Galactic Civilizations super high-tech looking interface or Master of Orions's classic feel that still keeps me coming back due to it's charming artwork.