Hi everyone!

We’re back with another Dev Diary, and this time we’re taking a closer look at Cranelock: how the city changed during development, why we rebuilt so much of it, and how we found its final look and structure.

And before we get into it, if you’d like to follow development more closely, share your thoughts, or chat with other players, you can join us on Discord:

https://discord.gg/GgpWJ6xFua

Now, let’s take a look at how Cranelock became the city it is today!

Cranelock is now a compact coastal city where most important locations are only a short drive away. It wasn't always like this.

During development, we changed the size of the map, the road network, the city's height relative to the water, the location of the player's warehouse, and even our approach to progression through the city. By the end, around 90% of the city had been rebuilt from the first blockout.

From the start, we looked at recognizable American cities, especially San Francisco, with some influence from Chicago and New York.

Before level design work started, we already had a visual concept and a modular kit for Cranelock. The artists studied real American streets and looked for the details that would help the city feel right.

Then we started building the map itself.

From a level design perspective, it all started with a blockout.

At first, there were very few hard constraints. We were building the city while prototyping the main mechanics, so there was plenty of room to experiment. Limits on the map size and warehouse location came much later.

Once the core mechanics were clearer, three requirements became obvious: the city had to be compact, easy to navigate, and comfortable to drive around. The map itself was not the only thing changing.

In one of the earliest concepts, the city had a retrofuturistic look.

As the narrative took shape, that style stopped fitting the world. We stopped trying to imagine the future through the aesthetics of the past and looked at the present instead.

We looked back at ten years of technological change and tried to imagine how another ten years might affect everyday life.

Cranelock gradually moved into a near-future setting. Its structure changed along with the visual direction.

One early version of the map split the city into four large areas: the Ghetto, the Industrial Zone, the Business Center, and the Fancy District.

The division affected much more than the map itself. Each district was meant to have its own architecture, color palette, types of businesses, and even potentially its own products and customers.

The Industrial Zone focused on manufacturing and working-class neighborhoods. The Business Center was built around more expensive city infrastructure, while the Fancy District focused on public and cultural spaces.

Even at that stage, we designed the city around deliveries. It wasn't enough to decide what belonged in each district. We also needed a reason for the player to go there.

The plan was to unlock the districts one by one as the player progressed. We eventually dropped that idea.

Testing gradually showed that our game wasn't about a huge open world.

And it wasn't really about driving either.

The warehouse is the player's main base. A large part of the core gameplay loop happens there. The city should add to that loop with new customers, places, and situations without making the player spend too much time on the road.

The large map was starting to work against that.

Unlocking the four districts one by one created another problem. We would have needed to explain why the player could drive down one street but not turn onto the next.

We didn't want invisible walls or artificial restrictions just to make progression work.

So we started shrinking the city.

Scale stopped being a goal in itself. We wanted the city compact enough that the player could head out on an errand and get back to the warehouse fairly quickly.

Whole blocks and roads changed during development. So did the map scale, the warehouse location, and even the city's height relative to the water.

Very little of the original blockout is still there.

Cranelock taught us one important thing: don't get too attached to what you've already built.

If something no longer works for the game, we have to change it, even after we've spent a lot of time on it.

Cranelock started as a retrofuturistic city divided fairly strictly into four districts. Today it's a compact near-future city, and its layout is shaped largely by how the player uses it.

We made the map smaller.

But Cranelock itself ended up feeling much more like a real city.

Early in development, most of the city's points of interest were fairly modest.

A pharmacy. A barbershop. A bar. A fishing supply store. A motel. A home goods store.

A small, recognizable storefront along the street was enough to mark a destination.

Looking at the first concepts next to the current city makes the change pretty clear: our idea of what a point of interest should be changed a lot along the way.

When we say Cranelock was inspired by San Francisco, it's easy to take that too literally.

We never set out to recreate a specific American city.

The question we cared about was simpler: what makes a place feel like that?

We weren't interested in San Francisco's famous tourist views or the large buildings downtown.

We focused on ordinary streets: small homes, low-rise buildings, outskirts, and working-class areas. We paid attention to how buildings sit along the road, how entrances and stairs are arranged, and which materials are used on the facades.

