Oh man. It really has been a year since I started this project. Can’t quite believe it’s already been a year, while also not quite believing the project carried on for a whole year. In the beginning, it was just a silly idea that I wanted to try out and see where it would go, not really expecting it to become an actual project with dozens of people regularly contributing. It would have likely faded after a few weeks without tons of people stepping up and contributing. But (at least in this reality) it didn’t, which I’m very happy about and grateful for.

Conor_ will thank the core team below, but I want to say thanks to everyone that contributed to the project. You’ve all been such a joy to work with. Thanks to the people contributing articles for presenting your passion projects and being so receptive to feedback, without you guys there’d be no project at all. Thanks also to the translators for working tirelessly on the various translations so more people can enjoy the project, and for putting up with the occasionally chaotic release schedule. Finally, thanks to the techies (especially MagPie) for fulfilling our every request concerning the website.

Читать полностью

You remember April Fool’s day this year? Was quite a while ago already, but if you visited the subreddit on that day, you probably saw arrow in my gluteus maximus’s mind-bending video. If not, this week’s issue #44 of Alt-F4 will catch you up and then go over how exactly this dark magic presentation was achieved!

A new perspective on “A new perspective on trains in Factorio” arrow in my gluteus maximus

Four months ago I released a video called: “A new perspective on trains in Factorio”. If you haven’t seen it yet, please watch it before reading the article, as it won’t make too much sense otherwise.

Some people have reportedly experienced headaches after viewing this video. You have been warned.

Those who downloaded the mod linked in the description know that this was an April Fool’s joke. For those who didn’t figure it out: I’m sorry. A few people have asked me for details on how I made this video, so I decided to write up a quick explanation. Don’t try this at home.

I’ve seen some people speculating that I somehow extracted 3D models from the game. That’s not needed, it’s a simple rotation of what’s already shown on screen. While the idea might be simple though, the execution is a bit more complicated. The first problem you come across is that screens aren’t circles. When rotating, parts of the image gets cut off, while other parts such as the GUI are missing.

I ended up applying my usual solution to recording problems for Factorio: use screenshots instead. Ingame screenshots are not bound by the limitations of normal screen recording. Therefore to capture the video I simply capture a screenshot every tick over a larger area than is normally visible. That way, no part of the screen is ever cut off when rotated.

The next problem is that the UI also rotates, this is not something we want. Screenshots also come to the rescue here. The take_screenshot() command has an option called show_gui. The trick is to take two screenshots every tick, one with the UI visible and one without it. If we take only the parts that differ, then we end up with only the UI, which we can then superimpose over the screenshot without UI. At least that was the plan. Various video editing problems made this unviable. For example, my video editor did not support lossless formats (that I could find, I tried a bunch). Small differences in encoding thus end up in the UI.

However, I found out that in recent Factorio versions the UI is no longer fixed to your player’s position in screenshots. It is always visible no matter what part of the map you take a screenshot of. So I looked for a colour far away from other colours that occur in the game. I settled on pink. And I changed the image of some concrete to be pure pink and turned clouds off. I changed the location of my UI screenshot so only the pink concrete is visible. This way I can get the UI by using a sort of greenscreen, or rather a pinkscreen in this case.

There were a few small problems with that though. Turns out there are transparent parts in the UI, namely the details panel that shows up when you hover over things with your mouse. It looked purple now. I ended up manually cutting it out of the UI, and nobody seems to have noticed.

Next, I created a small mod that played a sound whenever I started recording screenshots, this way I could sync up the in-game sounds with the screenshots. Similarly to how movie studios use clappers. The mod also wrote out the value of game.players[1].vehicle.orientation into a text file. I used this to calculate how much rotation is needed but smoothed out using splines.

I feared that these steps would not have been enough to make it believable. Taking that many screenshots slows down the game enormously. I was worried that it would be obvious that the footage was sped up by looking at my motion in-game. So I looked for a way to make the recording go faster. After recording the screenshots I encoded them into an mp4 with FFmpeg, so why not cut out the middleman and try to hook up FFmpeg directly to Factorio. Both encoding pngs and writing them to disks are expensive operations. So if I could skip these steps it would go a lot faster.

Step one would be to extract the raw image data (not to be confused with the .raw format) directly from Factorio instead of encoding it in a png. I couldn’t find an easy way to do it, but turns out a .bmp is very close. It’s the image data backwards with a header slapped in front. So this should be way faster to encode than a png.

