Release date inside!
Getting through Steam
As I mentioned in the last blog, we submitted our game to steam to get an early approval so we can release without a last second rush.This initial attempt was rejected for a number of reasons, primarily because our Linux build did not run on SteamOS.
This has turned out to be quite a problem for us because SteamOS uses some very old software, where we are running Manajro, which is bleeding edge software (more bleeding than not!).
In short, we need to build Trains & Things using old libraries (that software which our game depends on) but using bleeding edge tools (that software which which builds our game).
As you might imagine, it is potentially quite a problem as that fancy new tools might depend on some other fancy software which is in direct conflict with that old software we need to build our game against!
My first attempt at getting a build machine up and running, which took about 2 days, was Ubuntu 14 LTS. On this machine (virtual machine in my case) we can successfully build Trains & Things for SteamOS, but the fancy new build tools that we need to build a Windows executable I can't get working.
Enter the solution: Docker! What is Docker you ask? It is like a virtual machine, but more like a virtual operating system. So I can setup a docker or virtual operating system that has the old libraries I need and build the Linux executable (which doesn't need all the bleeding edge tools). Then for building Windows executables, I can just use my standard build procedure which needs the bleeding edge tools (the ones that I couldn't get working in the virtual machine).
It sounds simple, but it took a good 4 days to get it setup and working.
Game Settings & Lobby syncing
I've also managed to add in the last critical feature required before we ship: game settings. This allows you to configure the game to play it more how you like. It is basically game play style and difficulty settings such as how much cash you start with, how much interest the bank charges etc...We supply some pre-configured settings here to help you, then you can drill down into the details and make tweaks.
This will be especially helpful during early development as the maps are not particularly balanced yet, so will also provide a mechanism for you to work around that fact.
As a side effect of this, I have also implemented Lobby syncing. So when the server changes some settings the clients can see it. Nice!
Task tracking
One thing all software has isHaving a bit of a play, it looks to be a lightweight JIRA! Quite impressive!
So this is now publicly available for every one to see:
This will also provide some good transparency as we head into the Early Access period so you can see where we are at, what is coming up etc...
So we no longer display the build git commit number as this is kinda of pointless seeing as the above information gives you all the information you need.
Also with the switch to Godot Vulkan branch which has caused a few major graphics regressions (see next section for more info), I've decided to implement a Changelog which is, for now always the first thing you will see when the game loads.
The Changelog provides a list of bug fixes, feature additions from the prior version. It can include a summary message and a section fo known issues/workarounds.
We were expecting this to occur much sooner, but we took a risk and it might have been a mistake! Yet our initial reason for switching still holds: We want to release on Vulkan so not to allow for the situation where a user buys our game which runs fine under OpenGL, only for us to switch to Vulkan at a later stage and then mean the user might not be able to run our game if their PC is a bit of a potato!
To help alleviate some of the damage of switching to a very unstable, not-even-alpha version of Godot, we are introducing a Changelog when the game loads where we can display special messages to you for each version with some warnings, tips, and work arounds if needed as I mentioned above.
Versioning tweaks & Changelog
In a previous blog post, I talked about versioning. After some use of this system, I've tried to simplify things. We now have a version name which is a name that characterises the release we are doing. The first release will be called "Early Adventurer" to indicate it is for the early explorer, the brave at heart! This will then have a version number of v0.1 bXXXX where XXXX is the build number.So we no longer display the build git commit number as this is kinda of pointless seeing as the above information gives you all the information you need.
Also with the switch to Godot Vulkan branch which has caused a few major graphics regressions (see next section for more info), I've decided to implement a Changelog which is, for now always the first thing you will see when the game loads.
The Changelog provides a list of bug fixes, feature additions from the prior version. It can include a summary message and a section fo known issues/workarounds.
We shot ourselves in the foot
As we roll into January 2020, the full implications of transfering over to the Godot Vulkan branch are becoming apparent. Basically we have to work around bugs and our graphics have regressed. While I have pushed some engine fixes back to Godot, we just have to wait for the Vulkan code to become stable, which at this stage is looking to occur around mid 2020 *gasp*.We were expecting this to occur much sooner, but we took a risk and it might have been a mistake! Yet our initial reason for switching still holds: We want to release on Vulkan so not to allow for the situation where a user buys our game which runs fine under OpenGL, only for us to switch to Vulkan at a later stage and then mean the user might not be able to run our game if their PC is a bit of a potato!
To help alleviate some of the damage of switching to a very unstable, not-even-alpha version of Godot, we are introducing a Changelog when the game loads where we can display special messages to you for each version with some warnings, tips, and work arounds if needed as I mentioned above.
Trailer
So I have been chipping away at getting a template for the trailer done. This involves getting the game assets, text, music, beauty renders and putting together the trailer with everything excluding the in game footage.
Its been a tough choice deciding between using Blender VSE or Kdenlive for this. Ultimately we decided that we prefer ease of use over power or features so that we can quickly put together more trailers for the game. So the final decision was to use Kdenlive.
The early access trailer is almost fleshed out. The music has been cut to length, the text transition and the intro/outro splash have been added. Here's a quick screenshot of the project as it is now. The brief for the trailer was simply "Make it AWESOME!".... The trailer will be released in the coming weeks.
Its been a tough choice deciding between using Blender VSE or Kdenlive for this. Ultimately we decided that we prefer ease of use over power or features so that we can quickly put together more trailers for the game. So the final decision was to use Kdenlive.
The early access trailer is almost fleshed out. The music has been cut to length, the text transition and the intro/outro splash have been added. Here's a quick screenshot of the project as it is now. The brief for the trailer was simply "Make it AWESOME!".... The trailer will be released in the coming weeks.
Release date
Saving the best bit for last! As of today (03/01/2020), we have been approved by Steam for release! Our release date has been marked down as 24th January 2020!
The bitshift team
