Factory Progress Update (Patreon)

Well, everything's late, as always. Somehow, I'm still genuinely surprised by this.  

Anyway, Factory time! Last time we left off, we had working pipes, a milking machine, and a refining machine.

It looked like this.

First, a few minor things: aesthetics, usability, and debugging. Then we need to complete all the planned machine classes and pray that the fluid system doesn't need an overhaul to cope with the new stuff. We're still in the mostly-code section of making this game, so it's pretty technical :3

Aesthetics

So it's tempting to say "I'm gonna ignore all the visual stuff until the code is perfect." But this is kind of a trap. You won't know what problems there are with the code/art interactions if you completely ignore the visuals. Even something stupidly minor - adding little icons to the menu - broke the UI events that communicate with the game. 

It made me realize I was thinking about the UI wrong. I need to treat the UI like a real single-page website with dynamic data. A regular web page usually pulls data from a database. This one will pull it straight from the game.

So I need some real web development tools. jQuery is standard for scripting html stuff, but it's pretty bloated, so I'm using a super lightweight knockoff called cash.js. This will let me dynamically build and manipulate pieces of the UI more easily. Neat. Let's test it. (super wip obviously)

Clicking on the 'NPC' button pops up a list of all npcs in the game. We can select which npc will go into which machine. Progress.

The UI and game code are separate. But since they're both on the same web page, I can send information back and forth by triggering events on the page itself.

Something I've learned from doing ordinary web development is to always have a single source of truth. If an npc is selected in the UI, they'd better be selected in the game code too. So when the player clicks on an npc, the UI informs the game first, the game selects the npc, and then informs the UI to update. Boring, but necessary.

Let's make some minor tileset updates too. I'm sick of the colored squares.

Now that the machine background meshes with the wall behind it, I realize I need to put a little more thought into how these machines connect to their surroundings. The idea is that the factory is largely vertical, so I need a way to communicate that this is a big wall with machines sticking out and ponies hooked up. Will work that out with the artists.

Usability and debugging

For sanity, click-and-drag will lay down a whole pipe now. And since things are about to get complicated, I need some real-time debugging info on the pipes.

So each game tick (~0.1 seconds), I'll update a textbox with info over each pipe connection, and over the whole pipe. A red connection box means there's not enough room to output, so fluid is spilling. 

Machine type: Storage

New machine! Fluid storage. Fluid goes in the IN pipe and fills the npc. Then, when needed, fluid goes out the OUT pipe and fills whatever is down the line from it. 

Okay seems simple enough. I can get the fluid to go in, but now, how do I know when fluid needs to come out? I guess I need to check every machine down the line from the storage to see if it needs fluid... but since fluid transfers instantly, it's actually hard to tell if I'm accidently over-sending stuff from storage until it's too late. Also, there's a different between a machine needing fluid, and simply having room for more. Milking machines output all possible fluid. Storage should only output when asked.

I'll spare you the excessive complaining I did in real life, but this took a damn while to solve in a satisfying way. An indirect reason it was so hard was the fluid model I was using: the game was treating fluid like electricity, instantly transferring an infinite amount through one pipe. 

Aaaand there's that fluid system overhaul I was afraid of.

So the obvious question is- should I make the fluids actually flow through the pipes one tile at a time? After looking into the various fluid models that the Factorio devs grappled with (including a browser-based simulator someone put together), I decided on a compromise: a gas-based model of pressure and throughput. No need for a full-on fluid simulation that would take me years to debug.

Major changes:

• Instead of teleporting fluid from machine-machine via a pipe, dump the fluid into the pipe on one tick, and dump it out on the next tick. 
• Give each pipe a maximum capacity based on its size. 
• Give each pipe/machine connection a maximum throughput.

Much like actual gas pipes, all we care about are the nodes where things connect, and the pressure of the whole system. So this is already a big improvement, since in the previous version, a player could literally have the entire factory running on one pipe. Now you have to plan the system out better to avoid overflowing a pipe.

Now we can tackle the storage problem. Basically, I need two values for each pipe->machine node: the requested input, and the maximum input. So during a game tick, a machine will first output any fluid it needs to into the pipe's buffer, and then calculate these two values. Next, the fluid manager will add up all the requested/max inputs on a single pipe. Then, we ask each storage machine attached to this pipe to pump out the requested input (if the pipe's buffer hasn't already covered it).

Whew. Now the storage machines only output what machines down the line ask for. 

I had an alternate sketch for storage machine rigs, so let's test them both out.

Seems fine for now. Different machines of the same type could have different stats.

Machine type: Research

