
Factorio is a construction and management simulation game focused on resource-gathering with real-time strategy and survival elements. The player survives by locating and harvesting resources to craft various tools and machines,
Loading summary
Joe Nash
Factorio is a construction and management simulation game focused on resource gathering with real time strategy and survival elements. The player survives by locating and harvesting resources to craft various tools and machines, which in turn create more advanced materials that allow for the progression to more sophisticated technologies. The game was released in 2020 and has been hailed as a manufacturing masterpiece. Factorio's Space Age expansion just released. So we took the opportunity to speak with Michal Kavorek, also known as Kovarex, who who is the founder and director of Woob Software which developed Factorio. Michal joins the show with Joe Nash to talk about the origins of the game, the new expansion and everything in between. Joe Nash is a developer, educator and award winning community builder who has worked at companies including GitHub, Twilio, Unity and PayPal. Joe got a start in software development by creating mods and running servers for Garry's model, and game development remains his favorite way to experience and explore new technologies and concepts.
Michal Kavorek
Michal, welcome to the show. Thank you so much for joining me today.
Hello, thank you for inviting me.
So, as we covered you are the creator of Factorio, which I'm sure many of our audience are familiar with. But before we get into the game itself, I'd love to know what was your journey into game development and what led to Factorio?
That's a very, very long answer to a simple question. Basically I'm do you know the xkcd?
Yeah, yeah.
Comics were teaching at a university about some mathematical proofs, et cetera and the guy sitting there was like, oh, this is so complicated. I came here just to make games and this is exactly how I felt when I was in the universities studying math basically. So that's generally my journey. Like I always liked games and also liked programming from very early, like 11 years. And I remember like from the very beginning when I was doing Ms. DOS programs, I did some text games and such. I always like wanted to create. So this was very natural. I even have a story that when we were like, I don't know, like in our teens, we had a system in our school where we only could play games that are developed by the people from the school. Maybe you heard it somewhere.
That's pretty cool.
I like to say it's really cool because suddenly the people that wanted to make some simple games, they were not competing with the real games, but they were competing with only other games made in the school. And really also nice system. So this actually led to us our first kind of game that we made for someone else, me and my friend, we made Some kind of variation on Worms, not worms, where some kind of worms game. And basically we were selling it for Baguette. Like anyone who gave us baguette had like license to play the game in the computer lab.
That's incredible.
It really felt great. Like it was the first. Like I was eating the baguette and I felt like, yeah, this is end. Like this is a physical thing. And I ended by just, you know, writing on a keyboard. It felt so magical. So yeah, that's how kind of. But the first, I always kind of was trying some make some games. But then, you know, like the real kind of real life happened, quote unquote. And I started to do, you know, like I went to university and I didn't really like it that much at the end because I also had to go to work and kind of support myself. And eventually I got, you know how it ends when you, when someone goes to university and also they make money, usually the money money parents. I was also already doing programming, obviously, like, but it felt like much more interesting to go to work and make money and learn things anyway than going to university more. So I basically started to work and it wasn't gaming. I was like, okay, this is the adult life. I need to, you know, do the real stuff. I was doing some boring database stuff and I mean coding in C, but doing some, you know, like the typical company something company systems. I was thinking like, somehow I don't know why I thought that, like this is, this is the game how I will live my life. But this was only like four years of my life, so it wasn't that long. And then I somehow. So I didn't like do much thinking about how to make games in this time. Like I was more trying to get my Adolf life together. But this is where basically the factorial idea was creating. When I was playing some Minecraft mods and I was also like drawing doodles or how is it like doodles, right?
Yeah.
I was doodling on a sheet of paper during the corporate meetings about how fun would it be to have factory game where you would transport things, et cetera. And this is my favorite kind of moment where I've been told at some meeting, hey, this guy will be a software architect. He will tell us now how to structure our code and do stuff. And I already had some interaction with the guy and in my eyes he was shit. I was like, no, I'm like, I'm not going to work as this guy as an architect and I'm resigning right now. Like, I just sent up says like, okay, I'm resigning from a company. And at that point I was like, okay, what do I do? I had something saved and I was doodling the factory game. So let's make this for a fun for a while and see where it leads. So this is kind of out of nothing. It just happened that I wanted to make this like a hobby project. And I was thinking, oh, maybe one day I can, you know, if I sell few thousand copies of it, maybe some, you know, some super geeky people could just enjoy it and it could pay a little bit. I don't know, like that's what my kind of thinking at this point. So this led me basically to games. But apart like the childish kind of creations I was doing when I was in my teens, I didn't really specialize in like game creation or some special courses or anything like that. But I was very like focused on trying to learn to programming basically. I. For example, one of my recurring project was I was trying to make. I was basically trying to make. I didn't really like math that much. Especially the path of math where you need to like make the like expression simplification. Like you get some big formula or big something integral or something and you need to use all the tricks out of the box to try to simplify it or something. And I, I always find it that it's not that as smart or as interesting as they try to make it. And my way of thinking how to kind of prove them wrong was I was trying to program a program that does it automatically. Like if I can make a program that does it better than me, then this whole thing is bullshit. You know, that was my. So basically I spent a lot of time trying to like improve this program of mine, which was basically symbolical simplification of math formulas, this like step by step explanation, what you do, et cetera. I was even thinking one day maybe it could be used in school, you know, for teaching that people can like see, like they can always see step by step how things are done. It was before the programs, like what is it today? You have these, I forgot the names. Like you have these online programs that you can just put that and you get exactly this. But at that point it wasn't actually there when I was kind of starting with this. So basically for me it was really. These programs were kind of really big learning point where I learned how to manage a bigger project. I also learned because I learned how to do testing because basically I had like a lot of formulas to simplify. I could have A big data test. I was trying to do optimizations, but I It like just for fun, I was optimizing how fast the test can run and I was trying to outperform it again and again. So it's not like I wouldn't do programming for fun, just, you know, like this kind of geeky stuff, but not specifically games at this point. So.
Well, I mean, I think a big thing I've learned there is that we have a single terrible software architect to thank for Factorio. How things could have been different if you hadn't been.
I mean. And also there's one more thing that's kind of interesting, is that I'm really glad that I left because like after, I think like five years or ten years after Factorio, after I left something like that, I got invitation and basically there was this big meeting of the people that worked in the company. We kind of. We met up in the pub and it was basically like to not to celebrate a special event. And the event was that the whole project, the whole programming that was there done for like 15 years. I was four years there. But it was like a big history was just scrapped and it was removed, replaced by some kind of sub or something. So like imagine like you spend like 10 years perfecting some system for some people, you still can find some kind of value in it or some kind of personal and. But then it's all scrapped and it's like, yeah, also kind of.
And in the meantime you had made and delivered Factorio and.
Yeah, yeah.
Invented a genre and found a huge audience.
Yeah. So that's incredible.
You mentioned the doodling of the factories a little bit. For folks, I don't think there's very many, but for folks who are listening, who aren't aware of Factorio, can you briefly introduce the game?
So basically I would say it's a strategy game. That's the generalities. And it's about. In a very surface or in the very beginning, it's like a research management game, like where you have some resources, you can get them, but eventually it's about processing them, having the. Processing them into intermediate products and making. And from the intermediate products you make some kind of final products. And this process can be done manually, but very soon in the game you start making production lines and automating this process. And basically the game is about figuring out like how to automate it, how to spatially put automation stuff on demand because you have logistics of belts, you have production kind of centers. And also. So this is like the first strategy is about how to put into the map. Second strategy is like what to prioritize because you can always choose what to do manually and what to do automatically. And it's about the investment and where the investment helps you the most to move forward, which where I can see parallel in real life sometimes. And also it's. It's a lot about progression, which is just. I mean, who doesn't love progression in games? It's like in the beginning you have, you know, very slow and shitty things and in the end you are launching rockets or even beyond. So like the progression is huge. You basically get more powerful in the world, not only in the sense that you would build more, but even in the sense that you can automate the expansion of the factory better because you're the construction robots and blueprints. And basically it means that not only like you produce more, but the rate of increasing of the production is higher. So what is it like second or third derivation? Still positive. So the progression is very important. And then obviously there's a lot about. There's this like when this all is put together, then there's this feeling of when you build it and you can see how the things move on the belts and how everything is connected. It feels really like nice to just sit down and look at it. That's how I kind of got my programming partner who started to do program with me into the factory. I just showed him some superlap prototype and he was like, oh, everything is moving, everything has a purpose. It looks so great. And suddenly he. So this is, this is also when I want to describe also the game. Another way of describing it is to say the biggest inspirations, which for me it was clearly Transport tycoon. It was transport tycoon for the logistics Civilization for the tech tree, Starcraft for the fight and Minecraft Industrial crafts for the kind of industrial and automation part of it. So this is kind of in a way combination of these four games that.
Makes a lot of sense, especially the Transport Tycoon. Okay. God, a whole heap of things there. I think you're so right about the seeing everything moving. Like I've been playing a lot of Factorio this weekend leading up to this chat and like, you know, my partner who has never played Factoria at all in her life, would come in and I'd just be standing like in front of my bus with like all these belts and she'd be like, oh, that looks so cool. And it's like, yeah, it does. But the transport tycoon point is really interesting because I think One of the things that I had been thinking about, you know, I played Factorio years and years ago around first release, and then since then I've played other Factory games. Obviously satisfactory is like a more recent one. And coming back to Factorio, one of the things I've been sat here thinking is like, the trains are so satisfying. There's just something magical about the trains. I don't know how you've achieved the feel, but they feel so good, unlike any other train game I've played about it.
Basically. I remember that. I mean, I am not a huge. What is it the Transport tycoon like? Fine. I mean, I like the game, but compared to some other people, I'm a huge noob. Like, for example, Vaclav, he was just the main graphics manager in our game and Factorio, he was making mods to the game and playing it on an extreme level. But basically what I always disliked is, first of all, I know it's kind of. They don't move in smooth curves and very often, unless you use some special settings, they can just magically rotate in stations. I always liked the idea that you wouldn't have these things and it would actually, like. It would be kind of harder to connect everything and it would be like the trains you would really think, you need to think how to make them physically move properly and rotate and everything. So this was a motivation to make it feel a little bit more like real trains. But it's. Obviously they are like even more realistic games about trains, but then they don't really have the. The building part of it and the strategy part of it. Usually that's my feel.
Yeah, the note on realism, I guess. This brings me into my first game design question. So for listeners, I'm going to refer to a blog series by Factorio called the Friday Facts A lot, because you get into a lot of interesting things in the Friday Facts. So one of the things you frequently kind of talk about in your Friday Facts when you're looking at the development is like, you always have this really good line of commentary, which is like, you know, we tried doing something this way, which is the more accurate version or the more simulated version, and we found it was just like, not fun or we found it was too grindy. And so we made this concession to make it a better gameplay experience. And I think in general that's something that, you know, your team seems to do extremely well, which is like managing to make what is still a really satisfying simulation, a really satisfying system. But you're like managing the shave the Corners off to make it also, you know, a better game. Can you talk a little bit about how you approach, you know, balancing those two things?
It's kind of very simple. We have a rule that it's always fun above realism, right? This rule is just like you can carry hundreds of locomotives in your inventory. I mean, but. But obviously it's like there are different kind of things. How to say, like sometimes some things are not realistic and they just are fine in it. You can get away with it and people or whatever. Okay, I can carry 2200 locomotives in my inventory. It's funny but you know, it's still okay. But if the trains randomly move on the train, like some things are kind of only technical details because like, okay, it's one character. Maybe the character could move locomotives somewhere. Like it would be solvable problem. But if you are in the parts that matter that are kind of critical to how you look at the system, like the trains not kind of magically turning, for example at the ends of the rails. This is the part where it would be maybe even like smaller non realism if it did that compared to cutting the locomotives. But this is the part where it just feels more important. But generally we always. So for example, we have the space age and we were just. Now we have the distances like, I don't know, between the two planets. Currently it's like 15,000 kilometers. Even my son was saying like, oh, 15,000 kilometers is almost the same as around Earth. Like it's too close. Like you should change it and maybe we will, maybe we won't. But it's not really. These things are not really that important. Or for example, especially when SE player I think if I play a game or if I watch a movie, I think it's kind of related subject. Like in a lot of the movies and shows you can see like, I don't know, like some sci fi movie and they make a premise like, I don't know, you can teleport or you can something. And obviously I be like, okay, I know that probably it's not possible, but I'm okay with it. If the premise. This is an axiom, this is a premise. And let's see what you can do with that. It can't spoil my fun. But the problem is when they make premises and still it kind of doesn't work together or it's like there's some.
Logical fallacy or they spend an hour explaining the premise, right? There was like this period of films where they couldn't have any fake science without having some guy With a blackboard. Explain it. And I always say this is why Pacific Rim is an amazing film because it's like there are giant robots, there are giant monsters. End. Let's get to the film.
What movie?
Pacific Rim.
I don't know.
You'll enjoy that one. You'll enjoy it. Yeah, that makes a lot of sense.
Yeah. I remember watching Planet of the Apes recently and they also had this like they moved in time. I was like okay to get a visit but they had to spend like 10 minutes explaining some relativistic sci fi bullshit to somehow try to explain it. But basically so into the game we always go realism over fun. But if we can, we try to kind of make it realistic in the places that make it feel good. So like for example, you never really teleport items in the game. They always kind of move smoothly or I don't know, they are there. Yeah. Generally everything needs logistics that's kind of important. Like when you for example build stuff, you can build stuff remotely but some robot needs to go there and carry the item. I okay, the item might be a big rocket silo and smaller robot is holding it. In this case it's a little bit funny, but at least there's this still physical connection between things. It's not just completely magic. So I think there's some kind of experience of how it. It's more about how it feels and how actual realistic it is. That makes a lot of sense for sure.
So you mentioned there, I think needs to be connected by logistics. Things always been moving around. Which kind of gets me into my first performance question, which is obviously you've made a game here where by the end of a normal play, not even getting into the new expansion Space Age, but of a normal playthrough.
By the way, we have a quite a good timing because yesterday we basically lifted the embargo or any kind of information to factor in Space Age. So even some of those streamers that have the game can talk whatever. So I can also say whatever. So we don't need to be afraid about spoiling anything. It's now it's everything is. You can ask whatever. It's just a small.
I don't want to spoil the ending ending. But we will talk about the planners for sure. But yeah, so you know by the end of a normal playthrough an average player has has millions and millions of items moving around belts, there's robots, there's acres and acres of machinery. And having now read the Friday facts and seen all the work you put into Optimization. I understand a little bit more about how that's possible, but I guess fundamentally my question is, what is the architecture of the game? How have you built a game that can manage, I guess, to give a flavor to the audience? You use belts to move items around and you have hundreds and hundreds of these things all over the place. And the game is not only 10%.
Of thousands, more likely.
Yeah, they're everywhere. I accidentally damaged one at some point, removed it, had it in my inventory with again, thousands of thousands of belts. And like an hour later I was placing another belt and out popped a belt with a low bit of health, like, because it had retained it and it was somewhere just in a stack.
So that's the simplest thing. Like, you know, like having.
Yeah, absolutely.
Like, obviously the hard part is to make, like, optimize what. Like what actually matters is other things that are in the world and have to run all the time. So basically, performance was issue or not issue. I was aware that performance would be a problem for the very beginning because as I said when I before I started Factorio, I was playing some of the industrial mods in Minecraft, which were in some parts a little bit like Factorio, but obviously still very different. And the main issue was whenever I tried to build anything even remotely bigger in the factory of times it would be like starter super small starter base. It started to lack a lot because the game engine just wasn't built for it. And so the obvious kind of motivation was to make engine that's built for that. So it's like from scratch. It's built to actually support everything, support a big performance, potentially. Which mainly means we have access to change everything in the game. Like it's in C, there's no engine and we can change data structures of absolutely everything we want. But then it usually. It's not like it was performed from the beginning. It's usually we made a factory and eventually started to be too slow. So, you know, we made it to typical cycle. We found this one thing that was slowing in the most, found some way to make it better and then play it again and they made two times bigger factor. And it's like, okay, now something else is slowing it down. And basically step by step, we were learning and identifying what needs to be done to improve it. But generally, on a general level, the most important things were what we found. You can do things like optimize the disaster structure. So things are, for example, when you have some entity or some stuff you process in a linear piece of memory. It's like 100 times faster compared to when you have it randomly in your memory and you have to jump from place to place in memory and things like that. These things help a lot. But also the thing that mostly helps are when you have to do nothing. Like when you optimize things in a way that you don't actually touch things when you don't need to. So for example, when you have a machine and it has nothing to do, it just goes to sleep and it's only awoken when it has worked to do. And the same with inserters, like basically trying to only kind of update things that are actually updating at the moment. Because even the very optimal build factories, very often a lot of the parts don't work at the moment. So there were kind of many tricks and things we had to do to make it possible. And then there are a lot of custom optimizations. Like for example the belts. I think they have in a way kind of beautiful but simple structure that basically if you have belt, I don't know, it's the maximum length. But let's say you have like 1000 meters long belt and input things on one side and take things at the end. It has like complexity of a one of moving it because you basically you have like one piece of memory that says like relative position of the things and you just move one number saying what is the relative position of all the items? And then you only check the ending of the belt if they don't kind of some special cases that can happen there. And then you check the starting of the belt where you put items or something. But basically you don't need to kind of touch individual items on the belt because you move the belt as a whole. And things like this, obviously if then done properly, they help a lot. So there are many things like that. Like we can discuss some of them in specifics. I'm just giving some the first examples that come to my mind. So most of the optimizations that are really efficient is like, I would call them like business logic optimization when you kind of actually improve how the logic of it works instead of improve the actual instructions in the code.
Joe Nash
Do you love classic console video games but don't like paying unfair prices? Video Game Marketplace makes it easy to browse entire video game console libraries and then buy games directly from individual sellers with no extra fees. Looking for a sealed copy of your favorite game? Or just trying to collect all the games in an obscure RPG series. Maybe you just want a cheap used copy of a classic platforming or fighting game. Go to vgmarketplace.com to shop for retro console games and find the lowest prices online. VGMarketplace makes it fun to hunt for the classics you know and love, and those rare hidden gems you've always wanted. Check out vgmarketplace.com that's vgmarketplace.com okay, so.
Michal Kavorek
I do want to talk about some specific optimizations, but I guess before that, even in the game, it refers to things like ticks. And if you play factorial for an amount of time, you'll encounter ups and, you know, the idea of updates per second and this kind of stuff. Can you, I guess, run through briefly what the system is underneath that? I assume there's some kind of communication layer where every machine that can post something to a network is doing. So is that kind of.
What do you mean now? What do you mean? System of what? Of the whole update of the game or.
Yeah, I mean, what are the ticks? When something generates a pout, it's like one update.
The principle is simple. You have 60 updates per second. Because 60 ups, like 60 is a number.
30 is to looks good at 60.
Yes, exactly. So it was specified as or withdrew, which means you have 16 milliseconds to just do one update. And in the 16 milliseconds, ideally you just update the logic of the game. And also somehow we need to render the game at the same time. So typically what we do is like, the problem is when you are updating the game, you can't really like, render the game at the same time, or like you can, but you need to do it like. So what we do is like, we do what we call prepare. So we try to like, we are rendering the game at the same time as updating the game, but then there needs to be like one specific moment where we kind of collect all the data to be rendered. So we kind of collect basically like a list of data for like, this sprite needs to be drawn. We call it draw queue. It's like this sprite needs to be. Need to be drawn, like a plan of what we want to draw, which can be generated much more quickly than actually drawing it. So kind of we stop the game, everything stops. So we have like consistent state of the game at the end of after the update that we try to actually, in parallel, we collect these draw orders. So we kind of distribute the screen into some parts and we collect basically instructions of what needs to be drawn as fast as possible. Then once it's done, the game can the logic of the game can start updating the next step already. And then in the other thread, there's enough of time to kind of go through these draw queues, sort them properly, and then actually draw them into the screen while the game is being updated. So that's kind of the logic under this. I don't know if that's what you asked.
Yeah, no, that's great. Yeah, that's perfect. Yeah. I mean, answer my question via absence of something, which is.
We even have. I remember we have some specific Friday Facts about it. It's kind of interesting because as you already not mentioned the Friday Facts blog, we have sometimes, for example, now we have a change log of the expansion and I realized that half of the features we have there already covered in the Friday Effects would actually. I use the Friday Fact as like a reference, as documentations. Like I write in the change log, like, for example, how we edit elevated trails and I just put a link to the Friday Fact to see it with pictures and everything in description. Or it actually even happened in our company. Someone asked how is this done? Like, for example, the question you had, like, how are the stages of update versus us? And say, yeah, five years ago we made the Friday Fax, these pictures and everything. And I just link sometimes our developers to the Friday Effects as a documentation to the game, which is.
Yeah, it really is a fantastic plot. You meant, you know, you were saying earlier that the belts are like 01. Like, I have not encountered this much big O notation since my computer science degree. Like your team talks so much about, like, oh, this operation is like on depending on how many inputs it has or like all the time. It's really fantastic. It's a really good plug.
It's great. But I mean, the way we use it, it's not something you need to degree for language. Like you have basically one or like N N squared. And I think more is you don't care.
Yeah.
And so it's like three layers of what you can do and that's it. But obviously it really matters. Like, for example, we have a logistic network in the game where basically you can put. You can have like a system of chests. And whenever you put iron in one of the chests and you need it somewhere else, the robot can kind of immediately go to the chest and transport it from one place to another. And for example, this one is always also 01 the search for. Because there's this problem, like you have 50 different items in thousand different chests basically scattered all around. And it could be potentially not really that simple to Find. What do you mean? But basically the point is that every item has its own linked list of where are stored kind of things of that item in the map. So when the robot actually wants to see where is iron they find the proper list for iron stuff and then just immediately sees okay, it's in this chest. And things like this actually matters. I think it kind of also makes it a fun experience to learn about the optimization and this own notations in practice. Because one thing isn't being taught it in math class or in programming 101 class and think like oh yeah, this is something they already are teaching about. When you actually make like N squared algorithm for something and in one year it bites you into ass because someone gives you safe oh, this is super slow, what's going on? And you find out there's some N squared algorithm and you just fix it and suddenly it's a hundred times faster. You kind of get feel for how big of impact has it and suddenly it doesn't become becomes much less abstract because you kind of have to deal with it on daily basis. And it also obviously you need to be kind of pragmatic. So sometimes we say like yeah, this is not ideal algorithm, but they're not. For example, with trains, I remember we were doing some train logic and we said like yeah, this part of the logic is not that fast. But that will never be based with more than like five to 10 trains. So it's fine. And then now there are bases with thousands of trains. So we always had to change our assumptions about what kind of numbers can we expect in different things. And they always get bigger.
Is there I guess onto specific examples of optimizations and the idea of players defying your expectations. Do you have a favorite? We can't believe players did this. And it completely broke our assumptions. Example. Is there any particular optimization like your.
Pet that's so many. It's kind of. I remember one of the first ones, I had two of them. One was that, I mean it's not really breaking the game on purpose, but it was kind of. One of my favorite errors was in the very, very, very early stages of acterio. We were trying to debug a tutorial like to make people understand and we made some friends or random people play it and there was this like we put an arrow in the game to show something that's something they should do. And somehow we made an error entity in the game and we didn't realize that. And we also had transport belts and the transport belts worked in a very simple way they just move stuff. So we realize, oh, you can just put a transport belt and the transport belt moves the arrow from the game away, you know. Or for example, when they made when we may put cars that you could put things into the trunk and we have transport bots and suddenly people realize they can put cars on transport belts and suddenly they have different kind of transport belt that can have a big storage capacity. So things like this obviously happens and especially with the cases like, I don't know, is the trains. And mainly many of us, the scale of the stuff, like we make a robot network and someone saying, oh, the game is broken, it's getting slow. And we are like, you know, we are in panic. We open the safe, what's going on? And whenever we open save, it's like hundred thousand robots, you know, like a swarm of robots everywhere. It's just, you know, five ups. And so like. And I'm thinking like, okay, so this is not a real problem. Like you just have a. Like at some point people expect it to go to infinity and whenever it's not like fast enough, they think it's a bug. So these are the kind of things that sometimes happen, but I probably don't have too many examples out of my head. I will probably remember some of them as we go. But obviously people always come up with crazy stuff.
Yeah, yeah, I guess the optimization is a problem for both the players and the developer. I think every sandbox game has this problem. Right.
Also the main thing that makes it crazy to make things proper is mods also because like that's basically all these things are multipliers. Like you have a game that has multiplayer, like multiply your death complexity by at least two. You have mods. Multiply everything by at least two again and you have, I don't know, like you have performance, you need performance. Multiply it all by two. And because it's. These are multiplying because like if you have mods, suddenly you, you know, like if, you know, I don't know. For example, like, yeah, we have a chest and we know, okay, the chest has 40 slots at MAW. So it's. We can have some constraints about how to access the chest, how to work with it in the core. But someone makes a mod and suddenly the chest in the mod has 10,000 slots and suddenly they complain that it's slow. And we never thought about this extreme. So basically the mods kind of make extreme settings, extreme interactions of stuff. And it's like so much harder. Like everything that you are normally in the game development things are kind of stable, like your objects are stable. I know. And suddenly everything you work with can be whatever. And it's especially in game like Factoria, when things need to be super reliable and everything can interact almost like with. Not everything with everything, but things can interact a lot. It can make a lot of crazy stuff. And we always have to anyway, like, even if we try to kind of fix everything reasonable, but always we have to draw a line and say, like, yeah, this is too crazy, I can't help you.
Yeah, I mean, people always do deranged things with mods. But, you know, mod developers discovering the hard way why the core team has implemented something. How they have is a cursed genre problem. So on mods, as many sandbox games, you know, they see a second life through modding. And the community around Factorio's modding seems great. And in fact, I believe you've hired one of the modders for Space Age, right, Arandel? Yeah.
Yes.
So I want to talk to you a little bit about how you approach modding support, how you thought about the API and the developer experience of that.
Yeah, I actually this one of the things that I think I did really. Right.
Cool.
Because I had some experience with the Minecraft modding before starting the Factorio. I didn't really mod myself, but I was kind of trying to use it as a user, like applying the mods or like looking. I looked a little bit under the hood how it's done, and it was. I don't probably change in the meantime. I didn't look into it in many years, but it was kind of horror because you had these things where, for example, the blocks had integer values like, okay, block five means something and block six means something. And then if you had a mod, people had public similar tables where they kind of negotiated which numbers are used by which mod so they would become compatible and kind of had to make like making two mods work at the same time was a lot of work. And basically you had no API. So they would either kind of hack JavaScript directly and whenever you had conflict, you are fucked. Or you had these special mods which basically, I think it was called Forge or things like that. Basically programmed API for the mods, but they were different kind of kinds of them and different versions. And then when they wanted to update the mod, there were different kind of places where you can download the mob. It was like it was kind of a hell. And I was thinking that it shouldn't be that hard to make it better. And one of the first thing that I made is to make the ID system, which I think is really great. And the point is that every kind of we have like, I don't know, we have dozens of independent ID kind of sequences, which is basically like in Minecraft you would have the block id. And here we also have something like that. And it's numerical. Like when you run the game, for example, I don't know. Items, item have every number of like every number means some different item, but it's internal thing like the actual number, that's that. For example, five means iron plate and six means copper plate. It's not accessible to modules in any way, it's completely internal. And the modules always work with textual names. So they specify for example iron plate. And we have like. So in the beginning you say like this entity when mine gives you arm plates, et cetera. And it all based on textual id. So if someone wants to be sure that it doesn't conflict with some other mod, all the mod needs is to have unique textual name, which is pretty simple to do. And then under the hood we just assign numbers to the textual IDs. Like you start a game, we make a dictionary of what textual ID means, what item. And then basically it all runs on the numerical IDs, which are obviously more efficient. And only when you do things like use the API from remote scripting to do some stuff, they still use the textual stuff and use a dictionary to actually translate it to numerical stuff. So this means that the numerical values of what means what can be different and every safe and it's fine and they don't need to kind of negotiate anything and it just works Generally the main idea is to make it possible that two mods can. There's a. Like to increase the probability that two mods that even maybe modify similar kind of things can work independently without even having some special care to make that was made to make them compatible.
Yeah, they don't have to be aware of each other at all.
So ID kind of system was the primary thing. And then they were like basically obviously even the fact that we have the API. So basically every mod is a package. It's like one zip package which contains the definition of the objects or modification or other objects. You can have basically dependencies of which defines basically either what you want or the order of the things. Like this mod says that it needs to be loaded after some other mod. You have like three stages of updating data and we really try to make it that the API is friendly and they can kind of work Together nicely. And also what I think is very important is the mod portal. So basically we made one, we created one official place where mods are. And I'm not even sure that there's some other like unofficial mod portal. Probably not much because it's just integrated into game. It just works like you see a game, someone sets you a game, or you see a multiplayer game, you go to the game and you can just press one button, you know, install mods and join the game. And it's. Maybe it already is like this in Minecraft community, I don't know. But at that time when I was dealing with it, this was like sci Fi. And this is just. I think it's so important on. So basically I try to make it like easy for modders to solve this problem, easy for users. So they just click one button and it works and kind of save for us. So we have like one specifically specially defined API, which is the public one with documentation everything. And I believe that it worked.
Yeah, yeah, it definitely seems to have done. Yeah. And the API documentation I think is also really. I feel like a lot of games that have mod support, sometimes you have to dig a little bit to find it. But you make the API docs like it's in the top nav on the main website. Right. It's very prominent and easy to access. It's very core to the experience.
Yeah. And we are actually improving it a lot in the upcoming release because we were documenting like for example the API like what you can call, methods you can call, but we didn't relate a comment automatically, like the properties of different objects. And now we also have that. And here the big improvement we made is that we basically generate the API directly from the C code. So we had like, I don't know, for example, I have like car prototype object in the C which defines how car prototype is defined and its graphics and everything. And there's also this method which loads its properties from a property tree like the JSON or something that it loads it from. And always this method has like a comment which is used comments every field for generation of the documentation that it's then kind of script from the code and document it from that. And it's super important that it's done this way because when some programmers changes or removes or adds something, when it's right there like you are changing it and above you there is documentation and you would know that if you don't update it to file itself, it's outdated, there's way, way higher probability that it will stay up to date compared to having some wiki somewhere and then someone externally trying to keep it update. So not even like mentioning that now you have kind of like two versions separate and you have recommendations for both over there we can look at like versioning of documentation, et cetera. So this is something that was improved in the last years a lot and I didn't really. This is not like my work. Other people are doing it, but I think it's really nice.
Yeah, absolutely. Yeah.
Joe Nash
This episode is brought to you by WorkOS. If you're building a B2B SaaS app, at some point your customers will start asking for enterprise features like single sign on, skim provisioning, fine grain authorization and audit logs. That's where WorkOS comes in, with easy to use and flexible APIs that help you ship enterprise features on day one without slowing down your core product development. Today, some of the hottest startups in the world are Already powered by WorkOS, including ones you probably know like Perplexity, vercel, Brex and Webflow. WorkOS also provides a generous free tier of up to 1 million monthly active users for user management, making it the perfect authentication and authorization solution for growing companies. It comes standard with rich features like bot protection, MFA roles and permissions, and more. If you are currently looking to build SSO for your first enterprise customer, you should consider using work OS. The APIs are easy to use in modular, letting you pick exactly what you need to plug into your existing stack, integrate in minutes and start shipping enterprise plans today. Check it out@workos.com that's workos.com and we'll.
Michal Kavorek
Come on to I guess the evolution of the studio and how increasingly it's you're managing hordes of people. But first of all, we've mentioned Space age and Factorio 2.0 a little bit. So I guess before we go any further, at the time of recording we are a week away, less than a week away from the Release date of 2.0 and space age. I guess let's start with 2.0. The base game, which is 2.0 is a free update for everyone who currently owns Factorio. Right. What's new in 2.0?
Many things like the Rails. The most kind of intrusive things probably is the Rails being changed. So now basically we changed the shape of Rails and this means that you have more possibilities now the rails have 16 directions instead of eight and you have smaller shapes which are more modular so you can make like S bands and things like that weren't possible before, which breaks Kind of a little bit previous saves because the shapes are just different. But then there are a lot of quality of life changes. For example, we have the train system. And now before like what people have in the train system like in current version publicly is that they can specify a train like a schedule for the train. Like go to the station, go to the other station and cycle this schedule basically. And every station has some set of condition how long it should wait. But if I'm not mistaken, that's basically it. You can have some circuitry around it like you can connect circuit network station and control how long this. But you can never control where the train goes. And what we changed in 2.0 for everyone is now we have way stronger and in my opinion more interesting way addition to the control of the trains. You can basically make interrupts. And I specifically wanted to call this interrupt because it's such a fitting name. And basically now you can specify like have a list of interrupts and you can have condition when something happens, go to some specific station or sets of station and do something. So basically you almost like program the trains. And obviously there are some very simple examples where it's useful. Like for example, you have a train going between AAB and then you have interrupt. Okay, when you start to have not enough fuel, go to refueling station and then continue what you are doing. Or you know, but obviously there are like much more interesting use cases for it. But this is one of the bigger changes for people that play. But then there's. It's really hard. I would have to open the changelog and scroll through it. But there are many. Oh, let me actually, let me actually it's a good idea because I have the biggest changes. By the way, our changelog would barely fit a diskette. It's almost 1.4 megabytes only the change log from the beginning. It's absolutely crazy, but truly worthy of a 2.0. Yeah, we have train groups for example, which is like you can like now change trains at the same time. We have logistic groups which means like you can also like you can group what you request in logistic chest and just kind of change them all at the same time. Which is specifically done because space age because this is more into points where we try to kind of minimize the annoying parts of it like of the fiddling. Like you for example want one item now transported to all the planets and you don't want to change, you know, somehow. What do you do on the space platforms? What do you do on the planets? What do you do you can set it up in a way you just change one request and it is actually transported everywhere eventually automatically. Yeah, we get it. Factoryopedia, which is also like, it's basically like in game Wikipedia about the game where you can check many things that aren't even like checkable before.
Like which way is I think a very underappreciated move because I feel like every sandbox game nowadays has a compulsory Wikipedia that you need to have on the side. So having it in the game is so good, it's amazing actually.
It has pros and cons, I remember and it's kind of not the case anymore, but for me, interesting take is that one of the reasons why Minecraft was so popular back in the day, I mean, not saying all reasons, but one of the reasons is that it didn't have any hints whatsoever how do you craft things? It was complete magic. And I think it created this interesting kind of symbiotic relationship because people didn't know how to craft stuff. And either you could look at wiki which already kind of made some traffic and made people more kind of move into communities. But then you had YouTubers which were explaining things like in groups and how to do things. And the YouTubers because they were kind of drawing, because they were making videos, they were drawing more people to the game. And then the game became more popular and more YouTubers wanted to use the game to actually become popular. And this kind of cycle, I think made it popular and maybe, I mean it would be kind of interesting if I could make another universe and see what would happen if actually made a proper documentation in the game. Maybe the game wouldn't be that, maybe it would be just half the popular. It's really hard to tell because suddenly they wouldn't have to go out of the game and work to YouTube. So it's not always that clear what's better. That's what I wanted to say.
It's a really interesting thesis. Like game design for influencers is like, yeah, yeah, I love it.
I mean these days it's not that kind of out of the box thinking these days. But at that time when Minecraft was new, it definitely wasn't a thing to think this way. But anyway, the factory PDI is really like we realized it's space age that especially with smalls or space age, it's kind of really nice to quickly navigate through. Like, okay, what is this? Like typically like I get an item like what is this item used for? I don't even know. And there was no way Actually figuring out what is this item for? Or where do I get this item or you know, like, what are the alternative ways to get this item or in which machine I make this item. What all the things can this machine make? Like, all these things are now kind of in one place. Like. And we spent quite some time to. More and more info there. So let's see how like, for me, it's like I actually, even when I know the game, I use it daily too because we still tweak stuff and change recipes. So I'm not like 100%. I don't have 100%. Everything in the brain was. Was the current state. And I always use factory period to check on stuff. So that one is like. So I mean, yeah, super. First building, like now in the game you can just do Control shift build. And it means you build, you remove everything in the way you remove and you build like, you know, everything in the game. Smart for the construction like this or the search. Like basically one of the things we are also, I think over time we are improving. I'm trying to make this UI to be stronger than anything else in the game. And this is, for example, the search, like every window, almost every reasonable window has. You can press Control F and search in the window. It's so useful because like, it's not so much work to do. But for the player, it's like when I see a window with hundred things and I have to search something with my eyes only and I have no way to actually, like, we are so used to it in the browsers and everywhere. So why not have it in the game? And now what we edit, like kind of extreme version of it. You actually can play the game, not have any window open opened. You play Control F and you search in the map as a whole. What? Yeah, like you search like for example, the typical thing like, oh, where do we actually do we make, I don't know, assembling machines threes in the say, because eventually the factory is a bake and it's a mess. Or you play multiplayer, you don't even know or you don't remember. When it's done, you just press Control F assembling machine three and it just highlights you in the map. Okay, this is the place where we make it and you can just go there or you can search like deposits like where is coal? And you can kind of highlight the nearest coal deposits or things like that. So basically the point is that I think it's really important these quality of life features. When I look at it from the high level perspective, we are trying to improve the density of fun. And it's not fun to spend five minutes stumbling or not five minutes extreme, but even if it's like 30 second stumbling in your base and oh, where was it, where was it? Not here, not here, not here, it's not fun. It's just no one wants to do it. But it's fun to design and to kind of, you know, to be as much powerful as you can when it comes to figuring things out and building and actually make the spend the time designing and improving, et cetera. So like all these quality of life things should improve your density of fun. I think that's actually I never use this connection.
It's a good, good tagline for the design. Yeah, density of fun and also very appropriate to a game where you build a lot of very dense structures.
It's like, oh, this is actually one of the most geeky things I think I did and I was actually curious if it's too much and it's the blueprint parameterization because in the game, just to tell to people that might not know much on the game, like you can do game, you can just basically make blueprints which is you copy paste part of the base, typically some module or something that does like mining outpost or a train station or some intersection or anything. Basically in the factory you can copy into item as a plan, we call it blueprint, you can save it for later and build it later somewhere else. And what we did, what I was thinking about is that I was thinking that this is not enough and I made a blueprint parameterization which means you can basically make a parameterized blueprint with generic stuff. I would compare it to template in C, for example, you make a station which unloads iron and maybe you have iron filters on the inside. So never know, bad things can come to it. And the name of the station says that it's iron drop off station. And normally you make bridge of the station and you need to configure the station manually to what you want. But maybe if you have a kind of blueprint in which other filters and the name of the station was set like parameter zero. And upon building you are always asked like okay, for this station, what station is it? Okay, this one is iron and it sets all of the parameter things kind of, you know, fills them with iron Python and then you click just next to it and you make an iron station. And basically it can be used for many things. Basically anything that you can configure in a Game can now be kind of specified in a generic way, put in a blueprint and then now and you can parameterize numbers, you can parameterize, you can make like formulas. One number is depending on other. And basically you can, this way you can make like a template that's really strong for building things different ways. And I was thinking that this might be a little bit too geeky and I kind of wanted to do for a long time but I was thinking maybe it's too much and it's like I'm, you know, it's over the top. But then I was thinking I'm not that special. And in fact that I was paid with the idea that hey, the game is maybe a little bit too complicated for like average player, but I'm going to make it fun for me and maybe there are enough of people ever enjoy it. So I was like, if I want it so much, I think there will still be people that will enjoy it. And based on the playtesting because we have some kind of beta testers apparently some of the people are using it because we had like a lot of kind of tweaks around it because a lot of feedback around it. So it's. Apparently it's not completely stupid. And this kind of feature is nice because it doesn't make the game more complicated. If you don't specifically press, there's like one small button in the blueprint you can press parametrization and that's all like it's not in your way. It doesn't make the game more complicated. So I love these kind of changes where when someone wants to do power user stuff, basically they can, but it doesn't make it less approachable.
I think you actually give that. When the first time you use the circuit system you get a pop up saying like, hey, you don't need this to complete the game, but it's like useful if you're doing it. What system, sorry, the circuitry when you're using, I think you actually have a pop up that says like this is complicated, you don't need it to complete the game. And I like that approach because, you know, you have power users, you're very popular, the software engineering community as a whole. Like you have people who will enjoy that stuff but it doesn't get in the way for people who just want to, you know, do it manually, for example.
Also with the circuit system, it's also interesting, I think it's really. Because I actually never really use it that much before we developed Space Edge, the circuit system, I use it Just for the absolutely basic stuff, but not anything more complicated, like two wires and something and apart. When I was playing blights, et cetera. And in the space age, there are case, like, there's definitely more usages of it, more places where it's useful. And also I learned some tricks from Vasa which are really cool. And I realized, oh, there's some like. Because there's really. Again, it's just a big difference. Is this system complicated? Or like, do you need. In a way that you need to be smart to get it, or is the system just annoying to use? And it's really important to differentiate these two things because it might sound obvious, but a lot of times these things are misplaced one for another. And we made some little tweaks of it, general ones, which might look not that important, but they just make it so much. For example, when you open, you connect something to circuit network and you can make a condition like, okay, if, for example, you connect chest and insert and you make condition only make this inserter active, move things from one place to another when there's more than 50 items in the chest. So basically, suddenly you have some indirect logic. And we made a little piece of logic that in the slot where you specify what kind of signal item is it related to, you see a number. What is the current value? And it's a small thing, but suddenly like, oh, this is the right number. I know it's connected and the number is already there. And I know kind of is it working or not? And you can immediately see the formula if it's true or not, the inequality, not the formula. And I mean, these kind of things, even when you are suddenly, you realize, oh, it was not me not being stupid, being confused by it. It was just the system being a little bit, you know, a little bit around the corner.
That's such a good example. I literally used that on a belt sorter, like two days ago. I was like, I'd have no idea how much material was on this section of the belt. How do I set this? And it was right there. It was. Yeah, exactly.
I know, okay, this is. When it's this full, it means around this number. So we kind of know. Yeah, it's all not only for understanding it, but to know what kind of numbers. Yeah, exactly. So I think that generally, like, I have a feedback that, like the train changes and the rail circuit changes, they made it much more approachable. And I have actually feedback from people that have been playing a lot in the past. And they said, like, I never used my Train much trains or I never used much circuit. They use these systems much more now because they are just more approachable. So this is a big takeaway. And still these are all things that are for everyone in 2.0. So this is my answer. I mean I could go for a long time, but you know.
Yeah, it's funny, as I said, it's been a while since I played. First of all, I think I had under and I've been playing on 2.0 last couple of days. I don't think I had realized how many of these things were like recent improvements. But yeah, it all felt really nice. So on the space age we mentioned multiple planets. I think there's five planets.
Well, five together. So four new planets basically.
Cool. Okay, four new planets. I guess the main thing I want to talk about the planets is the thing you've done. And again you can. The Friday blogs kind of COVID what each one does. You've tried to make them not only unique biomes, but they also have kind of all their own tech trees and mechanics and different environmental conditions. I guess just as a design question, how did you approach deciding okay, we want to expand the tech tree. We want all these plants to feel distinct and have unique mechanics.
Well, so this was kind of very straightforward. First of all, I played some other game, I don't want to say the name but basically where you could go to other planets and etc. But all it was was that you go to other planet and it's a mining outpost and basically you get everything home and then you build and it's kind of meh. It's kind of okay. It's just a different way of getting resources and doesn't feel that interesting. So we definitely knew from the beginning that this is not what we want. And we wanted the planet things to be like more like not that everything goes home, but things move in different directions and it's kind of a net of kind of factories that work in tandem and kind of import and export different things. And the second thing we kind of wanted from the start, but realized even like later how. How important is it is to minimize the repetitiveness basically like to if. If in the extreme, if all the five planets are practically the same, it's just like one special thing. But you like 90% of the time you make the same thing on the planets. It's just repetitive and boring. And so we try to from the beginning, obviously we try to make them different and we try to make different mechanics on different planets. But I didn't realize and I Had blog posts about this. How much more different they should be compared to how little they were different at the beginning. So we kind of making it with every iteration internal which was like one year basically we were trying to make them more and more different because we realized, oh, this is not enough, this is still not enough. And now and we ended up in the state when there are really a lot of different. Like the difference is huge. So yeah, it was important that. So basically also it means that having just like more. This is another thing that having just a lot of recipes and everything be the same. It's not necessarily more fun. It's maybe the opposite. Like having if we just edit 50 more recipes with different icons, but it will be just always the same. Like you put these two items and the third item goes out or something and it's just again and again just on different panels with different little bit different graphics. It wouldn't, wouldn't mean that. So we were decision and the point was the. How was I saying it was mechanics to content ratio. Basically like how many new mechanics you have compared to how many times you do the things you already know. And we were trying to improve this ratio also. So this is why we have planet with my favorite and kind of the most quote unquote hated but Italy. The mechanic is the spoilage.
I do say clever.
Yeah, yeah, yeah. Like I knew from the beginning that I want this and this is, this will be fun. And basically now we have planet where everything spoils and you need to deal with it. And it's completely changes the way how you think about resources and how you think about the production chains. Because everything is kind of. Everything is renewable. So you don't really think in a way like oh, I will lose stuff here if I don't use it. Like you say, like I don't care. I just throw everything. Because new stuff is coming infinitely and you just do stuff differently and suddenly everything is different. Like you build different and you have other planet with. You have the full Quora. But there's a script. So instead of. You don't have any resources, you have just script. And from the script you get all more or less like high end products. And instead of like making from simple to complicated here you kind of put it on its own head and you make it from the complicated stuff and recycling them into more simple, more simple stuff that you need. So normally you use iron to make iron gear wheels. And here you get iron gear wheels and if you need iron, you need to recycle them to get iron and suddenly, like, again, like, you need to start thinking differently about it and you need to throw a lot of stuff, which you don't need because the ratios are different. And basically suddenly the way how you think about these factories is actually like really different from factory to factory. And the kind of the things that you do the same way are I think, like, minimized a lot now. So from basically, I think that what we kind of hoped to have is kind of happened. And I'm kind of happy actually with this because as like two years ago I was kind of in depressed that in my book was. I was saying, like, I was thinking, oh, maybe this is all a horrible idea. Maybe this can be done and it will be just boring and this whole thing, they'll have to be scrapped because it's not worth it or something. And it was like existential crisis. Almost like, oh, what am I doing here? Like, I'm a fraud. What's going on? But then, you know, after the two years of actually focusing on this and not giving up, I'm really happy to say that it doesn't. Didn't end like this and that it's really important to have this approach of, you always look what's wrong and you are not afraid to say it, because sometimes people are most afraid to say. Because imagine you are working on something for like two years, there's a team of 30 people, and you made something that's like half almost done. Or you feel like it's almost done, and everyone kind of feels like it's not that good. But, you know, it's kind of weird to say it loud, you know, it's kind of awkward. So everyone's like patting themselves on back. How are you moving forward? How the Trello cards are being finished, Everything. But it's not fun, you know. And I think it's really important to have this place, have this kind of. What is it? Atmosphere where you can say, hey, I think this is just boring. This is shit. This part is shit. I don't enjoy it, but what could we do about it? And it's like, you know, it's like a positive thing, actually, because in the beginning it's kind of not nice to say it. It's shit. We made it shit. But when you realize that you can actually work with it, it's not the end of the world.
Yeah. It's empowering when you're in a position to change it. Right. Once you recognize it.
Yeah, obviously. Obviously.
Yeah.
So, yeah, this is. This is really important to be kind of open because I don't know how it's sometimes with other games because I feel like sometimes they are. They want to prove that they are best designers or they want to prove that they are. They have unique ideas or they are genius designers or something. And I think it's not the goal. I think it needs. It's super important to kind of put the ego aside and always like remind ourselves what is actually go to make the game fun. Not to prove anything to anyone, just to make it fun. And I think that's. This might sound a little bit patronizing or something, but I think this is really important thing too. And when I saw like professionals from all other fields, not only game design like software, but even like actors and people like that when they worked in the team, they said whenever they put their ego aside and are able to say whatever, everyone that I think that's always is helpful. And I'm not saying we are perfect with this, but I'm trying to. I really think that it's very important. I think people should do it a lot in game design.
I mean, for what it's worth, as a lot of it comes out, you see a lot of comments in the Friday fact about like, you know, we tried this and it wasn't fun to have done this way. So obviously your team has internalized it and is happy to do it publicly, which is also a rare thing. Right.
Yeah.
I feel like we've had a lot of good game design nuggets here. We've got mechanics, mechanics over content, density of fun. We're going to get you a line of posters, T shirts made.
Yeah.
The mechanics of a content one is also really interesting. I feel like when I first saw. Is it Gleiber or Gleber? When I first saw Gleber I was like, that is an attack on the bus. That is an attack on the idea of having one big central belt. And I love that it's going to completely change how I have to build factories. I think that's really like everything. Even the space platforms in a way.
It is a little bit also attack on the bots.
Yeah.
Even when it's a little bit subtle. But basically because the logistic box is kind of a known secret that they can make the game easy in some cases, maybe sometimes even a little bit too much. But with the boss advantage is that you just make a, you know, requester chest and provider chest and just kind of. It's almost like teleportation. They just move it but you don't really have control. Which specific. Because Spoilage. Suddenly two items of the same type are not really the same thing. One is almost spoiled, one is fresh. And with the belts you have really full control. Like the fresh items just made go this way and after that they go some other way and you kind of. And only the fresh. And you know, like when you have really strong control over it. I mean, if, for example, want to make the freshest possible science packs and send them out and not just some science, like it's really hard to do it with the circuit network, but with the bells, the overall refactories, like it's much. It's much better. So that's another.
Yeah, and that's really interesting. So I'm very conscious that we've gone quite long. So final couple of questions before I let you go. So we spoke a little bit about, you know, the operation of Wubane, running a company of 30 people now. But how have you found the transition from, you know, lone developer to now running a sizable game development studio?
It was very smooth. Like I kind of. From the beginning we were kind of very. It was very clear to us that we don't want to just become a huge studio with like hundreds of people because it doesn't feel like fun to us. Like once you have enough of money to pay the bills, it becomes more and more important to actually have fun while doing the stuff. But imagining that I have a company, at least at this moment, I don't know, maybe in 10, 20 years I will have a different kind of view. But imagining that having like thousand people having to deal with it and manage it sounds more like a horror than something I would enjoy. So we. It was very, very gradual. Like we first we hired a friend and we hired another guy. Then we were like four or five people. Then we, you know, like every half year or something we had someone and it just was growing kind of very gradual. There was never like a big step. We suddenly it would double the studio size. So it never felt like I don't really have really some one point where things would change a lot. And I mean there was just one change where kind of we split a little bit to kind of manage not management company. Like now we have Vaclav, which is the main like manager of graphics department of the studio. And he basically makes the management of it completely for me. And he's like super reliable and everything. I don't need to know what's going on there at all. I don't need to know what like they are planning, what, who's doing what. Like I Just see the results in the, in the master, the dream. And I don't. Yeah, it's. It's really great. And then with programmers, we, if I still do have some say, obviously, basically I'm like, mainly like the. My main role is like being the Coverx approval. Basically, like when I put, you know, like the stamp here. This is fine. This is not fine. Like, that's my.
The COVID X enrichment process.
Exactly. That's my main. That's my main role. But mainly like, we made kind of a system where we made like senior programmers which are afflacing people assigned to them to ask questions and to solve something with them. And only they would kind of come to me personally when it's not clear what should be decided or either it's a gameplay thing, which I kind of. That's my main kind of role. It's not that I would actually. That's one of the things. So basically my role, I have like three roles. Like, one is technical programming still. Second is gameplay and third is like approving stuff. But for example, with the gameplay stuff and gameplay, game design, it's far from me designing everything. It's actually almost the opposite. Like in the space age, I was mainly like designing and asking for the basic. I said, like, please, like, let's develop spoilage in the code so we can build something around it. Let's develop this. And then Arendelle came because. And it's like, he's like super creative. So I told him, like, hey, let's. What if you proposed some kind of piece and something on what would happen? What happened on Cleba when we have spoilage and he made something. He made like a lot of stuff. It was super complex, let's say like four times more complex than what we have now. And so the good thing is that I didn't really have to like, invent stuff, but I could still be like, okay, I think this is too much. Let's simplify this. Or this part is good, let's take it. This part is bad, let's script it. So I still was there in every gameplay, gameplay, kind of important gameplay decision. I was there and kind of saying. Saying my like, last word, but. But I was not really. Didn't have to invent. Like, obviously I invented some stuff. Not that I wouldn't invent anything, but I wouldn't. I didn't have to invent much because they were really great doing this. So, man, this is. I think I would. This is my role. But this means I still, I still have my past like for example, when I was talking about the blueprint parameterization. So for example, this thing I just programmed myself. So the point is we have like 30 people in the team, but I still spent most of my time actually programming code or doing stuff related to programming code and managing is like the smaller part of the work, maybe almost half at this point, but still I'm really happy it will be like this. And it was the goal that I don't, I wouldn't, probably wouldn't be happy if I just didn't touch any code at all and I would just be, you know, checking tasks and doing management. That's. That wasn't my goal.
Nice. That's awesome. Well, I'm glad it's worked out that way. So I guess my last question, you know, it's been 10 years of Factorio over, I think since you announced on Indiegogo or Kickstarter, whichever one it was, and space age is just around the corner. Would you say what's next for Vube?
The typical question. Well, actually my son. No, because actually I have like three sons. So one of my sons asked me yesterday when we were falling asleep in the bed, like what, what will you do when you finish? You know, like. And for me it's mainly I will, I wanted to stay in. I say it everywhere, but I want to say it even here. Like we will finish this expansion. We will almost certainly have like 2.1 release and some support and do some little things here and there. But I'm certainly not planning like another big expansion pack or factory or 2 in 3 or something like that or Factory online or whatever. I think it's like you said, 12, 13 years of doing one thing. I think it's enough for one game. I think like factor will be finished. And the point is that it's the game. You can make it like as I said, you can increase the fund density by making more quality improvements and more kind of power user stuff, which is still. We can also do more optimizations by the way. Like for example, we were thinking of the fully multithreaded. Fully, fully YOLO multithreaded factorial where you actually like because now we have some multithreading. Like I, for example, I'm sorry for tangenting but we have like, for example, like transport belts. Like when you have, when you define, when you identify the two belts are completely independent. They are actually can be updated independently or things like that. We are for things like the. That are obvious and simple, relatively simple. We already have multithreading, but we don't have multithreading for the actual core of the Factory update, which is like the inserters and machines and everything. But we have a plan of how it could theoretically be done with some unanswered question, et cetera. But it could be interesting challenge with. You know, I. I don't know if it's actually how much it is possible. It's like not clear. But it could be something really interesting to see how extreme it can get with the performance, obviously. But the point is that Factorio, we can improve these kind of things, quality of life and performance, etc. And also we can add content. But I think Factory is big enough and adding more and more content at this point, I feel like finishing Space Age. For me it really feels like a journey and making it even longer feels unnecessary. And also there are mods. So for me it feels like it's enough. We added a lot and like making it more would be just a little bit too much. So it's. It would improve it for less and less people. That's how I would say it. Obviously there are always some people that would always like it to be more and, and more complicated and longer and everything, but there are less and less of them the more the game is actually long. So the point is that it would actually be like the closure of Factorio. And then I was thinking about making a different game because I always wanted to do two kinds of game. I wanted to make a strategy game, which I think we did. And then I also wanted to do RPG game. You know, I. I loved RPGs. Like I'm. I think the best computer game I played ever was Baldur's Gate 1 and 2 and Gothic and, you know, games like this.
Yeah.
And I was thinking that maybe this was always my dream to make RPG game. And also they are kind of. It feels like they are easier than Factorio because you don't need the performance that much. I think like when we came to the like, if it's not multiplayer, it's maybe it doesn't have to be. If it doesn't have modding and if it doesn't have the performance constraints, suddenly it's like two, three multipliers removed and suddenly vertically would be eight times simpler. So. And also you don't have a huge factor if it's like, like in factorial, like 200 different UI windows. Like eventually they just some like for all the machines and all the settings and everything.
I guess like between inventories and spell systems and all the stuff, there'll still Be a good amount of ui.
Yeah. But in actually it's. Yeah, it's not that much. Like it's still. It's pretty like it's order of magnitude less I would say.
Okay.
And so I think it should theoretically be easier on the like technical part, but obviously it's much, much harder on like the content part where you need to.
The creative part.
Yeah. Like it depends what you do. Like you can have like very big production quality where you spend a lot of time and resources on having like, I don't know, like open world with all the graphics and shit. Or you can have like simplified graphics and you focus on the gameplay. Make some kind of. Make it around some fun mechanic with actual super simplified kind of environment. I mean everything is. This is all kind of up to question. But I have an idea about like one specific mechanics that I would like to try in a game. So maybe this could be done. But I don't know. I don't have promises. I kind of. Mainly I want to finish factorio, have a vacation and a long vacation, I hope. Yeah, I mean from my personal experience I know that half year is the maximum to have a free time and after that I. I just need to have a project or I would become mad. So it's kind of at last. Long as I'm alive, it's kind of given that I would do something. So. So having some kind of other game is one of the possibility. We also wanted to make a. This is kind of a weird topic, but I wanted to make K which would be like my new version of C. This is kind of a. This could be a long topic, but basically I. I work in C for more than 20 years now. I think 25 years almost or even more, which is crazy. And I love the language, but I also hate the language. There are great things about it and I think a lot of the bad things about it just can be solved. Just no one did it and already decided to solve by making completely different language which is like the rust direction. Yeah, rust or like language is like two different. And what I was looking for is like keep it like a C but fix some specific problems, make some very specific changes. So if you are used to C, you start using this one thing, you spend like one hour learning the new things and you can just continue working.
Nice.
Something like that. But making it great. So obviously then the question is if you wanted to keep us password, what would we do with the graphics department? And obviously that would be a project not meant for profit because that's One of the things I was thinking, if I had money and I didn't really need money urgently, if we could afford two years of just doing what we like, that it would be interesting thing to do for free for everyone. Like then if it's. If it's great, if it's work, then it would be kind of using our experience, what we had to improve something. But obviously the question is like it will be just another programming language. Maybe it's not worth it.
It's.
I don't really know. There are a lot of possibilities.
But that's a very cool idea. That would be a great legacy of Factorio if you able to use those resources to scratch that itch.
This is another thing that I was. I've been asked, I'm kind of planning that at some point, I don't know when Factory would become open source and people could just do whatever. Like they could just. They could just forget and you know, like make some crazy stuff with it or make, you know. And actually this is one of the things because Factory is not really open source, but it's a little bit like we have a lot of people that have access to the code actually from outside. They just.
When that list gets long enough, you might as well just go the whole way.
Right? I'm a little bit afraid to say it here, but I will say it anyway. Like we have from time to time people just write us an email. Hey, I am really curious what is right. Could I maybe try to get access and we just. Yeah, why not? Why? I mean, why not? That's all I could. What could happen actually? Like, what could the person do?
We take no responsibility. From the state of your inbox after this episode goes out. That's not our fault.
Yeah, luckily it would go factory factory.com and they manage it for me. But basically we have like. I don't know how many people we have there, like 30, 50 or something outside people that some of them just randomly put a pull request that's actually nice or they just read it. So in a way it's little bit of open source, not really proper, but it's kind of. We are kind of open to it. Although there are basically two reasons why we don't do it. One is that it's absolutely fine to have open source and paid product at the same time, but people are just not used to it, so it's a little bit weird. And the second is that imagine that it's actually open source and there's like 10 pull requests every day of something and you have to either ignore it and be a bad guy who just ignores their proposals, or you have to go through it and argue about stuff and explain why maybe you don't like it, which sounds like a lot of work. So that's actually one of the reasons that it would be a lot of work to kind of go through it. But on the other hand, it could be a really great experience to see. Maybe people would make a great. Like, I'm quite sure that always when you have more eyes looking at some code, it could be like, interesting to see how could they maybe propose some improvements to the code? Because we are really focused a lot on code quality, trying to improve the productivity of this code, et cetera. And having ideas about this, having conversation about some specific code changes sounds like fun. And seeing what people do with the game also sounds like fun. So it will happen at some point.
Yeah, I totally get what you mean about, you know, people not being used to the juxtaposition. I think it's. After the long tale of space age, it would sound a good timing you wouldn't consider doing, I guess, like something like, you know, the code is available, but it's not technically open source, you don't accept contributions, that kind of thing.
Maybe, yeah. I mean, something like this could happen, but, you know, like, definitely, like in upcoming year, like, we have different things. Like, I think it will take at least half a year to stabilize space age and. And then half year to kind of stabilize what's happened, et cetera, and kind of reconsider what to do. But after that we can start thinking about it.
Yeah, cool. Well, Kovaksh, you've given me so much of your time. Thank you so much. And best of luck with the release. I hope it all goes smoothly and yeah, thank you for joining us today.
Yeah, thank you, thank you. And sorry for my weird English accent. It's just, you know, Chinglish.
No need to apologize at all.
Yeah. So have a nice day. Goodbye.
Podcast Summary: Software Engineering Daily - Factorio with Michal Kavorek
Introduction
In the November 7, 2024 episode of Software Engineering Daily, host Joe Nash engages in an insightful conversation with Michal Kavorek (also known as Kovarex), the founder and director of Woob Software, the studio behind the acclaimed construction and management simulation game Factorio. Released in 2020, Factorio has been celebrated as a manufacturing masterpiece, recently further enhanced by its Space Age expansion. Michal delves into the game's origins, the development challenges, the new expansion, and his transition from a solo developer to leading a growing game studio.
Michal's Journey into Game Development
Michal Kavorek shares his passion for games and programming that ignited at a young age. Starting with creating text-based games on MS-DOS when he was eleven, Michal's desire to build interactive experiences was evident early on. He recounts an amusing school initiative where students could only play games developed within the school, leading him and a friend to create a variation of the classic Worms game. Michal reminisces:
Despite his enthusiasm, Michal pursued a mathematics degree at university, a period he found less fulfilling compared to game development. Frustrated with academic constraints and corporate roles, he made a pivotal decision to resign and focus on creating games. This transition was inspired by his experiences playing Minecraft mods and sketching factory designs during corporate meetings, ultimately leading to the creation of Factorio.
What is Factorio?
Factorio is defined by Michal as a strategy game centered around resource gathering, processing, and automation. Players construct and manage complex production lines, transforming raw resources into advanced materials, ultimately progressing to sophisticated technologies like launching rockets. Michal highlights the game's extensive inspirations:
This combination of strategic layers from various classic games contributes to Factorio's rich and engaging gameplay experience.
Balancing Realism and Fun in Game Design
A core principle in Factorio's development is prioritizing fun over strict realism. Michal explains:
This approach allows the team to implement features that enhance player enjoyment, even if they deviate from real-world accuracy. For instance, the locomotives in Factorio can "magically rotate" at stations, prioritizing smooth gameplay over authentic train mechanics. Such decisions ensure that the game remains accessible and enjoyable without being bogged down by unnecessary complexities.
Optimization Challenges and Game Architecture
Factorio's ability to handle massive in-game systems—millions of items on belts and countless machines operating simultaneously—stems from meticulous optimization and custom game architecture. Built from scratch in C, Factorio leverages custom optimizations to manage demanding performance requirements:
Data Structure Optimization: Michal emphasizes the importance of linear memory processing to reduce access times.
Efficient Processing: Implementing systems where inactive components remain dormant, only activating when necessary, conserves computational resources.
Custom Optimizations: For example, transport belts are managed by handling movement as a whole rather than tracking individual items, significantly reducing computational overhead.
Michal notes:
These strategies ensure smooth performance even as players expand their factories to unprecedented scales.
Player Interactions and System Struggles
The podcast explores how player ingenuity can sometimes break game assumptions, leading to unforeseen challenges. Michal shares early bugs and exploits, such as transport belts accidentally moving game arrows or players using cars on belts to create storage capacity overrides. These scenarios highlight the dynamic nature of sandbox games, where creative player interactions can both enrich the game and pose new development challenges.
Modding Support and Community Engagement
A significant portion of the discussion focuses on Factorio's robust modding support, which has been instrumental in sustaining its popularity. Michal describes the implementation of a unique ID system where each mod uses textual IDs to avoid conflicts, simplifying compatibility between multiple mods:
Additionally, Factorio features an official mod portal integrated into the game, enabling users to easily browse and install mods without external dependencies. Comprehensive and up-to-date API documentation, generated directly from the C codebase, ensures reliability and reduces the likelihood of outdated resources.
Michal acknowledges the challenges that come with supporting mods, such as dealing with extreme mod interactions that can introduce performance issues or break game mechanics. Despite these challenges, modding remains a core strength, allowing the community to extend and customize the game extensively.
Factorio 2.0 and Space Age Expansion
As of the recording, Factorio is on the brink of releasing version 2.0 along with the Space Age expansion. Michal outlines the key features and improvements:
Rails Overhaul: Rails now support 16 directions and modular shapes, enhancing factory flexibility and functionality. However, this change affects save file compatibility as existing rails are replaced with new designs.
Enhanced Train Systems: Introduction of train interrupts allows players to program more complex train behaviors, such as dynamically rerouting trains based on conditions like fuel levels, deepening strategic transport management options.
Quality of Life Improvements: Features like Factoryopedia (an in-game encyclopedia), improved search functionalities ("Control-F" to locate buildings or resources directly on the map), and more intuitive UI enhancements streamline gameplay and enhance user experience.
Planetary Expansion: Introduction of four new planets, each with distinct biomes, tech trees, and environmental mechanics, such as spoilage mechanics and resource recycling, diversifying gameplay and reducing repetitiveness.
Michal emphasizes that these updates aim to enhance "the density of fun" by increasing the quality and variety of gameplay interactions without overwhelming players who prefer simpler setups.
Running a Growing Game Development Studio
Transitioning from a small team to managing a studio of 30, Michal describes the gradual growth of Woob Software. Emphasizing a preference for a manageable scale, the team avoids rapid expansion, ensuring that growth remains sustainable and enjoyable. Michal manages by delegating responsibilities to trusted team members, particularly in graphics and management, while maintaining a hands-on role in programming and key decision-making.
Michal shares:
He discusses balancing direct involvement in game development with overseeing a larger team, ensuring that his passion for programming and game design remains central to the studio’s operations.
Future Plans and Closing
Looking ahead, Michal hints that after completing the Space Age expansion and possibly a minor 2.1 release, Woob Software may consider concluding further Factorio development, viewing it as a completed journey. He expresses interest in exploring new projects, such as developing an RPG or creating a new programming language inspired by C, aiming to continue innovating while keeping the studio’s focus consistent.
Michal concludes by emphasizing the importance of staying open to feedback and maintaining a fun, collaborative internal culture:
Notable Quotes
Balancing Fun and Realism:
Magic of Game Creation:
Optimization Strategies:
Gradual Company Growth:
Empowering Change:
Conclusion
This episode offers a comprehensive look into Factorio's development, Michal Kavorek's design philosophies, the technical challenges of creating a highly optimized simulation game, and the importance of community engagement through modding. The forthcoming 2.0 update and Space Age expansion represent significant milestones, promising deeper and more diverse gameplay experiences. Michal's reflections on leadership and future aspirations provide valuable insights into running a successful game development studio while maintaining creative passion and technical excellence.