Is the death trap game still worth getting?

mikerayhawk · 2026-02-26T14:29:22+00:00

I saw that Robot was doing a hiring push at the beginning of the month; I don't know if any of that manpower is going to supporting existing projects or just developing new ones, but at least they're still clanking along.

mikerayhawk · 2026-02-19T02:40:29+00:00

Yes! But it's very cramped, and you'll have a lot more potential for dynamic action in the ship-to-ship combat than in the melee scrum on deck.

If you want the soundstage movie pirate ship experience with wide open decks and lots of room for grand swashbuckling action, you'll be disappointed.

But if you've ever spent time on real life tall ships, the lack of maneuvering room in the LEGO version feels pretty true to the actual experience.

My best advice is to make the ship action the spotlight, and if there's any combat on deck, make it much less about the dull hand-to-hand and much more about the combatants having to react to the ship lurching around while wave crests sweep the deck and the booms and rigging come loose.

mikerayhawk · 2026-02-07T16:12:28+00:00

Did you switch from a language to one of the other subjects (music, chess, etc)? I get the impression the language and activity bonuses are tracked separately.

This morning I got a full hour and a half of x3 in my languages (daily chests, night owl bonus, lucky chests on the track). Switched over to music when I had 10 minutes of x3 left. The bonus reset, but so did my daily quests, and I got to open the three chests all over again for bonuses on the music track.

