Devlog #18: Crafting & Storage

Long time no see! I had to take a couple of weeks off from game development to take care of some projects around the house, but I’m finally back with a fresh new devlog! We’ll be taking a look at the all new crafting system and take a deep dive into the design of item storage. Let’s dig in!

Crafting

Crafting is the cornerstone of any automation game. The whole point of a factory is to automate the production of some item. Automation Station is no different in this regard. You’ll be needing to craft lots of different items as you expand your factory and unlock new technology. The majority of games with crafting follow a similar formula: there is some building or menu where you can add all your ingredients and, after some time has passed, it will convert your ingredients into the desired product.

This system works very well, but I wanted to do something different with Automation Station. Specifically, I wanted a crafting mechanic that required the player to arrange the ingredients in a specific way. Rather than simply feeding all the items to a machine, you would have to carefully plan how to get the ingredients to the right place and at the right time. Way back in devlog #3, I outlined several different ideas that I was experimenting with for a crafting system like this, and I’ve continued to brainstorm new ideas since then. Unfortunately, all of these ideas had flaws that didn’t quite work for Automation Station. They were either too complex, too finicky, or too easy to trivialize with the other components available in the game.

Item Stacking

Eventually, the idea of item stacking was suggested by someone in our Discord server (unfortunately, I don’t remember who suggested this idea first ☹️). The last two devlogs were all about the new item stacking, so I won’t get into the details of how that works. To summarize, the new item stacking mechanic is a way for the player to construct vertical stacks of items. Players can use item stacking to, for example, increase the throughput of a conveyor belt by condensing the items into stacks.

But how does this all relate to crafting?

The Assembler

In Automation Station, the player will need to carefully construct specific stacks of items in a specific order according to recipes. Once they have a stack with the right items and in the right order, they can feed it to another machine to craft the final product. This new machine is called the Assembler.

The Assembler simply turns item stacks into new items. It has a belt input to receive stacks of items and the product will be sent along the belt output. When there is an item stack waiting to enter the Assembler, it will raise it’s “head” to the correct height to receive the item stack.

This system allows for a lot of creativity in how a factory can be designed. Some players might choose to stack everything right next to an assembler in a compact setup. Other players might have one factory that builds the stacks and another that assembles the stacks into the final product. If two recipes have some shared combination of items in the two required stacks, a player could choose to make one factory for the shared part of the stack and then split that to two more factories to make any final adjustments unique to each recipe.

Here is an example of a fully automated production line which smelts copper ore, assembles it into copper wire, and then stacks that on an iron ingot that has been smelted from iron ore. This stack of copper wire on top of an iron ingot is then assembled into stators, the final output of this factory.

At the moment, the Assembler does not require any explicit recipe to be set. It simply checks the incoming stack to see if it matches a recipe. This means that the player will need to learn the recipe rather than being able to pick the recipe they want from some kind of menu. I’m still deciding if this is the best option, but I think it would be neat to require the player to collect pages of a manual (similar to the game Tunic) and then refer to that when constructing a new factory.

Item Storage

One of the unique things about Automation Station is that buildings don’t have internal inventories. This was an intentional design choice to make all of the game’s information visible at all times, rather than hiding away details inside a menu. However, this comes with some tradeoffs. For example, in other automation games, a common early game strategy is to throw a bunch of ore inside a smelter and then come back several minutes later to pick up all of the newly smelted ingots. This allows the player to effectively perform batch operations so that they can spend their time on other things, such as scaling up their factory.

With the buildings I’ve shown so far, this isn’t possible in Automation Station. A crucible has to be fed ore one piece at a time. Same for all of the other processes in the game. Eventually, the player is able to fully automate a smelting setup with conveyor belts, but this requires a lot of resources and crafted items to set everything up. That means that the early game will require the player to do a lot of repetitive and manual tasks.

To address this issue, I decided to add an item storage building. I’m still working on the design and functionality of this building, but I wanted to show some of the options I’m considering.

Canister

If you’ve been following the game’s development for several years, you might remember the Canisters that I showed in devlog #2. I prototyped several versions but here is one of them:

The game worked quite a bit differently back then, but the basic idea for the canister was that it could store multiple of a single type of item. This constraint meant that I only ever needed to “show” one item at a time, which simplifies the art while keeping everything visible. Well almost everything. There was no indication of the quantity being stored. But this is something I fully intend to solve, perhaps with some kind of indicator on the side.

I like how simple this design is, but there is one major problem. How do you get the items out of it in an automated fashion? Automation Station doesn’t have any arms or inserters that can pick up items. But what good is a chest if you can’t pull the items out of it. One of the main goals of this building was to allow the player to use it as an input buffer for things like early game smelting.

One obvious solution is to just add arms to the game. I’ve been debating arms for quite some time, but that comes with a whole bunch of tradeoffs. I plan to do a deep dive into item transfer in a future devlog, so I’ll save that discussion for a later date.

Another possibility is to add some kind of output slot on the side of the canister:

If a belt was placed next to the canister, the item would drop on to the belt. While this concept seems nice in theory, there are some issues with clipping if the canister happens to be next to a cliff. In general, I try to avoid designs where the building extends beyond its hex tile. I also don’t really care for the design of this canister as I find the multiple item slots to be less intuitive and more awkward to use.

