EPISODE 1762

[INTRODUCTION]

[0:00:01] ANNOUNCER: 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 Kova?ík, also known as kovarex, who is the Founder and Director of Wube 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 Gary's Mod, and game development remains his favorite way to experience and explore new technologies and concepts.

[INTERVIEW]

[0:01:16] JN: Michal, welcome to the show. Thank you so much for joining me today.

[0:01:18] MK: Hello. Thank you for inviting me.

[0:01:21] JN: 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? What led to Factorio?

[0:01:32] MK: Oh, that's a very, very long answer to a simple question. Basically, do you know the XKCD comics?

[0:01:40] JN: Yeah. Yeah, of course.

[0:01:42] MK: We are teaching at the university about some mathematical proofs, etc., and the guy sitting there was like, "Oh, this is so complicated. I came here just to make games." This is exactly how I felt when I was in the university studying math, basically. That's generally my journey. I always liked games and also like programming from very early, like 11 years. I remember from the very beginning, when I was doing MSDOS programs, I did some text games and such. I always wanted to create, so this was very natural.

I even have a story that when we were, I don't know, 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.

[0:02:26] JN: That's pretty cool.

[0:02:27] MK: I would 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 game, but they were competing with only other games made in the school. Really, also nice system. That actually led to us our first game that we made for someone else. Me and my friend, we made some variation on worms, not worms, but some worms game. Basically, we were selling it for a baguette. Anyone who gave us a baguette had licensed to play the game in the computer lab.

[0:03:01] JN: That's incredible.

[0:03:02] MK: It really felt great. I was eating the baguette and I felt like, "Yeah." This is a physical thing, and I ended by just writing on a keyboard, it felt so magical. Yeah, that's how wonderful. I always was trying some - to make some games, but then the "real life happened," and I started to do, like I went to university and I didn't really like it much at the end, because I also had to go to work and support myself and eventually, I got - You know how it ends when even someone goes to university and also, they make money, usually the money part.

I was also already doing programming, obviously, but it felt much more interesting to go to work and make money and learn things anyway than going to university more. I basically started to work, and it wasn't gaming. I was like, okay, this is the adult life. I need to do the real stuff. I was doing some boring database stuff. I mean, coding in C++ by doing some, you know, the typical company, something company systems. I was thinking, somehow, I don't know why I thought I'd like this. This is the game of how I will live my life. But this was only four years of my life. It wasn't that long.

I didn't do much thinking about how to make games in this time. I was more trying to get my adult life together. This is where basically, the Factorio idea was created when I was playing some Minecraft mods and I was also drawing doodles, or how is it? Doodles? That's how it is?

[0:04:37] JN: Yeah. Doodles. Right. Yeah, yeah.

[0:04:38] MK: Doodles. 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, etc. This is my favorite 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 code and do stuff." I already had some interaction with the guy, and in my eyes, he was shit. I was like, "I'm not going to work with this guy as an architect and I'm resigning right now." I just send up, says like, "Okay, I'm resigning from the company."

At that point, I was like, okay, what do I do? I had something saved and I was doodling the factory game. Let's make this for a fun for a while and see where it leads. This is out of nothing. It just happened that I started, wanted to make this a hobby project. I was thinking, well, maybe one day, if I sell a few thousand copies of it, maybe some super geeky people could just enjoy it and it could pay a little bit. I don't know. That's what my thinking at this point. This led me basically, to games. But apart the childish creations I was doing when I was in my teens, I didn't really specialize in game creation, or some special courses, or anything like that. I was very focused on trying to learn to programming. Basically, 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 make the 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.

I always find that it's not that as smart, or as interesting as they try to make it. My way of thinking how to prove them wrong was I was trying to program a program that does it automatic. Because if I can make a program that does it better than me, then this whole thing is bullshit. Basically, I spent a lot of time trying to improve this program of mine, which was basically symbolic or simplification of math formulas. Is step by step explanation what you do, etc. I was even thinking, one day, maybe it could be used in school for teaching that people can see 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. You have these online programs that you can just put and you get exactly this. But at that point, it wasn't actually there when I was starting with this. Basically, for me, these programs were really big planning point, where I learned how to manage a bigger project. I also learned, because I learned how to do testing, because basically, I had a lot of formats to simplify. I could have a big data test. I was trying to do optimizations, but I did just for fun, I was optimizing how fast this test can run and I was trying to outperform it again and again. It's not like I wouldn't do programming for fun, just this geeky stuff, but not specifically games at this point.

[0:07:45] JN: Well, 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 -

[0:07:56] MK: I mean, and also, there's one more thing that's interesting is that I'm really glad that I left, because after, I think, five years, or 10 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 met up in the pub. It was basically to not to celebrate a special event. The event was that the whole project, the whole programming that was there done for 15 years. I was four years there, but it was big history was just scrapped and it was removed, replaced by some sub or something.

Imagine that you spend 10 years perfecting some system for some people, you still can find some value in it, or some personal - But then, it's all scrapped and it's like, yeah. Also, formatting -

[0:08:46] JN: In the meantime, you had made and delivered Factorio.

[0:08:48] MK: Yeah. Yeah.

[0:08:49] JN: You invented a genre and found a huge audience.

[0:08:52] MK: Yeah.

[0:08:53] JN: 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?

[0:09:03] MK: Basically, I would say, it's a strategy game. That's the genre it is. It's about in a very surface, or in the very beginning, it's like a research management game, 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 final products. This process can be done manually, but very soon in the game, you start making production lines and automating this process.

Basically, the game is about figuring out how to automate it, how to especially put automation stuff on the map, because you have logistics of bells, you have production centers. Also, so this is 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. It's about the investment and whether investment helps you the most to move forward, which where I can see parallel in real life sometimes.

Also, it's a lot about progression, which is just, I mean, who doesn't love progression in games? It's like, it's in the beginning, you have very slow and shittiest things and in the end, you are launching rockets, or even beyond. 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 have the construction robots and blueprints and basically, it means that not only you produce more, but the rate of increasing of the production is higher. What is it? Like, second or third derivation still is positive. 

The progression is very important. 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 I think is connected, it feels really nice to just sit down and look at it. That's how I got my programming partner, who started to do progress with me into the factory. I just showed him some super prototype and he was like, "Oh, everything is moving. Everything has a purpose. It's looks so great." Suddenly, he was -

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 trees, Starcraft for the fight, and Minecraft, Industrial Crafts for the industrial and automation part of it. This is in a way, combination of these four games.

