1. Techtonica
  2. News

Techtonica News

Techtonica & Desynced bundle now available

We have a bundle to announce!

For those who don’t know, we brought Techtonica to Tokyo Game Show this year. We were hanging out at the booth, showing the game to fans, when the Desynced devs introduced themselves. Within a few minutes of chatting, we decided we wanted to partner up for a bundle.

So, you can now grab Desynced and Techtonica together on Steam at 12% off.

https://store.steampowered.com/bundle/35493/Techtonica__Desynced/

This is a Complete The Set bundle, and that means you’ll still get the discount if you buy the game you don’t already own through the bundle.

Ready to get to work?

Save Slots are coming to Techtonica with the next update

Hey, Groundbreakers! We’re back with another weekly update for Techtonica.

Today, we’re showing off the new Save Slot feature that’s coming with v0.1.2. This update, in case you don’t know, is the second of two planned Quality of Life updates. We added these updates to our in-flux roadmap right after we launched as a response to our community’s feedback and requests.

Save Slots were a hotly requested addition, and they are officially coming very soon. When? v0.1.2 remains slated for a late October or early November release, so this stuff is only weeks away.

https://www.youtube.com/watch?v=7ZF3n37LJT4

How do Save Slots work? Let’s dig in.

[h3]About the old, current save system[/h3]

Before we get into how the new system works, let’s briefly touch on the current (soon-to-be old) save system.

There are no slots. It’s a pile of saves with, at first blush, hard-to-read names and time stamps. Yes, you have a pile of your saves organized from newest to oldest. You can, technically, access everything in this pile. The process, though, is really difficult.



The dev team didn’t like this one either, for what it’s worth! We often juggle lots of saves as we test and implement new stuff in-game. On the marketing side, we absolutely have unique saves with purpose-built layouts for screenshots, trailers, whatever. Our current save system makes it super, super tough to juggle this stuff.

[h3]Here is the new save system, featuring Save Slots[/h3]

Instead of a pile of saves arranged from newest to oldest, the improved save system that’s coming with v0.1.2 features Save Slots.

Save Slots are started every time you create a new game. Think of each slot as its own world or instance in Techtonica. Every auto-save or manual save that occurs in that world or instance will stick to that single slot. We’ve also made some adjustments to how we store autosaves, keeping some older ones around longer so players can go back an hour or two in addition to the recent ones done every couple of minutes.

Oh, and your old saves will automatically merge into this system, too, with their own instance-based slots.



The Save Slots are sorted by the most recently accessed and saved, too. So, if you have an old slot that you re-visit, that’ll appear at the top of your list next time you go to load a game rather than sit buried at the base of the growing list.

[h3]What about naming saves?[/h3]

It’s the obvious question, right? Players want to be able to name saves. It’s on our list, but it’s something we’re saving until we’re ready to overhaul the UX/UI for Techtonica.

It’s not as simple as adding a text field. We need to account for controller support on Steam and Xbox, and that’s not as quick and easy as this Save Slot upgrade was. It’s coming! But not yet.

[h3]More v0.1.2 detail added to the roadmap[/h3]

If you check our store page, you’ll see that we’ve updated the roadmap to include some more clarity about some of the changes bound for the second Quality of Life update. Here’s a shot of that section in particular.



You’ll notice that we’ve included the mass gathering for plants that Lauren details list week, along with more bug fixes and news of thousands of new ore vein voxels. We’ll get into that information when we drop the full patch preview.

[h3]Heads up! You won’t hear from us next week…[/h3]

That’s right! The Fire Hose team is hosting its annual summit next week. We’re a remote studio, and we don’t have the opportunity to connect in person too often. So, we make it a point to meet up once a year for a week of bonding, big team conversations, and in-person mockery.

That’s happening next week, so we won’t share an update.

However! We’re looking to share the complete preview for v0.1.2 when we return, so get ready!

Lastly, in community news, we officially have our first speedrun time for Techtonica! Viktoriahhh made it through the freight elevator in just under 17 hours.

Think you can do better? Join our Discord and post your time! https://discord.gg/techtonica.

See you there!

Techtonica is now 20% off!

Techtonica is officially 20% off here on Steam. This sale comes in honor of Programmer’s Day (you’ll see us in the special event this weekend), and it will last from October 3rd, 2023, until October 10th, 2023.

https://store.steampowered.com/app/1457320/Techtonica/

