Latest stable version: Checking...
Registry status:

    Greetings Citizens,


    It's been just over two weeks since we last posted news, so it's well due for a dev blog! By now most of you will have discovered that the last release we did caused some serious issues with stations and saving block changes.


    As a player, these severe issues can spoil your mood to play the game and in some cases also result in you losing in-game progress.


    As a game development team, we’re aware issues like these lose our players trust and support. Additionally, having to do several hotfixes also eats away time in every new release cycle.


    The release cycle, as it stands, is scheduled for a release every two weeks. Sometimes we extend major releases (such as NPC factions) to go through multiple release cycles. However, we try to stick to the two-week schedule as best we can. During this cycle, we have to plan, develop and test every release. We've found that it's hard to put a meaningful amount of content into a release in only two weeks, especially since we can't add anything new during the testing phase (currently 2-3 days) before release. What tends to happen is that after a release is sent out at the two-week mark, hotfixes are needed, we then lose even more time for the next release cycle.


    Adding more testers to our testing phase wouldn’t help in the sense that a tester’s job is to mainly maintain Phabricator and to report any dev issues along the way. It’s a never ending task and finding volunteers that will do this for a long period has so far been difficult.


    We've come to the conclusion that the current two-week release schedule is unfeasible for a team of our size. It's inefficient, unmanageable and it's not beneficial for our players or us. For these reasons, we've decided to work on a new release cycle, to eliminate/reduce severe issues in new releases and allow us to get more work done.


    New release cycle

    The changes we want to do here is to extend our release cycle to “as long as we need” with Dev Blogs to keep everyone up to date with what we’re working on throughout the release cycle.This gives us more time to do some long-term tests without feeling the need to rush a release out and then having to hotfix afterwards. This approach also lets us monitor any performance issues that pop-up and resolve them before a live release.


    Although this should already be more manageable for testing, we would like to minimise the risk of any issue going unnoticed during pre-release testing. Therefore, when we think it’s ready to go, we will inform you about all the dev build changes in a news post but not do a live release. That would be our release candidate which will be used for public testing. You can check those changes out on our test server and help us out by reporting any issue you find. We even have a few servers that want to run this release candidate on a backup of their entire server database to give us even more coverage. Having the community involved in the process before the release goes live will ensure we catch as many issues as we can, avoiding the need for as many hotfixes after it goes live.


    If you encounter any new issues, please report them here, and we’ll make sure to prioritise them correctly to fix any annoying or severe issues before live release. We’re planning to do these release candidates on a Friday if possible, and we estimate it will take roughly a full week before it can be uploaded to the release branch.


    This will allow us to get a lot more work done, as the two-week release cycle was holding us back quite considerably, often reducing features to minor gameplay and decorative updates while we didn’t make as much progress with bigger features as we would have liked. The most popular updates like the rail update did have long release cycles, so we already know that it pays off.


    We’ve written our different phases out here although they’re still subject to change. A lot depends on how well our next release will go when following these rules.


    Bug spring cleaning

    The two-week cycle also left bug-fixing in a poor state as we were always forced to fix bugs affecting the new features, and then hotfixing, neglecting other bugs that continued to get pushed back more and more. In light of this, our first usage of the longer release cycle will be the quest to fix all bugs that have a priority above “normal”. This is long overdue. We have also decided that when we release, the release should have fewer bugs than the last release. Not only will this make the game a lot better over time, but it will also free up resources for our testers, as fewer bugs will have to be processed.


    We understand that it was a bit frustrating for new testers to see their bug report(s) in queue waiting to be fixed for so long. This is also something we want to resolve through this process.


    Power update

    With regards to the power update proposal we shared with the community. We have worked on ironing out the flaws in our concept and were hoping to have been able to present our revision a week ago. However, we’re still not quite ready to share our revised proposal just yet. Some of you mentioned it was hard to judge a system with a lack of details which is why we’ve been working on it for a while now. As we expected it’s not easy to find a complex system where every block has a purpose and affects different portions of your reactor.  We’ve toyed around with several ideas such as heat management and reactor shapes, but the hardest part is finding a good base and sticking with it. For now, watch this space.


    Current changes

    Our primary focus these past few weeks has been on bug fixing, addressing all of the higher priority bug tasks that were still in queue. Fifty of them have been addressed so far, although testing is still required to make sure they’re resolved. With bug fixing also comes some small features, such as the ability to toggle cloak/radar jammers on fleets. We’ve also been looking out for those annoying issues that aren’t necessarily a high priority but can still sour gameplay experience after encountering it too many times.  For example, rolling a ship has always resulted in odd behaviour, and we’re very close to fixing it right now.


    Our next release will require some extensive play testing; we’re sure our community will be willing to help us out :)


    As always, thanks for playing StarMade

    ~ The Schine Team