[0:11:39] JN: That makes a lot of sense, especially the Transport Tycoon. Okay. Got a whole heap of things there. I think you're so right about the seeing everything moving. I've been playing a lot of Factorio this week and leading up to this chat. My partner who has never played Factorio in her life would come in and I'd just be standing in front of my bus with all these belts and she'd be like, "Oh, that looks so cool." It's like, "Yeah, it does." The Transport Tycoon point is really interesting, because I think one of the things that I had been thinking about - I've played Factorio years and years ago around first release. Then since then, I've played other factory games. Obviously, Satisfactory is more recent one.

Coming back to Factorio, one of the things I've been sat here thinking is 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. I'm like, any other train game I've played.

[0:12:25] MK: I'm glad about it. Basically, I remember that - I mean, I am not huge, what is it? The Transport Tycoon fan. I mean, I like the game, but compared to some other people, I'm a huge noob. For example, Vastlav, he was - which is the main graphics manager in our game in Factorio. He was making a mod to the game and playing it on an extreme level. Basically, what I always was it's like, first of all, I know it's they don't move in a smooth curves. Very often, unless you do some special settings, they can just magically rotate in stations.

I always like the idea that you wouldn't have these things and it would be harder to connect everything, and it would be, like the trains would really think you need to think how to make them physically move properly and rotate and everything. There's also motivation to make it feel a little bit more like real trains. Obviously, there are even more realistic games about trains, but then they don't really have the building part of it and the strategy part of it, usually. That's my feel.

[0:13:31] JN: Yeah. The note on realism, okay, I guess this brings me into my first game design question. 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. One of the things you frequently talk about in your Friday facts when you're looking at the development is you always have this really good line of commentary, which is like, "We tried doing something this way, which is the more accurate version, or the more simulated version and we found it was just not fun, or we found it was too grindy. So, we made this concession to make it a better gameplay experience."

I think in general, that's something that your team seems to do extremely well, which is like, managing to make - still a really satisfying simulation, a really satisfying system, but you're managing to shave the corners off to make it also a better game. Could you talk a little bit about how you approach balancing those two things?

[0:14:23] MK: It's very simple. We have a role that it's always fun above realism. Just really just like, you can carry hundreds of locomotives in your inventory. I mean, but obviously, there are different kinds of things. I would say, sometimes some things are not realistic and features are fine. You can get away with it, and people are whatever. Okay, I can carry it on to 100 locomotives in my inventory. It's funny, but it's still okay. If the trains randomly move on the train - Some things are only technical details, because okay, it's one character. Maybe the character could move the locomotive somewhere, it would be solvable problem. But if you are in the parts that matters, are critical to how you look at the system, like the trains not magically turning, for example, the ends of the rails. This is the part where it would be maybe even small and non-realism if it did that compared to cutting the locomotives. This is the part where it just feels more important.

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 plants currently, it's 15,000 kilometers. Even my son was saying like, "Oh, 15,000 kilometers. It's almost the same as - and on Earth. It's too close. You should change it." Maybe we will. Maybe we won't. But it's not really - these things are not really that important. Or for example, especially when as a player, I think if I play a game or if I watch a movie, I think it's related subject. Like a lot of the movies and shows, you can see like, I don't know, some sci-fi movie and they make a premise like, I don't know, you can -

[0:16:00] JN: Yes.

[0:16:00] MK: - teleport, or you can something. And we said 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 doesn't work together, or there's similar [inaudible 0:16:21].

[0:16:22] JN: Or they spent an hour explaining the premise, right? There was this period of films, where they couldn't have any fake science without having some guy with a blackboard explain it. I always say, this is why Pacific Rim is an amazing film, because it's like, there are giant robots, there are giant monsters, and let's get to the film.

[0:16:38] MK: What movie?

[0:16:39] JN: Pacific Rim?

[0:16:41] MK: I didn't know. I don't know.

[0:16:42] JN: You'll enjoy that one. You'll enjoy it. Yeah, that makes a lot of sense.

[0:16:45] MK: Yeah, I remember watching Planet of the Apes recently and they also had this like, they moved in in time, I was like, okay, to get a visit, but they had to spend 10 minutes explaining some, but a lot of it is sci-fi bullshit to somehow try to explain it. Basically, so into the game, we always go realism over fun. But if we can, we try to make it realistic in the places that make it feel good. For example, you never really teleport items in the game. They always move smoothly, or I don't know. Yeah, the general, like everything needs logistics. That's important.

When you, for example, build stuff, you can build stuff remotely, but some robot needs to go there and get an item. Okay, the item might be a big cricket silo and smaller robot is holding it. In this case, it's a little bit funny. But at least there's still physical connection between things. It's not just completely magic. I think there's some experience of how it - it's more about how it feels and how actual rails stick with this.

[0:17:45] JN: That makes a lot of sense.

[0:17:46] MK: That's for sure.

[0:17:48] JN: You mentioned that, I think, these be connected by the logistics, things always have been moving around, which gets me into my first performance question, which is obviously, you've made a game here, where by the end of a normal playthrough, now I've been getting into the new expansion space age, but have a normal playthrough.

[0:18:02] MK: By the way, we have quite a good timing, because yesterday, we basically lifted the embargo on any information to Factorio in space age. Even some of the steamers that have the game can talk whatever, so I can also say whatever. We don't need to be afraid about spoiling anything. Now, it's everything is, you can ask whatever. It's just a small.

[0:18:24] JN: I don't want to spoil the ending, ending. We will talk about the planets for sure. Yeah. By the end of a normal playthrough, an average player has millions and millions of items moving around belts, there's robots, there's acres and acres of machinery. Having now read the Friday Facts and seen all the work you put in optimization, I understand a little bit more about how that's possible. 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. The game is not only -

[0:18:58] MK: Thousands of 10% of thousands more likely. Yeah.

[0:19:01] JN: 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. An hour later, I was placing another belt and out popped a belt with a low bit of health, because it retained it. It was somewhere just in a stack.

[0:19:17] MK: There's the simplest thing, like having -

[0:19:20] JN: Yeah, absolutely.

[0:19:21] MK: Obviously, the hard part is to make - optimize what - what actually matters is other things that are in the world and have to run all the time. Basically, the performance was issue, or not issue. I was like, added performance would be a problem for the very beginning, because as I said, 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, it's still very different. The main issue was whenever I tried to build anything even remotely bigger, in the Factorio terms it would be starter, super small starter base. It started to work a lot, because the game engine just wasn't built for it.

The obvious motivation was to make engine that's built for that. It's from the scratch, it's built to actually support everything, support the big performance potentially, which mainly means we have access to change everything in the game. It's in C++, there's no engine and we can change the structures of absolutely everything we want. 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. We made a 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 factories. It's like, okay, now something else is slowing it down. Basically, step by step, we were learning and identifying what needs to be done to improve it.