Grab the game, tell a friend, and experience 4-player co-op. Together, you’ll plan your factories, dig into the terrain, and argue over who gets to carry Sparks.

Let’s get to work!

Mass gathering for plants will be in v0.1.2!

As we get closer to v0.1.2 QoL update–launching at the end of October or early November–the team is finalizing more features and bug fixes!

This week, we enabled mass gathering for plants, a hotly requested accessibility feature. Today, we’re going to deep-dive mass gather implementation, game balancing, and frobbable objects. At the end, I’m (Lauren!) going to explain why we bundle patches, just for some extra info.

Several people from the Fire Hose team chimed in on this week’s blog–Allie, the tech wizard who implemented mass gather, Richard on balancing, and Sharat and Ben for some frobbable chat.

[previewyoutube][/previewyoutube]

[h3]Mass Gathering for plants is in for v0.1.2!
[/h3]

Mass Gathering is primarily an accessibility feature based on the feedback we got from players asking about having to repeatedly press 'E' so many times. It's unlocked right from the start of the game, since we don't want to gate accessibility behind in-game upgrades.

To use mass gather, look at a plant and press interact. Instead of releasing, hold the interact button and look at other collectible plants. While held, the player will automatically continue to collect until the button is released. There is a short cooldown between collects (mostly for the animation to catch up) but you should just be able to vacuum plants up easily now, without repeatedly smashing the keys.

[h3]Why didn’t we just use the Mass Gather tool?
[/h3]

So, Allie actually implemented this first.



We aren’t using Mass Gather for plants, because balancing the beginning of the game matters.

First, the feature isn’t really something to be called Mass Gather, it’s an accessibility feature for holding down gather instead of mashing gather while harvesting. We didn't want to make gathering plants by hand faster or easier, just more accessible. Gathering plants by hand is meant to be tedious.

The M.O.L.E., planter and thresher, an exploit with building floors, and more items to come are meant to make gathering plants and fuel easier, so we don't want to introduce something extremely powerful that the player can do from the very start of the game. Finishing your farming machines for the first time is a much better reward when it's tedious to gather plants by hand. We spent a while balancing how much time is necessary to spend gathering plants before the player can automate fuel.

[h3]The implementation in code is interesting…
[/h3]

So, the code changes were to add an extra alternate TakeResourceMode to machine mass collection, internally called "FrobbableMultiGather," frobbables being collectible plants. That name predates me, and I cannot explain it (lol).

We do a raycast to determine what the player camera is looking at, and if it's interactable and the input is a long-hold, we determine if we should enter any multi-gather mode, and based on if it's a Frob then we enter FrobbableMultiGather mode. From that point, whenever we detect a new frobbable object via raycast, we check a timer. If enough time has elapsed, we interact with it (i.e., collect it as a plant), play the collect animation, and then restart the timer.

This state continues until the button is released, setting the mode back to none.

[h3]Frobbable? Is that a typo?
[/h3]



While this word also broke my brain, it is the actual term coined for an interactable object in game development. I Googled it, it’s a real word.

A frobbable object, also called a frob, is a usable object in the game. If a player or another game object can interact with it, it’s frobbable.

This sent me down a rabbit hole, so if you’re curious, the word originated around 1958 at MIT’s Tech Model Railroad Club. A frobnitz was a gizmo or other object you could use. This club at MIT also coined the term hacker. They really had a gift for weird words.

[h3]Why do we bundle patches instead of releasing content as we fix it?
[/h3]

This was a question asked in our Discord this week, and I wanted to go further in-depth than my reply there.

Getting a build of Techtonica that is stable and balanced is not trivial. It takes us many days of thoroughly looking at the same build we are about to release to be sure we're not introducing some awful bug for players. When we go through this process, we wind up needing to do last-minute fixes to make sure the build we ship is good to go. The time it takes to ensure everything in the game is in a shippable state is high.

With all that in mind, we're all working on tons of fixes in parallel and don't have the bandwidth to constantly run through the process of making sure everything in the build is in a shippable state. We want QA helping us with new features and checking bug fixes, etc. And we want the dev team to be focused and not worried about making sure we're ready to ship which is a drain on the whole team.

Finally, the build also needs time for certification for Microsoft (for Xbox/Game Pass). We need to send them a stable, final version of a patch for cert, versus piecemeal pieces of code.

