MAM & Mega Factory — shapez 2 Factory Wiki

What a MAM is actually solving

Randomized goals punish brittle designs. A MAM is the opposite of brittle: it separates concerns into lanes, buffers, and decision points so you can retarget quickly. If you remember nothing else: a MAM is a routing problem first, a building problem second.

Stage 1: decide what “done” means

• Coverage — which shape families must you support on day one?
• Layers — will you support 1-layer first, then 2, then 3/4?
• Colors — do you automate paint selection now or later?
• Throughput — are you building for survival or for records?

Players fail by building a cathedral for 4-layer full automation before they can reliably deliver 2-layer randoms. Incremental MAMs are still MAMs.

Stage 2: shape intake and identification

You need a consistent place where the game tells you what is required, and a consistent way to turn that into routing decisions. Keep this area visually obvious: if you cannot find your “brain” in 5 seconds while paused, your future self will not maintain it.

Stage 3: split the problem into parallel lanes

Parallelism is how you keep debugging tractable. A common pattern is quadrant thinking: treat each quadrant as a subfactory that eventually merges. Another pattern is layer thinking: build layer factories, then stack. Either can work — choose the one that matches your brain.

Stage 4: painting as a service

Treat paint like a utility grid: stable primaries, predictable mixers, and “service exits” that can be tapped by many consumers. If paint is flaky, everything downstream looks like a logic bug when it is actually fluid starvation.

Stage 5: stacking and verification

Stacking errors are the silent killer. Build a verification habit: pause, inspect one completed shape, and compare to the target image at each milestone of complexity. Automated verification (via routing constraints) comes later; early on, your eyes are the best test suite.

Mega factory scaling: throughput without mysticism

Mega factories are mostly repetition + logistics. Once a module works, duplicate it horizontally until belts saturate, then add trains (or other bulk transport) to move goods between districts. If you are chasing big numbers, measure in steady packs per minute, not vibes.

A sane build order (recommended)

1. Reliable intake + buffering
2. Coarse routing (big buckets)
3. Fine routing (quadrants/layers)
4. Painting services
5. Stacking + final QC belt
6. Only then: polish and compacting

Buffers are not waste — they are shock absorbers

Random requests create bursts. If your MAM has zero buffering, a single mismatch can ripple backward and stall intake. You do not need enormous buffers; you need predictable buffers placed at boundaries: between selection and processing, between paint and assembly, between assembly and delivery.

Make failures cheap: isolate subsystems

The best MAMs are boring to debug because each subsystem has a test input: you can feed it a known shape family and watch it behave. If everything is wired into everything, you will spend more time blindfolded than building.

Decompose a scary request into “ingredients”

Before you place another machine, write the request as ingredients: layers needed, quadrants needed, colors needed, support needs (pin/crystal), and the order operations must happen. Players often try to route first and think second — routing is expensive to undo.

Performance: readability beats compactness

A compact MAM screenshot looks cool, but you live inside the save file. Prefer wide aisles, obvious bus lines, and consistent spacing so you can spot mistakes while paused. Compacting is a late-game cosmetic pass, not a day-one goal.

Debug signals that mean “your MAM is too clever”

• You cannot explain a routing decision in one sentence.
• You fear touching a belt because “something magical depends on it.”
• You need to remember hidden state to understand normal operation.
• You fix one shape family and break another every time.

Those are not skill issues — they are complexity debts. The cure is usually to split routing into clearer stages, even if it uses more tiles temporarily.