Oct 12, 2023

Devlog 011 - Rendering performance optimization

shapez - Jelle

Hey everyone!

We get a lot of questions about performance, so we thought it would be a good idea to take you through our progress of optimizing Shapez 2 to run as smoothly as possible. We asked Lorenzo, one of our developers, to take you through everything. This is a very technical blog, so if you're not experienced with this stuff, feel free to skip this one.

Before you dive in, be sure to wishlist Shapez 2 if you haven't already! It helps us out massively. Thanks!

https://store.steampowered.com/app/2162800/shapez_2/

Lorenzo here!

In our journey to evolve the shape of Shapez from a 2D game to a stunning 3D experience, we've encountered numerous exciting challenges and opportunities. This transformation not only adds depth to the game but also infuses it with more personality, gameplay possibilities, and aesthetic appeal.

However, this transition has not been without its fair share of obstacles. The move to 3D has introduced a multitude of development challenges, spanning game design, artistic direction, and technical implementation. Perhaps one of the most significant technical challenges lies in rendering 3D objects.

In Shapez 1, rendering was relatively straightforward, with one sprite per building. In the 3D realm, each building has thousands of triangles to render, different materials and animations. For large factories, this requires a considerable amount of optimization, both in the simulation of these entities and in the rendering process.

In this devlog we go in-depth in a lot of the rendering optimizations tailored specifically for Shapez 2, as well as what is missing and what are the next steps in keeping a stable frame rate with massive factories.

Introduction

Performance has always been at the forefront of our development philosophy. Right from the beginning, we made deliberate choices to ensure the game's efficiency. In the game context, we can split the performance into three categories: Simulation, Rendering & Interfacing. The simulation changes from Shapez 1, as well, as some insights of how we are pushing the performance for large factories can be found in Devlog 001. The interface, meaning, every interaction that the user communicates with the game and reflects both in the simulation and rendering, is very circumstantial. It can be optimized on a case-by-case basis. The rendering issue, however, is one of the biggest challenges to overcome. We already did a lot, but given the massive scope that we aim for, it might not be quite enough yet.

To kick this devlog off, let's first discuss a bit about how the rendering works (in a very high-level way).

Overview of the rendering workflow (CPU-GPU)

It is important to understand that CPUs and GPUs serve very different purposes. I like to think of the CPU as the solver of all problems: no matter what you throw at it, it can handle it to some degree. Sure, if you jump around instructions and memory, the performance will degrade, but it is not compared to how a GPU would handle it. CPUs pipelines help process many instructions per cycle while branch predictors try to minimize the amount of incorrect jumps and L1, L2 & L3 caches reduce RAM fetching latency. On top of that, processors today come with many cores, but leave the responsibility of using such cores to the developer. More on this later.

The GPU on the other hand is a hardware specialized in processing a single instruction for a very large amount of data. That's why it shines in computer graphics and game development: just think about the number of pixels in your screen, the number of polygons a model has or the amount of rays that need to be traced to render one frame of a path-traced scene. As mentioned in the previous paragraph, it is not so good at switching state (branching). In other words, drawing two different objects once is slower than drawing one object twice.

With that in mind, the processor is the part that will handle all the input, interfacing, and simulation for game development. And after all that, it will dispatch to the GPU what it wants to draw. In order to draw something into the screen, the CPU needs to pass some data to the GPU: a mesh, transformation matrix and a shader (yes, this is very, very oversimplified). Imagine if we want to draw our very hard-working belt. The CPU, after processing the simulation, asks the GPU: “Hey, would you be so nice to draw this belt mesh at this position using this shader right here?” “While you’re at it, draw this shape in this position slightly above the belt” and so on.

Culling

The CPU tells the GPU (nicely or not) what it should draw, and the GPU complies without hesitation. What data is communicated is crucial for performance. Imagine telling the GPU to draw every object in your scene? Even the ones behind the camera? The GPU does not have a lot of context to work with and will process most parts of its rendering pipeline until realizing that the object is not in view. Defining which objects are visible in the current view is called Frustum Culling. Ideally, this should be performed by the CPU.

The way that the data is communicated is also very important, that's why the Khronos Group at some point realized that their OpenGL was too high-level and created Vulkan, a very low-level API for interoperating between CPU/GPU. Unfortunately, Steam character limit won’t allow us to go in depth, but you can read more about it here.

What we have been doing

Alright, now that we are in sync regarding how CPU and GPU need to communicate, let's talk about what already has been implemented in Shapez 2 to maximize the performance.

Game Object avoidance

We steered clear of Unity's Mono Behaviors for core components that demand high performance. Except for the UI, almost all of our systems are written without Unity components. This allows us to employ a better architecture following C# principles and have fine control over all aspects of the game, including the performance.

GPU instancing

In Unity, to draw geometry on the screen, draw calls are issued to the graphics API. A draw call tells the graphics API what to draw and how to draw it. Each draw call contains all the information the graphics API needs to draw on the screen, such as information about textures, shaders, and buffers. Less draw calls are better, as the GPU has less work to do and less switching to perform. One of the most important optimizations in the rendering of Shapez 2 is using the full potential of GPU instancing: grouping objects with the same mesh and shader in a single draw call.

In my assignment to enter tobspr, I was tasked to create a shader that would logically render many materials based on some mesh data. So I did, but In order to fully explore the potential of such a shader, I decided to run some tests comparing the performance of drawing Game Objects vs. batching all rendering in a single instanced draw call. For the test, I used 64×64×3 = 12k low-poly belts and the results were astonishing:

Material combination

Our buildings and space stations are composed by different materials:

Since each building might be composed using multiple materials, this would require multiple draw calls per building. To improve it, we combined all of them in a single shader. This allows us to have only one mesh for each building main part which is drawn with a single material, thus a single draw call. The material split is made inside the shader using the information of the UV0 channel, which encodes the material index per vertex data. Additional moving parts and effects need to be drawn separately.

Mesh combining

Having a shared material for all buildings reduces tremendously the number of draw calls, but it also provides the foundation for a very interesting optimization: mesh combination (also sometimes called mesh baking). At runtime, buildings on the same island are combined into a single batch dynamically. Since the material is unified and the mesh contains all buildings, we can render tons of buildings with the most varied materials in a single draw call.

The example below uses only two combined meshes to draw all of these buildings’ main components:

Level of Detail (LOD)

We take vertex count very seriously, even one extra vertex can become 300,000 extra ones when rendering very large factories. To support very detailed, yet scalable meshes, we created different meshes for each building in different levels of details. The model that is actually presented on the screen is calculated at runtime based on the camera distance.