We were especially drawn to San Francisco's hills, and to the way dense streets can still feel bright and sunny.

We also studied New York and Chicago.

The artists spent hours studying real streets in these cities and collecting elements we could use to build our own city rather than copy an existing one.

Historical accuracy was never the goal. We needed a set of rules that would keep the streets coherent without making every building look the same.

The Edwardian base quickly picked up elements of Late Victorian, Mission Revival, and Chicago School architecture. We cared less about putting each building into a precise style category and more about whether its scale, proportions, and materials worked with the surroundings.

The next challenge was bringing all of this into 2037.

We didn't want the future to erase all of Cranelock's existing architecture. Modern buildings had to fit into a city that was already there.

Sometimes keeping the familiar street scale and materials was enough. In other places, we could move much further away from the original architectural base.

For the Business Center and its huge advertising surfaces, for example, we looked to Tokyo and Times Square: media facades, corner screens, and dense city advertising.

Eventually, it mattered less and less how closely Cranelock resembled San Francisco.

San Francisco gave us a starting point: scale, terrain, the character of residential streets, materials, and architectural details. After that, we mixed those rules with other references, modern architecture, and the needs of the game.

Gradually, we stopped trying to reproduce a real city and ended up with Cranelock.

A good automation system should do more than save a few clicks. It should arrive at the moment a familiar task starts competing with something new, then quietly reshape the way the player runs the warehouse.

Character concept exploration from the world of Shipping Store Simulator 2037

That principle guided our robots, their breakdowns, and even the features we eventually left behind.

https://store.steampowered.com/app/4098030/Shipping_Store_Simulator_2037/

The demo introduces two assistants: the Customer Service Robot and the Loader. We deliberately do not hand them to the player at the start. Each appears only after a once-new mechanic has become familiar enough to demand too much attention.

The Customer Service Robot joins when the player has learned the rhythm of serving visitors and the queue begins to grow. VIP orders arrive at the same time, so standing behind the counter all day is no longer an option. The robot can take over that routine: it accepts orders, packs them into branded bags, and hands them to customers.

The Loader follows the same philosophy. Early deliveries are small enough that unloading boxes is a meaningful part of warehouse work. Later, the player spends more time running errands around the city. That is exactly when the Loader becomes useful: it keeps the entrance clear while the player is away, rather than leaving a mountain of untouched deliveries at the gate.

For us, the robots are not simply a path to full automation. Each one removes a routine the player has already mastered at the exact moment the game is ready to introduce a new layer of work.

The wider robot family is built around distinct jobs rather than cosmetic variation

And the family is growing. On October 14, players will meet five new robots, each with a unique function designed to help with new mechanics and the next stage of business growth.

Early exploration of a helper model across different proportions and levels of detail

Every robot and every piece of warehouse equipment has a hidden durability value with a maximum of 100. Each use reduces that value, and the rate of wear depends on the machine.

For example, the manual labeling machine is designed for 50 uses at full durability, so every use removes 2 points. The automated labeling machines unlocked after expanding the warehouse wear down more slowly.

Equipment and robots share the same durability logic behind the scenes

As durability drops, machinery and robots begin to work more slowly. Ignore a robot for too long, however, and the result becomes much more visible: it catches fire, panics, and runs around the warehouse. At that point, a normal repair is no longer enough. First, you have to catch the poor thing with a fire extinguisher.

Critical condition is intentionally dramatic and a little chaotic

Repairs use a repair kit. It can be applied to any machine or robot below 100 durability, and a single kit restores it to full condition regardless of how badly it has worn down.

A repair kit restores a worn machine or robot to full durability

One release secret remains. Observant players will discover a second, bonus use for the repair kit on certain robots.

Writers sometimes build a complete biography for a character: where they grew up, who their parents were, what they fear, and what happened before the story began. The reader may never learn most of it, but that background helps the writer make consistent choices.

We took a similar approach with the robots. Instead of writing biographies, we defined the context in which they exist. Can you walk into a shop and buy one? Is it normal to see a robot on the street? What sits underneath its outer shell?

