Textorio

Textorio runs on pneumatics. Air moves through pipes, pipes have real pressure, and pressure takes time to travel across a network. That was already in the game because the fluid system needed it. Then one day it occurred to me that pressure is a signal. High pressure is a 1. Low pressure is a 0. A valve that opens only above a threshold is a comparator. Two lines meeting is an AND. A line that holds its own state after the input goes away is a latch. And once you have a latch, you have memory. So i called it P.Logic. Pressure logic, bucause everything in my game runs on pneumatics :) It is hardware, not a script This is the part i want to be clear about, because most factory games that add logic add a text box. P.Logic has no text box. There is no scripting window, no console, no language to learn in the usual sense. You build the logic the same way you build everything else, by placing things on the floor and connecting them with pipes. Sensors, gates, comparators, latches, timers, counters. They are machines. They take up space. They can be in the wrong place. Which means your logic is visible. You can walk up to a circuit and read it, the same way you can walk up to a smelter line and see where it is backed up. In a text-based system the logic hides inside a window. Here it is just more factory. The memory cell The thing i keep coming back to is that you can build a working memory cell out of pipes. Not a scripted "remember this value" block. An actual latch, made of physical components, that holds a bit because of how the pressure behaves. You set it, the pressure stays. You reset it, it drops. Nothing in the code says "this is a memory cell". It is a memory cell because of what it does. The first time somebody builds one of those without me telling them it is possible, that is the whole game for me. The honest part: maybe five percent Now the doubt. I spent a long time on this. Weeks. And there is a real chance that most people who play Textorio will never pla...

Most devs post the good stuff. Here is a month of the other kind. All five of these were real, all five are fixed on my machine, and one of them is genuinely my worst bug so far. 1. The critters were eating your saves This one still bothers me. Textorio has small animals that wander around on the surface. In June i finally got them flocking properly, so they move together instead of drifting around like lost pixels. I was quite proud of it. The DEVLOG entry is basically me congratulating myself. The way flocking works is that each critter keeps a list of its neighbours. And at some point i changed that list from storing ID strings to storing the actual critter objects, because it is faster. So critter A points at critter B. And critter B points at critter A. That is a cycle. And JSON.stringify throws on a cycle. Critters get written into every save. So the moment two critters of the same species stood near each other, which is most of the time, because that is the entire point of flocking, the save threw an error. And here is the part that makes it a real bug instead of a funny one: the error was swallowed. The function caught it and returned 0. You got "failed to save" or, worse, nothing at all. Every autosave, every ten minutes, silently doing nothing. They were being friendly. That is what broke it. Fixed in 44c85a4. The neighbour list is per-tick working state, it gets rebuilt every frame anyway, so it never needed saving. It is stripped at the save boundary now, and there is a test that builds the exact broken structure and asserts it survives. 2. The battery that took 111 minutes Accumulators store power. Three separate files each declared how much they hold. Two of them said 2000000 and called it Joules. The power system runs in kilojoules. So the live accumulator was a 2 gigajoule battery, charging at 30 kilojoules per tick. That is 66,666 ticks. One hundred and eleven minutes to fill one battery. The comment in the file says the target was 16.6 seconds :)))...

TRANSMISSION 004 >> Orbital survey complete. The planet is bigger than the drop site. Quick honesty first, because i would rather say it up front than have you download and go looking for a button that is not there: none of this is in the public build yet. This is a progress report on what i have been building since the Colony Update. It runs here, it is playable here, and it will come to the build before Early Access in autumn. Right, now the fun part. ONE PLANET, NOT ONE MAP Every campaign so far has dropped you on one 100x100 map and that was the world. Kepler Online is a second mode sitting beside the campaign, and in it the planet is 32 x 32 claims, 1024 of them, and each single claim is a full campaign-sized map. Walk to the edge of your land, press , and you cross into the next one. The terrain flows across the border. It is one continuous planet, not a level select. The whole world is one integer. A claim is just a window onto the same noise field at an offset, so it is identical for every operator, forever, and it never gets stored anywhere. That is the trick that makes 1024 regions cost nothing. THE GEOLOGY IS HONEST NOW Early on every claim carried every resource, which meant no region was worth walking to. That is fixed. An ore body now follows the ground it belongs to. Average copper tiles per claim, by biome: TUNDRA - 8. effectively barren PLAINS - 37. scraps TROPICAL FOREST - 86. workable FOREST - 99. workable DESERT - 324. rich SAVANNA - 359. rich That is a 46x gradient. Copper and crude oil belong to the deserts and savannas, roughly 12% of the planet. Iron and coal stay common everywhere, deliberately, so you can always build from where you are standing. The trip is for tier 2, never for survival. You do not choose where you fall, so about 98 of the 1024 claims are landing sites and they are the only places you can descend onto. Those carry a full deposit set no matter the climate. In the fiction they are where the cycle-94 ships set down, chosen b...