What's the problem, then?

With all those optimizations, the rendering performance should be excellent, right? Well, it is, but we always want more. Better performance means bigger factories, more compatibility with older hardware and less hardware pressure. The question naturally becomes: what can be optimized next? So far, you might have recognized a pattern in the optimizations above: they are all targeted at optimizing the GPU rendering process. Less draw calls, less vertices, less context switching. Indeed, the hardest part of rendering is always focused on the GPU, and we’re getting very close to the scale we are aiming for. However, all of these techniques put further pressure on the CPU, which already needs to deal with the simulation part. As Tobias always says, each 0.1ms saved from the rendering will be well spent in the simulation, allowing for further complicated factories to run.

During development, we avoided using Unity components as they are generally not very performant. Core components have been written with performance in mind, employing several algorithmic optimizations to ensure everything runs smoothly. However, the code executed by the CPU is still written in C#. This comes with limitations on how performant it can be, as the language offers a trade-off between productivity and runtime performance.

The table below provides some insights about the performance of each language for single thread tests. The algorithm executed is the same, yet the time difference to execute it can be abysmal.

Source

Enter DOTS (or part of it)

Unity is a beginner-friendly engine with a lot of features both to help you get started and for veterans to write very complicated systems. However, although there are many highly optimized systems and a high influx of new optimizations, the underlying structure was not created with performance in mind. During the past decade, the engine race was quite fierce between Unreal and Unity. Numerous debates over which one is the best one, forced Unity hand to take their lack of performance into consideration, thus yielding a completely new paradigm with a powerful tool belt to back it up: the Data Oriented Technology Stack (DOTS).

It was created with the slogan: “Performance by default” and since its impressive debut in Megacity (2019), has received dozens of improvements. DOTS is a combination of technologies and packages that delivers a data-oriented design approach to building games in Unity. Applying data-oriented design to a game’s architecture empowers game creators to scale processing in a highly performant manner. It is composed mainly by three technologies: ECS for Unity, Burst Compiler & C# Job System.

ECS is a data-oriented framework focused on structuring the code in a very different manner than traditional Object-Oriented (OO). Instead of mixing and matching data and implementation. As the name suggests, ECS has three main parts. Here’s an excerpt from Unity’s own documentation:

Entities — the entities, or things, that populate your game or program
Components — the data associated with your entities
Systems — the logic that transforms the component data from its current state to its next state

Inside the DOTS Infrastructure, ECS is powered by the mighty Burst Compiler: that translates IL/.NET byte code to highly optimized native code and the C# job system: which allows Unity developers to take advantage of multicore computing platforms with parallelized code that can run safely and at speed.

DOTS looks amazing on paper: a completely new approach to design your game with a clear division between data and logic that is also very efficient due to the contiguous nature of ECS and the underlying tools that back it up. In practice, however, using ECS on production was not advised until recently, since the package was still in development. It also comes with a heavy price to pay if your code is already written and although it is easier to maintain, the initial code creation can be much more challenging. For the last few years, the API changed dozens of times, many of these rendered previous implementations obsolete. A lot of core systems, such as physics, audio and multiplayer have also stayed in pre-release for the last couple of years. Using ECS for production was risky and not advised.

The good news is that the Burst Compiler and the Job System work independently of ECS, and we get to enjoy their performance benefits without the hassle of rewriting all of our codebase from scratch.

Burst Compiler

Burst operates within constraints and patterns that empower the compiler to perform much of the heavy-lifting. These are:

Limited C# Subset: Burst Compiler operates on a constrained subset of C# and does not support, by design, inefficient patterns.
No Garbage Collection: Manual memory management eliminates the need for garbage collection, reducing time spikes.
No References, Just Plain Data: Data is stored without references, facilitating faster memory access.
Adjacent Memory: Most jobs are written reading/writing to contiguous memory, making it possible to use vectorization (SIMD) and efficient use of CPU caches.
Parallelism with Job System: Enhanced parallel processing capabilities.

When all these factors combine, they can result in remarkable speed improvements of 30x to 300x in CPU processing. This means that for code that is highly independent, math-dependent, and data-focused, we can significantly enhance its performance.

Source

Job System

In the game development realm, many games process everything in a single thread, not using the full potential of the processor. Here’s why:

It can be challenging to split the workload between multiple threads;
Most games are not coded with that in mind and have data dependencies everywhere;
Race conditions, deadlocks and complicated issues might arise
Most games do not have a lot of processing to do (generally the rendering is the performance culprit)

The Job system is Unity’s answer to all of these problems, providing a solution to take advantage of multicore computing platforms with parallelized code that can run safely and at speed.

Restrictions

The Burst Compiler and the Job System almost seem magical given the increase in performance they can provide. They come, however, with a hefty price to pay: it is way harder for your code to comply with them. A lot of constraints restrict how you should structure your code. In short, they do not support managed references. You need to stick with bare bones data-only structures and some pointers to help structure collections. And that's all you got. The benefit is that you can write very efficient code. If you are curious about what is allowed and what is not, here is an overview of what is supported by Burst:

❌ Arrays (T[])

✅ Unity Mathematics

❌ Managed types (classes)

✅ Unity Native Collections

❌ Anonymous functions*

✅ Structs

❌ Delegates

✅ Primitives (int, float, bool)

❌ Strings

✅ Pointers (IntPtr, T*)

❌ Char

✅ Pure static methods (no side effects, no

❌ Static data access

mutable data access)*

*ECS actually supports when defining systems that will execute on archetypes, but it is just syntax sugar, the lambda is converted down to a simple function

As shown, the Burst Compiler only accepts a very small subset of C# that feature-wise looks a lot like C. Furthermore, both Job System and the Burst Compiler do not accept references to managed code. To understand managed vs. unmanaged, it is crucial to first understand how the memory allocation works.

C# memory management

In the C# context, whenever you create a new instance of a class (and in many other circumstances), it allocates the class data in the heap to avoid loss. Once again, C# makes it easy for programmers because it implements a garbage collector.

On the other hand, if you use C# structs, the data is passed around on the stack by default. That means that using a struct, per se, does not allocate memory on the heap. When the function reaches its end, the data is automatically gone. The inconvenient part is that the programmer must guarantee that the data is properly copied between functions since it does not survive scope ending.

Managed vs. Unmanaged

With this in mind, we further refer to data allocated and disposed by C# simply as managed. This includes all instances where data is allocated in the heap. But what is unmanaged data, then? Well, it is not that this memory is not managed, it is just that it is not managed by the compiler. Instead of having the compiler solve it for us, the programmer becomes responsible for allocating and disposing it. Forgetting to dispose unmanaged memory will cause memory leakage. Premature disposal of it might invalid memory accesses and crashes. In Unity, this is done using a handful of DOTS extensions that are very similar to C's malloc and free functions.

