home about the studio about the team luxe game engine

You've successfully subscribed to Studio Any Percent!

Subscribe to Studio Any Percent

Stay up to date! Get all the latest & greatest posts delivered straight to your inbox

mossfield origins - dev #6

residency and power



Powered Residency

From last time, I mentioned I still want to look at power, and finish the residence system.

Today I did just that although I didn't spend much time so power is partially done. The subtitle here is misleading, no residence uses power at the moment...

Residence System Revised

Yesterday I mentioned the residence modifier system tracks a number of beds per residence, and a number of beds used. it didn't track who lived where, just that spaces available would be filled by a request for a new resident.

The second part to implement was "if I have no house for X number of days, I'm leaving...". I started by wondering where to add the state (like has_residence), maybe the Resident system? But that wasn't really ideal. It also doesn't belong on the research center... I don't want one system spread over 3 different systems, so I reset and thought it through properly.

A system in luxe is per world, it knows about all the modifier instances in the same world, i.e, the system knows about all the residences. The Residence system should be managing residence overall, so I rewrote the logic. The residence system now tracks some lists:

  • by resident: which house do you live in, if any
  • by residence: who lives here
  • by location: who lives at this grid cell

Transferring residents

The last one is probably curious, but it's because of the details mentioned in #5. When an upgrade is started, a Construct is built, which manages construction of the upgrade. When that completes, it destroys the Construct and the old Building, then builds a new Building.

The old building actually had the Residence modifier instance... and is now gone. We can't carry state across that way, so instead we pass it through the system by location instead since that's what the system can do easily. This works because the only time we care about removing residents is when the building is actually deconstructed, which is a separate event that triggers unloading the residents and marking them as having no residence.

Moving Day

One factor I added today while there is "moving in day". If you have a resident that has no current residence, and a new one is built, it should automatically assign them (based on the one who has been waiting longest, first). Instead of automatically doing it, instead they're marked as moving, and they're given till noon the next day to get their things sorted. This is also limited to one person per residence per day, so that everyone has a turn to move their things in without pressure.

What that means mechanically is if you have 4 residents and 4 empty houses, they'll each get their own house. I prefer this, but I like the framing of moving day since that's what made me realize it spreads them out....

Leaving Day

It's a sad day, but if you don't provide a residence for a resident within 8 days, they'll leave for good. This is implemented as well now. They'll also kindly finish the task they were doing before making their way to the research center to travel home.

Before moving is calculated, we (currently) just check all residents for someone who doesn't have a place to go.

The residents in that list keep a simple timer, which is checked and updated during a tick:

In motion

The video below shows our very first resident leaving because they haven't had a residence built yet. Note that I set the leave timer to 2 days for the video, 8 days takes a long time...  Also don't tell anyone the cheat to add a resident.

Basic Power Grid

The other factor I wanted to get working is the power grid.

Effectively at the moment there's a Power modifier system, this generates power based on a number of cells. You attach it to a power producer and set the amount e.g the maximum could be 8, because of the 3x3 grid the producer is on, and the center slot is taken.

Then there's a Powered modifier, which is the consumer. The consumer has a cost, and the producer calculates the load being spent and displays it. In the video below, a wood + stone producer are upgraded to higher tiers, which start to require power. Normally, they'd no longer produce until they had power, but I haven't had the producer ask if Powered.on(entity) is true to prevent it. Soon though.

I'm still figuring out if I want it to be strictly limited to cells, e.g one cell = one cost, and producers have a limited load (4 for wind, 8 for wood) etc. I know for sure I'm not going to get into actual kilowatt style display/consumption, simple discrete values fit this game better. I just have to decide whether the consumers on a single tile can exceed 1 cost. So far I did it for testing, but we'll see. I lean more toward simple.

next...

I spent some time on Rest and Social systems today, but it felt like I was struggling to find reasons for it to exist. I think the concepts behind it are vital (i.e being able to fail) but the exact details aren't clear yet. I'll think on it more instead of getting stuck there.

The other part of power is the power line. This extends the reach of a Power building, but not it's load capacity. That means you can use one generator and one power line to power some spread out things, but that's all. I wanna play around with how the power line works in terms of range and whether they stack. As in, build 4 producers and a single power line in the center, like a + shape, which means you have loads of power available there cos the power line pulls from all Power buildings it can reach.

There's still water and food too...