Generally, on a general level, the most important things were we found like, you can do things like, optimize the dust structure, so things are, for example, when you have some entity, or some stuff you processed in a linear piece of manual memory, it's 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. When you optimize things in a way that you don't actually touch things when you don't need to. 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 work to do. The same as in vectors.

Basically, trying to only update things that are actually updating at the moment, because even the very optimal build factories, very often, a lot of the paths don't work at the moment. There were many tricks and things we had to do to make it possible. Then there are a lot of custom optimizations. For example, the belts. I think they are - they have, in a way, beautiful, but simple structure that basically, if you have belt, I don't know, there's some maximum length, but let's say, you have 1,000 meters long belt and input things on one side and take things at the end. It has complexity of one moving it, because you, basically, you have one piece of memory that says a relative position of the things and you just move one number saying, what is the relative position of all the items? Then you only check the ending of the belt if they don't - some special cases that can happen there. Then you check the starting of the belt that you put items, or something.

Basically, you don't need to touch individual items on the belt, because you move the belt as a whole. Things like this, obviously, then done properly, they help a lot. There are many things like that. We can discuss some of them in specifics. I'm just giving some, the first examples that come to my mind. Most of the optimizations that are really efficient is like, I would call them business logic optimization, when you actually improve how the logic of it works, instead of improve the actual instructions in the code.

[0:23:04] JN: Okay. I do want to talk about some specific optimizations. I guess before that, even in the game, it refers to things like, ticks. If you play Factorio enough time, you'll encounter UPS and you know the idea of updates per second, and this stuff. Can you, I guess, run through briefly what the system is underneath that? I assume there's some communication layer where every machine that can post something to a network is doing so. Is that what's going on?

[0:23:26] MK: What do you mean, like system? Now, what do you mean, system of what? Of the whole update of the game or?

[0:23:32] JN: Yeah. I mean, what are the ticks? When something generates a power - 

[0:23:37] MK: Take is one update. The principle is simpler. You have 60 updates per second, because 60 UPS. 60 is the number for this to -

[0:23:47] JN: Looks good at 60. Yeah.

[0:23:48] MK: Yes, exactly. It was specified as what we do, which means you have 16 milliseconds to just do one update. 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. Typically, what we do is the problem is when you are updating the game, you can't really render the game at the same time. Or you can, but you need to do it. What we do is we do what we call prepare. We are rendering the game at the same time as updating the game, but then there needs to be one specific moment where we can collect all the data to be rendered. We collect, basically, a list of data for like, this sprite is to be drawn. We call it drawQ. This sprite need to be drawn like a plan of all we want to draw, which can be generated much more quickly than actually drawing it. We stop the game, everything stops, so we have consistent state of the game at the end of, or after the update. That if we try to, actually, in parallel, we collect these draw orders, so we 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 logic of the game, and start updating the next step already. Then, in the address thread, there's enough of time to go through these drawQs, sort them properly, and then, actually, draw them into the screen, while the game is being updated. The logic, under this, I don't know if that's what you asked?

[0:25:19] JN: Yeah. No, that's great. Yeah, that's perfect. Yeah. I mean, answer my question via absence of something, which is -

[0:25:24] MK: I had a memory of some specific Friday Facts stories. It's interesting, because, as you already mentioned, the Friday Facts blog, sometimes, for example, now we have a change work over the expansion, and I realized that half of the features we have, they are already covered in the Friday Facts actually - I use the Friday Facts as a reference, as recommendations. I write in the change work, for example, we edit elevated trails, and I just put a link to the Friday Fact to see the pictures and everything, and description.

Or, it actually even happened in our company. Someone asked, how is this done? For example, the question he had like, how are the stages of update versus us, and say, "Yeah, five years ago, we made a Friday Facts, there's pictures and everything." And I just link, sometimes, our developers to the Friday Facts as a documentation to the game, which is -

[0:26:11] JN: Yeah. It really is a fantastic - You were saying earlier, the belts are one. I have not encountered this much big O notation since my computer science degree. Your team talks so much about like, "Oh, this operation is ON, depending on how many inputs it has." All the time. It's really fantastic. It's a really good blog.

[0:26:31] MK: It's great. But, I mean, I mean, the way we use it, it's not something you need to take grief for now. It's like, you have, basically, for one, like N squared, and I think more is you don't care. It's three layers of what you can do, and that's it. But obviously, it's really matters. For example, we have a logistics network in the game where, basically, you can put - you can have a system of chests. Whenever you put iron in one of the chests, and you need it somewhere else, the robot can immediately go to the chest and transport it from this to another. For example, this one is always also Ozo 01, the search for - because there's this problem. You have 50 different items in 1,000 different chests, basically, scattered all around. It could be potentially not really that simple to find what you need. But basically, the point is that every item has its own linked list of where our store 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 also makes it a fun experience to learn about the optimization and these own notations in practice, because when you - one thing isn't being told in the math class, or in programming 101 class, and think like, yeah, this is something they already are teaching about. When you actually make N square algorithm for something, and in one year, it bites you in the ass, because someone gives you a safe, "Oh, this is super slow. What's going on?" And you find out there's some N square algorithm, and you just fix it, and suddenly, it's hundred times faster. You get feel for how big of impact has it, and suddenly, it doesn't become - becomes much less abstract, because you have to deal with it on a daily basis.

Also, obviously, you need to be pragmatic. Sometimes we say like, yeah, this is not ideal algorithm, but they're not, for example, these trains, I remember, we were doing some train logic, and we said like, yeah, this part of the logic is not that fast. But no one will - there will never be based with - it's more than five to 10 trains, so it's fine. Then the other basis is thousands of trains, so we always had to change our assumptions about what numbers can we expect in different things. They always get bigger.

[0:28:54] JN: Is there, I guess, onto some 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 that's like your pet?

[0:29:08] MK: There's so many. I mean, 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 one of my favorite errors was in the very, very, very early stages of Factorio, we were trying to debug a tutorial to make people understand, and we made some friends or random people play it. There was this like, we put an error in the game to show something, that's something they should do. 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. It just moves stuff. we realized, oh, you could just build - just put a transport belt, then the transport belt moves the error from the game away.

