Wube is such a unique game studio. They do a lot of very solid technical work and look like they have fun doing it. I particularly appreciated their recent post about porting Factorio to ARM64. They had a business reason to do it but it's clear the team was mostly just curious about whether ARM64 was a viable gaming platform now. And then shared the results with us. They seem like fun hacker guys.
It helps they don’t have a publisher to confuse them with quantitative and qualitative pattern matching. Just make the game you play and judge it honestly. Of course, the second part is a rare ability.
Based on the title I thought this would be about adapting Factorio for touch controls, but this is way more interesting. The folks at Wube have such a unique sense of technical curiosity.
As far as the game in concerned, the sprites are all just 2D assets. The fact that those assets came from a 3d model during development has no effect on performance. They also do manual post-processing on most of the 2D renders.
Your wording can easily be read as them shipping 3d models and rendering them as 2d at runtime. It's a weird way to say the game is made up of 2d assets.
The game doesn't consume that much VRAM. It plays on 4 GB GPUs just fine. The GPU only needs to keep resident what's currently on the screen. Even including every animation frame, that's 1 GB tops.
Hell, the minimum requirements are a GeForce 750 Ti, or Radeon r7 360. Those are 2 GB GPUs.
I don't have it installed now (lest I get tempted into a quick 2-hour session and end up being late for work 12 hours later), but IIRC it performed the same for me on iGPU and 4090, even on the big saves running below 60 FPS/UPS.
There are assumptions being made about texture resolution.
The high quality sprites are 64 pixels across per tile. With each tile being 1 meter, 1 pixel is 1.56 cm (About 0.63 inches) across. By today's standards, that's a very low texture resolution, though they can get away with it when your camera is so far away.
But if the game was 3D, you could expect players to put the camera closer to your objects. You'd need significantly higher texture resolutions. And you'd need a texture for each part of the object.
Meanwhile, consider a 3x3 object. That's 192x192 = 36,864 pixels. Assume it has a 60 fps, 2-second animation loop. That's 4,423,680 pixels. With 8 bytes per channel and 4 channels (RGBA), that's about 17.7 MB, which allows you to store 56 objects per GB.
Which doesn't sound like a lot, but we're making some huge assumptions. Not all objects are 3x3 tiles. Most don't have 120 frames of animation.
And as I mentioned in another comment, you don't need to store ALL the game's art in VRAM at once. Only what's on the screen. And you can certainly fit an entire screen's worth of animations in a 2 GB GPU.
> Meanwhile, consider a 3x3 object. That's 192x192 = 36,864 pixels. Assume it has a 60 fps, 2-second animation loop. That's 4,423,680 pixels. With 8 bytes per channel and 4 channels (RGBA), that's about 17.7 MB, which allows you to store 56 objects per GB.
I am assuming that they are laveraging multiple compression technics like using texture specific compression on the gpu, or sub sampling the resolution directly.
8 bytes per channel seems rather large here as well.
Hmmm... The Factorio team is famously performance oriented, and more scenes are often far less so. Are you sure the problem wasn't the mods? I have good memories of sending my Kerbal frame rates to hell with generous modding, both for graphics and the physics engine.
I also struggled with performance in space age and mentioned it to a developer, but the solution was setting a setting which I had tested previously (no fog) and did nothing... on Nauvis. Turns out it's the difference between stuttering and smooth when in space platform view. They do still care but I guess there's only so much you can do if you also have other tasks to get to
I'm (hopefully) getting a G1X soon, so I think I'm going to put it to work printing this stuff out. I'm now excited for this as a use case and I kind of hope someone builds something to convert an existing factorio world into a 3d model, though it might be to big to actually print so maybe a way to take a section would be even better.
Real-world Factorio, aka composable manufacturing, aka "factories building drones building factories", aka universal constructor, is the next trillion dollar company.
This project looks simple until you realize how much engineering went into it.
The original assets were never meant to be physical, so they had to completely re-engineer isometric tricks and floating geometry for 3D printing. Releasing the files instead of an expensive collector's edition is a classic Factorio move, and I personally love it. Now the community can remix these and build some awesome stuff that the original devs could never imagine. Awesome stuff!
Fun thing about taking Factorio physical is that the game already has a real scale. A tile is a metre, that's what the km/h readouts for vehicles are based on. So a yellow belt moves at basically walking pace, and the engineer runs everywhere at about 30 km/h all day without getting tired. The mining drill that eats a whole ore patch is a 3x3m box.
https://www.factorio.com/blog/post/fff-446
I'm looking forward to making a Factorio themed war game table. Star Wars Legion on the factory planet...
https://factorio.com/blog/post/fff-146
[1]https://www.prodeusgame.com/website/index.php
The game doesn't consume that much VRAM. It plays on 4 GB GPUs just fine. The GPU only needs to keep resident what's currently on the screen. Even including every animation frame, that's 1 GB tops.
Hell, the minimum requirements are a GeForce 750 Ti, or Radeon r7 360. Those are 2 GB GPUs.
Not everyone bought a GPU to run LLMs on. That is quite a bit of VRAM, especially for non-desktops
I don't have it installed now (lest I get tempted into a quick 2-hour session and end up being late for work 12 hours later), but IIRC it performed the same for me on iGPU and 4090, even on the big saves running below 60 FPS/UPS.
The high quality sprites are 64 pixels across per tile. With each tile being 1 meter, 1 pixel is 1.56 cm (About 0.63 inches) across. By today's standards, that's a very low texture resolution, though they can get away with it when your camera is so far away.
But if the game was 3D, you could expect players to put the camera closer to your objects. You'd need significantly higher texture resolutions. And you'd need a texture for each part of the object.
Meanwhile, consider a 3x3 object. That's 192x192 = 36,864 pixels. Assume it has a 60 fps, 2-second animation loop. That's 4,423,680 pixels. With 8 bytes per channel and 4 channels (RGBA), that's about 17.7 MB, which allows you to store 56 objects per GB.
Which doesn't sound like a lot, but we're making some huge assumptions. Not all objects are 3x3 tiles. Most don't have 120 frames of animation.
And as I mentioned in another comment, you don't need to store ALL the game's art in VRAM at once. Only what's on the screen. And you can certainly fit an entire screen's worth of animations in a 2 GB GPU.
I am assuming that they are laveraging multiple compression technics like using texture specific compression on the gpu, or sub sampling the resolution directly. 8 bytes per channel seems rather large here as well.
https://wiki.factorio.com/Blueprint_string_format
(Also unrelated, I think by clearance they mean tolerance?)
i typically interpret it as having a hint of embarrassment to it (e.g. "not me eating instant ramen for dinner for the 3rd time"), but not always.
I was hoping for an iteration of a factorio belt that could actually move!
The original assets were never meant to be physical, so they had to completely re-engineer isometric tricks and floating geometry for 3D printing. Releasing the files instead of an expensive collector's edition is a classic Factorio move, and I personally love it. Now the community can remix these and build some awesome stuff that the original devs could never imagine. Awesome stuff!