It is important to note that unmanaged memory should not reference a managed one, as this can create a lot of issues with the garbage collection – and in general – with the C# memory management. In the Burst context, accessing managed references is not even allowed, forcing the programmer to rely on blittable structs and unmanaged memory.

Garbage collection

The garbage collector is a system component responsible for managing memory by reclaiming and deallocating memory that is no longer in use. It identifies and frees up memory occupied by objects or data structures that are no longer referenced by the program. This process helps prevent memory leaks and simplifies memory management for developers, as they don't need to manually release memory.

Garbage collection can introduce performance overhead compared to scenarios with manual memory management. It adds periodic pauses to a program's execution to identify and reclaim memory, which can result in unpredictable delays. These pauses can be especially problematic for real-time or performance-critical applications, causing jitter and latency issues.

How to render with DOTS?

The limitations on the Burst Compiler and Job System also requires no access to managed API, including most of the Unity systems. Game Objects? Nah. Physics? Think again. Graphics API? Big no. This created a big problem for us. We wanted to use DOTS to speed up the culling process, but without access to the graphics API, there was no way to actually submit the render commands to the GPU. One option was halting the main thread and waiting for the jobs to complete at the end of the frame. That did not yield any performance gains, though, as the overhead was too big for dispatching the jobs, waiting for their completion and submitting the computed data from managed code.

To properly solve it, we had to research how Megacity solved it back in the day. Luckily for us, not only is the API available, but also received a recent update in Unity 2022.2 that improved the usability. The Batch Renderer Group API was designed to be accessed by unmanaged/native code (DOTS compliant). The way it works is that at the end of each frame, the BRG generates draw commands that contain everything Unity needs to efficiently create optimized, instanced draw calls. As the developer, we can fill in that draw call information and specify exactly what we want to draw from within an unmanaged context. Meshes and materials are managed types that need to be worked around. In BRG, we register them during a managed context and assign a unique ID to them. This ID is just a type-safe structure holding an integer, allowing us to reference meshes and materials from within the unmanaged code.

Space Background Decorations

Now, as mentioned, writing code supported by the Job System and the Burst Compiler is harder than writing regular C# code. Both technologies can be considered recent and, although quite mature, we still approached the problem with caution. Instead of refactoring dozens of rendering classes and completely switching to Burst-compiled jobs, we opted for focusing our attention on a very isolated system: the background rendering. The background has no relation with the simulation and, except for the camera data, has no dependency with any other class. That provided us the perfect experimenting backyard where we could test the power of DOTS without the massive amount of work required to implement it everywhere. Bonus: the background rendering was using quite a lot of the CPU, and optimizing it yielded good results in many setups being bottlenecked by the processor.

More specifically, we focused on the background rendering of the chunked decorations, because they are dynamically generated based on where the player is looking. There is a lot of optimization that could be made algorithmically to improve the decorations, but we kept them the same to analyze how impactful using DOTS could be. The decorations are generated based on noise the first time they are discovered and cached for future queries.

The Batch Renderer Group has several interesting features that might fit a lot of games well:

Persistent GPU
Scriptable layout
DOTS instancing shader variant
Compatible with DOTS

Evidently, for us, the compatibility with Jobs & the Burst Compiler was the captivating factor, but the BRG offers something for many projects. For example, the persistent GPU offers a pipeline similar to Unreal Engine, where data is uploaded to the GPU once and updated sparsely. This avoids having tons of data to wire between the CPU and the Graphics card. In Shapez 2, we don’t have static geometry (like most games have), except for the main HUB. We actually upload instance data every frame to the GPU. The new scriptable metadata layout allows customizing exactly which data is passed to each instance. For the decorations, we keep the data to a minimum to reduce the amount of data uploaded to the graphics card.

To understand how the improvement works, here’s a breakdown for a simple scene without many buildings using the previous solution. By inspecting the Profiler data closely, it is possible to check that the main CPU loop (the left side) takes most of its time culling the decorations (Draw Managed Background Particles / Asteroids / Stars). Only after they all finish, the data submitted to the GPU can start being processed.

The main change we implemented is running the decorations culling using burst compiled jobs. These jobs are scheduled as soon as we have the camera data information (the only data the decorations need to be culled). While the main thread is busy processing the inputs, simulation and other rendering, the jobs execute concurrently as can be seen in the image below:

The jobs are much faster than their original managed counterpart, but even if they weren’t, we would see improvements due to the parallelism. When the main thread is done with the other tasks, the decorations are already culled and everything is ready to be dispatched to the GPU. In these example frames, the CPU time reduced from 9.21ms to 2.35ms, halving the total frame time.
There are many optimizations missing for the jobs that would make them run even faster:

Due to the nature of a culling algorithm, vectorizing the code is very challenging, but we believe a part of it could still benefit from the AVX set;
You can see that each decoration is culled sequentially in a single thread. Each decoration could dispatch one job per thread, or the jobs could be scheduled to run at the same time. For higher numbers of cores, both could be combined to achieve even more parallelism.

Mesh combiner

Besides the background, one of our highest bottlenecks comes from combining meshes. As mentioned earlier, combining meshes at runtime reduces a lot of pressure on the GPU, which can draw many buildings with many materials in a single draw call. The mesh combination process, however, needs to be processed by the CPU. In order to reduce the pressure on the processor, a new mesh combination system was written using the Job System and Burst Compiler. The goal was creating a system that could handle combination requests from both managed and unmanaged code, while the combination itself would be performed in a job to reduce the amount of work the main thread has to do.

In-game results

The FPS improvements we have seen in most systems are very exciting, but the individual performance improvements are even more. Before we dive into the numbers, let me quickly explain the difference between the cached and uncached tests: since the decorations are created dynamically based on the seen chunks and the map is infinite, there is no way to bake all the decorations beforehand. Whenever a chunk is seen for the first time, the decoration for that chunk is generated from noise and cached for further lookups. One issue in the previous version was that turning the camera fast and discovering many new chunks at the same time would cause a huge spike in the frame time. It would also generate a lot of memory garbage to be collected. This is not a problem anymore with the new solution, as it can handle the generation much faster.

Disclaimer: these tests are not averaged. They are a representative average frame manually sampled from the profiling pool. Tests are using an i3-9100F & RTX 3060 Ti.