Or, for example, and they made - and we put cars that you could put things into the trunk, and then we have transport belts, and suddenly, people realized they can put cars on transport belts, and suddenly, they have different transport belts that can have a big storage capacity. Things like this obviously happens, and especially with the cases like, I don't know, with the trains. Mainly with the scale of the stuff like, we make a robot network, and someone was saying, "Oh, the game is broken. It's getting slow." We are in panic. We open the save, what's going on? Then we open save, it's a hundred thousand robots, like a swarm of robots everywhere. It's just five UPS. I'm thinking like, okay, so this is not a real problem. At some point, people expect it to go to infinity, and whenever it's not fast enough, they think it's a bug. These are the things that sometimes happen. I probably don't have too many examples out of my head. I will probably remember some of them as we go. Obviously, people always come up with crazy stuff.

[0:30:57] JN: 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?

[0:31:03] MK: Also, the main thing that makes it crazy to make things proper is mods also. Basically, all these things are multipliers. You have a game that has multiplayer, multiply your def complexity by at least two. You have mods, multiply everything, but at least two, again. Do you have, I don't know, like you have performance, you need performance, multiply it all by two. Because these are multiplying, because if you have mods, suddenly, if you know, if I don't know, for example like, yeah, we have a chest. We know, okay, the chest has 48 slots at mall, so we can have some constraints about how to access the chest, how to work with it in the call. But someone makes a mod, and suddenly, the chest in the mod has 10,000 slots. Suddenly, they complain that it's slow, and we never thought about this extreme.

Basically, the mods make extreme settings, extreme interactions of stuff, and it's so much harder. Everything that you are normally in the game development, things are stable. Your objects are stable. Suddenly, everything you work with can be whatever. Especially in a game like Factorio, when things need to be super reliable, and everything can interact almost with not everything with everything, but things interact a lot, it can make a lot of crazy stuff. And we always have to, anyway, even if we try to fix everything, reasonable, that's always, we have to draw a line and say like, "Yeah, this is too crazy. I can't help you."

[0:32:29] JN: Yeah. I mean, people always do deranged things with mods. But mod developers discovering the hard way why the core team has implemented something, how they have is a curse genre problem. On mods, as many sandbox games, they see a second life through modding, and the community around Factorio's modding seems great. In fact, I believe you've hired one of the modders for space age, right? Arando?

[0:32:52] MK: Mm-hmm. Yeah.

[0:32:53] JN: 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.

[0:32:59] MK: Yeah. Actually, this is one of the things that I think I did really right, because I had some experience with the Minecraft modding before starting the Factorio. I didn't really mod myself, but I was trying to use it as a user, like applying the mods, or looking - I looked a little bit under the hood, how it's done. I don't probably change in the meantime. I didn't look into it in many years, but it was horror, because you had these things where, for example, the blocks had integer values. Like, okay, block five means something and block 16, something. Then if you had the mod, people had public similar tables where they negotiated which numbers are used by which mods, so they would become compatible and had to make - making two mods work at the same time, or whatever. Basically, you had no API, so they would either hack the JavaScript directly and whenever you had conflict, you are fucked.

Or you had these special mods, which basically, I think it was called for, short things like that, basically, programmed API for the mods, but they have different kinds of them and different versions. Then, even if you wanted to update the mod, there were different places where you can download the mod. It was like, it was hell, and I was thinking that it shouldn't be that hard to make it better. One of the first things that I made is to make the ID system, which I think is really great. It's the point is that every - we have, I don't know, we have dozens of independent ID 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.

In the game, for example, I don't know, items. Item have every number of every number means some different item, but it's internal thing. The actual number that, for example, five means iron plate and six means copper plate, it's not accessible to modders in any way. It's completely internal. The modders always works with textual names, so they specify, for example, iron plate, and we have - so in the beginning, you say, this entity, when mined it gives you iron plates, etc. And it all is based on textual ID. 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.

Then, under the hood, we just assign numbers to textual IDs. You start a game, we make a dictionary of what textual ID means what item, and then, basically, it all runs under numerical IDs, which are basically, more efficient. 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 translate it to numerical stuff. This means that the numerical values of what means what is if can be different in every save, and it's fine. They don't need to negotiate anything, and it just works out.

Generally, the main idea is to make it possible that two mods can - to increase the probability that two mods that even may be modify similar things, can work independently without even having some special care to make, that was made to make them compatible.

[0:36:13] JN: Yeah. Be aware of whichever tool.

[0:36:15] MK: Yeah. ID system was the primary thing. Then, there were like, basically, obviously, even the fact that we have the API, so basically, every mod is a package. It's like, one, the package, which contains the definition of the object, some modification of other objects, you can have, basically, dependencies of which it defines, basically, either what you want, or the order of the things like, oh, this mod says that it needs to be loaded after some other mod. You have three stages of updating data. We really try to make it that the API is friendly, and they can work together nicely.

Also, what I think is very important is the mod portal. Basically, we made one. We created one official place where mods are. I'm not even sure that there's some other, like an official mod portal. Probably not much. Because it just integrated into the game. It just works like, you see a game, someone sets your game, or you see a multiplayer game, you go to the game, and you can just press one button, install mods and join the game. Maybe it already is like this in Minecraft community, I don't know. But at the time, when I was dealing with it, this was like sci-fi, and this is just works.

I think it's so important on - so, basically, I try to make it easy for modders to solve this problem, easy for users, so they just click one button, and it works, and safe for us. So, we have one specifically, specially defined API, which is the public one with documentation, everything. I believe that it worked.

[0:37:42] JN: 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 in the top nav on the main website, right? It's very prominent and easy to access. It's very core to the experience.

[0:37:58] MK: Yeah. 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 really recommend automatically the properties of different objects. Now, we also have that. Here, the big improvement we made is that we basically generate the API directly from the C++ code. We had like, I don't know, for example, I have car prototype object in the C++, which defines how car prototype is defined, and this graphics and everything, and there's also this method, which allows its properties from a property tree, like JSON or something, that it loads it from.

Always, this method has a comment, which is used, comments every field for generation of the documentation that it's then script from the code and documented from that. It's super important that it's on 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 a documentation, and you would know that if you don't update it to file itself, it's outdated as a 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. Not even mentioning that now, we have two versions separate, and you have documentations for both, so then you can look at versioning of documentation, etc. This is something that was improved in the last years a lot. This is not my work. Other people are doing it, but I think it's really nice. 

[0:39:31] JN: Yeah, absolutely. Yeah. We'll 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, to start with 2.0, the base game, which is a 2.0 is a free update for everyone who currently owns Factorio, right? What's new in 2.0?