Hopper

In real life factories, a hopper is the name for a container used to store bulk material. Typically, it is tapered at the bottom so that the material can fall out the bottom using only gravity. They are also commonly found holding coffee beans on top of an espresso machine or coffee bean grinder

Hoppers aren’t very common in games, with one big exception: Minecraft. Minecraft features both hoppers and chests, both of which can store items. The chest is mostly for manual use while the hopper lets you collect loose items, input items into buildings, and pull items out of buildings. However, hoppers have a relatively small inventory so they are typically combined with chests to get the best of both options.

With the new height-based mechanics that have been added to Automation Station, I thought that a hopper design could work well. I came up with two variants: one that drops items into an adjacent building, and one that sits directly top of a building and drops items into it.

The design on the left is the most consistent with existing mechanics in the game. Conveyor belts can drop items into lower adjacent buildings, so this hopper would work the same way. However, I personally find this design a little weird. When I think of a hopper, I generally think of something that sits on top of something else, not to the side of it. There is also the problem of knowing how high the hopper needs to be. Without a bunch of indicators, it will be hard to know for sure that the hopper is high enough to drop items into the building next to it.

I find the hopper-on-top design on the right to be much more intuitive. Simply stick it on a building and it will drop items into the building below. No guessing if things are high enough. If the player is able to place the hopper somewhere, they know it will work as expected. I continued to iterate on this design and here is what it looks like in game:

There are a few considerations with this design. The first is that loading items into this hopper requires bringing items way up high and dropping them into the top of the hopper. This would require multiple ramps or a big cliff to get the height needed. This isn’t necessarily a problem, but it is quite clunky to use in fully automated setups. More recently, I had the idea to have toggleable mode for the hopper. In output mode, it would drop items out the bottom like normal, but in input mode, it could suck up items from the bottom and into the hopper. This would avoid the issue of needing to lift items way up high to get them inside the hopper, but mode toggles introduce some complexity with controls and UI.

The second consideration is that this hopper-on-top idea requires support for stacking buildings on top of other buildings. This hasn’t been a feature of the game up to this point and is a pretty big change. On the implementation side, I spent several days converting the existing hex grid into a full 3D grid that supports stacking. But this also has big implications for gameplay. If a hopper can stack on a crucible, what other buildings can be stacked together? I have some other ideas that could leverage stacked buildings, but I’m not sure that there are enough ways to make the mechanic interesting. Perhaps the hopper is one of the only buildings that works this way, but it feels like this should become a primary mechanic of the game or not have it all.

There is also the question of whether stacked buildings work with the current camera and controls. When things stack, they can easily occlude large parts of the factory behind them, making it hard to see and hard to click on what you want. Other games get around this by either having a first person camera or having a way to view specific layers.

Stacked buildings is a pretty big topic that I plan to explore more. At the moment, I’m still undecided on if it is the right direction for the game. I’ll revisit this topic in a future devlog, but for now, let’s get back to designing an item storage solution!

Belt Chest

Another idea I wanted to try out for item storage was a chest with a belt input and output. Here is the design I came up with:

There are two ports on the chest: one to receive items and one to output items. If you’ve played Satisfactory, this is pretty much identical to how the storage chests work in that game. However, there is also a slot on top. This serves two purposes. The first is to show what is currently inside the chest. Just like all the other designs I’ve shown, the chest will be limited to one type of item, so I only need to show a single item. Quantity will be indicated with some kind of indicator on the side. When the chest receives its first item, it will place that item in the top slot. And this item will be consumed and come out the output port if it is the last item in the chest.

The other purpose of this top slot is to receive items that are dropped into it. Since receiving dropped items is supported on other buildings, I figured that it made sense here as well. That means that when an item is dropped on to the top of a chest, any existing item in the top slot will be consumed. This also makes the chest easier to manually use, as the player can simply highlight the item on top to pick it up.

The main consideration with this design is that it relies on the player having belts unlocked. Initially, I wanted the item storage to be available in the early game prior to them unlocking belts. That way, they can start processing resources in batches before they have everything fully automated. But with this design, the player will need to unlock and start crafting a few belts to use the chest. I’ll need to playtest this option to see if it is a problem or not with the game’s progression.

Wrapping up

I’m still figuring out which approach I prefer for item storage. There are a lot of considerations with these ideas and a lot of them depend on some other open design questions. For example, are buildings able to stack? And what methods of item transfer are available? Regardless, I’d love to hear your thoughts on your favorite proposal. Or if you have a different idea for item storage or how to solve the early game batching use case, please drop a comment below or join our Discord community.

Changelog:

Here are all the changes since the last devlog:

• New model for the Assembler
• Implement the Assembler functionality
• Animate the Assembler
• Create new models for ingots and copper wire
• Create prototype for canister design
• Create new model for hopper
• Create prototype for hopper design
• Create new model for chest
• Create prototype for chest design
• Rewrite grid system to be fully 3D, supporting stacked buildings
• Update placement logic to account for stacked buildings
• Allow camera to be tilted vertically

Thanks for taking the time to read this devlog! I plan to get back to releasing new devlogs every two weeks, so you can expect the next one in early October. Have a great weekend!

-Scott