DarkStarlike

One of the kinds of gameplay I like is base-building - or, more accurately, house-building.

I really liked The Sims, but the focus on it being a time management game always wore on me. I didn't like that mechanic, especially since it punished building large, beautiful houses and rewarded building cramped little zig-zag houses. What's the point of building a house if you're going to be punished for building a nice one?

I've always wanted to do the opposite: a game where time isn't short, but long. I became interested in facilities that are inhabited. Really lived in. The exact opposite of The Sims, it's a game where you build your base specifically to keep your inhabitants happy in the long term, as they live in it for days, weeks, years. Not "how efficient can you make it", but "how long-lasting can you make it", both in terms of mechanical components lasting for a long time and in terms of keeping the inhabitants happy with their daily lives and interactions as time wears on and on.

That's why my most recent prototype is codenamed 'Dark Star'. If you haven't seen it, Dark Star was made before Alien, and then the script was reworked and refilmed and called "Alien". It's about a crew of a deep-space mining vessel, as time wears on them and they are harassed by an unimaginably stupid "terror". Unsurprisingly, since John Carpenter directed both, it also has a lot in common with The Thing. But the focus is less on the alien terror and more on the steadily unraveling humans stuck in isolation for years at a time. And it's also a comedy, rather than a horror movie.

Any way you cut it, the difficulty of this concept as a game is how you model the inhabitants. Their behavior has to be simple enough to be meaty, but also support the steady unraveling and social pressures teams suffer when isolated for long periods of time. This is doubly important for my needs, because the game is intended to allow you to leave ships in various places and use them to either gather scientific data, materials, or hook up with other ships later and serve as supply points. There's going to be multiple ships out in the universe, so the modeling has to be something that the player can grasp relatively quickly. They'll have forgotten the precise details of what's going in ship 1 when they're flying ship 9.

I thought about it a lot, but I couldn't come up with a very good mechanic. They were all really "The Sims"y, based on needs and proximity and so on. It got complicated, because you had to do things like assign rooms and jobs and manage shifts so that people would encounter each other - just a huge headache. I needed something that would run in an obvious manner at high timescales, as well as be easily and deeply modified whenever you wanted.

So, here's the simple idea:

The ship is a grid. Each inhabitant can be "posted" at one particular grid node. However, that's not their physical position: we don't actually care about their physical position for our simulation (although we do care about it for visuals). From their post, they project a "+" pattern - a beam in each orthogonal direction. All the tiles their beam hits are tiles which concern them. Those are the tiles they use or maintain day-to-day. So it should obviously include a place to sleep and a place to eat and a place to relax, whatever you can manage... and it should also hit the facilities they are responsible for repairing or using. The "+" pattern has no end - if your ship is 500 tiles wide, they will be concerned with 500 tiles horizontally (and howevermany a vertical slice is, as well). So larger ships allow characters a wider variety of facilities... and a much heavier maintenance duty, if you aren't careful.

In terms of maintenance, it's best to have enough sailors to cover every single tile. Tiles that aren't covered aren't maintained. For some tiles, that's okay. But most facilities need maintenance. Similarly, a work station means nothing if nobody works at it.

In terms of socializing, when two beams overlap that's a social encounter that the characters will have regularly - maybe not every day, but fairly regularly. The kind of social interaction depends on the kind of facility at the overlap. So if they overlap at a mess hall, they tend to eat lunch together. Characters aligned diagonally will always interact at precisely two points, so you can control what sort of interaction they have and what kind of social sustenance they provide by carefully choosing which points you interact on - if both points are the same kind of interaction, it's much more powerful but also much more limited.

On the other hand, inhabitants can also be aligned on the same beam - either horizontally or vertically. (They can't be on precisely the same space, though.) In this case, there are a massive number of overlaps: every single tile along that axis. This can be a very powerful way to create plenty of social interactions... but overloading is often worse than going without, so care needs to be taken.

The core idea is that the characters have particular social characteristics and needs. Each character is probably marked by obvious appearance characteristics as to what sort of needs they have - otherwise it would be a bit difficult to tell quickly enough for my taste. You could replace that with a series of floating icons or something if you really want to avoid stereotypes, but I was planning on using floating icons for what their actual state is. Requirements/tendencies are different from actual state.

Then it's a simple matter of calculating from their various activities, and moving from your current state towards the calculated state by some amount per day (10%?).

The most basic element is your personal needs. You need a bedroom, a washroom, and a place to eat on your beams. If you don't have them, you'll quickly get annoyed. If you have extra good ones, that might help to blunt your mood swings! However, this is just a very basic baseline. Things get more complex from then:

You can calculate interpersonal interactions by simply looking at all the places your beams collide with other crewfolk's beams. This is a social interaction, and of the type the room specifies. The bad news is that this isn't scaled. On a ship with, say, 100 crew, you'd probably have 198 interactions, assuming none of the other crewmembers have the same X or Y coordinate as you. (There are ways to build a ship where the intersections happen in empty space or on incorrect job rooms, which can lessen that, but in general it stands.)

This is made much worse when someone shares a coordinate with you, because they'll overlap on around half of your rooms in most cases, meaning you can easily rack up the width or height of the ship with interactions with that one person.

Individuals can blunt this automatically, however. Any room they touch with a beam that nobody else touches with a beam is considered personal space, and they can use it to avoid 1 interpersonal interaction. So if I have 8 interpersonal interactions and 4 personal spaces, I can negate 4 of those interactions - and I'll automatically negate the ones that are the most problematic for me. If I'm not overdosing, I don't need to negate any of them. This doesn't mean you don't meet up with the other person, it just means that you also spend some time alone.

Obviously, if someone shares a coordinate with you, then all the rooms on that axis are going to be shared rooms because they have the same beams as you. This means that it's going to really limit your personal space.

The other kind of social input is the rooms you touch - shared or otherwise. This really only matters in small ships, because it's capped. If you touch three rooms, they'll each give you 33% of the social input you would have gotten if someone interacted with you there. But if you touch 100 rooms, you only get 1% each. So, as the ship gets larger, the contributions trend towards a very low baseline.

Some rooms count differently depending on your skills/job/tendencies. For example, a medical doctor isn't going to get any benefit from a deep space scanning room, and a astrophysicist won't get any benefit from a med bay... even if the two overlap on it and theoretically have a social encounter. It just does nothing. So it's critical to have a very quick and easy "read" of the situation, which is simple enough. Just color and mark the beams, and estimate the social situation for the crewmember a few weeks into the journey.

As the journey wears on, that might change. People's fundamental tendencies slowly drift out of kilter based on their long-term actual states. But it's a good enough estimation to keep a newbie in the game and not terribly confused. We can also implement some kind of actual relationship growth as well, if we like, which would further drive them off kilter - probably mostly driven by someone having lots of the same kind of social interaction with you.

All told, this system should make it very easy to estimate how people will interact socially, while also linking everything to a fun and complex space station/ship game which lets you build, leverage, launch, and reuse ships. It seems like a fun combination of managing social topology, work, and ship maintenance. Rather than being about dealing and repairing damage from space battles, it's all about trying to create a ship that operates well for extremely long periods of time, including when damaged or on the fritz or a crewmember is sick.

Anyway, I'll go ahead and program it some more.