[0:39:55] MK: Many things, like the rails. The most intrusive things, probably, is the rails being changed. Now, basically, we changed the shape of rails, and this means that you have more possibilities. Now, the rails have 16 directions, instead of 8. You have smaller shapes, which are more modular, so you can make aspens and things like that, that weren't possible before, which breaks and of a little bit previous saves, because the shapes are just different. But then, there are a lot of quality of life changes. Like, for example, we have the train system. Now, before what people have in the train system 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.

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. You can connect a circuit network to the station, and control how long this stay. But you can never control where the train goes. 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. I specifically wanted to call this interrupt, because it's such a fitting name. Basically, now, you can specify, have a list of interrupts, and you can have condition of when something happens, go to some specific station, or set of station, and do something. Basically, you almost program the trains.

Obviously, there are some very simple examples where it's useful. For example, you have a train going between A and B, and then you have interrupt. Okay, when you start to have not enough fuel, go to a refueling station, and then continue what you are doing. Obviously, there are 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 - 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, so I want to send it to you from the beginning. It's absolutely crazy.

[0:42:21] JN: Truly worthy of a 2.0 time.

[0:42:22] MK: Yeah. You have train groups, for example, which is like, you can now -

[0:42:26] JN: Well, they're amazing.

[0:42:27] MK: - change trains at the same time. We have logistic groups, which means you can also, you can group what we request in logistic chairs, and just change them all at the same time, which is specifically done, because space age, because this is more into the points where we try to minimize the annoying parts of it, like of the fiddling. For example, one item now transported to all the planets, and you don't want to change somehow, what you do on the space platforms, what you do on the planets, what you do. You can set it up in a way. It will just change one request, and it is actually transported everywhere eventually, automatically. Yeah, we get a Factoriopedia, which is also, it's basically in-game Wikipedia about the game, where you can check many things that weren't even checkable before.

[0:43:16] JN: Which, by the way, is, I think, a very under-appreciated move, because I feel like, every sandbox game nowadays has a compulsory Wikipedia that you need to have on the side. Having it in the game is so good. It's amazing.

[0:43:27] MK: Actually, it has pros and cons. I remember, and it's not the case anymore, but and for me, interesting take is that one of the reasons why Minecraft was so popular back in the day, I mean, not saying our own reasons, but one of the reasons is that it didn't have any hints whatsoever, how do you craft things. It was complete magic. I think it created this interesting symbiotic relationship, because people didn't know how to craft stuff. Either you could look at the key, which already made some traffic and made people more move into communities, but then you had YouTubers, which were explaining things in the groups, and how do you do things. The YouTubers, because they were 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 cycle, I think, made it popular.

Maybe, I mean, it would be interesting if I could make another universe and see what would happen if actually made a proper documentation of 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 to the game and with you. It's not always as clear what's better, that's what I wanted to say.

[0:44:42] JN: It's a really interesting thesis. Game design for influencers is -

[0:44:46] MK: Yes, exactly. I mean, these days, it's not that out-of-the-box thinking these days, but at the time when Minecraft was new, it definitely wasn't a thing to think this way. But anyway, the Factoriopedia, we realized especially with mods or space, it's just really nice to quickly navigate through, okay, what is this? Typically, I get an item. What is this item used for? I don't even know. There was no way to actually figuring out what is this item for, or where do I get this item, or 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? All these things are now in one place. We spent quite some time to more and more info there, so let's see how -

For me, it's actually, even when I know the game, I use it daily, too, because we still tweak stuff and change recipes, so I'm not 100% - I don't have 100 percent of everything in the brain was the current state, and I always use Factoriopedia to check on stuff. That one is like - I mean, yeah, super-first building. 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 - everything in the game is marked for a construction like this, or the search. 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. This is, for example, the search. Every window, almost every reasonable window has, you can press control F and search in the window. It's so useful, because it's not so much work to do, but for the player, it's like, when I see a window with 100 things, and I have to search something with my eyes only, and I have no way to actually - we are so used to it in the browsers and everywhere, so why not have it in the game? Now, when we edit extreme version of it, you actually can't play the game, not have any window opened. You break control F, and you search in the map as a whole.

[0:46:43] JN: What?

[0:46:45] MK: Yeah. You search, for example, the typical thing like, oh, where do we - actually, do we make, I don't know, assembling machine threes in the same, because eventually, the factor is a bake, and it's a mess when 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 deposits like, where is coal, and you can highlight the nearest coal deposits, or things like that. Basically, the point is that I think it's really important, this quality of life features. When I look at it from the high-level perspective, we are trying to improve the density of fun. It's not fun to spend five minutes stumbling, or, no, five minutes is extreme, but even if it's 30 seconds, stumbling in your base, and, oh, where was it? Where was it? Hmm, not here, not here. Hmm, not here. It's not fun. It's just, no one wants to do it.

But it's fun to design, and to be as much power first, you can, when it comes to figuring things out and building, and actually make the standard time designing, and improving, etc. All these quality of life things should improve the density of fun. I think that's actually, I never used this correlation to fun.

[0:47:56] JN: It's a good tagline for the design, yeah.

[0:47:58] MK: Yeah. Density of fun.

[0:48:00] JN: Also, very appropriate to it. Again, when you build a lot of very dense structures.

[0:48:04] MK: It's like, oh, this is actually one of the most geeky things I think I did. I was actually curious if it's too much. It's the blueprint parameterization, because in the game, just to tell to people that might not know much on the game like, in the game, you can just basically make blueprints, which is your copy paste, part of the base, typically some module, or something that does mining, outpost, or train station, or some intersection, or anything. Basically, in the factory, you can copy into the item. It's a plan. We call it blueprint. You can save it for later, and build it later somewhere else.

What we did, what I was thinking about it, that I was thinking that this is not enough. I made a blueprint parameterization, which means you can basically make parameterize blueprint with generic stuff. I would compare it to template in C++. You for example, you make a station, which unloads iron, and maybe you have iron filters on the inside of the zone. Never know, but things can come to it, and the name of the station says that it's iron drop off station. Normally, you make a brain of the station, and then you need to configure the station manually to what you want.

But maybe if you have a blueprint in which all the filters and the name of the station was set like, parameter zero, and up on building, you are always asked like, okay, for this station, what station is it? Okay, this one is iron, and this sets all of the parameter things. Fills them with iron on iron plate, and then you click just next to it, and you make an iron station. Basically, it can be used for many things. Basically, anything that you can configure in a game, can now be specified in a generic way, put in a blueprint, and then now - and you can parameterize numbers, you can parameter - you can make formulas with one numbers, depending on the other. Basically, you can, this way, you can make a template that's really strong for building things, different ways.

