Techtonica News

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!

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!

Greetings, Groundbreakers!

This week’s dev update will be centered around more of an in-the-background element of what’s coming in v0.1.2. It’s an important one that will help with performance, so we thought we’d get a little closer to it for a look at exactly what we’re providing and improving. Richard, our Game Director, helped me (hi, it’s Joey!) draft this post.

Before we get there, just a reminder: Techtonica v0.1.2 is still slated for a late-October or early-November release. We’re closing in on that date with each passing weekly update, so stick with us as we slowly pull back the curtain on what’s included. Last week, we detailed some of the video and gameplay settings inbound with the update.

Today? Today we’re talking Machine Streaming.

[previewyoutube][/previewyoutube]

“What’s Machine Streaming?” Great question! Let’s dig in.

[h3]“Really, stop dodging the question; what’s Machine Streaming?”[/h3]

Hang on, okay. Let’s start with problem #1…

In the river biome alone, there are about 180 million voxels of space. That’s space players could fill with 180 million stack inserters if they wanted (please don’t do this). It’s cheap to render and animate inserters; but, do anything 180 million times, and things might get out of hand.

Let’s continue this thought experiment of placing 180 million stack inserters. Now you, a player standing near PT VICTOR, will see only about 800k inserters in front of you. That’s only 0.5% of the total.

So, why bother animating or rendering the rest?



The factory simulation runs independently of the visuals, and we, therefore, only load in and process the visuals for the inserters that are actually on the screen. We refer to this trick as Machine Streaming, and it has been mostly in the game since v0.1.

But there’s more!

[h3]Okay, but how does Machine Streaming improve in v0.1.2?[/h3]

To understand how we’ve improved things, we need to talk about problem #2…

Unity (boo, hiss!) is designed to tether just about everything you see in the game to a piece of data called a game object. Game objects come with a lot of stuff that can be useful in various scenarios, but when you don’t need all that information or extra processing, there isn’t a way to get rid of it. This isn’t usually an issue for many games, since we’re talking about very small amounts of overhead, but even with machine streaming, we’ve still got 800k inserters on screen, and each inserter comes with 14 game objects, so we’re talking 11 million game objects!

Multiply all that tiny Unity overhead times 11 million and now we’re looking at a very large amount of wasted RAM and CPU time.

But fear not, we don’t need 11 million game objects; we actually only need 14 of them.

The new and improved Machine Streaming in v0.1.2 skips past the Unity overhead and only uses the original inserter objects as a template. Everything else we need to render and animate 800k inserters goes into a giant list of precisely engineered data to only use up the RAM and CPU necessary to render and animate each Inserter. We don’t need to store the data for where to render the inserter map markers, how big the collision bounds are, what material the inserter uses, what mesh it uses, the color of its lights, and much more 11 million times. We only need to store it once. The new and improved Machine Streaming does exactly this.



Now when you make a ginormous factory, we do not have tons of wasted RAM and CPU overhead over managing and spawning these objects!

And it gets better! Every game object in Unity comes with what is called a Transform. Transforms are pieces of data that just store the position, rotation, and size of the objects in the game. Transforms are rather expensive to update in Unity, but the new and improved Machine Streaming in v0.1.2 does not use transforms! Instead, we efficiently store all of this data in a way that is super fast to update and stream in and out. This vastly reduces the amount of hitches you may experience as you wander around your factory.

Previously, Techtonica would be working quite hard to update all the game objects and transforms as we stream in the visuals for the machines that you can see, but now we’ve cut all of that overhead out!

Additional wins include being able to do things like separate collision detection from the machine animations. Now, instead of there being a collider for the floor 100m away that you cannot interact with at all, we only load in the collision data for the machines within range of player interaction!

[h3]How many FPS will players gain with Machine Streaming in v0.1.2?[/h3]

That’s an incredibly nuanced question with many answers. The new and improved Machine Streaming is primarily targeted at two things: reducing the hitches players experience while walking and the RAM consumption of large factories. It is not simple to measure how much Unity overhead we have cut out when we don’t have access to their API, but players should experience higher frame rates in large factories. Reduced RAM usage should also reduce the likelihood of crashes on Xbox platforms.

I want to reiterate: this is not an optimization to improve performance on smaller factories. These Machine Streaming updates are an investment we have made in our systems before we start giving players tools to build really massive factories and give them new places to build those factories. Yes, it comes with some performance improvements in large factories, but most importantly, this optimization lays the groundwork for many future performance improvements we’re planning to make that were impossible without this new Game Object-less Machine Streaming system.

[h3]So, what’s next for simulation system improvements?[/h3]

Now that we have Game Object-less Machine Streaming, we can start talking parallelization!

