Update 1.0.15: a hardcore mode where you can't do anything by hand

 

Five new Custom difficulty settings from a player's idea, a fixed Mac crash, and a bug an AI helped us find

Craftomation 101: Programming & Craft

EducationProgrammingAutomationSandboxPuzzle

 

Hello mates!

 

It's Kolya, the programmer of Craftomation 101, and Sasha, our tester, again. Last time we told you about the big optimisation, and today it's update 1.0.15. It has a hardcore mode that a player came up with in the comments, a fix for the Mac crash, and a bunch of other fixes.

 

If this is the first time you've heard of us: Craftomation 101 is a game about visual programming and automation. You land on a frozen planet with one hungry robot, put programs together from code blocks, and the robots follow them: they gather resources, craft, keep the bonfires burning, build more robots and slowly bring the planet back to life.

 

Here's the trailer, so you can see what it looks like:

 

 

 

 

The main thing in this patch is five new settings for the Custom difficulty. With them you can, for example, forbid yourself from doing anything at all with the mouse: no mining, no carrying, no dragging robots around. Then everything on the planet is done only by the robots you've programmed. Below we'll tell you where the idea came from, why one ban wasn't enough, what it's like to play, and what happened to Macs.

 

"Making things more tedious isn't hardcore"

 

In update 1.0.13 we added the Hardcore and Custom difficulties. In Hardcore, robots use more charge, bonfires burn for less time, and deposits hold few resources. In Custom, you can set all of that with sliders however you like.

 

And then, under the post about that update, a player called fed1s wrote: "Hardcore in a game whose core is 'programming' means limiting the player's direct actions and making them solve every task algorithmically. As long as you can do everything by hand (clicks, taps and drag-and-drop), there's no challenge."

 

 

 

 

It's hard to argue with that. Craftomation 101 is a game about programming, but a lot of it can be done with the mouse: mine a stone with a click, drag a resource to a bonfire, carry a robot closer to its work. The sliders make the game harder, but they don't make you program any more.

 

In the last post we said we really liked the idea, but we didn't promise anything. Turns out we didn't need to promise: we just went and did it.

 

Five new switches

 

The new settings live in the Explore Worlds window. Pick a map, choose the Custom difficulty in the Game mode row, and five switches appear below the sliders. The Craftomates in their names are our robots.

 

 

 

 

Only Craftomates can mine; no clicking allowed. You can't click on deposits any more. Every single stone has to be mined by a robot you've programmed.

Only Craftomates can move items; no dragging allowed. You can't pick anything up and move it with the mouse: not a stone, not an item you've just crafted, not a robot. Everything moves around the map only through programs.

Free emergency fire for an empty, frozen fireplace. It's on by default, and now you can turn it off. More on it a bit further down, it's a story of its own.

Unlock all Craftopedia entries. The Craftopedia is the catalogue of all the items in the game. Normally an item only appears there once you craft it for the first time, and until then you can't use it in a program. So you can't tell a robot "find a Steel Plate" if you've never made one. With this switch, every item is available right away.

Unlock all Programming upgrades. Normally commands unlock gradually through the upgrade tree: the simplest ones first, and arrays and loops a couple of hours into the game. With this switch, the whole language is available from your very first robot. Only Recharge and the battery and bonfire upgrades are still bought separately, as before, and you have to start with Recharge. The switch unlocks the language, not everything else.

 

 

You can turn the switches on in any combination: just one or all five. And you can stack them with the Custom difficulty sliders. Sasha puts it like this: push all the sliders all the way to the right and you get hell. Add the bans and you get hell within hell. That's why the game honestly warns you that these restrictions can make it impossible to continue.

 

The two "unlock" switches are player requests too, just from different players. Some have already finished the game and don't want to fill in the Craftopedia item by item a second time. Others know how to program, and it's boring for them to think one command at a time at first and only get arrays and loops two hours later. Now, already on your first ten stones, instead of writing "bring a stone" and sitting there waiting, you can tell the robot right away: "bring me two stones, five times".

 