I was thinking that this might be a little bit too geeky, and I wanted to do for a long time, but I was thinking, maybe it's too much, and it's like, it's over though. But then I was thinking, I'm not that special. Factorio was right with the idea that, hey, the game is maybe a little bit too complicated for average player, but I'm going to make it fun for me, and maybe there are enough of people who enjoy it. I was saying, if I wanted so much, I think there will still be people that will enjoy it. Based on the play testing, because we have some beta testers, apparently, some of the people are using it, because we had a lot of tweaks around it, because a lot of feedback around it.

Apparently, it's not completely stupid now. This feature is nice, because it doesn't make the game more complicated. If you don't specifically press this one small button in the blueprint, you can press parameterization, and that's all it's not in your way, it doesn't make the game more complicated, so I love these changes where, when someone wants to do power user stuff, basically, they can, but it doesn't make it less approachable.

[0:51:01] JN: 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 useful if you're doing it."

[0:51:10] MK: What system, sorry?

[0:51:10] JN: The circuitry, when you're using -

[0:51:12] MK: Oh, yeah. Oh, yeah.

[0:51:13] JN: I think you actually have a pop-up that says like, "This is complicated. You don't need it to complete the game."

[0:51:16] MK: Yes. Yes.

[0:51:17] JN: I like that approach, because you have power users, your very popular software engineering community as a whole. You have people who will enjoy that stuff, but it doesn't get in the way for people who just want to do it manually.

[0:51:26] MK: For example, also, there's the circuit system. This is so interesting. I think it's really, because I actually never really used it that much before we developed space age the circuit system. I use it just for absolutely basic stuff, but not anything more complicated, like two wires at something. A part when I was playing the lights, etc. In a space age, there's definitely more usage of it, more places where it's useful, and also, I learned some tricks from Vastla, which are really cool. I realized, oh, there's some - Again, there's a big difference. Is this certain system complicated, or do you need any way that you need to be start smart to get it, or is the system just annoying to use? It's really important to differentiate these two things, because a lot of - it might sound obvious, but a lot of times, these things are the space one for another.

We made some little tweaks of it, general ones, which might look not really 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 insert active, move things from one place to another when there's more than 50 items in the chest. Basically, suddenly, you have some indirect logic.

We made a little piece of logic that, in the slot, where you specify what signal item it is related to, you see a number, what is the current value. It's a small thing, but suddenly, oh, this is the right number, I know it's connected, and the number is already there, and I know, is it working or not? You can immediately see the formula, if it's true or not, the inequality, not the formula. I mean, these things, even when you are suddenly, you realize, oh, it was me not being stupid, being confused by it, it was just the system being a little bit around the corner.

[0:53:22] JN: That's such a good example. I literally used that on a belt two days ago. I was like, I don't have no idea how much material was on this section of the belt. How do I set this? It was right there. It was -

[0:53:31] MK: Yeah, exactly. I know, okay, this is - when it's this full, it means around this number, so we know. Yeah, it's not only for understanding it, but to know what numbers. Yeah, exactly. I think that generally, I have a feedback that 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 circuits." They use these systems much more now, because they are just more approachable, so this is a big takeaway. 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.

[0:54:07] JN: Yeah, that's perfect. Yeah, it's funny. As I said, it's been a while since I played. First of all, I think I had, and I've been playing on 2.0 the last couple of the days. I don't think I had realized how many of these things were recent improvements, but yeah, it all felt really nice. On the space age, we mentioned multiple planets. I think there's five planets.

[0:54:26] MK: Well, five together. So, four new planets, basically.

[0:54:29] JN: 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 cover what each one does. You've tried to make them not only unique biomes, but they also have all their own tech trees and mechanics and different environmental conditions. I guess, just as a design question, how did you approach deciding like, okay, if you want to expand the tech tree, we want all these planets to feel distinct and have unique mechanics.

[0:54:55] MK: Well, so this was very straightforward. First of all, I played some other game. I don't want to say with the name, but basically, where you could go to other planets and etc. All it was was that you go to other planet and it's a mining outpost. Basically, you get everything home and then you build. And it's, meh, it's okay, it's just a different way of getting resources, and doesn't feel that interesting. We definitely knew from the beginning that this is not what we want. We wanted the planet things to be more like, you know everything goes home, but things move in different directions and it's a net of factories at work in tandem and import and export different things.

The second thing we wanted from the start, but realized even later how important is it is to minimize the repetitiveness. Basically, if in the extreme, if all the five planets are practically the same, it's just one special thing about you. 90% of the time you make the same thing on the planets, it's just repetitive and boring. We tried to, from the beginning, obviously, we tried to make them different, and we try to make different mechanics on different planets. But I didn't realize and I had blogposts about these, how much more different they should be, compared to how little they were different at the beginning. We were making every iteration internal, which was 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."

Now, and we ended up in the state when they are really a lot of different - the difference is huge. Yeah, it was important that - Basically, also it means that having just 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. If you just edit 50 more recipes with different icons, but it would be just always the same, you put these two items and the third item goes out, or something, and it's just again and again, just on different planets with a little bit different graphics, it wouldn't - for me, that's where we were - this isn't the end 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 those things you already know. We were trying to improve these ratios also. This is why we have planet this - my favorite and the most "hated," but really, a mechanic is the spoilage.

[0:57:34] JN: I knew. It was like, Gleba

[0:57:36] MK: Yeah, Gleba. I knew from the beginning that I want this and this is - this will be fun. 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 - everything is renewable. You don't really think in a way like, "Oh, I will do stuff here if I don't use it." You say like, "I don't care. I just throw everything, because new stuff is coming infinitely," and you just do stuff differently. Suddenly, everything is different. You build different. Then you have other planet with, you have the Fulgora, but there's this scrap. Instead of, you don't have any resources, you have just scrap and from the scrap, you get all more or less high-end products. Instead of making from simple to complicated, here, you put it on its own head and make it from the complicated stuff and you recycle them into more simple stuff that you need.

Normally, you use iron to make iron gear wheels. Here, you get iron gear wheels. If you need iron, you need to recycle them to get iron. Suddenly, again, 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. Basically, suddenly, the way how you think about these factories is actually really different from factory to factory. The things that you do the same way are, I think, minimize a lot now. From basically, I think that what we hoped to have is happened. I'm happy, actually, with this, because as two years ago, I was depressed that in my blog post, I was saying that I was thinking, "Oh, maybe this is all a horrible idea. Maybe this can be done and it will be just boring. This whole thing will have to be scrapped, because it's not worth it, or something." It was an existential crisis, almost. Like, what am I doing here? I'm a fraud. What's going on?