The concept here is to have a science-y machine that inputs fluids from multiple sources, consuming and processing them to unlock something in the game. I'll start by making a ghetto research tree with a couple of blank research objects. I'm storing these in plain json just like the NPCs, then reading them in when the game starts. Each Research stores any parents/children it's connected to, its costs, whether or not it's unlocked, and which machine is currently working on it. 

The machine trades the fluid you pump into the npc for research progress.

I quickly realized there wasn't much to do with this concept. I wanted the machine to go through stages of research where it did naughty stuff to the npc in the name of science. The second attempt went a little better.

A bit of a mess to look at, but here's what's going on: Now, a Research has a set of costs. Each cost requires a specific fluid, and a specific condition from the npc in the machine. For example, semen + pain. So once you provide the fluid it needs, the machine will go into shock/pleasure/tickle/whatever mode, and torment the npc to provide the right conditions for the science to be done. You can also see the temporary UI for selecting Research, which details the costs. 

So the machine automatically switches between modes and will poke and prod at the npc in an appropriately sciencey way. When it's done, a notification pops up:

The research doesn't actually unlock anything yet, but it's a good resource sink. Onward!

Machine type: Breeding

Oh boy, here we go. I'm just gonna throw all my thoughts and concerns about this out and see what sticks.

Making actual babies: Will need to actually generate a new npc. That means a name, stats, design, and colors. Presumably, we'll do this procedurally using the stats, design, and colors of both parents.

Gestation/growing time: Obviously the pregnancy and aging process will have to be sped up at all stages, so for the sake of balance/gameplay, let's say we'll trade fluid resources to make this magically happen. 

Pregnancy and birth stages: The machine will have to progress between a set of stages for a complete cycle- ovulation/oviposition, fertilization, gestation, birth, recovery.

Normal pregnancy vs eggs: I want both. Normal pregnancy requires a female (or a womb, at least), but eggs can be implanted in all kinds of places. We'll start with normal pregnancy to keep things simple though. Also, for simplicity, I'm representing birth using an egg for now.

Who's the father? Since semen from many npcs can get mixed, and that makes things extremely complicated, I've decided that mixed semen means that the baby will generate using the mother's stats only. So for now, we're going to assume a "no clear father" scenario, just to make things easier on myself. In the future, we'll figure out how to better pair a mother/father.

Jesus. 

So I've sketched a basic machine that'll take us through the cycles. The BreedCycle object holds all five stages and their associated costs/animations. Once a stage finishes, it moves us into the next. I decided that in order to sustain the Breeding machine, you have to meet a sustained fluid/second cost, unlike Research machines where you can just dump it all in at once. So here's the (very) rough idea:

This part took a while. Each stage needs to progress only if the sustained cost is met, which means it's tied to the game tick (10/second). However, the animations need to play at normal speed, which means they progress on the game update (60/second). There's also setup and ending animations for each stage, so we need the BreedCycle object to know when it's in a main stage, or when it's transitioning between stages, etc. 

At the Insemination stage, a new npc is generated. 

At the Birth stage, it's officially added to the roster.

Randomly generating tweaked stats from two parents isn't hard, but colors? Computers aren't good at knowing when two colors look good together. So after some flailing around, I settled on chroma.js to try to generate color palettes. Here's a set of generated palettes for Pinkie children using a bit of randomness plus some strict limitations:

Needs some work, but we're getting somewhere!

I had an actual-milk milking machine concept sketched, so let's throw that in, make the map huge, and run some full-on tests with our new stuff.

Big ol' janky lewds

Outputting to storage 

Breeding setup 

Trying to fund research 

Placing machines and pipes for research 

All-milk research setup 

Big factory testing 

What's next?

Well, all the planned machine classes are in and functional, if not pretty. There's still a lot to do before prettifying. BUT the way it's going makes me more and more optimistic that my original vision for the game is feasible. I don't know how much of that vision is being communicated to you guys with what I'm showing you, but we're getting dangerously close to having an actual game.

A few things for core functions: I need to put work into different fluid types, so there's a reason to have a bunch of different machine setups producing the different types. Also, I need to break the factory into smaller rooms with specific purposes, not just a big grid. The idea is that you shouldn't just have one giant milking battery of 25 npcs producing milk, but have multiple smaller setups that produce different milk fusions as-needed. 

It's still in the "kinda-playable" state where it crashes unless you know what to click on, so it's not quite worth posting an early build yet. 

Working on Factory takes a lot of time right now, since I'm still building core functionality. My plan is to pull back on development once core functionality is done, and let the artists do all the work. That way, I can focus on SHF3 code without being pulled back and forth.

Next up:

Gonna post some SHF3 stuff. Frankly I'm a bit scattered with it atm so I'm not sure what's making it into this next post. I think it's a good chunk of stuff!

You guys are way more patient with me than I would be and I love you for it. <3