Yesterday I wrote a cluttered essay about making construction games that have NPCs in them. The basic idea is that construction games generally have bad/nonexistent feedback on player activities, which means they have no real traction. However, if we put NPCs in the game, they can react to the player's actions. They can react to the things the player constructs, react to the actions the player takes outside of construction, and react to how the player's constructions fare as the world weighs down on them.
It's easy to think of this as "creating a game where NPCs live their lives in the player's constructions" - think The Sims. However, that's the opposite of how we should think of it.
Normally, we use smoke and mirrors to make convincing NPCs. Now we will use the NPCs as smoke and mirrors to make a convincing game.
Let's consider some methods.
First, when the player installs something new, it needs to be acknowledged by the NPC population. One way to do this is the Sims' method: NPCs walk over and admire or disdain the new purchase. This is too small and shallow, although it's probably worth implementing. The real response needs to be deeper: NPCs need to adopt the new purchase as part of their lives or work.
This is more flexible and immersive than it sounds, but it requires us to make every component of our construction human-centric rather than intersystem-centric. That is, we can build a power station, but it has to be something a person works with or at, not just a passive device that adds N power to the ship/base.
We have some wonderful opportunities here.
A) The NPCs can openly discuss who should have control over the new system (or how they should share it). Someone says their job needs the new computer, or decides they maintain the engines, or that this is their new quarters.
B) The player can manually assign those duties instead of allowing them to be automatic, changing the dynamics of the NPC's lifestyles manually.
At a low level, this means that the most critical thing you'll need is workers. As you build stuff in your base, you'll need to have enough workers to use/maintain it. There's a natural tendency to make that a serious constraint, so that you'll need hundreds of workers to manage any decently-sized base. However, the human brain can't really keep track of that many people at once, and therefore their responses will start to feel random and arbitrary instead of purposeful. We need to keep the number of workers manageable. That's more complicated than it sounds, but at this stage it simply means that NPCs should be allowed to take on a truly staggering number of duties without suffering.
Instead of requiring more NPCs, the NPCs can take on more duties. This will shape their lifestyle and prominence in the facility: someone responsible for more things is busier, but is also respected more and has a lot more social clout. Not all duties are considered equal, though, and there's a lot of complexity we can add in as we please. For example, some jobs give you social prominence, others give you happiness, others give you cash, others increase your stats...
Working out the NPC response to a newly installed segment is an opportunity for us to make a fun and details bloom out of our game, but it's only the first step. We also need to consider non-constructive gameplay such as damage/degredation, missions, daily life, etc.
How we make our NPCs react to these other systems will further shape our game, but first we need to figure out what kind of systems we're talking about.
I rather like the idea of having multiple concurrent missions at all times. For example, your science team could be searching for allergens in the local flora, your political time might be trying to learn the Xargiblot language, your political team might ALSO be struggling to keep a neutral peace going until they finish learning the language, your exploration team might be collecting rare samples from the artic poles, your engineering team might be optimizing the atmospheric thrusters to work best in this atmosphere, etc.
All of these missions take different amounts of time to complete, and have different drivers that push them forward. The idea is that the player can focus on any given mission for a short amount of time, optimizing things and polishing and manually setting things up, but the missions also proceed automatically in the background. This allows the player to choose which missions they want to focus on, and switch missions if they ever get bored.
This also means our NPCs are split into teams. This is good, because it's an excellent way to "chunk" our NPCs. Characters with no structured relationships are hard to remember, but if we split them into teams, the player can partition them up and remember them relative to the team rather than to N other NPCs.
Teams can have high or low status to other teams just like NPCs can have high or low status compared to other NPCs. Most of an NPC's relationships will be within the team - interteam relationships are hard to remember, so they should only happen when specified by the player.
Chunking teams is a big, easy thing to do in order to make our bases or starships more interesting. For example, your instinct might be to have a big dorm room for all your workers, but team cohesion suffers. It's better to have different dorm rooms for each team, especially since you can then decorate the room or have nearby rooms that enhance that team's performance but wouldn't benefit teams with other priorities.
Combining and splitting teams is also a ripe fruit. For example, the political team needs to talk to the natives of this planet. However, you don't know their language. So you split the team into two: a xenolinguistics team to research the language, and a social team to try and mime their way towards peaceful coexistence. One team, one mission. Once the language is learned, you can merge the teams back together.
Not everything is a mission. You don't split the engineering team into an engine maintenance team, a life support maintenance team, etc. Those are simply duties that happen in the background. The mission would be optimizing engines or something similar. Something that has an end state.
Because the missions move at different rates, each team is under a different amount of stress and a different phase of their work. As missions get near completion the stress is at its peak, so the players will naturally tend to focus on missions near the end of their run as they have to step in to massage stress problems.
We can also have personal missions, resource allocation challenges, etc.
All of this leverages the player's ability to choose missions. While some games are completely open, allowing the player to flat-out make up missions, my approach does require explicit missions. But since there are so many missions and so much flexibility about assigning them, it should feel pretty open. There's nothing that requires you to learn the alien language, or even to negotiate with them. You can create an overall mission profile based on your own personal approach.
The combination of NPCs working on the mission and the devices supporting them gives you strong feedback about your design and whether it works well to support the NPCs. Should be pretty clear and rewarding.
Anyway, that's my concrete thoughts on using NPCs to provide feedback. What are yours?
No comments:
Post a Comment