For the average case, the performance is increased by 6x. However, since it is running in parallel, the effective benefit we see is 28x faster culling. This only holds true if the jobs finish before the main thread, which requires the main thread to be busy and the other threads not so much. Further improvements will need to consider balancing what is processed where. The more tasks we move to other threads, the less impactful these changes are.

Now, looking at the uncached case, which is the one that requires more from the CPU, we can see that for generating new chunks both scenarios struggle more than with cached data. While the original one drops the FPS substantially, the Burst version still delivers runtime acceptable performance. Most of the jobs’ time was used in the lazy mesh combination. The combination still requires some improvements on the managed side (some balancing), but some delay is expected (something close to 0.5ms per frame that fetches mesh data). If we schedule one per frame, it’s not an issue, but the meshes might take too long to bake. That's why we need some smart balancing.

These results should give you a rough idea: 30x – 120x improvements in the main thread. 6x – 114x overall. Now, let’s also check the memory improvements and the actual FPS improvements in-game.

From the benchmark, you can see that the average FPS improved. The 1% however, was the most affected metric, highlighting that the new version should handle processing spikes much better.

Now what?

Eventually we will reach the limit of what we can do to optimize the factories, but we are still not there yet. The next steps are more challenging, but we have some optimizations prepared. The first step is moving all the mesh combinations from managed to unmanaged code. This is easier said than done. To fully support it, there is an incoming headache of standardizing the vertex layout formatting or solve it generically, balancing problems to figure out and more optimizations to research regarding using the main thread for computing.

Besides it, we have many checks and benchmarks aligned to make sure everything is compliant with the performance standards we established. After this is done, ideally, we would like to move the whole rendering to burst compiled jobs, but that is a complicated task that involves lots of refactorings, structural changes and many Unity crashes to go.

You can see it for yourself! Starting from Alpha 8, we also created a new benchmarks' menu, which can be used to evaluate the performance running the exact same scenario with multiple configurations.

Please let us know if you also benefited from the changes. Hurry up, they will probably get removed in Alpha 11

So, that's about everything! We hope you enjoyed this deep dive, and we'll see you again in two weeks.

~Tobias, Lorenzo & the shapez 2 team

Join the community:

Twitter / X YouTube TikTok Discord Reddit Patreon

Sep 28, 2023

Devlog 010 - Shapes, Menus & Progression

shapez - Jelle

Hey everyone!

It’s time for another progression blog. These past two weeks were all about visual improvements to the shapes, building and various menus & UI!

As per usual, make sure you wishlist shapez 2 here on Steam to support the development of the game! Following the game will also make sure you stay up to date with the latest news. Thanks!

https://store.steampowered.com/app/2162800/shapez_2/

News

Alpha 9

Since Devlog 008, we have released two new Alphas! Patreon Supporters gained access to Alpha 9 last week, with all-new progression, research UI, new visuals, massive performance improvements and much more! If you’d like to get your hands on the latest Alpha version, consider supporting us on Patreon.

Devlog 010

So, what have we been working on the past month? Let’s talk you through the highlights.

Visual update to shape designs

We made a couple of changes to the general look of all shapes in the game. The sides of shapes are now solid black and the height of every layer has been lowered. This will make shapes with many layers a lot less tall and clunky than before.

Be sure to let us know what you think about these changes!

Progression Rework

We have completely reworked the progression of the entire game. We swapped around the Halves Swapper and the Stacker, as we found that the Halves Swapper was too complicated to be unlocked that early into the game. While we were working on this change, we figured it was a good time to look at the rest of the progression. We got a ton of feedback from the community on the progression system, so we made a lot of changes to the later stages of the game especially. We hope that the newly reworked progression system will feel more natural than the previous one. Patreons can experience the new progression in Alpha 9.

Building design updates

Stackers have been updated to be more of a challenge to use. The old design, with the input on one side and the output on the opposite end, had one very clear, obvious and quite boring optimal setup that everyone would use.

The new design has the output at a 90 degree angle compared to the input, either on the left or the right. This will make Stackers a bit more tricky to use, and allows for multiple different solutions to the problem.

We also made stackers faster to keep optimal designs similarly compact even with the added space for creative problem solving: now instead of needing 5 Stackers per full belt, you will only need 4!

All variants of the Rotator building have updated design concepts to more clearly display their use.

Half Cutters have been renamed to Half Destroyers to more accurately reflect their functionality. Their design has had a big update, featuring a fancy laser beam of destruction.

Additionally, the Full Painter building has been updated with a new design concept.

Skill Academy

We added what we call the ‘Skill Academy’. Essentially, these are tips that appear in the top left corner to guide new players through the early stages of the game. This is not the tutorial, but should help prevent confusion when players are new to shapez or factory building games as a whole. These can be toggled off, if desired.

Speaking of the tutorial, you'll also spot the "First Steps" section. This is, in fact, the tutorial. It will guide you through the early sections of the game while you're playing, by giving you pointers to what things are what exactly is expected from you while playing Shapes 2.

UI updates

A lot of screens got various degrees of updates. The research screen got a reworked concept, and should now more clearly show what you can unlock, when you unlock them, and how you unlock them. The progression system has also received an update, with side goals that are unlocked once reaching a specific main goal.

The research unlock screen got updated to display the new tools you unlocked and how they work. The current visual of the unlocked tool is a placeholder.

The in-game shape viewer has had an update to make the shape code editable, allowing you to view any shape you want. Hours of entertainment guaranteed!

Finally, we gave the building and island toolbars a fresh lick of paint for better readability.

We would love your feedback on all these UI updates, so let us know what you think!

Blueprinting

Blueprints have received a big update in two parts. Now, when selecting one or more space stations, you’ll get an overview of all buildings and connections, as well as the total cost of everything that’s placed on or connected to them. You’ll also get a more in-depth overview that breaks down the amounts for each type of building.

The second big update lets you copy, cut, rotate and paste your selection of space stations. This means you’ll be able to grow the factory faster than ever and increase your throughput with just a few clicks, as long as you have the resources!

You can accumulate more blueprint resources by delivering shapes of completed research.

Performance Improvements

We made big strides when it comes to performance! Below, you can watch a showcase of what it's like playing on a Macbook M1 Pro at 4K. This save features 540.000 buildings.

Of course, the FPS isn't the greatest, but these machines aren't really made for games. You would already hit 60 FPS on modern machines. Shapez 1 would already run at 1 FPS under these circumstances.

We still have a lot more performance improvements planned, so the game will run even better when we enter Early Access. Rest assured that we work very hard to make this game playable on as many machines as possible!

Various other changes

The procedural map generation has been improved. You should now come across more interesting shapes to work with. The nodes remain placeholders for now.

