Progress bar and preferences

This week, I added a progress bar which will show the status of connecting and downloading objects from the server.



Having a progress bar is crucial as users will not be expected to look at console output to determine what is going on. This was implemented by using Ogre's built-in progress bar and tweaking the code as well as colours to match with the current gui scheme. The progress bar shows up when connecting to a new game, and also when updating objects in-game. The background is blanked out to prevent sending orders during updates, however it looks very empty right now, so I'm thinking of putting up some of the thousand-parsec art as the loading screens.

One bad point about the client is that it runs slowly on systems without a 3d card, although I'm not decided on what minimum requirements I should be targeting. One suggestion made was to make the icon view (the map with abstract icons) dependent on frames per second, meaning that when the performance gets too low, the client should switch to icon view. I tried this out and it gave me some issues, specifically with how to switch the client back into 3d mode. Since switching to icon mode speeds up the rendering time, the client will keep switching back and forth between the two modes making the user feel nauseous. As a compromise, I made a preferences window for users to set the zoom level at which the client will switch to icon view. The window is summoned by clicking the "Config" button on the Login screen.


The thousand-parsec project has kindly provided us with some hosting space, so I will be putting up windows binaries in order to get some feedback. I have been messing around with tools like Inno Setup, but for now it is simply a self-extracting file.

My objective for the coming evaluation is to make the client as playable with the Reach for the Stars ruleset as I can, and at first I wanted to focus on the ship design component, until I learnt that RFTS does not require the user to create their own designs, which leaves MTSec as the sole ruleset with player-designable ships. I feel there is scope for adding some cool stuff here - ship design has always been a favourite of many 4x games.

Currently, I have the following issues to fix:
Select objects which are very close to each other - It is hard to click on objects, especially when they are clustered together, so clicking on a cluster of objects should bring up a menu to choose from.

No good way to indicate which planets are yours, the enemy's, or neutral - Perhaps have a coloured rectangle somewhere around it to serve as a flag.

Having a turn counter, to keep track of the current phase in rulesets like RFTS. Related features to this also include an End-of-Turn counter keeping track of the time before the turn updates.

I will be working on these issues tomorrow, as soon as I compile the latest version.

P.S. (ugly personal confession) - I guess I should have seen it coming, but this week saw a lot of distractions due to my powerful new system and it's ability to play the latest games, not to mention the Euro 08 tournament. Am I allowed to call playing Sins of a Solar Empire as doing research? Really sorry... I will make up for lost time next week somehow.

Icon view

For this week, I've been trying to implement a view where all the objects appear as icons when the user is zoomed out. The advantages of having an icon view are that the objects tend to get harder to spot when far, as well as harder to click on. Also, it's a good way to increase the frame rate when viewing many systems at once. At first, I tried making icons with letters on them, where an 'F' would represent a fleet, a 'P' would represent a planet and so on. However, the letters turned out to be too hard to read, so I went for pictures instead.


Hopefully what the icons represent is clear enough. Triangles for the fleets and circles for the planets and stars. I haven't coloured the objects according to which player they belong yet, but the colour scheme should be the same, except that I can now colour the planets as well. I'm not sure how to represent different ship types, perhaps I could scale the size of the triangle icon?

Another thing I've been working on is trying to create a starfield for the background. Since the current background code is slow, I tried a few different alternatives to the particle system approach.

The first thing I tried was to create a static image for the background, then make it into a skybox. At first, it looked okay:

However, at the corners of the skybox the stars appeared warped which made it unusable. I'm not really sure how to solve that issue; after some googling I found one method of using blender to map a sphere and then render the result, but I must have screwed up somewhere because the result looked even worse.

In the end, I went back to the same approach but reduced the "layers" of stars and replaced the star image with a pixel instead. This seemed to give me somewhat better performance. I also made the starfield stay at the same distance when the camera zooms in or out which should make it look more natural during movement. I'm still not too happy with the look of it, but I'm out of ideas for this at the moment.

This week hasn't seen too many updates, reason being I just got a new computer and I'm trying to install Mac OSX on it. With a little luck, I can try supporting the Mac versions of the client in the future.

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.

Sending orders via a menu

My focus this week is on sending orders with the tp client, so that I can actually play with it.

