Home
Artists
Search
Recent
Random
Posts
DMs
Tags
Random
Importer
Import
FAQ
Account
Register
Favorites
Login
Factory Progress Update (Patreon)
Content
tldr- skip to the gifs linked near the bottom.
Okay, so. Factory. I have no idea what y'all are expecting out of this first post. This is the result of a few solid weeks of work, after my progress being thwarted early on. I recorded my dev process this time. Dunno if this sort of thing is actually interesting, but I figured it'd be fun to show off a little of the process it takes to start a game from scratch.
// defold -> phaser
First step: learn the Defold game engine. It's a competent and modern engine. Just... three problems. I have little experience with its structure, the all-in-one IDE is impossible to code in, and I'm beginning to realize the Lua is an awful, filthy programming language.
After announcing Factory, I banged my head against the new engine and language whenever I took a break from SHF3. But I made very little progress with each attempt. I just couldn't wrap my brain around all the differences of the engine, language, and IDE. Eventually, I came to a sobering conclusion: even if I succeeded in getting a basic prototype working, there would be no release from this self-created hell. I'd be stuck with Defold and Lua for as long as the game lasted.
Nope. No way. It was time to scrap the pitiful amount of progress I'd made and switch engines.
Enter Phaser 3. I'd dismissed it before due to a lack of features and documentation, but it's improved a lot in both areas recently. It uses JavaScript/TypeScript. Ew. But at least I know how to use those. It links up well with Tiled, the map editor, and the latest versions of Spine, my go-to animation software.
One day in and I'm already far beyond what I'd managed in Defold. Yep. This was the right choice. The performance is a little unstable and there's a lot of javascript bullshit to get through, but I think I can actually make a game out of this.
// tiles
First, let's get a simple tilemap up. The game is tile-based, so everything happens on a grid. The open-source editor Tiled is super easy to learn.
Great, now to get it running in game. The red dots should convert to slots where you can place machines. I'll add some animated mspaint blobs rigged in Spine as placeholders for npcs/machines.
Clicking on the slots adds them to the map. Clicking again activates the fluid particle test. Nice. Well, it doesn't LOOK nice. It's a first step.
Machines should be different shapes and sizes though, not just a square tile. Let's make machines multi-tiled, expand the map, and let you place them anywhere.
Hitboxes also up and working for mouse interaction.
// hud
We're gonna need some UI for this thing to function. You'll need to be able to select things out of a menu, and there'll be an ever-expanding list of machines and tools. Ugh. Making UI in games is the bane of my existence. There's just never a working library for decent menus, and Phaser is no different.
Although now that I look at it... I mean, Phaser is just drawing on the DOM. It's a website at heart. I could just use HTML over top of the game stage, then pull in the HTML elements to set up event listener in the game's code. It doesn't feel like it should work at all but...
Holy crap. I can just make it like a normal website.
That'll do for testing. I'm using Bulma, a super lightweight CSS framework, for basic UI elements. It looks boring, but it's just pure HTML/CSS so I actually know what the fuck I'm doing with it. And it scales for mobile. Factory's UI may be usable yet!
// pipes
Aw yesss, pipes. First up, the pipe tiles.
The player will be making/deleting them by clicking, so each time a pipe segment changes, it and its surrounding tiles need to check what kind of connections they have, and select the correct image (corner, T-junction, straight piece).
It turns out, I can be clever and use a bitwise operation to indicate which directions a pipe connects to. 0000 is a segment with no connections, 1000 is connecting UP, 0001 is LEFT, and so 1001 is a corner piece connecting UP + LEFT. 1101 is a 3-way T-junction. 1111 is a four-way intersection. That number is also each tileset image's id in the tilemap.
Sneaky lil' shortcuts.
Next, the pipes need to be actual game objects that know how long they are, and what tiles they're sitting on. Easy enough. Keep a list of all tiles a pipe contains. Add each new pipe segment to the list of any existing pipe it's touching. If a new pipe segment touches two different pipes, add them together.
Easy!
Now, to let you delete them. The tiles are simple.
Okay, wait. How does the game KNOW when a pipe is broken into two? The tiles display fine, but the game still thinks it's all one pipe. Even if it knows the pipe is split, how does it determine what tiles belong to which side of the split?
Oh! I could just see which tile is touching which in a recursive... endless... loop.
Wait.
Um...
Oh god...
NO WAIT, A* pathfinding! That's a common solution for figuring out areas in tilemaps! And pathfinding will be useful in making laying pipes easier! Problem solved!
Well, I implemented it. Then I realized A* is just pathfinding... it finds the shortest path. It doesn't search out ALL adjacent tiles in a set.
So this is the point where I finally learned about a flood fill. A simple recursive algorithm that emanates out in all four directions from the point where the pipe segment was deleted. Ignore previously-traversed tiles, and lump each chunk of adjacent tiles together.
And there we go. Now we fuckin' know. We're able to accurately split a complex pipe into multiple smaller pipe entities. Good.
Next, we need a simple, universal way to define pipe connections to machines. Pipes will look for these, treat them as adjacent pipes, and keep a list connected Input/Output points for transfering fluids. Simple enough. Let's define machines and IO points in a JSON object. For sanity's sake, a single connection can only be an Input or an Output, not both.
Neat.
// rigs
Let's get a couple of actual rigs together in Spine now. I'm sick of looking at the dumb blob. It'll be smart to hide the eyes, hair, and tail as much as possible when designing a rig. Since every NPC can be put in any machine, if a new character has unique traits, I'll need to add those traits to every single machine rig in the game. Best to minimize that.
Also, I'll need to avoid expensive mesh deformations and large amounts of bones like SHF3 uses. There'll be dozens of machines showing at once. Just use a handful of bones and images for the entire rig.
When we define an NPC, it won't actually have its own game sprite. It's just a set of colors and traits that we send to the machine rig, and ask it to display a character that looks like our defined NPC... who should be in a standard format that all machines can read.
// functions
Time to start making this thing functional.
A Machine has one or more basic Functions:
- Milking
- Refining
- Storage
- Research
- Breeding
Luckily, I wrote out the entire design document before starting to code this game, so I already know what all of these entail. The Machine Function will act on the NPC in the machine. The NPC will then produce an output.
Milking will pleasure the NPC. When they orgasm, the resultant fluid will exit via the IO point we defined earlier. There's a lot of work needed to make this happen though. Mainly, we need the Machine and NPC to be separate objects, but both still use the one animation rig. So let's define all possible animations and reactions in the Machine's data, and have the NPC request an animation from the machine when necessary.
Two distinct game objects, one animation rig. It works by having Machine and NPC animations on different animation tracks overlapping each other, but manipulating the same set of bones.
So now that I have a milking machine, I need the pipes need to actually transfer fluids so I can test a refining machine.
// fluid transfer
This'll be the performance killer. We need to keep the number of things the game is doing every frame down to a minimum. First, let's say that the game doesn't need to calculate fluid production and transfer at 60 frames per second. The animations will be at 60 fps, but the player probably won't notice slower game logic in a game like this. Let's do a game tick at 10fps, and do all the machine and functions on that tick.
Now we need to transfer fluids. Machines in this game will push out fluids no matter what. If things get backed up, the pipes will overflow and spill their fluids. So we need to make sure that fluids are moved and processed in the right order, so we're not accidentally spilling more fluids than necessary. If a fluid is moving from A->B->C, then it should go from B->C first to clear up space for A->B. But considering how interconnected things could get, the "right order" is going to be a mess.
Solution: Don't care about the order of machines processed. During a game tick, all machines do their Functions and output their fluids into the pipes. Pipes will buffer the fluids during this phase without spilling. Next, figure out the maximum amount we can currently output from this pipe so we can tell the ratio of buffer : outputs. Now step through every output point on the pipes, and push out the buffered fluid into all available inputs. Tell the remainder to spill out from the IO points.
So, 2~3 steps. And we don't have to go over every IO or every machine multiple times per tick. This should reduce the threat of there being lag every tick. I feel like there's still a lot I can do to pare this process down though.
After a day or so of bugfixing, it's time to test it out.
Aw yeah. The refining machine is receiving the fluid outputted by the milking machine.
// putting it together
Now, the refining machine needs to pump fluid into the NPC and inflate them. Over time, the fluid inside the NPC will refine into a new fluid type, and pump out. Let's ignore fluid types for now and just get the fluid functions fully flowing.
Note that we're treating fluids like a pressurized gas: instantly and evenly pumping it from pipes to all available outputs. This might change in the future.
Machine A inputs, inflates the NPC, slowly refines the fluids, and pumps it out into Machine B. Good. Gooooood. Now let's test it out with more machines.
It works :3
But the refining speed is too slow to inflate a pony with already-refined fluid. We need more refining machines all feeding into a main pipeline that'll deposit refined fluid into one pony. Let's expand the test map and try one last time.
It worked! The pink pony in the bottom right is now filled with refined fluid. And it was actually kinda fun to try out a couple different layouts to get there. This has a glimmer of the game's concept shining through. There's a lot to do still, but damn, it feels good to see things come together.
// final thoughts
I'm excited. Obviously, there's no "point" yet. But there's already something awesome emerging- the ability to express an idea through gameplay. Done right, this game could be pretty cool :3
I want to let everyone test this out. As soon as it's not broken, I'll post a build. The usability is pretty bad still- laying pipe is a chore, deleting machines is buggy, spills aren't displaying yet, the ui is unclear, etc.
Okay also. After playing other building games, it's clear that this needs some more building convenience features. Factorio has a lot of little tricks I'll need to steal.
Once all five machine functions are done, the pipes are improved, and the map is broken into distinct rooms, I'll be ready to hire on some help and spruce up the visuals. Then things will get really fun.
That's all for now!