The upgrade tree hasn't gone anywhere, though. It's there for people who are just getting to know programming: when commands unlock one by one over several hours, they're easier to understand without getting lost. The switch is for those who don't need that ladder any more.

 

Emergency fire, or a safety net from the developers

 

Sasha speaking

 

A few patches ago we added the Emergency Fire button. The situation was this: there's a mistake somewhere in a program, the bonfires have burned out, the base has frozen, the robots have stopped. It's not a dead end, you can warm the base back up. But it's slow and dreary. Players complained: the base froze gradually, and then they had to suffer through thawing it out just as gradually.

 

You can use the emergency fire once a minute. Every bonfire that has gone out and frozen gets one unit of whatever it burns: a regular bonfire gets a fire, and a bonfire that runs on steam batteries gets a Steam Battery. Bonfires that have just gone out but haven't frozen aren't touched. It exists exactly so that the base thaws, the robots start moving again, and you can calmly fix your program.

 

Now you can turn it off, so that mistakes hurt more. That's for the really tough hardcore players.

 

Oleg, who usually writes our posts, asked me: is this even good design? Emergency fire is a slightly unfair crutch, the player uses it to get around the rules. I think it's very good design. Players have the right to tune the difficulty to themselves. Some people rush home wanting to tear everything apart: keep an eye on everything and make ten decisions a second. Others are tired after work or school and want to just play a bit rather than really play. If they missed something or had to step away from the computer, the game shouldn't scream "aaah, now I'm going to punish you". It should help. This is an old story anyway: the very first Doom already had difficulty levels, and on Nightmare the enemies even came back to life. Everyone can set it up the way they like.

 

Why one ban isn't enough

 

Kolya speaking

 

Technically, banning the mouse wasn't hard. The difficulty turned up somewhere else: a ban on its own doesn't make the game playable. Sasha and I worked really closely together on this: he played and found places where you couldn't go any further without your hands, and I closed them. Here's what we had to add:

 

If manual mining is banned, the starting rocket brings two robots instead of one. A single robot at the start, with no help from you, is just too bleak.

If picking things up is banned, the starting robots and reward robots arrive fully charged, and the Feed Mate command is available from the very start. You can't recharge a robot by hand, so robots have to be able to charge each other right away.

A reward robot can now be switched on with a click right where it appeared: after all, you can't drag it anywhere.

If mining by hand is allowed but moving things isn't, whatever you mine stays on the ground. The robots will pick it up.

 

 

20 minutes in hell within hell

 

Sasha speaking

 

Before this post, I honestly sat down and played for 20 minutes on the very hardest setup, the way a regular player would. And I didn't die.

 

The game became a completely different game. I even found a kind of zen: now the game wants optimisation from me. If not of the code, then of the base: what stands where and who walks where. Resources are scarce, so you can't just put things wherever any more. For example, I started switching off the robots that carried fires to the bonfires: there were too many fires, and the robots use up energy. A whole different vibe.

 

Without hands, while you have few robots, it can be a bit tough, but the second robot at the start helps a lot. And when you have lots of robots, the ban becomes more of a plus: it's interesting, and you can sit back and play with one hand.

 

In those 20 minutes I brought two seeds to the base, grew a tree from them and got as far as the Furnace. I think you can finish the game this way: the game generously gives you bonfires, chests and robots for completing tasks, and there should be more than enough of everything. Whether you can get hopelessly stuck somewhere is a question for our hardcore players.

 

[ИЛЛЮСТРАЦИЯ: база Саши через 20 минут на максимальной сложности со всеми запретами (дерево, Печь) — скриншот или короткое видео]

 

The Mac that crashed after a minute

 

Kolya speaking

 

Good news first. Since patch 1.0.14 with the big optimisation, not a single player has written to us that the game lags. We're incredibly happy about that: the patch was big, complicated and long, and it looks like our effort wasn't wasted.

 