Next to get this into FFmpeg without saving to disk first. Turns out FFmpeg has built-in features for piping images, so a named pipe with a .bmp extension did the trick. (Example command: ffmpeg -f image2pipe -framerate 60 -i - -r 60 -c:v libx264 -vf format=yuv420p -crf 1 example.mp4 -y < pipe.bmp)

Don’t forget to keep the pipe open between screenshots with a sleep command: sleep 10000000 > pipe.bmp, kill the sleep command at the end to let FFmpeg finish the recording. I did a test run at a low fps and … that’s not right! What’s going on here?

The problem is that images are getting mixed. Factorio rendering is multithreaded. While one frame is still being written to the pipe, the next one might already start. Essentially mixing the pixels of both frames together. The fix is to force Factorio to wait until the previous frame is rendered before starting the next one. This can be done with by calling game.set_wait_for_screenshots_to_finish() every frame. This however slows down Factorio enough that we no longer can call it real-time. Although I still have some ideas to speed it up, at this point I spent way too much time on this project already and decided to go with the tried and true method of using replays.

Factorio has this wonderful feature where it doesn’t check if the code of the mods used during the recording and playback of a replay are the same. So I first recorded a replay normally at a normal speed. Then I edited one of my mods to take screenshots every tick. Then, when playing the replay, Factorio will start taking screenshots. That is assuming the changes you made to the mod don’t change the game state.

Sadly due to using replays, I had to cut a few scenes. I was going to show how weird it feels to build things from a rotated perspective, but it turns out Factorio doesn’t save your mouse position in the replay. So in the replay, the UI follows your mouse at the time of playback, not the position your mouse was in when you recorded it.

All in all, this was a fun challenge and I enjoyed confusing the Factorio players.

Contributing

As always, we’re looking for people that want to contribute to Alt-F4, be it by submitting an article or by helping with translation. If you have something interesting in mind that you want to share with the community in a polished way, this is the place to do it. If you’re not too sure about it we’ll gladly help by discussing content ideas and structure questions. If that sounds like something that’s up your alley, join the Discord to get started!

In this week’s issue #42 of Alt-F4, after previously investigating the games that influenced Factorio, we’ll now be looking at how Factorio influenced the automation genre as a whole, if that’s even a thing. Maybe it isn’t. After 7.5 million years of contemplation, Nanogamer7 has an answer, and it might surprise you.

The Best of Its Genre – The Influence of a Game Nanogamer7