After some discussion with mithro and greywhind, we felt that having a radial menu would be a good fit for the client. I have only implemented a few orders, as shown below.


Pressing spacebar brings up the orders menu (if there are any) for the currently selected object.


Clicking an order shows the parameters for that order. If there are multiple parameters a scrollbar will appear. For orders that take in a list of arguments, I'm unsure how to get the list of available options.

Build fleet window with empty options box. :(
Once I am able to get the list of options, there shouldn't be any problem in sending the build fleet order. Moving a fleet is already ok, as shown here:


List of bugs in the program

• Some of the stars in RFTS (Enif and Sabik) appear too close together.
• Selection box not visible at a distance
• Selection box does not follow the ship after an update
• Order queue not update immediately after sending an order (must wait for update)
• Network thread crashes while updating if the client is accessing some cache stuff simultaneously
  

Screenshot tour

Today, I wanted to try my hand at colouring the fleets. This would allow the player to differentiate his forces from the enemy's. I also thought this would be a good opportunity to try and learn shader programming. I found an excellent resource: Nvidia's Cg book. But, after doing a few chapters I felt it would take too much time to learn and I wanted to have something to show by the end of the day. What I did instead was to edit the diffuse colours of each ship to match the player:

This shot is using Epyon's ship models. :) The little green ship orbiting the Terran-class planet is a scout, and those beefier types orbiting the star are frigates. Here's what another player's fleet looks like:


At this point, I realised that colouring the entire ship made it look a little weird, since most sci-fi ships are made of grey metals. The approach taken by most strategy games is simply to have different models for each player, or to colour certain parts of the model only. Anyway, I decided to take off the colours and just explore the system.

Red herrings

I got a little distracted by some issues yesterday.

The first was the sphere mesh I was using for planets and star objects. No matter what texture I applied to it nothing would display on the surface except for the general colour of the texture. For some reason I decided it would be cool to generate a sphere in code using the "create a sphere" code snippet. It cost a bit of time to adapt the code and finally I got stuck at the part using pointers anyway. What I did in the end was to create a new sphere mesh in blender with the texture coordinates applied.


Here's the stars and planets with a texture (from vega strike again!) applied. It is very faint, but the "glow" of the star has an issue as well: it runs into the image border and looks cropped. Once again, I spent time fooling around with different image formats and Ogre's scene blending options to try and fix the problem. I also tried creating flares with a transparent background but Ogre doesn't like that, it requires a black background instead. The cause and solution was found in this forum thread, which is to adjust the levels and make the outer glow invisible.

So anyway, I was trying to create a selection boundary around the selected object, and came across this cool thread detailing the use of stencil buffers and render queue listeners. After a while, I had adapted the code over to python but found what seems to be a bug in python-ogre: RenderQueueListener methods require a return value which is a pointer to a c++ bool object. Even with a listener stripped of all code it would still have the error, and I'm not sure how to create a c++ type. This might have been fixed in the latest Python-Ogre, but compiling that is quite a chore.


What I went with in the end was a simple billboard pasted over the selected object, which is still better than using the bounding box. I'm currently wondering if this sun, with the glow exposed, is more 'sunny' than the previous one.


After adding a few different types of planets and stars.

Ship Models

A huge debt of gratitude goes to the Vega Strike project, this model is from their upcoming Ogre port. I think this model would be good for a 'scout' class ship.

Actually, Thousand Parsec does have it's own talented modeller, Epyon, and his work can be viewed here. (Check out the cool concept art as well!) However, I encountered difficulties in bringing over the meshes from the .max format. Since I don't have that software, I had a friend to convert it to ogre for me. Portions of the model would disappear and also I was apparently missing some textures. I think these are all just temporary problems, and with a little effort they will be ready to roll as well.

Going back to the 'Scout' model, I found that scaling it in proportion to the planets would make it lose a lot of detail, so I will try scaling the size of all objects up to allow further zooming in.


It's extremely faint, but if you squint (or click on the image) you can see the previous background has been replaced by a starry background. I hope to make it dynamic as well, in the sense that when you zoom in it will generate more stars further back, just like actual space. And other possibility would be to tweak the particle system so it generates clumps of stars with a glow to them.

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