You just don't see commitment to shipping quality product in the games industry like this. This is what makes Factorio special.
You just don't see commitment to shipping quality product in the games industry like this. This is what makes Factorio special.
In the decade or so that I've played Factorio, I can't even remember a single crash of the base game. It was always mods that crashed.
Factorio performance is also fantastic, running smoothly on potato PC's until you get in to the megabase range. It's mostly mods that cause performance problems, but even those have gotten a lot better over the years.
The Factorio devs could really give a master class on how to make games moddable. Factorio's ecosystem of over 5000 mods is a testament to that.
I wish modding APIs in general did more sanity checking before loading a mod. A low hanging fruit is APIs to be statically typed, and also to not use nulls on such APIs and things like that. A more comprehensive check is to verify whether two mods are guaranteed to be compatible (but this sounds a bit hard).
But more importantly (not sure if that's the case with Factorio) not break the damn APIs all the time. Lots of games that are actively developed don't bother keeping stable APIs (a bit like like Gnome and its disregard for extension APIs), breaking mods at every new release. An egregious example is Europa Universalis IV and other Paradox games. This ensures that there is a tail end of mods (which is by far the majority) that just will never work anymore, and the mods being kept up to date become rarer and rarer.
As an example of just how far accessible APIs can benefit games/their players: The god awful language and API that has enabled Armed Assault franchise modders to create entirely new games - literally, PUBG started life as a mod for Armed Assault 2. Armed Assault 3 launched ten years ago, and there are still many new mods being produced today, and Bohemia have further embraced this community by supporting "community developed" DLCs such that modders get rewarded for their effort.
I often wonder how much better/diverse/stable these innovative and entrepeneurial ventures could be with a "proper" API.
Lua has been a modding staple across countless games, so millions of gamers/modders are already familiar with it.
I'm convinced that chosing Lua for modding is one of the main reasons Factorio has over 5000 mods now.
If they'd chosen a more obscure language I'd doubt we'd have nearly as many.
As for Lua I think it is rather chicken:egg. Lua is popular because it is used by mod APIs, or is Lua use by mod APIs because it is popular?
My own experience is the former. I think it is a horrible language (in that I argue many others are better) and especially difficult for new-to-programming gamers with great ideas to pick up. Haskell or Erlang (or Java or C#) with type-safe APIs would be much more educational for them, and provide better support IMO.
> especially difficult for new-to-programming gamers with great ideas to pick up
and you're proposing haskell or erlang as an alternative first programming language for somebody?
when i eventually got exposed to python (but more heavily C/C++, and even some lisp/pascal) and came back to lua, i was grateful lua did not inundate me with parens/primitives/modules/data-structures/grammars, and found the flexibility of the interpreter and also what lua tables present as a unified primitive for multiple container types to be so nice and accessible for getting right to flow-state.
i did not have to look up another API and read about a set of semantics provided with a desired module, i just needed to know 1. what i want to achieve and 2. a single API: the lua table
its small std library is performant and easy on the cognitive load, and then it plays so nicely with other languages and environments.
have you written much lua?
The Minecraft Java world at least starts with static types and memory safety. It'd be interesting to see if that results in a mod ecosystem that's more stable.
I still don't know how they pulled this off, and as a software engineer I've read all of the development blogs.
It is still impressive that you can scale this thing to huge mega-bases, with things smoothly gliding down coveyer belts, inserters swinging, bots flying around, trains everywhere, biters doing biter things all over the exposed (essentially endless) map ... and no problem in most cases.
60 FPS/UPS.
It almost seems as if the entire thing is written in handcrafted assembly compared to how other games perform.
I'm sure parts of it are.
As far as I'm aware, it's all C++.
For example, originally a conveyor belt applied a speed to any object in the same tile. Each frame the position of the object would be updated based on the speed, just the same as any other moving object. You could place down up to three objects side–by–side on the belt, and they would all travel together. But eventually they realized that this is a waste of time, because inserters only ever place items in specific positions on the belt, and the items are all the same size. This means that they could instead just keep a bitmask of which spots are filled, and a queue of items that will pop out of the edge of the tile. Even that is wasteful though, because you might have 1000 tiles of belts all in a row, so you can group them all into a single queue. Now you only have to put new items into the beginning of a single queue and take them out of the end, instead of doing that for 1000 queues. On the other hand, this means that you can no longer put down items at arbitrary positions on a belt; they will now snap into one of the 12 slots in one of the two lanes.
A similar thing happened to inserters. It used to be that they had a certain amount of rotational speed, and would calculate a new position and rotation for each of their three two joints every frame. Eventually they realized that 99% of the time they would be in the same few positions over and over again; it is only when they are chasing an object on a belt that is too fast that they need to calculate a position. The rest of the time they just loop through a fixed animation. This gave Wube the opportunity to tweak the animation cycles so that they are exactly the same length in all orientations of the inserter, which is definitely a good thing.
And of course they consistently paid close attention to data locality, so that every time they have to work on a collection of objects they maximize the amount of useful data that fits into the CPU cache. I haven’t seen the code, of course, but I assume that this means that they are using an ECS–style system where you have a dense array of just the position and speed of each biter, or just the animation frame for each inserter. The code can then loop over those dense arrays knowing that it doesn’t have to test the type of each item in the array (few or no branches needed), and that every byte loaded into cache will be used during the loop (maximizing use of the memory bandwidth).
I suppose that means in the developer's opinion, the game is not quite ready -- they wouldn't sell it to someone who expects a complete game. Caveat emptor. Fair enough. In practice it has been playable and enjoyable (at least by me) since first listed on Steam in 2019. New features and more polish come every few weeks, and it's coming up on 1.0. I don't know if they'll keep supporting it well after that, but it's clear to me they want to sell something good and complete, however long that might take, not just something profitable.
[1] https://store.steampowered.com/app/784150/Workers__Resources... (Windows only but runs great under WINE)
I can’t think of a single bug I’ve encountered across many, many Factorio playthroughs, some including overhaul mods.
In all the release notes, there is a sizeable section of bug fixes; time and time again, I was surprised that there were any bugs.
Hats off to Wube, you’re a true inspiration.
I know there are a lot of peculiar and hilarious hug reports for games like dwarf fortress, too.
And yes, they implemented all of it. Everything that was promised and much much more. Just check out the trailer for Echoes that dropped yesterday (the new update for the game): https://www.youtube.com/watch?v=dqpVCwwuyh8
I'm glad to hear he seems to regret it. I do suspect allowing some room for redemption and regret is a better strategy for reducing negative behaviors than completely writing someone off. It might have been nice if he faced actual legal consequences for his criminal fraud (alright alright I am not a lawyer), but barring that, I'll take self-correction.
Meanwhile factorio allows you to benchmark it by opening a save and running it for a set number of ticks -- it's just that stable in its simulation.
Not to say that ONI isn't a fun game, it has different elements (e.g. dupe management) that make it fun despite its instability.
In comparison, Factorio only started to slow down late game (or during very heavy biter combat).
I suspect where some games might just move on these folks really are committed to "hey let's rewrite that" type decisions that don't fit in traditional commercial game development.
It has been very encouraging to see that there room for an arguably improving quality when it comes to some games.
If people keep playing your game in early access, you must be on to something. There are tens of thousands of games people could be playing, but for them to pick yours means you are scratching an itch that can’t be found elsewhere, and that inspires developers create great games.
Early access does get flack for allowing people to release unfinished, often never finished games, but it’s a wonderful test of product market fit. If people try your game and like it, give you feedback to improve your game so even more people like it, it’s the ultimate positive feedback loop.
I don't game like I used to but I was playing an early access game recently, got a pop up on a keyboard shortcut to submit a bug with a screen shot and the game state.
Total win win for everyone.
https://www.gamesradar.com/zelda-tears-of-the-kingdom-was-ba...