Hello everyone!
One of the biggest differences between Shapez 1 and Shapez 2 is, of course, the visual upgrade. The transition from 2D to 3D is an enormous task, and we spare no effort to guarantee we will ace this step forward. For this devlog, we asked Nils, our 3D artist at tobspr Games to take you through the process of how we settled on the design philosophy of Shapez 2 and what we have to keep in mind whenever we design something.
Before we get started, please make sure you have Shapez 2 wishlisted! We have some exciting times ahead of us, and it would be a shame if you were to miss out on future updates! :)
https://store.steampowered.com/app/2162800/shapez_2/
[h2]News[/h2]
[h3]Alpha 12[/h3]
Last week saw the release of Alpha 12, a huge update that focuses on improving the onboarding experience of Shapez 2. We are currently working on polishing this experience to a near-final state, barring any feedback we may receive from you. Want to try it out for yourself?
Consider joining our Patreon!
[hr][/hr]
[h3]Nils here![/h3]
Even though Shapez 1 was a pretty complex game, it wasn’t what we would call a looker. The graphics were simple and readable, but not exactly aesthetically pleasing. It’s programmer art, as our lead artist would say! This is fine for those who value function over vanity, but it makes it difficult to attract new players who aren’t experienced factory builders already. If you take a look at a game like Satisfactory, a game that’s both complex and beautiful, it appeals to all kinds of players. It has the visuals to be interesting to players who are new to the genre and the gameplay to teach them the ropes, while also being complex enough to keep veterans engaged.
This is something we feel Shapez 1 lacked. While the low-stakes gameplay was very friendly to new players, the visuals made it more of a game for people interested in IT and programming. So, for Shapez 2, Tobias envisioned a sequel that takes all the gameplay strengths of its predecessor, but takes the jump to 3D and makes it look good while keeping the game accessible.
One other change we deemed important is the complete removal of ‘black box’ buildings. If you look at the buildings in Satisfactory, Factorio or Dyson Sphere Program, the resources you feed into a machine disappear into nothingness. A couple seconds later, a product pops out, and you have no clue which steps happened in between. We think the segmented nature of the shapes allows for a non-black box approach where you can see exactly what a machine does by simply looking at it doing its thing. We are not smelting iron, copper and Arachnian stalagmites to create the inverse Galerian crop circle
or whatever. We cut squares into smaller squares, circles into slices, paint and then stack them. We can animate every step in the journey a shape takes, from extraction to delivery.
There are some exceptions to this rule, however. Some processes would be too difficult to animate and take more time than it’s ultimately worth. An example would be the packing of a thousands shapes into a small crate – it makes sense from a gameplay perspective, but would visually not work well.
[h2]Getting started[/h2]
We started off with a very basic aesthetic, inspired in some ways by Mini Motorways. Limited geometry, a desaturated color palette and no fancy effects. No metallic objects, reflections or bevels. We made a few concepts for the general theme of the game and worked together with the community to settle on the space theme Shapez 2 now sports. With the theme set in place, we could now start detailing with shading, reflections and metallic objects.
The visual language for the buildings – repeating patterns, colors and design choices – developed over time. Back when I joined tobspr Games, all I had to work with were some very basic visuals Tobias made. Essentially, it was my job to make them look good! I proposed a few early design ideas, created animations and defined design rules that we still adhere to today. Some of these early ideas are still present in the current version of the game, like the animation for the lifts.
[h3]Pinpointing our vision[/h3]
The direction we wanted to work towards could be described as a marriage between the realism (physicality) of factories and the abstraction of space. Good examples of this are the belts and belt corners. Instead of being a simple 90 degree curve with a stretched texture, or a hard UV seam like many other games do their belts, we made something akin to how a real belt functions. These belts have a texture looping around rollers, ‘cartoonified’ a bit by hiding certain complexer parts of the mechanism. This way, the belts get the vibe of a real factory, with enough abstractness to allow for greater creative freedom. More examples will follow later on!
In general, we’re aiming for a highly polished look with tons of detail, many of which may never be seen by a lot of you. The buildings would hold up in a (non-existent) first person mode, even if we didn’t design them with that goal in mind. With the use of LODs, a consistent design language and a lot of iterating, we ended up with the world we imagined. It captures the spirit of Shapez 1, while looking a lot more appealing (to most), as well as being more readable and easier to understand.
With this design philosophy in mind, let’s dive into some specific examples!
[h2]Designing buildings for Shapez 2[/h2]
The building blocks that make up the core of Shapez 2 stayed largely the same as in Shapez 1. Quite literally actually, as the game is still logically separated in square blocks of one. Since the functionality of a lot of buildings is directly taken from Shapez 1, we ‘only’ had to come up with ways to visualize their inner workings. This turned out to be quite the challenge, however. With the technical and artistic constraints we were working with, it became very difficult to come up with the designs.
A lot of the technical constraints are set to make sure the game keeps running smoothly. We had to limit animations and forgo most of Unity’s basic systems in order to support large factories. We cannot use baked animations, for example. If you’d like to read more about the performance constraints, be sure to
check out devlog 011!
[h3]Four pillars of design[/h3]
Readability, building uniqueness, building uniformity and ‘coolness’. These are the four design pillars we try to adhere to. However, within these four pillars, we can already find two conflicts: readability versus coolness and uniqueness versus uniformity. Let’s go over both these conflicts!
Readability versus coolnessIn a nutshell, readability is the ability for the player to easily differentiate between buildings and understand what a building does from a distance, in our case about 30 meters away. For this reason, buildings shouldn’t have too much visual noise and animations should be simple, e.g. not have too many moving parts. Coolness is all about how fun and interesting the game looks.
Of course, it would be fun if we could give every building big lasers, launchers and complex animations, but this comes at the cost of readability. The more flair a building gets, the more detailed it gets and the less readable it becomes. If we make every building a big light show, you’d have no clue what’s going on after you’ve placed a couple down.
Uniqueness versus uniformityThis conflict links directly to readability. You need buildings to look and feel unique to make them stand out and make their function clear. However, the game should look coherent and every building should share one visual design language.
Every building should follow these four pillars of design. They should look cool, yet readable. To be readable, they should look unique, yet similar enough to fall in line with the other buildings.
[h3]Design pipeline[/h3]
Each and every building has to go through a long string of departments and stages before its finalized form makes it into the game. Their journey is as followed:
- Game design prototyping
- Art concept
- 3D prototyping
- 3D refinement
- Polishing (Quality Assurance)
Of course, this is a very simplified look at the entire process. It makes sure we don’t miss any crucial oversights, like animation clipping between adjacent buildings or concepts not adhering to the aforementioned design pillars.
[h3]Logistic versus processing buildings[/h3]
We differentiate between logistic and processing buildings. Belts, mergers, splitters and lifts are logistic buildings; they move shapes around. Buildings like cutters, stackers, painters and swappers are processing buildings; they make changes to the actual shapes, producing different shapes.
The function of a building will also determine their design language. Logistic buildings have lightweight, open designs that clearly display what they’re transporting. They have unique designs per build layer to differentiate them, and have one central orange element that does something, like the pusher element in a splitter. Processing buildings should stand out and really look like buildings. They have very boxy designs and have thick, orange borders, yet should retain a unique look to differentiate them. With these differences, players should easily be able to tell the difference between the two types of buildings, even from far away.
[h3]Design limitations and rules[/h3]
With all this in mind, we face a handful of limitations when it comes to designing buildings, the design pillars aside.
- Buildings must not exceed their defined chunk (their personal space, as it were), especially not during animation
- Inputs and outputs should always be in the center of the chunk and be uniform across all buildings (looking at you, old tunnel entrances and exits)
- Animations should be readable from a distance, good looking up close and convey their purpose
- Animations are limited to moving, rotating and scaling
- The amount of (moving) objects per building should be limited to keep performance smooth
- Shader-related restrictions, like glass being expensive to render
- Shapes should not be rotated during an animation (except, of course, the rotator)
- Shapes should not clip through objects during an animation or when transported
- Animations should loop perfectly
- Animations should support a belt at full capacity and stop when the output stalls
- Shape supports should be handled in some way, they may not just spawn in or magically disappear
One issue we’re still actively working on are the supports for multi-layer buildings. As you can place buildings below these belts, the belt supports can conflict with the building below. Not having any supports looks weird, but they’re technically not relevant for gameplay.
[h3]Casus 1: The (full) cutter[/h3]
Anyone familiar with Shapez 1 will probably recognise the cutter:
This building works well in the Shapez 1 style, but it doesn’t translate well to Shapez 2. Tobias created a basic model for the cutter, which gave me a rough idea on how it should work in 3D as an open design. However, the visuals needed a complete rework.
This presented quite the challenge, since in Shapez 2 the building operations are not dependent on camera rotation, but tied to the world as it were. This is necessary, as blueprints wouldn’t work if the buildings would change the axis they work on. If the cutting angle would be baked into the building itself, said angle would change if the rotation of the blueprint would change. This also means you’d get a different output every time you rotate a blueprint.
You can see the solution below. The blue half circle indicates which part of the shape is manipulated. The same principles extend to the Swapper as well.
[h3]Casus 2: Lifts[/h3]
To introduce a completely new problem to developing this game, we decided to add layers. You have to be able to move a shape from one layer to the layer above or below. Let’s go through all the boxes it has the mark off, shall we?
Lifts should…
- not clip
- not use baked animations
- support a fully upgraded belt
- be able to stop if the output stalls
- not use more than 2 moving parts
- support corner and backward delivery options
- make sense when viewed from above
- fit the general style of the game
- not take up too much space (open design)
- look solid and sturdy
- have visible support for moving parts
- have a looping animation
That’s quite a lot of requirements to work with, but we’re very happy with how it turned out. The current design is almost a year old by now, yet it’s still one of my personal favorites.
Not to mention you can make stuff like this:
[h3]It’s in the details[/h3]
As we mentioned before, we went for a very polished, yet stylized look. Almost every building currently has one or two little details that you can discover if you zoom in close enough. Let’s have a little peek:
The belts were made to emulate the look of real conveyor belts, including a bit of suspension that holds everything in place. We made sure the UVs and textures aren’t stretched and decided on handling the change of direction of belts in a way where they feed into each other instead of warping.
Or take a look at the painter, which is admittedly still very much a work in progress as far as shaders are concerned and will get another overhaul later. We wanted the painter to adapt to the height of the shapes coming in. So, we added a hinge and allowed the roller to move up and down as shapes of different heights are fed into the machine.
[hr][/hr]
We hope this devlog showed you a complete picture of our design process for Shapez 2. Of course, we also hope you enjoyed it :)
If you have any questions, be sure to join
the Discord server.
https://store.steampowered.com/app/2162800/shapez_2/
See you again in two weeks!
~ Nils & the Shapez 2 team
[h3]Join the community:[/h3]
Twitter / X YouTube TikTok Discord Reddit Patreon