Then, after the two years of actually focusing on this and not giving up, I'm really happy to say that it didn't end like this. 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 two years, there's a team of 30 people. You made something that's half almost done, or we feel it's almost done and everyone feels like, "It's not that good." It's weird to say it loud. It's awkward. Everyone's patting themselves on back, how are you moving forward? How do the [inaudible 1:00:11] are being finished and everything? It's not fun.

I think it's really important to have this place, have this, what is it? Atmosphere, where you can say, "Hey, I think this is just boring. This is shit. This part of this is shit. I don't enjoy it. What could we do about it?" It's a positive thing, actually, because in the beginning, it's not nice to say 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.

[1:00:38] JN: Yeah. It's empowering when you're in a position to change it, right? Once you recognize it.

[1:00:42] MK: Yeah. Obviously, obviously. Yeah, this is really important to be open, because I don't know how it's - sometimes with other games, because I feel like, sometimes they want to prove that they are best designers, or they want to prove that they have unique ideas, or they are genius designers, or something. I think it's not the goal. I think it's super important to put the ego aside and always remind ourselves, what is the actual goal? To make the game fun. Not to prove anything to anyone. Just to make it fun. I think this might sound a little bit patronizing, or something, but I think this is a really important thing, too.

When I saw professionals from all other fields, not only game design, software, but even actors and people like that, and they work in a team, they said, whenever they put their ego aside and are able to say whatever, everyone that, I think that's always is helpful. I'm not saying we are perfect with this, but I'm trying to. I don't think that that's very important. I think people should do it a lot in game design.

[1:01:48] JN: 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, "We tried this and it wasn't fun, so we've done this way." Obviously, your team has internalized it and it's happened to do it publicly, which is also a rare thing, right? I've thought 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. The mechanics of a content one is also really interesting. I feel like, when I first saw, is it Gliba or Gleba? When I first saw Gleba, I was like, that is an attack on the bus. That is an attack on the idea of one big central belt. 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.

[1:02:26] MK: In a way, it is a little bit also a tech on the bots. Even if it's a little bit subtle. But basically, because the logistics box, it's a non-secret that they cannot make the game easy in some cases. Maybe sometimes even a little bit too much. With the bot advantages that you just make, request a chest and provide a chest and the post chest, it's almost like -

[1:02:48] JN: Almost like, on any base.

[1:02:50] MK: They just move it. You don't really have control, which specific, because of the spoilage, suddenly, two items of the same type are not really the same thing. One is almost spoil, one is fresh. With the belts, you have really full control. The fresh items just made go this way and after that, they go some other way. Only the fresh - you have really strong control over it. I mean, if for example, want to make the fresh possible science specs and send them out and not just some science, it's really hard to do it with the circuit network. But with the belts over all the factories, it's much better. That's another.

[1:03:29] JN: Yeah, and that's really interesting. I'm very conscious that we've gone quite long. I've found a couple of questions before I let you go. We spoke a little bit about the operation of Wube, I'm running a company of 30 people now. How have you found the transition from loan developer to now running a sizable game development studio?

[1:03:48] MK: It was very smooth. From the beginning, we were very - it was very clear to us that we don't want to just become a huge studio with hundreds of people, because it doesn't feel fun to us. Once you have enough money to pay the bills, it becomes more and more important to actually have fun while doing this stuff. 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 view, but imagining that having 1,000 people having to deal with it and manage it sounds more like a horror than something I would enjoy. 

It was very, very gradual. First, we hired a friend and we hired another guy, then we were four, five people. Every half year or something, we hired someone. It just was growing very gradual. There was never a big step, very suddenly, it was double the studio size. I don't really have some one point things would change a lot. I mean, there was just one change where we split a little bit to manage, not management company. Now, we have Fatsloff, which is the main manager of graphics department of those to do. He basically makes the management of it completely for me. He's super reliable and everything. I don't need to know what's going on there at all. I don't need to know what they are planning, who's doing what. I just see the results in the master.

[1:05:18] JN: The dream.

[1:05:20] MK: Yeah. It's really great. Then these programmers, if I still do have some say, obviously. Basically, I'm mainly - my main role is being the cover, accept approval, basically. When I put the stamp here, this is fine. This is not fine. That's my -

[1:05:36] JN: The kovarex enrichment process.

[1:05:37] MK: Exactly. That's my main role. Mainly, we made a system where we made senior programmers, which are people assigned to them to ask questions and to solve something with them. Only they would come to me person, or when it's not clear what should be decided. Or either, it's a gameplay thing, which I - that's my main role. It's not that I would - Actually, that's one of the things. Basically, my role, I have three roles. One is technical programming still. Second is gameplay and third is approving stuff. For example, with the gameplay stuff and gameplay - game design is far from me designing everything. It's actually almost opposite. In the space age, I was mainly designing and asking for the basic asset like, "Please, let's develop spoilage in the code, so we can build something around it. Let's develop this."

Then, Arandel came, because he's super creative. I told him like, "What if you proposed some piece and something on what would happen, what would happened on above and we have spoilage." He made something. He made a lot of stuff. It was super complex. Let's say, four times more complex than what we have now. The good thing is that I didn't really have to 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 scrap it. I still was there in every gameplay, important gameplay decision, I was there and saying my last word. But I was not really, didn't have to invent.

Obviously, I invented some stuff that I wouldn't invent anything, but I didn't have to invent much, because they were really great doing this. Yeah, this is I think I would - This is my role. But this means I still have my past. For example, when I was talking about the blueprint parameterization. For example, this thing I just programmed myself. The point is I still - we have 30 people on the team, but I still spent most of my time actually programming code, or doing stuff related to programming code. Managing is the smaller part of the work. Maybe almost half at this point, but still, I'm really happy to be like this and it was to go 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 checking task and doing management. That wasn't my goal.

[1:08:09] JN: Nice. That's awesome. Well, I'm glad it's worked out that way. I guess, my last question, it's been 10 years of Factorio over, I think since you announced on Indigo, Kickstarter, whichever one it was, and space age is just around the corner. Would you say what's next for Wube?

[1:08:24] MK: The typical question. Well, actually my son, because actually, I have three sons. One of my sons asked me yesterday when we were falling asleep in the bed like, what will you do when you finish? For me, it's mainly, I wanted to stay, and I say it to everybody, but I want to say even here, we will finish this expansion. We will almost certainly have 2.1 release and some support and do some little things here and there. But I'm certainly not planning another big expansion pack for Factorio two and three years, something like that, or Factorio online, or whatever.

I think, it's like you said, it went 12 or 13 years of doing one thing. I think it's enough for one game. I think Factorio will be finished. The point is that, it's the game - You can make it like, as I said, you can increase the fun density by making more quality improvements and more power usage stuff, which is still, we can also do more optimization, by the way. For example, you are thinking of the fully multi-threaded, fully YOLO, multi-threaded Factorio, where you actually - Because now we have some multi-threading, for example, I'm sorry for tangenting, but we have -

