Friday, September 19, 2014

Generating Playable Star Trek Plots

I've talked about creating science fiction tabletop games, using the example of Star Trek. One of the things that comes up a lot whenever you do this is how you can create enough MEAT.

Fantasy games have grown a kind of plot progression out of long practice. Fantasy stories you read in books don't have the same pacing at all: a fantasy game features a huge amount of content that would give an editor fits. Dozens of pointless fights, considering which sword to buy, exploring each dungeon room one by one... this is the meat of a fantasy game.

If you've ever tried to run a science fiction game, you probably noticed that it was pretty hard to get enough meat. The plot either felt full of filler, or moved too fast. That's because you were probably using the same structure as a fantasy game. Science fiction plot lines can't really support that - there's no monsters to slay, no real advantage to exploring every room.

Science fiction plot arcs require a different approach. And we haven't really figured it out, because we haven't spent forty years perfecting our craft.

But I do have a guide that might help. Here is my guide for creating science fiction arcs that last 1-3 sessions - "Star Trek" plots that play nicely and have meat.

The Noose
The players always need to be under pressure in a science fiction plot. Players used to a fantasy plot know enough to move the plot forward even with relatively little pressure, but nobody is that used to science fiction plots yet. The noose is a crisp and looming deadline to force them forward.

Nooses should have a concrete time span and failing to deal with them is the lose state. Players might be able to push nooses back, but they can't ever reduce the noose's effect. The noose is all-or-nothing, high-stakes. The situation may also get worse as the noose approaches, but the noose is specifically the looming deadline.

Noose examples include: the disease will kill everyone on the planet in 2 days. The Klingons will declare war in a month if you don't find their lost ship. The vote happens tomorrow and the majority of the senators are planning to vote "no". The space wedgie will cause life support to fail in six hours.

Personal Mire
My planned gameplay revolves around people, and therefore the NPCs need to be the terrain of the game - half like a dungeon map, half like a monster fight. To make this easy for the GM to plan out without needing a ton of advance work, I recommend "constellations" of NPCs - groups of NPCs that are related to each other around a specific topic.

For example, the "impending new order" constellation would feature characters from the old guard and the new order and some conflicted bystanders, and their relationships would be clear. You could leave most of the characters in the wings until you need them, not bothering to create any details until you need them to play a role.

The idea is that any given NPC would belong to two or more of these constellations, and their motivations would intertwine. This adds some complexity to the things the players do, and create some nice terrain for them to be wary of. It also creates a lot of hooks that are easy to turn into complications, twists, and major NPCs.

Complications
Normally, solving the noose is pretty straightforward. If there's a disease, you need to research the cure. If there's a lost ship, you need to track the warp trail. If there's a vote, you need to convince people to vote your way.

Complications are what make the situation a lot more difficult - they are reason that the actions that should solve the situation either can't be performed or produce a bad result.

Complications usually give the noose emotional resonance, and should generally be themed to give a strong, unified feeling.

For example, the disease turns out to be a nasty engineered bioweapon, which makes curing it much more difficult. The next complication might be that the weapon was created by the locals, and they don't want that revealed and certainly don't want to help you fix it. The next complication might be that the creators died of the disease and can't help. These complications are loosely themed - they're about plans going awry, smaller evils blooming into larger ones.

Other Examples: The Klingon ship was kidnapped by a space godling. The senators you need to convince are stranded on an ice planet. The space wedgie is making time judder backwards and forwards randomly.

Twists
A twist simply changes the lose state. It either replaces the noose with a new noose, or it reverses the noose so that your efforts have been working against you, or it makes everything you've done feel very different now that it's over.

Examples: the vote needs to fail to keep their society stable. The "missing" Klingon ship is an ambush. The space wedgie was trying to protect you from a warp core breech.

Twists don't need to be clever. This is not about creating clever plot lines - it's about creating meaty plot lines. The twist either adds more meat, or makes the meat you already ate taste funny.

B-plots
The B-plot is actually an integral part of science fiction plots, although it may not be immediately obvious. See, the function of the B-plot is to create emotional resonance with the primary plot.

Most science fiction primary plots are about something big - a starship, a disease, a political movement. But in the end, the plots are an excuse to show how people live and act in those situations. The B-plot is the easiest way to lure the players into that kind of close emotional connection.

The B-plot is often "unrelated" to the main plot, at least in terms of causality. However, it reflects the human judgments and lives of the main plot. So, your B-plots should shadow your complications and twists. Since your complications and twists should be loosely themed, the B-plot will likely match many of them at the same time, and offer a human window into a world of big things going wrong.

Typically a B-plot is introduced before the first complication - often before the noose. It exists first even though it is an echo or window onto those larger events.

For example, if the vote is being screwed up because the senators are stranded on an ice planet, you'll start off with a B-plot that plays with that. Perhaps it's about planning a vacation, or the life support going on the fritz, or being unable to get off the ship, or having family visiting.

If the twist is that the lost Klingon warbird is actually waiting in ambush, the B-plot might be about your Klingon crewmember being proud of his culture's obsession with honorable combat, or it might be about an officer training test where everyone dies in an ambush: the Koboyashi Maru sequence. B-plots don't have to be clever or hard to connect.

However, B-plots do have to offer some meat. Think of them as a sequence that doesn't require the GM: when the GM is busy with a particular player, this is something the other players gnaw on.

Therefore, the B-plots should be things where the players can spend some time expressing themselves or their characters, and should involve some die rolling or content that A) doesn't require the GM and B) dictates how things go for them.

For example, the Koboyashi Maru B-plot. It isn't just a line you feed them. You say "this is an officer test." You walk them through it once or twice. But there's a table of results - if your leadership is this, this happens in the first segment. Roll weapons fire, check to see what happens in the second segment, and so on.

A concrete reference as to what can happen lets the players compare their performances to each other, and makes it easy for the GM to give various bonuses or penalties according to their efforts without having to spend a lot of time thinking up new things.

In another example, if the B-plot is that someone's family is visiting the ship and being annoying, assign a family member to every other player. Now whoever is free can be an annoying family member to anyone else who's free. Moreover, you can also get incidental synergy - if the same player is playing the goofy father and the lead starship engineer, then the goofy dad and the engineer get along oddly well. That's fine.

The whole point is to offload the content creation to the players. You need to seed it, of course - tables, NPC character sheets, whatever else is needed. But then the players run with it, try it in different permutations and different places. This lets them control the pace of the play rather than dumping it all on you, and is similar to how fantasy players might mull over what powers to buy on next level-up.