Cranelock already contained the answers. Robots are sold in city stores. Delivery drones move calmly over the streets. Competitors use their own machines in advertising campaigns. The technology is so ordinary that a robot can stand in a queue among people and nobody gives it a second look.

Customer facing forms became a study in approachability without turning the robot into a toy

That context became the model’s “biography” and gave the art team useful boundaries. A robot should not look like an experimental prototype from a secret laboratory, but it should not feel like something welded together in the garage next door either.

Too much polished metal, neon lighting, and spotless surfacing pushes the design into distant science fiction. Too much dirt, exposed welding, and rough construction makes the technology feel rare and improvised. We were aiming for something from the near future: modern and friendly, but still practical and believable.

The arms and heavy rotating waist were designed around the physical work of handling boxes

We were equally careful not to overdo the “cozy” side. The robots were never meant to be cute or toy-like simply to win the player over. Their personalities come first from their jobs. The Customer Service Robot uses smoother, friendlier shapes. The Cleaner borrows a familiar language from robot vacuums. The wholesaler model has reinforced limbs and visible hydraulics because it must carry heavy loads.

We continued that logic even in places the player will never see. The team explored what sits under each shell, how the components connect, and what makes the mechanism move. None of that detail appears directly in the final game, but it gave everyone the same mental model.

That was the artistic goal: the player may not know a robot’s history, but they should immediately understand what it is and why it exists.

A broader concept study of robots as everyday machines with different roles

Over the course of development, plenty of ideas reached the concept or prototype stage without making it into the final version. Sometimes they simply did not work. Sometimes they worked perfectly well, but we found a better solution.

The warehouse did not always look the way it does now. We tested many layouts before settling on a compact, single-storey building. The reason was practical: from almost anywhere, the player should be able to scan the space and understand what is happening.

We considered placing the player room upstairs, then chose to keep the warehouse visually accessible

One of the experiments with warehouse layout and circulation

Searching for the right scale meant testing very different warehouse proportions

We also experimented with conveyor belts. At first, nothing seemed better suited to an automated warehouse. In our space, however, the conveyor quickly demanded too many convenient exceptions. Where does a box go when the belt reaches a wall? Does it disappear behind it and magically reappear somewhere else?

An early conveyor belt experiment

We wanted the opposite. The player should see the entire life cycle of a box: unloading, labeling, and movement through the warehouse. For a simulator, feeling connected to those physical processes mattered more than maximum automation. We handed some of the work to robots and removed the conveyors.

For a similar reason, we eventually removed the placement grid. It made the warehouse tidier and more predictable, but it also began deciding what a “correct” layout should look like. We cared more about player freedom: where equipment goes, how work zones are organized, and how chaotic the logistics become should be the player’s choice.

The labeling machine evolved from a visually dominant prototype into a quieter part of the workspace

The current level one labeling machine no longer pulls attention away from the rest of the room. It sits naturally inside the warehouse instead of feeling like the room was built around it.

Some experiments were harsher. At one point, robots could explode if the player waited too long to put out the fire. It sounded fun right up until the explosion destroyed a robot the player had invested time and money into. We decided the joke was not worth the punishment and cut the idea.

Charging station concepts were also removed to preserve free placement

We also considered upgrades and expansions for the player’s private room. The logic seemed obvious: the warehouse grows, so the personal space should grow too. During development, we realized that this was the one place where constant progression was not useful.

While the warehouse is rebuilt, filled with equipment, and reshaped by the player, the private room remains familiar. It is a recognizable constant: a place where the same objects stay roughly where the player expects to find them.

Two versions of the player room explored during development

The same rules extend beyond the warehouse. Cranelock has to feel like a place where deliveries, service robots, and unusual machines are part of daily life, not a spectacle reserved for a distant future. Street scenes, interiors, and character studies helped the team keep that tone consistent.

Cranelock street studies connect the warehouse to a broader city built around everyday logistics

That process sums up how the game changed during development. We did not remove ideas only because they were bad. Some mechanics were interesting on their own, but they got in the way of something more important: player freedom, readable spaces, and the sense that every process in the warehouse happens for real, right in front of you.

After all, we are making a simulator. If a box goes somewhere, we want the player to know where it went.