The Overview Mode view for these resource nodes has also had a visual update!

Tunnels can now be set to automatically place tunnels connection your space station.

We added a new concept design for the 1x1 Shape Miner platform. Just look at this little guy go!

We continue our work on trains and will soon be ready to do a deep dive into how exactly they will work and what you can do with them.

Additional mouse and keyboard settings have been added to the settings menu, allowing you to set your horizontal and vertical mouse sensitivity, as well as the keyboard camera movement speed. It goes up quite a lot, in case time is of the essence.

That’s everything for this blog. Let us know if you like what you’re seeing! The next blog will go more in-depth again, so on the lookout for that one dropping in two weeks.

Again, please consider wishlisting the game if you haven’t yet!

https://store.steampowered.com/app/2162800/shapez_2/

We hope you enjoyed devlog 010, and we’ll see you again soon!

~Tobias & the shapez 2 team

Join the community:

Twitter / X YouTube TikTok Discord Reddit Patreon

Aug 31, 2023

Devlog 008 - 2 months of progression

shapez - Jelle

Hey everyone!

It’s been a little while since the last devlog. We’ve been very busy with the Gameplay Reveal trailer from two weeks ago, which was then followed up by Gamescom.

However, we’re back now! So let’s discuss what we’ve been working on since devlog 007.

News

As previously mentioned, we finally released the Gameplay Reveal Trailer for shapez 2! Thank you to everyone who joined us for the premiere and supported the trailer.

In case you missed it, you can find the trailer here:

If that got you as excited as we are, be sure to wishlist the game and follow shapez 2 to stay up to date with the news!

https://store.steampowered.com/app/2162800/shapez_2/

Reinforcements

The astute among you may have noticed a second logo at the end of the trailer. We are working with Gamera Games – who you may know from Dyson Sphere Program – to publish the game in Greater China & Japan. They will also handle the Simplified Chinese translations for our announcements and devlogs!

Additionally, we have enlisted the help of Game Drive, a games marketing agency. As we’re moving ever closer to the Early Access release next year, marketing becomes more and more important for the growth of the game, so we need some extra manpower!

Alpha 7 Build

Alpha 7.4 of shapez 2 is currently available on our Patreon and has been for a bit. A lot of the changes you’ll read about below have already been implemented in this build. If you’re interested in giving this new build a go, be sure to subscribe to our Patreon to get access, alongside a host of other great benefits!

Devlog 008

So with all that out of the way, let’s dive into the new devlog.

Rendering & graphical performance

After watching the trailer, a lot of you had questions about the performance of the game. Once you really got going in shapez 1 and made a huge factory, or made a make-everything-machine or two, the simulation could start to lag quite badly. So understandably, when people saw the graphical uplift of shapez 2, people assumed this would make things worse. Well, fret not!

Unlike Shapez 1, Shapez 2 is made in Unity with C#. This gives us a lot more tools to optimise the simulation and prevent unnecessary use of your system’s resources. One of the changes is that the game now supports multi-threaded processing, so the simulation and the game won’t run on just one of your CPU’s cores. The biggest change however, is how we handle off-screen simulation. Instead of just fully simulating everything in your factory at all times, we’re limiting the simulation of the portion of your factory that isn’t currently on your screen to just 2 times a second – down from the full 60 times a second – while still running at full precision. You won’t notice a mechanical or visual difference at all. However, it’ll make sure the simulation runs smoothly regardless of the size of your factory.

We stress tested this system on a mega factory of 360.000+ buildings and it works great. In fact, you saw this very factory in the trailer! Our goal here is to allow for about 1 million buildings on a modern PC build for the release of the game.

Do keep in mind that the massively improved graphics will mean you most likely won’t be able to sneakily play Shapez 2 on the school computer as you could (and we know you did) with shapez.io. You will require a bit more computing power to run this at a smooth frame rate; without any tweaking of the settings, that is!

To counteract the increased resource demand of the game somewhat, there will be a host of graphical options to tinker with, alongside a ‘minimal mode’. This mode will reduce the visuals to an absolute minimum and allows Shapez 2 to be played on laptops. This mode has been tested on a Microsoft Surface Pro and runs fine!

Exact minimum and recommended system requirements are to be determined and published closer to the release of the game. If you want to give it a try right now though, be sure to download the free alpha version through our Discord server! As the game still has a lot of optimisation to go in its current state, it’s safe to say that if your PC runs Alpha well, it will be able to run it in the future.

Trains progress

We know you’re excited for space trains, and we’re working hard to make them a reality. You’ve seen them in action in the trailer, so you’ll have a good idea of the vision we have for them. Do keep in mind that the trains are still subject to change.

However, a lot of work still needs to be done to make trains fully operational, but we’re on track to have the trains depart for Early Access next year. We hope to do a devlog dedicated to trains in the future, once they’re finalised.

Barreling

In devlog 006, we introduced you to the world of fluids. One of the topics we addressed here was fluid packing and cross-island transport. As there’s no way of moving fluids directly between islands, you’d need to produce barrels to keep the fluid in, fill the barrels, then move it by your preferred mode of transportation. Once at your destination, you’d empty the barrels and pump the fluid back into your pipe system.

We feel like the process of producing barrels didn’t quite fit. Having to deliver shapes somewhere to produce the barrels made fluids a hassle to use. It didn’t add anything interesting to the mechanics, just more tedium.

Instead, the Fluid Packer building will take the fluid and ‘freezes’ it into blocks that can be transported however you wish.

Auto pinning side goals

As the side goals are very important for your progression through the game, we want to make them a bit more prominent. Now, side goals are automatically pinned if you produce the shape they require.

We will continue working on the early game and research experience and are planning to add a full tutorial.

Visualisation layers in overview mode

We added brand new visualisation layers to the overview mode. You watch a neat little demonstration here:

The layers now include:

Islands grid
Shape Patches
Fluid Resources
Shapes
Explored Areas & islands
Tunnels
Train Items
Train Lines
Train Stations

You can enable multiple layers at once, or even all at once if you hate being able to see what you’re doing.

Island selection toolbar

We added a new Island Selection toolbar, allowing for quick and easy access to the different types of islands you can place. You’ll also be able to select multiple islands and delete them all at once. It’s easy to accidentally delete a lot this way, but don’t worry, you can undo everything if you mess up.

Packer Building

We’ve been working with the Packer and Unpacker buildings. The Packer building allows you to stack many shapes of the same type and color and pack them into one item. The Unpacker, as you may expect, does the opposite.

