Devlog #12: Launching & Item Routing

Hi folks! It’s been another two weeks so I’ve got a fresh new set of changes to share with y’all!

The theme of this sprint was Launching & Item Routing. I started off by re-adding the Launcher building that can launch items into slots further away. If you’re familiar with Factorio, you can think of these like an underground belt, but instead of going underground, they launch items through the air! You can use them to cross two belts without them interfering with each other. But you can also use them to launch items up cliffs, into machines, or to other islands.

I first introduced launchers to the game back in October. However, since the introduction of the build mode and other large refactoring efforts, most of the buildings have been broken. When re-adding the launcher, I took this opportunity to improve how they function as well as fix some bugs. The main change is that launchers are now able to launch without any recharge delay. That means that if you have a full conveyor belt of items going to a launcher, it will be able to keep up and launch every one of them without delay.

One of my main gripes with launchers when I first added them was that they required an empty slot to launch into, even if that slot was about to be empty. This was simply because launchers were being updated before conveyor belts. I could reverse the order to update launchers after conveyor belts, but that would mean that the launcher would not be able to receive a new item while launching its current item. Basically, there was this dependency problem where launchers and conveyors both were dependent on the output of the other.

This is a tricky problem to solve as it requires maintaining a graph of dependencies between all of the item transfers that are happening across all the different building types. I’ve known about this problem for a while now and decided that it was finally time to fix it once and for all. After many days of head scratching, I wrote a brand new Item Router system that can resolve these kinds of dependency chains. It can even handle cycles, such as when you have a loop of conveyor belts and launchers, all full of items.

With the new Item Router, I was able to easily add some new functionality to the Mining Drill so that it ejects ore when mining is complete. This avoids needing something like an arm or inserter to transfer the ore out of mining drills.

I’m also debating making it so mining drills poop ore on the ground if there is nothing to receive the completed ore. This might just prove to be annoying, but I do think it would be cool to come back to a drill and see a mountain of ore around it. I’d love to hear your thoughts on this!

An a similar note, I made it so that the Crucible now produces the metal ingots on the adjacent tile. It looks a little strange right now, but the crucible will eventually be animated so that it looks like it is pouring the molten metal out to form the ingot. I’m also considering making this pour the ingot on the ground if nothing is there to catch it.

By making the crucible pour like, it opens up a lot of cool gameplay opportunities that I plan to explore in the future. For example, perhaps there is a way to pour the molten metal directly into a gear-shaped casting mold to more efficiently craft iron gears. Or maybe you could have two crucibles pour into an “alloyer” that is able to create new metal alloys. I think it would also be cool to pour the molten metal into a pipe to take it somewhere else in your factory. These are just ideas at this point, but its fun to consider the possibilities.

Now that mining drills and crucibles can eject their outputs, I still needed a way to get items into machines, such as getting coal into a burner or ore into a crucible. I’ve been on the fence about adding arms or inserters to the game as they trivialize parts of the puzzle-like gameplay. So in the meantime, I decided to make it so that items could be dropped into slots from above. Now you can deliver iron ore to your crucible by dropping it from a conveyor belt up on a cliff. You can also use launchers to launch items directly into the slot.

Overall, I’m considering leaning more into elevation height as a gameplay mechanic. I think there are a lot of interesting possibilities to explore. Let me know if you have some cool ideas for height-based gameplay!

The last thing I worked on this sprint was reworking the game clock. Previously, if the FPS dropped significantly for whatever reason, it was possible that systems would update in an invalid order, resulting in all sorts of weird behavior. With the new clock system, I ensure a very specific order of systems. As a side effect of this change, I can now slow down or speed up the tick rate without the animations glitching out. I’m thinking of adding these time controls as a slider in the UI as it is quite useful for debugging your contraptions.

Alright, that’s all for this update! As promised, I’ll be creating a thread below so that you can share your feedback and comments. Hope you all have a great weekend!

Changelog:

• Simplified item slot transfer
• Simplified item pickup and placement
• Re-added launcher building
• Rewrote launcher system
• Removed recharge delay from launcher
• Launchers now launch to correct position while being moved or rotated
• Remove statefulness from item slots
• Merge all world generation settings into a single asset to make it easier to switch between world presets.
• Created a brand new item routing system that works for all item transfers, not just conveyors.
• Reorganized tick systems into well-defined groups (move, propose, accept, send, receive, etc.)
• Created Depositor capability for depositing items into adjacent slots
• Add Depositor capability to Mining Drill to deposit items when complete
• Crucible now pours out molten metal into adjacent slot (animation still needed)
• Items can now be dropped from a higher elevation into anything with a slot
• New clock system to ensure that tick and tock updates happen in an alternating fashion when fps drops significantly
• Increasing or decreasing the tick duration at runtime now does so smoothly without messing up animations.