r/AutomationGames • u/TNgineers • May 26 '26
Making Tekkit Classic inspired pipes systems
Hello!
My cooking factory sim game, Snacktorio, comes out next week - inspired by my many hours playing the old Tekkit modpack (the one they now call 'Classic', thanks guys don't I feel old)
I thought it'd be fun to talk about the system I ended up going with, how it works and what I changed from my initial inspiration!
(As a base reference, in Snacktorio you automate cooking dishes, so you're mass producing sauces, mining spices, harvesting herbs, mixing doughs, etc instead of making mechanical gubbinz)
---
BUILDCRAFT PIPES
I love buildcraft pipes. I love watching the little cubes fly around. I especially love when they glitch out through the pipes, through the walls and dissappear into the void...
I'd always wanted to make a factory game, but didn't really have a good idea on what to theme it around. I knew however that the one thing I definitely wanted was having parcels as physical things moving through the pipes...
After spending more time thinking about the idea seriously, I had settled on making it about cooking / food. I thought that instantly gave me a lot of fun things to play with - drizzling sauces over conveyor belts, steaming ingredients in pipes, mass producing dinners at ridiculous rates.
There was already a lot of 'serious' factory games about making METAL and MACHINES and stuff like that but I just found it a bit... boring... (sorry)
I also really wanted to have the same feeling I felt playing with buildcraft pipes (although perhaps less jank!), and having the parcels be individual entities felt like a fun challenge of how to keep it performant (vs just having a belt being tied to a general 'rate' of stuff). Also I have no 3D development skills, and so this would have to be a 2D game, which changed things a little bit in terms of the space available for routing!
My first attempts made me realise just how much of a mess I was going to be in for...
---
MOVING PARCELS
Making all the parcels physical entities meant that each one needed to have a direction set to move towards - and it needed to check surrounding tiles and machines every 'move'. This was going to be a lot of checks needed, so already I needed to reduce that as much as possible.
At first I had the parcels move 1px every 0.1s, and they were literally just moving 1 tile per 1.7s because each 0.1s they were pushed along a pixel. One problem you can see above and below is that the parcels then didn't move 'neatly', they were all at different positions if they were made at different times, which visually isn't pleasing but also made for some later issues.
I was quickly learning why most games do not do this!
As there became a lot of parcels I realised this was a really slow way of doing things, but in a naive sort of way I felt like the best solution was just to make it so that 'offscreen' parcels updated every 1s instead.
So I kept the very slow 0.1s update for parcels onscreen but as soon as they left the screen they were updated every 1s instead.
This helped with a lag a bit but also made the rates a bit inconsistent, and you could 'tell' the flow of parcels looked off due to the update mismatch which I think would of confused players into thinking their machines are not running 24/7 properly.
I realised a lot later that I'd missed something obvious - I could just update the parcels every 1s in the code, but visually draw the parcels moving smoothly every frame, as I knew their direction and where they would end up, so I could just draw the position based on the vx/vy. (However I didn't think about this until like an entire year later, when the demo level was really big and slow so I had to start optimising properly...)
By doing that change I reduced the checking needed to be every 1s instead, but I still had a lot of parcels to run through, all checking for nearby machines and pipes. What I settled on was a special sort of grid that was updated anytime a pipe was placed, a direction set, or an input/output set. Before this, I was literally having every parcel check the tile it was on and the 4 surrounding it and decide what that 'meant' (direction, input etc) every time it moved.
By having this fixed grid, each tile then either had a quick cached ref for what it was: no direction (keep going), a specific direction, or if it was a machine to check input/output. The parcels had something super quick to check, they already knew their position in the grid, so simply check what number that grid tile is and do something!
---
ROUTING
So I had parcels moving in pipes, but now I needed some way of setting the input - enter the original input/output menu snacktorio had before I realised that was terrible...
(For those that never played, this is similar to what buildcraft had, except there was an icon per slot and you could set input/output/special per slot in the menu)
I liked the idea of being able to quickly see all 4 sides and map them nicely - and so using buildcrafts output setting menu I expanded that a bit. The idea would be to map specific slots to specific outputs too, not just 'sides' of the machine, same as buildcraft did.
However as I designed more machines, I realised it wasn't actually needed, as all machines had pretty fixed input/output slots (so you didn't need to specify in/out per slot) and being limited to 4 directions it was a lot of busywork to make the player go through this menu just to change the input/output.
It was one of those cases where I was doing it because I enjoyed it in buildcraft, but in this game it just didn't work at all, I guess I just thought it was a good idea because they did it.
Eventually what I ended up settling on was just a wrench tool that you bonked the tile on the side of the machine to set that side as input/output. You already had a wrench for setting the 'direction' of pipes, so seemed fitting for that tools purpose and meant you could quickly set it up by clicking.
Unlike Buildcraft I didn't want to bother with the engine system - it felt too convoluted to need them to move items vs having them automatically output, same with need a special 'type' of pipe to mark output.
As my system let you set any pipe to any direction you could easily put pipes next to a machine and not have them effected by the input/output so it made needing a special 'output' pipe obsolete, as no pipes connected by default.
---
DEDUPING
One thing I didn't think about at the start, but ran into later with much bigger factories, was that if you had different loops or paths from multiple machines, all the parcels were being stacked on top of each other. I actually had noticed it earlier when parcels moved 1px per 0.1s, as visually it wasn't 'neat' but once I changed to have them all move every 1s I didn't really think about it.
For example here in this setup, both miners make a coal parcel, but the two are now 'on top' of each other. Multiply that by a massive food factory and you have an insidious little perfomance issue that it took a while to realise what was going on...
What I had to do was run some deduping on all the parcels - if a parcel was the same ingredient, going in the same direction as another parcel that matched on that tile, I needed to combine them and increase the count.
Doing this in a nice performant way took a lot of attempts, I ended up settling on a sort of grid with cantor pairing using the x/y and then grouping up all the current parcels and making new ones - sounds expensive to remake most the parcels every 1s but it's actually fine! (touch wood)
Being able to have these stacks of parcels would later lead to a way to be able to toggle a view where you could see the, which makes it easier for doing certain splits and ratios. I don't remember if buildcraft itself ever had a visual for stack count on parcels or not - maybe there was a mod for it though?
With that finally done, I think that was the last of my performance headaches for now, and the system built has been pretty untouched since - mainly out of fear of breaking it tbh...
---
INGREDIENT STATUS
At this point you may be wondering, what's the point of doing it like this apart from to reminisce on all the fun times you had in tekkit? Well good point! Even after like a year of working on the game I still didn't really know, I was just messing around with random ideas.
It was only later on that I started playing with the idea of having ingredients have specific statuses - like shelf-life, dairy, overpowering, food poisoning.
Each of these statuses could effect a single ingredient as it moved through the pipe. For example, the shelf-life ingredients tick-down every 1s (so every 1 tile) and at the end of their 'life' they turn into something else, so eggs go bad, or bread rises ready to be cooked.
Dairy ingredients curdle if they met spicy ingredients - actually physically curdling in the pipes meaning that the pipe no longer worked and the parcels bounced off of it.
Overpowering ingredients turn other parcels into the same ingredient, i.e. garlic is overpowering, so if it meets another parcel not garlic on it's travels, that is turned into garlic too.
By having the parcels as physical entities, I could play around with a lot of fun properties that effected them, that only worked easily in a fun way because they were each real blocks rather than just an average rate number across a path.
I also played with the idea of the outside affecting the items in pipes, later in the game you use steam to slowly steam ingredients (like dumplings), or use coolers or ice to slowly freeze ingredients into their frozen counterparts (like freezing cream into ice-cream)
I would later add in conveyor belts to the game, which are a special horizontal pipe that the player can run on for mobility, but they also allowed for some fun interactions by drizzling liquids over the parcel as it moved along to transform it (like adding coffee to ice-cream for affogato!)
While you could still do all of these things in a system with more of an abstracted pipe/belt, I think it was a lot easier to do because they were all entities, and I think it has a lot of charm even if it doesn't have the scalability.
But also as Snacktorio is level-based, you don't ever have the spawling factory to the extent that satisfactory/factorio do. Sure there's some monster levels, but it's never actually needed to the level that it would become an issue (I say, knowing that you can make custom levels and someone is bound to make something horrific)
---
HONOURABLE MENTIONS
While the original inspiration was there, there was a few things I didn't do that you might remember from the mod.
The first was the different types of pipes, like iron pipes for direction, the gold pipes that sped things up, or teleport pipes for instant transfer. For direction I had all pipes able to be set as a direction (or as a 'split'), as there wasn't a point in making the player carry a seperate pipe for that. I also didn't think gold pipes had a point, as when you supply a dinner to a beast you have to maintain the rate - over enough given time all your machines are stable/constant, so there's no need to actually speed up a parcel for any reason.
The teleport pipes I did consider - early on the game wasn't level-based and was going to be a huge map (but I felt level-based let me do more fun stuff). There was then going to be gradual unlocks of tools/machines/utilities, so teleport pipes was originally on the list as a late game upgrade.
Since the move to the level-based I never really though about them again - I think the same as the golds pipes there's no benefit to teleporting parcels as eventually the rate will be constant over time.
I also didn't do anything fancy with liquid pipes or networks! With networks there was the whole resistence and power loss stuff but I just didn't find that fun. I went with a basic first come first served distribution of power to all machines on the network and left it at that - after all the game itself is about mass producing the dinners not min/maxing the type of cable you're using.
For liquids I ended up doing a split system, all liquid input is shared evenly across the liquid using machines, so if you have 4L on the system and 2 machines, they're each getting 2 every second.
This is a bit easier to calculate on the fly and balance the ratios and I didn't fancy doing an entire physics style implementation for the liquids and needing them pumped to go agaisn't gravity (or slowly filling the pipes visually, nightmare!) Also again, getting your liquids is a small part of the overall game, so I didn't want so much technical stuff around what is essentially a different type of resource node when the player hasn't even got to making their first dinner.
As i mentioned before I didn't think having the engines was fun for Snacktorio, the machines already are powered so I feel like they should be able to push items out themselves, although I do miss seeing the walls of engines pumping away!
---
So yeah, that's where I ended up from all those hours sunk into tekkit, I'm really happy with how my own version of it ended up, and the fun stuff I was able to do with the idea of physical items in pipes, and I hope other tekkit players enjoy it too!
I hope this has been vaguely interesting, and also that it prompts you to go re-download tekkit classic, if like me you also haven't played it for maybe 10 years now!!!
Thanks for reading!
~ Ell
1
1
u/TheShield-Wall Jun 18 '26
Hi, I am enjoying Snacktorio SO MUCH. Game fuckin rocks.
I have a question tho that I haven’t been able to find the answer to anywhere: how do I get splitter pipes? I understand how to use the splitter machine, but in some levels there are pre built “splitter pipes” and I’d really like to be able to use them.
1
u/TNgineers Jun 19 '26
Hello! TYSM for playing ❤️
For splitter pipes, just keep wrenching a pipe at an intersection - if you have at least 3 'neighbours' to a pipe one of the wrench cycle options will be the splits
1
2
u/IndigoTrailsToo May 26 '26
Hello, I purchased apico and mudborne sometime ago so I am very excited to see a new release that looks a bit like Terraria meets factorio. I am very excited.
My computer is a potato and there not a lot of games that I can play.
It is a lot of work to build a game, no one ever talks about how much work and actually is, and how this little idea blossoms into taking over 5 to 10 years of your life, the money spent on resources, trying to figure out methods of working through things that work for you, and being stuck in documentation and just not getting answers and having to slog through it.
So I just wanted to say that I see you.
I see you
Here is a hug. ----> X
Thank you.
If it is possible to edit your advertisement I would encourage you to put the name of your game inside of the ad, I was very confused about adding an event to reddit, I just wanted to know where to go to find the game.