While at PAX Aus 2015 we had the pleasure of meeting Meghann who writes freelance for PC PowerPlay. Tim gave her a demo of the game. “I can see myself spending a lot of time on this”, she said at the time. PC PowerPlay was writing a feature on the best 12 indie games at the event. Meghann devoted a whole page of the six available to a preview of Forts! You can find it in issue #247 which has just hit the shelves.
It’s been two weeks since PAX Aus ended. We’ve taken stock of what happened and what we accomplished. While it was not the first time we had publicly shown off Forts (that honour goes to our local GameOn exhibition), it was certainly the biggest yet. There were a lot more people coming past and press booking interviews. With the exhibitors fee, flights, accommodation, and a fair bit of preparation needed, the stakes were pretty high. Would people ‘get’ the game? Was it stable enough? Were people able to learn the controls? Do we have a chance of getting some good press? Let’s find out, dear reader.
We managed to get all of our equipment to Melbourne without damage and did most of our set up on the Wednesday, giving us time to troubleshoot anything before the expo started on Friday. We only had two playable terminals and one small TV to loop the teaser trailer plus another video that Nick had made to show the features of the game. I had built a mini ‘fort’ to hold our monitor. The idea was to get it above the crowd so people could see it from a distance. I even drilled bullet holes and stenciled burn marks radiating out from them. We had 1000 Forts contact cards and some candy for people to take. Thursday was spent tracking around Melbourne getting a few missing items such as a suitable ethernet cable for multiplayer games, head phones, gaffer tape, an adapter, screen wipes, insoles (a great feet-saving idea), and Strepsils (thanks for the tip Kamina!). We even had matching Forts t-shirts and the sign that Nick designed looked brilliant.
The press were there an hour earlier than the general public were let in on Friday. We managed to get ready to show the game in time, but it was not a mad rush to begin with. At about 9am the crowds started trickling through and Forts started to get some attention. The punters were getting into it, it was great! We had planned to run a ‘tallest fort’ competition on a special mini-game map, but too much fun was being had blowing stuff up so we dropped the idea. Many were signing up to our mailing list anyway.
On the first day I counted six people who came up and said that Forts reminds them of a pencil and paper ‘game’ they used to play when they were young. One dad even said he still plays it with his son. The way it goes is each player draws up a fort on each side of the paper, puts in little weapon emplacements, and then takes it in turns to draw dashed lines, showing where the projectiles were being fired. Yes, it relies heavily on imagination. It’s so unfortunate that none of the original battles I drew from my childhood have survived. I was happy to see the game evoking nostalgia in so many.
Quickly it was discovered that the game as presented was too hard for new players, so I made a few changes at the end of the day to improve the situation. The swarming missiles’ incendiary capability was disabled. The fire was made to spread at half the rate and do half the damage. The repair area radius was doubled. Some of the AI’s forts were crippled a little bit too, as they would just pepper the new player, making it difficult to coach. In spite of the learning curve, the PAX goers were excited about the game and many wanted to know when it was coming out. We ended up giving away about 750 of our cards.
During a lull I suggested to Nick we have a multiplayer battle against each other to show how the game plays out at high skill levels. Soon there was a gathering around us watching the game. It was a fun match and two of the spectators wanted to play each other afterwards, even though they hadn’t played it before. Nick and I coached our respective fort commanders; it was very tense! Nick’s player was victorious with a tried and true laser attack, our fort having insufficient armor to take the blow. We would have loved to see more of these head-to-head games, but one or both terminals were almost always in use, making it difficult for friends to claim them both at the same time.
Saturday was supposed to be the biggest day. It probably was a bit more busy but it was hard to notice. You have to remember to eat and drink. The insoles and Strepsils were serving us well as being on your feet talking all day takes its toll. We were having a steady stream of media come and ask us about the game with varying degrees of preparedness. It was always fun, as they asked some of the best questions. It’s been thrilling to see us top a few ‘best indie game at show’ lists.
Crippling the AI fort by taking out their big weapon proved to be counter productive. It meant the player could be coached without the threat of being wiped out instantly, but when left alone the player would just continue indefinitely, preventing others from trying. I had to reintroduce the cannon to one of the maps to give the battle a timely end.
By Sunday we had our pitch and coaching routines down pat. People seemed to learn it faster and have more fun. The AI was still making it difficult. More effort will have to go into making a good show map and configure the AI to give players a chance to learn without leaving it open ended. We were enjoying ourselves, and some people were coming back two or three times. A few were turning up saying a friend had recommended they check out our game. It felt great to hear that.
After a hectic weekend I got about half an hour to wander around and play a few of the other indie games in the PAX Rising area. I wish I had more time to do this; it was good to meet other developers and talk about their pride and joy, the issues they were facing, and try some cool games. The amount of support (moral and practical) shown between indie devs was wonderful, and I think everyone partly wished the event would never end for this, and other reasons. It’s definitely huge for a developer to have a face-to-face conversation with someone who instantly gets their game and wants to know more about it. Same goes for talking with other devs, and some of the conversations can be extremely useful. We received a few hot tips which may make a big difference.
It was such an awesome event. We’re grateful to the organisers, the attendees who gave our game a go, the other devs who gave us support and words of encouragement, and the press who have written, streamed or podcasted about the game. We’re happy that the game was solid and fun for you. Thanks for being patient with the difficulty – we’re working on it. Thanks also to Anna for making us (and Nart) healthy lunches and snacks every day.
I hope we see you at the next big show!
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.
Nick is interviewed by J.A. Laraque from Obsolete Gamer, starting at 1:27.
Networking, compression, font rendering, image processing, scripting and audio are implemented with third party libraries, but much of this project is built from the ground up. Not necessarily for a good reason – it started simple and functionality was added when needed. The project has been going so long and substantial time invested in a decent system that wiping it clean and using a third partly library would cost more that it’s worth. The user interface is a good example.
It could be more powerful and better designed, but it’s good enough and better than some used for commercial projects. I have built a screen editor (see image below) that allows creation, reordering, deletion, moving, resizing, customisation, and copying and pasting of controls. There is support for a range of control types including text, text button, check boxes, edit boxes, panels, textured buttons, list boxes and tabbed panels. Unfortunately the screen editor was started in MFC way back when and I still have to deal with its difficulties.
The panels automatically detect if there are corners and tiled edges available and break up the panel into child controls to use them. This allows me to easily make panels with rounded corners or frames of any size.
I’ve just implemented a style system, so each control’s parameters can default to a particular style. If you decide all the controls with the ‘Heading’ style should be a bit larger and have a shadow then it’s a matter of changing a couple of lines in the style script, rather than going through and editing every screen. Screens are serialised as Lua scripts, so if a parameter is not found the style’s value is used instead. This means you can customise controls, while keeping down the file size. When a style is changed it is automatically reflected during the next execution of the screen editor or game.
The controls support layout variables too, so you could have a variable that defined the position of the title on each screen, making minor adjustments painless. There’s no animation support, but it doesn’t look like we’ll need it for Forts.
Adjustments to the coordinate mapping allowed support for correct display in different screen aspect ratios. We’ve targeted 16:9 as our primary user interface aspect ratio, which is the most commonly one used on Steam. Aspects of 16:10 just shows more of the background image above and below the controls, and 4:3 is letter boxed. You can see the guides for these in the screenshot.
I’m basically working full time on the game at the moment. I have another business that demands attention, but the momentum of the game keeps growing. There’s a tension between new features and stability that keeps me working at it. I’ll add a new feature or two, we test it and uncover some bugs, I fix enough of them to think the game is stable and add more features. In spite of all the debugging support I’ve added, some crashes have remained a complete mystery.
Recently my dev laptop started failing to reallocate memory. I was writing the entire game’s replay data into one buffer, and inevitably the amount of data outgrew the buffer; so it had to grow too. We are not talking about huge amounts of memory – 8 or 16MB allocations would fail. It was a little surprising give the 2 or so GB of virtual memory available.
There must be some fragmentation of the heap going on – quite likely since I dynamically allocate small amounts of memory for the very dynamic physics, projectile and effects system. My test machine with the same OS did not have the same trouble, but I figured I should bite the bullet and work out a better solution. After all, there’s no telling how long or complicated games will get when it’s out in the wild, and running on all sorts of low-end hardware.
So the new system accumulates replay data in a smallish buffer of 1MB, but a flush is triggered when there is more that 256KB written. The chunk is compressed and then appended to the physical file for the replay. If there’s a crash, desync, the player quits or goes into instant replay, whatever is in the buffer is also flushed. When a replay is viewed the entire list of chunks is read and decompressed into a single large buffer. This is needed because the user can seek to any point in the replay. It doesn’t seem to be a problem allocating big buffers once at the beginning – although perhaps I’ll have to work out a replay streaming system if it is for other people.
Even with this working, there was the possibility of the buffer running out because I had not yet serialised any projectiles. I put this off because I thought it was unnecessary work and didn’t seem to matter that much, but now I had a good reason to. If there was a continuous fire fight a flush could be put off for a long time. The replay key frames are important for desync recovery, so there must always be one in the current buffer. The other thing was, players can attempt to join any time, and they would have to wait until there were no projectiles to actually enter the game. If the host had paused while any projectiles were airborne the joining client would hang at the loading screen. Not good! So with a little extra work – perhaps a day – I managed to write and read the state of bullets, mortars and guided missiles to and from the key frames. It felt good to have that working, finally! Now the game can make perfectly regular key frames, the buffer use is much more predictable (although individual key frame sizes can vary), and players can truly join at any time.
I just discovered today that this new system of writing the replay to disk in chunks caused a problem with the way games are restarted. After the game configuration (map, users, AI configuration, etc.), the first thing the game records in the replay file is a snapshot (or key frame) of the game, which allows the source data to change without invalidating the replay. When the player restarts a game it would seek to the beginning of replay to reload that key frame and start again from there. But now with the buffer flushed that data wasn’t there, unless it was a very short game. So I had to read in the game configuration preamble and the first compressed chunk which contained that vital first key frame. Anything after that is discarded and the new game data is appended.
Another thing I did today was prevent the game rolling on indefinitely after a game had ended. This maybe not be a big issue for players, but I have been pitting two computer players against each other to test stability. Without a forced pause the replay could go on and on with nothing actually happening. Little things like this are tightening up the game, bit by bit. It feels like it’s coming together rapidly, but it’s actually taking a very long time.
Prefab engines such as Unity or Unreal help a lot of game developers reduce the total amount of work, but I really don’t think there is much in this game that is generic. The hardest problems I deal with feel very unique, such as synchronising target selection for missile launchers via snipers over any number of clients. Not being hamstrung by an existing framework may be an advantage is some cases.
Last night I had a bit of a crisis. I did a regular backup of the Subversion repository to DVD and Dropbox, but something happened to the original files during the process. The files looked sensible if you opened them, but Subversion was failing! Luckily the DVD backup was good and replacing the files with the backup sorted it out. Although there was no danger of losing work on the game, having a complete history of changes is extremely valuable.
It’s amazing how much work all this takes. I wonder how apparent that is to anyone playing the game.
The last couple of weeks have been focused on completing the AI. The biggest task was to make its rebuilding process more reliable. That is, when the AI fort is partially destroyed it must reconstruct the missing fort to the same blueprint. Previously it tried to build all the missing parts simultaneously. This sort of worked but because it paid no attention to build order pieces would fall off along the way and sometimes it would get stuck. It would also build struts and then not be able to afford the next one which kept it in place before it fell off.
I reworked this so that it keeps a list of which fort actions needed to be redone. Before making any new additions to the fort it checks this list and tries to build the earliest actions, and unchecks them as they are complete. If some actions are unable to be completed for some reasons then it skips over them temporarily and tries something further down the list. If it gets to the end of the list, even with some frustrated steps, it starts adding new structures again.
While in this process of rebuilding, the weapons system dials back the offensive in order to save resources. Each weapon type has a probability of being fired, so more expensive weapons are unlikely to be fired, but light weapons will fire frequently. It also avoids repairing lightly damaged struts. When rebuilding is complete the offensive and complete repair resumes.
When creating a new joint, the AI now saves up resources to build the bracing strut too. This prevents the AI losing struts while waiting for the resources to brace them. It would previously get stuck on this kind of problem.
Another issue is that the fort moves during gameplay as the structure is damaged or sways under its own weight; joints may not be where they were when the fort template was recorded. I’ve partially addressed this by making minor adjustments to new joint positions when the AI is told that a requested strut is too long or too short. I may have to move to relative joint placement, rather than absolute, but for now this is helping quite a bit. It may be useful to improvise some unscripted segments and attachments to span large gaps. From a programmer’s perspective this is fertile ground for experimentation – I’m having a lot of fun with this.
Each time a weapon opens doors to fire it has a chance of leaving the door open for the next shot. This means the next shot can happen a little bit sooner, but it leaves the weapon exposed in the meanwhile. This probability also varies by weapon type, so weapons slow to reload will generally close their doors.
I’ve divided up the weapons into light and heavy categories. Each category has a list targets in order of priority. Until now the AI would start at the top and work its way down. This ended up being too predictable and tedious, with some targets being attacked persistently. Now the AI calculates a random offset into this list based on a normal distribution. It starts from there and works its way down, meaning lower priority targets get some attention too. If it fails to find one then it starts one above the offset and works its way up. The result of this change is an apparently much more dynamic and unpredictable opponent.
Different weapons are able to penetrate a structure to different extents. The cannon can take out at least one layer of armor, the laser too. The armor piercing (AP) sniper doesn’t destroy the armor but it does damage weapons up to two layers of armor behind it. When the AI casts a ray to the target currently under inspection it passes a number of hit points to ‘spend’ on getting through the layers of structure. This allows the AI to focus on attacking devices that it has a chance of damaging. For heavy weapons, if it fails to find any such weaknesses it goes back over its list of priority targets and picks one without regard to direct structure penetration. Using this I can encourage weapons that won’t necessarily break through to try anyway. For example the mini-guns will attack doors of weapons hiding inside until they eventually break through.
To mimic the player’s grouping mechanism, I’ve added a weapon grouping affinity table. Each time the AI goes to fire a weapon it scans its other weapons. The weapon types have a certain affinity for being grouped with the lead weapon type; some groupings make more sense than others and these have a higher probability of being selected. The important grouping that I was aiming to achieve is the missile launcher with the swarming missiles: the swarm protects the missile in transit. It also works well for groups of similar weapons, such as mortars and mini-guns, or you might have the mini-gun soften up some armor before hitting it with a missile. If firing the group is unaffordable at the time then it doesn’t fire anything. In this way it chaotically saves up for firing expensive groups but also fires single weapons. Some weapons shouldn’t be fired alone very often, such as the missile launcher; it is expensive and vulnerable to total failure. There’s an additional probability for abandoning such actions.
AI forts are recorded for a specific team on one side or the other of the map, but often the maps are symmetrical. To leverage the work done recording forts on these maps I have allowed the fort to be mirrored. The AI will build an identical fort on the other side, just flipped about the midpoint of the map.
While this work has dramatically improved the quality of the AI, there are still some significant issues with it. For example, because it blindly follows the original build order, it can spend a lot of time waiting for resources when it would be smarter to connect to nearby mines that it has lost a connection to. There may be additional work that I can do to patch these holes, and I will have to write some guidelines for recording quality AI forts, but for now it feels like it is ready for being enjoyed by the public.
Below is a series of screenshots showing the AI taking cannon fire, suffering considerable losses to its structure, and then rebuilding the lost parts. It doesn’t have the requisite workshop and upgrade center to rebuild the mini-gun and mortar, but once rebuilding is complete as possible it starts using the grouped swarm and missile again.
You might have noticed big gaps in development if you looked at the older posts. In fact, this project has been going since 2003. At least that’s the earliest entry I have in my development journal. Work was pretty solid in my spare time until perhaps around 2007, when development took a break.
At this time I was working on online match making and connection. I had written a master server to advertise online games. This was more or less working, but I had trouble getting NAT punch through working. NAT stands for Network Address Translation, and it allows a local network to appear on the internet (the network of networks) with one IP address. This is great for security and reducing address use, but it makes connecting to a game server difficult.
RakNet is the networking library that I use to pass messages between instances of the game. This has a technology that allows the NAT to be circumvented, or ‘punched’. I tried to get this working, even with the help of RakNet’s author, but to no avail. I couldn’t get the game client to connect to the game server over the internet and it was very discouraging. I was turned off development for a long time until a slow period in my new career and I decided the game was worth resurrecting. The game’s concept is great and, as far as I know, still unique. It’s a good thing I’ve stuck with it, because it looks as though the problem has been resolved, at least for the majority of cases.
The solution I’ve just implemented uses Universal Plug and Play, or UPNP. This protocol allows devices behind the router (which runs the NAT software) to request a port to be opened to outside devices. Before this protocol and sans RakNet’s technology there was a lot of messing around with port opening to allow servers to be run at home. Now the game can request one be opened temporarily without intervention by the user.
I’ve updated to the latest version of RakNet, which has now been made open source by Oculus, the developers of the Rift virtual reality system. RakNet provides a free server to run its NAT punchthrough technology, and I have tried to connect to this, but it is so far failing. I continued anyway, and implemented the UPNP port opening and match making. The match making master server is also run by RakNet, but will eventually be supplanted by Steam’s system. With fingers crossed I tested it out. Yesterday Nick and I were able to connect to each others server over the internet! We’ve got online connection working!
A smaller but also very exciting feature has also been added which allows clients to join a game in progress. This was a big feature in the real time strategy game Stormrise that I worked on with The Creative Assembly (which later became Sega Studios Australia). When a client wants to join the game it first loads all of the assets, and then the host sends the current state of the game, using the same system created to store keyframes in the replay. The host immediately starts sending all game messages to the joining client so that it doesn’t diverge in state and cause an immediate desync. I’ve yet to test this in adverse conditions but it’s working perfectly on a local network.
This feature will allow for players to join a game after it has started to assist either team. New players don’t bring any additional resources with them, so it simply means there are more ‘hands on deck’ to control weapons and build and repair structures. Resilience of the game is improved too. If a network connection is interrupted or the program or PC crashes then the player can restart and join the game again. Finally, it means observers can join in to watch the game in progress – something useful for popular tournaments.
Now for something visual! One of the mechanics of the game is about controlling ground. When you build a new foundation it expands your area of control, and therefore the space you can potentially build new ground devices. These currently include the mine which gathers metal ore, the swarming missile and its upgrade. The area you can actually build on has been rather opaque until now, depending on discovery using the colour of the preview device. I’ve now started drawing a pulsing glow on the ground where the player is able to build (screenshot below).
So work continues. Nick’s working on the trailer video and providing small pieces of art work. My focus shifts depending on need. A desync appeared in a game against Brian recently – the first in a while. These are always high priority, just behind crashes. It took quite a bit of digging and the careful construction of a scenario to reproduce the bug to figure out what was happening. Yet again it was caused by the system I added to hide network latency when building structures. I’m seriously thinking about overhauling it to reduce the instances of these kinds of problems, but that will take considerable work and destabilise the code for a period too.
Usability is probably the next priority. The game is deceptively complex. I consider it to be a real-time level editor, with projectiles. Not only does it need to be powerful, it needs to be intuitive and tell you what happened if you did something wrong. The standard is higher than typical in-house development tools because the player will get frustrated more easily and doesn’t have someone nearby to tell him how to use it. I’ve added some new cursors to give contextual feedback, such as showing a door icon when the selected weapon is blocked by a door. The aiming arc is also coloured according to which angles are clear to shoot, which are blocked by doors, and which are blocked by solid structures (see image below).
Structures can now be built with a drag motion as well as point clicking, and dragging over an existing structure will replace the material with the current selection. This reduces the amount of accidental material changes and allows for the preferred building systems of different people which we observed during GameOn.
A major bug with the sound has been fixed. The problem was Fmod keeps channels reserved even after they finish playing, and the game didn’t un-reserve them. The game would eventually run out of channels to allocate, preventing new sounds from playing and spamming an error message to the console.
Optimisation is usually pretty far down the list, after various bug fixes and new features, but with Nick building some big forts (image below) for the trailer I’ve had to address some performance issues. In the process I made an observation that led to reducing load times from about 14 seconds to 1 second. I wish I had found that a year ago!