Back On Track
In our last blog we said:
We have decided to halt development until Godot 3.1 is released, as there are two critical issues we require that [we] are expecting: LOD, and Multiplayer Timeout settings.We expected Godot 3.1 to include fixes for both of these issues, however they have been pushed back to Godot 4.0 which probably won't be out this year.
Now that we have had a break I want to get Trains & Things into some sort of ship-able product. It is 80% done so why not put in some effort and get it out there?
Finally, in talking with the team, we have decided to get back on the tracks and work around the missing Godot features, and we have put together a little list of the things we want to do before we consider shipping:
1) Performance improvements
2) Polish up a set of maps
3) Deal with some pain points
4) PR/Marketing/Social
It sounds so simple! In fact the biggest problem we are facing is a lack of time - which a successful Kickstarter would have provided. Instead all we can do it work on T&T in our spare time.
Today I want to look at what we are doing to address the first point:
Performance Improvements
We've started with performance improvements as when the frame rate gets too low, multiplayer games can de-sync due to the packets not getting between server and client in time. Typically this is a problem mid game when the frame rate drops far too low to be enjoyable. And a low frame rate is not fun.I implemented a LOD system that works surprisingly well. This will help keep the frame rate up, especially as you zoom out. This has been implemented for tracks, trains and some particle systems. It still needs to be rolled out for a number of systems such as the terrain, train carriages and map props.
Now to Mesh Instancing. Here are two screen shots, the first is without mesh instancing and the second is with mesh instancing:
Secondly, the frame rate, it goes from 11 to 70! I'm rendering 4000 trees here on the Tutorial map. That is a nice improvement, but that this is not real world conditions. It's a debug build, then there aren't that many trees on a real map, plus the trees on maps are likely to be broken into small patches. All these factors mean the performance gain will not be as significant, but it still will make a difference.
The final improvement I want to talk about is the track mesh generation. So far, this has all occurred on the main thread. The client or server received a curve placed down by the player and then takes a mesh and tessellates it and deforms it to fit the curve and the terrain. This has resulted in a micro stutter when you build tracks or they are received from remote players in a multiplayer game.
To resolve this I've implemented a nice threading system which makes pushing tasks into threads a breeze, and so this track mesh generation is now threaded. This should ensure less frame drops and hence less multiplayer de-syncing.
That's it for this time!
http://www.bitshift.io/trains-and-things/
