In Automation Station, players need to use B0XB0T’s laser to harvest resources and heat up the crucible for smelting, but thus far, they haven’t needed to explicitly equip the laser to do this. Since the laser is currently the only tool in the game, that has worked pretty well. However, I plan to add a scanner and a variety of other tools that the player will unlock throughout the game.
While it might be possible to dynamically switch to the correct tool when interacting with an object, that assumes that only one tool can be used on a given target, which may not always be the case. There is also a danger of making the game too smart such that the action performed is not what the player expected or intended. Alternatively, each tool has its own keybinding, but that is asking the player to do a lot of memorization.
The much more flexible and common solution is to have a way to equip different tools. I decided to try this out in Automation Station and found that it works quite well. Here is a look at the new tool system in action:
The toolbar at the bottom of the screen now has a special section for tools alongside the items. Each item and tool can be equipped. By equipping the laser, the player is able to harvest ore and heat up the crucible. And if the player unequips the laser or switches to an item, they get a different set of actions. Each equipped tool changes how the player will interact with the different objects in the world.
Now that the player can separately equip items and tools, I had to revisit how the interactions worked when an item was equipped. The primary action while holding an item is to deposit it, so I decided to show an arcing trajectory indicator to help communicate where the item will be added. Using the item while hovering over a building will attempt to place the item in the building’s slot. If the item can’t be added, it will show as red to help communicate that depositing is invalid.
After adding these trajectory indicators, I realized that it felt like you ought to be able to throw items anywhere. While this isn’t super helpful at the moment, I decided to re-add the throwing mechanic so that you can toss items loose on the ground. I’m hoping to add additional gameplay elements that leverage this throw mechanic in fun and playful ways.
In the last devlog, I mentioned how I had reworked the controls to streamline certain interactions. While I think these changes were an improvement, there were still some issues that players were running into. Specifically, having the same button for depositing items and using the laser meant that players were never quite sure what was going to happen when they clicked that button. In reality, there was only ever one option. For example, if a crucible is empty, left click will attempt to deposit an item. If the crucible has ore, left click will start heating the crucible. But even though the game had no ambiguity in these scenarios, it still felt somewhat ambiguous to players and led to pressing the wrong buttons or being frustrated by things not behaving as they expected.
By introducing the tool system and requiring players to explicitly equip different items or tools, the goal is to remove this ambiguity. For example, if the player has the laser equipped, the game should assume that they are trying to use the laser, even if the target can’t currently be heated. And if the player has an item equipped, the game should assume that they are trying to deposit it, even if there is no room. More generally, the equipped tool lets the player tell the game what they want to do, even if it may not be possible, and the game should respond accordingly.
The main downside of the new item and tool system is that the player now has to manually switch what they have equipped, which can be cumbersome. For example, if you’re building a house in Minecraft, you often want to switch between your wood planks for building and your wood axe whenever you mistakenly place a block in the wrong spot. You can try to optimize your toolbar arrangement to make switching fast, but it still adds friction to the gameplay. That’s why I decided to add an item/tool toggle. Pressing the keybind for this will switch between the last used item and the last used tool. This makes it much easier to manually smelt ingots in the early game since you need to switch between depositing ore and then heating it up.
With all of these changes, there were still several open questions related to the controls for interactions. How does the player perform interactions that don’t require an item or tool, such as picking up items or pressing buttons? Can the player unequip or holster an item and tool? What does it mean to have an “equipped” item or tool in terms of the controls? When should I show the throw trajectory and laser targeting indicators?
I spent a huge chunk of time trying to answer these questions by prototyping different control schemes. For example, I tried out a system where the player had to hold right click to “aim” the current item or tool by holding right click. While aiming, left click would throw the item or use the tool. While not aiming, left click would pick up items and press buttons. This worked pretty well, but it felt a little awkward to hold right click and press left click. So then I tried an aim toggle on right click. This worked a bit better, but it was easy to get lost in all the different modes (tool toggle, aim mode, build mode, etc.). I even tried having a separate button for tools and items.
Ultimately, I settled on a system that works as follows:
So far, playtesters seem to like this option best. However, I think this will be a part of the game that I’ll continue to iterate on and refine, especially as more content is added and I get more people playing the game.
Beyond all of the stuff above, I also spent a lot of time on some build mode improvements, but I’ll save those for a future devlog. I also decided to port a bunch of custom shader and rendering stuff to Unity’s new API, which ended up taking almost a full week. Anyways, that’s all for this devlog. Huge thanks to those of you who take the time to read through these! As usual, let me know if you have any thoughts or suggestions in the comments below or in our Discord server.
Cheers!
-Scott
- Improvements to hover logic
- Sort total building cost and individual building costs for consistency
- Zooming in play mode no longer zooms the build mode camera, and vice versa
- Slow down the camera zoom to improve smoothness
- Simplify the interaction framework by removing the need for separate systems
- Consolidate interaction systems across build mode and play mode
- Add control prompts for constructing, placing, picking up, rotating, copying, and demolishing in build mode
- Add the ability to "aim" while holding an item
- Slow down the player and have them face the cursor while aiming
- Add arcing indicators while aiming to show aim direction and target
- When depositing is invalid, color aim arc in red and stop moving the dots
- Limit aim arc distance based on max interaction distance
- Disable building indicators outside of build mode
- Added keybind for "Q" to restore or holster equipped item
- Disable retrieve interaction while holding an item
- Add warning message when attempting to heat something that is not currently heatable (e.g. an empty crucible)
- When picking up and moving buildings in build mode, "cancel" now restores their previous locations instead of demolishing
- Only allow depositing when holding an item
- Combine interaction systems for depositing into slot and depositing into stacker
- Remapped scroll wheel to cycle through items in the toolbar instead of zooming
- Added controls to zoom camera on "," and ".". This will likely be changed in the future.
- Prevent items from being added to a cache
- Only snap the arm aim indicator when the slot can be deposited into manually
- Brought back outlines and highlight for the occluded portion of the hovered object
- Add in separate control prompt for rotating a building by clicking and dragging
- Disable outlines when hovering non-buildings in build mode
- Add keybind to cancel in build mode using "Q"
- Disable the ability to demolish buildings while planning or moving another building
- Restyle control prompts with modifier to show the modifier key before the primary keybind
- Add warning message when attempting to place or construct a building in an invalid location
- Added control setting to switch between toggle or hold aim
- Added targeting indicator when laser is equipped
- Improve laser beam targetting
- Added a separate "tool" bar for holding tools (currently just the laser)
- New UI for toolbars with the ability to switch between items and tools
- New authoring workflow for adding tools to the new tool bar
- Reworked internal state of toolbar to support tools and the item/tool mode toggle
- Rewrote logic for spawning the correct item in the player's hands based on toolbar state and equipped item
- When toggle aim is enabled, switching items or tools automatically enters aim mode
- Slightly reduce walk and run speed
- Add sort index to tools so that they always appear in the same order
- Add an abstraction layer between input controls and the interactions that they are mapped to based on the current control scheme settings
- Add a third control scheme that allows tools and items to be used on right click instead of needing to hold right click and pressing left click.
- Added support for auto-populating enum dropdowns in debug menu
- Fix the ability for stackers to receive items from input conveyor belts
- When loose items spawn from a destructible rock, add a delay before the player can automatically pick them up
- Adjust several settings for the destructible rock explosions
- Items can now be thrown loose on the ground when not aiming at a slot
- Laser can now be fired when not aiming at a laserable target
- Improve laser vfx heat marks to help avoid graphical clipping
- When extracting resources with the laser, stopping and starting the laser will resume progress. This is especially useful when the cursor accidentally drifts off of the target.
- Extracted resources now spawn on completion instead of gradually throughout the laser animation
- When heating something with the laser, stopping and starting the laser will resume the heat progress.
- Added a fourth control scheme, similar to toggle aim, but instead of toggling aim mode, it toggles between the item being equipped or holstered.
- Complete rewrite of outline render feature for Unity's new RenderGraph API.
- Complete rewrite of cavity render feature for Unity's new RenderGraph API.
Cheers!
-Scott
]]>Automation Station is a game about automation, so it hopefully isn’t surprising to hear that my priority has been on the game’s systems. I always planned to add more vegetation and life to the world, but I kept telling myself that I can add it later once the “core” of the game is done. But it had been literally years since I added the blubber tree, the only resemblance of life in the entire game. At this point, I think I could safely justify spending a couple of hours on some new plants. So that’s what I did!
As you can see, the island is now full of little bushes and patches of grass, making it a lot more lively. It also means that I can reduce the number of blubber trees without it feeling too barren. This is great because dense trees cause several issues with obscuring the player or buildings.
While I think these bushes and grass are serviceable, they are only placeholder. As I mentioned above, I’m trying not to spend too much time on making the world pretty at this point, so I went with the easiest and fast option: I took my leaf shader from the blubber trees and slapped it on some bush-shaped blobs to make the bushes. And the grass is pretty much the same but applied to a flat hexagon shape.
I’ve been fighting the urge to dive into more sophisticated grass shaders for a long time now, but eventually, I’ll give in. So you can expect the grass and bushes to look a lot better in the future.
Yup, arms are back. Arms are a building that picks up items from an adjacent building and places them in a building in the opposite direction. If you’re familiar with Factorio, it’s essentially an inserter.
Those of you that have been following the development of Automation Station for a while will know that I don’t like arms. My main issue is that they feel too similar to a conveyor belt. Both transfer items from one place to another, so why do we need two buildings? This is the question I’ve been struggling with for years… and I mean years.
Consider the crucible. Ore needs to be placed inside of it, then it is heated up and it produces an ingot. Getting ore into the crucible can be accomplished in a lot of ways, such as dropping them in from a cliff or ramp, launching them in, or dropping them from a hopper on top. But how do you get the finished ingot out of the crucible?
After deciding against arms early on, my solution had been to add a hinge to the crucible that would “pour” the ingot out onto a belt. This works pretty well, but it has a few problems. Firstly, the crucible is the first building you unlock, before getting access to belts or other automation tools. It could pour onto the ground, but this makes a mess and is unwieldy. Or the crucible could be smart and wait to pour until there is an output, but that makes the it complicated and confusing, especially when it shows indicators for the pouring functionality. Secondly, the integrated hinge is a feature that I will need to include on all of the buildings that I wish to output from. This adds an art constraint to a huge pile of other art constraints that I’m already struggling with. Thirdly, now that height is an integral part of the game, it is critically important that the player understands the output height of the crucible. With a rotating hinge design, this is not very intuitive or clear. I would need to rely pretty heavily on indicators to help the player understand the behavior. And lastly, I want the crucible to be as simple as possible. Ideally, the only thing it does is smelt when heat is applied. But this design requires the crucible to also transfer items, just like a belt. And at that point, I may as well have something like an arm.
By adding a dedicated arm building, I can get the exact behavior I want for the crucible and other buildings that need to be unloaded. An arm is the only building that can pick up items. Belts can only receive items from other belts or have items dropped onto them. There are still a few issues with arms and details to work out (especially concerning height and drops), but I think arms are the best solution going forward.
I have a lot more I can say on the topic, but I’ll save that for a future rambling on Discord. But I’d love to get all of your thoughts on this change, so let me know in the comments below or in our Discord.
In some recent playtests, one issue that kept coming up was players not knowing what they were interacting with. In some cases, the control prompts would give some hints (e.g. “Left-click to extract stone”), but there were several cases where it was impossible to know what an object was or how to interact with it.
I spent the last couple of weeks overhauling the UI to add a lot of missing information.
Specifically, hovering an object now shows its name at the top of the screen. If an object is interactable, I show all of the control prompts, even if some of those interactions are currently not possible. Some objects can have lots of prompts, so I decided to move them to the bottom of the screen so that they aren’t in the way. Finally, when hovering an item in the toolbar, it now adds a little tooltip giving the name of the item.
When I first started adding these new UI elements, I added a lot more information, such as item descriptions and building statuses. While this was useful in some cases, it really cluttered the UI. And for things like building statuses, you could usually figure it out based on the building’s appearance and behavior. I decided to remove all but the most essential pieces of information to keep the UI a bit cleaner. If the player still wants more detailed information, I think it would be best to show that in some kind of codex.
However, there were still a few pieces of building information that were necessary in the UI. When hovering a canister or anything with storage, it is important to know how many items are inside. The radial indicator helps a bit, but sometimes you want the exact number. And when hovering a pylon lock, it is important to know exactly how many items it needs so that you can prepare accordingly. Thus, when hovering those objects, a bit of extra information appears at the top of the screen.
UI is definitely one of my weakest areas of game development, but I’m really happy with how this is coming together. I have a whole list of other little tweaks and style changes I want to make, but the priority is on making the UI usable and presenting all of the required information. I’ll continue to iterate on the UI aesthetics later on in development.
The game’s controls and interactions have gone through several iterations throughout development. In the initial prototype, there was no character, and the game was all about placing buildings. When I first added the character, I reworked a lot of the interactions to be similar to the game Astroneer. Specifically, items could be moved around with the cursor between the character’s backpack and the buildings. While this system was super tactile and playful, it was pretty finicky when the camera was zoomed out and it didn’t work on the controller at all. To solve these issues, I introduced an interaction system similar to Stardew Valley. Instead of a tactile backpack, there would be a toolbar and inventory. Selecting an item on the toolbar would place the item in the player’s hands, allowing you to quickly add that item to a building.
This was a huge improvement for the style of the game and made it a lot easier to play. However, there were still some issues that were coming up in playtests. Specifically, using the same button for picking up and placing items was problematic as it resulted in lots of cases where the player would do the opposite of what they wanted. Also, the held item system was a bit cumbersome as you constantly needed to store items to harvest resources or manually smelt and then restore those held items afterward.
To address these issues, I plan to make the following changes:
The basic idea is to switch to a system where most interactions are on the primary button, only using the secondary button when there is already a primary interaction. And the changes to the held/active item should help streamline a lot of the interactions.
I already made some of the above changes, such as allowing smelting while holding an item. Here is what that looks like:
As you can see, if you’re holding an item you’re still able to heat the crucible. But like I mentioned above, the plan is to move this item to a dedicated slot on top of the backpack so that the player doesn’t have to hold the item awkwardly with one hand. More playtesting is needed to evaluate this change, but I think its a big improvement to the game flow.
In the last devlog, I showed off some of the indicators I added to buildings to help explain their behavior. With the reintroduction of the arm, I revamped all of the indicators for item transfer. Now the belts, ramps, arms, and launchers all use a consistent style and timings to work well with each other.
That’s all I have for this devlog. Thanks for taking the time to follow along with my development journey. If you have any feedback or suggestions, I’d love to hear them in the comments below or in our Discord server.
Cheers!
-Scott
]]>For most of Automation Station’s development, the game has been more of a creative sandbox where the player can place buildings for free. This has been great for testing new systems and features, but the plan has always been to make buildings require items in order to build. I’ve finally implemented a system that checks for and consumes all the required items when constructing new buildings.
There are a few different things to unpack in this gif. While planning out the placement of new buildings, a panel in the bottom right will tally up the total cost of all the buildings (ignore the overlapping panels; that is an artifact of the tiny resolution I’m recording at). If the player has all the required items, the holograms will be blue, but if they can’t, they will turn red. Once placed, the building will be “constructed” and consume all the required items.
Also, the building previews now use the hologram shader that I showed off in (devlog #20). The hologram effect helps communicate that the building does not yet exist. This is especially important when considering that buildings can also be picked up and moved around. Since the building is already constructed, I just use a blue glow effect and raise the building up instead of using the hologram effect.
If you decide that you want to remove a building completely, you can also demolish it.
As you can see, demolishing a building will drop a bunch of items. These are the exact same items that were used to construct the building, so you’ll never lose items when demolishing. I’m still deciding between dropping loose items and adding them straight to the player’s backpack, but I definitely think the loose items are more playful.
One of my design goals is to make all the buildings super intuitive to use. However, there are still a lot of cases where the behavior isn’t perfectly clear, especially with how a building will interact with others. To help with some of these problems, I added indicators to several buildings.
These are still a work in progress, but I think they already help quite a lot. Since belts pause in build mode, just showing the belt direction is already a huge help. They also show a preview of how items will drop from the end of a conveyor belt or out of a crucible, taking into account any differences in elevation as the building is dragged around.
The current plan is to only show these indicators in build mode, since that is when they are most useful. They’ll show up both for new building previews and when an existing building is hovered or picked up.
I expect to iterate on these quite a bit and make them all look a bit more unified, but let me know if you have any thoughts for how these could be improved.
I thought I’d wrap up this devlog with a preview of a little terraforming system that I prototyped.
While reworking some of the terrain systems, I realized that supporting terraforming in-game was actually quite easy to do. Even though this feature may never make it into the final game, I decided to try out and got it working in less than a day.
If I wanted to add terraforming properly, there is still a ton of animation, particle, controls, and UI work needed to make it look nice and integrate with the rest of the game. But, it’s still cool to see that the terrain tile generation system was flexible and performant enough to support this in real time.
Just to be super clear, this was mostly a curiosity experiment and is not a guarantee that terraforming will be in the final version of the game. There are a lot of considerations to adding a terraforming system to the game, especially when it wasn’t planned for from the beginning. The environment with its trees and height variations was intended to add a bit of a puzzle element to factory planning. Letting the player terraform (even if it is expensive) may result in a worse overall experience.
That’s it for this update! Let me know what you think about these new systems in the Discord server or in the comments below.
Here are all the significant changes since the last devlog:
Cheers!
-Scott
]]>In the first devlog of 2023 (devlog #4), I debated how buildings should be made in Automation Station. Initially, buildings came packaged in these little crates, but I quickly realized that making each building crate unique and distinguishable was too difficult.
Then, I tried creating miniature versions of the belts and other buildings to represent the “item form” of the building. While this looked adorable, it complicated the controls for placing buildings, and creating the art for these miniature buildings was proving to be a lot of work.
Ultimately, I decided to go with a completely different approach. Rather than crafting the buildings in your factory, you only need to craft intermediate items, such as gears and plates. Buildings can then be constructed from these parts when placed.
In February (devlog #5), our little box bot friend got a backpack! Prior to this, you were only able to store 4 different items in your backpack, which proved to be extremely limiting in an automation game.
While I added the cliffs near the end of 2022, I did a bunch of work to make all the buildings work with them. This made it possible to drop items off of cliffs or launch them up to the top.
In devlog #6, I introduced a brand new system for interacting with items. This made it possible to pick up nearby items and place them in buildings without needing to aim precisely with a cursor. This also made it possible to support controllers in addition to mouse and keyboard.
While the backpack was great for increasing the player’s storage, it had the downside of not being able to see what items you had nor a way to quickly access items. To address this, I added a toolbar which can be seen in devlog #7.
In devlog #8, I showed off a new method for mining ore. Using your trusty mining laser, you can heat up an ore-rich rock until it explodes into chunks of ore, ready to be smelted.
Next up was the Build Mode! At any point in the game, you can enter build mode, allowing you to select and construct new buildings. The goal was to make factory construction as painless as possible.
The most common building is the conveyor belt, so I spent a bunch of time improving the belt placement tool, allowing you to quickly make paths around obstacles and through your factory.
You can read more about the build mode and the build menu in devlog #8, devlog #9, and devlog #10.
In May, I finally decided to try out a perspective camera. Although the change is subtle, this made it much easier to determine depth and navigate the world.
While this was a relatively small change, I had to spend a lot of time upgrading all of the shaders and visual effects to support this camera change.
In devlog #11, I reworked the smelting to be based around a new heat system. At the start of the game, you can smelt using your laser to heat up a crucible filled with ore.
Eventually, you can set up coal-burning heaters and connect everything with conveyor belts to fully automate a smelting factory.
The item launchers, which act as a way to launch items over obstacles, have been in the game for a while. However, they used to have a delay before launching their item. In devlog #12, I rewrote the logic for item transfers and launchers to remove this delay, even when a loop of conveyors is completely full of items.
While attempting to fix some weird timing bugs, I ended up rewriting the game’s clock which controls the timing of buildings and their animations. A fun side effect of this work is that it is now possible to slow down or speed up all of the buildings in your factory.
One of the more unique elements of Automation Station is how every building can be moved and rotated while continuing to perform its function. In June (devlog #13), I polished up the mechanics to ensure that any combination would work as expected. To recap, I’ll show off the various “movers” and how they can be used.
First up is the Piston which pushes an adjacent building over by one tile.
The Rotator is able to rotate an adjacent building either clockwise or counterclockwise.
Finally, we have the Orbiter which orbits all adjacent buildings around it in a clockwise or counterclockwise fashion.
In devlog #14, I made it so that loose items on the ground will be automatically picked up when the player gets close to them. This removed the need to manually pick up each item one by one, which was especially useful for manually mining and extracting resources.
Ever since adding cliffs to the game, it was quite awkward to get items uphill. You could use launchers, but sometimes that felt a bit overkill. So in July (devlog #15), I added conveyor ramps!
Technically, you don’t need a ramp to get items down off of cliffs, but I think some players might prefer the gentle ramp over the sudden drop. Perhaps some items in the game are fragile and need to be carefully moved around without dropping them from cliffs, providing a non-aesthetic reason to use ramps.
In August, I introduced a new core mechanic to the game called “Stacking”. As the name implies, stacking refers to vertically stacking items on top of each other. I prototyped several different designs for the Stacker building which I documented in devlog #16 and devlog #17. Ultimately, I settled on this design that features a little support to hold items at different heights:
There are currently two versions of the stacker which allow you to create stacks of up to 3 items. However, I’m considering reworking this and other buildings to be more modular which would allow for even taller stacks.
With all of the new height-based mechanics that I had been adding to the game over the last year, it was becoming increasingly clear that the current item size wasn’t going to work. Up until this point, the items were roughly spherical and somewhere between the height of a conveyor belt and the height of a cliff. This made it impossible to make things line up vertically. Eventually, I decided to change the shape of items to follow this flat cylinder shape, as seen here with stators:
While part of me misses the old item balls, I think transitioning all of the items to follow this shape will be a huge improvement for gameplay.
Automation Station has gone through several iterations on the design for a crafting system. I’ve tried a ton of unique and creative options for crafting; all of them had problems with how they interacted with the rest of the game’s systems and art constraints. However, in September, I finally added what I believe will closely represent the crafting system in the final game.
This new crafting mechanic is based on the item stacking. The player must construct a stack of items in a particular sequence and then feed that to an Assembler which will craft a new product from the stack.
In devlog #19, I showed off two new storage buildings that I added to the game. The Chest is able to receive and send items via connected conveyor belts, making it easy to create in-line buffers of items:
The Hopper is a building that can stack on top of other buildings, dropping items into them one at a time.
In October, I finally started working on some of the progression systems that will allow the player to discover and unlock new technologies. The Caches are structures scattered around the world, each containing the cartridge for a new building or recipe. However, in order to open the cache, the player must collect and provide the requested resources to the lock(s) surrounding the Cache.
Once a cartridge has been collected from a Cache, it must be decrypted. For this, I added a new Decrypter building at the center of the starting island. This structure allows players to decrypt cartridges retrieved from Caches to unlock new buildings or recipes.
You can read more about the progression mechanic in devlog #20 and devlog #21.
That brings us to the end of 2023! It’s been a busy year, and the game has evolved significantly during this time. I attempted to highlight most of the significant and exciting new features, but there were numerous other tweaks and changes that I omitted.
While there’s still a long journey ahead, seeing everything I achieved in 2023 fills me with immense excitement for 2024 and the ongoing development of Automation Station.
I want to express a huge thanks to everyone who has been following along on this journey, especially those of you in our Discord server who consistently provide feedback and assist me in addressing design problems. The level of support I’ve received has heightened my motivation to get this game to the finish line.
Happy holidays and I look forward to seeing you all in 2024!
❤️ -Scott
]]>In the previous devlog (devlog #20), I introduced the new decryption mechanic. To recap, Caches scattered throughout the world require specific resources to unlock. Upon unlocking, an encrypted cartridge can be obtained, which requires a visit to a Decrypter for decryption. Once completed, a new building schematic or recipe is revealed.
Overall, I think this progression mechanic has a lot of potential. The game loop of discovering caches, collecting and crafting items to unlock them, and speculating about the contents of the cartridge is fun and rewarding. It also eliminates the need for a traditional tech tree, allowing players to carve their unique path through the game’s technologies.
However, there were still a lot of details to figure out regarding how this whole process looks and feels. How does the player track the decryption process? How do they know what they unlocked? I set out to answer these questions.
The most obvious missing piece was some amount of UI that told the player how far along the decryption was and what they unlocked when complete. My first attempt looked like this:
There is a lot to unpack in this gif. As a cartridge is placed in the Decrypter, a progress bar appears in the top left of the screen. Normally, it won’t fill up quite so fast, so this serves as a way to track the progress of the decryption. Once completed, it flashes, signaling the opportunity to claim the new unlock by clicking on the UI.
There is a new set of shortcuts in the top right of the screen for navigation ease, especially for new players. Once a new building is unlocked, small notification bubbles will appear on the build mode shortcut and the newly unlocked building in the build mode toolbar.
While I was reasonably happy with how this was looking, I knew there were some problems with it. I asked for feedback from a friend who highlight a number of potential issues with the design.
The first problem was how the decryption progress bar felt awkward and inconsistent with the rest of the game. Generally, I opt for more diegetic and physical interactions instead of relying on UI. A great example of this is how the player has to physically slot a cartridge in the Decrypter to kick off the decryption instead of opening a menu. However, once the cartridge was slotted, it suddenly requires the player to watch and interact with a piece of UI in the top left of the screen. This is awkward and feels unnecessary. I originally did this for convenience so the player could claim an unlock from anywhere on the map. But because the player has to be there to physically slot in the next cartridge, I don’t think this is an important part of the design.
The second piece of feedback was how the progress bar being visible at all times added a sense of urgency. When players can see the progress like this, they might be incentivized to minimize downtime on the Decrypter by being ready to immediately claim and slot the next cartridge. But this feeling of urgency is completely at odds with the cozy vibes that I’m hoping to give to players. Looking back on this now, I also think the UI is distracting, pulling your attention even when it’s not finished.
The final piece of feedback was on the claim step. Once the decryption is finished, the player needs to claim the new unlock. But when they do so, very little changes on screen. This feels very anticlimactic, especially when this is supposed to be the player’s reward for successfully unlocking and decrypting the cartridge.
Now you might be wondering why have the claim step at all. It would work perfectly fine for the new building to be unlocked as soon as the decryption is complete. However, I was worried that players might miss or dismiss a new unlock without the explicit step of needing to claim it. I also think it feels more impactful when you have to manually click a button to get the reward. To double-check my instincts, I put out a poll on the game’s Discord. The overwhelming majority said they preferred manually claiming new unlocks, so I think the problem was in my execution of the claim step.
Based on this feedback, I iterated on the UI and flow until I came up with a second version that I was much happier with. Here is how it looks:
My fix for the awkward and inconsistent progress bar was to simply remove it. There is already a progress bar on the Decrypter itself, so players can still see how far along it is. I also added a little notification that appears when the decryption is complete, so that players don’t have to constantly check progress. However, instead of claiming the unlock in the UI, you now have to click on the glowing cartridge instead.
As you can see, the claim step was completely redone. This time with a lot more particle effects 😁. There is also a pop-up that tells you exactly what you unlocked right at the center of your screen where you can’t miss it.
What are your thoughts on this version of the decryption mechanic? Does it feel like an improvement, or are there further adjustments needed? Share your feedback in the comments below or on Discord.
While the majority of the sprint was spent on the decryption feature, I also worked on some other behind-the-scenes features that I have been wanting to add for some time. This section will be a bit more technical, so feel free to skip if you aren’t interested in the programming-focused aspects of the game’s development.
Up until recently, the game has been much closer to a creative sandbox game. All of the buildings used to be unlocked immediately, and I could just start building whatever I wanted. But with the new addition of the Decrypter, there is now a process to unlocking buildings. That means that when I want to test out something, I first need to unlock the required buildings. This becomes quite tedious when I want to make a quick code change and test it out.
Now, I could just hack in a keyboard shortcut to unlock all buildings with a single keypress. In fact, that is what I did at first. But, over the game’s development, I’ve added so many of these that I’m starting to forget what key does what. This solution simply doesn’t scale well.
Ideally, all of these keyboard shortcuts would instead have corresponding settings and buttons in some kind of debug UI that I could easily open and browse in the game. But if you’ve worked on any kind of UI before, you know that adding UI is almost never easy, and definitely not for me.
Despite that, I realized that I really should spend some time to create a little debug menu instead of adding yet-another-shortcut. In the process of doing so, I realized that I was doing a lot of similar steps. For each debug setting I wanted to add, I would create either a checkbox, slider, textbox, or button and then wire it up to the piece of data I wanted it to. Once I see that kind of repetition, the programmer and automation-game-player in me instantly wants to try and figure out how to automate it.
So… that’s what I did. Now this may not seem like the highest priority feature to spend my time on, and you’d be right. But I had a lot of fun conquering this programming puzzle, and I think the final result will actually save me a lot of time in the long run.
Here is what the debug menu looks like:
As you can see, the debug menu automatically updates to reflect the game. Meanwhile, I can interact with the menu to update the game. The data is synced in both directions automatically.
I realize that this doesn’t look like much, but the magic is how it was created. To add the “Tick Progress” slider, I simply added a few C# attributes to the existing game component that stores the current tick progress. Here is what the code looks like:
public struct Clock : IComponentData
{
public double ElapsedTicks;
public float DeltaTick;
[DebugMenu]
[Category("Clock")]
[MinMaxSlider(0, 1)]
[ReadOnly]
public float TickProgress
{
get
{
float fraction = (float)math.frac(ElapsedTicks);
return fraction > 0 ? fraction : 1.0f;
}
}
}
For the tick rate buttons, I have the following:
public struct DebugSettings : IComponentData
{
[DebugMenu]
[Category("Clock")]
public ButtonEvent SpeedUpTick;
[DebugMenu]
[Category("Clock")]
public ButtonEvent SlowDownTick;
}
The only thing I had to do was add the attributes like [DebugMenu]
and [Category("Clock")]
. The rest of the stuff was already there for existing game systems. It is extremely easy to add new stuff to the debug menu which means there is a half-decent chance I’ll actually use it instead of resorting to print statements while debugging.
After I had the debug menu working, I was able to easily add another debug feature using the same system. Essentially, I can now hover any object in the game and pull up data on the object, such as its position, facing, altitude, etc. This can be extended by simply adding an attribute to any component type I want. I think this will be invaluable when I’m trying to debug something that is only happening in a build where I can’t use my normal editor-only debugging tools.
If you are working on your own ECS project and think this would be useful, please let me know. If there is enough interest, I’ll open source the code for this debug menu system.
A common programming challenge is figuring out how to design a system that is flexible in all the ways you want it, without being overengineered and cumbersome. My latest example of this was the slot restriction system.
Consider the crucible and the hopper. Both buildings have a slot that can hold items. The crucible is only able to smelt stuff like raw ore, so it makes sense to limit the slot to only smeltable things and prevent all other items from entering. Meanwhile, the hopper can accept any type of item, but upon recieving one, it can only accept more items of the same type. Both are examples of places where I want to restrict the item slot.
In a more object-oriented programming project, you could imagine making the crucible and hopper both inherit from some kind of “slottable” class or interface. Then each building could override the behavior for checking if an incoming item is valid. This could work great, but it isn’t really compatible with the data-oriented design philosophy. Automation Station is built on Unity’s Data-oriented Tech Stack (or DOTS) and Entity Component System (ECS), which treats “objects” as purely data associated with a given entity ID. All of the logic happens inside of systems which aren’t tied to any particular objects.
So how can I represent slot restrictions as data?
My solution up until now has been to populate a list of valid item types for each building. This could be changed at runtime so that, for example, the hopper can restrict its slot only after it receives its first item.
To support the crucible, I had to provide a list of all of the smeltable items types in the game. This may not seem like a problem, but I routinely would forget to update this list when I added a new ore or smeltable resource. Also, if I ever add mod support to the game, I would need a way to detect all of the new ores added by mods and ensure that they can all work with the crucible.
Ideally, I would just specify that the crucible accepts all items that are smeltable. But how do I know what items are smeltable?
ECS allows items to have empty components on them which serve as a way to tag a group of entities that have some common property. However, there isn’t an easy way to store a list of those types since types aren’t really the same thing as data.
(For any ECS experts reading, it is possible to store a list of component type indices, but these are not deterministic across builds. I also found this method to be a lot more complicated than my solution below)
My solution was to create something I’m calling a “Trait”. Items have a list of all of their traits, defining their characteristics. Meanwhile, a building could store a list of required traits for items in its slot. Thus, all ores have the Smeltable trait and the Crucible only allows items with the Smeltable trait.
So how is a trait represented as data? Internally, I use something called a GUID, or Globally Unique Identifier, for each trait. This is just a 128-bit number that can uniquely identify something. Thus, each trait has a unique GUID. These are generated at random when I need a new trait. It turns out that 128 bits are enough that the probability of randomly generating two identical GUIDs is effectively zero. Even if the player added thousands of mods, each adding a bunch of traits, there would be virtually no chance that there are any duplicate GUIDs.
Addtionally, I create GUIDs for each type of item. That way I can restrict the hopper slot to one specific type of item. With all that in place, I now have a simple and flexible way to solve my slot restriction problem. I can also leverage traits for other gameplay systems.
That’s all for this devlog! Thanks for making it this far and hopefully I didn’t bore you with all the technical details. In the next sprint, I will be continuing to work on the progression mechanics including island unlocking, so stay tuned for the next devlog!
Here are all the significant changes since the last devlog:
Hope you all have a great week!
-Scott
]]>As you explore your starting island, you can now stumble upon mysterious Caches.
These enigmatic structures are scattered throughout your world, each guarding precious encrypted cartridges. To gain access to these cartridges, you’ll need to deliver specific items to the locks adjacent to the Cache. Each lock requires different items to open. At the start of the game, one of the first Caches you encounter only requires raw stone, which is easily mineable from a nearby stone ore node. Once you deliver enough stone to the Cache lock, it will unlock, revealing an encrypted cartridge inside.
Each lock displays a hologram indicating the required item. Hovering over the hologram provides a tooltip showing what needs to be delivered. As you provide the required items, the circular progress bar on the lock fills up, tracking your progress. As you advance further in the game, Caches will feature multiple locks, some of which require items that need to be smelted, refined, or crafted in your factory.
This design accommodates up to three locks on a single Cache, which is currently the maximum I’m planning. However, as the game progresses, each lock might require hundreds of items to unlock, encouraging automated production and delivery.
The design of the cartridge draws inspiration from a particular classic retro video game console. While I’m undecided on whether to keep this design or opt for something more unique, I believe a video game cartridge is a fun way to convey the presence of information hidden inside.
Once you’ve successfully unlocked a Cache, you’ll discover an encrypted cartridge inside. To unveil its secrets, you’ll need to take it to the Decrypter. I’m still fine-tuning the design of this building, but here’s a sneak peek:
Delivering a cartridge to the Decrypter initiates the decryption process. This will take some time, and you can track its progress by observing the loading bar on the sides.
I’ve attempted to create a sci-fi visual effect for when the cartridges are being decrypted. While I’m still relatively new to VFX, I’m reasonably happy with this initial attempt.
The missing piece in the decryption progress is actually unlocking the new building or recipe. Although I wasn’t able to address this in this update, the plan is to include a notification popup in the UI explaining what was unlocked, as well as some visual indication in the build menu of what was recently unlocked.
One lingering design question for the Decrypter is how players will initially gain access to it. Given that cartridges control all building and recipe unlocks, I’ll likely need to provide it to the player at the start of the game. One possibility is integrating it into a larger HUB structure where the player would initially spawn and possibly provide other utilities, such as manual crafting and early power generation. However, I plan to address this at a later stage, so for now, a single Decrypter will spawn at the center of the world when the game begins.
Since each Cache lock requires different items, I needed a way to communicate this to the player. While tooltips are helpful, I believe they shouldn’t be the sole method of providing this information. My solution was to make each lock display a hologram of the item type they require. To be effective, it’s important that these holograms are clear and easily distinguishable.
My first attempt at a hologram shader featured a more traditional hologram effect that was partially transparent and included glitchy animated “lines” scrolling across:
However, this design appeared quite noisy and cluttered. I then experimented with a clear blue effect:
While I found this design visually appealing, it looked more like clear blue plastic than a hologram. I decided to reintroduce some glitches and scrolling lines:
This change negatively impacted visibility, so I realized it wasn’t the right solution. To enhance readability, I returned to the initial design that used item colors instead of blue, but this time I removed the scrolling lines.
This approach worked better, but I noticed another issue: the partially transparent items added visual noise by revealing the internals and backs of the items. Instead of true transparency, I tried a dither transparency effect, a common technique used in video games to avoid the performance impact of “real” transparency. This approach also exclusively showed the front of the item in the hologram.
This version made it much easier to discern the items, as they closely resemble the real items in the game. But at the same time, the dither effect, combined with the glitchy jitter, make the holograms feel less like physical objects in the world, which helps sell the effect.
Here is a still image of the holograms:
While I may still adjust the colors and lighting on these holograms, I’m very pleased with the final result. I’d love to hear your thoughts and suggestions for improving the hologram shader!
Behind the scenes, I’ve made significant updates to support these new systems. In addition to the shader itself, I’ve implemented a new system for generating holograms of every item in the game. I’ve also expanded world generation to spawn Caches and Decrypters, which required adding support for multi-tile structures like the cache.
Furthermore, I’ve updated to a new version of Unity and updated all the packages I depend on, providing access to bug fixes and new engine features. I’ve also fixed up the automated build pipeline to ensure a smooth development process.
With the Cache and Decrypter systems in place, I finally have the required pieces to add some proper progression to the game. One of the next tasks on my agenda is to implement building unlocking, expanding the building menu to include the building only after you have decrypted the required cartridge. However, there’s still much to be done in terms of progression. I plan to implement a similar item requirement system for the pylons that unlock new islands. Stay tuned for more information in the upcoming devlogs!
Here are all the significant changes since the last devlog:
Thank you for your continued support and enthusiasm for Automation Station. Have a great weekend!
-Scott
]]>First up is the Chest. The chest can currently store up to 10 items of the same type, although I expect to increase that number based on playtesting. The chest features a belt input and output port, allowing you to connect conveyor belts directly to it. As items enter the chest, they will pass through the chest and exit onto any output belt if there is one and there is room. If the item cannot be sent to the output, it will be stored inside the chest, appearing in the top slot. As more items enter the chest, the circular indicator will fill up to show how full it is. Likewise, whenever items leave the chest, the indicator will lower accordingly. The item in the top slot will drop down to the output belt when the chest is sending its last item.
Here is what it looks like in the game:
The top slot serves as a visual indication of what is currently being stored in the chest. This avoids the need for any kind of UI pop-up or overlay. However, the top slot also functions as an alternative input for the chest. If an item of the correct type falls into the top slot of the chest, the chest will quickly store the existing item in the top slot to make room for the new addition.
The player is also able to manually store and retrieve items in the chest. While holding the correct type of item, the player can simply click to add one item to the chest. They can also click and hold to fill up the chest with items from the player’s inventory. If the player’s hands are empty, clicking the top item or the chest will remove one item. Similarly, clicking and holding will remove all items from the chest (or until the player’s inventory is full).
The other storage building I implemented is the Hopper. Just like the chest, the hopper can also store up to 10 items of the same type. However, instead of belt input and output ports, the hopper has a port on the bottom that allows items to drop down to buildings below. For this to work, the hopper must be placed on top of other buildings. Here are some examples:
The hopper is mostly intended as a way to add an inventory to the input side of a building before having it completely automated with conveyor belts. For example, you could place a bunch of ore in a hopper on top of a crucible to effectively queue up several ingots to be smelted. But just like the chest, the hopper’s top slot doubles as an input for receiving items. Due to the height of the hopper and the fact that it is typically stacked on top of another building, it can be a little tricky to get items up to the required height to drop them into the top slot. But given the intended use case, I think this is an okay tradeoff.
And, just like the chest, the hopper can be loaded or emptied manually with the same interactions.
You might be wondering why there are two item storage buildings. Both the chest and hopper can receive and output items, albeit in slightly different ways, and store 10 items internally. This overlap in design isn’t inherently bad, as it gives the player more options. However, it can also be a little confusing and misleading. For example, if the player wants to store some crafted items at the end of an assembly line, they might try to use the hopper. While this works, it is more awkward to use for receiving items due to the height of the top slot. Alternatively, if the player wants to queue up a bunch of iron ore to be smelted, they could use a chest and a ramp to deliver some ore to a crucible, but it is much more straightforward to place a hopper directly on top of the crucible.
Initially, I only wanted one item storage building. However, I struggled to come up with a single design that met all of my design goals. I wanted a storage solution that could be used in the early game to enable smelting in batches rather than one at a time. In terms of progression, it would be ideal if the storage building didn’t require the use of conveyor belts. This is where the idea of the stackable hopper came from. But I also wanted a storage building to collect items at the end of some production chain, so a design like the chest made more sense.
One possibility is to tweak the functionality of the hopper and chest so that they no longer overlap. Perhaps the hopper cannot receive items into the top slot in an automated fashion. This would make it only useful as an input inventory that has to be filled manually. And perhaps the chest can only receive items, requiring the player to manually retrieve them when needed.
After implementing the chest, I realized that it is essentially identical to a normal conveyor belt, just with the extra ability to store items. Any time you would normally use a straight conveyor belt, you could instead use a chest without any real downsides. In fact, I can imagine that some players using chests everywhere in place of belts as a way to add buffers to their production chains.
This could be seen as an advanced feature, but it feels at odds with the design of Automation Station thus far. All of the buildings are modular primitives that are intended to be combined in different ways. The fun of the game is figuring out how to combine these primitives to solve a goal. The chest design I’ve shown is basically a combination of a belt and a storage chest. It feels like it is doing too much, especially when half of it (the belt) already exists as another building in the game.
When I’ve encountered similar design problems in the past, I’ve always found a solution by breaking up the idea into more modular pieces. For example, instead of a furnace, there is a crucible and heater as separate buildings. (There even used to be something called a “caster” that would handle resolidifying the molten metal into an ingot).
Applying this to the chest, the obvious solution would be to separate the storage component from the belt. In-game, this could mean that the storage is an attachment that you place on top of a belt. Functionally, this would behave the same way as the original chest design, but it requires the player to choose and place the storage according to their needs. And the player could also add this storage module to other buildings that it is compatible with, increasing the possibility space.
This idea of a separate storage module is pretty similar to the hopper design. A hopper can be placed on top of a belt and get most of the functionality of a belt-chest. Although, at the moment, the hopper cannot suck up items from the belt into its storage, it can only output items. This has me wondering if there could be something like the reverse of a hopper that sucks up all items beneath it. Or perhaps there is a way to flip a hopper upside down to toggle it to “input mode”.
One of the subtle differences between the hopper and the chest is that the hopper’s indicator doesn’t account for the item in the top slot. This is because I wanted the indicator to represent the items inside the hopper, not any outside, such as the item in the top slot. At first, the chest indicator also worked this way, but I realized that with the chest receiving items either from the input or the top slot, it was a bit confusing. Thus, the chest’s indicator accounts for all items in on on the chest.
At the moment, I still prefer the hopper’s indicator design. It doesn’t feel like the item on top should be occupying any space inside the hopper. But I also don’t like that the chest and hopper have inconsistent indicators. Perhaps there is another way to solve the visibility problem of items passing through empty chests. Or I can just make both function like the chest indicator.
As you can probably tell from all the design considerations above, I think there is still a lot to figure out when it comes to item storage. For now, I have two options fully implemented that I’m reasonably happy with. Based on feedback from you lovely readers and playtesters, I’ll evaluate what changes need to be made and perhaps cut or consolidate the available item storage buildings. Let me know in the comments below or in Discord if you have thoughts about item storage or feedback on the new hopper and chest.
Besides item storage buildings, one of the other new additions in the last couple of weeks are Platforms. Platforms are a new basic building block that allow you to position your other buildings at specific heights. Most buildings can be placed on top of platforms, including other platforms. This is incredibly useful in combination with ramps to get items up high, such as the top of a hopper.
I’m not totally sure if platforms will stay in the game in the current form. One of the cool puzzle aspects of Automation Station is figuring out how to place things around the terrain to leverage existing cliffs. The addition of platforms completely removes that challenge. However, I do find them incredibly useful for debugging certain features, so I’ve gone ahead and added them for now.
The hopper and chest both required a lot of work throughout the rest of the codebase to support their functionality. For example, I had to refactor the entire item routing system (again) to allow the hopper to drop items directly below it. Due to the complexity and interplay of all the game’s systems, these small changes take a lot of time and careful thought to get right. Below is the full list of the notable changes from the last two weeks.
Here are all the changes since the last devlog:
As always, thanks for taking the time to read this devlog! My next big task will be tackling progression systems in an effort to turn this bag of systems into an actual game. Stay tuned for another devlog in a couple of weeks!
-Scott
]]>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.
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?
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.
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.
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.
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!
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.
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.
Here are all the changes since the last devlog:
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
]]>I’ve spent the last couple of weeks iterating on the new item stacking mechanic that I showed off in the last devlog. While there isn’t a ton of new features to show off, there are a lot of interesting design details to cover. I also wanted to give an inside look at my design process for the Stacker. Let’s get into it!
I showed a version of the Stacker in the last devlog that was able to stack items. Here is how it worked:
The player is able to drop all of the items into the top of it and, once full, the stacker will output the final stack. I think the idea of filling a tube actually works really well for stacking and generally feels intuitive.
So what was wrong with this design? As you can see in the gif above, the resulting stack is not always the same. It relies on the order in which the items enter the tube. Unfortunately, because the items must enter the top of the tube, all of the conveyor belts sending items are competing to send their item to the same space. The game resolves this by having the senders take turns, but this is mechanic is not very intuitive and it is difficult to fully master. But let’s say that they do figure out to make the inputs take turns in the right order. If one of the conveyors happen to run out of items, there is nothing stopping the other conveyors from sending multiple items to the stacker. The player could address this by ordering all of the items on a single input belt, but that is not a simple task either.
In other words, if the player wants a specific order of 3 items (which is important for future crafting plans), there is no easy way to guarantee that with this design. So back to the drawing board we go…
As I mentioned in the last devlog, the original plan for item stacking was that it wouldn’t require a special building. Instead, stacks could be formed by simply dropping items on top of each other. This could be done by dropping items from cliffs or launching them with a Launcher.
I still think this idea is pretty cool, but it has some serious drawbacks. Firstly, this would lead to items accidentally stacking all of the place. Any time a conveyor backed up with items, other items might start dropping from cliffs onto occupied conveyors and forming stacks. Luckily, down ramps can help here for avoiding cliff drops, but not for launchers. A launcher would always stack if the destination was occupied.
The other issue with the design is that there is no easy way to guarantee a specific stack of items. At least compared to the tube design, this is a bit easier since the stack can be formed gradually: a cliff could drop one item on top and then later another cliff can drop a third item on top of the other two. We no longer have to rely on weird tie-breaking behavior, however, there is nothing stopping the items from continuing on if there happens to not be an item ready to drop onto it.
To summarize, with this design if conveyors back up we get accidental stacking, and if conveyors run low on items we get incomplete or incorrect stacks. Doesn’t sound very fun to new players at the start of the game.
In effort to fix these problems, I spent many days talking to a bunch of folks on the Discord and brainstorming new ideas. A lot of different ideas were proposed but I’ll mention a few of them:
This is similar to the tube design, but items enter at the bottom via a conveyor belt, pushing any existing items in the stacker up. Once full, it outputs the stack. The main advantage to this design is that it avoids weird tie-breaking scenarios since only one input conveyor can be connected at a time. However, it now forces the player to order the items going into the stacker in reverse which is counter intuitive. Also, the game doesn’t provide any tools to easily and consistently order items on a belt.
The slot ladder mproves on the tube design in a couple of ways. Firstly, items can enter at different heights wihch will correspond to their position in the final stack. Also, items don’t drop to the bottom of the stacker, so items entering at a given height will always be in that position in the stack. This idea had a lot of potential, but the center slot was awkward to use and items would clip through the supports.
This is basically the same idea as the slot ladder, but using some kind of tractor beam visual instead of discrete slots. While cool looking, it isn’t clear how many items it can hold or which slots are empty.
The welder is inspired by Infinifactory’s building by the same name. Each welder is aimed at a space in front of it. Any item passing through this space will be held in place. The player would be able to stack multiple welders on top of each other and they would connect up. Once all connected welders have an item, they would “weld” them together into a stack and release it. Functionally, its mostly identical to the slot ladder and tractor beam ideas, except the structure of the welders are on an adjacent tile to where the items are being stacked.
There are currently no arms in Automation Station, but there could be arms designed specifically for stacking. They would be able to pick up items from conveyor belts and then hold the item at a given height. Combinining multiple of these arms would allow the player to create a stack. The main problem with this idea is that it is unclear how the player would avoid outputting a partial stack too early if the bottom arm(s) already had their item but the top arm did not.
The “transposer” was a super cool suggestion from a member of the Discord. The basic ideas was that this building would be able to pick up multiple items from a horizontal row of hex tiles at once. Then it would “transpose” those items into a vertical stack of items and output that. The main issue with this idea was that it required the stacker to be a large multi-tile building, which doesn’t play nicely with the pushing mechanics in the game. It also didn’t really feel like the items were being “stacked” since the height of the inputs didn’t matter.
The black box was a suggestion to address some of the art issues I was facing with the stacker designs. As the name suggests, the idea was to make the stacker more of a black box. Inputs would be added to the input ports and the final stack would come out the other side. Functionally, it would be similar to the slot ladder, but would require the inputs to be received from specific input directions rather than any direction.
In general, I’ve been opting for more open designs that clearly communicate the state of the building. Functionally, this idea would work great, but it would be difficult to see what is inside the stacker.
After several days of brainstorming, I was still having trouble coming up with an idea that I was completely happy about. A common issue was that I would figure some behavior for the stacker that I liked, but couldn’t come up with a good visual design for it that was intuitive and fit in with the rest of the game’s visuals. It was around this time that a Discord member suggested that I formalize the requirements for the stacker. That way we could evaluate the designs against these requirements to figure out which one is best.
Here are the requirements I came up with:
With these new set of requirements, I was able to figure out which ideas had the most potential. The “slot ladder” and “tractor beam” both offered the exact gameplay experience I was looking for. The player will be able to build a reliable stacking setup where the heights of the inputs directly corresponds to the heights of the items in the stack. And there was a natural way to block a partial stack from leaving by containing in some kind of structure. However, I still wasn’t really sold on the visual design of either. The slot ladder was funky to use, especially when items were side-loaded into the middle slot. And the tractor beam was a cool aesthetic, but it wasn’t obvious how many slots it had or which slots were empty.
I iterated on this idea further and eventually came up with this design.
It is basically an evolution of the slot ladder, but it removes the middle slots. Instead, there is only a top slot. There are currently two version of the stacker, the short 2-item stack and the tall stacker designed for 3 items. In order to make a stack of three items, you chain together the short and tall stacker like so:
However, it is also possible to only use the short stacker if you send a stack to the top slot.
As a result, I thought about removing the tall stacker entirely, but I think the tall stacker is more intuitve to new players. This will be one of things I’ll evaluate in a future playtests.
Looking back at the design requirements, this design seems to satisfy all of them. The player can easily stack two items and three isn’t too much more difficult. Stacking is entirely opt-in. Once constructed, a given stacking setup is 100% reliable regardless of input rates. It is easy to see what is currently inside the stacker and what it is waiting for. And finally, it relies on physically adding the inputs at different heights, which helps the player feel like they are stacking. Awesome!
However, I’m still not totally happy with the stacker’s visual design. I think it needs to be a bit bulkier and more visible when zoomed out. But I think it is a great starting place to start gathering feedback on the stacking mechanic. I’d love to hear your thoughts or if you have other suggestions for how the stacking could work.
While iterating on the stacker, I realized that I would need to adjust the sizes of items in the game. The current item size was problematic for stacking as the items didn’t match the height of the conveyor belts or cliffs. That meant that if a conveyor belt had an item that it was trying to add to the top of the stacker, it was unclear how high the conveyor belt needed to be. There were similar problems with the height requirements for dropping items into the crucible and burner.
Since the items were already pretty close to the height of a cliff, I first tried making the items a little bigger to match the height exactly. That way a conveyor belt on a cliff is exactly high enough to stack an item on top of an item below it on another conveyor belt. Here is what the larger items look like:
I didn’t mind the size of a single large item, but a stack of items could cover large parts of the screen, blocking parts of the factory. There were also clipping issues when stacks when up and down ramps.
Then I tried making the items small enough to match the height of a conveyor belt (which is half the height of a cliff). What’s nice about this size is that cliffs could also be made shorter, making everything (conveyors, items, and cliffs) all the same height, creating a sort of height standard for the game. Here is what that looks like:
As you can see, there are no longer problems with items covering up too much of the screen nor clipping issues. However, I personally felt like the items were way too small for the belts. I’m sure a big part of it is how used to the old size I had become, but it still feels very disproportioned even after playtesting it for a week.
I wasn’t until the very end of last week that I remembered that I already had a shorter item in the game: the stator. The stator is going to be an intermediate item used for crafting motors and other gadgets. All of the other items in the game were roughly similar in height, but the stator model was shorter, almost exactly matching the height of a conveyor. So I tried seeing what it looked like to stack the stators. Here is the result:
When I saw this, I was immediately sold on it. The items felt sufficiently big, and they looked great when stacked, and, in my opinion, much better than a stack of round items that I had been testing out earlier. And if all items were of a similar shape, I could have a much more intuitive height system in the game where conveyors and items are both 1 “unit” high. Yay! 🎉
The shape of these items reminded me of a suggestion my friend had for item stacking: burgers 🍔. I quickly modeled some buns and a (vegan) patty and threw them in the game. I also had to temporarily change iron, copper, and coal nodes to give burger parts instead of the usual ore. Here is the result:
No idea if burgers will remain in the game, but I think they do a good job of showing what stacking will look like and what is possible.
There were a smaller set of changes this sprint as it was mostly focused design, but here is the changelog:
That’s all for this devlog! I just want to give a huge thanks to those of you that were willing to chat about stackers and item sizes for hours on Discord. Its really nice to have people to help me get unstuck on a design issue, espcially as a solo-developer. If you are interesting in joining in on these design discussions, feel free to join our Discord using the link below. Thanks for reading!
-Scott
]]>I’m back with another devlog full of juicy new features for Automation Station. This time we have three new buildings added to the game: the Stacker, the Swapper, and the Reverser. There is a lot to unpack here so let’s get to it!
The Stacker is a building that, like its name suggests, can stack items. Items can be dropped into it from above and it will start forming a stack of items. Once the stack height is reached (currently 3 items), the Stacker will output the completed item stack along its output conveyor belt. The model is still a work-in-progress and its missing an animation for the door opening, but here is what the Stacker currently looks like:
As I briefly mentioned in the last devlog, the primary use case for item stacking is related to crafting. Certain crafting recipes will require a stack of items in a specific order as input. For example, making circuit boards might require stacking a silicon board at the bottom with copper wire on top and a transistor on top of that, and then providing this stack to an assembly machine to produce the circuit board. There is a bit of a puzzle element in forming these stacks in the right order, which should make each recipe an interesting challenge.
In addition to crafting, item stacks can be used to increase the throughput of conveyor belts. Instead of only transporting a single item per tick, if the items are stacked, the conveyor can transport three items per tick. This can be used to combine three resource lines into one high-throughput line. At the moment, there is no way to unstack the items in a stack, but that will be coming in a future update.
My initial plan for item stacking actually did not require a special Stacker building. Instead, items could just be dropped on top of each other anywhere. That meant that any time an item was dropped from a cliff or a launcher, it could land on another item and form a stack, up to some height limit. However, after discussing it with some of you on Discord, we decided that this would lead to a lot of accidental stacking and the arbitrary stack height limit felt awkward. The dedicated Stacker gives the player a lot more control and the height of the building gives some clue as to the stack height.
Next up is the Swapper. The Swapper is relatively simple machine that can swap the locations of two adjacent buildings. This is yet another tool that the player can use to create various contraptions, including splitters and mergers.
Combined with Conveyors, Pistons, Rotators, and Orbiters, I think the Swapper opens up the door for some really cool and interesting builds. I’m excited to see what players come up with!
The Reverser is a building that reverses the polarity of the building in front of it. Placing a reverser next to a conveyor belt will reverse the direction of the belt. Reversing an orbiter or rotator will reverse the direction of the spin.
If you have been following the development of Automation Station for a while, you might recognize the Reverser building, but this one works a bit differently. The original Reverser would reverse the polarity every tick. That means that a reverser next to a belt would alternate the belt direction every tick. When I first showed it off, it was suggested to change the Reverser to work more like a temporary modifier. So instead of reversing every tick, the Reverser applies a “reversed” modifier to the building and keeps it in that reversed state so long as the Reverser is nearby. But as soon as the Reverser or its target are pushed away, the modifier is removed, restoring the original behavior of the target.
I think this new behavior is a lot more intuitive, but I’d love to hear your thoughts.
Here are all the important changes from this sprint:
That’s all for this devlog! The plan for the next sprint is to finally add support for crafting, so stay tuned for the next devlog in two weeks.
If you have any feedback on the new buildings and mechanics, feel free to leave comment below or join our Discord server. Thanks for reading and have a great weekend!
-Scott
]]>