Dev Diary #299 Navigating the Ylands Release Seas
Ahoy Ylanders!
In this dev diary, we will take a deeper dive into our programming and patch/update release workflows and we'll get a bit more technical, as our programming department shares the ins and outs of the job!
Since we just released the Winter Fest patch and Update 2.2 is on its way, it is a good time to peek behind the scenes at what it even takes for a new release of Ylands to get to you, our dear player!
Each new release contains a multitude of new features requiring new code and data. We toil on them daily, saving (or committing, as the proper lingo would go) our changes to a 'version control system' (VCS). A VCS helps us keep track of project history and lets us recover an old state on the off chance we ever mess up. Importantly, it also allows us to work on multiple versions of the project (called branches) at the same time, with work on one usually not disturbing the others. Daily changes are committed mostly to the trunk version (branch). On a busy day, there can be over a hundred changes made to the trunk.
One part of a programmer's job, on which we spend a great deal of time, is dealing with bugs. A bug is a term used for any issue with the game, whether it comes from bad code or bad data. The development of a long-term project like Ylands is fundamentally about adding or improving new features as well and as fast as possible while minimizing the number of new bugs we accidentally add.
The first line of defense against the insectoid menace is something called 'continuous integration' (CI). CI is a term for a system that automatically integrates and tests changes made to a project. It is important to say that 'integrates and tests' actually means specific things for specific projects. For Ylands it goes like this: several times a day, about every hour or so, a new build of the game is made with the new changes made since the last build (from only a couple to low tens of new changes per build). Before each build, we run set validation procedures that help us automatically check any rules that we can enforce without the need for human oversight. If validation passes, we build a new version of the game. A successful build continues to automated testing, where our in-house automated system simulates player input to run the game through a range of predefined gameplay scenarios to detect any regressions (a feature that worked but does not work anymore after a recent change). Recently, we also introduced multiplayer testing against dedicated servers.
CI, in our case automated building and testing, usually uncovers the most obvious regressions in existing systems. For anything more complex, we rely on our QA team, who know the game inside out. They test new features, to ensure they are the best they can be and also continuously check that our meddling did not break any of the existing stuff.
This process of daily development and CI continues merrily until the release of a new version draws near. We set a date of a 'datalock', usually about a month before release. A datalock comes when all new features should be good and done in the trunk branch and no new changes should really be required, besides the occasional bugfix. In theory at least. On the day of datalock, we copy the trunk version into a new 'release candidate version branch' (RC), so that it is not further disturbed by daily changes. We then proceed to test RC builds rigorously. The RC branch receives only as few changes as possible to avoid introducing any more last-minute issues.
In some cases, the RC build is made public as the Experimental Steam beta branch about two weeks before a release. We closely monitor player feedback and react to any critical issues that might be found. What is super exciting, is that starting with the 2.2 Experimental, it should be even more useful for us, as it will let players continue with their existing progress from the live version of the game (but not carry over experimental progress to live).
Finally, once the day of release is set in stone, we announce a maintenance window. On the day of the release, we flip the button, push the final build of the game live, and do a last round of checks to make sure that everything works. We celebrate, take a breather, and start the whole cycle anew.
And there you have it, Ylanders - the release cycle summarized from the point of view of our programmers.
Is there any topic from the development of Ylands that you would like to hear about? Let us know here or come chat with us on our Discord!
Stay Classy, Ylanders!
In this dev diary, we will take a deeper dive into our programming and patch/update release workflows and we'll get a bit more technical, as our programming department shares the ins and outs of the job!
Since we just released the Winter Fest patch and Update 2.2 is on its way, it is a good time to peek behind the scenes at what it even takes for a new release of Ylands to get to you, our dear player!
Each new release contains a multitude of new features requiring new code and data. We toil on them daily, saving (or committing, as the proper lingo would go) our changes to a 'version control system' (VCS). A VCS helps us keep track of project history and lets us recover an old state on the off chance we ever mess up. Importantly, it also allows us to work on multiple versions of the project (called branches) at the same time, with work on one usually not disturbing the others. Daily changes are committed mostly to the trunk version (branch). On a busy day, there can be over a hundred changes made to the trunk.
One part of a programmer's job, on which we spend a great deal of time, is dealing with bugs. A bug is a term used for any issue with the game, whether it comes from bad code or bad data. The development of a long-term project like Ylands is fundamentally about adding or improving new features as well and as fast as possible while minimizing the number of new bugs we accidentally add.
The first line of defense against the insectoid menace is something called 'continuous integration' (CI). CI is a term for a system that automatically integrates and tests changes made to a project. It is important to say that 'integrates and tests' actually means specific things for specific projects. For Ylands it goes like this: several times a day, about every hour or so, a new build of the game is made with the new changes made since the last build (from only a couple to low tens of new changes per build). Before each build, we run set validation procedures that help us automatically check any rules that we can enforce without the need for human oversight. If validation passes, we build a new version of the game. A successful build continues to automated testing, where our in-house automated system simulates player input to run the game through a range of predefined gameplay scenarios to detect any regressions (a feature that worked but does not work anymore after a recent change). Recently, we also introduced multiplayer testing against dedicated servers.
CI, in our case automated building and testing, usually uncovers the most obvious regressions in existing systems. For anything more complex, we rely on our QA team, who know the game inside out. They test new features, to ensure they are the best they can be and also continuously check that our meddling did not break any of the existing stuff.
This process of daily development and CI continues merrily until the release of a new version draws near. We set a date of a 'datalock', usually about a month before release. A datalock comes when all new features should be good and done in the trunk branch and no new changes should really be required, besides the occasional bugfix. In theory at least. On the day of datalock, we copy the trunk version into a new 'release candidate version branch' (RC), so that it is not further disturbed by daily changes. We then proceed to test RC builds rigorously. The RC branch receives only as few changes as possible to avoid introducing any more last-minute issues.
In some cases, the RC build is made public as the Experimental Steam beta branch about two weeks before a release. We closely monitor player feedback and react to any critical issues that might be found. What is super exciting, is that starting with the 2.2 Experimental, it should be even more useful for us, as it will let players continue with their existing progress from the live version of the game (but not carry over experimental progress to live).
Finally, once the day of release is set in stone, we announce a maintenance window. On the day of the release, we flip the button, push the final build of the game live, and do a last round of checks to make sure that everything works. We celebrate, take a breather, and start the whole cycle anew.
And there you have it, Ylanders - the release cycle summarized from the point of view of our programmers.
Is there any topic from the development of Ylands that you would like to hear about? Let us know here or come chat with us on our Discord!
Stay Classy, Ylanders!
