⭐ Forensic Friday 23: Conquering Pipes!
Welcome everyone to Forensic Friday 23! In the red corner is…. the forbidden pipes! Very scary! But the good news is that we have figured out a unique method of doing pipes that seems to work very well! …and in the blue corner is scientists & research (geez again). Well to cut a long story short, pipes KO’d first round. Though scientists are on their way to becoming a champion. More about both contenders below
That which should not be named #
Pipes… such a small word that has caused a lot of pain and suffering for us. In our plight to make an intuitive model for fluid dynamics, we had problems with edge cases with previous designs. A keyword before I continue - “fluid holder”: any entity that can hold fluids (duh?) such as a pipe or silo storage. Previously, our flow model was decentralised (it still is but more on that later). Every fluid holder took into account the difference in fluid amounts in adjacent fluid holders. Depending on this difference, a fraction of this difference would be transferred from one fluid holder to the other, so eventually they should balance out. The keyword here was should. While this worked perfectly for uniform layouts, where all the fluid holders were the same type - had the same capacity etc, there were a tonne of edge cases that just didn’t work. Since fluid holders only knew about other fluid holders they were connected to, this caused problems where mixtures of storage silos and pipes would not distribute fluid as expected, since there was no way for a singular fluid holder to know where pressure was coming from.
Later attempts led us to trying to create a pressure system, so that along side fluid volume, fluid holders would also have a pressure amount that could help us to fix these issues. However, this felt more like a hack, and again, numerous edge cases made this infeasible without making our model even more complex.
So What do other people do? #
Looking at ways that other games do this was a research task in itself, and none of their models had the behaviour that we really wanted. For example, Factorio (according to their wiki) works on percentages - source: Factorio Wiki.
Meanwhile, some other games don’t have a flow model, instead fluid amount is a constant across all connected fluid holders, relying on a centralised system to handle this. While both of these would suffice, and no one would probably complain, we really wanted a system that did exactly what we imagined. And it seems that we have a cool idea that seems to be working.
The New System! #
Example of Cellular automata evolution. Source: The cellular automata model of sound propagations and its application in structural noise calculation, Kun Luo, Zhenguo Wang, Xiaoyan Lei
So now we’re all caught up. Funnily enough, this was one of those things where the idea took 99% of the time, and implementing it has been fairly quick. Our whole idea is based around cellular automata. This is where a grid of “cells” have simple rules and about where they can move, famous examples being Conway’s Game of Life or Rule 184 Automata. Each fluid holder has a cellular automata inside of it, represented as an array data structure wise, where each cell contains either nothing, or a fluid type (e.g. water, sewage, oil… you name it). For every cell, if one of it’s random neighbours is empty, and itself has a fluid type, then these values swap. If specific cells contain a fluid type, then they can transfer their content to an adjacent fluid holder. This random approach works wonders, where there are 0 edge cases since a larger storage amount just has a cell automata with more cells, and results from only a few hours work seem very promising where it’s almost finished.
This also allows us to now implement fluid mixing, whereas our previous model only allowed 1 fluid inside a fluid holder at any one time. We have yet to decide whether fluid mixing is something that we want in the game, since it could be annoying for a player if a fluid becomes contaminated by mistake, but that’s something that’s easily fixable if we need to remove it. For now, fluid mixing is a thing, and it works fine, and can cause some interesting gameplay aspects - you probably don’t want sewage coming through the kitchen taps
What’s Left? #
So after a lot of theory, back to a more high level look at what’s left. We need to tinker with the rules of our cell automata so that fluids can flow “better”. This is slightly subjective but there are aspects that I want to improve so more testing is needed! As well as this, powered fluid holders such as pumps are a previous mistake that needs fixing. We have a base script for powered items, and a base script for fluid holders. Since a pump can’t inherit from both of these, we decided that it should inherit from power items. Therefore we need to create an interface for entities that don’t inherit from the fluid base script so that they can still interact with fluid holders. For now though, take a look at a time-lapse what it looks like currently!
Nice speed up time-lapse of water propagation (still a few kinks that need ironing out such as speed of flow)
Scientists Come to a Close #
Jumping briefly over to the research system. It has been a slow slog. Though, the slog is almost (and I really assure you) over! Researching actually works now! As in, experiments are archived, and then research progress is made via Lab Processing. What is lab processing you may ask? Well after completing experiments, a scientist creates a report. They carry this report to a cabinet laboratory. Once it is inside the lab; if scientists are working in said lab, and doing research; that experiment will also get researched. Each experiment has a certain maximum amount of research points it can spit out, including some trace research points (which take considerably longer to produce). So after some time of researching, you gain various types of research points that you can then spend on the tech tree :O.
Looking Forward #
All that is left is to make a simple framework for the Tech Tree. (This would be GUI-less because I can’t take Unity GUI framework anymore and we are planning to eventually start using XML-based UI frameworks :O ), and to make things savable! Then it’s on to….doing a bug-fixing run, and small gameplay features, then…security NPCs (…and that includes something we have been waiting to do for a long time BALLISTIC Mechanics. Guns, armour and blood! This also includes an upcoming rewrite/refactor of the health system. We have a lot of exciting ideas for that one.). Expect this to happen around Forensic Friday 30-40, if we maintain a good pace! Also take a look at this stupid bug I encountered whilst working on research things. Possible first entry into Bug of The Week?
Damn, he can carry a lot
Case Closed #
That’s all folks, archiving the case now. Next week, expect pipes to be finished! Experiment system will very likely be finished also, so on to newer more exciting things! As the weeks go buy, everything gets a little easier, which is a good sign. The horizon is quickly approaching and the game being playable feels only a few steps away. Perhaps rather large steps, but a countable number at least!
TL;DR: Pipes conquered, guns on horizon.