Alt-F4 #12 - Reverse Engineering the Spider 2020-11-06
In this very easily divisible issue number 12 of Alt-F4, xthexder goes into some of the technical behind-the-scenes regarding the bouncy spider at the bottom of the page. Then, TheKool gives some newcomer-friendly insight into production modules and their uses. Finally, T-A-R shares some info on an upcoming community event that looks like a lot of fun.
Building Spidertron for the Web xthexder
As you’re no doubt aware, the Alt-F4 website has a spidertron sitting at the bottom of each page, similar to the rocket on Factorio’s website. Many people have probably clicked on it, hoping for something exciting to happen, only to be disappointed when spidertron merely continued bouncing in place. Now, readers with a keen eye may have noticed that this changed with the release of Alt-F4 #8 A Love Letter to Factorio. If you haven’t seen this yet, why not scroll to the bottom, click on your little buddy, and have him follow along!
When we first set the site up it was pretty obvious we should have spidertron do something, but we didn’t really have time at the beginning to record anything more than its idle animation. Recording spidertron is tricky to do, since we need to record without any background. We originally achieved this using a secret mod by Klonan that uses undocumented functions in the Factorio API to record gifs. Recording a loop is even trickier since spidertron’s movement is semi-random, so anything more than just the idle animation would require some extra effort to get right.
The original plan was to have spidertron crawl up the page and be the same back-to-top button as the rocket on the official Factorio site. This required recording an animation of walking upwards, and then looping it as we moved it up the page. Then, Dr.Magpie had the idea to have spidertron follow a targeting remote around the page, just like it does in game. This was way beyond what can be done using recordings, since there would be way too many combinations required.
Though knowing our community, there are probably some mad lads that would help with this just for the sake of it being a challenge….
— psihius (October 3, 2020)
Challenge accepted
Creating a functional spidertron for the website has certainly been a challenge, but also quite fun to work on. psihius’s comment prompted me to get to work in what I’d consider a textbook case of Nerd Sniping. The first order of business was to simply get a spidertron drawn, using the original Factorio sprites so they could be moved independently. I chose to use raw HTML and CSS elements, hoping that the browser would be able to accelerate rendering with the GPU. This turned out to have several downsides, since certain changes triggered a recalculation of the entire page’s layout and negate any performance benefits. However, with a basic spidertron drawn, I was free to start working on the animation side in JavaScript.
After all the legs are connected, spidertron is made up of 58 unique sprites (Each leg has seven sprites, plus two for the body). All these elements are controlled using CSS variables that can be modified from JavaScript. I started off with four variables per leg: the upper and lower leg lengths, and the upper and lower angles. Using some trigonometric functions I could then calculate the values needed to land the foot at a specific point. Using the mouse as a target, the first major hurdle became apparent… where do you place the knee?
I began studying videos of spidertron moving around in Factorio to try and determine how to make the leg movement look right. This Factorio Crab Rave video proved to be immensely useful, since I could jump around frame by frame and examine the leg movements. I went through many iterations, trying different ratios and formulas, but none quite matched the movement we see in game. Then it occurred to me that I wasn’t thinking in three dimensions. Spidertron’s body is hovering above the ground and, with Factorio’s isometric projection, this is done simply by subtracting part of the z-axis (height) from the y-axis (south). With this in mind, I went back to the video and noticed that spidertron’s knees are a fixed height (z-axis) above the body, and the knees are about halfway between the body and foot on the x- and y-axis. This 3D position is then projected into 2D, resulting in a near-perfect replica of the in-game proportions.
To get spidertron walking on its own, I spent some time cleaning up the initial code-spaghetti and started with the idle animation. This was an easy one; it’s just a sine wave applied to the body’s height off the ground. The body originally had an independent speed and position; this was later changed to use the average of each leg’s position, to prevent the legs and body getting out of sync. That left just eight points to animate and make “steps” toward the target.
The real spidertron can have up to three legs in the air at once, and uses a currently unknown method for determining the step order. For my initial tests I used a fixed step order, which worked, but didn’t look very good moving in all directions. I later transitioned to sorting the legs by distance from target and alternating between the closest and farthest leg. This is what was used in the first release, but I’ve made several small tweaks to the pattern and timing since to try and replicate the in-game version.
When a leg starts a step, it predicts where spidertron will be on the next step. It then sets the target for the leg, plus a little bit of randomness to reduce repetitition. Every frame, each active leg is moved towards its target. By Wednesday night, I was getting closer to a walking spidertron, and was determined to have something ready to go out with that Friday’s Love Letter issue.
On Thursday afternoon spidertron.alt-f4.blog was created so the whole Alt-F4 tech-team could test out spidertron and help with finding and fixing bugs. The way motion prediction was calculated in relation to frame rate caused any lag (of which there was plenty) to teleport the legs around, and very glitchy movements in general. Due to some CSS bugs the leg segments also had a minimum length which, in certain positions, caused further glitchy movements. After another late night of coding some of the major bugs were fixed, and the first public release went live on the blog.
More bugs were fixed over the following weeks, such as pixel rounding errors in the leg lengths causing the legs to jitter around when idle, and different monitor refresh rates causing spidertron’s speed to change, resulting in the legs getting out of sync with the body. Spidertron also received a few other updates, like its orange paint, fixes for the mobile page layout, and many performance improvements. Overall, I’m very happy with the result. It even ended up 150 KB smaller than the original idle gif, with all sprites, JavaScript, and CSS stylesheets included!
Thanks to yay, Dr.MagPie, psihius, and the rest of the Alt-F4 Techies for helping me build and test spidertron. For those interested, the source code is available on GitHub. Hopefully everyone has as much fun playing with it as I did building it. (The sprites are not included in the repo as they are the exclusive property of Wube and used with their permission.)
Complexity Corner: Productivity Modules TheKool
Welcome to the first in a series of articles about elements of the game that seem intimidating at first glance, but turn out to not be that hard to start using. The series starts off with a trilogy about modules, spending a short time to focus on each of the three choices in turn. Later, the series may return with additional topics. Each article will attempt to answer three simple questions: What is it?, What results can it give?, and Where should it be used?
Preface: Complexity bias in Factorio
Before diving into specifics, I wanted to briefly touch on why we might shy away from the complex aspects of the game and stick to the comfortable ones we know. If you’ve ever found yourself looking at something you are unfamiliar with and telling yourself “That looks complicated; I’ll just stick with what I know and figure that out later”, then you’ve experienced complexity bias.
Complexity bias is a mental tendency to see things as more complex than they really are, especially when we don’t fully understand them. When it comes to projects this may manifest as procrastination, as we avoid a task that we expect to be long and difficult. When it comes to Factorio, this usually manifests as a preference to stick with the comfortable game mechanics we know and understand in order to avoid learning how new ones like circuits or nuclear power work. However, just as that task often turns out to be much easier than anticipated, I hope to show you that the game elements you’ve been avoiding may be simpler than you thought after all.
What are productivity modules?
In case you aren’t familiar with them, modules are items that you can place into buildings to change some of their performance characteristics, like crafting speed and energy usage. They can also be placed into beacons, transmitting their effect to every building within range. This can be very powerful, which is why modules are often used in large builds to reduce the number of buildings needed to meet a certain goal. This often means they’re seen as an end-game tool, as seen in LoneWolf’s Megabase Thinking article for example. They can, however, be quite powerful much sooner. Indeed, they can be used as early as the green science stage, appearing immediately after advanced circuits in the tech tree.
Now, productivity modules are the most mechanically complex modules in the game as they do four things: increase pollution, increase energy usage, slow the machine down, and add a productivity bonus. As complex as they sound, that last one is the only one that really matters. The productivity bonus works in the same way as the mining productivity bonus: If you have, for example, a 10% productivity bonus then every cycle will add 10% to the productivity bar, and when it reaches 100% you get a free product. That’s right, free. It didn’t even take any resources, it just appeared out of thin air.
What results can they give?
Productivity modules then, while being the most complex module mechanically, have the most straightforward answer to how you should use them. Put simply, they reduce how many resources you need for your factory. If you want to get more output than your inputs would normally allow (such as when you are short on one or more resources), you use productivity modules. This means their use is as straightforward as it gets: for best results, spam the ever-living daylights out of them. They are actually unique in this regard, as they are the only thing in the game aside from the mining productivity research that gives something from nothing.
The earliest application is likely to be two productivity 1 modules in an assembling machine 2, which gives a +8% productivity bonus at the cost of -30% speed and a lot of extra energy usage and pollution. One of the latest applications is four productivity 3 modules in an assembling machine 3, which gives +40% productivity and -60% speed, with a boatload of extra energy usage and pollution. At this point, I hope you’re not worried about biters anymore! Getting 40% more output from your resources is a pretty big deal, and that benefit accumulates all the way down the tech tree if you’re using them wherever you can. If you’re using them at every opportunity in your rocket silo recipe, you can actually drop the raw ore requirements down as low as 15% of the original value! Don’t believe me? Take a look for yourself.
As mentioned, they do also reduce the working speed of whatever they are placed in. If you build closely to ratios in your factory, you’ll need to consider both the slowed working speed and the bonus outputs in your calculations, because these will turn all your ratios on their heads. To solve this, I usually just let KirkMcDonald’s calculator do the work for me.
Where should they be used?
So you’ve decided you’d like to use productivity modules. Where should you put them? The obvious answer is “everywhere you can”, but there are a few cases that deserve special mention, even if you use them nowhere else.
- Rocket Silo: If you load your silo with four of the productivity 3 modules, you only need about 70 rocket parts worth of materials to make your rocket, and you likely won’t notice the slow effect at all.
- Oil: If you are running a map that doesn’t have enough oil fields within reach and you’re struggling to pump enough crude oil, consider placing productivity modules in your refineries and anything that uses the oil and plastic products. It may not look like much, but it can help stretch that struggling resource further.
- Labs: You can place productivity modules in labs! Free science! They don’t even produce pollution; you’re avoiding the worst drawback entirely! What’s not to love?
- Mining drills: It’s a trap! Don’t do it! It doesn’t multiply with your mining productivity research, it just adds to it, and the research gives a much more significant bonus. You’re better off with speed or efficiency modules.
Productivity modules have a couple of special caveats though. Specifically, they can only be used for intermediate products, meaning those items that are used in other recipes and not placed down as buildings. Secondly, they cannot be placed into beacons. If they could, they’d be overpowered! If you’ve not been using productivity modules, you should strongly consider tossing a few together for your rocket silo or labs and see the difference they make.
Thanks for all the fish T-A-R
As a dedication to Comfy Factorio I would like to share an invitation to another multiplayer event taking place tomorrow, November 7th, 19:00 CET. All are welcome to play, or simply drop by to have a look and share your congratulations.
Countdown has passed
Comfy Factorio is a community with an emphasis on original maps and a “chill” experience. Popular Comfy scenarios are Biter Battles, Mount Fortress, and recently the teleporting Chronotrain. To celebrate their 3,000th Discord member, Comfy has teamed up with Big Community Games, who hosted the community event mentioned in Alt-F4 #7, to host a Massive Multiplayer Fish Defence Game.
Let’s take a look at the map we’ll be playing; unsurprisingly, it’s in the shape of a fish:
In the center of the map is a market full of fish. Alien biters located in the tail of the fish have picked up the smell of this delicious treat, which means the fish need to be relocated to a safer place. The shared goal is to build the rocket silo required to perform this task. Meanwhile, the fish must be protected at all costs from continuous, ever-growing attacks coming from the east.
This map allows some of the participants to just whack biters non-stop while others can focus on building the base. No mods are required. Both of these hosts have shown that they know how to throw a party, so I’ll say “Enjoy, and have a good one!”
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!