Bamboo Comparisons

The flying machine farm is one of the most visually impressive bamboo designs in the community. A slime-block flying machine sweeps back and forth across a field of bamboo, shearing stalks as it passes. It scales cleanly to multiple chunks, requires no redstone at the individual plant level, and looks undeniably satisfying in action.

The problem reveals itself when you map the design against the surrounding area. The build demands space and there's simply no way around it. On top of this, flying machines are notorious prone to breaking during chunk loading and unloading. Giving them a couple strikes dispite their impressive output numbers

The observer-piston farm is the most common bamboo design you'll encounter in survival worlds and tutorial videos. Each bamboo stalk gets its own dedicated observer watching for growth — when the stalk grows by one block, the observer quasi-powers a piston under and behind it for harvesting.

The design is reliable and genuinely self-contained. Every stalk manages its own harvest cycle pseudo-independently, with no timing and minimal cross-plant coordination required. It's straightforward to build, trivial to tile, and it works. The trade-off is resource cost: one observer per stalk adds up fast, and the observer density makes this design one of the most expensive to build at scale.

Output per tile is decent but not exceptional. Because each stalk reacts immediately to every growth event, there's no wasted bamboo sitting on the ground — but the component overhead means fewer stalks fit within the same chunk volume compared to lighter designs. This may not seem like a huge issue, but it's actually the achilles heal of the entire design.

More on that later.

The alternating variant attempts to address the observers cost overhead by sharing a single observer for every 2 pistons, firing the piston underneath and three pisonts behind rather than dedicating one to each plant. On paper this nearly halves the component count while preserving the event-driven harvesting model.

In practice there's no output gains but instead resource reductions. The shared timing introduces small windows where a stalk can grow and not be immediately detected — depending on which row the piston last fired, you may miss one growth event per cycle. Because some tiles don't have a piston, a fully grown bamboo may sit there and wait until it's neighbor who does have an observer finally grows.

Resource savings are genuine, but output per tile decreases, with tiles per chunk increasing. This ends up meaning you get identical rates for less resource input.

The timed farm was my first original design, built around a completely different philosophy: instead of reacting to individual growth events, use a clock to sweep all stalks at once on a fixed interval. I used an etho-clock to fire a row of pistons approximately every 15 seconds (40 items), pushing down across an entire line of bamboo simultaneously.

The advantage is component density. With no observers at the plant level at all, you can pack bamboo shoots significantly tighter within the chunk volume. The entire harvesting mechanism is centralised into a single clock and piston row, rather than distributed across every individual stalk. Per tile, this translates to more bamboo growing in the same footprint.

The main disadvantage is ironically tied to how efficient this design is.

Computing Resource, aka. LAG...

Because we can fit so many pisons in a small area, this can come end up firing 256 pistons every 15 seconds, which as you can imagine, causing a decent amount of block updates.

This directly translates to noticable latency in your gameplay, especially as you scale the farm up.