The main purpose for these packs is to transport the shapes via train. Pack the shapes, insert the packs into a train, remove the packs from the train, then unpack everything again. It’s also great for massively increasing the throughput on a belt, as long as you have enough Packers. Details on how this building will work together with trains, will come in the devlog dedicated to trains.

Graphical Improvements

A lot of time has been spent on improving the graphics of the game across the board. Improvements have been made to the materials of the Space Station, all buildings, the playing field as well as global lighting effects. We hope you liked what you saw in the trailer!

One of the main improvements we’ve been working on is LOD (Level of Detail). For those who don’t know, a common technique to increase performance is to lower the LOD of models that are far away from the camera. This technique is especially important to make the game run smoothly when zoomed out, like in Overview mode.

We don’t want the decrease in LOD to look jarring when you zoom out though, so we’re trying our best to make this look smooth and as unnoticeable as possible. This is done by having multiple stages of LOD, so the transition from one LOD to the next isn’t as big. We’re also fading out the shadows now, instead of simply removing them.

Now, we’re finally caught up! Again, apologies for the lack of devlogs lately. Now that the trailer is out and we have some reinforcements, we hope to bring you new devlogs every other week.

If you’d like to support the game, please wishlist the game here on Steam and follow the Shapez 2 page if you’re not already. It really does help us out a lot.

https://store.steampowered.com/app/2162800/shapez_2/

We hope you enjoyed this devlog and can’t wait to show what else we’re working on!

~Tobias & the shapez 2 team

Join the community:

Twitter / X YouTube TikTok Discord Reddit Patreon

May 21, 2023

Devlog 006 - Fluids

shapez - tobspr Games

Hey everyone!

Today I wanted to give you some insights about the fluids in Shapez 2!

As always, be sure to wishlist & follow Shapez 2 to get a notification on important updates:

https://store.steampowered.com/app/2162800/shapez_2/

Alright, so let's dive into the devlog!

Devlog 006 - Fluids & Painting

Recap - Shapez 1

Shapez 1 didn't have fluids, and colors were simply items that you could mine, just like shapes. The painter would then take those items as an input and modify the shape color:

This worked, but for Shapez 2 we wanted something more interesting and also more "visual" and easy to understand. This is why we are introducing fluids:

Fluid Extraction

The first step to acquire fluids is to find a fluid resource on the infinite map. In the area close to the HUB you will be able to find the 3 primary colors: red, green and blue. Farther apart, we can imagine that there will also be secondary colors, but that's not settled on yet.

We still haven't figured how those fluid resources should look, so they are still placeholders in the game.
Daniel already made some concepts for them, but all of these are super early!

Once you found a resource to mine, you can place a fluid extractor island on it. Again, this is only a placeholder:

There is already a concept for it as well, but again, very early!

On the miner itself, there will be a fluid patch, similar to the shape miner, where you can place pumps to extract fluids. Pumps currently extract 1200 Liters per minute, but this is not final. Currently the unit used to measure fluid volume is liters, although we could imagine introducing additional units in case we ever want to add steam for example.

Fluid Transport & Simulation

To transport fluids on the island, you can then place different types of pipes. There are straight, corner, junction and cross pipes. As everything in the game is open, we wanted the pipes to also be open so you can see the fluids actually flow through your factory!

Fluids are simulated at a fixed tickrate right now. Basically every pipe has a "storage" called "FluidContainer" internally. The size of that storage is 50 L for pipes currently.
Every container then stores the current flow to the adjacent containers.
When updating the simulation, it basically goes like this:

1. Iterate over all containers and "spread" fluids.
Every container can only store one fluid at a time, so once it is "tagged" with that fluid, it can only store that fluid until it is entirely empty again. More about that in the "Mixed Pipes" section.

2. Compute & propagate pressure differences
Pressure in a container is simply computed as value / maxValue. The simulation then tries to achieve a state of "balance" where all containers the system have the same pressure.
However, just trying to average the container levels won't work great, because then the throughput will be extremely low at some point.
Thus, instead of storing only the pressure, we also store a flow rate, which is determining how much fluid from one container flows to another container in one tick. The flow rate only changes very slowly, and increases / decreases based on the pressure difference.
There are still some issues that a lot of fluids simulations typically have, for example dealing with waves. But we already have a few ideas how to tackle them!

3. Clamping & clearing
In the last step, all containers that are empty are now un-tagged, so they can receive a different type of fluid again. Also in case any container did over- or underflow, it will be clamped.

While the fluid simulation can be a little technical, our goals is and was that if you just want to use fluids, it should be intuitive and "just work". With the current system in place and the visual indicators, we feel that already is the case, but we are very interested in your feedback!

Mixed Pipes

Since mixed fluids in the same pipe wouldn't really make sense, we don't allow them. Instead, every fluid container can only store one fluid and is tagged with that. Transfer between containers then only works if they have the same fluid:

There are also buttons to flush pipes or the entire network, in case you mess up.

Secondary & Tertiary colors

In order to produce secondary and/or tertiary colors, you can mix colors with the color mixer:

Cross-Layer Transport

Fluids can be transported up and down, however, in order to transport them up you will have to place a pump:

The pump will limit the flow to one direction, so you can also use it as a gate to prevent backflow:

We are also considering to add a building just for that, in case it becomes a commonly used pattern.

Instead of going for an overly complex system, the rules for cross-layer transport are very simple: Fluids only go up in a pump, and they go down in regular pipes. This should be very intuitive and still allow for some interesting designs. However since it's not final - let us know what you think!

Buffering

In case you want to store some fluids, there is also a fluid tank, and because of the cross-layer pipes, you can also stack them on top of each other:

Keep in mind that, because the simulation effectively averages the pressure, the tanks will only fill once you have a surplus of fluid in the system.

Painting

There will be different types of painters in the game, for now we have planned a topmost painter and a full painter. The topmost painter only paints the highest layer of a shape where as the full painter paints the whole shape (and needs more paint in exchange).

Here's an early concept of the topmost painter in action (the animation is currently broken):

As you might have seen, there are multiple inputs - and again, due to the multi-dimensionality of the game, you can build some pretty cool & compact setups!

Fluid Packing & Cross-island transport

If you read the past devlogs, you might wonder how you actually transport fluids between islands, since there is no building space for pipes in between.

Disclaimer: The following mechanics are work in progress and we don't know whether they will end up exactly like this in the game. However, let me explain what we have right now!

To transport fluids, first you have to produce barrels. Barrels are produced from shapes, and the size & color of the barrel depends on the used shape:

Once you produced the barrels, you can now fill them using the fluid packer:

Then transport them between islands and unpack them again.

Since barrel production is pretty slow, you can also recycle the production by returning the empty barrels again (as seen in the above gif)

