Sep 6, 2023
Techtonica - lauren
Now that our v0.1.1 Update has been launched into the void of your computers, let's talk about what’s next: v0.1.2!
We’ve updated the Roadmap with a few items that we’re ready to confirm. Well, as ready as possible. The Roadmap, remember, is a living document that can and will change over time. In this week’s update, we’ll deep dive into production planning with our producer, Lexi, and explain what our current timeline looks like.
This week's video deep dives production with thoughts from our producer, Lexi, if you prefer video format!
To plan production timelines and updates, there are several factors that must be balanced, both external and internal.
Tada! We’re really excited to (tentatively) confirm that these items (and more) will be in v0.1.2. We will have more details on the current roadmap items in the coming weeks, but for now, this is what we’ve got planned!
Oh yeah, it’s time. Fixing the HVC and Monorail bug has been high on our list for a while now, but community sentiment really pushed it to the top. Rob already detailed our process for choosing what is important in a previous blog post about this bug if you’d like to deep dive it, but the TL;DR is that it bothered everyone a lot so we decided to fix it faster.
Previously, fixing the monorail and HVC bug was slated for v0.2, but after reading all the feedback you have given us, we’ve decided to take a shot at getting it ready for v0.1.2.
Here’s the thing: We’re not putting this on the roadmap just yet. We’re not sure that we’ll be able to fix it quickly enough. We will decide in early October if it will be fixed by 0.1.2, so keep your eyes peeled then!
First, how often do players need updates so they keep playing and don’t fall off? This is a guessing game until you get data. Techtonica has not been around long enough–we’re only on our first patch!–and we have a small team, so we’re doing a bunch of guessing. We are using community cues to see if players are bored and need smaller, more frequent updates. Right now, we are listening to the community a lot to see how they feel and making guesses for the first few updates as to what our cadence should be.
We also take into account Steam sales that will increase our visibility. While we can’t always launch an update before a sale, it’s a good practice to try and time them together to capitalize on the increased visibility.
The big one is the content; what are we trying to put into the patch/update?
We also need to factor in team velocity–how long it takes the team to build and finalize features and bug fixes. There’s a lot that factors into team velocity.
Leads in charge of teams do planning and support for their teams, but also do work for the game. That affects the velocity of those team members, depending on the extent of their responsibilities.
When you calculate your team velocity, you have to add buffer to every timeline. You can’t say, “This is how long it is going to take us,” as there is no certainty in game development (or life, in general). You need to add more buffer the more complex an issue is. For example, the monorail and HVC bugs are super complex, so more buffer has been added to fixing those.
For small things, such as adjusting localization or adding a toggle or setting, those items are more well understood so you need less buffer. Lexi’s basic rule is to add 20% of buffer to a timeline for planning. For quick fixes that have a high level of complexity (for example, “Hey this should take me only a few hours but I don't know how to do it”), Lexi rounds up to a full day. This ensures that we aren’t constantly pushing back patches or updates, because we’ve planned for uncertainty.
QA testing timelines are another internal factor, which we deep-dived with Rob, so I’m not gonna explain it again here.
And finally, team members are humans. They have vacations, days off, holidays, and need to onboard new team members. This has to be taken into consideration when planning as well.
Our team is currently working on features and fixes for the end of October, but Lexi’s goal is to be working several months in advance. This allows more time to make sure everything works and to make sure it’s fun, it works really smoothly, and we have the time to put it through all of Rob’s QA cycles.
When we design a feature, we want to talk it over with all of the disciplines involved to make sure there are no hidden obstacles–such as a coding issue or a required workaround needed–so we won’t have a feature blocking implementation. We want to make sure an idea is really sound before we start working on it. After we have a prototype, we want to use it internally and play it to see if it’s fun.
For example, with base building, we want to build bases internally and make sure we have fun playing and iterate on that! We’re taking input from the entire team, artists, designers, tech and even marketing. We encourage interdisciplinary feedback to get eyes from all angles, which takes longer to generate, but it makes it fun holistically.
Once we’ve validated feedback across the team, we need to actually build the stuff. We are currently ramping up the team for base building, but we have a small team and things take time. Unless someone wants to buy us a time machine, which, hey, we’ll take it.
v0.1.2 is slated to release at the end of October or early November.
There are no major sales around those times, but we did, however, want to release somewhere between our planned v0.2 release and our v0.1.1 release. That time falls roughly in the month of October. We also have our company summit planned for October, which is our big internal factor in pushing to the end of the month. We want this to fall after the summit so we aren’t trying to fix bugs or help the community right before we leave. This allows more time for QA testing, more time for extra eyes, and release when we return!
Over the weeks between now and v0.1.2, we’ll pull the curtain back on what we’ll have ready for the second Quality of Life update for Techtonica, so stay tuned.
Have questions? Want to chat with us directly? Join the Discord at https://discord.gg/techtonica.
Until then, Groundbreaker, let’s get to work.
We’ve updated the Roadmap with a few items that we’re ready to confirm. Well, as ready as possible. The Roadmap, remember, is a living document that can and will change over time. In this week’s update, we’ll deep dive into production planning with our producer, Lexi, and explain what our current timeline looks like.
This week's video deep dives production with thoughts from our producer, Lexi, if you prefer video format!
So, how do we choose what’s in an update?
Our producer, Lexi, is the timeline overlord and in charge of planning for our entire team. Below are her thoughts on production planning (summarized and commentated by me, Lauren) and how we plan for Techtonica’s updates.To plan production timelines and updates, there are several factors that must be balanced, both external and internal.
Before we get into that, The Roadmap
Tada! We’re really excited to (tentatively) confirm that these items (and more) will be in v0.1.2. We will have more details on the current roadmap items in the coming weeks, but for now, this is what we’ve got planned!
We're working on a fix for the HVC / Monorail bug
Oh yeah, it’s time. Fixing the HVC and Monorail bug has been high on our list for a while now, but community sentiment really pushed it to the top. Rob already detailed our process for choosing what is important in a previous blog post about this bug if you’d like to deep dive it, but the TL;DR is that it bothered everyone a lot so we decided to fix it faster.
Previously, fixing the monorail and HVC bug was slated for v0.2, but after reading all the feedback you have given us, we’ve decided to take a shot at getting it ready for v0.1.2.
Here’s the thing: We’re not putting this on the roadmap just yet. We’re not sure that we’ll be able to fix it quickly enough. We will decide in early October if it will be fixed by 0.1.2, so keep your eyes peeled then!
What are the external factors?
First, how often do players need updates so they keep playing and don’t fall off? This is a guessing game until you get data. Techtonica has not been around long enough–we’re only on our first patch!–and we have a small team, so we’re doing a bunch of guessing. We are using community cues to see if players are bored and need smaller, more frequent updates. Right now, we are listening to the community a lot to see how they feel and making guesses for the first few updates as to what our cadence should be.
We also take into account Steam sales that will increase our visibility. While we can’t always launch an update before a sale, it’s a good practice to try and time them together to capitalize on the increased visibility.
How about internal?
The big one is the content; what are we trying to put into the patch/update?
We also need to factor in team velocity–how long it takes the team to build and finalize features and bug fixes. There’s a lot that factors into team velocity.
Leads in charge of teams do planning and support for their teams, but also do work for the game. That affects the velocity of those team members, depending on the extent of their responsibilities.
When you calculate your team velocity, you have to add buffer to every timeline. You can’t say, “This is how long it is going to take us,” as there is no certainty in game development (or life, in general). You need to add more buffer the more complex an issue is. For example, the monorail and HVC bugs are super complex, so more buffer has been added to fixing those.
For small things, such as adjusting localization or adding a toggle or setting, those items are more well understood so you need less buffer. Lexi’s basic rule is to add 20% of buffer to a timeline for planning. For quick fixes that have a high level of complexity (for example, “Hey this should take me only a few hours but I don't know how to do it”), Lexi rounds up to a full day. This ensures that we aren’t constantly pushing back patches or updates, because we’ve planned for uncertainty.
QA testing timelines are another internal factor, which we deep-dived with Rob, so I’m not gonna explain it again here.
And finally, team members are humans. They have vacations, days off, holidays, and need to onboard new team members. This has to be taken into consideration when planning as well.
How far in advance do we start working on new content?
Our team is currently working on features and fixes for the end of October, but Lexi’s goal is to be working several months in advance. This allows more time to make sure everything works and to make sure it’s fun, it works really smoothly, and we have the time to put it through all of Rob’s QA cycles.
When we design a feature, we want to talk it over with all of the disciplines involved to make sure there are no hidden obstacles–such as a coding issue or a required workaround needed–so we won’t have a feature blocking implementation. We want to make sure an idea is really sound before we start working on it. After we have a prototype, we want to use it internally and play it to see if it’s fun.
For example, with base building, we want to build bases internally and make sure we have fun playing and iterate on that! We’re taking input from the entire team, artists, designers, tech and even marketing. We encourage interdisciplinary feedback to get eyes from all angles, which takes longer to generate, but it makes it fun holistically.
Once we’ve validated feedback across the team, we need to actually build the stuff. We are currently ramping up the team for base building, but we have a small team and things take time. Unless someone wants to buy us a time machine, which, hey, we’ll take it.
So, the important part, when will v0.1.2 release?
v0.1.2 is slated to release at the end of October or early November.
There are no major sales around those times, but we did, however, want to release somewhere between our planned v0.2 release and our v0.1.1 release. That time falls roughly in the month of October. We also have our company summit planned for October, which is our big internal factor in pushing to the end of the month. We want this to fall after the summit so we aren’t trying to fix bugs or help the community right before we leave. This allows more time for QA testing, more time for extra eyes, and release when we return!
Over the weeks between now and v0.1.2, we’ll pull the curtain back on what we’ll have ready for the second Quality of Life update for Techtonica, so stay tuned.
Have questions? Want to chat with us directly? Join the Discord at https://discord.gg/techtonica.
Until then, Groundbreaker, let’s get to work.
Share: 