A few months ago (in issue #34) I tried to find the origins of Factorio, and with it the origins of the automation genre. But since the time Wube pioneered this genre in 2013, many games adapted and embraced its ideas, like Satisfactory and Dyson Sphere Program, but also games more focused on survival like Astroneer, later versions of Minecraft and more recent mods for it. In this article I want to explore what became of the automation genre, and how automation games are differentiated to survival games with some automation.

Part 1: The Big Three

When you ask someone to name some automation games other than Factorio, the most common response you’ll get are Satisfactory and Dyson Sphere Program. Together with Factorio, they are even regarded as the (un-)holy trinity of automation by some players. But what makes these games stand out from the rest (apart from their rating, the highest among all games on Steam with the “automation” tag)?

• All three games are set in an open world and you, the player, are an entity in it, building the factory. Neither of these are required for automation, as for example shapez.io perfectly works without a playable character, and there a plenty of games like Opus Magnum that are in a level-based puzzle environment.
• Your progression is mainly through a skill/technology tree (be it a very shallow one in Satisfactory); Special technology to send through a space elevator in Satisfactory, research matrixes in DSP, and finally, the bottle-shaped science packs in Factorio. Most open world (survival) games feature some sort of skill tree, but acquiring new points rarely features a connection to the game world. The factories, however, have to be built primarily for the tech tree itself; you don’t have some requirements to limit your progress in the “story”, the requirements are directly tied to the progress towards the final goal.
• And finally, all three games mainly challenge your knowledge and understanding of logistics. While the spaghetti of some bases might suggest otherwise, space isn’t actually an issue (or at least not a big one) due to the open world, but getting massive amounts of raw resources from a mining outpost back to your main base requires you to overcome obstacles like mechanics, throughput, and environment. And it can get even more challenging, for example moving production to said outpost to export the most dense/compact products (see Alt-F4 #7) uses complex ratios to get the most efficiency. This challenge might be a direct result of the open-world nature of these games, but especially long range trucks and trains provide a much needed “unknown” variable to the defined ratios (unknown as in not as obvious as items per second on belts), as well as a challenge, a bottle neck scaling inversely with production.

The different research trees, with DSP more similar to Factorio, and Satisfactory in its shallow tier system.

Apart from the similarities in gameplay, the three games also feature a remarkably similar scenario of the player being dropped on an empty planet; however this is probably of the most obvious narrative reasons for the player to start from scratch. This article won’t elaborate on the story behind the games, but rather focus on the gameplay itself.

These are some of the most important similarities between the three games. There are definitely more smaller ones, or in areas other than gameplay, but if you get to the core of it these three are what define the games, trains unfortunately not being one of them. But how do games not generally regarded as automation fall into this scheme?

Part 2: Automation in Other Games

Speaking of scenario, there is a forth game with this scenario, with a similar theme of multiple, small planets, with a great rating, with the “automation” tag on steam, and it is arguably even more popular than the other three games: ASTRONEER. Why didn’t I mention it before? It certainly has a similar scenario, you can automate large parts of your production, and so on.

Let’s get back to the previous article, what does automation even mean?

Keep in mind this is only one possible definition of the genre, but it already runs into some problems. For example Nanocarbon Alloy, one of the most important Astroneer endgame materials, already fails to be automated at one of the most basic steps of getting all required resources together—which isn’t necessarily bad though, the game wasn’t developed as an automation game. The auto arm—and with it some other tools to automate—only got added in version 1.13, a full year after the original 1.0 release of the pure survival game.

Many (survival) games feature some sort of automation today: Minecraft’s hopper, added with version 1.5 in early 2013 is the first example of a simple machine to machine transfer I could find, and might have influenced Factorio’s inserter too, but ASTRONEER’s auto arm, the auto miner, the conveyors in TerraTech, the belts in some Overcooked levels are all reminiscent of similar Factorio mechanics, and all got released after Factorio first got popular. And then there are mods: Basically every tech Minecraft mod since 1.6.4 (although those might also be influenced by the earlier Minecraft mods) features automation.

Still, none of the games above have automation as the defining mechanic, it only gets complimented by it. You might spend way to long building complex machineries, intricate factories, and tightly packed rovers, but none of them progress your gameplay directly. You still need to explore, discover, fight, and decorate your way further towards your final goal. There can however be made an argument for SkyFactory, one of my favourite Minecraft mod packs, which circumvents the problem of exploration by having nothing to explore. It still allows you to incase your factory in nice blocks, decorate it with flowers, which is the other main goal of Minecraft, only coming as a secondary possibility in Factorio.

How do games not generally regarded as automation fall into the scheme from part one then? Logistics present themselves in the form of inventory management, and is a common part of survival games, as is the open world. And the skill tree, which the automation games make completely unfeasible to hand craft, is just supplemented by automation in the other games. This supplementation is the important part, adding automation as another mechanic among many has become popular with the popularity of automation games.

Part 3: Simulation, Idle, and Puzzle Games

Most games so far are in some way an open-world survival or sandbox game, however there is a subgenre of automation most of us have come on contact with and regularly play: Designing the assembly line itself. There are numerous automation puzzlers which exclusively focus on that part of automation. One example is Opus Magnum, as already mentioned, or factori, a game scoring one of the first places in the recent GMTK 2021 game jam. But fit the definition (“you make stuff that makes stuff”) chemicals in one, and letters in the other. Does Emergency Protocol (there area lot of puzzle games in game jams btw) fit the definition? You make a pattern that makes a path? In its core it sounds like automation—you tell a little robot what to do (program it), and it repeats your commands—but that also sounds similar to idle games—set something up, and it does a job for you while you are away.

Speaking of which, idle games aren’t really considered automation games, and neither are management games or simulation games, as I discussed in my last article. But then again, there is the meme of automating Factorio itself, which some players have successfully done. On a more serious note, some players really do play Factorio as a management game—city block blueprints often have every assembly line, every problem already solved, your job now is to balance the different resources and power, and manage the factory on the larger scale.

Conclusion

To summarise, automation still isn’t a type of game like “puzzler’, but it can definitely be the defining genre. However it is still possible to add automation to game, without having it at its core. That being said, my last article left automation a bit more open, and I hope a could give a more SATISFACTORY definition and conclusion this time by FACTORIOing in more recent games.

Contributing

As always, we’re looking for people that want to contribute to Alt-F4, be it by submitting an article or by helping with translation. If you have something interesting in mind that you want to share with the community in a polished way, this is the place to do it. If you’re not too sure about it we’ll gladly help by discussing content ideas and structure questions. If that sounds like something that’s up your alley, join the Discord to get started!