[1:09:39] JN: No, it's great.

[1:09:39] MK: - for example, transport belts. When you identify the two belts are completely independent, they are actually can be updated independently, or things like that. We are the first things that are obvious and simple. Relatively simple. We already have multi-threading, but we don't have multi-threading for the actual core of the Factorio update, which is the insertors and machines and everything. We have a plan of how it could theoretically be done with some unanswered question, etc. It could be interesting challenge with, I don't know if it's actually how much it is possible. It's not clear. But it could be something really interesting to see how extreme it can get with the performance, obviously.

The point is that Factorio, we can improve these things, quality of life and performance, etc. Also, we can add content. I think, Factorio is big enough. Adding more and more content at this point, I feel like, finishing space age for me, it really feels like a journey. Making it even longer feels unnecessary. Also, there are mods. For me, it feels it's enough. We added a lot. Making it more would be just a little bit too much. It would improve it for less and less people. That's how I would say it.

Obviously, there are always some people always like it to be more and more complicated and longer and everything. There are less and less of them, the more the game is actually long. The point is that it would actually be like, the closure of Factorio. 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. Then I also wanted to do RPG game. I loved RPGs. I think the best computer game I played ever was Baldur's Gate 1 and 2, and Kotik and games like this. I was thinking that maybe this was always my dream to make RPG game. It feels like they are easier than Factorio, because you don't need the performance that much, I think.

When we come to the, if it's not multiplayer, 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 two, three multiplayers removed, and some of their tech, they would be at times simpler. Also, you don't have a huge factory with - in Factorio, 200 different UI windows, eventually. Some for all the machines and all the settings and everything.

[1:12:23] JN: It's between inventories and spell systems, all the stuff. That's to be a good amount of UI.

[1:12:28] MK: Yeah. Actually, it's yeah, it's not that much. It's pretty, like it's order of magnitude less, I would say.

[1:12:34] JN: Interesting. Okay.

[1:12:36] MK: I think it should theoretically be easier on the technical part. But obviously, it's much, much harder on the content part where you need to -

[1:12:45] JN: The creative font. Yeah.

[1:12:46] MK: Yeah. It depends what you do. You can have very big production quality, where you spend a lot of time and resources on, I think I don't know, open world with all the graphics and shit. Or you can have simplified graphics and you focus on the gameplay, make it around some fun mechanic with actual super simplified environment. I mean, everything is, this is all up to question. But I have an idea about one specific mechanics that I would like to try in a game. Maybe this could be done, but I don't know. I don't have promises. Main, I want to finish Factorio, have a vacation, and -

[1:13:28] JN: A long vacation.

[1:13:30] MK: Yeah. I mean, from my personal experience, I know that half year is a maximum to have a free time. After that, I just need to have a project, or I would become mad. As long as I'm alive, it's given that I would do something. Having some other game is one of the possibility. We also wanted to make - this a weird topic, but we wanted, I want to make K++, which would be my new version of C++. This could be a long topic, but basically, I've worked on C++ for more than 20 years now. I think 25 years almost, or even more, which is crazy. I love the language, but I also hate the language. There are great things about it. I think a lot of the bad things about it just can be solved. Just no one did it. Already decided to solve make complete by making completely different language, which is -

[1:14:26] JN: The Rust direction.

[1:14:27] MK: Yeah. Rust, or language is too different. What I was looking for is keep it like a C++, but fix some specific problems, make some very specific changes. If you are used to C++, you start using this one thing, you spend one hour learning new things and you can just continue working, something like that, but making it great. Obviously, yeah, and the question is if you wanted K++, what would we do with the graphics department? Obviously, that would be a project not meant for profit, because this 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. Then if it's great, if it's work, then it would be using our experience, but we had to improve something. Obviously, the question is it will be just another programming language. Maybe it's not worth it. There are a lot of possibilities.

[1:15:29] JN: It's a very cool idea. That would be a great legacy of Factorio, if you were able to use those resources to scratch that itch.

[1:15:35] MK: This is another thing that I've been asked. I'm planning that at some point, I don't know when, that Factorio would become open source, and people could just do whatever. They could just fork it and make some crazy stuff with it, or make, you know. Actually, this is one of the things, because Factorio is not really open source, but it's a little bit. We have a lot of people that have access to the code, actually, from outside.

[1:16:01] JN: When that list gets long enough, you may as well just go the whole way, right?

[1:16:03] MK: Yeah. I'm a little bit afraid to say it here, but I will say it anyway. 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?" We're just, "Yeah. Why not?" I mean, why not? What could happen, actually? What could the person do?

[1:16:20] JN: We take no responsibility from the state of your inbox after this episode goes out. That's not our fault.

[1:16:26] MK: Yeah. If luckily would go, factorion.com, and they manage it for me. Basically, we have like, I don't know how many people we have there. 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. In a way, it's a little bit of an open source. Not really for a profile, but it's we are open to it. That basically two reasons why we don't do it. One is that it's absolutely fine to have open source and paid product at same time, but people just are not used to it. It's a little bit weird. The second is that imagine that it's actually open source, and there's 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 a lot of work.

That's actually one of the reasons that it would be a lot of work to go through it. On the other hand, it could be a great experience to see. Maybe people would make a great - I'm quite sure that always when you have more eyes looking at some code, it could be 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 code, etc., and having ideas about this, having conversation about some specific code with strangers, it sounds like fun. Seeing what people do with the game all sounds like fun. It will happen at some point.

[1:17:55] JN: Yeah. I totally get what you mean about. People not being used to the juxtaposition. I think, it's after the long tail of space age, it would sound like a good time. You wouldn't consider doing, I guess, something like, the code is available, but it's not technically open source. You don't accept contributions, that kind of thing?

[1:18:11] MK: Maybe, yeah. I mean, something this could happen, but definitely in upcoming year, we have different things. I think it will take at least half year to stabilize space age, and then half year to stabilize what happened, etc., and reconsider what to do. After that, we can start thinking about it. Yeah.

[1:18:32] JN: Cool. Well, kovarex, you've given me so much of your time. Thank you so much. Best of luck with the release. I hope it all goes smoothly. Yeah, thank you for joining us today.

[1:18:40] MK: Yeah, thank you. Thank you. Sorry for my weird English accent. It's just Chinglish.

[1:18:45] JN: No need to apologize at all.

[1:18:47] MK: Yeah. Have a nice day. Goodbye.

[END]