B-plot participation should be worth XP and/or in-game resources. The people who do best at Koboyashi Maru get a commendation point, for example.





Anyway, those are my thoughts.

Tuesday, September 16, 2014

Star Trek Tabletop Musings

I wrote a really long essay on mechanics inspired by my last essay, but it was too cumbersome to read. So let's talk about a Star Trek tabletop RPG, and I'll hit the same points with a clear example in mind.

Firstly, there's the concept of "class". Nearly every tabletop RPG has the concept of "class", because it's easy for the players to understand and the devs to balance. The issue is that some classes unlock new types of play: for example, only a magician can use spells, only a hacker can hack computers, etc.

Classes like "mage" and "cleric" are pretty seamlessly integrated into fantasy worlds because their abilities let them participate in the basic gameplay (fighting). A mage really sucks at fighting, but they are capable of throwing artillery fire into the mix.

On the other hand, classes like "hacker" are not integrated into Shadowrun very well at all, to the point of GMs just often just handwaving them as NPC-only classes. This is because the added gameplay - hacking, psychic stuff, and piloting - cannot easily integrate into the basic gameplay. A hacker sucks at fighting and has no easy way to contribute to a fight.

But hacker and pilot could actually be integrated into combat a lot more powerfully, and Shadowrun is slowly drifting that way. Use small combat drones, or perhaps live-tweak an allied cyborg to get every once of performance, or screw up enemy hardware, or create holographic illusions, or program heuristic nets in real time to predict and counter enemy actions.

Anyhow, our very first step is to make sure that all our "classes" can participate in our core gameplay.

...

... Our very zeroeth step is deciding what our core gameplay is.

Star Trek is not about combat. It's about seeing new things and meeting new people, and the conflicts that can arise. It's about finding common ground with aliens, no matter how odd: there is no "other" in Star Trek, no faceless masses to gun down. There are counterexamples, but those are usually from later on, after the series began to seriously decay. In the early days, even aggressive enemies like the Klingons were treated like people who didn't like you, rather than dangerous things you needed to kill.

As mentioned in the last essay, science fiction is about the life of people in the universe rather than about proving your own mettle. Therefore, rather than combat, we need the opposite: unification. Consensus. If D&D is like Pac Man, Star Trek is like Tetris. Rather than our basic action removing pieces from the board, our basic action needs to move pieces into alignment.

This also works well with the original combat of the series: it was u-boat combat. Submarines maneuvering, searching for each other in the dark. Pitched battles were rare and both sides usually came out pretty badly.

Unifying the pieces is a fun thing to consider, but we need to consider how that actually works. The advantage of a combat system as the core mechanic is that the GM can add and remove pieces pretty easily, without drowning in complexity. The plot of the D&D arc typically has very little to do with the combat, aside from maybe determining which pieces are involved.

But if we're unifying a large group of pieces, that means the GM is responsible for coming up with a lot of pieces, and setting them up strategically to offer a challenge.

We're not talking about a puzzle game with an optimal solution, but we're still talking about a game where pieces are related in a much wider variety of ways than "ally/enemy". The wider variety of options means that the GM needs to do a lot more planning.

Let's assist.

Instead of thinking of each individual person as the same thing as a monster in D&D, instead consider specific "constellations" of people.

Adding individually would require something like choosing to add "Renault, the old-guard dignitary", then deciding who he is related to in what ways. Instead, we would have a "government in transition" constellation which would have several people stock - the old-guard dignitary being among them.

There are two keys to this approach.

The first is that a person can be in multiple constellations. Renault might be the old-guard dignitary from the "government in transition" constellation, but he could also be part of the "corrupt medical industry vs the plague" constellation, or "industry vs preservation" constellation. Which roles he plays in those will inextricably link the old guard to those topics, and add a lot of complexity to the situation.

The second key to the approach is that the GM doesn't have to preplan everything. The players don't meet everyone at once, and there's no reason to add them all into the game at once. The GM can use our "constellation" system to roughly plan out a scenario, then introduce characters as they are needed. The GM will always know what characters remain "in the wings", and can pluck out various pieces as needed to make the adventure more interesting.

This sounds a bit dry, perhaps, but it's the same as talking about how GMs might populate a dungeon with monsters. There will also be various setpieces and named characters, but it's a different topic.

...

The stats and classes the player chooses are important. Let's start with stats.

We want to choose stats which create the Star Trek universe's unique flavor. Basically, if people can be good or bad at something (a stat), then that thing is going to be very important to our setting.

"Piloting" wouldn't be a stat, because only a few people pilot at all. Similarly, "strength" is a bad stat because it almost never matters.

"Combat" would be a good stat. Spock and Data have very high combat stats because of their species. Kirk has a high combat stat because of his training and build. Bones has a very low combat stat. This variation in skill creates variation in results - not just winning and losing in combat, but whether combat is a route that can be considered. Even if there is no combat, the act of avoiding combat is gameplay in itself.

"Intellect" is a bad stat, because it's too vague.

"Expertise" and "Theory" are good stats, instead. Expertise covers your ability to work with complex technical systems such as repairing starships. Theory would cover your ability to do things in your head, like math, history, or tactics. Theory would probably cover medical expertise as well: Star Trek considers it almost a humanities job rather than an engineering job. So Bones and Crusher would both have a high theory stat, but a mediocre (Crusher) or abysmal (Bones) expertise stat.

We would need a variety of social stats, because a lot of the challenges will be social.

"Leadership" wouldn't be as limited as in most games, because you have a lot more allies than in other games. The engineering staff follows you. The ally you made by rearranging pieces counts. So leadership could be used to move allied pieces faster, further.

On the other hand, "Negotiation" would be how well you could affect pieces that aren't your allies (or aren't operating in unity at the moment), and visa-versa. So Kirk would have a high leadership, while Picard would have a high negotiation.

Lastly, "privilege" is a good stat for us, reflecting a combination of rank, self-assurance, and backing. People with higher privilege can act much more outlandishly and be forgiven more easily - it's our version of charisma. Even when in trouble, Kirk's high privilege meant he could continue acting like an ass and eventually he'd be back on top. On the other hand, Worf has a very low privilege, and therefore he gets stomped every time he steps even slightly out of his comfort zone.

Privilege is an unusual stat, but it helps to define the universe of Star Trek. It's especially important in NPCs, as much of the behavior of guest stars is dictated by their privilege. It gives the universe that slight "dystopian bureaucracy" aftertaste that it often carries.

We could use these six stats: combat, expertise, theory, leadership, negotiation, and privilege.

