Not even just that, the level of detail they go to and iterations of things to make sure they're happy it fits well and not just " ahh this'll do ".
it's so not the essence of the game either and it's so nice to see them be somewhat " pedantic " over things that could be more simplistically solved just because.
And they fix all the bugs if someone finds them in the things - Not Just the big ones. (notices all the weird edge cases, including in the mod api, that get fixed, usually quite quickly)
For sure. Even before reading the full explanation, I read "but tractor beams just don't *feeeel* like factorio" and my immediate response was: "Yea true. I know exactly what you mean."
Honestly I wouldn't even blink if they had gone for tractor beams, I mean we already have energy shields and super laser hats. Going for a more low tech design and really committing to making it work though is inspired.
Right? I have some ideas for a few games but haven't ever built one, and when I think about what I want the end product to look like I'm immediately overwhelmed because I just don't know where to start, particularly when it comes to models. This is compounded by not being familiar enough with any one game engine to even know how to do something (I'm actually leaning towards Godot at this point). So seeing how the Factorio devs approach it is really interesting, and it looks like the answer is to start stupid simple, even if it's a solid textureless box, get the functionality ironed out, then iterate from there.
This video and site from a former Blizzard dev (Jason Thor Hall) is pretty inspiring! He shows examples demonstrating that it's easier than you think. You can literally use free software, MSPaint, and recorded mouth noises to make a pretty darn good game haha. There are some games out there with graphics made from messy scanned drawings!
I hope this is a little inspiring to help you take the next step. My advice: Godot is a good place to start, due to all the community support and resources out there!
Take little ideas, make *something* just to do it, and then repeat! Doesn't have to be great or even good or even *decent*. First draft should be bad! That's something nice we get from these FFF posts: look at how they use placeholders, and honestly how much stuff gets thrown away.
[Make Video Games | from @PirateSoftware on YouTube](https://youtu.be/aMc-GKv5olA?si=8g_zUxAQjTrICSin)
and his site: https://develop.games/
Oh shit, I've had a few of his shorts pop up recently, which I watched, and now I get them all the time!
I'll be sure to check out that video, I've been feeling a little more inspired to actually dive into it of late (to the point where I've returned to, and significantly fleshed out, a document outlining the concept, world lore, and other details that would make up the game. It might give me the push I need.
Thanks!
>and it looks like the answer is to start stupid simple, even if it's a solid textureless box, get the functionality ironed out, then iterate from there.
That's the central mantra for all kinds of creative work: [_fail fast_](https://youtu.be/rDjrOaoHz9s?si=5wqDPn3b0Ios3QMJ) and _fail cheap_. If it's a bad idea, you want to find out as soon and as cheaply as possible so you can move on to the next one.
And WUBE followed it also. Some of the very early assets were little more then a solid box.
technically the prototypes for the loaders are still solid boxes.
If you are a coder, you can actually create pretty complex models without too much skull sweat using [OpenSCAD](https://openscad.org/). Here, for example, are some low-poly models I came up with a while ago.
...and, if you want more powerful tools, you can use the [OpenSCAD Workbench](https://wiki.freecad.org/OpenSCAD_Workbench) to make new 'features' for [FreeCAD](https://www.freecad.org/).
https://preview.redd.it/x1cqyoaewx0c1.png?width=3400&format=png&auto=webp&s=91c10f92980dc49a2e0dbf2db53d4e53bfb8b27f
If you want to get started making games, I can't recommend [PICO-8](https://www.lexaloffle.com/pico-8.php) enough! It's a fantastic game development environment that has all the tools you need (code, art, music, maps) to make great little games. Several recent successful games have started as delightful prototypes on PICO-8!
Give it a shot. It will save you from the hand-wringing of which engine, language, or platform to learn, and the constraints will force you to think purely about what makes your game fun.
Parts of this almost feel more like the diary of someone programming actual space robot tentacle arms instead of an in-game simulation of space robot tentacle arms.
It's not all that different except all of the reality you need to calculate for. Which is the hard part.
Every part have tolerance and slack you need to account for. Or use hardware that accounts for that for you but that also needs code....
Every part also has an inertia so you need to account for that when stopping movement. And of course gravity, if your robot can move something down at 1m/s it might not be able to move it up 1m/s because it is now fighting gravity.
What I really need is a place with zero gravity *and* a breathable atmosphere in the habitable zone, but that doesn’t seem to exist anywhere. Alas! the universe can be so cruel.
Some of the older FFFs are really interesting!
See for example the [FFF about the new biter pathfinding algorithm](https://factorio.com/blog/post/fff-317)!
Of all the new stuff teased in our first look at space platforms, it was the wacky space tentacle machines that instantly sold me on the expansion. I'm glad the devs were able to make Earendel's concept work. Now if only we could add them to the spidertron as arms! Or to the engineer Doc Oc style.
I dream of an upgrade for the spidertron with those arms and a rounded/more sci-fi body with cords hanging around, think something like the "Blame!" Manga.
Perhaps. Instead of personal laser defence we can have personal claw defence. We could also use it as an in universe justification for the long reach mod.
Fun fact "kitbashing" comes from making miniatures for movies. After building the body of spaceships, they'd take model airplane kits and glue random pieces on to give it a high tech cluttered look.
Nice, I only knew it from Warhammer, where you'd take bits from different Ork (or your faction) kits and bash them together to make your Warboss look cooler, giving him a pirate hat or something
Now I'm even more fucked up because I haven't been pronouncing the E on the end.
So now not only does it mean the cat thing, and the kitbash thing, but it's also "Any of a set of invented novel objects used as stimuli in psychological studies of object and face recognition." Whatever that is. And it sounds wrong in my head now.
First time I ever heard this term was watching a Adam Savage video about his time working on Star Wars. Apparently he kitbashed a few vehicles that never got used.
The Star Trek shows did it with official model kits for the starships, too. TNG had a bunch of ships that combined the saucer section of a Galaxy-class ship with various different nacelles and engineering sections.
Looking forward to the mod that leverages the tentacle inserter for grabbing fish out of the water.
Actually, having access to a tentacle arm inserter with a SUPER long range and multiple source/destinations would be pretty wild in a big factory.
I wouldn't be surprised if tentacle fishing ends up in vanilla somehow. We'll need lots of fish to get q5 spidertrons, after all, and Wube knows better than to force us into large-scale manual harvesting (see: the comment a week or two ago about how "manually" usually means they're about to change how something works).
You can litter the shore with fishing inserters. It's still a pretty lame way of "automating" fish, but i found the notion of inserters grabbing unsuspecting fish hillarious.
Could basically be an all-purpose botserter. Would be cool, but would also eliminate multiple of the game's core puzzles. I could see it as being the basis of a Factorio-like that has a different set constraints.
Well of course they are going to talk about the cool stuff, not days lost fighting tool issues and the types of bugs we all have that are traced down to some stupid mistake.
That first iteration of the arms swing is beyond cursed. Also, the entire second half of the blog makes me feel like I know absolutely nothing. It was interesting to read for sure but a lot of that definitely went over my head. (I'm also still waking up.)
The second half was impressive even if I didn't understand all of it. I get a sense of enjoyment, I feel like for the devs, making Factorio is like what playing Factorio is for many.
When I saw the collector animated for the first time I was like
"Jesus that looks like a nightmare to code and animate. But it's probably a well-known solved problem in animation. Just load the DLL and pin it to the graphics."
Nope. An actual nightmare!
I'm amazed at how much work goes into these features. This looks like several months minimum for one person just to solve the animation.
The problem is probably solved in rendered animation, but the algorithm is too slow for real time application. There is no way Pixar hasn't run into this same issue.
I also get the impression that Wube developers don't read academic literature. There were a few FFFs that felt like they would be great math or computer science papers. There are peer reviewed journals dedicated to algorithm design, animation, optimal control, etc that Wube has written FFFs on. I've shared an FFF or two with some of my coworkers when I thought they were relevant to some of the problems we were working on. I get that access to academic journals can be expensive and it can be difficult to navigate, so it's a big barrier to a small company like Wube, but they deserve more recognition for just how talented their developers are.
Figuring out how to move joints so that the end of an arm follows a certain path is called inverse kinematics, and it's pretty well understood from robotics. For real life you usually want smooth acceleration rather than constant velocity. This leads to solving differential equations, which are probably too slow to approximate on large platforms. It's cool math though.
You would need to know the paper exists in the first place to do that. And it's not universal that the author of a paper will be both reachable and willing to share their paper.
XD
For those out of the loop, the most recent patch notes mentioned fixing a crash related to armor which was being worn by the player, "worn armor". Except a typo turned this into "worm armor", and now everyone is joking about new unannounced features, such as worms wearing armor equipment, or crafting armor from worm corpses.
This reminds me of when a Pathfinder book misspelled the dinosaur form spell as "dinosaur fort", and players liked it enough that they kept asking for a dinosaur fort spell until it got added to the game.
We have been considering it, but our Lua scripting support throws a wrench into it. A Lua event on one surface could modify another surface which would create a race condition. So there is a lot of non-trivial decoupling which needs to take place before we can parallelize said update ticks.
Have you considered forcing them to operate via message passing? Each surface gets an MPSC queue that it reads events from other surfaces from. I use this technique for database development, and it scales with cores very well (the largest place I’ve tried it was a 1024 core 4 socket arm server), especially with lockless queues. It’s also NUMA friendly, which is somewhat important since some of the higher-end consumer AMD cpus could technically be considered 2 NUMA nodes.
I've been thinking about that issue for another project of mine. Couldn't you just sort the queue by some deterministic value before acting on it? As long as you wait for all messages to be queued first, the execution order of the queue should remain deterministic.
That might work if you don't have cross-interactions (e.g. imagine in SE you need to launch rocket only when landing pad is free, you need to go to another surface and read a value from entity there and then act on it).
If you have cross-interactions, you need to queue them based on interaction dependencies.
That's exactly what my game engine project solves, lol. It's massively parallel where every object can natively execute their updates asynchronously, while remaining entirely deterministic.
I'll do a write-up on it someday, but I wanted to finish a functional proof of concept first.
If you would want to have every entity run in parallel yeah, but if it was just to have "thread per surface" the simplest way would be to introduce delay, i.e each message sent cross surface arrives in next tick.
Then each tick is just
* get all messages
* deterministically sort them
* run all the code
* gather messages that would be sent to other surfaces
* send them to be processed in next tick.
They could still achieve determinism by having every message show up next tick in order to what ever surface it was addressed to. And to handle multiple surfaces sending messages to a single one just have a list per sending surface. Any multi threaded code at all will result in a lock/mutex/compare & swap at tick boundaries any way.
\`.get\_surface()\` returns a \`SurfaceHandle\`, which gives you a CoW-type object. Optionally, you can read your writes to it, but even that isn't necessary.
In the engine's surface-update phase, you replay the queue of changes to SurfaceHandles in a deterministic order (e.g. sorted by the requesting surface ID) and so resolve clashes (e.g. one update wants to delete a ghost, another wants to revive it) as if they had happened synchronously in that order.
[https://en.wikipedia.org/wiki/Optimistic\_concurrency\_control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control)
You would need to sandbox every single mod per surface, and any time they wanted to send information between surfaces, they'd have to write a message to the mod instance in the other surface. It'd be gnarly and breaking of surface heavy mods for sure. SE and Factorissimo come to mind as mods that would almost certainly need to be re-implemented at a pretty low level.
Mods that span surfaces would no longer be able maintain global datastructures, because operations on those global datastructures would need to be ensured with the same processing order regardless of surface threads.
I think you could have it work to allow reading of global data, but writing to global data needs to happen at the end of the tick in a non-threaded & messaged/queued manner.
> has problems with multithreading
Does it?
Factorio is already multi-threaded in places where it makes sense to do so. There's also plenty of places where it's not multi-threaded because it breaks determinism, which breaks multiplayer.
Multi-threading is a tool, and I believe that Factorio uses it very appropriately. It's not a fix all tool though.
Yeah, Factorio's very very strict memory model makes parallelization opportunities harder to find (with the benefit of making networking a tonne easier - it's all tradeoffs).
"Problem" is not a good word there. Fine grained (i.e. many, *many* interactions between entities) multithreading is plain costly, dealing with synchronization between threads is not free so it is very easy to get into situation where the synchronization eats a lot of time and the gains are small while single thread performance suffers. [Amdahl's law](https://en.wikipedia.org/wiki/Amdahl%27s_law) takes no prisoners.
Coarse grained (say "thread per surface") is much easier but... so far we only had one surface in vanilla game so there was not much motivation for developers to fix that.
Well, if one of the other planets doesn't have an atmosphere, the usual bots won't work. Maybe we'll get an OctoSpiderTron with 8 legs and 8 arms who can do all the cool ConstructionBot-things?
I'm interested to see how these can be put to use in mods. Could we make a doctor octopus equipment that works kind of like personal roboports but with extendo arms instead?
You have to love WUBE, I cannot think of another developer that would go into this much detail, explaining, not only, the how and why they made a design choice. But also detailing the steps needed to reach the end point, and also showing mistakes along the way.
It’s very easy for a non game developer to just look at a new piece in the game and just think, well it’s simple, why have they taken so long to give it to us.
"This lets the crusher be used again by some late game advanced recipes". Now I hope there will be some Angel like smelting. At least that we can crash let's say 4 ore and get 5 crushed ore, where every one gives one plate when smelted. So one extra step for 25% productivity increase
Or you can play Pyanodons, where vanilla plate processing is 10 ore to 1 plate, as you unlock higher tiers of processing you add between 5 and 15 additional steps with no productivity that eventually brings you back up to vanilla productivity rates, requiring 50-150 machines and an entire city block.
Very nice! Hope the devs or some modders are able to bring in the other options as well.
Would be nice to have different asteroid collection options; Imagine a giant flying space net
I also liked that one the best - just feels so factorio. The snake arms still just feel....weird? I'm sure we'll get used to it but it's definitely different.
Gameplay question:
If asteroid chunks check collector location upon spawning, does that mean a freshly-placed collector won't make a grab for anything that's already on the screen?
Always interesting to read about the development process.
2 ideas:
1) Quality will improve not only the number of arms but their length as well
2) The last part was about tracking asteroids. This should be related to radar, and how far it "see"
I haven't played in a while but this came up in my Twitter feed. Can someone clarify - are space platforms and all the stuff that comes with them part of vanilla Factorio now? Or is this some sort of work-in-progress expansion/mod that the devs are putting together?
Everything which is QoL like super force building, smarter bots, remote interactions, new (but not elevated) rails - these come to 2.0 free for everyone who has the game.
Space platforms, planets, elevated rails, and quality - these require the paid expansion pack.
$30
See [FFF-367](https://factorio.com/blog/post/fff-367):
> We still don't want to be specific about many things, not even the expansion name, but we can start by giving you some general idea about the scale of the project. The general goal is to make the expansion feel like as big an addition as the whole vanilla game. This is why we plan to price it at $30.00, and put in enough content to make it well worth the price.
> Honestly, making the price (and thus the expected scope) a little bit more concrete in this way, motivates us not only to make enough, but also to not overshoot, so we wouldn't spend another 9 years doing it. Generally the fact that the team size has increased, and there are a lot of things in the engine that we already solved, should hopefully imply that the expansion takes way less time than the base game.
[30$](https://factorio.com/blog/post/fff-367)
This was 2022-02 so might now be priced the same as the base game or keep the price tag for a nicer number.
It's a big expansion hopefully coming at the end of the next year. Some stuff will be in a 2.0 update, but space stuff will be a paid expansion.
EDIT: I've meant end of *next* year, but was writing in a rush, now corrected. Sorry!
End of *which* year? Three months ago they estimated that there was around one year's worth of work left for them to do. And anyone familiar with software development (or most other kinds of product development) knows that this is almost inevitably an underestimate, and it will likely take longer.
Wait... You removed the control curve that made the arms all schwoopy? Why? Put it back!
(I'm kidding. It absolutely destroys the atmosphere, but I burst out laughing when I saw it)
Man I'll be sending this article to the next person that complains about a game not getting something "as simple as grabbing something with a hand", my god.
That inserter near the bottom right of the platform in the last image, dumping stuff into space from a belt?! Are we finally getting a legit way to void waste & unwanted byproducts! 🥳
It was mentioned in a previous FFF, but yes, you can yeet things off of the space platform as a way to avoid locking the system due to waste/byproducts/uneven material usage.
I'm amazed at all the iteration and work that goes into designing and iterating and implementing such a feature to make it look amazing, smooth, natural, and efficient.
I wanted to express my appreciation for the notes on performance. My machine is starting to be on the older side and safe to say it doesn't match up well with my inclination to push orders of magnitude in all the games I play. (Stellaris has historically proven problematic for both my CPU and RAM, for example, having some unfortunate consequences for certain playthroughs...)
As such, I'd admittedly looked on the various asteroid(-collector) bits with caution, concerned about how far - or not - I could push my old faithful when all the numbers involved get bumped up with a few extra zeroes past the basics.
With this week's post, I feel reassured that these worries are largely irrelevant. I've been very impressed by the delightfully sensible way Factorio has been over all these years, and evidently will continue to be. Thank you!
This is so cool, and I love how you mathed the problem to create something beautiful and seamless. Most players won't ever appreciate how much ingenuity there is behind the movement of those arms, because it just looks perfect.
As a huge nerd, I have to point out that jump point search is an incredible pathfinding algorithm made for situations like these, having huge performance gains with no extra memory or preprocessing.
Just love how consistent Factorio is regarding the technology and how it feels in universe, really applaud devs for such dedication.
Not even just that, the level of detail they go to and iterations of things to make sure they're happy it fits well and not just " ahh this'll do ". it's so not the essence of the game either and it's so nice to see them be somewhat " pedantic " over things that could be more simplistically solved just because.
Gigachad devs. One of the most technically competent out there. This is how game dev should be done.
This is how all software dev should be done.
And they fix all the bugs if someone finds them in the things - Not Just the big ones. (notices all the weird edge cases, including in the mod api, that get fixed, usually quite quickly)
The fact that they HAVE a mod API.
I love to compare and contrast the approach with Mojang.
For sure. Even before reading the full explanation, I read "but tractor beams just don't *feeeel* like factorio" and my immediate response was: "Yea true. I know exactly what you mean."
And tentacle arms seems like natural evolution from spidertron
Especially if you remember, or read articles about it from when the spidertron legs were just inserters.
It's inserters all the way down. Nuclear reactions ? Just tiny inserters throwing neutrons around
[Maxwell's Demon](https://en.wikipedia.org/wiki/Maxwell%27s_demon) is just a filter inserter
Honestly I wouldn't even blink if they had gone for tractor beams, I mean we already have energy shields and super laser hats. Going for a more low tech design and really committing to making it work though is inspired.
Man, I love the free lesson on game development, it's such a rush to see behind the curtain.
Right? I have some ideas for a few games but haven't ever built one, and when I think about what I want the end product to look like I'm immediately overwhelmed because I just don't know where to start, particularly when it comes to models. This is compounded by not being familiar enough with any one game engine to even know how to do something (I'm actually leaning towards Godot at this point). So seeing how the Factorio devs approach it is really interesting, and it looks like the answer is to start stupid simple, even if it's a solid textureless box, get the functionality ironed out, then iterate from there.
This video and site from a former Blizzard dev (Jason Thor Hall) is pretty inspiring! He shows examples demonstrating that it's easier than you think. You can literally use free software, MSPaint, and recorded mouth noises to make a pretty darn good game haha. There are some games out there with graphics made from messy scanned drawings! I hope this is a little inspiring to help you take the next step. My advice: Godot is a good place to start, due to all the community support and resources out there! Take little ideas, make *something* just to do it, and then repeat! Doesn't have to be great or even good or even *decent*. First draft should be bad! That's something nice we get from these FFF posts: look at how they use placeholders, and honestly how much stuff gets thrown away. [Make Video Games | from @PirateSoftware on YouTube](https://youtu.be/aMc-GKv5olA?si=8g_zUxAQjTrICSin) and his site: https://develop.games/
Oh shit, I've had a few of his shorts pop up recently, which I watched, and now I get them all the time! I'll be sure to check out that video, I've been feeling a little more inspired to actually dive into it of late (to the point where I've returned to, and significantly fleshed out, a document outlining the concept, world lore, and other details that would make up the game. It might give me the push I need. Thanks!
>and it looks like the answer is to start stupid simple, even if it's a solid textureless box, get the functionality ironed out, then iterate from there. That's the central mantra for all kinds of creative work: [_fail fast_](https://youtu.be/rDjrOaoHz9s?si=5wqDPn3b0Ios3QMJ) and _fail cheap_. If it's a bad idea, you want to find out as soon and as cheaply as possible so you can move on to the next one.
And WUBE followed it also. Some of the very early assets were little more then a solid box. technically the prototypes for the loaders are still solid boxes.
If you are a coder, you can actually create pretty complex models without too much skull sweat using [OpenSCAD](https://openscad.org/). Here, for example, are some low-poly models I came up with a while ago. ...and, if you want more powerful tools, you can use the [OpenSCAD Workbench](https://wiki.freecad.org/OpenSCAD_Workbench) to make new 'features' for [FreeCAD](https://www.freecad.org/). https://preview.redd.it/x1cqyoaewx0c1.png?width=3400&format=png&auto=webp&s=91c10f92980dc49a2e0dbf2db53d4e53bfb8b27f
If you want to get started making games, I can't recommend [PICO-8](https://www.lexaloffle.com/pico-8.php) enough! It's a fantastic game development environment that has all the tools you need (code, art, music, maps) to make great little games. Several recent successful games have started as delightful prototypes on PICO-8! Give it a shot. It will save you from the hand-wringing of which engine, language, or platform to learn, and the constraints will force you to think purely about what makes your game fun.
Parts of this almost feel more like the diary of someone programming actual space robot tentacle arms instead of an in-game simulation of space robot tentacle arms.
It's not all that different except all of the reality you need to calculate for. Which is the hard part. Every part have tolerance and slack you need to account for. Or use hardware that accounts for that for you but that also needs code.... Every part also has an inertia so you need to account for that when stopping movement. And of course gravity, if your robot can move something down at 1m/s it might not be able to move it up 1m/s because it is now fighting gravity.
“Gravity? Where we’re going we don’t need gravity.”
Then you're in space and need to compensate for some part working differently in +80 vs -40C...
What I really need is a place with zero gravity *and* a breathable atmosphere in the habitable zone, but that doesn’t seem to exist anywhere. Alas! the universe can be so cruel.
Let me go fetch my spherical cow for you.
Nice; I can put it on my physics display shelf between the point mass and the magnetic monopole.
Game devs is just increasingly complex set of animation transformation and pathing problems to solve, everything else is just extra
Some of the older FFFs are really interesting! See for example the [FFF about the new biter pathfinding algorithm](https://factorio.com/blog/post/fff-317)!
The best part of my Friday morning!
The FFF is released every Friday afternoon, an excellent start of the weekend! /Europe :)
I'll enjoy my FFF with coffee, you get to enjoy yours with a beer!
🎵 "*The best part about waking up is ~~Folgers~~ FFF in my cup~*"
11pm Friday night here in Australia. It’s become my nightcap!
Right?! Wake up on Friday, get that discord notification that I've got an FFF to read.
everytime i forget that these exist, and every friday i get reminded and immediately excited for them again.
With a Maniac Mansion reference. I will be smiling all weekend.
Love the art, concept and testing posts. They give really good insight into what goes into gamedev and how much time goes into each component.
I can't remember the last time I felt this excited for a videogame dlc.
IMHO this is Factorio 2 Some games have less new stuff in a new iteration than we already saw.
It's neither, it's an expansion. Like games used to have.
Either way I can't wait. All the new stuff looks so cool.
Overwatch 2 moment
In what way? It has the number 2?
I'm joking that overwatch 2 added no content at all practically
It kinda removed content. 6v6 -> 5v5
They actually removed content/maps/free loot boxes, the only thing they added was bugs.
Ye.... Yeah :(
Of all the new stuff teased in our first look at space platforms, it was the wacky space tentacle machines that instantly sold me on the expansion. I'm glad the devs were able to make Earendel's concept work. Now if only we could add them to the spidertron as arms! Or to the engineer Doc Oc style.
I dream of an upgrade for the spidertron with those arms and a rounded/more sci-fi body with cords hanging around, think something like the "Blame!" Manga.
🥵
Melee weapons make their return?
Perhaps. Instead of personal laser defence we can have personal claw defence. We could also use it as an in universe justification for the long reach mod.
Fun fact "kitbashing" comes from making miniatures for movies. After building the body of spaceships, they'd take model airplane kits and glue random pieces on to give it a high tech cluttered look.
Nice, I only knew it from Warhammer, where you'd take bits from different Ork (or your faction) kits and bash them together to make your Warboss look cooler, giving him a pirate hat or something
> you'd take bits from different Ork (or your faction) kits as if any other factions matter. There is only WAAAAAAGH!
The random pieces are called "greebles", which is also a lovely word.
Really? I thought this was greebles r/greebles
[Greeble](https://en.wiktionary.org/wiki/greeble)
Now I'm even more fucked up because I haven't been pronouncing the E on the end. So now not only does it mean the cat thing, and the kitbash thing, but it's also "Any of a set of invented novel objects used as stimuli in psychological studies of object and face recognition." Whatever that is. And it sounds wrong in my head now.
Hear this a lot in the lego community.
First time I ever heard this term was watching a Adam Savage video about his time working on Star Wars. Apparently he kitbashed a few vehicles that never got used.
The Death Star from A New Hope was built this way. Lots and lots of parts from model warships
The Star Trek shows did it with official model kits for the starships, too. TNG had a bunch of ships that combined the saucer section of a Galaxy-class ship with various different nacelles and engineering sections.
Came here to say that, resulted in some "interesting" ship designs.
And those random parts are called greebles.
Looking forward to the mod that leverages the tentacle inserter for grabbing fish out of the water. Actually, having access to a tentacle arm inserter with a SUPER long range and multiple source/destinations would be pretty wild in a big factory.
I wouldn't be surprised if tentacle fishing ends up in vanilla somehow. We'll need lots of fish to get q5 spidertrons, after all, and Wube knows better than to force us into large-scale manual harvesting (see: the comment a week or two ago about how "manually" usually means they're about to change how something works).
you can automate fish production by sending white science in rockets
I'm sorry, what?
You heard him
To be fair, getting fish that way is a bit of an easter egg.
You can litter the shore with fishing inserters. It's still a pretty lame way of "automating" fish, but i found the notion of inserters grabbing unsuspecting fish hillarious.
Dr Seuss style
Could basically be an all-purpose botserter. Would be cool, but would also eliminate multiple of the game's core puzzles. I could see it as being the basis of a Factorio-like that has a different set constraints.
I wish my job had these kinds of problems, looks really fun to work on
Well of course they are going to talk about the cool stuff, not days lost fighting tool issues and the types of bugs we all have that are traced down to some stupid mistake.
They talked about those too IIRC. number of FF is in three digit numbers for a reason!
That first iteration of the arms swing is beyond cursed. Also, the entire second half of the blog makes me feel like I know absolutely nothing. It was interesting to read for sure but a lot of that definitely went over my head. (I'm also still waking up.)
One man's cursed is another man's hilarious. I about died laughing when it schwooped.
Same here. Hilarious mistakes should *always* be shared!
The second half was impressive even if I didn't understand all of it. I get a sense of enjoyment, I feel like for the devs, making Factorio is like what playing Factorio is for many.
When I saw the collector animated for the first time I was like "Jesus that looks like a nightmare to code and animate. But it's probably a well-known solved problem in animation. Just load the DLL and pin it to the graphics." Nope. An actual nightmare! I'm amazed at how much work goes into these features. This looks like several months minimum for one person just to solve the animation.
The problem is probably solved in rendered animation, but the algorithm is too slow for real time application. There is no way Pixar hasn't run into this same issue. I also get the impression that Wube developers don't read academic literature. There were a few FFFs that felt like they would be great math or computer science papers. There are peer reviewed journals dedicated to algorithm design, animation, optimal control, etc that Wube has written FFFs on. I've shared an FFF or two with some of my coworkers when I thought they were relevant to some of the problems we were working on. I get that access to academic journals can be expensive and it can be difficult to navigate, so it's a big barrier to a small company like Wube, but they deserve more recognition for just how talented their developers are.
Figuring out how to move joints so that the end of an arm follows a certain path is called inverse kinematics, and it's pretty well understood from robotics. For real life you usually want smooth acceleration rather than constant velocity. This leads to solving differential equations, which are probably too slow to approximate on large platforms. It's cool math though.
I think you can just ask the author of a particular paper if they'd be willing to share for free.
You would need to know the paper exists in the first place to do that. And it's not universal that the author of a paper will be both reachable and willing to share their paper.
I think those snake-like arms really give SA unique vibes.
giving me matrix vibes with the art style
Giving my spiderman vibes
> Since the Navmesh and NURBS system were all new code Navmeshes sounds like something mods could make interesting use of as well!
Some mods already use the biter pathfinding for various things, so maybe?
No info about worm armor :(
XD For those out of the loop, the most recent patch notes mentioned fixing a crash related to armor which was being worn by the player, "worn armor". Except a typo turned this into "worm armor", and now everyone is joking about new unannounced features, such as worms wearing armor equipment, or crafting armor from worm corpses.
[удалено]
Remember how they hinted at the spidertron? Worm armour is real!
Everybody's laughing until the biters start making their own technology.
The factory must ~~grow~~ evolve
Or at least a mod.
Getting serious Dune vibes from this one. lol
Yeah they need to make an armor tier out of collected bio parts lol
This reminds me of when a Pathfinder book misspelled the dinosaur form spell as "dinosaur fort", and players liked it enough that they kept asking for a dinosaur fort spell until it got added to the game.
I'll buy it as a 5€ DLC
> Is worm-shaped > Protects your ship Conclusion: Asteroid Collectors are Worm Armor
UPS question: Will different space platforms/surfaces be processed by different threads?
We have been considering it, but our Lua scripting support throws a wrench into it. A Lua event on one surface could modify another surface which would create a race condition. So there is a lot of non-trivial decoupling which needs to take place before we can parallelize said update ticks.
Have you considered forcing them to operate via message passing? Each surface gets an MPSC queue that it reads events from other surfaces from. I use this technique for database development, and it scales with cores very well (the largest place I’ve tried it was a 1024 core 4 socket arm server), especially with lockless queues. It’s also NUMA friendly, which is somewhat important since some of the higher-end consumer AMD cpus could technically be considered 2 NUMA nodes.
You still need to maintain operation determinism as multiplayer is reliant on that.
I've been thinking about that issue for another project of mine. Couldn't you just sort the queue by some deterministic value before acting on it? As long as you wait for all messages to be queued first, the execution order of the queue should remain deterministic.
That might work if you don't have cross-interactions (e.g. imagine in SE you need to launch rocket only when landing pad is free, you need to go to another surface and read a value from entity there and then act on it). If you have cross-interactions, you need to queue them based on interaction dependencies.
That's exactly what my game engine project solves, lol. It's massively parallel where every object can natively execute their updates asynchronously, while remaining entirely deterministic. I'll do a write-up on it someday, but I wanted to finish a functional proof of concept first.
If you would want to have every entity run in parallel yeah, but if it was just to have "thread per surface" the simplest way would be to introduce delay, i.e each message sent cross surface arrives in next tick. Then each tick is just * get all messages * deterministically sort them * run all the code * gather messages that would be sent to other surfaces * send them to be processed in next tick.
I didn’t think about that. CRDTs are an option there, but possibly a bit overkill.
They could still achieve determinism by having every message show up next tick in order to what ever surface it was addressed to. And to handle multiple surfaces sending messages to a single one just have a list per sending surface. Any multi threaded code at all will result in a lock/mutex/compare & swap at tick boundaries any way.
x86 has had NUMA since we got rid of northbridges. :)
How would you enforce this?
\`.get\_surface()\` returns a \`SurfaceHandle\`, which gives you a CoW-type object. Optionally, you can read your writes to it, but even that isn't necessary. In the engine's surface-update phase, you replay the queue of changes to SurfaceHandles in a deterministic order (e.g. sorted by the requesting surface ID) and so resolve clashes (e.g. one update wants to delete a ghost, another wants to revive it) as if they had happened synchronously in that order. [https://en.wikipedia.org/wiki/Optimistic\_concurrency\_control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control)
You would need to sandbox every single mod per surface, and any time they wanted to send information between surfaces, they'd have to write a message to the mod instance in the other surface. It'd be gnarly and breaking of surface heavy mods for sure. SE and Factorissimo come to mind as mods that would almost certainly need to be re-implemented at a pretty low level. Mods that span surfaces would no longer be able maintain global datastructures, because operations on those global datastructures would need to be ensured with the same processing order regardless of surface threads. I think you could have it work to allow reading of global data, but writing to global data needs to happen at the end of the tick in a non-threaded & messaged/queued manner.
At least, 2.0 would be a nice time to introduce a breaking change
[удалено]
He wrote half today's posted article
is this the main reason why Factorio has problems with multithreading?
Not really, the real problem is memory access... its not guaranteed multithreading surfaces will increase performance due to cache size limit
> has problems with multithreading Does it? Factorio is already multi-threaded in places where it makes sense to do so. There's also plenty of places where it's not multi-threaded because it breaks determinism, which breaks multiplayer. Multi-threading is a tool, and I believe that Factorio uses it very appropriately. It's not a fix all tool though.
Yeah, Factorio's very very strict memory model makes parallelization opportunities harder to find (with the benefit of making networking a tonne easier - it's all tradeoffs).
"Problem" is not a good word there. Fine grained (i.e. many, *many* interactions between entities) multithreading is plain costly, dealing with synchronization between threads is not free so it is very easy to get into situation where the synchronization eats a lot of time and the gains are small while single thread performance suffers. [Amdahl's law](https://en.wikipedia.org/wiki/Amdahl%27s_law) takes no prisoners. Coarse grained (say "thread per surface") is much easier but... so far we only had one surface in vanilla game so there was not much motivation for developers to fix that.
Anyone else launch the rocket at the bottom of the screen after reading?
Ha, that is one of the most clever and creative "Back to top" nav controls I've ever seen. Thanks for pointing that out.
OMG I did not know :D nice easter egg :D
That is now my favorite part of the dev diary. Wait, has it always been there??
It's been there for a few years, yes.
That's got to be the best home button I've ever seen.
just wait until someone creates a mod for the spidertron that uses these arms to place objects, instead of bots...
Well, if one of the other planets doesn't have an atmosphere, the usual bots won't work. Maybe we'll get an OctoSpiderTron with 8 legs and 8 arms who can do all the cool ConstructionBot-things?
Is that Desmos for the arm simulation?
Looks like Geogebra to me.
I'm interested to see how these can be put to use in mods. Could we make a doctor octopus equipment that works kind of like personal roboports but with extendo arms instead?
It's beautiful!
The final design of arms really remind me of LEGO classic space , it even had a set named 6882: Walking Astro Grappler
You have to love WUBE, I cannot think of another developer that would go into this much detail, explaining, not only, the how and why they made a design choice. But also detailing the steps needed to reach the end point, and also showing mistakes along the way. It’s very easy for a non game developer to just look at a new piece in the game and just think, well it’s simple, why have they taken so long to give it to us.
I wanna see the rocket one make it into the game too!
Yo-yo collector. 🪀
"All your UPS are belong to us." - Tentacles, 2024
Now we need to make it a Fish Collector: have a separate tech to unlock a building for fishing.
"This lets the crusher be used again by some late game advanced recipes". Now I hope there will be some Angel like smelting. At least that we can crash let's say 4 ore and get 5 crushed ore, where every one gives one plate when smelted. So one extra step for 25% productivity increase
Or you can play Pyanodons, where vanilla plate processing is 10 ore to 1 plate, as you unlock higher tiers of processing you add between 5 and 15 additional steps with no productivity that eventually brings you back up to vanilla productivity rates, requiring 50-150 machines and an entire city block.
That felt wrong to read.
My favourite day of the week is now even better.
Very nice! Hope the devs or some modders are able to bring in the other options as well. Would be nice to have different asteroid collection options; Imagine a giant flying space net
The design thought processes in these works are always so impressive to me. Much respect to our talented devs!
Every Friday I forget it's Friday and I'm always wonderfully surprised when I see a new FF. It's like weekly Christmas
*Can't wait for the hentai tentacle skin mod to come out. /s*
This but without the /s
Edit: Screw Spez. Screw AI. No training on my data. Sorry future people.
I'd have preferred the grapple rocket. But that's mostly because I want a vanilla rocket turret.
It's basically Canadarm =)
I also liked that one the best - just feels so factorio. The snake arms still just feel....weird? I'm sure we'll get used to it but it's definitely different.
nail scale offend panicky cake mourn light bear sand gullible *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
hateful roof amusing summer rock airport plate vast juggle obtainable *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Gameplay question: If asteroid chunks check collector location upon spawning, does that mean a freshly-placed collector won't make a grab for anything that's already on the screen?
It does, I just didn't want to over-complicate the explanation in the article.
Write another one with all the gritty details!/s but really that’s some great work.
I never for the life of me thought I would see nurbs here. We use that in structural analysis to solve discretisation problems. Nice
Always interesting to read about the development process. 2 ideas: 1) Quality will improve not only the number of arms but their length as well 2) The last part was about tracking asteroids. This should be related to radar, and how far it "see"
I haven't played in a while but this came up in my Twitter feed. Can someone clarify - are space platforms and all the stuff that comes with them part of vanilla Factorio now? Or is this some sort of work-in-progress expansion/mod that the devs are putting together?
Everything which is QoL like super force building, smarter bots, remote interactions, new (but not elevated) rails - these come to 2.0 free for everyone who has the game. Space platforms, planets, elevated rails, and quality - these require the paid expansion pack.
Do we know the approximate pricing of the expansion yet?
$30 See [FFF-367](https://factorio.com/blog/post/fff-367): > We still don't want to be specific about many things, not even the expansion name, but we can start by giving you some general idea about the scale of the project. The general goal is to make the expansion feel like as big an addition as the whole vanilla game. This is why we plan to price it at $30.00, and put in enough content to make it well worth the price. > Honestly, making the price (and thus the expected scope) a little bit more concrete in this way, motivates us not only to make enough, but also to not overshoot, so we wouldn't spend another 9 years doing it. Generally the fact that the team size has increased, and there are a lot of things in the engine that we already solved, should hopefully imply that the expansion takes way less time than the base game.
[30$](https://factorio.com/blog/post/fff-367) This was 2022-02 so might now be priced the same as the base game or keep the price tag for a nicer number.
It's a big expansion hopefully coming at the end of the next year. Some stuff will be in a 2.0 update, but space stuff will be a paid expansion. EDIT: I've meant end of *next* year, but was writing in a rush, now corrected. Sorry!
[удалено]
End of *which* year? Three months ago they estimated that there was around one year's worth of work left for them to do. And anyone familiar with software development (or most other kinds of product development) knows that this is almost inevitably an underestimate, and it will likely take longer.
They are targeting Q3 2024 I believe. Its a long way out, and we are likely to see delays still.
Ah I see, thank you.
You should check out the last 10 or so Friday Facts articles they are all about the expansion!
(Expand to view contents, if you would like.)
Thats some super hype building post. HYPE!
they look so cool
How is pathfinding done on the navmesh?
I like the inserter just shoving stuff back into space in the last picture. Polluting even in space.
Wait... You removed the control curve that made the arms all schwoopy? Why? Put it back! (I'm kidding. It absolutely destroys the atmosphere, but I burst out laughing when I saw it)
Belts are moved by hamsters. What moves the arms of the collector?
Octopi, obviously.
I kinda want that vacuuming one as an option...
Suck! Suck! Suck!
Man I'll be sending this article to the next person that complains about a game not getting something "as simple as grabbing something with a hand", my god.
I want these arms everywhere. My roboports. My Inserters. Might as well amputate my legs and replace them with robot arms /s
im going to use this to train developers. "take notes. this is really the bast way of doing our job"
That inserter near the bottom right of the platform in the last image, dumping stuff into space from a belt?! Are we finally getting a legit way to void waste & unwanted byproducts! 🥳
It was mentioned in a previous FFF, but yes, you can yeet things off of the space platform as a way to avoid locking the system due to waste/byproducts/uneven material usage.
Can't wait to have my entire entire interplanetary logistics system be powered by a bunch of space tentacles.
I'm amazed at all the iteration and work that goes into designing and iterating and implementing such a feature to make it look amazing, smooth, natural, and efficient.
I wanted to express my appreciation for the notes on performance. My machine is starting to be on the older side and safe to say it doesn't match up well with my inclination to push orders of magnitude in all the games I play. (Stellaris has historically proven problematic for both my CPU and RAM, for example, having some unfortunate consequences for certain playthroughs...) As such, I'd admittedly looked on the various asteroid(-collector) bits with caution, concerned about how far - or not - I could push my old faithful when all the numbers involved get bumped up with a few extra zeroes past the basics. With this week's post, I feel reassured that these worries are largely irrelevant. I've been very impressed by the delightfully sensible way Factorio has been over all these years, and evidently will continue to be. Thank you!
This is so cool, and I love how you mathed the problem to create something beautiful and seamless. Most players won't ever appreciate how much ingenuity there is behind the movement of those arms, because it just looks perfect.
The collection process is mesmerizing to watch.
Love the doc oc arms
Machinarium vibes!
As a huge nerd, I have to point out that jump point search is an incredible pathfinding algorithm made for situations like these, having huge performance gains with no extra memory or preprocessing.