Warscale 24 - Loading procedure

Hi everybody!

This weekend, I forgot the laptop charger in the office meaning that I was unable to code as much as I wanted but of course that means more time with my family. As there was such a nice weather, I decided to take my 18-month old son to the beach for the first time. I found that he doesnt like to have sand on his feet so I had him on arms all the afternoon. I finished with sore arms but I had a nice day.

What was planned
On the Warscale front, I managed to use the remaining charge in my battery to synchronize the repositories with my Undead HP. I found my Undead HP able to run 3D so I decided to hunt down a bug which was crashing the game on the small Dell Latitude. Well, it looks like the HP, half dead and all, is still a beast because it managed to run the 2 servers, 2 clients, run at an acceptable framerate and not get any runtime crashes. Maybe that setup is too much for the Dell. At least the crash is fixed for now (just a problem with the animation definition).

Its incredible when something which at first looks deceptively simple turns out to be something really complex. I'm talking about the startup procedure which was the focus for this week. I must say displaying a progress bar is not the hardest part (more on this later).

Ready status
Last week I included a ready/unready button so that a player can inform when he is ready to play. I had to fix some inconsistent state bugs on this procedure which appeared when the game owner decides to disconnect. This is fixed now and working fine.

Different army sizes
The prototype always considered that every army had 40 units but this is no longer valid for the alpha version where the players can create their armies using 24 to 40 units. The problem here was changing the internals of the current loading procedure. The benefit is detailed in the next point.

Reduced startup message
The startup info was optimized saving between 60 and 240 bytes (depending in the number of players) on the startup message. This is not a magical saving. The data has been distributed along all the gaming process. (e.g. You get the player names when you log into the server, you get the player equipment when the player joins the game) so its no longer necesary to send again all that information. Its the same info being transferred but it has been diluted so its nicer on the network.

Bitmapped progress bar
Some controls are not what I want in Warscale. This time, I really required a skined progress bar not the simple one provided by Torque. I found a skinned progress bar as a resource but it was not what I wanted as it stretches the image at the middle instead of tiling it. This is a common problem with a lot of controls in Torque. Also it only provided a simple management of the bar caps.

So, I was forced to consider the benefits of writing such a control and realized that it was just not worth it. This problem can be solved with two bitmaps so I did that. I created my progress images on the required sizes. Then, I set two bitmaps controls one above the other using a wrap (not stretch) rendering mode with the same dimensions of my progress bitmaps (which are 360x24 size). One is the background bar and the other is the foreground bar. When I need to update the progress I just query the size of the back image (360) and multiply it by the progress (say 360*0.65 = 234), and set the width of the fore image to that value. The result is a fully functional progress bar.

What wasnt planned
Simplifying the startup procedure
Torque startup procedure can be a real pain. As Warscale is basically a fully local game with only a TCP thread to a server, I have managed to clean the procedure a little so its faster to load the mission. The code is also more organized but still messy.

Improved shard shutdown handling
Sometimes, the shard crashed due to a problem with a script or the C++ code. In that cases, all the clients were diconnected and sent to the shard selection screen. The problem is that they were not being updated when the shard was started up again so I was forced to shutdown the clients and start everything up again. This was a major problem and has been fixed.

Bandwidth pondering
As I had no laptop to work on at some times (my son loves to see YouTube videos in the HP laptop). My mind was free to wonder about the intrincacies of how in the hell will I setup all the servers when the game is ready????

So, I did some computations about the bandwidth. Warscale is basically a chat game running on a TCP/IP network. Each chat message holds information about an action like the player id, the spell target, etc. and average 16 bytes each (aside from any additional heading added by Torque which I dont know). The servers are currently configured to host 1000 players.

My estimate is that the average user will send 1 message each 2 seconds meaning a full server will constantly transmit about 8kb/sec which is way lower than current 1Mbit bandwidths so I guess I'm safe on the speed side even when players grow more fingers and start writing at ten times that speed. For the purposes of this exercise I will consider 32Kb/sec, that is, four times the expected speed.

So, 32Kb/sec ==> 1920Kb/min ==> 115200Kb/hr ==> 2764800 Kb/day ==> 82GB/month. I can get nearly that transfer ammount on a AU$150 plan + $10 for the static IP address account here in Australia (yes, they cap the transfers here). Of course, depending on the server charge, I just can increase or decrease the maximum player allowed in the server with no adverse effects.

But of course, I would like to host this on a dedicated server. If somebody knows a dedicated server service which allows to manage ports, run exes and install a SQL database and all please tell me.

Screenshots!
Not much to see this week. Just the loading screen which has been reorganized.

The plan for this week
Improved player disconnection handling
If a player disconnects while loading, the game should analyze the status. If there is more than one player still remaining, the process continues. If only one player remains, the game loading process is cancelled and all players are informed to stop loading and return to the game screen.

Other player status information
If the player finishes loading but the other players are still in the process, the client displays a simple message telling about the other player status.

With the loading procedure in place, this week goes to the ending procedure. That is, what happens when the player disconnects from a running battle. That means fixing the game results window and returning to the game lobby so that the players may have another go.

Also, the next week, I will improve the options menu and improve the keyboard response. I'm skipping the game on purpose as I want to focus completely on the 3D portion later.

Due to my Dell laptop limitations, it looks like I will be forced to write a single player version of the game after all. In order to simplify the AI, I will try and program the Kill The Boss single player game which means the server will pick a suitable opponent for you (and your army). Sometimes you will fight an elemental, sometimes a Dragon or a Ent, and so on. If you beat him before it beats you, you will get a reward. If the AI works for 1 creature, I may enhance it for 2, 3 or more in order to create an encounter later.

Thats all for now, good luck with your projects!
Guimo