Live data from Hacker News

Seven Years of Factorio Friday Facts (2020)

spieswl.github.io

41–50 of 76 posts

Re: Seven Years of Factorio Friday Facts (2020)

#41

This reminds me of a cool article I read about how Kerbal Space Program 2 renders orbits. I love reading things like this: https://www.kerbalspaceprogram.com/dev-diaries/6509/

Those disclaimers at the beginning of the article are so out of touch

Re: Seven Years of Factorio Friday Facts (2020)

#42
post #11
post #6

For those wondering why this game about factory management keeps showing up on the front page of HN, it’s because the gameplay reminds its fans of software engineering in subtle ways. People who are good at one are likely to be good at the other. More about this here - https://blog.nindalf.com/posts/factorio-and-software-enginee...

An interesting thing about Factorio to me (beyond what’s stated in the linked article), is that it contains a nearly a perfect 1:1 analogy to software concurrency. • Belts are blocking CSP channels, as seen in e.g. Golang (where N producers have to share — or eventually “merge onto” — one channel representing the blocking-receive point of the consumer; which are best only used to transport messages of a single type,…

Also I see trains as network design. You have to commit to the train size upfront (network block size) and you can hit throughput limits

Re: Seven Years of Factorio Friday Facts (2020)

#43
post #38
post #24

Earlier quoted context omitted.

The comment that really made it click for me is that there are two diametrically opposed responses for engineers playing Factorio: * "This game is scratching the same itches as my day job, but with more dopamine and less bureaucracy - how can I play this all the time?" * "This game requires me to expend the same brain-effort as my work/side-projects, but I don't even get anything tangible out of it? Why would I ever…

I'm square in the second group. Factorio is fun for a while, but after somewhere around mid-game you realize that it's much more frustrating and less enjoyable than actual programming. I can't easily "refactor" parts of my factory without fearing it will break some pipeline that depends on the changes. I wish there was a way to "write" "tests" or do mass changes safely. Blueprints and robots help automate things, but…

Most of my games ending when I realized that I have to rebuild half of my base because of some thing and I don't want to spend so much time with inactive base. And my internal perfectionist can't live forever with quickly-hacked sub-par solutions.

Robots at least make it somewhat bearable.

Re: Seven Years of Factorio Friday Facts (2020)

#44
post #12

Earlier quoted context omitted.

I've seen this said literally hundreds of times and can only imagine that these comments are hyperbole now. I've given Factorio dozens of shots now, and have played for hours and hours with people who are great at the game, but it just isn't for me. I get bored in the monotony of the early game, and I'm too stupid to keep things going in the mid game.

When I first picked up Factorio I loved it for about ~12 hours. Then I just felt, everything is too hard and there isn't a sense of purpose. For me, I think it would me a fun game if there was more strategy or something else to do besides build the factory. It seems to me the progression system is actually really linear. > I get bored in the monotony of the early game, and I'm too stupid to keep things going in the m…

The invading bugs sort of are the purpose, to defend against those. But I find it tedious, so I like to turn them off, and then yes, the game is even more noticeably lacking purpose.

I think though that making train networks is my big pleasure with the game. Very satisfying.

Re: Seven Years of Factorio Friday Facts (2020)

#45
post #11
post #6

For those wondering why this game about factory management keeps showing up on the front page of HN, it’s because the gameplay reminds its fans of software engineering in subtle ways. People who are good at one are likely to be good at the other. More about this here - https://blog.nindalf.com/posts/factorio-and-software-enginee...

An interesting thing about Factorio to me (beyond what’s stated in the linked article), is that it contains a nearly a perfect 1:1 analogy to software concurrency. • Belts are blocking CSP channels, as seen in e.g. Golang (where N producers have to share — or eventually “merge onto” — one channel representing the blocking-receive point of the consumer; which are best only used to transport messages of a single type,…

> (Sadly there’s no exact equivalent to Erlang-style message-passing, where producers target messages of arbitrary type at a specific consumer, which all go to the consumer’s single inbox; and where, if that inbox is full, then the message just “evaporates” en route

Train stations plus circuits can do this. Trains can be configured to leave a station when not empty (after receiving a message item of any type), and recipient stations can be disabled by a circuit if the receiver is full, causing the train to skip the station. The last station on the train's route would empty it before it goes back to waiting for a message item to deliver.

Re: Seven Years of Factorio Friday Facts (2020)

#46

This reminds me of a cool article I read about how Kerbal Space Program 2 renders orbits. I love reading things like this: https://www.kerbalspaceprogram.com/dev-diaries/6509/

Those disclaimers at the beginning of the article are so out of touch

Why?

Re: Seven Years of Factorio Friday Facts (2020)

#47
post #11

Earlier quoted context omitted.

An interesting thing about Factorio to me (beyond what’s stated in the linked article), is that it contains a nearly a perfect 1:1 analogy to software concurrency. • Belts are blocking CSP channels, as seen in e.g. Golang (where N producers have to share — or eventually “merge onto” — one channel representing the blocking-receive point of the consumer; which are best only used to transport messages of a single type,…

> (Sadly there’s no exact equivalent to Erlang-style message-passing, where producers target messages of arbitrary type at a specific consumer, which all go to the consumer’s single inbox; and where, if that inbox is full, then the message just “evaporates” en route Train stations plus circuits can do this. Trains can be configured to leave a station when not empty (after receiving a message item of any type), and re…

Not quite the same scheduling/locking semantics, though — sure, it's "concurrent" and packet-oriented, but it's a token ring. It's similar to the original Redis model of concurrency: just have everyone make a series of tiny requests, and then loop around / select(2) from your clients, handling each client's latest request serially, with no request queuing because all requests are synchronous/blocking for the client making them.

N logistics bots are a much closer analogue to N scheduler threads each working in parallel to 1. take a message from a priority heap (really, to take a schedulable process from a priority heap and then run it to produce messages, but same difference) and then 2. synchronously shuttle that message to its destination queue.

I suppose you could get the same semantics with N parallel train tracks, one per scheduler-thread; plus an actual scheduler priority-queue implemented in circuits. But I feel like that's a "non-idiomatic case", in that, no matter how you designed your stations or where you put them, it'd be incredibly painful to design a loader/unloader for a "bus" of parallel train tracks. Especially if all the trains arrive together. It'd be a setup the devs would take one look at and say "that's too much of a kludge, and yet the kludgeyness is necessary, and that's our fault for not including a necessary abstraction. We'll just put in that abstraction."

(The alternative would be a mod that allows trains to pass through one-another on a track. Then you could have one train-line where each train cleanly represents a scheduler thread. No idea what would happen if they tried to stop at the same station at the same time, though. Ghost trains~)

Re: Seven Years of Factorio Friday Facts (2020)

#48
post #20

Quick links to the five "must read" posts that William highlighted: > FFF #243 - New GUI tileset: Showing off their GUI design document. A MUST READ, if only for a good example of a comprehensive design style that fits the game theme perfectly. ( https://factorio.com/blog/post/fff-243 ) > FFF #176 - Belts optimization for 0.15 : Incredible analysis of transport belts and optimizing their performance. A MUST READ. ( h…

> Earlier this week we got a bug report about the game freezing, consuming all of the available RAM, and then crashing when it ran out of RAM. It was again a modded save file so my first instinct was to blame it on a mod. Again, I had to test it. And again... it's never what you think it is. > So, I still repeat the phrase: "Crashing on dereferencing null? Just add a null check!" as a reminder to myself and others to…

It's a perfect example of how useful it is to think in terms of what invariants should hold and why.

Re: Seven Years of Factorio Friday Facts (2020)

#49
post #17
post #11

Earlier quoted context omitted.

An interesting thing about Factorio to me (beyond what’s stated in the linked article), is that it contains a nearly a perfect 1:1 analogy to software concurrency. • Belts are blocking CSP channels, as seen in e.g. Golang (where N producers have to share — or eventually “merge onto” — one channel representing the blocking-receive point of the consumer; which are best only used to transport messages of a single type,…

I wanted, but never got around to, creating a mod that accepts some kind of data outside the game (lines of text, JSON objects, packets from the TUN driver, whatever), wraps them up as Factorio objects, and plops them onto a belt, and another that reads them and sends them back out. The idea being that this could be (A) a cool hack (belt speed factoring into ping time, lmao), but (B) a way to visualize data flow in c…

Sounds a lot like clustorio.

https://mods.factorio.com/mods/Danielv123/clusterio

Re: Seven Years of Factorio Friday Facts (2020)

#50

My biggest Factorio lesson was this: I no longer start a new factory from scratch if I want to do things differently. I use my existing - and now outdated - factory to launch a new one a few minutes run away.

Throw the first one away. Especially when starting a run, plan on throwing away the starter base.

I learned this trick watching AntiElitz speedruns. He'll build a manual bootstrap "factory" (really just mines and smelting) to get plates, then build a very-polished-through-iteration bootstrap base which builds all the development essentials - circuits, arms, belts, ammo, etc. That's used to build the real base.

Post reply on HN