We are not 100% certain this feature will be a great fit, so be sure to leave your feedback on it, so we know whether you like it or not!

Color Blind Support

As soon as colors are a crucial part of the gameplay, we have to think about color-blind support as well.
We are still looking for good ways to make it easier in case you are affected, such as patterns, or different symbols for fluids. If you have any ideas please let us know!

Wishlist Shapez 2

I hope you enjoyed the devlog, and I wish you a nice remaining weekend!

And as always, be sure to wishlist & follow Shapez 2 to get a notification on important updates:

https://store.steampowered.com/app/2162800/shapez_2/

~Tobias

May 7, 2023

Devlog 005 - Research & Progression, Blueprints

shapez - tobspr Games

Hey everyone!

First of all, I want to apologize for the late devlog. A lot of stuff is happening right now, and it's hard to find time in between!

News

We are slowly growing the team - last week we welcomed Lorenzo who will help with the Development, so there are now 5 people working full time on shapez 2!

New Soundtrack

Shapez 2 will ship with 40 minutes of soundtrack from Petter Sumelius, the composer who also made the amazing shapez 1 soundtrack!

Additionally, there will be a supporter edition that will add additional 40 minutes of soundtrack to the game, composed by Petter as well!

Wishlist shapez 2

Be sure to wishlist & follow shapez 2, so you get a notification on any significant updates!

https://store.steampowered.com/app/2162800/shapez_2/

And if you want to try out the current alpha, be sure to join the shapez 2 discord!

Devlog - Research, Progression & Blueprints

Please note: A lot of content shown here is subject to change. While we are already satisfied with the new research system, we can not guarantee it will end up exactly like this in the final game.

Recap - shapez 1

In shapez 1 you had a linear level system, where you had to deliver one certain shape to complete the level and unlock the next technology.
Additionally there were 4 different upgrades where you could increase the speed of buildings.

While efficient, this system leads to some issues. First of all, having a purely linear structure means that even if the next level contains a building / technology you don't need or want, you still have to unlock it to progress.

Additionally, it means that the replayability is not really good, because every playthrough looks exactly the same, without a lot of meaningful choices.

Which is why for shapez 2, wanted to rework the system.

What we tried - and didn't work

Our first approach making a big research tree. There was a "main" goal section in the middle, but otherwise it was just all research nodes in one single tree:

(The image is quite large, you can click to enlarge it)

However, during playtesting, it showed that this was way too confusing. It was almost impossible to figure out which upgrades to go for next, which ones were more important or even required, and which not.

Thus, we decided that we needed to go for a hybrid approach instead.

New approach - Categorizing upgrades

To make the upgrades easier to understand, we started separating them into 3 different categories:

Milestones

Milestones are upgrades that unlock new technologies which allow you to produce new types of shapes. These upgrades are required for the progression within the game and can not be skipped, for example painting shapes. Milestones are supposed to be large goals you work towards for a while, while also pursuing other goals in the meantime since they can take a while to complete.

Basically we went over all upgrades and asked the question "Will the game experience be bad if the player doesn't unlock this?". For the current alpha, we already ended with 14 milestones, although we plan to add a lot more content, even for the early access release.

QoL Upgrades

Quality-of-life upgrades are upgrades like the storage, counter-clockwise rotator, decorations, labels and so on. These are upgrades that you can go for if desired, and they can make a lot of sense for your factory, but they are not required to progress in the game. Thus, you have a lot more choice if and when during your playthrough you want to unlock them.

"Flat" Upgrades

Flat upgrades are upgrades like Belt Speed, Platform Limit, HUB Size which just have different tiers (i.e. Belt Speed 1, Belt Speed 2, ...). Those upgrades are supposed to be infinite, but we haven't figured this out exactly yet.

Organizing the upgrades

To connect the upgrades together in the research UI, we started with a linear progression at the top.
We put the milestones in a linear order, which is very similar to the levels system in shapez 1.

Then we started categorizing the QoL and Flat upgrades into different categories like Transport, Processing, Fluids and so on. Each category got their own little tech-tree, in which you can unlock the QoL upgrades, as well as an area at the bottom for the flat upgrades to better separate them:

The QoL and Flat upgrades can depend on previous upgrades, as well as milestones. For example, if a QoL upgrade requires red circles, it will most likely depend on the "Painting" milestone. This is also shown so you have an idea which shapes you can already produce, and which ones need new technologies first.

You can also pin all upgrades to your screen to track them:

With this change, you now have a lot more control when to unlock optional upgrades, while still having a guideline through the game progression! While we really like the new system, we'd love to hear your feedback and thoughts on it though!

Random Goals - Replayability

While the new system makes the replayability a little better, it's still not great. Thus, we are planning to add a "seed" to the research tree.

All shapes you have to produce are then randomly generated, instead of predefined. There is a standard seed (0) which is the default research tree, but you can enter another seed to get an entirely different set of shapes.

This means that whenever you want to start a new playthrough of shapez 2, you don't end up having to produce the same shape again and again, but instead every time it's a new one!

Additionally, this also allows us to have a much better difficulty setting than just increasing the amount of required shapes for every goal:

Basically, we will develop an algorithm that allows to create a shape requirement, given a set of currently available technologies and desired difficulty. The more difficult, the more steps (like cut, rotate, ...) and resources need to be chained to produce the shape.