With those in mind, we can discuss classes and species.

For example, Vulcans and androids have significant bonuses to combat, expertise, and theory... but they have significant penalties to leadership, negotiation, and privilege. (Vulcans like to negotiate, but they're really not very good at it.)

Betazoids have empathic powers which, among other things, radically increases their negotiation and privilege - perhaps balanced by a loss of theory or expertise.

Klingons have a bonus to combat and leadership, but a penalty to theory and privilege. Their low privilege is their adherence to their own aggressive, weird culture - it doesn't mean they blend in. Their aggressiveness is a fish-out-of-water issue, not a high privilege.

Classes could start simply as the branch you choose. Command-branch characters would obviously focus mostly on leadership and negotiation, while engineering-branch characters would be mostly expertise and theory. Security-branch would be combat, leadership, and expertise, etc. Rather than granting bonuses to these stats, they would instead require those stats for their class abilities, much as a a magician has a high intelligence but being a magician does not increase your intelligence.

But... what's the grist between the stats and the conflict?

...

Every decent RPG has "grist". This is the stuff that lies between the stats you chose at the beginning of the game and the actual die-rolling you do while playing. In D&D, the grist is mostly inventory selection - getting the gear you want, choosing the spells you want, and so on.

Those things are enabled by your stats, and then you use those things in combat. Your direct action is to swing a sword. You have a sword because your strength is high and warriors get weapon feats. But you don't "roll strength" against the enemy, nor do you simply rub the number of weapon feats you start with on them. You choose a specific weapon and a specific feat, and apply them at specific times.

In our Star Trek game, we're the same way. Except that we don't care about inventory at all. Captain Kirk does not have a different phaser than Scotty.

Our grist is made up of interpersonal stuff.

Rather than choosing a sword or an ax, Captain Kirk chooses a threatening or gentle approach. Like choosing a sword, Kirk cannot easily change tactics - it'll screw up his rhythm and make the target think he's unreliable and weird. "Why's he acting friendly/unfriendly all the sudden?"

Rather than choosing four spells from a spellbook, Kirk will choose four techniques he excels at. Some might be based on his authority as captain: the threateningly low orbit, the photon torpedo spread, the surprise teleport. These are things he can use without "owning" the abilities, but the abilities make them fast and effective.

Some of his abilities will be based on Star Fleet authority: offering technical assistance, threatening with regulations, setting up trade agreements, having crimes dismissed, etc.

Some of his abilities will be personal: the two-handed chop, dressing everyone up in local clothes to blend in, seducing the locals, monologuing.

Everyone gets abilities. Some are species-related, like the Betazoid empathic power, the Vulcan mind-meld, or the Klingon berserker pain resistance. Some are job-related, like the time-dilation powers Scotty has or Bones' tendency to put people on sick leave. Some are personal, like Riker's charisma or Geordi's visor. Some are based on cultural or social authority, such as Picard's reputation or Guinan's knowledge of everything everywhere.

And a vast number of them are just personality traits like arrogance, loyalty, racism, etc.

All of these "abilities" are a bit different from abilities in D&D. Rather than being permanent additions to your character, they are more like equipment. The player will switch them out whenever it seems like a good idea.

Similarly, traits like "arrogance" are not just a flat role play guide. There are hundreds of things that could be called "arrogance", just like there are hundreds of variants on "short sword". It's possible to refine your arrogance infinitely, and eventually end up with the Star Trek version of a short sword +3 flaming +5 vs ogres. Something like "arrogance about job (+2) and ship (+3)".

Sometimes your abilities will fail you or vanish - just like a sword can critically miss or you can be disarmed. Some are more permanent, like Geordi's visor. Some are quite malleable, like whether Bones feels argumentative this week.

And, yes, sometimes you'll gear up with specific abilities when going on a mission. Kirk can decide not to bring his arrogance along this time, because it'd make the situation worse. He's still Kirk, he's just trying to be less self-absorbed today. If that doesn't work, then he can spend the next time he's alone for a few hours to reconsider his approach.

That's the key to enjoying this game. Your characters' personalities are not some monolithic obelisk. This is about interacting with other people, understanding them, and working with them. Like in real life, your personality isn't always raging out of control.

...

Mechanically speaking, the game works something like this:

The GM comes up with a scenario intended to last 1-3 sessions. The players participating place their 'business cards' (note cards with their character names) into the center of the table.

The players explore the situation by free role playing, and while that unfolds the GM places business cards for each NPC and unfolding situation they encounter. For example, if you reach a high-tech but non-spacefaring planet where there is a disease raging out of control, the GM will place the disease as a card, as well as the various individuals the players meet, such as the planetary governor, the lead medical researcher, and the man dying of the disease. As time passes, the GM may add the military commander, robot police forces, and an oncoming hurricane.

Cards that are neighbors long-edge to long-edge are tightly allied (or being watched) and within shouting distance. Cards that are aligned on their short edge are more loosely allied. Note that tight allies chain - a giant stack of tight allies are all allies with each other. But loose allies do not: you can never be loosely allied with more than two people.

This is a player-focused arrangement, so if there is hidden information that only the GM knows, it doesn't have to be reflected in the cards until it is revealed. Of course, since it's player-focused, much of their efforts will be to align these cards to suit their needs.

Sometimes this is easy: if two players want to team up, they just agree to do so. Assuming no NPC or situation interferes, it's just a simple bit of free role play and the players' cards butt up.

Similarly, moving your card out of alignment is easy - going off on your own, breaking an alliance. It's just some free role play and you can move your card. But your erstwhile allies might not take it well, depending on the situation.

The real challenge is when you are trying to align yourself with non-player cards.

Bones wants to check out the disease, so he decides to move himself vertically with the disease. This doesn't mean he's allied with the disease, it just means that he's going to be in the midst of it. To do this, he'll need to explain how he's finding infected people.

One approach would be to talk to the lead medical researcher. Another would be to talk to the man dying of the disease. If they are okay with it in free role play, then Bones can be led to the disease and hook up with it without ever needing to leave free role play.

But there is plenty of strife. The dying man doesn't want to talk, and the researcher says it's too dangerous to expose him to. Now what?

One option is elbow grease. Bones can strike out into the city (perhaps with some friends) to search it manually. This is a shift action (~6 hours), so Bones expects it to take a while.

If Bones can use an ability to help out, this stands a pretty good chance of working. If he has a specific kind of medical scanner ability, that'd be fine. He could also use a less specific ability - such as medical intuition or intent to help everyone. The downside of the broader abilities is that he must have them equipped to use them, which means they can be used against him by the GM later on. It's much harder to use a medical scanner against you.

Bones has to roll against a particular target number on a D10. This number can be higher than 10 or lower than 1, but you may still want to roll, because the amount of failure or success matters.

Each point of success or failure can be spent to reduce the time spent or to increase the result's effect. If Bones succeeds by only a little, it could take him 6 hours! But if he succeeds by a lot, it might take him only a few minutes, or maybe he discovers a massive number of sick folk.

If Bones fails, he'll get in trouble. There's no such thing as "merely failing". If he fails by a small amount, he'll get arrested after 6 hours. But if he fails by a large amount, he might get shot after only a few minutes! Bones chooses how to spend his failure points, and he has to decide whether to fail fast and harmless, or slow and painful. Failing slow is really useful, because that means someone can interrupt his search before he actually gets caught, essentially negating the result at the last second. This requires that person spend "convenience points", but it's better than getting shot.

Anyway, that's if Bones has a suitable ability. If he doesn't have any suitable abilities, he can fall back on pure stats - probably privilege or negotiation. This may or may not succeed, but either way you ALSO fail by the exact same margin. If you roll a 3-margin success, you also have a 3-margin failure. If you roll a 3-margin failure, it's just a failure. This is the punishment for over-reaching.

Let's say Bones doesn't have any suitable abilities, but would prefer not to risk the automatic failure. So he instead chooses to win over one of the people who might be able to help him.

Let's say he chooses the lead researcher to buddy up with. He could also tail them, threaten them, etc, but let's say we're going the friendly route. The goal is to form a loose alliance (short edges of their cards butting up). The lead researcher is pretty antagonistic at the moment, so this might not be easy. How to accomplish it?

"Form a loose alliance" is a specific action, and there is a specific set of approaches to doing it. The negotiation stat is usually the backbone off this approach. Each time step dedicated to it reduces the difficulty - if Bones negotiates for a scene, he gets +0. An hour, +1. A shift, +2. A week, +3. In addition, he'll want to use an ability, or he'll run into the "autofail" problem again.

Well, Bones doesn't have any real negotiation abilities, and his negotiation stat is rock-bottom. So he has to fall back on privilege, which can always be substituted into these kinds of situations if you don't mind a small penalty. By ignoring cultural and situational barriers, Bones can just hang out with this researcher and try to make friends. Bones has a very high privilege - he's a grumpy old luddite weirdo that everyone loves.

Bones decides to hang out with the researcher for a phase to ally with him.

If this seems too hard, Bones can soften the researcher up by de-escalating. Escalating and de-escalating are important tactics to control the situation without directly moving cards. De-escalation is done by focusing on shared elements and ignoring potential thorns. Both Bones and the researcher are medical, and that means they share a job that relies on theory. Bones can use theory (and, hopefully, some ability) to de-escalate, then use privilege to form a loose alliance.

Even if Bones has no abilities to help with this, he can juggle timing to make it work out. He gets smacked with an autofail if he works without abilities, but that's okay. He'll spend all his success points on lowering the time to success, then spend all his fail points on increasing the penalty for failing. Now he has a few hours between his success happening and his failure happening, and in that space he can take advantage of the alliance.

Well, anyway, that's just a very basic set of ideas. I haven't polished it much.

Friday, September 12, 2014

Science Fiction Games are Different

When we look at tabletop RPGs, we see that fantasy is the most popular. Nearly everyone plays a fantasy RPG. Even famous science fiction games like Shadowrun aren't really that widespread. Plus, it's mostly a fantasy game anyway.

Why are science fiction RPGs less popular? It's not the genre itself - science fiction computer games, movies, and comics are at least as popular as fantasy.

I've thought about it, and I've come up with two big problems with science fiction tabletop games.

The first is that they aren't as easy to imagine. Science fiction games tend to have bigger, stranger things to think about. That means that the player has a harder time imagining them. It's easy to imagine a swordfight, trekking through a bog, sneaking through the dark, or looking out over a mountain range. At the very least, we've played at those things in real life. But it's much harder to imagine rescuing a stranded astronaut or saving the day with a piece of clever code.

These bigger, stranger images are the ones I prefer, and I think a lot of people feel the same way. Although most science fiction fare these days is basically action flick crap with a science fiction gloss, it still has big, powerful imagery. In computer games and movies, it's easy to show these images. An AI flickers into existence. A plague mutates the local wildlife. A gleeful coder hacks a mainframe while surrounded by massive screens. Biological cells bond to plastic, and your eyes reboot into Terminator-vision...

But when you look at a scrap of paper with words on it, those things are hard to portray. If I see a picture of a sword, I can immediately understand everything and imagine going to battle with or against the sword. If I see heavy armor has a speed penalty, I can immediately imagine a slow, armored knight against a fast, unarmored rogue. If I see a castle, I can imagine a siege. Etc.

If I see a robot... the images don't pop into my head nearly as fast. The robot looks cool, but there's no "AND THEN" going on. I don't automatically think about the scenarios the robot would be part of. Same with space ships, cybernetic enhancements, life support systems, computers...

Now, the first thought that popped into my head is that you simply need to be a lot more aggressive. When you describe a robot, lay out a fragment of a scene to give the player something to grip onto. When you describe cybernetics, have an NPC talk about something that happened to them because of the cyberware.

If it's hard to imagine, give the player a leg up. Easy enough!

But... this brings us to the second big problem with tabletop science fiction games.

...

Fantasy games can be thought of as running around in the back yard waving a stick around. Science fiction games can be thought of as running around the house with an armful of plastic toys making "whoosh" noises. As soon as you succeed in landing a plastic rocket on the couch and your action figure gets out to explore the surface of this alien world, you'll understand the appeal of science fiction.

That is, fantasy games are about your personal merits. Your strength. Your cunning. Your speed and willpower. You may use all sorts of equipment, but in the end it's about proving your mettle.

Science fiction games are mostly about STUFF.

Your space ship, your antigravity belt, your supercomputer, your robot arms. And of course, all the other stuff: that nebula, this space station, that mind-control laser, this ancient databank...

"Wait! Fantasy games have tons of STUFF in them!"

Definitely. But science fiction is fundamentally about how people behave when situations are different. The STUFF in these settings defines how people behave, what questions are being asked, and so on.

That said, it's definitely true that there is a vast amount of STUFF in a fantasy game. Massive amounts of stuff. In fact, most fantasy games have more stuff in them than most science fiction games!

Even the giant stack of guns in Shadowrun doesn't hold a candle to the array of weapons in D&D. And it's not just a matter of how old and widespread the systems are: D&D is fundamentally more stuff-heavy because it lets you arbitrarily augment or craft your own stuff. Enchanted swords, special potions, new spells, armors made of rare new materials. D&D has a literally infinite variety of swords. No matter how many different guns with different ammo types Shadowrun lists, they simply cannot keep up with that!

Hm. What the hell do I mean that science fiction is about "stuff", then?

Well, look, fantasy games are about personal merit. But there's not a lot of personal merits in them. There's a few stats, an alignment, maybe some personality traits, and a class. These things determine your personal merits. They determine who you are.

In turn, these merits serve as an anchor. The game has a vast statistical maelstrom of STUFF. This is the meat of the game, where all the players struggle and fight. The merits you have serve to anchor you within this maelstrom, so you can participate without getting swept away in confusion. You're a mage with a high speed? This is where you stand. A warrior with low charisma? This is where you stand. Your personal merits mean you'll approach the situation like such.

Most science fiction tabletops take this same approach. But that misunderstands a lot.

Because fantasy games are about your personal merits, they feature things which are easy to personally imagine. Even a dragon or a giant dwarven hold is something an individual can imagine pretty easily. They can hold their merits up against these challenges and see what kind of struggle would happen, what kind of standing they have. The vast array of statistical gear and spells and such allow them to grapple with these figments, pushing and pulling at the things they can do... but the things they can do are still rooted in their perception of who they are, their personal merits and traits.

Science fiction tabletops try to hold that same line, but the setting of a science fiction game is about STUFF. So you're a hacker, a smuggler, or a space princess - you have all these traits... but the setting is about a planet that's being colonized, or an ancient civilization, or a disease, or a robot rebellion. These are not things affected by your personal merits.

A smuggler or hacker can certainly get involved with all these scenarios, but the scenario is both larger and more lively than they are. A hero could imagine fighting a dragon... but a hero is of a lot less use when a radiation storm is inbound. A hero can imagine walking the ten thousand steps of fire... but those ten thousand steps are just a barrier to overcome, not a living thing like a space station full of refugees.

In the end, the setting sabotages the game. The game is built around individual merits, but the setting doesn't give a shit about your individual merits. The setting cares about STUFF.

Well, stuff isn't bad.

See, fantasy games can build this giant maelstrom of stuff on top of a setting that cares about personal merits. Science fiction cares about stuff, so it may be possible for us to build a giant maelstrom of personal merits.

This is really what science fiction is about. It's about a foundation of specific assumptions, and seeing how that affects the people. "What if space ships could travel faster than light?" "What if we were psychic?" "What would people do if aliens invaded?" "What happens when robots can do our jobs better than we can?" "What if our TVs were able to watch us?"

The STUFF here is very specific and limited. Robots that can do a specific kind of thing. A government that acts a particular way. A space ship that can move a specific way. There's not 10,000,000 different kinds of robots, each with their own stats - it's just a few kinds of robots to set the stage properly.

And from that foundation blooms an outpouring of human behavior. How do people behave? What do they do? How do they feel?

This is where the powerful imagery in science fiction tends to come from.

The images Roy Batty describes - "Attack ships on fire off the shoulder of Orion... c-beams glitter in the dark near the Tannhäuser Gate" - these are not things with any clear image, but they can still make you shiver. They are mysteries to us - but Roy has been there. He's been there, and he remembers, and he's fighting to live.

Roy's life is defined by the stuff he's seen. Roy's struggle is defined by the stuff he's seen. Roy is defined by the stuff he's seen.

By stamping down a foundation of stuff, we can allow people to shine, both as individuals and as groups.

So why don't any science fiction games work like that?

Well, because nobody's written one yet.

...

I can't pretend to have a good set of mechanics in mind. I'm still thinking this through. But logically, a few things seem clear.

First, the stuff is less complex and the personal merits/beliefs are a lot more complex.

Second is that you would choose your stuff more carefully than your personal characteristics. You don't need to know if you have a strength of 14. You need to know that you have an antigravity belt or Jedi powers. Those will provide a foundation for interacting with the challenges in the game. The personal merits like strength can vary over time or be completely unimportant.

Third is that your personal merits/beliefs would not be concrete. For example, in a fantasy game you'd choose "self-confident" as a trait and it'd stay forever. In this game, the self-confidence comes in many forms. There are times when you'll lose confidence, times when you'll only have confidence in certain ways, and times where your confidence doesn't matter at all. Just like wielding a sword in a fantasy game: you can drop it, replace it, and sometimes you'll leave it sheathed.

Fourth is that combat cannot be the focus. Combat is fundamentally about personal merits, so it can't be the foundation mechanic. The foundation mechanic needs to be about stuff. You won't struggle to kill goblins: you'll struggle to push through a mind-control laser beam. You'll struggle to get robots accepted as people. You'll struggle to keep death at bay.

...

I hope I've been clear. Let me know if you understood what I was trying to say.

Tuesday, September 09, 2014

Texture in Gameplay

The reason I keep building tabletop RPGs that nobody really plays or sees is because tabletop games have an interesting clarity. A lot of the most time-consuming stuff in a video game (or even a published RPG) is not required when you're building these kinds of prototypes, so you can explore a lot and polish a lot.

The big thing I keep thinking about is the difference between elegance and texture.

One of the impulses I always have is to aim for elegance. I always want a set of simple rules that work in all situations and create a lot of tension and emergent complexity. But that's not necessarily the best thing to do. It's very bland.

It's true that these rules make the game pretty easy to pick up, and it's also true that the game can be very interesting if the players and the GM inject themselves into the world. But it's hard to get traction with a system that tastes like tofu.

The other end of the spectrum is oldschool AD&D, where nearly every rule is special-case. The mechanics governing armor class are completely unrelated to the skill check mechanics which are completely unrelated to the class restrictions which are unrelated to the loot drops and so on. It's not just a stapled-together set of independent mechanics, it's also a bunch of special cases within those mechanics.

To a lesser extent, any game with a specific world is full of this kind of special-case stuff. "Oh, this particular city specializes in this particular thing, and has this particular relationship with that city..." "Oh, the prestige class 'bone knight' has these abilities and is widely considered by the public to be..." "These forests are full of lurk-spiders, which are giant spiders that also have a chameleon ability..."

A lot of people might consider this to be "color", but it is often very integral to a player's experience.

First, they're important narratively. These things will often be what the GM uses in her campaigns, and will drive small or large plot elements. Even if they aren't used directly, the GM's own scripts will tend to reflect the examples provided.

Second, they're important statistically. A lot of these special-case rules flavor the choices the players make. "I need to gain two points of strength so I can use this particular skill", for example. Or "we better stock up on jorts, they're heat resistant and we're headed into a jungle." Or "I'm learning this worthless cantrip spell because I can use it in these unexpected ways..."

Third, special cases are important to the "stewing" part of the game.

"Stewing" is a concept I've not really seen explored anywhere. Basically, when someone gets interested in a system, they don't simply stop thinking about things the instant the session ends. They keep thinking about it. They think about it a lot on their own time. They imagine their path forward, alternate builds, imagine potential scenarios, read about interesting monsters and places, maybe read the novelizations if they get really interested.

This isn't about the GM actively scripting a session. It's about just stewing in the system.

In my opinion, stewing is the purest example of traction. The more rewarding it is to stew over a game, the better the traction is. I think this same traction shows itself in gameplay and session scripting too, but its purest form is when a player borrows the rulebook so she can read it on her own time.

As far as I can tell, in order to improve traction you need to have a particular kind of world design, a particular kind of special case.

Basically, it's the special case that makes people think of a scenario.

A special case rule might be a critical hit table full of generic hits. Critical to the leg, -1 dex; to the arm, -1 str; etc. But this is pretty flavorless: nobody reads that and thinks about a scenario.

A better table would be one like the Hackmaster tables, which are deeply hilarious, pages-long tables that include hit locations like "left nipple". But even these are probably not ideal.

If you want the best critical hit table, you need hit locations that make the player imagine what it'd be like to get hit with one, or hit a monster with one. "Leg, -1 dex" isn't going to make anyone give a shit. But "knocked down and flung 10 feet backwards" would make them think.

It's important not to drown them in options. There's a reason monster descriptions tend to be most of a page and include a lot of extraneous details: if it's just an endless list of names and stats, the player will lose focus and skim. It's the same with tables.

You don't need a "flung 5 feet backwards" and "10 feet" and "20 feet" variations. You just need one option that punches that particular spot. The next option does something else, such as "concussion: cannot use skills for 5 rounds".

To be honest, a random table is also not a very interesting way to handle critical hits. Instead, consider linking critical hits to the weapon. Each category of weapon has its own critical hit. The hammer class knocks people down, the staff class concusses them, and so on.

By linking the events to other in-world choices, you accomplish two things. First, you make those choices matter more. Second, you make the assumptions of the player matter more. For example, many players will just assume a particular weapon for a particular character. Now they have a piece of rules meat attached to that assumption, and they can easily imagine the results. "Oh, dwarven warrior with a hammer... cool, he'll be blasting things away from him!"

...

The thing you have to watch out for is taking it too far. If everything is special-case rules, then you can only play if you've already played before. No new players will really be able to get a feel for the system.

Five ways around this:

First, have a really easy to understand set of core rules. The texture comes out during play, not during initial explanation.

Second, have templates ready so a player can choose what they want without understanding all the rules. Make the templates decent.

Third, make the special case rules imply scenarios. A rule like "+3 to attack" means a lot less than "nightvision". Nightvision implies a lot of scenarios. +3 to attack is a statistical tweak. Even if +3 to attack is stronger, it's not as vibrant.

Fourth, there's nothing wrong with statistical meat: just hide it far along the player's career. Everything a new player is likely to encounter should be vibrant and scenario-inducing. Later on, when they deeply understand the balance of the system, +3 attack will make them drool and think up cool scenarios just as much.

Fifth, add in a hint of the scenario if you don't think the special case gives enough impulse on its own. Old Shadowrun books used to do this a lot - the endless list of guns or districts or whatever would roll by. But at the end of each entry would be some chummer snarking over the net, gently giving hooks. Like "GUNCHILD_88>> Oh yeah this was the place where the cops did that mafia sting... never been the same since!"

Anyway, those are my thoughts.

Thursday, August 28, 2014

Repeating-Design Space Ships

Recently I've been thinking about space ships. AH HA that was a joke. I've been thinking about them since I was three.

One of the things I've done in the past is focus on the concept of systems in a space ship. You need life support, engines, fuel, solar panels, batteries - by breaking down the ship into a pile of parts, you can create a lot of complexity. It's also useful because you can add in additional complexity easily - just create or mod in new parts with new functions.

But there is another approach to ship design: having many of the same modules.

You can see this most commonly in space ships from movies or concept art: the artist doesn't need a space ship that statistically "works". They need one that looks and feels "right". So it has dozens of repeating modules - hundreds of engines, dozens of rows of unnamed windows, glittering lights aplenty. You can also see this in parts of Space Engineers, due to the fact that modules cannot be scaled, so larger ships need more repeating modules rather than larger versions of the modules.

There is something to this design sense, both mechanically and visually. Space Engineers doesn't really take advantage of it - I can't blame them, because nobody has.

Space Engineers (and most other non-physics ship games) use non-topological modules. That is, aside from some minor restrictions, it doesn't matter where in the ship the modules are put. If you need 50 engines, you can arrange them however you want, as long as nothing is directly behind them. This is good in that it gives you a lot of freedom as to how your ship looks, but it's bad in that it's not very compelling gameplay.

One easy way to make it more compelling is to make topological relationships matter. For example, imagine that an engine module has an efficiency rating based on the modules around it. Maybe the engine module generates heat, and if that heat is allowed to build up efficiency falls off... but if it is kept too cold, it also falls off. Maybe having high-pressure fuel raises efficiency, but every engine on the "fuel chain" diminishes the pressure for the rest. Maybe the engine module vibrates, reducing the efficiency of neighbors. There's a lot of options.

Addressing these options is a fun part of building a ship. Not only will you want to place your engine modules carefully, but you'll want to use support modules such as heavy-duty pumps, heaters, heat vents, dampeners - and those support modules may also have a variety of requirements.

Topological constraints can really make building ships interesting, but there are some constraints on the constraints. Lemme 'splain.

In order for topology to be fun, it has to be bumpy, have texture - the player needs to be able to properly grip it. Every piece the player adds has to make the player think "oh, this is going to be fun to put together!"

If every module is a 1x1x1 brick in 3D space, the player will never think that. Every piece will just be a bundle of basic stats.

One way to give the pieces "texture" is to change how they are shaped. Giving them various sizes and shapes will make it fun to figure out how they can be interlocked in interesting ways. If certain points on each one are hardpoints or resource intakes/outputs, fitting them together becomes even more complex - but don't accidentally make it so restrictive that there's only one way to fit things together!

There is another way to give the pieces texture: restrict where they can be placed.

An endless 3D grid doesn't give the player anything to grip onto. But if you make assumptions about how your ship "needs" to be laid out, you can really change the end result. for example, we can assume a standard "spinal" ship design. Then we can allow the player to choose how long or broad to make their ship, and split the spine into sections - crew section, support section, engineering section, engine section. Each module can only be attached to one section, or to a part that is ultimately anchored to that section.

However, modules near each other are "smoothed" together with the ship skin, linking them physically in the final form even if the modules are actually anchored to completely different parts of the ship. In this way modules from different segments can interact with each other and be linked together, allowing them to affect and support each other, and forming the basis for topology more complex than a simple branching tree. Basically, branching tree construction, but realspace interactivity.

Another option is to create a spaceframe of some simple shape (like a 'U'), then allowing you to put modules anywhere... but never attach modules to modules. All modules must be attached to the spaceframe. This "surface area" approach allows you to relate whatever mods you like, but space constraints become absolutely critical. Obviously, larger spaceframes have major drawbacks.

There are a lot of other methods, but the basic idea is simple.

I've been thinking about this a bit recently, partly because it produces much more refined ships. Rather than being a simple string of every required module, the space ships have repeating motifs. If you wander around inside of them, you'll walk through a ship that seems to be engineered to fight against space: halls of pulsating engines, rows of churning computers, life support pumps hammering away. It's not just a checklist - "life support, check!" - it exists properly. It's been designed, carefully balanced and placed by a rocket scientist (or, at least, someone pretending to be one).

It also looks better from outside. Regardless of the constraints used, the repeating module motif produces much more interesting ships than the "one of everything" motif.

Anyway, those are my thoughts.

Tuesday, August 19, 2014

Fluid Time

I realized a little while ago that I've been leaning very heavily on a particular concept nobody else seems to use at all. I call it "fluid time". I have to explain it in order to explain my NPC-mod system, so here we go!

Most of my recent prototypes involve being able to fast forward, pause, even rewind. They feature going to some other location, but still having the first location processing in the background.

Normally, if you have things that change over time in a game, you'd attach them to the frame or physics loop and process them each iteration. But that doesn't scale very well as timescales change and the number of changing objects reaches the thousands or millions.

Using fluid time lets me get around that, and handle extremely large numbers of objects at any timescale I please.

It's a pretty basic idea. You take the statistics that behave predictably, and instead of calculating that predictable change every frame, you just create a function for it.

For example, let's say Anna is the only farmer we have. She produces food. When we plonk her into the game world and assign her that task, the "food" stat begins to change in a predictable way. The formula becomes "at day 1: 0 food. +1 food per day."

Now, if we zoom off to the far side of the galaxy and do a million other things, that function continues to exist. It doesn't take up our CPU, Anna doesn't need to be loaded into the scene. If we want to know how much food we have, we just call that function with the current day and it calculates out how much food we have.

Let's say that farmers stop producing food in winter. In that case, our function would simply have a bound. "At day 1: 0 food. +1 food per day until day 270."

We know when the function becomes invalid, so we know when to revisit and recalculate.

If we want to do it strictly, we can: day 270 dawns, we revisit the situation, and the formula changes to "At day 270: 269 food. +0 food per day until day 360."

Alternately, we could simply pause time in that area until we revisit - time stops there at day 270, and the player gets to take control at that time, even though the day might be 190,028 in another sector.

We also have a lot of options about historical info. Once day 270 rolls around, we can either save that now-obsolete span of time, or we can discard it if we don't need to remember. What would historical info get us? Well, you could rewind time, you could look at historical trends, you could play in multiple times simultaneously...

Another big advantage of this method is that it allows synching multiplayer really cheaply. It doesn't work for everything - for example, it can't respond easily to details like movements or the moment-to-moment choices of other players - but it works well for cheaply keeping track of thousands of low-maintenance shared objects. Of course it does: that's what it's intended to do locally, and it works just as well on a network.

There's one more big advantage, and this one's a doozy: it's easy to mod.

One of the core problems with mods is that they can only usually interact with the "surface" of the game. Mods that affect core functionality are usually not possible, to the point where several Skyrim mods come with a java program that runs in the background to forcefully intervene against the core code base. The reason it's hard to do isn't malice, it's architecture: the code is intermeshed with itself to do a specific kind of job, and there's no "cracks" in the wall for mods to break in through.

An event-driven system is a lot more flexible, as you can either overwrite the delegate assignments or start catching events.

But there are some problems with event-driven frameworks.

The biggest for us is that Unity doesn't serialize event subscriptions or delegate assignations, so saving and loading and transferring them over a network is nightmarish. The biggest problem for everyone else is that events are hard to debug, hard to keep track of - too many asynchronous pieces moving in every direction.

So most games don't expose much event-driven stuff, and mods have to break in. This results in things like Skyrim's dreaded "script cancer", where scripts run every frame to check all the relevant stats and states, bogging things down to a crawl. Events would allow you to do this more fluidly, attaching your functions to events like "onStrengthChanged" or "onEquippedItem" or whatever. But... it doesn't serialize and it's hard to debug.

We can tackle both of these issues at once if we create an event handling framework that can serialize and deserialize properly. The framework can easily keep track of who is signed up for what and make it easy to debug and even visualize in real time.

It's annoying to have to build this kind of framework when the C# event/delegate framework works almost well enough on its own, but on the plus side it lets us integrate into Unity and our specific project much more firmly. For example, press F12 and you can see the rays of connectivity between watchers and watchees.

Fluid time benefits from this due to the large number of interconnected moving pieces. A new farmer, or a storm, or a mod that introduces crop blight - they can all interact with the "food" fluid time system and run in a very low-maintenance, cheap way.

Press F12, and you can see what mods are affecting the crop totals, what mods are waiting for food production to reach certain levels, what mods are reflecting food values in some ways, when the current formula is due to be obsolete, what is making it obsolete...

Anyway, soon I'll write a post about how we can use this to make moddable NPCs, but this is long enough as it is. A hint: it involves scripting in the lexical sense!

Friday, August 15, 2014

Moddable NPCs

I've talked a lot about mods a lot, and I'd like to talk about NPCs.

Even with highly-moddable games, the NPCs are miserably difficult to manage. Skyrim probably has the most moddable NPCs, but the way the NPCs are implemented in the base game really limits their behavioral flexibility.

So, let's talk about a game where modding NPCs is the point.

You play a godling. Not in a gods-eye view, but as an actual person in-world, similar to Skyrim. Your big power is to create people out of clay. They turn into living NPCs, and you can interact with them.

The basic loop is that the NPCs generate resources for you. You can gather some resources on your own - clay, water, grass, and whatever else you can find - but those are very basic and there's no crafting. Instead, you set the NPCs up to generate resources. First you create a farmer, and they make food. Lots of food - enough to feed everyone else nearby and still give you a stack of foodstuffs if you decide you need them. Maybe you create a woodcutter to create lots of wooden planks so you can build wooden houses instead of log cabins. Maybe you create a carpenter to turn wood into furniture, so you can fill those new wood houses with nice furniture. Maybe you put a shrine in the house so they can worship you and give you spirit points. Or a library, so they can generate new ideas...

As time passes, the NPCs will get better at their jobs. This isn't stored as some internal skill variable. Instead, it is evident in the tools they use. Their tool shed becomes more full with higher-quality tools. Their bookshelf is filled out. Their yokes & ploughs upgrade to the next tier. Their skill is represented quite concretely by the objects in their home. Trying to move these items to a new home will lose a lot of the upgrades, so it's kinda-sorta-vaguely NPC-specific.

While there is some challenge to creating a good flow for all the resources you'd like, the real challenge is in keeping your NPCs alive. You can create them easily enough, but if they are put under too much stress, they revert back to clay statues. They're not really dead - you can wake them back up as long as the statue isn't destroyed - but they certainly aren't living.

Unfortunately, these NPCs are very vulnerable to stress. Their default state is "dead of stress", and it gets much worse if they have a job. You have to build their homes to alleviate that stress.

For example, if you're going to start by building a farmer, you'll obviously need to give her all her farm tools and so on... but you'll also need to set up her home so she can survive. A bed, kitchen, and so on are all required to prevent added stress due to exhaustion and hunger. Then you also need to set things up to reduce the stress she is under! A fireplace, candles, some books, a veranda, some company...

There's no need to simulate the NPC's stress in real time - it all derives from the furniture in her house. The NPCs are simulated when you are nearby, but that's for social purposes, not for statistical purposes.

So, you set up a little farmer family. They farm, and they support each other, and stress is kept to a minimum. However, nothing lasts forever. As time passes, all the furniture in the house drifts and/or decays. This won't affect something like a workbench, but things like beds and chairs and bureaus and costumes all migrate and/or degrade. So your carefully balanced house steadily falls out of true, and stress becomes an issue. Eventually things will drift far enough or decay badly enough that the NPCs turn back into clay statues.

This is often a catastrophic spiral, because a lot of the stress relief comes from other NPCs. The farmer parent's bed is a double, with each side assigned to one of them. This creates a romantic relationship between them, and that really reduces stress quite dramatically. But if mom turns to clay, that stress relief stops happening and dad quickly turns to clay. Of course the children are likely to turn to clay as well, since much of their stress relief comes from being taken care of by their parents (indicated by the parents ownership of things like the kitchen, front door, etc).

Now, the moment-to-moment behavior of the NPCs is actually handled the same way. Every object can create a "state" for the character, and that state has certain kinds of behaviors and takes certain kinds of inputs. It's very freely done, and the heart of the modding system. Each state gets to "vote" on what it thinks the action of the NPC should be at any given time.

For example, the parents share a bed, which sets up their romantic relationship. In addition to being stress control, this also creates a behavior state for each - the romantic interaction state. Romantic interaction probably doesn't mean "having sex" - it means the gentle interactions over the course of the day that show they are used to each other and think of each other frequently. The romantic state only votes on situations involving their lover, and it doesn't always win the vote: another piece of furniture might cause the pair to fight, or just do things other than get along gently.

Moreover, the state of the bed can really change the nature of their interaction. Different beds might have different nuances - perhaps certain relationships are more bitter, or more brusque. Each side of the bed can be customized with a pillow, or perhaps have several states such as made/unmade, bedspread, etc. These can all be used as markers for different tones in the relationship.

It might feel stupid to rely on things like a specific color pillow to represent a specific kind of interaction, but the point is that the NPCs can swap out the components randomly over time and their relationship will drift. By controlling how things get swapped out and how likely things are to be swapped in various ways, you can control how relationships grow or degrade. This is still clumsier than having a simple state machine hidden inside the NPCs, but it's much easier for the player to understand and control.

Moreover, the relationship system is bound to the specific bed item type. Use a different bed for a different kind of relationship - not necessarily just a different nuance: it can be a completely unrelated mod with similar functionality. You can have both mods loaded into the game without difficulty: one is tied to beds A&B, the other to bed C. In fact, there's nothing preventing you from having several beds for one pair of people, each with a different relationship attached, resulting in several simultaneous romantic relationships.

That might sound broken, but there is a limiting factor:

The more rooms and furniture you have in a house, the more maintenance stress. This stress is distributed evenly among everyone, unless you have cleaning supplies assigned to specific people, in which case it is dropped on them. In the short run, mom and dad having three beds is quite nice, and stress is really kept very low thanks to the stress-relieving property of beds. However, as the beds decay, their stress relief drops off quickly and the relationships become rocky. The amount of maintenance stress does not drop off, so stress relief drops off three times faster than it would with a single bed.

You can build a wealthy nobleman's house, lots of beds... just assign the maintenance duties to servants. That's how the pampered live their lives. Of course, their position of authority may involve taxing their citizens, in which case the citizens will all gain more stress because of the nobleman lording it over them... but there are advantages to that, with the nobles generating resources ordinary people can't generate. Well, that's one approach, at any rate. Maybe you have a different set of "nobility" mods loaded in.

Anyway, all of this is done through an open API, allowing anyone to compile a plugin using the Unity framework. An integrated mod manager is actually pretty easy using the asset management tools in Unity, so this would be pretty easy to mod. It could also easily support multiplayer shared worlds due to the low amount of simulation required.

There's a lot of other details. For example, the alignment and position of furniture often matters. A chair facing the fire is relaxing; a chair facing a desk will help generate ideas; a chair next to another chair will make the two people assigned to those chairs get along and have lower stress. Another thing to keep in mind is that NPCs might have different "hearts" - while they are all made out of clay, the seed you build around can be any small item. This can allow for NPCs to also be directly modded rather than always relying on furniture.

Well, all in all it's actually not a hugely difficult game to start. At the beginning, it's just a simpler version of The Sims.