The factory simulation must be done (mostly) sequentially, but the same is not true for updating the visuals to match the simulation. It doesn’t matter whether we animate a Smelter or an Assembler first, so why not let them happen at the same time with multi-threading? Previously, using Game Objects and Transforms would have made this task quite challenging, but our new Machine Streaming system is set up such that parallelization is a possible upgrade we can make in the future!



And this is just the tip of the iceberg. As we continue to add more content to the game, we are constantly working to push more and more of these optimizations so that players can build bigger and bigger.

We’ve been really inspired by all of the factories we have seen so far, and we are very motivated to keep improving the game to see what you all can do!

[h3]By the way, we’ll be at Tokyo Games Show![/h3]

Yes! Techtonica was selected to participate in the TGS 2023 Indie Select 80. If you’re reading this and you plan to attend the show, stop by our small spot and say hello. I (Joey) will be there!



That’s it for this week’s update. We’ll be back next week with more detail on Techtonica v0.1.2.

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.

Hey folks! We know you like factory games. We also like factory games. Now you can get two factory games, bundled, at a 12% discount on Steam.

We’ve partnered with the Captain of Industry team to bundle Techtonica and Captain of Industry.

https://store.steampowered.com/bundle/34792/Techtonica__Captain_of_Industry/

Own one of these games already? This is a Complete The Set bundle, so you’ll still get the discount if you buy the game you don’t already own through the bundle.

Ready to get to work?

Settings!

I mean this with complete sincerity, but I love that detailing Settings functionalities for Techtonica means so much to our community. You care about the gameplay experience you’re getting, and we’re really happy to be making so many Settings-based changes in v0.1.2.

Selfishly, I care a lot about these, too. I’m most excited about Fullscreen Borderless Windowed support, but there’s lots in here to love.

In case you missed last week’s update from Lauren (which you can read right here), v0.1.2, the second Quality of Life update, is slated for late October or early November. We’re taking the time between now and then to showcase what’s coming.

[previewyoutube][/previewyoutube]

So! Let’s dig in. Oh, and before we get started, make sure to read ahead for a special partnership we’ve put together with another awesome factory game.

[h3]Belt Riding and Smart Snapping[/h3]

There was a call on our team a few months before the launch of Techtonica where we took a look at how much time we had left and what features (big and small) we wanted to get in before launch. Lots of stuff was on that list, like Ultrawide Support, cloud saves, and a screen shake toggle. So was riding Belts.

It’s true! We wanted players to be able to ride on Conveyor Belts before we launched, and it was a super easy add for us to include.



It turns out that not everyone wants to ride on Belts, though. So, we’re adding the No-Fun Belt Riding Toggle with v0.1.2. Tick the box off and you’ll no longer accidentally move while standing on a Belt in, say, build or deconstruct mode.

We’re also adding a Smart Snapping toggle with this update. It won’t be super important until Base Building comes in v0.2, but for now it’ll prevent stuff like Miners from auto-spinning toward the closest ore vein. When Base Building gets closer, we’ll detail more about how the Smart Snapping toggle may help you build your bases.



[h3]Limit those frames and other video settings changes[/h3]

Techtonica features Vsync support. When Vsync is turned on, the framerate is automatically limited to the refresh rate set for your display. But, maybe you want something lower? With v0.1.2, we’ll add a framerate limiter that will aid performance and GPU temps. You’ll be able to tweak your desired framerate from a dropdown of options in the Video Settings menu.



We’re also adding Borderless Windowed Fullscreen with v0.1.2. This is great for multiple-screen users like me! Anecdotal aside, I find my webcam hangs when I use fullscreen but runs smoothly with windowed and borderless windowed for most games. Might be a hardware allocation issue, but who knows?

[h3]The FMOD update that only affects some folks[/h3]

Finally for this week’s update, we have news regarding audio fixes that will likely only affect a small portion of our users. Some Groundbreakers have, since launch, been having some more significant audio issues. In relatively rare instances, this includes no audio at all.

We’ve made an update to FMOD, the audio engine we use, that should fix these issues. This was a hard one to reproduce, so please let us know if you had the problem and it persists.

As always, you can start threads on Steam or join us on our Discord at https://discord.gg/techtonica.

Ah, and one more thing before we go.

https://store.steampowered.com/bundle/34792/Techtonica__Captain_of_Industry/

We’ve been chatting with the Captain of Industry team, and we decided to put together a Complete the Set bundle for Techtonica and Captain of Industry. Get the games together and save 12%. If you already have one, you can complete the set and get the other for the discounted price.

Hit our store page to snag the bundle!

See you soon, Groundbreakers.