Also, when we show things working in dev blogs, that doesn't always mean they don't still have dependencies elsewhere that still need to be fixed. For example, we might show off new content that hasn't been localized yet, or that still has UI updates coming to support it elsewhere. So something appearing in a blog or a video doesn't always mean it would be ready to ship right then, even if we wanted to.

As a result, we try to put things into bundles to maximize the best use of our time while still getting fixes out to you all in a timely manner.

That’s it for this week, folks! Below is our streaming schedule for October.



As always, join our Discord to chat with us and other players discord.gg/techtonica.

See you next week!

We’ve fixed a nasty HVC Monorail bug for 0.1.2!

This week, we’re pulling out the big guns, because we’ve fixed a big bug. The nastiest HVC (High Voltage Cable) and Monorail bug has been fixed for 0.1.2!

As we continue to improve and fix bugs for QoL update 0.1.2, we’re posting more info about the bugs we’ve squashed and improvements we’ve made. Reminder, this update will launch sometime around the end of October or early November.

In case you missed last week’s update with Joey, we’ve worked on a slew of Machine Streaming improvements for 0.1.2 that we’re really excited about. This week is all about tackling a big, big bug.

I (Lauren) spoke with Sharat, Lead Engineer for Techtonica, about what caused the HVC and Monorail to fight each other and how they fixed it.

[previewyoutube][/previewyoutube]

[h3]What bug are you talking about?
[/h3]

In case you never encountered this bug, it appeared to be pretty simple. If you tried to attach the HVC to the monorail, you would get no power. Y’all flagged this as a really frustrating error to encounter, so our team pushed hard to get it fixed.

And, we totally understand that it was frustrating! But it was a complicated bug across systems, which meant it took some time on our end to solve.

[h3]So, what caused it?
[/h3]

The bug with monorails using power over HVC's had to do with the way our power networks are set up. Simple power networks are created for contiguous sets of power floors. They get updated whenever you build and erase floors. Voltage Steppers allow you to connect multiple of these simple power networks together via HVC cables and splitters.

We have a separate HVC network concept that we use to check if two Voltage Steppers are connected to each other by a chain of HVC's. The way we track those connections is by linking together any simple power networks that have Voltage Steppers on matching HVC networks.

When we connect the networks this way, we're marking one of the simple power networks as a "child network" and another one as the "parent network". For normal power usage, we run everything through the parent network, checking the power needs, power supplied, and accumulators across all of the child networks. And that system all worked fine for our initial 0.1 launch.

So what's special about monorails? Well, monorails require power in two different ways. First, in the same way as assemblers, they consume some small amount of power every tick in order to run baseline operations such as unloading and packing batches of resources. However, monorail depots require an instantaneous burst of stored accumulator energy in order to send out a new cart of resources. We use accumulator energy directly in a few other cases, such as when upgrading a production terminal or activating late game techs. When the monorail wants to send out a new batch, it sends a request to its associated power network to find energy to use.

The bug came up when that power network was a child network. The bug caused the child network to not properly forward that request to its parent network, which would result in the energy request never being granted to the depot. In 0.1.2, we've fixed it so that the parent network now handles all the requests in all of its child networks now. Editor’s Note: I did suggest trying a therapist, too, to resolve their issues. But it turns out it was actually tech related.



But wait, didn't I say that there were other cases using the accumulator energy? Why weren't they broken in the same way? Well, it turns out that all the other cases were already special cases. When using energy to activate a tech, we currently just draw from all build accumulators directly, ignoring connectivity. For upgrading the production terminal, we're checking directly for networks connected to specific HVC ports on the terminal. It's using a different flow since it's searching for parent power networks from the HVC connection instead of from the floor connection. So in the end the monorails were the only case where the bug would show up.

[h3]Does the monorail still have other bugs?
[/h3]

Yes, this only fixes the power issue - which was the biggest one. We've noted that there seems to be some complicated cases for monorail bugs with save/load. We've added a few more safety measures in 0.1.2 to help avoid those issues from breaking the save completely. However, we still haven't solved the root problem, so there may be some issues with some mid-transit monorail batches getting lost or duplicated when loading a save. That’s a larger code refactor than could fit into this update.

As always, you can join our Discord to hang out with our community and chat with our team. Find us at https://discord.gg/techtonica.

We’re also streaming on Twitch on Tuesdays and Thursdays from 1-3pm ET at https://twitch.tv/firehosegames.

Until next week!