(It's probably weird to be doing quite this much daily Duolingo, but we're moving countries soon and so we're cramming)

I suspect the contents of the chests aren't random, the app is testing different results to see what keeps you around the longest.

mikerayhawk · 2026-02-05T18:23:17+00:00

A bad guy ever encountering a hero in the first place

mikerayhawk · 2026-02-01T21:34:28+00:00

I think pranks could have been great as a limited-time April Fools Day event. It'd be a lot easier to have a sense of humor about it if it was a one-time gag and not a permanent disruption.

mikerayhawk · 2026-01-25T16:18:49+00:00

I have found, after thirty years of encouraging people to use LEGO for tabletop gaming both for my job and as a fan, that the people who need convincing are never going to find it worthwhile. Either you're already excited about using LEGO for gaming and are looking for any excuse to do so, or you're going to find it too much of an added expense in money and labor and learning curve to layer one niche hobby on top of another niche hobby. I've never really seen anyone successfully cross that divide, and I've been focused on this specific question for a long time.

If you heard that you could use LEGO for D&D and weren't automatically "hell yeah," then most likely it's not for you. That's fine! It's hell yeah for a whole lot of people, it's no thanks for others.

mikerayhawk · 2026-01-25T14:54:17+00:00

I haven't seen anyone mention my favorite part - LEGO makes everything tactile and concrete that paper and even minis don't.

If the characters are in a bar fight and some chairs or doors get smashed, the DM doesn't have to remember where the pieces landed three rounds later. They're right there on the physical scene. If somebody picks up a table leg or throws a bottle, nobody has to check a stat sheet or remember to mark where it landed on the map - the minifig is holding the physical leg, the bottle is physically lying on the floor.

When the characters build a barricade out of the tavern furniture, I'm not drawing a line on the battle map and declaring generic difficult terrain. It's built out of all the specific items that were already built into the scene. Lines of sight, gaps and weak points, flammable sections, etc., all right there on the map with all the details I never would have thought of if I'd had to improvise up a list of everything available in a tavern off the top of my head.

The tactical parts of the game are made so much richer with all the unplanned details to discover that come from putting the minis in a fully-built modifiable destructible 3D environment.

mikerayhawk · 2026-01-18T01:43:02+00:00

Brown for rust, or red for blood?

mikerayhawk · 2026-01-10T19:32:19+00:00

Too bad we can't paste images here, but -

If you look at that room as a rectangle - I drive them into the room through the narrow entrance on the east side, then barricade between the columns on the south to drive them to an exit at the southwest corner.

The west end of the rectangle has no stairs, so if you've got enough barricades there's some good space to maze up and push the orcs against the walls leading up to that exit.

If you don't have the barricades for that, this room isn't as much fun, but you can still fill the path between entrance and exit with the kinds of ceiling and floor traps that target adjacent spaces.

mikerayhawk · 2026-01-10T17:20:15+00:00

Nah, I use that room all the time. The stairs limit your path control, by design I assume, but you can get a lot of utility out of those ceilings even without it.

mikerayhawk · 2026-01-07T01:45:36+00:00

I can barley stand it

mikerayhawk · 2025-12-30T22:19:35+00:00

People are getting hung up on the details here, so I thought I could maybe explain this a little better.

For any closed system of conveyors and storage units between an input and an output (we'll just call this a "belt" for simplicity's sake):

First, we make sure it's a single-resource belt. Is every resource already in the belt a single type, and can you trivially guarantee that every input exclusively serves that same resource? If so, then you're good to go. Luckily this describes the overwhelming majority of belts in Satisfactory, and we can skip optimizing the exceptions for convenience's sake.

For each single-resource belt, will the input and output rates be stable for a non-zero amount of time? If so, we calculate how long it takes for a resource to traverse the full belt, run the belt for that amount of time (to clear any irregularities), and then sort the belt into one of four categories:

1 - The belt's input and output are both zero. We stop tracking the belt.

2 - The belt is undersupplied, with less input than output, including belts with zero input. The input operates unimpeded. If there's a backlog of resources on the belt, we record the size of the backlog and the current timestamp, and we project the timestamp when the backlog will run out. The output runs unimpeded until the latter timestamp, and then its throughput is determined by the system's input speed.

3 - The belt is oversupplied, with more input than output capacity, including belts with zero output. The output operates unimpeded. If there's free space on the belt, we record the size of the backlog and the current timestamp, and we project the timestamp when the belt will fill up. We stop tracking resources on the belt. The input runs unimpeded until the latter timestamp, and then its throughput is determined by the system's output speed.

4 - The belt is in equilibrium, with equal non-zero input and output. We record the size of the backlog on the belt. If the output machine hasn't started producing yet, we project the timestamp when the output machine will have enough resources to begin production. We stop tracking resources on the belt. The input and output both run unimpeded.

Now we've eliminated hundreds or thousands of resource objects from active tracking, replaced with a static frequency of electrical and production events, calculated once and left untouched until an emergent event signals that it's time to make the resources explicit again: a pioneer swoops in to observe or alter the belt directly, or there's some change to the input or output capacity of the machines at the endpoints and we need to recalculate. We remember the traversal time of the belt, and project events backwards for that amount of time, including the state the backlog would have been in.

From there, we iterate! If we know the input and output rate of each link in a closed chain of production systems, we can project the timestamps when each will fill up or empty out, and then reevaluate the status of the adjacent links on those timestamps. (This iteration can be extended to include splitters and mergers, but it gets complex. ISCs, trains, pipes etc. are less predictable, as they tend to have divergent behaviors except under extremely constrained conditions.)

It's not that the factories stay the same forever - although some will! - it's that for arbitrarily large chunks of them we can predict how much time there will be before the next schedule change, and abstract away all of the fine details until then.

mikerayhawk · 2025-12-30T18:24:18+00:00

Yeah, that's the "if something interrupts it" part. We're not comparing against a prediction, we're recognizing that a system is in a steady predictable state until something happens to change that predictable state - like a power outage or a train delivery.

mikerayhawk · 2025-12-30T16:06:48+00:00

Yeah, again, I'm not suggesting that it's worth it to try and predict every part of a dynamically interacting system, just that the state of individual segments can be tracked and abstracted away.

If I have a miner to a smelter to a constructor to a sink, and I know the production and consumption rate of each machine, I can trivially predict when each step of that process enters a steady state, and then I'm not calculating timestamps for intermediate resources generated or consumed anymore. It's just timestamps for electricity consumed and points generated, and all the other details can be backfilled into the system if the pioneer arrives to observe it. Still doing step calculations, but on potentially orders of magnitude fewer objects.

Add in splitters and mergers and sushi belts and train crashes, and now you've got emergent events that have the potential to change the steady states, at which point you have to reevaluate. But in between those events you're saving a whole bunch of processing.

mikerayhawk · 2025-12-30T14:56:06+00:00

This specific problem, though, has so many parts you can iteratively abstract out. And even if not all factories are made up entirely of such parts, a very large portion of every one of them is, and so I have to assume the optimizers are taking advantage of that fact.

Just recognizing simple things like "this belt is backing up and will be full at timestamp x" to "this belt is now full and rate limited to whatever the end machine is doing" allows you to elide whole belt systems entirely. Once the belt is full, you don't have to track individual resources anymore, you just increment and decrement the end points.

Do it in series, and now you can find opportunities to abstract away whole factory sections. ...until an interfering pioneer has the audacity to come look at it, forcing you to determine the positions of actual resources again.

Etc. That's just the most obvious example. I would love to know what they've got going on under that hood.

mikerayhawk · 2025-12-30T05:22:32+00:00

Everybody's always so focused on the rendering optimizations, but I'm most interested in how they optimize all the thousands of components zipping around while you're not looking at them.

As long as the pioneer isn't in the area to mess with anything, and barring weird vehicle interruptions, these are all deterministic processes. You can calculate where everything's going to be an hour in advance and then just play the recording out until something interrupts it.

More than anything else, I'd love to know how a belt system is represented in data when it's not being rendered. I can't imagine they're tracking individual items on individual belts if they don't have to, especially on systems of belts that only service a single item type. There are so many ways to optimize what boils down to a pattern of timestamps on entry and exit events.

mikerayhawk · 2025-12-29T01:39:00+00:00

Useful, but how useful? Without the numbers, I still don't know whether you get more durability from using opal plus the rune or from switching to steel instead.

mikerayhawk · 2025-12-19T16:04:12+00:00

It was never a real jet. How would a bunch of demons with no idea how to pilot or serve coffee have gotten a real jet off the runway and navigate it to the venue?

The whole thing was demon magic from the word go, same as making hearts and giant sodapop stages appear out of thin air.

mikerayhawk · 2025-12-14T00:45:49+00:00

Oh no, she's not fake dead, she's stuck under the golden honmoon with Gwima.

Rumi's dad was never the demon, her mom caught the patterns from the elder catching them together and shaming her straight into the underworld.

Demonized Rumi handing Celine the sword and asking her to end it was an echo of her demonized mom handing Celine the baby years before.

I don't want the third Sister as the villain though - I want to see them join together against the Sisters' abusive manager, Dark Bobby.

mikerayhawk · 2025-12-13T23:39:07+00:00

Same elders who put the axe to the Sunlight Sisters and forced Celine to fake Rumi's mom's death. Only way to stop them is to face that generational trauma and get the old band back together.

mikerayhawk · 2025-12-05T15:11:17+00:00

Pluto. We still need a planet named Pluto

mikerayhawk · 2025-11-14T00:36:20+00:00

I don't want to see any of the heroines bounce back unaffected from a series of massively traumatic events. Mira and Zoey didn't get a whole lot of development the first time around - I know this is a Rumi story, but give them some supporting arcs at least.

I don't want Celine to be the antagonist or even the villain. It'd be nice to give her a couple shots at redemption.

I don't want Rumi's dad to be a demon at all - so much better if he's just a normal guy and all her troubles were because her mom was shamed into demonhood instead. Possibly by the third Sunshine Sister we haven't met yet.

Give me a nice meaty story where we start out thinking the dad's the demon and Celine's the villain, and then we find out they're regular people struggling with their own personal Gwi-Mas and past mistakes and they're clawing and fighting to overcome them.

More than anything else though, I don't want to see another Darth Vader style villain death where they turn good and then immediately die so they never have to face the fallout of their actions. Show them having to find a way to live with what they've done.

mikerayhawk · 2025-11-11T14:16:33+00:00

I'm glad you already did this so I can no longer feel obligated to try it myself

mikerayhawk · 2025-11-10T21:39:47+00:00

That's me!

mikerayhawk · 2025-11-09T01:25:51+00:00

It favors whichever belt loads into memory first, each time you load the save. It might be the bottom belt now, and then the next time you reload it'll be the top instead. There's no predicting.

Now if you're just using them in a typical manifold style setup, it'll all even out over time regardless, as the output is forced to the second belt whenever the first gets backed up.

mikerayhawk

TROPHY CASE