Now the bad news. Under the same post, a player called HuskyExercist wrote that after the update they couldn't play on a MacBook with an M1 chip: the game crashed after about a minute.

 

 

 

 

It turned out the cause wasn't so much the optimisation as the new version of the Defold engine we moved to in 1.0.14. In it, the engine chooses by itself how to draw the picture on a Mac.

 

Let me explain a little. To draw a frame, the game uses a graphics API to tell the graphics card: "draw this on the monitor for me". There are several ways to talk to a graphics card. Macs have Metal, the modern one made by Apple itself, and good old OpenGL. The new engine started choosing Metal by default, since it's newer. And on some Macs something went wrong with Metal. Whose fault it is, ours or the engine's, we don't fully know.

 

The solution was simple: we brought OpenGL back. The previous engine version ran on it, meaning the game all the way up to 1.0.14, and everything was fine for everyone. Now the game on a Mac always runs on OpenGL, whatever the configuration.

 

To check the fix, we went around the whole office and gathered every computer with an Apple M chip. We found four, and the problem is gone on all of them. Unfortunately, HuskyExercist hasn't replied yet about whether it helped. If you play on a Mac too and the game used to crash for you, please let us know whether it's fixed.

 

A bug nobody had reached yet

 

Sasha speaking

 

There were no funny bugs with silly pictures on screen this time: the game is pretty polished by now. Kolya says a player would have to try really hard to run into my latest finds.

 

But there was one strange one. The fuel economy upgrade somehow slowed down plant growth and changed how much water plants drink. Even though it has nothing to do with plants at all.

 

These days I hunt bugs like that together with an AI, Codex. It can compare what was intended with what's actually written in the code, and then announce: "Guys, ha! You're multiplying by the wrong variable in this formula." And that's exactly what it was. So now we catch not only bugs that have already happened to someone, but also ahead of time: we recheck every suspicious place so that they never happen to anyone.

 

What else is new

 

Custom function groups can now be reordered by dragging them by their header. The new order is saved.

The keys that speed up and slow down a robot can now be rebound in the controls settings.

The game starts even faster if you have lots of saves: before the main menu it no longer unpacks custom functions from every save at once, and only checks the world you're loading.

 

 

And the rest of the fixes

 

After loading a finished world, the game no longer gives you the task for a rocket that has already flown away again. Saves where this has already happened get fixed too.

The Brewery keeps its ingredients, finished ale and output queue. Ale no longer disappears after loading if there was nowhere to put it.

Loading code from a Memory Card inside a Repeater in a custom function no longer gets mixed up with the old program.

An Ale Sprinkler with Primordial Ale restores 2 energy per second, as intended, instead of 6.

Recreating custom functions no longer restarts a tutorial you've already completed.

Tile coordinates on Shift follow the cursor again while the code editor is open, and the tile highlight disappears when it closes.

In the bug report window, pasted text wraps across lines, automatic line breaks no longer end up in the sent report, and your own line breaks made with Enter are kept. And Ctrl+A works now.

Save cards count only the robots you've selected at least once, not every robot on the map. We also fixed some labels and translations in the world list.

The upgrade points counter updates right after a purchase, and the reminder about unspent points no longer appears when there's nothing left to buy.

In the demo, the difficulty window opened from Explore Worlds correctly shows the full version's restrictions on every tab.

 

 

Try to break our difficulty

 

We spent a long time going through combinations of switches and sliders, looking for places where a player could get so stuck that no scheme would get them any further. It looks like there are none left. But you're surely more inventive than we are. If you find an impossible combination, be sure to tell us: we're genuinely very curious.

 

And if you find a bug, send it to our Discord, in the comments, or right from the game: there's a bug report form there. We'll see everything and fix it.

 

And thank you, fed1s, for the idea. Sometimes one good comment turns into a whole game mode.

 

Kolya and Sasha