Dynamic Tips, Bandwidth and Smooth Cameras

You might have seen the photos from the recent GO423 games exhibition in Brisbane where we showed Forts to the public. It was well received (again), and people had a lot of fun with it. We did notice that there were some pretty common mistakes or sometimes general confusion about what to do. There’s also the point that knowing what you can do and developing a competitive play style are different things. We do have tutorials with a voice over to introduce people to the game – they have to be carefully crafted. I watched one player go through the resources tutorial and get stumped even with text on screen telling them what to do. It didn’t help that it was probably too loud in the room to hear the voice over well.

After this event Nick and I decided to put more effort into easing the learning curve by adding context sensitive tips to the game. We’ve implemented five so far. One recommends using the R key to repair damage around the cursor (see screenshot below). The others recommend building resource collection and storage devices when the player can’t afford something or is maxing out. More will soon follow, including a tip to recommend building level platforms (to allow device placement) and to build a sniper in order to fire a missile launcher. It’s a bit of a balancing act, of course. We don’t want to overwhelm or annoy the player, so we need to limit how frequently they pop up, and ease off when the player shows proficiency. After three dismissals the tip no longer shows. I still think there’s value for many players in a structured tutorial, but the tips will serve as a good substitute for players who want to dive in, to fill gaps in the tutorials and to reinforce them. I’ve started adding tips to the tutorials themselves to provide additional guidance when the voice over can’t.

In order to simplify specification of the tips (important for localisation), I had to implement word wrap. Easier said than done, but still a fun little task. Nick wanted to emphasise some words with colour, so I also introduced some limited form of markup to identify the words inline. Multi-word phrases have to remember the highlight state across new lines – an example of something you discover as you’re implementing such features. The word wrap will be useful for other aspects of the game too, such as sub-titles and multiplayer lobby chat.

We also had the opportunity to have a local game design class to test the game for a day. It was interesting to see their style develop and some of them becoming competitive. During the initial stages players don’t have much of an idea about the consequences of what they are doing. For example, the player might select the shield material and build a few randomly at the back of the fort. They are expensive to run and will do nothing to protect the fort from incoming fire there. The player is yet to work that out, and if the enemy is a bit more savvy they might destroy the now energy poor player. We don’t want new players to become frustrated by shooting themselves in the foot too much. In an effort to limit this, I have programmed the game to switch to bracing after a new shield is built. It should reduce new player frustration and perhaps make it more apparent that the shield is expensive to run. It could annoy seasoned players if they want to build more than one shield at a time. Time will tell if it’s a good move, but we can make it optional. Many of these little usability improvements are being identified and implemented at the moment, and the external testing we are getting is helping dramatically. I’m looking forward to launching the Early Access program, but we have high standards and so are taking our time to make a good first impression.

Another improvement I’ve made is an optimisation of bandwidth usage. To enable the game to progress synchronously it must send regular ‘tick’ messages. They basically tell the connected clients that there are no more commands pending for this time-period of the game and they can proceed to calculate the new game state. In order to check if the clients calculate the same game state as the host the client must send a ‘tick check’ message back. It contains check sums of various different aspects of the game state, such as structures, devices, projectiles and resources for the different teams, as well as the random number generator. Having the check sums itemised like this makes it much easier to identify what caused a desync when it happens, so it makes total sense. I didn’t realise until recently, however, that I don’t have to send them all the time. They are only needed when a desync actually occurs, which is increasingly rare. So I have cut down the bandwidth use substantially by sending a check sum of check sums for every tick, and only sending the full itemised list of 14 after a desync has been detected.

The game doesn’t actually use much data anyway, but I only started thinking about this because I have just bought and moved to a small farm where we can’t get ADSL. This was a fact I discovered only after entering into the contract – the owners had assured me that you could get it. A satellite connection has something like a 600ms latency, which would make anything but a turn based game unplayable. It was out of the question. The only option for me to play my own game at home was mobile broadband, which operates using the same technology as cell phones. After doing some research I was hopeful that 4G could do the job, but was nervous about the coverage and especially the latency.

The first test I ran with the Huawei mobile broadband modem blew me away. It was actually faster than the ADSL2+ broadband that I had been using previously in suburban Brisbane! The ping reported by speedtest.net was 20ms, with 37Mbps download and 3.3Mpbs upload speeds! This was with only 2 bars of signal! I thought that I may have to buy an external antenna, but I have gone for three weeks with typically 1 bar of signal and have been completely satisfied with the speed. Very cool and a big relief. The only drawback is the expense. The best plan costs about AU$6.60 per GB and $10/GB for additional use. Playing a game of Forts may only cost a few cents at that rate, but I started my career working on racing games designed to run over dial-up where the available bandwidth was much lower. It still feels good to optimise its use.

Over the weekend I reworked the camera manipulation system. Instead of working out the rate of change when a transition was requested and then applying it until the target is reached, it now keeps the source and destination positions and tracks the current time in order to interpolate between them. This allows me to apply different interpolation functions while still guaranteeing the arrival time. Previously all interpolations were linear, which was functional but very jarring. For short transitions I am using a cubic ease in/out function, which makes a zippy but smooth movement. For longer panning transitions I have made a composite quadratic/linear function. It uses a quadratic equation to ease in and out, but a linear function for the bulk of the movement. The slope of the functions are matched where they meet to eliminate a sudden change of speed.

Following this change I adjusted the mouse scroll-wheel zoom-in function to use the cursor position as the target. It takes the current screen position and the final screen position and interpolates a little way between them. More at wider zooms so it doesn’t take too long to reach a comfortable single-fort viewing position. Previously the zoom-in would use the center of the screen as the target.

Dynamic repair tip.
Dynamic repair tip.