If you then play on "easy" difficulty, you will get shapes that require far less steps than on "insane".
Of course, in the beginning of the game both modes will still require simple shapes (since you can't produce more complex ones) but especially in the end of the game it will be a huge difference!

We hope that this makes the game a lot more replayable and I'd love to hear your thoughts on it!

Blueprints

A big, if not the biggest complaint in shapez 1 was that blueprints unlocked a little late.
Basically the issue with blueprints is, the earlier they are unlocked, the simpler the blueprint shape needs to be (because you can't produce more complex ones at that point).

For shapez 2, we wanted to change this, so we came up with the idea of blueprint points:

You unlock blueprints very early, and in order to gain the blueprint points (BP), you need to deliver a certain shape which is then converted into points:

Once you unlock new milestones, you also unlock new shapes you can deliver to more efficiently generate the blueprint points:

Basically if you deliver the left shape, you get 1 blueprint point, whereas you get 100 if you deliver the right shape.

Copying structures or islands then cost blueprint points, and exponentially more the larger the blueprint or island is:

This allows us to make blueprints available a lot earlier, but still having interesting blueprint shapes later in the game!

Let us know what you think about this as well!

PS: There will also be a blueprint library - you can already share and load blueprint strings in the current alpha, but we want to make it easy to also create collections of blueprints, store them, share them and so on! But more on that in another devlog!

Wishlist & Follow Shapez 2

https://store.steampowered.com/app/2162800/shapez_2/

Have a nice remaining weekend, and I hope you enjoyed reading the devlog!

~Tobias

Apr 29, 2023

Devlog 004 - Map & Space Platforms

shapez - tobspr Games

Hey guys!

In this devlog I wanted to share some insights how the map in shapez 2 works, which is mainly based around the concept of building space stations platforms.

https://store.steampowered.com/app/2162800/shapez_2/

Here's a quick screenshot of how the islands look like, although it is already outdated:

However, to understand why the concept ended up the way it is, we need to look at how shapez 2 evolved:

IMPORTANT NOTICE: This devlog includes a lot of old screenshots, alpha footage and placeholders. The final game will look very different!

How it started

Back in July 2022 when I started prototyping shapez 2, this is how it looked:

As you might notice immediately - I actually started with a hexagonal grid. This originated from a survey on the shapez 1 discord, and was basically my starting idea to distinguish shapez 2 from shapez 1:

It quickly evolved, and starting from the beginning I already wanted all machines to be open:

However, once I actually started to implement basic belt placement, I ran into the first issues already.

Placing straight belts on a hexagonal grid is possible, but only in 3 directions. This leads to weird looking sharp-turn belts. Disabling sharp turns didn't make it any better though, since then connecting machines got really annoying, and you still can't have straight belts in all directions:

Additionally, symmetry and tilable designs are possible, but work very differently in a hexagonal grid:

Which is, after long consideration, I decided to drop the hexagonal grid, in favour of allowing to build multidimensional factories (which we will cover in another devlog!).

Infinite map?

I definitely wanted to have an infinite, procedurally generated map for shapez 2. However, to make it look more interesting than in shapez 1, initially I wanted to introduce a concept of "Biomes". Biomes could be areas that contain exclusively red color patches for example. This would also incentivize the new mass transport features.

Here is a first overview how it looked with those different biomes:

The result was not pleasing, but because I wanted to keep shapez 2 abstract, I couldn't just introduce styles like "Forest " or "Water" which would have made it more interesting.

Thus we came up with the "Islands" concept (they are still called like this internally), which evolved around the idea of, while still having infinite space, having to build the playable area yourself:

The idea was that you could craft islands by using shapes:

Basically better islands would cost more and/or better shapes, and they could also have shape and color resources.

After a few iterations, we simplified the crafting dialog:

However, while playtesting, we found that the crafting mechanic wasn't really interesting. The main issue was that the organic factor was entirely missing, thus every playthrough would be the same. And I didn't want to introduce randomness into the crafting, since that would not fit the concept of shapez.

To fix this, we decided the resources should instead spawn procedurally on the map again, and to mine them there will be special miner "islands":

Here is an early screenshot of the map, although the resource distribution is temporary and will change!

I hope you can already see at which scale you'll be able to build within shapez 2!

Modular Designs

Another feature of the islands was allowing to build modular - the idea was that in the lategame, you no longer have to build individual islands but instead you have an island that contains only cutters or stackers and you can rearrange them - building on a much, much larger scale. The idea was basically that these modules are like a building from shapez 1, but instead it was built and designed by yourself!

(If you want to find out more about building modular, Giantwaffle showed it during his exclusive stream of the alpha)

This is a first draft how I wanted it to work:

Art Style Change

During the transition, we also introduced an art style change, which is a topic for another devlog!
However, because we changed to an "Abstract Space" style, the islands now became space station platforms:

Island Layouts

I wanted to have different layouts of islands which allow for interesting combinations, while not being too simple. Inspired by the idea of "Pentominos", every island consists out of chunks which are up to 16x16 tiles large.

(Image source)

The layouts for the islands are not determined yet, but we will try to make sure that every layout has a use and it doesn't get too much of a puzzle (i.e. there should be some puzzle aspect - but it could also get very frustrating if the layouts don't fit together nicely).

Inter-Island Transport

Additionally to the mass transport (trains - covered in another devlog) we of course also need local transport between islands.

To make the islands actually meaningful, it was clear that we can not just allow transport on all sides of the island. Otherwise, there would be no actual difference to an infinite map.

Thus, we came up with the idea of "notches", only allowing to transport shapes at certain locations of an island:

The concept is very simple: There is a building (we call it "belt port" internally) that allows you to catapult shapes over a certain range. Because the distance between two islands is higher than the maximum range of the belt port, transport is not possible. But because the "notch" has 4 tiles that are closer to the other island, these are the places where you can exchange shapes between islands.

A notch allows for 4 of these buildings per layer - so once having unlocked 3 layers, that means effective 12 belts throughput (throughput of the belt ports is identical to the belts):

Notches are displaced, so that if both islands have a notch at this location, you actually get twice the throughput:

As you can see, they are also bi-directional (which is actually something we are considering to change - let us know what you think!)

Island costs

We spent a long time thinking about the costs of the islands. Since we removed the crafting mechanic, at this point the islands were entirely free to place.

The first idea was to make them still cost a certain shape. However, then we figured it makes a lot more sense to instead keep them free, because it would fit the concept of shapez best - buildings are free as well, after all.

This incentivices playing around with the islands, rearranging them, deleting them without having any penalty attached to it.

To still reward building optimized factories, we then introduced a "limit" to the maximum chunks you can place, which can be increased via research. Every island consists of multiple chunks (as shown above), so larger islands are more "expensive". But because it is just a limit and not a cost, you can just play around find out what works best for you!

As you can see, the cost if the island (4 chunks) is shown when placing it, as well as the current usage and the limit.

Of course, the limit can be increased via research, and we actually want to make it an infinite research so your factory can grow forever!

Further topics

Writing this devlog has actually been incredibly difficult, because there are so many more topics I could dive into, but even writing this together already took quite a while! (Which is why I had to delay it by one day).

However, I wanted to already give you an insight on what topics you can expect from further devlogs:

- Fluids & Fluid packaging
- Multidimensional factories
- Crystals
- Trains
- Research Tree
- New blueprint system & currency
- Art style change
- ... and so much more!

If this was an interesting read to you, please let me know in the comments so I know the devlogs are appreciated!

And if you want to stay informed about the upcoming devlogs, giveaways and more, please follow the Shapez 2 store page:

Follow to get updates

PS: In order to get updates, be sure to wishlist AND follow Shapez 2, since just wishlisting doesn't give you any notifications on new events & updates!

https://store.steampowered.com/app/2162800/shapez_2/

Have a nice remaining weekend!

Tobias