tag:blogger.com,1999:blog-117582242024-03-23T11:35:31.769-07:00ProjectPerkoChronicling the intrepid adventures of an ivory-tower theorist.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.comBlogger1577125tag:blogger.com,1999:blog-11758224.post-47197262477524640492019-10-01T08:07:00.000-07:002019-10-01T08:15:25.071-07:00Ace of SwordsI find a lot of writers fall into a trap: trying to write a story with the wrong ingredients.<br />
<br />
No matter what story you want to write, you need the foundation of having the right amounts of the right things. The more of something there is, the less unique and distinct it is.<br />
<br />
If there's loads of swords in your story, then a sword is not unique or distinct.<br />
<br />
If there's only one sword, a lot of your story will be about why there's only one.<br />
<br />
By carefully deciding how many swords to put your story, you get just the right amount of swordiness in your story.<br />
<br />
Pretty basic, right?<br />
<br />
<b>One</b><br />
One sword, and a lot of the story is about that one sword. Whether it's because that's the Sword of Light that no weapon can match, or whether it's because only one character in your office comedy show carries a sword.<br />
<br />
While that one thing will always be distinct, you can make it more important by defining related things as blandly "not that". Or you can play it down by having a lot of variation.<br />
<br />
For example, if your story is about twelve nearly-identical adventurers and a shlubby dude, the story is about the shlub. On the other hand, if your story is about thirteen people, only one of which works in a coffee shop... well, presumably, the others work in other places and the coffee shop employment will be distinct but not a major driving force.<br />
<br />
This is also an easy one to accidentally trip over.<br />
<br />
If your story features six white guys and a black lady... that one lady is going to stand out far more aggressively and distinctly, even if you didn't intend her to.<br />
<br />
An example of this would be Bulk and Skull in Power Rangers. They're usually considered as "one unit", and they're really the only non-superpowered unit in the series. Because of this, they draw a lot of attention - people often feel more strongly about those two than about any individual rangers. As a plus, they can be split apart when needed and used as...<br />
<br />
<b>Two</b><br />
If there's two swords, the story will be about how those two swords get along. A sword of fire and a sword of ice: who has them, how do they shape the world, what happens when they fight? You can see Lodoss Wars for an example of that.<br />
<br />
Having exactly two of something draws attention to it. It can't be played down as much as if there's only one, or if there's a lot. Two is a really loud number.<br />
<br />
Whether it's two swords that fight, or two amulets belonging to twin dragons, or two short people in a land of tall people, or two countries on the continent, or two species in your fantasy setting - it's all about how those two connect, and the differences in how they affect the world around them.<br />
<br />
A lot of people write dualities like this into their stories without realizing how important it can become. <br />
<br />
For example, you might set up a hero and a rival as being the only two people with a specific ability. If you then resolve their conflicts and have them move into the third act together, it's going to feel strangely flat and cheap... because their tension was far more powerful than whatever random baddie you're having them team up against. Makes more sense for the rival to take over as the big bad.<br />
<br />
<b>Some</b><br />
If there's "some" swords, then the swords usually map to a specific category of character, and represent that character. They separate that kind of character from other kinds of characters, and become projections of that character's desires.<br />
<br />
The easy example of that is Star Wars, where each space wizard has their own sword. It sets them apart from non space wizards, and the swords are usually considered to be extensions of the space wizard. If someone uses a sword that's not theirs, it won't work right unless they are "accepted", and if you find an abandoned sword, it probably still echoes with the space wizard that made it.<br />
<br />
This may sound very spiritual, but it's an extremely handy way to extend your characters into your story space. Space wizards can have an outsized effect on the story because they are able to extend themselves into the story with their magic swords. The swords reflect and project who they are and what they want.<br />
<br />
A non-swordy example might be superpowers in a comic book, or adventurer licenses in a fantasy manga. For less combat-centric things, it might be jobs in an office comedy.<br />
<br />
When setting this up, it's important to choose a thing that extends the characters in a way your story needs. If space wizards had magic wands instead of swords, the story would feel more ephemeral and distant... but swords are immediate and primal, suiting the melodramatic conflicts of Star Wars. Similarly, in an office comedy, having distinct job roles extends the characters into the office space in a suitable way. If they had swords... well, it'd be funny, but it'd be a very strange office comedy.<br />
<br />
"Some" may also be used to define a unified group, but in this case it's really just "one". For example, there are "some" ring wraiths, but in story terms there is "one" group of ring wraiths, and a lot of the story is spent on exactly how and why they exist. There are "some" Borg, but it's really just one group, etc, etc.<br />
<br />
<b>Lots</b><br />
When there's lots of swords, they stop being unique and start being a functional prop. Their existence is important to the story, but individual swords are not terribly interesting and the things they do are often glossed over and taken for granted. They are often used as a framing device or narrative engine, rather than being used as swords.<br />
<br />
For example, if absolutely everyone has swords, that says a lot about the kind of world they live in... but individual swordfights are likely to be glossed over and summarized. A Game of Thrones and The Hobbit show that.<br />
<br />
If you want the swords to be more important, you have to come up with more important swords. So these are magical swords. Oh, too many magic swords? This one is a super-duper magic sword...<br />
<br />
This isn't necessarily bad writing, but it's essentially separating the thing into "a lot" of ordinary swords and "some" special swords. This is why Bilbo's sword Sting can be easily thought of as an extension of Bilbo: short but sharp and shines when things get dangerous. There are "a lot" of ordinary swords and then "some" swords that are extensions of specific characters.<br />
<br />
Again, swords are just an example. Another example might be monsters in Power Rangers, or species in Star Wars. They push the plot along and frame the story, but they are only distinct or unique as required to do that.<br />
<br />
<b>Summary</b><br />
This is a very basic, easy, and primitive way to consider what ingredients you're adding to your story world.<br />
<br />
Regardless of the type of story you want to write, if your ingredient proportions are wrong, you'll end up struggling to write what you wanted to write.<br />
<br />
This is especially important when <i>you're not writing the story</i>.<br />
<br />
If you're designing a world for a tabletop game, or for an extended series of stories, you need to arrange the ingredients to support the kinds of stories you want to exist!<br />
<br />
At least, that's my take. Let me know what you think.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com1tag:blogger.com,1999:blog-11758224.post-64978277635364118252019-09-16T09:49:00.000-07:002019-09-16T09:49:28.238-07:00Writing CRPG CharactersI've come to have very strong opinions about how characters should be written in CRPGs.<br />
<br />
Here's the rule: the character needs to <b>engage with the player</b>.<br />
<br />
This is a funny thing about a CRPG. The game can have terrible writing and unbelievably poorly written characters... as long as the characters properly engage with the player. Similarly, even if you have wonderfully written characters voice acted by legends, if they don't properly engage with the player, they're background noise.<br />
<br />
So here's the exercise:<br />
<br />
Don't write a backstory. None of your characters have any backstory.<br />
<br />
Now your writing will radically improve.<br />
<br />
----<br />
<br />
In order for a character to feel real, they have to exist in the same time and place as the player character. They have to talk to the player character. Negotiate, exchange ideas, come to a shared understanding of the world they exist in and their places within it. Their relationship has to evolve.<br />
<br />
Backstories are poison to this, because a backstory exists in another time and place. Dripping a backstory into the player's ears as they earn relationship points doesn't establish a shared reality, doesn't involve negotiation or an exchange of ideas, doesn't improve the character's understanding of anything, and rather than evolve the relationship, it happens after the relationship evolved!<br />
<br />
Some games try to bring the backstory into the present. This is possible, but it's more likely that you'll screw it up.<br />
<br />
The basic rule is that you should never close loose ends without opening at least as many.<br />
<br />
Most character backstories come into the present to close off loose ends - essentially ending the backstory and closing out the character. I have no idea why this is common, but it's just the worst approach.<br />
<br />
Since I've been playing Pathfinder: Kingmaker, let me give some examples. <br />
<br />
(Keep in mind that this game is written abominably.)<br />
<br />
There's a warrior you'll use as your primary tank. I think every player uses her. Her backstory is that she's just so gosh-darn pretty that she was adopted by the religious order of beauty. She got angry with everyone telling her she was pretty, and quit.<br />
<br />
Seriously.<br />
<br />
Her "loyalty mission" is a character from her backstory showing up, fighting her, and scarring her face. The end. She's apparently no longer pretty and apparently the church no longer cares about her. All the loose ends are tied up and her character is now in limbo. No more interests, no more goals, no more looming threats, no more opinions.<br />
<br />
There's another character that's undead. Her loyalty mission involves figuring out who killed her and, again, tying all the loose threads up so she has no more plot.<br />
<br />
There's a character that's a ranger. His loyalty mission? Murdering innocent trolls because a troll killed his family. Again, it's tying the loose ends and closing the story of his life.<br />
<br />
There is one character that qualifies, that passes the "loose threads" test. That would be the dumbass barbarian poseur.<br />
<br />
Her backstory is that she ran away from her tribe because they didn't respect her. Her loyalty mission? Earning your respect and her self-respect at the same time by hunting a monster and taking the lead against it.<br />
<br />
That's how you do it.<br />
<br />
You and her are in the same time and place, discussing something happening in this time and place. It's not a monster from her past, it's just some random monster-of-the-week threatening your kingdom.<br />
<br />
You and her are negotiating and exchanging ideas, finding a good balance between her heritage, her need to prove herself, her desire to belong, and the very blunt threat of a giant monster.<br />
<br />
She grows as a person, having proven herself to herself. She's a little less of a poseur, and has found a place that accepts her.<br />
<br />
You and she have an evolving relationship: you're no longer just 'a baron of some land I happen to be on', but her adopted tribe leader. A more fun and unusual relationship than the normal "strangers->friends->lovers" route!<br />
<br />
I won't say her character is good or interesting. It's written with all the subtlety of a freight train... falling on another freight train...<br />
<br />
But the structure of her character beats is solid, and therefore her character seems to exist and be a part of my story. She didn't close any loose threads off, she just joined my story as a living, growing person.<br />
<br />
Could you adapt the other character beats the same way?<br />
<br />
Sure. If the fighter's beauty is so great, let her lure in an ever-increasing volume of ever-richer and ever-more-aggressive suitors. Eventually it gets out of hand, and you have to choose: do the two of you get married in name only just to keep the suitors off, or does she carve a scar into her own face to stop them from coming?<br />
<br />
It's not great writing, because the premise is dumb, but it's a situation that exists in the present and evolves your relationship to each other.<br />
<br />
---<br />
<br />
If we look at other characters from other games, we can see the same basic premise.<br />
<br />
Did you, like everyone, like Garrus? Well, guess what? He's the one that followed these rules. His character beats were always about something happening right now, he grew as a character, you negotiated and exchanged views with him, and your relationship steadily evolved.<br />
<br />
Did you like Aeris? Well, guess what? She followed these rules.<br />
<br />
Did you like Celes? Well, guess what? She followed these rules.<br />
<br />
Even characters like Solas, weighed down by a ponderous backstory, are popular not because of their backstory, but because of how they bring their backstory into the present. How their backstory creates more problems, more loose threads... rather than resolving any.<br />
<br />
I think there may even be some compelling characters whose names don't end with S. Try to find some, and see whether they follow these rules. I think they will.<br />
<br />
So, my take:<br />
<br />
1) Character beats should take place here and now, about things that matter here and now.<br />
<br />
2) Character beats should involve debating, exchanging ideas or opinions, not just listening.<br />
<br />
3) Character beats should evolve the character. Remember that weakness is strength, and that their place in the world is changing.<br />
<br />
4) Character beats should evolve your PC's relationship with the character.<br />
<br />
If you follow these guidelines, even if you write terribly, you'll at least have a compelling character!<br />
<br />
At least, I think so. Let me know what you think.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-4926078337041111262019-08-13T10:13:00.001-07:002019-08-13T10:13:20.041-07:00Topological Construction Play With ScenariosI love building things in games. Whether it's cities, planets, space ships, or nanomachines, I just love putting things together and letting them do their work.<br />
<br />
But this kind of play requires careful construction. A lot of games rely on a "spreadsheet" approach, where the modules just add to numbers on a spreadsheet. This is almost universal on mobile, and is sadly common in indie games on every platform. <br />
<br />
You want to build a city? Add a fishery for +5 food! A space ship? Add an arc reactor for +5 energy!<br />
<br />
The problem is that spreadsheet play is fundamentally passive. The thing I'm building doesn't <i>do</i> anything, it just drifts along as a pile of numbers.<br />
<br />
The things that bring a construction to life are the challenges it faces.<br />
<br />
If I build a city, how does it fare in winter? If I build a castle, how does it fare against siege? If I build a starship, how does it fare during re-entry?<br />
<br />
It's possible to push a spreadsheet to respond to challenges, but I prefer having more direct control. <br />
<br />
I prefer <b>topological construction</b>. That is, where I put things matters.<br />
<br />
The details of this matter. How do you make placing things relative to other things matter?<br />
<br />
Well, there's three pieces: the mechanic, the load, and the scenario modules.<br />
<br />
<b>The mechanic</b> is how you make the location matter. The key to the mechanic is that is has to be a local effect with consequences. It shouldn't be pass-fail: the whole point is to create a soft, widely interlocking mechanic that the player can adjust in a lot of ways.<br />
<br />
For example, in SimCity, the main mechanic is traffic. Traffic produces pollution, and if you fall short, it also produces economic slowdown, unhappiness, and road failure (in that overtaxing a road results in a traffic jam).<br />
<br />
In a space ship game, the mechanic might be power. Power transfer produces lot of heat and nearby elements may degrade, and the laser will fire slowly and weakly if you fall short... Or perhaps the mechanic could be damage, coming in from an outside vector, needing to be blocked and dispersed...<br />
<br />
In a boat or plane game, the mechanic might be water or airflow - how it exerts pressure at various speeds.<br />
<br />
As you can see, not all mechanics are internal-only. Many of them are about how your system interacts with the wider world. And, of course, most construction games have many mechanics, some larger, some smaller: SimCity has traffic as a mechanic, but also pollution, economics, happiness, weather, water...<br />
<br />
<b>The load</b> is how the mechanic expresses itself in local space, and what modules the player can use to handle that.<br />
<br />
For example, SimCity has roads for cars... and also road/car variants like subways, buses, etc. The player is given freedom to optimize: put in a subway from the residential district to the commercial district, and most of that kind of traffic will go through there instead of through the more limited surface roads, freeing those up for shipping...<br />
<br />
In a space ship game, it might be power cables, capacitors, etc. Or, if damage is the mechanic, it might be armor, magnetic screens, shock absorbers, air gaps, shield projectors... the idea is to make it something local, so shipwide shield generators do not count.<br />
<br />
In a boat or plane game, it'd obviously be the hull itself, both hull plates and elements that happen to be exposed.<br />
<br />
<b>Scenario modules</b> are elements you install specifically to create or respond to scenarios. Sometimes these are not specifically spawned by devices inside the creation, but even then the creation will be arranged to respond to a specific scenario and you must allow that scenario to be fired.<br />
<br />
In SimCity, houses and office buildings create an interlocked scenario where traffic goes from one to the other, then the reverse. In exchange, you get money. There are constraints to prevent you from crowding houses and offices together (noise pollution, etc) so you're forced to connect them via long traffic routes.<br />
<br />
Of course, SimCity has dozens of traffic scenarios and the modules to affect them. Shopping centers, airports, external highways for import/export, farms, floods, etc. And SimCity also has scenarios that aren't traffic-related, such as whether to use green energy or high-pollution coal energy or a nuclear reactor.<br />
<br />
Allowing the player to choose which scenarios to accept in which locations gives the player a lot of room to explore and express themselves.<br />
<br />
In a space game, scenario modules would be things like engines, lasers, etc. These are installed with the understanding that they will be useful in the scenarios of the world at large, and that those scenarios are the ones this ship will usually be in. Of course, they create load by being used, but they also take up space and perhaps have a secondary load even when not in use...<br />
<br />
In a boat or plane game, one scenario module set would be engines, with the idea that different amounts of different engines would propel you at different speeds and different heights. Are you building a submarine? A high-altitude spaceplane? Which engines you choose will determine what kinds of scenarios you can face, so those engines are a scenario module.<br />
<br />
<b>The point</b> is to get the player to select what scenario challenges they want to face, and allow them to create something that deals with those challenges. The idea is almost never to deal with a single challenge, but is instead to deal with a parade of challenges, often tightly themed.<br />
<br />
An example of this would be Dwarf Fortress, where there are four or five categories of challenge: invasions, mood swings, the elements, supplies, etc. The player builds their fortress with these considerations in mind, depending on where they built. Your fortress has a death zone for attacking invaders - but make sure you know what kind of invaders you'll be facing. You have a jail for depressed or berserk folk. You have dug deep to find water, and now need to pipe it up into the living quarters.<br />
<br />
You can see how each of these challenges can be abstracted to traffic patterns with side effects. Here's the pattern for incoming enemies. Here's the pattern for water. Here's the pattern for farmers going to work. Here's the pattern for quickly isolating a self-destructing inhabitant. Here's how they interact - the farmers walk right across the incoming enemy lane, that seems dangerous...<br />
<br />
Well, it's the same thing no matter what the theme of the game.<br />
<br />
My space ship should face the challenges I want it to face, and that will test the setup I created.<br />
<br />
Not a spreadsheet, but a living entity that responds and changes on a local level.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-31911008914653377382019-07-23T09:50:00.002-07:002019-07-23T09:50:35.342-07:00Making Things Seem BiggerOne thing I love about video games is that I can make things as big as I want.<br />
<br />
However, I've quickly learned that bigger isn't always bigger.<br />
<br />
The human brain uses a lot of specific techniques to "feel" how big something is, and those are not the same techniques a game uses to render bigger things.<br />
<br />
As a result, a lot of indie content is overly huge... but doesn't feel big. It just feels boring.<br />
<br />
So my focus now is on how to make content feel bigger without actually making it that big.<br />
<br />
This shares a lot of techniques with various architecture, theme park, and interior design practices, but it's distinct from them because we're working with something that doesn't actually exist.<br />
<br />
With that in mind, here's some half-formed ideas I had about it. Feel free to chime in.<br />
<br />
---<br />
<br />
One thing is to "clutter" the right amount.<br />
<br />
Say you have a 10mx10m area. That's about the footprint of a small house. How do you make it feel big?<br />
<br />
Well, one way is to declutter. If the area is wide open, flat, and brightly lit... it'll feel bigger. But it'll also feel empty and pointless when you move through it.<br />
<br />
Another way is to clutter. For example, if we put in islands of furniture, maybe add some pillars... we can add a lot of density to the space. In this case it will feel smaller to the eye, but it'll feel much larger and more interesting when you actually move through it.<br />
<br />
We can probably get the best of both worlds by using "zoning" tactics instead of simple clutter tactics. For example, using different flooring types to cut the room into areas, adding a raised or lowered section, creating drop ceiling elements, using ceiling topology to create complexity up high, adding lights that create patterns or focal points in the corners... these keep the room feeling large to the eye, but still make it feel detailed as you move through it.<br />
<br />
If I was creating a complex level, I might focus on decluttering on neighboring spaces the player won't travel to much, so I can make them physically smaller but feel like they are quite large when glimpsed by the player. Spaces with dense gameplay, I might use clutter to reduce travel times and create overlapping concerns. Spaces with a moderate combination of both gameplay and travel might focus more on zoning...<br />
<br />
This is a really basic example, but I wanted to show that what I'm thinking about is not simply "how to make things look bigger", but "how to make things feel bigger as you move through them". After all, video games are interactive.<br />
<br />
---<br />
<br />
If you are walking up to a space ship, how can you make it seem like a really big space ship?<br />
<br />
How about if you're flying up to one? Swimming? Teleporting?<br />
<br />
Controlling the kind of movement the player is using is critical, because that's how you amplify the size of a ship.<br />
<br />
For example, if the player is walking on the outside of a ship, the ship is basically terrain, very close to the player's face. Even small ships like fightercraft can feel very large if you're clomping across their wings in magnetic boots! They'll feel even bigger if you're going hand-over-hand along a guide rail, your helmet a mere foot from that same wing surface...<br />
<br />
If the player is coming in from a distance, it's important to allow them to feel the distance of the ship by giving them nearby motion. For example, walking through gates, or passing through a cloud of debris, or walking past parked cars. To amplify this, the nearby motion does not have to be parallax: as you approach the ship, cars drive past you away from the ship. Barriers lift in front of you. The wind kicks up a dust storm. These motions will help to give the ship a sense of scale, even though they're not technically parallax.<br />
<br />
The ship itself is also optimizable.<br />
<br />
One thing you can do is simply add elements of scale to the ship, like a heavy crane loading up cargo, or a worker squatting on the wing, touching up the paint. These are things that we think we understand the size of, so our brain will naturally get a feel for how large the ship is. If they're slightly undersized as compared to what we expect, then the ship will feel oversized: workers should be crouching or kneeling to reduce their apparent size, cranes can be built with "heavy industrial" feel even when they're medium industrial size, etc.<br />
<br />
The ship itself has a particular layout that can be optimized to create parallax. Smaller ships should have protrusions and/or limbs: head, wings, engine nacelles, antennae or cannons that stick out. These need to stick out in directions that create parallax: having an antenna stick up is good to create a sense of presence, but it doesn't create any parallax unless it's sticking outward. Things like antennae should have lights at the tip: this will make the parallax clearly visible and also make the ship feel larger at greater distances since the lights will define a perimeter.<br />
<br />
Larger ships can be thought of as places rather than things. For them, it's more important to create an approach vector that creates nice views, rather than having protrusions. If the player is moving towards a large ship on a curved approach to dock or enter on a specific spot, that will allow the player plenty of time to see the parallax grow as they get close. However, if the player is approaching on a direct path, the parallax will be minimized.<br />
<br />
Entryways like docking bays and gangways should be nestled into concave areas. The surrounding protrusions will create a sense of parallax as you move towards or away from the entrance. So... overhangs, side braces, giant clamps, whatever you can do.<br />
<br />
You can also use "bristles" on ships, large or small. Any kind of semitransparent lattice will work, with the idea being that regardless of your approach vector, these will have noticeable parallax. Lighting concave areas and areas behind the "bristles" will also produce a lot of changes as those regions become more or less visible due to parallax.<br />
<br />
If the ship has large topologically uninteresting zones, add lighting or paint elements to create demarcations. They don't have to be visible at large ranges, they're specifically to break it up when the player gets close, so faint greebling or motion-sensor lights are plausible.<br />
<br />
In addition to parallax tricks, you can use a million other tricks. Small ships can "bulk up" when parked by raising their wings, opening their canopies or fueling covers, half-ejecting fuel rods. How heavy they feel is also a factor: do the feet sink into the ground? Does the howling wind knock their antennae around but leave them unbudged?<br />
<br />
There's also things like atmospheric effects, depth of field, and converging lines to think about... placing a parked ship noticeably above or below the horizon will make it seem closer, while on the horizon it will feel further away. Therefore, small ships should park on the horizon line and large ships should park above or below it... keeping in mind that the player's horizon line is determined by camera height, not by eye height or walkway height, so approach vectors should have ceilings to force the player's camera into a predictable horizon line.<br />
<br />
And that's just the exterior...<br />
<br />
---<br />
<br />
Making areas feel big on the interior is perhaps even more critical, because you don't want the player to have to walk long distances inside of a building or space ship. So things need to feel big without being big.<br />
<br />
Level design conversations about this are not impossible to find, but here's some basic tips I'm eager to try:<br />
<br />
Windows or overlooks onto interior spaces, not just exterior windows. Central spaces with complex traffic patterns, including multi-floor elements.<br />
<br />
Clean straight paths through cluttered rooms with a clear view of the next room, curved paths through larger, uncluttered rooms...<br />
<br />
Light the corners more aggressively than usual, but while remembering to break the cubey feel of corners. IE, stick well-lit furniture into corners.<br />
<br />
Use cut-out alcoves to create workspaces, rather than putting workspaces into the main floor area.<br />
<br />
Trying "false windows" instead of Jefferies Tubes: IE, a grate or transparent panel with a largish, lit area behind it.<br />
<br />
Having screens default to scenery instead of black.<br />
<br />
Using the wall lines common in sci fi to enhance the size of the room instead of just making it feel cluttered. This is easiest on scales larger than a small hallway: for example, in cargo bays. One critical part of this is to use lighting in any sci fi recesses: IE, if you have a head-height outwards bend, put lights in it.<br />
<br />
Use furniture/functional elements that take the room's major axis into account. For example, if I want a hallway to feel shorter, I can use vertical banding (braces and bulwarks). If I want it to feel longer, I can use horizontal banding (stripes and shelves).<br />
<br />
Using small rises and falls, both in large rooms and in chains of small rooms. The rising and falling can be floor, ceiling, or both.<br />
<br />
Create centerpiece elements that aren't actually in the center of the room, since players shouldn't be using 100% of the room evenly. Centerpieces should make the room feel larger when you're passing by, and usually only one or two edges of a rectangular room are travel lanes.<br />
<br />
Interrupt the flow of a room logically, but not visually. Using glass, transparent hologram, floor and ceiling patterns...<br />
<br />
And I want to try adding things like diffusing drapes and frosted glass rather than just big heavy metal doors.<br />
<br />
---<br />
<br />
So that's what I've been thinking about this week.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-28958872127654624782019-06-18T08:49:00.000-07:002019-06-18T08:54:11.517-07:00Space Survival GameplayI was asked a little while ago how I would do a space survival game, since I've been ragging on them recently. I also mentioned it in a video or two. So let's talk.<br />
<br />
Let's get started simple. Let's say I'm a Star Citizen dev, out to put survival mechanics into my pew pew shooty game. I already have gorgeous starship interiors, now it's time to leverage them. How do I do it?<br />
<br />
Well, my goal is to turn survival into a yarnball. A soft, complicated challenge that interlaces with a lot of other things. I also want to make sure that it unfolds into a narrative according to the choices the player makes.<br />
<br />
So I implement a The Simslike survival system. Every time you make a space jump, your various meters go up. Hunger and filth, for example.<br />
<br />
Actually using kitchens and showers is a repetitive and uninteresting task, so rather than requiring you to use the facilities, we simply reduce the meter if you have them. If you have a kitchenette, your hunger goes up 90% slower. A full kitchen? It doesn't go up at all... until your food runs out.<br />
<br />
We do want to push the player to exist in that space, so we do allow the player to use a facility for a temporary boost - until the end of the next jump. If we use the kitchen, we get a +20%, but it uses up a bit of food. If we use the shower, we get a +10%, but it doesn't use up anything. This bonus doesn't reduce your meters, it simply enhances your performance. It doesn't stack.<br />
<br />
To make this into a more narratively cohesive experience, we have to decide on the narrative we want. And the narrative we want is how the pressures of space travel shape our life aboard a ship.<br />
<br />
This is not simply about "life aboard a ship". The point is to turn challenges - the challenges of a human surviving in space - into narrative beats. The ship is our tool to do that, but the challenge it parses is the challenge of survival.<br />
<br />
If we want a gritty feel, we could get things like life support involved. But the ships in Star Citizen are ridiculously high tech, so instead we're thinking more about the social narrative. How does the mind fail, rather than the body.<br />
<br />
So we add a few more meters. Loneliness, claustrophobia, boredom.<br />
<br />
When they go up, you have to bring them down. Find someone to talk to. Land on a planet or space station and step outside. Have some fun by daredevil flying or fighting or driving a different vehicle.<br />
<br />
...<br />
<br />
A new player buying a new ship finds it comes with a little pocket gym. The gym reduces the meter growth of those three stats by 50% each, maybe.<br />
<br />
But the player knows they are playing solo, and are planning to go on long explorations. So the big threat here is loneliness. The others can be dealt with in the middle of nowhere by visiting any random rock, but finding a person will be tough.<br />
<br />
So the player rips out the gym, replaces it with a media console that constantly blares news shows and comedies. She puts portraits of her family on the wall, or pinups maybe. She buys a wisecracking robot companion.<br />
<br />
These keep her company. And she can use them to boost: give the family a kiss, get +30%. Watch a TV show, get +40%, but use up a media slot - she'll need to buy the next season of Game of Space Thrones or trade SpaceYouTube caches with someone else to get those slots filled up with new stuff. Better to keep that cache intact, so it burns at the slower default rate and lasts longer.<br />
<br />
And sure, she gets twitchy from the claustrophobia and the boredom. But that's why canyon racing was invented.<br />
<br />
...<br />
<br />
On the other hand, someone else might be playing on a team. They know loneliness won't be an issue, because there's another player around here. So they max out the others. They buy giant 3D landscapes for their walls - radically reducing claustrophobia, but actually increasing loneliness. They replace their gym with a video game console.<br />
<br />
They can go for a long ways without having to land or play around, but they have to chat with someone every two jumps to stay happy.<br />
<br />
No problem, they're sitting next to you.<br />
<br />
...<br />
<br />
We can see how the player's construction choices change the narrative. The player is choosing what narrative beats to include, which ones to play up or limit. One of those players is having a long, lonely journey hopping from planet to planet. The other is on a road trip with friends.<br />
<br />
Those are very different narratives. We didn't write those narratives: we allow the challenges to be faced in a way that turns them into narratives.<br />
<br />
We can push this in a lot of ways. For example, if we make it so that talking to a specific person works worse every time you do it, then those long journeys get more challenging because you have to find new people to talk to. If you burn media to keep your boredom under control, maybe you change one of those "size three hardpoints" from a gun to a giant subspace antenna that lets you transfer media from space stations a hundred light years away. Need food? There's a variety of greenhouses both internal and external...<br />
<br />
These ramifications are polish on a core concept. If we didn't have the core progression, they'd be pointless. Most of this would be pointless if the player had to return to a station every time they logged off, for example: long journeys would be limited by a player's capacity to sit at their desk and play. But since you can log off in midjourney and come back, we can assume many players will go on very long journeys.<br />
<br />
The question becomes: what of the players that don't?<br />
<br />
What about the players that are short-haul? Players that specialize in fighting or shipping people or freight over shorter distances?<br />
<br />
It's a common thing. A lot of players want to sit and do A Mission Now, and be done in half an hour. They don't want to log off midmission and come back to the same thing.<br />
<br />
Can we make our survival systems create their narratives, too?<br />
<br />
Well... no. It's not survival. But we can use the same core mechanics.<br />
<br />
...<br />
<br />
We could try to add stats like paperwork that go up as you dock... but what sort of narrative unfolds with that?<br />
<br />
Not much of one. How can we make it messier and more entangled?<br />
<br />
Well, most short-haul specialists will have specific hub stations - or, at least, specific preferred factions.<br />
<br />
This is where it can't be Star Citizen, because their faction system has a ceiling. But if we throw that away, we can allow the player to build their contacts with the faction.<br />
<br />
Rather than focusing entirely on the ship, we can allow the player-generated content to include people. Both NPC crewmembers aboard your ship and people you have agreements with on various space stations.<br />
<br />
I would do it using a similar modular setup to the one used for ships and interiors:<br />
<br />
As you rank up, you get a better "dossier" for that faction.<br />
<br />
Like a ship, a dossier has specialties and hardpoints. This dossier specializes in freight permissions. This one improves insurance and rates on being a passenger liner. This one's exploration-based.<br />
<br />
The hardpoints are people. This one's a tier 3 diplomat hard point, and you can slot in any NPC diplomat that rank or lower to act as your "weapon", giving you access to more options, more goods, more security, more sites. Reduce the rank by one just like you'd do for hardpoint turrets, and hire that person as a crewmember on your ship instead of being specific to their home space station...<br />
<br />
Because the dossiers are essentially ships, we can offload our survival mechanics onto them.<br />
<br />
As time passes and things happen, you might gain criminality, or disinterest, or distrust. These can be reduced if you equip the right kind of person on your hardpoints, but otherwise you'll have to do faction missions to clean them up.<br />
<br />
And now, again, we've turned a challenge into a narrative.<br />
<br />
Building small dossiers is easy, but you quickly learn you need to tweak it to suit your style. Do you do some... not so legal missions? You'll want a lawyer and a fence installed. Do you do a lot of business with other factions? You'll want a politician, to keep the distrust low. You go on long journeys? You'll want a reporter, to keep disinterest under control. You trade with a lot of different systems from that faction? Buy a one-rank-lower trader as a crewmember, so you get that advantage in every system.<br />
<br />
These could even be tweaked per-faction. Both by the player, depending on their interactions with the faction... and by the devs.<br />
<br />
Your Vulcan-ish faction might never gain disinterest, but gives bonus distrust if you sell science data to other factions. Your Klingon-ish faction loses interest extremely rapidly but never gives out criminality...<br />
<br />
This has an extremely high ceiling. At upper levels, you might be adding the president of a space station to your dossier, or using a cross-contact politician to transfer stats to another faction's dossier.<br />
<br />
And you can go negative. You're disliked by the Vulcan-ish faction? Add specific nemesis to your unhappy dossier. It's got a few good hard points - contacts from other factions or even turncoats from this faction - but you have to fill all your negative hardpoints first, adding in suspicious cops, angry politicians, and persistent bounty hunters.<br />
<br />
Again: build your own narrative out of the challenge. *You choose* how your story of banditry or war unfolds.<br />
<br />
...<br />
<br />
Hopefully this has been a fun exploration of how to make player-created content that can turn simple things (survival, faction rank) into more robust, soft, complex mechanics that create a narrative.<br />
<br />
To be clear: I think you could create an entire game around these concepts, rather than the shooty pew pew gameplay that I find so dreary.<br />
<br />
There's also a lot to talk about in regards to things like resource tiering and keeping inflation under control, and it's tightly related. But... I think this is long enough.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-21802379788406251082019-06-11T08:05:00.000-07:002019-06-11T08:05:19.409-07:00Boiling the YarnballI've been thinking about why I like the construction games I like.<br />
<br />
I'm including things like The Sims into this category. Whether you're constructing vehicles or facilities or people, there is one specific feel I like, and a bunch I don't.<br />
<br />
I think it's yarnballs.<br />
<br />
Big, soft, messy challenges that can be approached in a lot of different ways with a lot of different entanglements to the rest of the game.<br />
<br />
For example, you're playing a space game. The rules are: you must have one point of life support per astronaut.<br />
<br />
This is a small, hard constraint. There's no softness, no flexibility, no entanglement... no mess.<br />
<br />
But in Oxygen Not Included, that rule is turned into a yarn ball thanks to the physics sim. I can create drafts of carbon dioxide, let rooms sort themselves into bands of gases and keep people in the oxygen zone, let them breath diseased oxygen, use pressure gates to optimize pressure for ideal algae conversion...<br />
<br />
A combination of complex approaches (scrubbers, cleaners, algae, natural oxygen sources, etc) combined with complex topological possibilities (pressure, natural air sorting, air filtering, wind, etc) creates a lot of possibilities, a lot of bizarre, fun approaches that affect everything else in my facility.<br />
<br />
It's not me balancing a spreadsheet. It's me building a facility, with all the complexity that entails.<br />
<br />
One thing that makes this yarnball approach shine is how it ties into the rest of the construction, and how it turns a challenge into a narrative. <br />
<br />
Challenge: you need to provide air. <br />
<br />
Narrative: "the third and fourth floors of our Mars base are pressurized. Whenever we venture down to the first floor to change out the algae, we hold our breaths and work fast. Sandra got real sick when she couldn't hold her breath long enough."<br />
<br />
<br />
<br />
The thing about yarnballs is that you do, eventually, sort them. Maybe not to some perfect standard, but you develop a method that works for you, and you'll usually stick with it.<br />
<br />
That's why it's so important that the construction game is a huge pile of yarnballs.<br />
<br />
If I sort one, there's another behind it. <br />
<br />
More importantly, as I sort that one, I realize it's tied to the first one, and I didn't sort it well enough!<br />
<br />
This creates an endless chain of narratives as I watch my facilities struggle with challenge after challenge, all their difficulties largely being my fault.<br />
<br />
<br />
<br />
Another example of a yarnball is having children in The Sims. <br />
<br />
Not only are the children themselves fairly complex, but caring for them is a convoluted, messy yarnball. You may think you have it solved, but then you realize your stay at home parent this time is a neat freak or something, and your timetable falls apart.<br />
<br />
Or how about building a defensive entrance in Dwarf Fortress?<br />
<br />
You have to deal with the threat of invaders, so you build a defensive gate. But how big is it? How do people get through it on their daily lives? How many resources can you afford to spend on it? What traps can you build? When you need to upgrade it, how will that work out?<br />
<br />
And when the invasion happens, the gate helps turn the rather blunt narrative of "you lose, everyone dies" into a more nuanced narrative: "Bjornblatt lost an arm fighting off the goblins that got through the traps, and Hjornol is now responsible for rebuilding those traps into something more effective..."<br />
<br />
<br />
<br />
I think yarnballs require a certain presentation to catch my attention.<br />
<br />
I call it "boiling the yarnball".<br />
<br />
This is a technique where nearly all of the game is incremental. In The Sims, your skills slowly go up, money slowly trickles in, you slowly do better at your job. In DF, you slowly farm, slowly build another bunkroom. It's all incremental.<br />
<br />
Except then it's not. There's a challenge you're working towards.<br />
<br />
In The Sims, is it time for a kid? Time to move? Time to get a promotion? Maybe just time to throw a big party?<br />
<br />
In DF, is it time to build a defensive gate? Internal waterways? A magma forge? Maybe just time to rearrange who sleeps where?<br />
<br />
What the player considers to be "a big thing" will vary depending on skill and interest. But you're usually working towards at least one big thing. You're playing the game to push the edge of what you can do, what you understand.<br />
<br />
If the goblins trashed you last time, this time you're playing to build goblin defenses. If your sim died old and alone last time, this time you're playing to make a family. You build towards those challenges, and some part of your construction is difficult and challenging... because you haven't mastered that yarnball yet.<br />
<br />
So the premise here is that the yarnball isn't thrown at you. It's something you walk up to. Something you explore.<br />
<br />
The challenge that creates the yarnball might not be so gentle. The goblins will eventually attack. You will eventually get old and die. But you have some leeway before then.<br />
<br />
Otherwise, there's not enough time to try and detangle the yarnball.<br />
<br />
<br />
<br />
So I like to "boil the yarnball". You let the challenge that defines the yarnball simply sit there and simmer. When the player's ready, they can begin pulling at it... at which point, the narrative becomes more concrete.<br />
<br />
To make it more concrete, I think there are four phases to this. I'm just getting started with my thoughts on this matter, but here's what I've come up with so far.<br />
<br />
1) Planning<br />
What challenge does the yarnball address? How will that challenge affect your facility? How will different levels of addressing it change that? How much space do you have to build in? How many resources do you have? How many workers can you divert, for how long, before things get risky? <br />
<br />
Tie the planning into the overall flow of your facility, so it becomes part of the narrative: "in fall of 392, we began to defend ourselves. As harvest season ended, the farmers turned their hands to construction..."<br />
<br />
2) Construction<br />
Did you plan it right? What goes well? Poorly? What opportunities do you seize, or threats do you face that affect your construction efforts? Again, the construction is part of the narrative of the facility: "The great iron gates in the plan were changed to wood, at the request of the lord of the land, whose brother owns a lumberyard..."<br />
<br />
There should be no real randomness in the mechanisms of construction. The randomness comes from outside: "oh, there's a gold seam where I wanted to put a wall. Oh, my workers are throwing tantrums because of the rain..."<br />
<br />
3) Daily life<br />
How does your construction affect things that aren't that challenge? The 'daily life'? What new opportunities does it create? What troubles? How does it integrate into your normal daily narrative?<br />
<br />
For example, "The gate lay open, guarded by a single lookout. The lookout became very good friends with the hunters and lumberjacks, as they passed by nearly every day..."<br />
<br />
4) Spotlight<br />
How does your construction actually do its job? Specifically, how does it change a challenge into a narrative?<br />
<br />
For example, "When goblins attacked, our lookout was slacking. Several got through the gate before it could be closed. Fjornblatt is fighting the intruders while, outside, torches are being lit..."<br />
<br />
<br />
<br />
Each of these four phases of a yarnball helps to cement the narrative of the overall facility. The yarnball is positioned specifically to turn a challenge into a narrative, not just in the moment that the challenge arrives, but in an unbroken chain throughout the course of planning, construction, and daily life.<br />
<br />
If you turn this idea towards other genres, you can see hints of it in other games. Coincidentally, those tend to be the games I like.<br />
<br />
In an open world RPG? Building a character is several yarnballs. Watching the character face the challenges I intend them to face is great fun, as is watching that build struggle through challenges not related to their specialty. That's the part of an open world game I like.<br />
<br />
Contrarily, without boiling yarnballs, even games in genres I like aren't very interesting to me.<br />
<br />
For example, most "factory builders" where you assemble cars or medicines or whatever don't hold my interest. Either because the optimizations are all very cut and dry, or because the yarnball isn't presented in a way that helps me digest it.<br />
<br />
<br />
<br />
How about you? Any of this fit into your idea of what's fun and what's not?<br />
<br />
Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-1554728230479546702019-04-19T08:37:00.000-07:002019-04-19T08:37:06.294-07:00ModdingI love mods, and people are talking a lot about mods, so let's do more talking about mods.<br />
<br />
A lot of people are annoyed that Unity and Unreal don't make modding easy... but modding has never been "easy". <br />
<br />
Flash, CryEngine, IdTech, RPGMaker... none of them are "moddable" right from the ground up. Modding has always been something the devs decide to include.<br />
<br />
With that in mind, we can talk about mods in two ways. From the perspective of the person installing the mod ("player"), and from the perspective of the person making the mod ("creator").<br />
<br />
---<br />
<br />
From the player's perspective, there are probably three kinds of mods:<br />
<br />
<b>1) Piecemeal Content</b><br />
This is content that will almost never conflict with other piecemeal content, except in the most trivial ways. Piecemeal content is probably the most popular kind of mod, including things like recruiting other players' characters, sharing messages about sun-praising, downloading vehicles from the workshop, adding new skins, etc.<br />
<br />
<b>2) Local Content</b><br />
This is content which will conflict with any other content in the same locale. For example, if you install a mod to turn you into Bayonetta and a mod to turn you into Link, they won't get along. Similarly, you can't be in two levels at once, two missions at once, etc. <br />
<br />
Local content can be turned into piecemeal content if you add a tool to help the player manage this kind of conflict - for example, Bayonetta and Link can both be "skin options" instead of simply overriding your appearance.<br />
<br />
<b>3) Core/Process</b><br />
Some mods change fundamental rules of the game. For example, Skyrim mods that make character progression different, or change how weather works, or make you need to eat and sleep, or make the shaders work better. <br />
<br />
Sometimes the mods are completely invisible, such as mods which allow other mods to work, or mods that clean up memory usage. <br />
<br />
Frequently, core/process mods are part of a chain of required mods, like 'install the event mod, then the silent talking mod, then the progression revamped mod, and only then you can install the custom skill pack'.<br />
<br />
---<br />
<br />
The reason to think of mods like this is simple: it helps us to think about how mods work within our game. Can our game support piecemeal content additions? If the gameplay allows for certain kinds of piecemeal content, what is required to surface that and allow the players to load it in? If the game can support local content, can we change the way our game presents it to turn that into piecemeal content?<br />
<br />
Can our gameplay support core/process mods? Can our game architecture? Can we revamp it? Can we create a tagging system so that we can have mods say what other mods they require, at what version?<br />
<br />
The answer is rarely a flat yes. This kind of thing is a bit difficult to engineer, and it may damage your core gameplay. But even a small amount of moddability is a good thing, and you can leverage it to either make your game more appealing or make your game stickier.<br />
<br />
For example, in Guacamelee, the only kind of moddable content is custom skins. However, they sent out custom skins to popular YouTubers, enticing them to play the game and be more positive about the experience. The modding made for great outreach.<br />
<br />
---<br />
<br />
The other half of the equation is how the creator of the mod thinks about the mod. This is equally important.<br />
<br />
<b>1) Diegetic assembly</b><br />
When the creator never leaves the game to create the content. In the best case, the content is created simply by playing the game, but nearly all of the time this is an in-game editor. For example, you create your character, build your ship, assemble your house - all using an in-game editor.<br />
<br />
The key here is that diegetic assembly happens <i>in the course of normal play</i>. A character builder counts because every player will use it at least once and consider it part of their playthrough, their experience. A mission editor generally doesn't count, because it's never used in the course of playing the game.<br />
<br />
There is a challenge to keep the editor simple enough for everyone to use but powerful enough to let players create complex or nuanced results. There is also a challenge to leverage the editor: a character editor for a game where you only create one character is not as well-leveraged as a game where you create multiple characters over the course of the game.<br />
<br />
Compare The Sims' character editing to Fallout 4's.<br />
<br />
<b>2) Tool-assisted assembly</b><br />
The creator uses a separate tool to assemble the content. This tool may be in-game, such as a mission editor. It may be out-of-game, such as photoshop or visual studio or even just notepad. Either way, this is a thing the player has to go and do, separate from playing the game.<br />
<br />
This is quite a hurdle. Few players will go and use a tool that is not required over the course of play. Because of this, it's usually ideal if you can leverage a tool in both the main gameplay and as an asset creator. Normally this is done by using the same tool, but having a creative mode where the player's specific play constraints are relaxed.<br />
<br />
Done well enough, this turns into diegetic assembly.<br />
<br />
Core/process mods are a good example of mods that are almost always created with tool assists. It is exceedingly rare for a game to allow its own rules and progressions to be overwritten in the course of play. Normally these mods are created with visual studio or notepad, the code then injected back into the game.<br />
<br />
<b>3) Hacked assembly</b><br />
If the creator has no way to add their mod to the game, they may hack the game to force it to accept the new content.<br />
<br />
You might consider this similar to a tool-assisted mod at first glance, but a tool-assisted assembly uses an injection method the developers intended for modders. That text you edited, that DLL you compiled, the game goes out to look in that directory for those things because the dev decided to support those kinds of mods in that way.<br />
<br />
Hacked mods usually take advantage of things the dev accidentally left available instead of intended for mods. For example, they might be "trainers", hacking the game's memory space to give you infinite health or cash. Or they might overwrite the game's core assets with new assets.<br />
<br />
As a game dev, hacked assembly is something to avoid. Mods assembled via hacking almost always conflict with other mods just due to how they work, so it's best to try and create a proper interface for mod injection.<br />
<br />
---<br />
<br />
When I think about mods, that is how I think.<br />
<br />
What kinds of content can be injected? What kinds of tools can I use to make that injection easier, more useful, more potent?<br />
<br />
What methods of creating content are there? What kinds of interfaces can I create to help modders create mod packs and chains of mods that don't conflict?<br />
<br />
Unfortunately, no game engine natively supports this kind of thinking, because it's part of every individual game's unique design. There's not really any low-hanging fruit here: you have to design your game to be modded.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-72968476714883790002019-02-20T09:46:00.000-08:002019-02-20T09:46:21.651-08:00Adaptive Modules in Construction GamesOne thing I like in construction games is being able to create different modes within a creation. For example, a car that can turn into a jet, or a space ship that can switch between science mode and warp speed mode.<br />
<br />
Very few games reward this kind of thinking due to one big constraint: single-purpose, static modules.<br />
<br />
Non-adaptive modules.<br />
<br />
For example, if I want a space ship that can switch between science and warp speed mode, there has to be some advantage to switching rather than just being in both modes at the same time.<br />
<br />
But the modules for science and warping are always the same size, always the same configuration, always require the same amount of power, etc, etc. The only "switching" we'll likely do is simply turning one or the other off to save power, rather than something that creates a fun visual or play impact like sliding parts around, expanding or shifting, etc.<br />
<br />
There are a few ways to create the opportunity for players to build adaptive designs, and they all boil down to adaptive modules. Here's some types.<br />
<br />
<br />
1) Folding modules. <br />
<br />
If our science and warp elements can both fold down to take up less space, then we can have them share their expanding zone. To allow for more interesting results, we'll want to allow for at least some adaptiveness in the folding. Perhaps science modules come in a variety of shapes and expansion zones, while warp engines can expand arbitrary amounts, allowing us to pick and choose exactly how much space they share, when. <br />
<br />
This can get even more complex with things like power capacitors and tanks being extended when full, etc.<br />
<br />
The folding can also be complexly related to the flow of ship resources. Perhaps the science devices unfold and create a new control room people can walk into, meaning it has to be butted up to the pressurized section. Or maybe it has in/out fluid flow, and the position of the outlets changes as it inflates...<br />
<br />
<br />
2) Expensive timing elements. <br />
<br />
If our science and warp elements take quite a bit of juice, simply turning them off and on is important. But to make things feel meaty, simply turning things on and off won't work. We need timing elements.<br />
<br />
Perhaps the computers take a little while to boot. The engines need to spool up. The science sensors require a massive influx of water to extend.<br />
<br />
To make this really meaty, give us the option to accelerate the timing with outside resources. Computers boot faster if other computers lend it processing power. Engines spool up faster if you use a flywheel assist. Science sensors expand faster if you send them water faster.<br />
<br />
Note that these all start up fine with no assist, it's a matter of time savings. That way, even newbies can create this stuff, no need to wire it up in a complex way to just get it working at a baseline level.<br />
<br />
<br />
3) Incompatibilities. <br />
<br />
If modules are incompatible, then turning them on and off is an important technique. To make this especially meaty, the incompatibility should be manageable in some way if you make your ship clever enough.<br />
<br />
For example, the warp drive spits out a ton of radiation noise when active, rendering science sensors useless. Computers vibrate when in use, radically lowering the performance of nearby modules. Science sensors require 180hz power, while warp drives require 30hz power.<br />
<br />
These incompatibilities mean you can't simply throw more power at your systems to have them all on at the same time. But you can design cleverly. Have an extending strut move the engine away if you need science sensors on at the same time. Have the computers on their own module off to the side of the ship. This gives a reason to create fun, unusual designs.<br />
<br />
<br />
4) Service requirements.<br />
<br />
Requiring human access can make your ships very interesting to design. Why is the engine on a piston rather than permanently floating way out behind the ship? Because that brings it in line with the rigging, so spacewalkers can get to it quickly and easily for maintenance purposes.<br />
<br />
This does require you to put in some adaptive human access options. Extending ladders, cables, etc. But those also look great, so they're not a bad call!<br />
<br />
<br />
5) Stacked modules.<br />
<br />
It may seem obvious that every identical module should have identical requirements, but for the sake of making things meaty, the opposite is true. <br />
<br />
If modules are stacked on top of each other in a specific way, they should have different performance stats and require subtly different resources. IE, every science sensor arranged in an exact row performs better than the last, but requires power at a higher hz, or requires more cooling.<br />
<br />
This will allow players to stack or destack modules to fit their personal vision and constraints. One player might have five stacked science sensors and a big module for providing them with their complex support needs, while another player might have ten unstacked science sensors... requiring more people and more space, but without the complexity.<br />
<br />
<br />
6) Careful design of multipurpose baseline elements.<br />
<br />
Obviously there are baseline elements constraining your operational modules. The most obvious example is electricity, used in nearly every construction game. Other examples might be fluid, food, computation, etc. <br />
<br />
Designing these carefully is the key. You want them to inspire specific layouts all on their own.<br />
<br />
The easiest way to do that is to make categories of element, then allow a multipurpose system to handle anything within that category. This allows for the same infrastructure to serve multiple roles, while also creating bottlenecks. For example, pipes can handle water, fuel, oil, air, exhaust - anything that flows. Players can create huge numbers of dedicated pipes or fewer pipes that take up less space if they can figure out how to switch the load on the fly...<br />
<br />
The basic approach I use is designed to make these baseline elements inspire interesting configurations.<br />
<br />
a) Flow types: one type of module moves the generic resource around, one type collects it in a spot (often adaptively sized), one type pushes or pulls it, one type transforms or creates it. For example, pipes, tanks, pumps, intakes. Or network cables, tape archives, sensors, and computers.<br />
<br />
This four-fold approach gives me a flexible way to drive different layouts by simply changing which elements take up space in what kinds of ways, or require which secondary resources to run. For example, there's a huge difference between tanks that can expand and tanks that can't. Similarly, there's a huge difference between pipes that take up one voxel space per pipe, as opposed to network cables, where you can bundle any number of them along the same one-voxel channel.<br />
<br />
b) Reward both centralization and decentralization. There's beauty both in duplication and in centralization. People should be able to find a cool way to implement "a hundred pipes" approach, but also be able to implement a cool "one big pipe" approach.<br />
<br />
In general, one big pipe is what players will tend to rely on if they're just piping lots of one resource. If every module requires water, there's going to be one big water pipe. But as the resources get more varied, the player will tend to go for multiple pipes. Whether this is different temperatures of water, or different fluids, creating converters or mode switching is overhead some players do not relish.<br />
<br />
Having resources that vary inside themselves can be very powerful, especially if they can change state and be moved in another way.<br />
<br />
For example, if the engine needs fuel... well, maybe each stacked engine performs better, but prefers fuel injected at a hotter temperature. Therefore, the fuel subresource varies on another axis (temperature), making wrangling it more complex without requiring any extra content. Clever players might supherheat the fuel into gas for fast transit, or even freeze it into wax for long-term storage.<br />
<br />
Either way, this complexity should arise only as the player embraces it, since this complexity can create a difficulty cliff.<br />
<br />
c) Allow suboptimal setups. Allowing the player to fall short while still having a decent result is critical, both for players that aren't great at construction and for players that are trying to be very clever.<br />
<br />
An example of this might be if the science sensors require computation to run. If the player doesn't have enough, the science sensors continue to function, but at a reduced rate. Even at zero computation, the science sensors should still function a bit.<br />
<br />
You can make this more complex by creating pseudogenerics. For example, the science sensors require quantum computing. Any kind of computer can generate quantum computing, but at less than half speed if they aren't quantum computers. This allows players to use somewhat unsuitable setups in a fun way.<br />
<br />
Similarly, you might have pumps specialized in fluids... but they can pump gases a bit. Or visa-versa.<br />
<br />
Combining these elements means the players have a ton of flexibility. It also makes for the opportunity for them to add complexity by creating switching systems to use the proper pumps/computers when required, while reusing the same generic flow containers (pipes/wires).<br />
<br />
Allowing for extremely high-performance single-use elements is fun as well, but make sure they have other constraints. IE, the fuel-only pump requires tremendous cooling...<br />
<br />
<br />
<br />
... anyway, them's my thoughts on the matter.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-90485001378382748332018-09-10T13:24:00.000-07:002018-09-10T13:32:13.519-07:00Character-Driven Game DesignWell, another day, another trailer.<br />
<br />
These days, a lot of video game teasers and trailers are animated shorts with no relation to the gameplay. Today, League of Legends posted a teaser about an energetic, funny space ship crew and asked you to join up.<br />
<br />
Of course, it's not an energetic, funny space ship crew game. It's League of Legends, meaning it's a MOBA - a plodding arena combat genre known mostly for toxic team play. In short, not energetic, not funny, not character-driven.<br />
<br />
This is not a one-off. Virtually every major action game has been releasing character-driven shorts of extremely high quality and pretending it has something to do with the game in question.<br />
<br />
It reminds me of the old days, when the cover art sold the video game. Except, of course, the cover art would be some Vallejo painting and the game would be eight pixel high sprites jumping from platform to platform.<br />
<br />
Given the response I and many others have to these teasers, it's clear there is an interest in high-energy, cinematic, character-driven experiences.<br />
<br />
But no games like that ever seem to come out.<br />
<br />
Let's talk about it!<br />
<br />
<h2>Hangin' Out, Havin' Ourselves a Parrrrtaaay</h2>There are games with strong characters. For example, Telltale-style adventures. However, you can't really "hang out" in those games. The narratives are character-driven, but the games are narrative-driven. This is a bad fit for me: I care a whole lot about the characters I'm hanging out with, and the distraction of being told to uncover some ancient secret while fighting off invading ninjas just weakens the experience.<br />
<br />
There are games where you can hang out. For example, open world RPGs. However, while you can hang out in the world, you can't really hang out with the characters. They're programmed to only really respond to specific world events. Worse, semi-open RPGs like FFXV or Dragon Age often ruin the hangingoutness with dull filler and melodrama in equal measure.<br />
<br />
But I mod games. A lot.<br />
<br />
A modded party member has the disadvantage of not being in the core event structure. They aren't introduced in some blazing cinematic, and they don't have loyalty quests.<br />
<br />
This means that the modded party member has to make their presence known during normal play. <br />
<br />
A lot of modded party members tell stories, crack jokes, sing songs, and randomly comment on anything and everything the game has to offer. This ends up making them feel more real than the core party members, at least if you're the kind of player that randomly wanders the world and never bothers progressing the plot.<br />
<br />
We script characters to respond to world events. When we have control over the world events, we script them to perfectly match the specific events we've created... but that's a flaw. We need to get out of that habit if we want to let the player hang out with them. Because hanging out isn't specific.<br />
<br />
There are lots of games with "specific hangouts". For example, chatting at the camp fire in Dragon Age, or private actions in Star Ocean. But these are tightly scripted events that are a facsimile of hanging out rather than actual hanging out. They're expensive to make and limited to play, and I think we can do better.<br />
<br />
<h2>Structural Issues</h2>We think about hanging out as being unstructured, but the truth is that it is very structured.<br />
<br />
In order to interact with a character, you need a medium of interaction. A task, basically. Most tasks have a set of progressions that can be used to move the hangout along a fun path.<br />
<br />
For example, if you're drinking in the bar with a fictional friend, what happens? Maybe they get drunk. Maybe you get drunk. Maybe they start a bar fight. Maybe someone at the bar recognizes them, and then something unfolds. Maybe they get hungry for real food and you change locations. Maybe someone else you know walks through the door and the dynamic changes. Maybe you look for dates.<br />
<br />
Alternately, if you're playing video games, there's a lot of flexibility as to what game you play, whether you switch games, who tries hard or not, who wins or not, whether you start betting, whether people start getting way too into it, etc.<br />
<br />
These progressions are at the heart of "hanging out", and they are also at the heart of how a character can express themselves.<br />
<br />
Each character in the game can prefer different progressions. They don't need to be completely unique: a lot of characters can get drunk at the bar. But if the progressions go on for several elements, you'll see their uniqueness start to manifest: person A gets drunk and starts a fight, person B gets drunk and hits on everyone, etc. These are small, simple things to talk about, but this is the heart of how hanging out has to be approached: there's a task, and different characters want to progress or change the task depending on their personality, mood, etc.<br />
<br />
This spectrum of progressions allows the characters to contextualize the event as they see fit, and to recontextualize a generic event ("at the bar") with a specific in-character event ("picking up guys" or "getting shit-faced") based on what progression they want to see.<br />
<br />
<h2>Adapting to Existing Games</h2>For example, in Skyrim you might be wandering the world map with Lydia, your dull, dutybound housecarl.<br />
<br />
Skyrim has progressions built into its systems and maps. If you're wandering outside picking flowers, you'll run into options to fight monsters, go into dungeons, see wonders, change biomes, get rained on, go from day to night, find an ore resource, find a town... these are all perfectly valid progressions.<br />
<br />
By understanding what progression Lydia wants to see while on the world map, she can make comments about what's going on. For example, if she sees a bear, she might say "that bear might threaten travelers, maybe we should drive it away."<br />
<br />
This would be different if she saw a monster in a dungeon, where it's not a threat to a city. She might say "some skeletons ahead, I wonder if we can get around them." Or, if she sees a monster in a town, she might flat-out rush to attack, to protect the people of the city.<br />
<br />
By allowing her to decide what the current context is, she can choose what progressions she'd like to see. This gives her dialog a lot more vitality than simply yelling "yahhh!" and charging at any monster you find.<br />
<br />
However, this is still very shallow. Since Lydia has only dialog and the player has only action, it's a lopsided mess where it's difficult for the situation to progress in any meaningful way. In the end, it boils down to Lydia making comments on what the player chooses to do, just like in later games such as Dragon Age.<br />
<br />
The simple fact of the matter is that hanging out is collaborative. Lydia can't really collaborate with the player in the gameplay as it exists.<br />
<br />
<h2>Stop, Collaborate and Listen</h2>One thing we can do to make this more collaborative is to let the player give dialog responses. However, I don't think that's a good approach, as it will lead to very repetitive interactions as you hang out over and over.<br />
<br />
Instead, I would prefer to do the opposite: let the NPC offer action plans.<br />
<br />
When Lydia says "that bear might threaten travelers..." two action plans might pop up and be selectable. "Take it out, I'll support you" and "let's ambush it, follow my lead" might be the two options (with the third 'ignore' option implicit). These are represented as dialog, but they're not simply dialog: they're functional plans. Not only do they determine Lydia's behavior, they can also embed bonuses: Lydia gets an attack boost if you tell her to take it out, and a stealth boost if you say you'll ambush it.<br />
<br />
Moreover, these plans are excellent at advancing several progressions at once. Not only is Lydia advancing from "outdoors" to "defending the roadways", but she's also advancing along her "Lydia, stealthy supporter" or "Lydia, front line knight" character progressions. She may also progress on her personal opinion of you if you do particularly well or poorly, although remember that all such progressions are temporary. You'll hang out again some other time, and things will unfold differently.<br />
<br />
These action plans can offer things the player literally can't do without the NPC, as well. For example, Lydia might say "oh, this is such a rich iron vein. Let's claim it for the city!" at which point you'll have the plan to claim it for the city: something you cannot do on your own, or with another character. Other housecarls might also be able to do it... but for other cities.<br />
<br />
This combination of factors will hopefully make the player want to participate in these collaborative plans.<br />
<br />
<h2>Save and Load Contexts</h2>One technique that can help us add depth to the characters is to allow contexts to be shelved and readopted as necessary.<br />
<br />
Our instinct might be that Lydia following us around is Lydia hanging out with us, and the whole day is one "hangout session". But that leads to problems, because the context might not progress at all. The player might literally gather plants for three hours straight, and Lydia's constant talk about what she'd like to do will get repetitive and futile.<br />
<br />
Instead, she can simply shelve an intended progression when it falls through.<br />
<br />
So if Lydia says "that bear might threaten travelers..." and the player doesn't engage, Lydia won't follow that up with "that skeleton might threaten travelers" and "that treant might threaten travelers". Instead, that progression is on hold.<br />
<br />
However, if the player does engage an enemy on the world map - pretty much any enemy - Lydia will be able to instantly pick up the progression. "You'll never threaten another traveler!" she barks as you smash down a mudcrab or whatever. From there, she's in her "cleaning up the wilderness" context, which can be built any way the devs want. Maybe one progression is to attack stronger monsters. Another, less preferred branch is to attack weaker monsters. Monsters in another biome. Monsters marked as 'evil'.<br />
<br />
This context is active, so Lydia won't say "that bear might threaten travelers..." because she's not in that context any more. Instead, she might see a bear and say "let's clean up this forest a bit!" in an attempt to progress along the biome path of her "cleaning up the wilderness" context.<br />
<br />
Of course, once the hangout period ends (spending a certain amount of time in another major context, like in a city or a dungeon), the contexts can reset and she can start over.<br />
<br />
This isn't an ideal solution, but it effectively allows you to script character events that unfold naturally and opportunistically as the player plays, rather than being segregated into their own quest lines.<br />
<br />
<h2>Parties, not Companions</h2>Probably the easiest way around the collaboration difficulties is to have more than one companion. If there are several NPCs, they can discuss and banter. This is something Dragon Age does well, but primarily by using random snippets.<br />
<br />
We can choose to anchor the banter to contextualized progressions, instead. As an example, if you're wandering Fallout 4 accompanied by both Piper (reporter) and Curie (science robot), they'll both contextualize the wandering and have directions they want it to go. You get a sense of this in Fallout 4 as it stands: they have a variety of generic comments on situations you might encounter.<br />
<br />
But by allowing them to comment to each other, you can build up a sense of progression even if the player ignores their preferences.<br />
<br />
For example, if you find a few talkative ghouls, Piper might say "hey, we should get their story!"<br />
<br />
If the player chooses not to do that and walks away, rather than something like "PIPER -2 FRIENDSHIP", Curie can disarm the situation with an excuse like "We cannot be distracted by such tings, we have important tings to do!"<br />
<br />
Of course, the player avatar could theoretically also say that kind of dialog, but the player might not be thinking the same thing. The player might be thinking "sure, give me a second to raid this treasure chest first", which is very different from the dialog claiming it's something that won't happen. <br />
<br />
If a third party says the dialog, being wrong is acceptable and can give rise to more complex lines of progression.<br />
<br />
For example, if you do go back and talk to them, it's relatively easy to have remembered the original dialog, and now have different dialog. This can be quite generic. For example, as you approach, Curie might say "I remember zees people", then Piper can say "Now do we have time?" Or, if you're now just adventuring with Piper, she might say "hah, now that Curie's not around, we can do some snooping and scooping!" These are fairly generic dialog lines that can be deployed in a lot of different situations.<br />
<br />
If we consider hanging out to be a task with a variety of progressions, then we can again run multiple contexts at the same time. We're progressing this specific subquest. We're progressing Piper's "search the wasteland for news" context, which may lead to her wanting to go home and write about it. We're progressing Piper and Curie's relationship with each other - again, it must be stressed that it's a hangout context, not a permanent progression. We're progressing Curie's "focus on the science" context.<br />
<br />
By having many contexts which can be progressed, shelved, and activated at the same time, we can make the experience as character-cohesive as possible. From the player's perspective, it doesn't matter which context gets progressed next: they all have Piper acting like Piper or Curie acting like Curie, and for reasons that make sense.<br />
<br />
It will require a bit of effort to create the engine to do this, though. You'll need to figure out the right generic dialog to switch or resurrect contexts, just for starters. It's not something I've seen done before.<br />
<br />
<h2>New Hangouts</h2>This is all about adapting the concept to existing games, but the truth is that we don't need to do that. We can make new games.<br />
<br />
If they're intended to allow for this kind of thing right from the start, there's no struggle to make sure all the metadata you need exists or all the conversations have to work within some specific fiction: it's all designed from the ground up to work.<br />
<br />
Moreover, it allows us to radically reduce the amount of content and gameplay we need to support, because this context-centric approach can use much smaller amounts of gameplay to accomplish the same thing. Rather than gameplay strongly relating us to the world, the gameplay is more about collaborating with a friend.<br />
<br />
For example, you could decide to hang out with someone and spend the afternoon assembling ships in bottles. It's basically a minigame, but it's made much more interesting because there's a character-driven progression in play. The actions you take affect what the other people do, and what they want to have happen. Doing well at the minigame may be a bad idea... or, rather, doing well at the minigame may not involve actually building the ship in a bottle.<br />
<br />
Hanging out and making ships in a bottle is not just about the progression of the task of ships in a bottle.<br />
<br />
We've already talked about longer-term contexts like "Lydia's stealthy follower progression". Well, the whole point now is that the event progression is more about the personal contexts and progressions that our friends are going through. Rather than having one preferred contextual progression, the progression they want from this event is influenced by the progressions they want from their other, personal contexts.<br />
<br />
You've going to have very different "ship in a bottle" minigames depending on whether your friend is drunk, angry at her parents, mourning the loss of a friend, nervous about a piloting test, or embarrassed that you found out she likes a terrible TV show. The progression of the minigame is not the point: the point is the progression of her personal contexts, as expressed through the progression of the minigame. Hell, she might even play the minigame without the player's input at all - the player can just watch.<br />
<br />
We can spread this idea even further, into the world's overall state. Her personal context affects how well she can fly the ship, or how aggressively she fights. Whether or not there's actual gameplay involved with those or if it's just some flavor dialog, it will convince the player that there's a world and stuff happening.<br />
<br />
One possible example leading towards this would be Dragon Age 3, just the parts where you decide who to send where, and for what purpose. You could hang out with someone, and then when you send them on a mission, they get better or worse results depending on how they feel. Their personal context will then be altered by the mission they just went on, so it's a good time to hang out with them again...<br />
<br />
<br />
<br />
Anyway, those are some of my thoughts.<br />
<br />
What do you think?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com2tag:blogger.com,1999:blog-11758224.post-34365573200802889362018-09-05T09:54:00.001-07:002018-09-05T10:03:35.154-07:00A Sense of PlaceSo, I really like games with a sense of place. Some days, I think it's the most important part of a game, more important than how the game actually plays.<br />
<br />
But only some days: the vast majority of games don't give me any immersive sense of place.<br />
<br />
I asked around on Twitter, and nobody chose the same places I did. They all had very different priorities. And it's clear that game devs share their priorities - especially clear, given half the respondents were game devs.<br />
<br />
What they mostly liked was a sense of scale. Mostly cities with epic vistas and large scales.<br />
<br />
I sure do like pretty cities, but that's not what keeps me coming back to a game year after year. I'd like to talk about what I like in cities and towns, try to nail it down so that I can build it myself.<br />
<br />
So, let's start: one video game city that keeps luring me back is in Bloodlines.<br />
<br />
It's not big. It's not beautiful. The design is blunt and uninspired. It has no redeeming qualities as a city or a piece of art.<br />
<br />
But... I keep replaying the damn game, and a big part of that is how much I enjoy being in the city. There's a little fizz beneath the city that instantly smashes me into the game and keeps me there.<br />
<br />
I think that's a good hint. Since there's not much distracting epicness, I can focus on the one thing I want to see more of, even though it's just a fizz.<br />
<br />
<h2>Pace in Place</h2>In most games with cities, the cities are subordinate to the wider gameplay. The city might host missions or objectives, but living in the city is not an objective.<br />
<br />
There are games where the city is the main gameplay. For example, in Crackdown. Surprisingly, this seems to be even worse for my little fizz: it reduces the city to a mechanic.<br />
<br />
The experience of being in the hubs in Bloodlines is different.<br />
<br />
You are living in the city. Or... unliving, I guess. <br />
<br />
You're existing in the city.<br />
<br />
Your struggles in the game are simply struggles to continue living in the city. You end up fighting dangerous battles against ridiculously overpowered enemies, but the point is that, at the end, you'll get to go home and take a nap and then tomorrow you can maybe visit your friend downtown. Even the end boss is literally chosen by you deciding what kind of city you want to live in!<br />
<br />
Over the course of your adventure, you establish a life in the city, with friends and coworkers and maybe someone to date.<br />
<br />
You also get to know the city a bit better. Although exploring the city isn't really the point, you do explore it while you roam around trying to make a life for yourself. There are plenty of things to find - a few topological secrets, like the back entrance to the the pub. A few new people with new missions, such as Ash in the cemetery or the truck vendor that wants you to clear out a parking lot. A few areas that are locked and you'll have to remember later.<br />
<br />
The pace of discovery feels right to me. In many video game cities, you explore to find random treasure baubles scattered around. But in Bloodline's cities, you search to find new people with fun new missions, new shortcuts, new locked doors you'll unlock later. You never feel like you came here just to get a mechanical reward: if you go into the back alley, you won't find $5 in a treasure chest. You will find a skeevy guy that wants you to clear out a parking lot.<br />
<br />
In a theoretical modern remake, you might feel compelled generate these missions on the fly. But you'd have to be careful: the point is to make a life for yourself. When I clean out the parking lot, the skeevy guy not only gives me a reward, but becomes a better vendor. If you were randomly generating missions, you'd still have to make sure the rewards are about better living... and I don't need more than one skeevy guy selling me stuff.<br />
<br />
If you look at the missions in these cities, nearly all of them are about living in the city. Either getting you established, or making the city safer for you, or making friends and allies. <br />
<br />
Even though all the NPCs are barely functional weirdo jerks, they somehow become <i>your</i> barely functional weirdo jerks. Mission after mission, day after day.<br />
<br />
<h2>Counterexample</h2>The most obvious counterexample is Stardew Valley, or any similar game. They are about building a life, but in the most mechanical way possible. You literally build your life: more farmhouses, more crops, more ore, more machines. But the town is not really part of that.<br />
<br />
The NPCs are rigid and inflexibly forced into your life. You cannot be allowed to alienate the shopkeep because there are no other shopkeeps. You cannot work for or against the mayor, because there are no other factions. There are few NPCs, and they largely exist to fill specific roles in the gameplay. Dating is the exception, but usually you can only date NPCs with no critical role, and therefore they have no actual place in the town. Moreover, you can typically only date one of them.<br />
<br />
Although you can make friends, there's no particular change in the way the game feels, or your lifestyle. <br />
<br />
This doesn't mean the games are bad. It means those games aren't what I'm talking about right now.<br />
<br />
<h2>Extending That</h2>If I were to imagine a game where this little fizz was turned into a torrential waterfall, we would need to punch the Bloodlines up without Stardewing it.<br />
<br />
A big part of it is that the city is largely not interested in you. They don't like you, but they don't dislike you, either. If you want to make a place for yourself, that starts with proving yourself to them in their own personal corner of the city.<br />
<br />
This is in stark contrast to most game cities, where the inhabitants are intended to pull the player into the game world and narrative. The NPCs in a normal game might welcome the player, or be hostile until a plot point, or they might just talk incessantly about whatever the main plot element in the area is. <br />
<br />
These are all the wrong choice if you want to feel like you are making a life for yourself.<br />
<br />
This doesn't mean they can't do those things. But the main purpose is make the player figure out how this person fits into their life in the city. Maybe the player decides they're a threat and sabotages them. Maybe the player needs their friendship... for now. Maybe they want to date this person, or just want them around as business partners or something.<br />
<br />
And, along the way, the NPCs can be welcoming or hostile or exposit endlessly. But regardless of that, the player knows this is a person that will impact their life in the city, and they have to decide what kind of impact that should be.<br />
<br />
Easy example from Bloodlines: when you meet the two-faced bar owner, she's friendly... but you know she can't be trusted, because you haven't earned a life here. Similarly, although the anarchists are unfriendly, you know they can be turned around and made friends if you can earn a life here.<br />
<br />
If you're considering how to structure your missions, this is a good thing to keep in mind. Not only in terms of how the initial encounter goes, but in terms of the final outcomes: the player's goal is to be friendlier, sabotage, charm, alienate - therefore, those should be the possible outcomes of the mission, rather than choosing something like a "renegade" or "paragon" ending.<br />
<br />
<br />
<br />
The design of the city itself is also important, because living a life means being in a place.<br />
<br />
This doesn't mean the city needs to be beautiful or epic, but rather that these NPCs need to have lifestyles and locales. They have their life in the city, just as you want to have. By choosing who to rely on in what ways, you get an echo of these lifestyles.<br />
<br />
This was one thing that really, really worked in Bloodlines: all the NPCs were vampires, meaning they literally don't have day jobs. Whenever you meet them, they're doing whatever they've decided to dedicate their life to, and that includes the lifestyle they've chosen. From the poolhall relaxation of the anarchists to the overly formal, excessively expensive meetings with the town boss, none of the vampires are ever portrayed as simply filling time with sleeping or working a day job. They are always living their life. Unliving their death. Whatever.<br />
<br />
Contrast this to games like Fallout 4, where the only thing that defines your settlers is their day job. <br />
<br />
Establishing a lifestyle is not something which has to be scripted. It would be relatively easy to randomly generate NPCs with specific lifestyles and specific methods of fitting into your life. But it would be difficult to randomly generate them in the right variety: NPCs come in packs, and often a pack of NPCs will have similar lifestyles and offerings, but subtly different ones. <br />
<br />
If you do generate randomly, you'd need to think in terms of generating teams of NPCs rather than individuals that happen to be in the same place. There are a lot of fun scaffolds for this, such as the five-person hero team, but they'd all need to be adapted in order to make sure that the player has something interesting to gain from each one, and perhaps a reason to prefer specific members of the team over others.<br />
<br />
All of this would need to be reflected in the construction of the city.<br />
<br />
That in mind, the team should probably have a good time hanging out together in places that suit them. If their lifestyle together doesn't seem fun, that would poison the well: the player wouldn't be interested in fitting into their life. There's a lot of different kinds of fun: an annoying overlord can still provide a good lifestyle if the player thinks being rich and powerful looks like fun.<br />
<br />
<h2>Near Misses</h2>There are a number of cities that make me allllmost feel the fizz, but it fizzes out.<br />
<br />
One set is the Citadel and your hub ships in the Mass Effect series. The first impression is very good, but it doesn't end up panning out because you aren't trying to establish a lifestyle. It's about already having a lifestyle, and getting to live it.<br />
<br />
That's not bad! I loved hanging out with my buddies. But I never got to choose how people fit into my life. They were written in or out of my life at the scriptwriter's convenience, and that left me unable to get that fizzy feeling.<br />
<br />
Most such modern RPGs give that same "alllllmost" feel, like Dragon Age.<br />
<br />
Another example is The Sims. While I can choose which characters fit into "my" lifestyles, I can't get a feel for the city. Their lifestyles are encapsulated in their individual homes, and nobody is really integrated into the city. <br />
<br />
Even if I go into the city and people are around, I know it's not really an integration. Their existence or lack of existence wouldn't change the feel of the city any.<br />
<br />
There is one other example I wanted to talk about: Skyrim (or the modern Fallouts). These have lots of cities of varying size and shape, all stuffed full of NPCs that have opinions and lifestyles.<br />
<br />
These cities create an itch I cannot scratch. Their characters have lifestyles and want me to help them, but doing so doesn't lead anywhere or provide me with a life in the city, because there's no reason to have a life in the city. If I decide to track down and kill the weird cultist... nothing changes.<br />
<br />
While I do replay these games frequently, I typically spend less and less time being social in cities, more and more time doing other things. Being social doesn't really lead anywhere.<br />
<br />
It does in Bloodlines. It always leads to a new life in the city.<br />
<br />
<br />
... anyway, I wonder whether anyone else feels like this.<br />
<br />
It might just be me.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-46842266656664451772018-08-30T10:53:00.001-07:002018-08-30T11:04:35.077-07:00Player-Generated NPCsHey, let's talk about player-generated NPCs, and sending them to other players.<br />
<br />
In order to turn player-generated content into content for another player, you need to add context and a reason to play. This isn't too hard in mechanically-oriented games, but in an RPG it's tough.<br />
<br />
Imagine playing Fallout 4 and running across random player settlements. Most players make facilities that are focused on making the numbers go up. Recontextualizing that into an RPG point of interest doesn't work out well: you end up with a dozen nameless NPCs and a bunch of empty buildings with beds in them. Hardly compelling RPG content.<br />
<br />
The problem is obviously in the recontextualization. The settlement was created to make numbers go up, and now you're trying to interpret it as an RPG town? There's no connection.<br />
<br />
The answer might be to make the original context an RPG context, so the player's created settlement is RPG content right from the start.<br />
<br />
<br />
<b>Pushing Context In</b><br />
<br />
Let's pretend we're designing a Mass Effect game: players create colonies, which are then exported and encountered by other players.<br />
<br />
As you play through the game, you make various choices. You visit the turian homeworld. You choose whether to side with the turians or with the humans.<br />
<br />
If you side with the turians, you receive a number of applications from turians, willing to move into any colony you make. If you side with the humans, you get human applicants.<br />
<br />
When you build your colony, you can add any applicants you like.<br />
<br />
When your colony is exported so other players can visit it, the game checks to see what they did on the turian homeworld. If they did the same thing, those settlers are friendly. If they did the opposite thing, those settlers are more hostile. If they haven't been there yet or didn't take sides, those settlers are just background color.<br />
<br />
This is an extremely fast and easy way to push RPG context into your colonies, and then continue to push that context forward into other players experiencing your colonies.<br />
<br />
<br />
<b>Pulling Context In</b><br />
<br />
In addition to this, we can use simple keywords to keep these applicants interested in similar conflicts. Those turian applicants came because you chose turians over human interests. That means they will continue to have opinions on decisions regarding turian vs human competition, or more generally turian vs any other species.<br />
<br />
If you visit the Citadel and side with a turian shopkeep over a human shopkeep, the turians back at your colony will compliment you for it, gain loyalty, become more effective citizens. If you choose the human shopkeep, the turians in your colony will be a little annoyed and rib you about it, although there probably shouldn't be any statistical punishment for such a minor event.<br />
<br />
If you visit the citadel first and choose the human shopkeeper over the turian, you'll probably get a human applicant. Then you visit the turian homeworld, make your choice there, and your human responds appropriately.<br />
<br />
Since it's keyword-based, events can be done in any order, and mods can be integrated smoothly.<br />
<br />
In this way, your colonies will have a vested interest in your continued adventures, and you'll be taking your citizens' opinions into account as you journey.<br />
<br />
<br />
<b>Generating More Context Globally</b><br />
<br />
Tying your colonies into the galaxy is important: if your colonies feel entirely isolated, that's not very immersive. So your colonists need to do more than have generic responses to keywords.<br />
<br />
They should put their thumb on the scale.<br />
<br />
If you visit the turian homeworld, get some turian applicants, and then get into that turian-vs-human shopkeeper conflict, your colonists should call you up to chime in.<br />
<br />
Here's the key, though: it should be the wrong colonists.<br />
<br />
If the colonists that actually care about turian/human competition call up, they'll try to convince you to choose the turian side again. This creates a feedback loop where you have more and more pressure on you to choose the turian side of things. With no counterweight, that's not a good idea.<br />
<br />
Instead, you should hear from different colonists with no stake in the turian/human competition, and they should put their thumb down on the other side.<br />
<br />
For example, since you chose turian last time, a quarian might call you up and say the turian sold them a lemon last time they visited. The idea is to push the choice back into balance.<br />
<br />
Basically, if NPC A has a vested interest in turian/human conflict, that causes a situation where NPC B reweights the conflict to make it hard for the player to choose a side.<br />
<br />
There will be some conflicts where the player has a particular favorite. If they really like turians, then you might need to apply quite a lot of pressure to make the choice difficult. In situations where the player doesn't seem to have much interest and are easily swayed by the third party pressure, it makes sense to create additional conflict by having your colonists come in on both sides and have a bit of an argument about it. Raises the stakes.<br />
<br />
<br />
<b>Generating More Context Locally</b><br />
<br />
You'll need to generate a lot of RPG-context content in the colonies you build. Otherwise, the player will get stuck in a statistical, base-building mood.<br />
<br />
RPG rewards, RPG missions, RPG context deepening, and RPG/statistical linkups are the tools we'll use.<br />
<br />
In short, we can generate random missions when you talk to NPCs. But these missions are not the generic fetch quest blobs you're used to: we can generate much more interesting missions because we understand how these NPCs got here and what they care about.<br />
<br />
If you talk to the turian that applied because of how you helped his people, he'll generate a mission about turian/human competition. Perhaps it's entirely local: him competing with a human colonist, or perhaps him falling in love with one. It might be partially local: for example, buying a human grabloxotl to improve potato growth speed. It might be entirely nonlocal: a lost ship he wants you to rescue. <br />
<br />
The sides of this conflict can be weighted understanding the player's recent turian/human choices. If you've chosen humans recently, this mission is a chance to prove that the colonist wasn't wrong to trust you. If you choose turian a lot, then this is a chance to do some dirty work for the turians... or perhaps a chance to improve turian/human relations instead of keeping them pitched against each other.<br />
<br />
The mission generation does not need to be terribly difficult - pretty basic missions will do. Instead, the key is that they generate RPG context.<br />
<br />
One kind of context would be to reshape the local context. If it's a turian/human local competition, helping the turian makes them the boss. Helping the human does the opposite. This will create RPG context in that there's now a new social context.<br />
<br />
Another would be to link RPG context to statistical performance. If you help the turian, his stats go up. They don't gain levels otherwise, so this is important.<br />
<br />
Another would be to give the player versatile RPG context rewards. For example, new applicants, new colonist gear, new permits to plant potatoes on a new world...<br />
<br />
These generated quests intend to be a change of pace from the rest of the game, letting you 'come home' to do some unwinding. So they should generally be fun and silly, rather than grinding. The difficulty or time taken is not the point: choosing a side is the point. The "body" of the mission is just there to make sure you understand what's going on and what the stakes are.<br />
<br />
<br />
<b>Showing More Context Locally</b><br />
<br />
The most difficult and delicate part of making the colony RPG-ish is getting the player to feel like their settlement is an RPG hub. <br />
<br />
The player will only intermittently visit the colonies, will be focused on their statistical nature, and will probably forget the details between visits. So creating local context requires A) unmistakable, easy-to-read elements, B) remote-friendly elements so their video messages create context, and C) creating context via direct interactions when the player is around. Optional, D), linking colonies together to create "global but player-local" context.<br />
<br />
A) Easy to read elements probably involve three things: colony decorations, colonist clothes/gear, and non-player-centric interactions. <br />
<br />
These can all be used to create NPC-specific context, colony context, and plot/conflict context. For example, if there are bales of corn everywhere, you know what the colony's doing. If someone's wearing an elegant evening gown, you know they are a socialite and that the colony has a swanky side. If a boss is reading the riot act to a subordinate, you feel one way about it, while if they're gently guiding their subordinate, you feel another way.<br />
<br />
These decorations can be generated randomly, or they can be supplied by the player. For example, if you back the human shopkeeper, rather than get a human applicant, you get an evening gown you can give to any colonist. This isn't simply cosmetic: giving a colonist an evening gown retroactively forces the colony to have a swanky side.<br />
<br />
Symbolism is also a factor. Different colors and building designs give different feels, and having a bunch of turian flags waving tells you right away that this a turian-focused colony. These can quickly give you an overall impression of the colony.<br />
<br />
B) Remote-friendly elements would be elements that show up in messages. This would be character elements that show up on headshots, background elements that show behind headshots, and topics of conversation. These should be focused on reminding the player about the nature of the colony, rather than telling them about the nature of the NPC.<br />
<br />
C) Direct interactions are things the NPCs do to each other or to the colony. Too many games slot the inhabitants into either "work" or "sleep" and that's it. It makes more sense to use animations to tell you who these people are and their relation to the colony. So rather than digging in the plant bed, it makes more sense to show them teaching someone how to dig in the plant bed, or bragging about their plant bed, or anything that gives you a stronger impression of their social role within the base. This can randomized, or, again, it can be inherited from missions in the game world.<br />
<br />
<br />
<h2>Recontextualizing for Another Player</h2>When it comes time to export your colony for other players (or import their colonies), it's important to keep it as interesting as possible.<br />
<br />
<b>Recalibrating Opinions</b><br />
<br />
Probably the most fundamental element is to simply recalibrate how the NPCs treat the player by looking at how this player has handled the same choice axis. If this player chose the humans, then the turians will dislike him. This can be scaled pretty easily: by looking how severely the player has preferred the humans so far, the turians can be calibrated anywhere between mildly standoffish to instantly murderous. Most of the time, it'll fall between the two - for example, they might interfere with your missions, or lock your ship down, or try to assassinate you in the middle of the night.<br />
<br />
Obviously, these frequently become mission content.<br />
<br />
<b>Final Missions</b><br />
<br />
Unlike the creator, the new player is unlikely to revisit this colony. So we can go all out generating missions for this colony: it's fine to blow things up and kill colonists. In fact, it's preferable.<br />
<br />
These missions have the same basic role as the missions we generate for the creator, but the volume is turned way, way up. If the creator chooses humans, the turian might grump at them, or maybe even leave. But if the new player chose humans, the turians will start a mission to get vengeance. This will embroil the whole colony, and may involve impounding the player ship, launching assaults, blowing up facilities...<br />
<br />
However, in the end, it's still about the player choosing. So even in this kind of mission, the player will be expected to choose between turians and humans again. This time, it'll be something like whether to save a turian child or let it die as you escape.<br />
<br />
Aside from the mission, the colonies should generally offer amenities - shops, etc. The player may never visit again, but they should at least be able to do normal things while they're here, assuming the colony isn't specifically built to prevent it.<br />
<br />
Of course, if a colony is too similar to the player's choices, you can always generate an invading monster or a weird disease or something. This will give the locals a chance to show off their social nature.<br />
<br />
<br />
<b>Leads from Elsewhere</b><br />
<br />
Another key to integrating this player-generated content into the universe is to mix it into the universe. Partly, this just involves getting leads from somewhere else.<br />
<br />
If the colony is heavily turian, then a player will get a lead from a turian: "my family lives here, you should go visit them!" Or perhaps, if they are anti-turian, a human: "this is a turian stronghold..."<br />
<br />
More than that, additional content can be easily mixed into friendly colonies. Recurring NPCs, threads of ongoing missions, or minor loyalty events for your companions can be interwoven into the colony. Characters that are oriented around a conflict this player doesn't care about can be easily removed and replaced with known quantities from this player's game. IE, if this player seems to not have an opinion on turian vs human, those turians might be replaced with an asari psi-broker telling you where to get the next link in the psi investigation chain.<br />
<br />
This can be punched up as necessary by making you have to rescue them from whatever's going wrong.<br />
<br />
Generating these missions can be as complicated as your algorithms allow, as you can see. But even if it ends up fairly simple, it should hold up.<br />
<br />
<br />
<b>Recontextualize-Friendly Construction</b><br />
<br />
Another trick we want to use is to leverage the simulationist nature of these colonies. Because we're simulating so much, there's no need to always just offer mission-mission-mission-shop.<br />
<br />
Like in Skyrim, sometimes you'd visit a town just to steal things. It's really fun to try and figure out how to get away with your theft.<br />
<br />
This is similar, except we have a wider variety of simulated objectives. For example, you can change who's in charge by helping them, giving them better gear, etc - or by harassing their opposition. You can change the culture by arguing about things - for example, if you argue that the turian culture is inherently corrupt, you can sway things towards the human side of the turian vs human conflict. You can hack computers, steal vehicles, reroute credits, teach children, rearrange their defenses, get them better deals on their exports, get them better gear for their processing...<br />
<br />
These things are all already being "weakly" simulated. We had to, in order to create both the statistical and RPG contexts in the original creator's world, and to link those two contexts together. Therefore, we can expose some of that simulation and let the player do something besides chat.<br />
<br />
We're not talking about deep simulations. I mean, in Skyrim you steal stuff, but the shopkeeper doesn't actually get any poorer. This is the same sort of thing: we expose enough of the system to let the player interact with it, but we don't have all the pieces deeply connected, and we don't need to.<br />
<br />
<br />
<b>Final Thoughts</b><br />
<br />
That was long.<br />
<br />
And some of it might be a bit of a stretch.<br />
<br />
Fundamentally, I think we can give player-created colonies a lot of RPG context by tying the people, facilities, gear, and options to your RPG adventures.<br />
<br />
And then I think we can wire that back into the world, to make your colony part of the RPG adventure.<br />
<br />
And then I think we can export your colony to other players, and make it part of their RPG adventure.<br />
<br />
What's your opinion?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-41487141893573844442018-08-02T09:53:00.001-07:002018-08-02T09:53:06.571-07:00Action-Oriented Escalated BiddingI've been thinking about new kinds of gameplay for MMORPGs, because I'm not happy with any of the current styles.<br />
<br />
I love the feel of the "personal epic" games like Star Wars Galaxies, Star Trek Online, even things like WoW. There's a lot of joy to be had in running around a world in real time. But the combat in these games is always either so clunky it's painful or so action-oriented that you have to be a twelve year old with broadband.<br />
<br />
Thinking about alternate combat styles, one with appeal is escalated bidding. <br />
<br />
This kind of bidding (found in poker and many tabletop games) basically allows players to judge a situation and decide whether to escalate or end the round. It's easy to balance, compelling, and naturally cinematic.<br />
<br />
However, it's turn-based.<br />
<br />
It's easy to come up with styles of play that allow for this kind of combat, but the turn-based nature is hard to avoid. And turn-based doesn't mesh well with the epic personal feel I'd like in my imaginary MMORPG.<br />
<br />
I was having a hard time coming up with escalated bidding that didn't involve turns, but I think I figured it out: it's just a simple rework of existing mechanics.<br />
<br />
For example, you're playing Star Trek. You're wandering into combat with your space ship. What's the "escalated bidding" for this?<br />
<br />
Well, it's the same as Star Trek Online currently is... just a few small tweaks.<br />
<br />
One critical element is range. Tiered bidding is a great way to escalate. In Poker, that would be the ante, the initial bidding, and the final bidding - but in Star Trek, it might be shields, system, hull. Rather than having distinct rounds, it's based on range.<br />
<br />
You start off at long range, taking shield damage. You get closer, your weapons tick over into optimal range... but, at the same time, you now take systems damage from incoming shots. You get even closer, your weapons are guaranteed to deal terrific damage... but now any damage that leaks through your shields will blast away at your hull... and some damage is always going to leak through.<br />
<br />
Conversely, if you can stay at long range, your ship is not at risk even if your shields go down. Incoming fire will scratch your hull and temporarily glitch out your systems, but that's damage that can be rapidly and completely repaired.<br />
<br />
To be clear: as your weapons enter optimal range, you take a lot more damage. The better you can shoot, the more you get shot.<br />
<br />
This range element adds a ton of complexity to conflicts, because your systems-damage range may not be the same as your enemy's systems-damage range. A long-range torpedo boat may be taking hull damage from a small merchant vessel while the small merchant vessel is still taking shield damage! This means the small merchant vessel's shots will squirrel through the torpedo boat's shields, while the torpedo volleys will largely splash off the merchant's shields.<br />
<br />
Matching ranges will be a major element of what ships you use, when. Party loadout becomes a really interesting challenge.<br />
<br />
<br />
<br />
In most bidding systems, how much you bid is also critical. But in this case, the "bid" is how close you get, for how long. Starships have position and relative speed: committing to a deep run can net bigger rewards if you come out on top... but huge problems if a lucky hit knocks your torpedoes offline. Ship headings are another, interlocked kind of bid, if each shield quadrant fails independently of the others.<br />
<br />
Additional bidding can be done using various one-off powers. This is a classic "cooldown" setup: if you overclock your reactor for ten seconds, you won't be able to do it again for another two minutes, better make use of those ten seconds well. <br />
<br />
Unlike current combat systems which look similar to our bidding system, the cooldown skills in our bidding system would exist to gamble on the next few seconds. <br />
<br />
You're claiming the next few seconds will be critical, either offensively or defensively. With the range-based tiering system and quadrant-based shields, it makes a lot of sense to focus our skills on being useful shortly before or after changing range tiers - either your own or the enemy's. Fire your torpedoes when the enemy enters into their systems damage range, regardless of your current range. Pump your shields just before you change to systems damage range, since the damage you take in ten seconds will be far worse than the damage you take now.<br />
<br />
Offensive firepower should be tiered as well, basically turning it into a set of cooldown skills. A full barrage hits hard, but takes a long time to recharge. Smaller shots recharge faster - fast enough to do more damage overall, but obviously the enemy's shield recharge and maneuvering cancel much of that advantage out. Will you do some small shots as you close, followed by a full barrage when the enemy becomes vulnerable?<br />
<br />
This timing-based "bidding" feels more natural than any kind of shared pot or other abstraction. This also plays up the differences between different kinds of enemies with different ranges, and makes engaging multiple enemies or being part of a team a very interesting tactical opportunity. Obviously, various shortcuts also have value: a stealthed warbird decloaking right on top of you doesn't need a magic "decloak and fire" special power. Their special power is that they're right on top of you: you're at hull damage range, and at least some of that firepower is going to leak through the shields.<br />
<br />
<br />
<br />
This combat is extremely similar to the existing Star Trek Online combat engine. The tweaks are very minor: simplified range indicators, slightly different damage model, slightly rebalanced skills. But the actual play is so similar that people probably wouldn't have to think about it very hard: they'd just suddenly be having amazing, epic fights.<br />
<br />
<br />
<br />
This model could also be used for ground combat in the Star Trek universe, since ranged ground combat is the norm. You could just have literally all the same things.<br />
<br />
A Klingon with a blade can rush through blaster fire: their max range is quite low, which means their range tiers are tiny. The blaster fire would just burn their armor a bit. Of course, when the Klingon reaches you, they are well within your nastiest damage range, and are guaranteed to put you down in short order.<br />
<br />
The same basic mechanic would work for any personal combat system to some degree. A Star Wars combat system could be similar, with the light sabering Jedi naturally being similar to a Klingon. A Force-user could also take medium-range powers like Force Throw or Force Lightning. These would extend their attack range... and also extend their damage tier ranges. Someone specializing in sabers would be able to bull through Force Lightning because it's outside their damage tier range!<br />
<br />
Even in tight combat, you could still see variations. A long light saber seems like a great choice... and it is, against anyone with a gun. But against someone with light daggers, your melee range is actually outside their most critical damage tier, meaning they can hold you off without too much danger... but you're not so lucky against them. You'd have to use combat abilities to close the range or disarm them unless you have a lot of time on your hands!<br />
<br />
The downside of this is the bidding, since at melee ranges you don't really commit to be at a specific range or a specific angle for particularly long. To counteract that, I'd recommend using "charge" skills which push you into melee combat with a large bonus for a specific amount of time, but then leave you with a big penalty until it recycles. In this way, melee attackers would choose how much to "bid" by choosing a light, moderate, or heavy charge attack. They can also do this while already in melee combat, of course.<br />
<br />
<br />
<br />
A tiny change to a fairly ordinary combat system: your optimal attack range is also the range you take worse damage. From there, a rebalance to existing combat approaches should result in a really interesting, cinematic challenge.<br />
<br />
At least, that's the theory!Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-7687552964781640172018-07-25T09:23:00.000-07:002018-07-25T10:30:31.776-07:00Pacing MechanicsI'm going to write a little about pacing mechanics, although to be honest I'll probably make a video on this topic once I've worked out the kinks.<br />
<br />
Pacing mechanics are gameplay that exists only to keep the game flowing at the right rate, and with the right traction. In theory you could argue that all gameplay is like that, but pacing mechanics are specifically for that purpose rather than to be entertaining, challenging, thought-provoking, etc.<br />
<br />
An example of this would be in an Animal Crossing game, where you can only harvest things once per real-world day. This gives the player a specific amount of that rewarding task each day: enough to call the player back (traction), but only a small amount, so they're encouraged to do other things once they're engaged (flow).<br />
<br />
There are three basic kinds of pacing mechanic, as far as I can tell.<br />
<br />
<b>The physical play mechanic</b>, like in the Animal Crossing games. <br />
<br />
It lures people to log in each day, or on specific days, or in specific places. For example, Pokemon Go rewards players for going to new real-world locations, or physically meeting up with friends.<br />
<br />
This is a bit different from the kinds of energy play you often see in mobile games. Rather than providing traction and flow, most energy mechanics simply let you play until you suddenly can't play any more... unless you pay money. The traction and flow elements may still exist, but they're weak, because they're not the point.<br />
<br />
<b>The structured play mechanic</b>, where players are given specific, rewarding in-world tasks to be performed on an in-world schedule. <br />
<br />
For example, watering the plants every morning in Stardew Valley, or having to return to town to recover mana in an RPG. These tasks give you specific things you are strongly pressured to do (traction), but also can only be done for a short while before pushing you to go do other things (flow). Typically, these mechanics adjust over the course of the game and to the preferences of the player - some players love visiting towns and talking to people, others just want to shop and get back out on the field.<br />
<br />
Something like a hunger meter in a survival crafting game is not a structured play mechanic, despite appearances. The goal of a hunger mechanic is to push new players into growing food and engaging with a core construction loop, but the actual task (eating) is not a mechanic with any traction or flow. It's simply a mechanic to guide the player into engaging in the first place - more of a tutorial mechanic rather than a pacing mechanic. <br />
<br />
This becomes extremely clear as you reach mid/late game and eating just becomes an annoyance rather than an opportunity.<br />
<br />
<b>The tiered play mechanic</b>, where players can accomplish a certain amount with the setup they have now, and then need to find new resources.<br />
<br />
For example, in Minecraft you can do only so much with materials in your starting biome. You are pushed to dig deeper, search further for newer resources. This contains a number of staggered resource tiers, culminating in things like creating a portal to Hell so you can mine it. <br />
<br />
This is a very common mechanic, and can be seen in every crafting game.<br />
<br />
However, there are a lot of other ways to do it. For example, in an RPG, you need to move onto the next town to get new equipment, new story. In Skyrim, you'll eventually need to either leave the woods for the towns or leave the towns for the woods, because you'll run out of interesting things to do.<br />
<br />
The idea behind all these tiered mechanics is that the player chooses when to leave. Usually, it happens just before they consciously realize they're bored of the current options. Players build their cool wooden Minecraft mansions, and when they start to run out of steam they naturally consider going abroad for new materials, or digging down to find some redstone or something.<br />
<br />
A counterexample would be a game where you have 1000 gold to spend, and then have to go earn more. This is, again, just a tutorial mechanic rather than a pacing mechanic. A pacing mechanic would be "no matter how much gold you earn, there are things which cannot be bought with gold." <br />
<br />
How you earn gold could also be a pacing mechanic.<br />
<br />
Also, it's worth noting that tiered play mechanics can easily go wrong if you give any hint that there are a certain number of things to accomplish. This is common in RPGs: sidequests are intended for players that enjoy faffing about and moving slowly. But they accidentally sidetrack a lot of players that don't particularly enjoy that, but see them as tasks to do rather than optional crap for more relaxed players.<br />
<br />
<br />
<br />
<b>Let's go into detail</b>.<br />
<br />
Now that you understand the intent of a pacing mechanic, what makes a pacing mechanic good, or bad? <br />
<br />
A good example of bad pacing mechanics would be No Man's Sky, even after their most recent update. It's clear that the mechanics are built around the same concepts as things like Minecraft. There's tiered materials, unlockable research, different biomes, etc. Why does No Man's Sky only charm a few of its players?<br />
<br />
It's because the traction and flow system isn't properly set up. It's got the same basic mechanics, but they're not engaged properly.<br />
<br />
Their version of traction is to require the player to keep topping up their tools and engines and stuff. However, this is a stick rather than a carrot. <br />
<br />
It doesn't pull the player in by offering them rewards if they do it, it punishes the player by grinding the game to a halt if they don't do it. It's got more in common with a cash shop energy system than a pacing mechanic, even though there's no cash shop!<br />
<br />
The traction system of other games? Well, watering crops results in incremental progress towards harvesting crops. Also, it doesn't require you to wander across a new hellscape in search of water - water is right there, you just have to do the grunt work. Returning to town to restore your MP? That gives you dozens of opportunities to power up your characters, get new quests, and so on. Also, you can adjust your battle strategies to minimize the need to do it.<br />
<br />
There is a hint of what it would be like with the right traction mechanic, since building your bases requires quite a lot of specific kinds of materials. It would be an opportunity for me to build a giant wooden castle, steadily exhaust everything I can do with wood, then begin building a metal underwater base or something. In this way we would get a nice, tiered setup.<br />
<br />
In addition, the upgrades are not properly integrated into the pacing mechanic. In order to buy upgrades you need to wander the world looking for buried treasure, which magically turn into treasure points which your machines magically turn into new blueprints. This isn't necessarily bad, but it's not a good pacing mechanic. There's not much traction or flow involved, and it interferes with my ability to explore the nature of having a wooden castle. If I dig up more treasures, I should probably spend them on unlocking more advanced base equipment in the next base tier, rather than wasting them unlocking the ability to build a window.<br />
<br />
If the traction side is flubbed, the flow side is just as bad. <br />
<br />
I think the theory was that the limited inventory space would keep you from wanting to stockpile specific resources, meaning that you would be pushed into moving forward. That could have been a good flow, but it doesn't work in practice because the universe doesn't really support that kind of motion. If the game environment doesn't support your pacing mechanic, then your mechanic won't work.<br />
<br />
There's some promise to the idea of compressing resources down into denser, more high-quality variations of themselves. This could theoretically produce a nice loop where you harvest a lot of a given planetary resource, spend some time condensing it into an easy-to-carry variant, and then move on once you have a complete stack of ultra-dense stuff.<br />
<br />
I think a game could be built around that pacing mechanic really easily... but NMS is not that game. Instead, it features a smattering of annoying, slightly rare materials that take up way too much of your limited inventory space and can't be meaningfully compressed. Trying to hunt down rare materials would be fine in a game with different pacing mechanics, but these mechanics actually make that task extremely annoying.<br />
<br />
This isn't to say NMS is "bad". It does hit the sweet spot for a fair number of people. It's simply that the pacing mechanics aren't really doing their job.<br />
<br />
<br />
<br />
<b>Conversely</b>, there are games with spectacular interlocking pacing mechanics, and those are well worth studying.<br />
<br />
Stardew Valley is probably the current king of this. With at least half a dozen interlocking, adaptive pacing mechanics, it appeals to a surprisingly broad player base.<br />
<br />
Daily energy is the most basic mechanic. High-intensity tasks like harvesting, chopping wood, and adventuring can only be done sparingly, which pushes the player to then do low-intensity tasks such as exploring, charming the townsfolk, cooking, and so on. The low-intensity tasks show the player how to unlock more efficient high-efficiency tasks, which makes a nice circle.<br />
<br />
Daily hours is another basic pacing mechanic. You can only get so much done in a day, even if you short circuit the energy mechanic with expensive foods. This pushes you to do at least some high-intensity tasks, rather than just doing a bajillion low-intensity tasks, to make the most of your daily energy.<br />
<br />
Tending the farm (watering, milking, etc) is a structured play pacing mechanic. It gives you a mostly-reliable task to do, and each time you do it you get a little bit of gain - whether in the form of direct goods or moving towards a harvest.<br />
<br />
Crop management (planting, harvesting) is another pacing mechanic, and allows you to determine how much farm tending you want to live with while also juggling your daily energy.<br />
<br />
Tiered tools (sprinklers, better axes) is a tiered pacing mechanic that pushes you to do things besides simply farm, because they making farming more efficient.<br />
<br />
Processing (jams, ores, etc) is another structured play mechanic where it takes time to refine things and you're rewarded for efficiently returning on schedule to set up the next batch. But, like all these mechanics, it's largely player-driven: players can simply invest in more hardware if they want to get all their refining done without needing to tend it too much... or they can slack off and only process a few things, because there's not that much of a need to minmax it.<br />
<br />
All of these systems interlock, and are supported by the structure of the game's world. Each time the player engages with one, they are rewarded (traction), but only to a certain extent, then they are pushed to do other things (flow). It's an interlocking matrix of pacing mechanics, where the player can invest in a number of different ways to change the dynamics.<br />
<br />
It's just a spreadsheet, sure. But the pacing mechanics make it a damn fun spreadsheet.<br />
<br />
Plus there are some minigames if you need a change of pace.<br />
<br />
...<br />
<br />
Those are my thoughts on pacing mechanics.<br />
<br />
What are yours?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com1tag:blogger.com,1999:blog-11758224.post-2940921188501800302018-06-26T09:38:00.002-07:002018-06-26T09:43:19.822-07:00Background MechanicsFor the past few weeks I've been working on a new prototype which allows players to quickly "sketch" space ships into existence.<br />
<br />
However, in order for the sketched ships to mean anything, there needs to be a world they exist within. A framework in which they can be judged. A set of rewards for doing well. A progression in the types of devices and hulls, and so on.<br />
<br />
Any kind of stat-heavy core gameplay loop (repeatedly designing space ships, for example) needs a larger context.<br />
<br />
Now, you could create a story. "The Earth Empire is expanding into deep space and oh no the Brikklebats from Klonor 5 are attacking!"<br />
<br />
Or you could create a simple board-game-like set of mechanics. "The ship you created will manage to map sector 3 in 8 years, then you can build a colony ship..."<br />
<br />
But both of those are missing the point.<br />
<br />
See, when the player builds something, the point of the game is to <i>glorify</i> the thing they built. Whether it's good or bad, you want to make those good and bad aspects shine.<br />
<br />
Games where you can fly the ship after you build it are good at this, because you can really feel that the engines you installed work well, or that the guns really aren't good enough, or whatever. But I don't want to make a game solely about ships that shoot at each other. The player is far more likely to build a freighter or a science vessel, and I need to glorify those... and there's not many games which do that.<br />
<br />
I think the main feeling I want is that moment in a science fiction show where you see a ship type you're familiar with doing something in some episode. It could be a squad of Galaxy-classes struggling to fight off a Borg cube, or it could be something as simple as a rebel B-wing sliding into a docking bay alongside Luke's X-wing.<br />
<br />
These ships are things you recognize, and they exist in the universe. Hell, they make up the universe. They have an ongoing role not just in one story, but in dozens of stories. They don't stop existing once you've rated them, and the fabric of the universe is woven out of these threads.<br />
<br />
To make this something that works in a game environment where the players make the ships, we need to be able to tell those kinds of stories.<br />
<br />
So... what if we make a star map that is entirely about creating story hooks?<br />
<br />
Instead of placing facilities that make numbers go up, you place facilities that create stories.<br />
<br />
For example, instead of placing a lunar mining facility to make your minerals increase, you might place a "mining concern" that overlaps the planet and the moon. This would create stories of strife between the lunar miners and the planetside miners. To place it, you would need to build some kind of freighter or mining ship. Then there would be an "episode" - a simple story where the emergency performance of your ship helps miners survive... or die. The core performance of your ship would determine how long the mining concern remains a mining concern: at the end of that duration, it would transition into established and peaceful infrastructure.<br />
<br />
Basically, each turn the player might choose to place a concern on the map, and then either build a new ship class or assign an existing ship class to it. The simple, generated story it tells highlights the ship's emergency performance and livability, while the numbers attached to it at the end are determined by the ship's core mission functionality. The story can easily include arbitrary existing elements: interference from nearby concerns, ships inherited from old concerns in the area, named characters and ships from other episodes.<br />
<br />
The amount of player control over these episodes is limited, perhaps even nonexistent, and the story quality is not important. I mean, they play the same role as an arbitrary random encounter in a combat game, they don't have to be genius.<br />
<br />
They exist solely to take what the player has created and show it back to them in full glory. "You made this", the game says, "look how it works in this universe!"<br />
<br />
With a side plate of "oh, remember this stuff from before? What a definitely-existing-and-not-at-all-completely-bullshit universe we have!"<br />
<br />
... I think it might work.<br />
<br />
What do you think?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-21340833375944728302018-06-08T10:47:00.000-07:002018-06-08T10:47:11.366-07:00Voxels and ArchitectureA lot of games use voxels to allow players to build whatever they want.<br />
<br />
But the key in that sentence is "they want". <br />
<br />
What do they want? What will they want?<br />
<br />
Obviously, players will come into the game with some ideas from outside. People are always going to try to build familiar things. But your design of the voxels and the rules of the game will influence what they want to build later on, when they start getting used to the game and wanting to push their limits.<br />
<br />
Most voxel construction games have cubic meter voxels, which is a good size to allow people to build personal-scale architecture. It's a good balance of personal freedom of expression vs complexity. <br />
<br />
With this scale of voxel, most construction voxels are simple bricks, then further decorated with detail blocks such as stairs, chairs, paintings, and so on. While those decorative elements do matter, the fundamental construction of the walls, floors, roof, garden - these are almost always done with simple cubes of various textures and colors.<br />
<br />
Despite this, you can have quite a complexity of structural results. With just simple cubes, you can model anything from an ancient cave to a modern home to a huge castle to a mighty bridge. There are some constraints, though: it is quite difficult to model things like roundhouses, or anything else that is deeply non-orthogonal. Despite that, the variety of things you can build is pretty amazing, and you can do quite a few complicated architectural things like drop ceilings, natural light control, and so on.<br />
<br />
Unlike those games, Medieval Engineers and Space Engineers have massive, 10 cubic meter voxels. These voxels are scaled way up because the things the players are supposed to build are not personal-scale: you're supposed to build huge battleships and massive castles.<br />
<br />
However, because of the large scale of these blocks, they are usually not simple cubes. The players want more control than that. <br />
<br />
In Space Engineers, the blocks are frequently angled or rounded, to allow for the common hull shapes you see in fiction. Because of this, rather than having many block types and varying between them, most space ship hulls are built out of only one or two block types. The player's efforts are spent entirely on switching the shapes of the blocks, and perhaps painting them afterwards.<br />
<br />
Similarly, in Medieval Engineers, almost no construction voxels are simple cubes. Instead, they are common medieval castle shapes crammed into a 10m3 package. A curved wall. A gateway. Thick or thin stone battlements.<br />
<br />
A very tightly-themed game, Medieval Engineers is focused almost entirely on castle construction. The voxels have been limited to specific kinds of evocative, themed shapes to help the audience build variants on the accepted theme.<br />
<br />
In both cases, the theme is much tighter than in a game with smaller voxels. Nobody in Space Engineers is interested in building a medieval castle, and nobody in Medieval Engineers is interested in building a space ship... but in Minecraft, people frequently build both in the same world.<br />
<br />
I'm not saying that these themed large blocks are "worse" than the unthemed small blocks. Once you get used to the system, it's easy to build huge, beautiful things in those games. <br />
<br />
What I'm saying is that constraints matter.<br />
<br />
When you put together a construction system, you're not putting together something in a void. You're building something that exists specifically to help players build stuff. The methods and the constraints are critical.<br />
<br />
Even if you're doing standard small blocks, constraints and construction methods will radically change the outcomes. <br />
<br />
For example, in Eco, roof tiles automatically form into slanted roof elements to make convincing roofs. This happens to have an edge case where, if you have a 45-degree roof, you end up with a stepped roof with a wonderful gap to let light in. Just this small foible is enough to create a whole slew of architectural possibilities. It influences what players want to build... even though it's just a small visual idiosyncrasy!<br />
<br />
A more obvious example would be monsters. If you are playing on a monster-filled Minecraft server, your homes will have various ledges and overhangs to prevent spiders or creepers from being a problem. This creates a distinctive feel to many survival-mode houses.<br />
<br />
This isn't really an ideal constraint, though, because it's not integrated into the game very well. For example, there's nothing preventing you from simply building a floating house. Going in the other direction, there's no real way to use the attackers in a more interesting way - they just randomly wander up. You can build traps for them, but the traps are usually coffinlike underground pits, not any kind of interesting architecture.<br />
<br />
Redstone is also a missed opportunity in Minecraft, because it does not attempt to create any sort of architectural opportunity. You can see hints of what could be when you look at vertical redstone torch elements and such, but architects have to try really hard to force redstone into an interesting architecture.<br />
<br />
Imagine if redstone had more interesting topological constraints. For example, what if a vertical stripe inverted the charge? What if parallel, horizontal redstone trails would damp each other, making both null unless both were active? What if redstone healed people nearby? What if it had to be regularly repaired by direct access? What if a redstone "window" generated charge by harvesting sunlight, instead of using a torch?<br />
<br />
With a rethinking of how redstone works, you could easily see integrating redstone into your living space, or at the very least having a redstone system be architecture.<br />
<br />
If you want less fanciful architecture, you could also include less fanciful constraints. Heating is not hard to simulate at that level, and including a heating system would inspire players to create lots of different heating and cooling arrangements that would be similar to the real world. Moreover, each biome has different patterns of hot and cold ambient temperatures, meaning more variation in houses!<br />
<br />
Well... adding all these complexities naturally raises the complexity of the construction.<br />
<br />
Space Engineers has a way to calculate whether a space is pressurized. However, because it's very hard to figure out why an area is failing to pressurize, this remains one of the most annoying parts of the game. Similarly, it allows for rotors and pistons, but because they are so buggy and unreliable, trying to use them is just an exercise in aggravation.<br />
<br />
Adding complexity constraints is not always the right idea, but it becomes the right idea more often if you "work up to it". That is, if an ordinary construction by a newbie wouldn't encounter any problems due to it.<br />
<br />
For example, if you have a structural integrity simulation, but it's gentle enough that an ordinary player house in an ordinary biome wouldn't be at risk. It's only when the player begins to try to build that megacastle on Mars that they have to start worrying about it. Or, similarly, if active redstone slightly healed anyone nearby, players could use it for that without having to try and delve into computation.<br />
<br />
These sort of things are great fun to think of, and would definitely be more interesting to more players!<br />
<br />
There are a lot of things I want to try to put into a construction game! But... even the smallest ones feel like they could make a game all by themselves. <br />
<br />
For example, what about a construction game where you want birds to nest in your house? What about a game where views matter, either because people like them or because systems can only respond to threats they can see? What about a game where you whittle your starship hull instead of voxel-build it? What about a game where natural lighting is the most precious resource? What about a game where annoying extended family members are constantly visiting and you need to keep them impressed while also driving them away?<br />
<br />
What I'm saying is: you can sculpt what you want players to want.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-39467283888263871152018-04-17T10:07:00.001-07:002018-04-17T10:07:12.672-07:00A Simple Game about Huge Space NationsLike everyone else, I love and hate 4X games.<br />
<br />
Hearing the epic story of an entire species as they romp through the galaxy weaving their ten-thousand-year story in with friends, enemies, and supernovas? Yes please!<br />
<br />
But the actual gameplay is so bland. It always goes in one of two ways. It's either "fun at first but now we've done the same thing 50 times" or "that thing is polished away, so it's not even fun at first".<br />
<br />
I like the stories of interstellar civilizations!<br />
<br />
Much like I like the stories of the families in The Sims. <br />
<br />
4X games have some elements to create a foundation for these stories. Tech trees, alien races with reliable personalities, planets with different characteristics, and so on. However, the pattern falls apart in the midgame, as playing well becomes more important than having a story. <br />
<br />
The Sims takes the opposite approach: after you've gained a few job levels, you probably have some breathing room. You can focus entirely on leveling up your skills and jobs in The Sims, but there's no real pressure to do so. The midgame allows you to develop the stories as you see fit. In short: the beginning of the game forces you to choose an approach, and then it gets easier so you can see what kind of stories arise from the approach you've chosen.<br />
<br />
I've been brainstorming to see if I can think of a cool 4X-like design that does something similar, and here's one I like.<br />
<br />
One of the big issues is that fungible resources like cash are disconnected from the continuity of your story. When you spend money to do something, you're not connecting it to a previous story beat. Therefore, instead of using space cash, how about constructing chains of assets?<br />
<br />
For example, you have a garden planet. It has four slots: two industry, two evolution.<br />
<br />
You might choose to mount a "mining" industry onto your planet. Rather than producing cash, it has some more specific slots: materials, orbital, metropolis. You can then start to slot in things like advanced armor, orbital construction yards, and a cultural center. In turn those have slots, and you can continue to build out a chain of Things Your Species Has.<br />
<br />
This chain allows for context to be preserved. Your space fleet was built at the orbital construction yards supported by the mining industry of your home planet. This not only gives the player cues for their internal story, but it also gives the game opportunities to create interesting challenges: if the mines run out, it's not just a matter of losing a random facility on a random planet. Within a few years your construction yard will turn into a ghost town, and a few years after that, your fleet will start to fall apart.<br />
<br />
That's an interesting situation from every perspective... especially if we punch it up with characters that are part of this. We can seed them all ahead of time: the mine foreman, the construction foreman, the admiral. In the beginning, you meet them, and the admiral doesn't care about the mine foreman's problems... as time passes, you can see the changing situations written on the characters, as the mine foreman becomes destitute and the admiral starts bickering with the construction foreman about why his ships can't be properly maintained.<br />
<br />
You don't have to go that far, of course. I'm just doing whatifs.<br />
<br />
Replacing that mining industry would be a priority. The easiest solution might be to put a "fossil fuels" asset on the planet. It takes up and evolution slot and has an industry mounting slot, which you could then move the mining industry onto. Bang, everything's solved. Right?<br />
<br />
Wellllll...<br />
<br />
A big part of this is that the chain of assets is not simply a chain of fungible things. The space fleet isn't simply "the same as every other space fleet but from a specific planet". Instead, the space fleet inherits all the "side effects" of its parent cards. Side effects are always passed down. Some are good, like "advanced armor". But some are bad.<br />
<br />
The mining industry might have a side effect of "exploited underclass". This means that the docks, the space fleet, the cultural center: all would have an exploited underclass. Adding in the fossil fuel cards also creates a "toxic" side effect. Now the docks, the space fleet, and the cultural center have both an exploited underclass and a toxic side effect.<br />
<br />
In addition to providing more materials for the implicit and explicit story we're weaving, they also provide a hook for an entire game mechanic: stories made out of the side effects rather than only the assets. The toxic + underclass combo is rife for a "black lung outbreak" story, where millions of underpaid workers are dying of toxic fumes and the corporations are trying to conceal it. This kind of story is great for allowing the player to explicitly specify what kind of space nation they're running. How far will the player go to help the underclass? To help the economy? After all, any choice they make will send a shockwave down the chain: if they spend a lot of effort on helping the miners, then the mining industry will suffer a temporary (20-year?) penalty. Halfway through that, the penalty will propagate to the dockyards and cultural center. Halfway through that, it'll hit the space fleet.<br />
<br />
Now, the real secret of this approach is that it's only half of the system. That's the physical half, covering things and physical technologies.<br />
<br />
The other half is the social half, covering rules, governments, cultures, social technologies, and so on.<br />
<br />
The two sides interact. Assets for the social half are provided both by physical assets and by the vignettes inspired by physical side effects. Assets for the physical half are provided both by social assets and the vignettes inspired by social side effects. <br />
<br />
So if you side with the miners, in addition to a physical penalty, you'll get a social card. Perhaps "worker's unions". Siding for the corporations has a physical bonus, but also gives you the social card "monstrous corporations". If you don't play them, you'll hit your hand limit and you won't get any more physical-side vignettes until you do.<br />
<br />
You can add any additional complexity you like in terms of things like maps and factions and battle mechanics, but the heart of the system is simply a physical and social chain, where you try to manage the fallout of your older choices, especially as side effect build up.<br />
<br />
I think it'd be fun! I prototyped it a bit, but it requires a lot more assets to work, so I'd have to put in a lot more effort to make a playable.<br />
<br />
What do you think?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com1tag:blogger.com,1999:blog-11758224.post-91557080115821985522018-03-06T09:28:00.001-08:002018-03-06T09:32:56.253-08:00Methods of Topological Constraints in Base BuildingI love base building games, and I love it when the base building is a challenge.<br />
<br />
Most base building games are spreadsheet games where the checkboxes happen to be on a map somewhere. There's rarely much in the way of topological challenges - it's mostly a matter of building the right things in the right order and dealing with whatever semirandom challenges the game throws at you. <br />
<br />
But I like topological challenges. So here's some methods to introduce topological challenges and constraints.<br />
<br />
<b>Time compression</b> is by far the most common method. Most base-building games feature inhabitants which walk around your world, and they only do their jobs when they're at the right place. Since time is dramatically accelerated, this means that the time they spend going from A to B is a major part of their day. You can see this in games like The Sims, Dwarf Fortress, and any base building game with people that walk around and time that passes. <br />
<br />
Personally, I don't much like this constraint. It is overused. It's especially bad in games where the worker AI is semiautonomous: you can't really optimize the worker's habits and instead just have to dully crowd things together and hope it works out.<br />
<br />
<b>Connective constraints</b> are also quite common. This is when base component A has to be within X distance of base component B, or you need a physical wire, or some other method of constraining the shape of the base by requiring things to be within certain ranges of other things. Often this only applies to specific types of facilities - typically electrical. For example, in Fallout 4 and Rimworld you need to wire up your bases for electricity. <br />
<br />
Some games are much more constrictive. For example, in MewnBase you have to have every pressurized unit connected directly to another pressurized unit. In Space Engineers, booster elements have to be directly attached to boostable components.<br />
<br />
Some connective constraints are so common and natural that we don't even think about it. For example, every base-building game where you can build vertically requires the next story to be built on top of the previous story. This kind of "crushing constraint" we'll talk more about later.<br />
<br />
<b>Simple topological constraints</b> is when you can only build in specific places, and the explanation is very bluntly "you can't". For example, in Dune you can only build on concrete, and extending your concrete is a major factor. In fantasy citybuilder, you might only be able to build on the valley tiles, and not on the mountain tiles. You can't build over there because you can't build over there. Simple.<br />
<br />
This is typically a level-bound constraint - that is, the player is challenged to make their facility work within the constraints of the level. The connective constraints we discussed before are module-bound constraints instead - that is, these modules have the same constraints regardless of the level you're on. The two typically work in conjunction to put a lot of pressure on a player. These two constraints working together have produced some of my favorite base-building games.<br />
<br />
<b>Perimeter constraints</b> are when there is a fitness test waged against your base in a topologically consistent way. For example, a windstorm blows through every month, always from the same direction. Invaders spawn at the edge of the map and march towards you. Space lasers hit your battleship from predictable directions while you're in battle. <br />
<br />
While there are many kinds of fitness tests, these perimeter constraints deserve special attention because they are topologically enforced. This isn't you running out of gold or whatever: there's something producing stress on your topological perimeter, and you have to build your perimeter specifically to deal with the threat. Extending your base is often expensive simply because you have to start with your defenses!<br />
<br />
Some perimeter constraints are more brutal. For example, if the island is constantly sinking, so after a while all your perimeter buildings are simply erased.<br />
<br />
<b>Topological stress constraints</b> are similar to perimeter constraints, except they're not based around your perimeter. This is commonly used as a secondary enemy type in enemy-centric games. For example, teleporting troops pop up in the middle of your base, or there's lightning strikes that hit randomly somewhere in your facility.<br />
<br />
These produce topological stresses, but at semirandom locations. For example, in Evil Genius, one kind of hero would dig through the walls of your base and pop up inside. The places they can arrive are predictable, but typically well inside your defense perimeter. <br />
<br />
Building your base to withstand these arbitrary pressures is quite a challenge, and typically these sorts of threats are considered advanced or high-level, since building a functioning base in the first place is the main challenge.<br />
<br />
There are other kinds of topological stress constraints:<br />
<br />
<b>Self-induced topological stresses</b> are similar, but these are topological stresses you create with your own engineering. In a space ship game, this might be heat: you can't fire your lasers for long because you didn't put in enough nearby cooling. In a fantasy game, it could be height: building a skyscraper in Medieval Engineers is challenging because of the physics of building tall stone structures.<br />
<br />
Personally, I think self-induced topological stresses are the most fun. I like to change connective constraints into self-induced topological constraints by adding in concepts of quantity, speed, and gravity. For example, many base-building games allow you to pipe water. In most games this is a simple connective constraint - pipes must connect to pipes. But if we introduce some basic physics, we create a lot of interesting new challenges.<br />
<br />
At lower levels, piping water would be basically the same as if we were just doing connective piping, because that's how the physics is weighted. But when we try to bring in a lot of water, or water under high speed, or lava instead of water, we have to get really clever. Imagine trying to build a medieval castle and figuring out how to pipe in lava, or maybe using high water pressure to create a defensive cannon.<br />
<br />
<b>Moving constraints</b> are rarely seen, but they are simply topological constraints coming about because you can move portions of your base. At the most basic level, this can simply mean locking the doors or raising a drawbridge when enemies attack. At more complex levels, it might involve sliding ladders, moving staircases, inflating rooms, tuck-away furniture... but I think this concept can be pushed far, far harder. We just generally don't think about it much.<br />
<br />
<b>Constraint Result Types</b><br />
While we've talked about the kinds of constraints we might see, it's also worth talking about what happens when the constraint hits a fail state.<br />
<br />
"Hard" constraints aren't ones that are difficult, they're ones which literally cannot be failed. You can't build on mountain tiles. You can build levitating buildings. If you somehow manage to get into an illegal state, the facility is erased - it collapses, explodes, etc.<br />
<br />
A medium-hard constraint is one where you can get into an illegal state, but if you do, the facility doesn't immediately vanish. Instead, it is simply nonoperational or begins a countdown to death. This is often found with things like not wiring up your power-hog modules: the player is allowed to realize their mistake (or plan ahead by building illegally), then fix it up afterwards. This is also often found with things like structural stresses: the overstressed pipe doesn't immediately explode, first it springs a leak.<br />
<br />
A soft constraint is where there's not really an "illegal" state, it's just that the state gets worse the more stress you put on it. For example, as you route more electricity through a wire, it gets hotter and hotter and you have to deal with the heat output. Or the taller your building, the thicker the lower story walls get, until they're so cramped that people can't even get through.<br />
<br />
Anyway, those are some of my thoughts, mostly to myself. Let me know if you have any opinions on the matter.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-75695428225189669672018-02-23T08:26:00.000-08:002018-02-23T08:26:53.646-08:00Constructive DifficultyAs you know, I like construction games. I like building things. <br />
<br />
But nearly all construction games make construction too easy!<br />
<br />
I don't think the games are too easy. I think the <i>construction</i> is too easy. I don't need goblins attacking in waves or plague or economic challenges. I'm here for the building! Give me a construction challenge!<br />
<br />
A long time ago, I fell in love with Medieval Engineers, because construction was a real challenge. At the time, there was no inventory: if you needed ten stone to build a wall, you had to get the ten stone within a few meters of the wall. If you were building a tower, you had to build a scaffold first, so you'd have a place for stone vertically close enough to the wall. In turn, the mechanical elements - carts and pulleys and stuff - were actually useful, because you didn't want to lug those stones up yourself, one by one!<br />
<br />
In short order they added a magic inventory. Also, they made the buildings more structurally forgiving, because they decided to focus on warfare, and the idea was to see how well your building could survive bombardment instead of if your building could stand at all.<br />
<br />
This ruined the game for me.<br />
<br />
The problem is that Medieval Engineers is actually more about siege combat than anything else. With that focus, simplifying the construction and focusing on how the buildings survive sieges makes sense. It allows players to get to the meat - the sieges - faster and more robustly.<br />
<br />
Of course, I don't give a single crap about sieges, so to me the game is now pointless. But I can't really blame the game devs for not having the same priorities as me.<br />
<br />
I want to build. I want to have to figure out how to make a three-story building and use buttresses to keep it from falling over. I want to see how high I can build a tower, and what clever things I can do with internal supports to eke out a few more stories. I want to build a castle on a cliff and have to figure out how to wire it into the cliff so it doesn't go sliding down the mountain. These are the challenges I like.<br />
<br />
This isn't limited to medieval stuff.<br />
<br />
When I build space ships, I want to struggle to get them to work at all, so that when I make even small, functional rockets it feels great. Kerbal used to be quite good at this. However, as Kerbal came closer to release, they carefully dumbed down all the physics elements. It's now extremely difficult to get a rocket to fall apart: everything auto-welds and the forces have been much reduced. The game is much more focused on simple payload/fuel calculations, which isn't nearly as interesting to me.<br />
<br />
Starship Corporation is a lot more my style, with intricate construction and extremely interesting testing phases. However, the game's difficulty doesn't revolve around engineering challenges, but around contractual obligations and research constraints. Once you understand the complex, nitpicky nature of things like power and oxygen, you can engineer a lot of interesting ships... except the game doesn't give you any additional parts or hulls until you've spent hours and hours and hours doing absolutely nothing. Again, the challenge isn't related to the construction, the challenge is based around some external measure of fitness that can't really be turned off.<br />
<br />
There will always be some external measure of fitness, some external gating or rating system. Otherwise the game would be completely freeform. That wouldn't necessarily be bad, but it would fail to engage a lot of players. So the external ratings continue.<br />
<br />
But these external ratings could be tied to the actual construction of stuff, instead of to how well you do things outside of construction, such as stabbing orcs or balancing a corporate checkbook.<br />
<br />
A good example of this would be a skating game. The game is all about doing tricks and stunts. You earn scores based on your tricksiestuntness, but the scores are largely open ended. <br />
<br />
The scoring is usually weighted to prefer long combos - meaning that you typically want to string tricks together rather than go for one ultimate mega-trick. This shapes the way you do tricks, but it's still fundamentally about your own stuntwork and allows for plenty of personal self-expression.<br />
<br />
Alternate ratings systems - such as bonus points for being higher off the ground or moving at faster speeds - would result in different priorities for our tricks. Moreover, these would typically be just as easy to implement. It would be trivial to make it a toggle: join one team and get rated based on chained tricks. Another team, rated on speed. Another team, rated on height over the ground. Now the player has a ton of freedom to shape their own external ratings system to match their own stunt construction preference.<br />
<br />
I want building something to feel the same way. I want my construction to feel like a neat trick chain in a skating game. Something I personally did, with my personal skill and priorities and artistry. <br />
<br />
And that means it has to be hard to do, but also with enough slack that I can do a lot of different things for any reason I feel like.<br />
<br />
Can that exist as a game people want to play?<br />
<br />
I dunno.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-65774959301511068382018-01-12T08:03:00.000-08:002018-01-12T08:03:01.723-08:00Simple Mechanics for Compelling GamesRecently there's been a bout of compelling games using very simple mechanics. In particular, I'm going to use the mobile Marvel Puzzlequest game and Battle Chef Brigade as examples, because both create compelling and narratively-dense games using match-3 gameplay!<br />
<br />
Using simple gameplay to make compelling games is far from a new idea. Every game does this. An RPG uses basic math. A shooter uses simple moving and shooting.<br />
<br />
But what we're seeing these days is something a bit different. The play is more emergent than ever, and the emergent play is more narratively compelling than ever.<br />
<br />
Everyone tells stories about that time something cool happened while they were playing a game. The ten-person raid that almost didn't work out. The time you drove a jeep into an exploding alien. When you did five no-scopes in a row. These emergent moments are extremely powerful draws, to the point where many games (like Overwatch) attempt to automatically highlight cool emergent moments.<br />
<br />
But you don't need expensive content or complex mechanics to create those emergent moments.<br />
<br />
For example, I just had a fight where Storm, The Thing, and Juggernaut fought Spider-Man and two of those Spider-Man variants or clones or whatever they are. It was an epic fight. Storm was about to die, but The Thing stepped in the way, took the blow, and went down himself. Even while unconscious, he shielded Storm as she called down a hailstorm. Finally she went down to a web-swinging kick, and it was just Juggernaut against them. The hailstorm helped take out two of them, but in the end, Juggernaut and the last standing Spider-man were going toe-to-toe. Juggernaut couldn't catch him, and was ready to fall over at any second. In a last, desperate attempt, Juggernaut slammed his helmeted head into Spider-Man and they both went down. A battlefield of fallen heroes. Well, the villains were stopped, and that counts as a victory for the heroes, even if they're all unconscious.<br />
<br />
Here's the twist: that whole battle was a damn match-3 contest. There were very few visuals - just some particle effects and a few generic superhero poses flashed up from time to time.<br />
<br />
Still, it felt properly epic in my head, and it was probably the best time I've ever had playing a match-3 game. Would it have been better with more graphics? Sure. But putting aside the juice, the fundamental play of the game allowed this story to emerge.<br />
<br />
Regardless of anything else, we want our gameplay to allow for that kind of emergent narrative. How do we do that?<br />
<br />
Well, first is <b>contextual elements</b>.<br />
<br />
In the Marvel game, the context is really easy: the various characters on each side of the fight. We are familiar with most of the characters, or at least their templates, and therefore we can easily picture how things are unfolding. Even the assists have a character attached.<br />
<br />
In Battle Chef Brigade, the characters on each side certainly have context, but since you're always playing the MC, that's not really a factor. Instead, it's the ingredients and judges you learn to identify. This takes more time than Marvel's context, because we aren't really familiar with the elements in BCB, but it's the same basic idea.<br />
<br />
Context is mostly established at or near the beginning of a match. You know who's fighting, who the judges are, which ingredients are available, etc. Context can change over the course of a fight as well, but the starting context is critical. Here I think BCB does well: the various statistical effects are incorporated into high-context items like fun pots and strange knives. The Marvel game isn't quite as good, since they're just called things like "blue/green boost".<br />
<br />
<b>Endings</b> are important, and not just statistically.<br />
<br />
In the Marvel game, the end of the battle isn't just a win/lose. There's also how many resources you expended, and how long injured heroes will take to recover. But more than the statistical elements, there's the question of how the victory unrolled. Who gave the final blow? Who fell, when? I don't think that the Marvel game plays this up as much as they could, but it would probably hurt their monetization if they tried to push this any further.<br />
<br />
In BCB, the ending also isn't simply win/lose. You are judged by several judges each. This not only gives a final win/lose, but teaches you more about the judges and what you should serve them next time. In addition to that, the dishes themselves are fun. You've created the dishes out of high-context ingredients, and seeing those transform is fun. Put in a lot of eyeball monsters, the final dish is an Eyeball Saute.<br />
<br />
How things end is the capstone of your narrative experience. If the arches are in the right spot, the capstone holds everything together and you get a great result. If the arches aren't right, or the capstone isn't placed, the whole thing collapses into rubble.<br />
<br />
Although Marvel's game can give us great fights with cool endings, that's not the norm. Normally fights fizzle out without much of an ending. This is made worse by the fact that the difficulty is front-loaded: the ending is almost always the easiest part of the fight, when you have the fewest enemies and the most resources to deal with them.<br />
<br />
This isn't universally crappy, though. The statistical results of fighting mean that a battle's conclusion feels real and solid even if the ending was pedestrian. For example, if you win without taking a hit, you don't have to heal anyone and can immediately move forward, and that feels pretty great even if you were a set of level 100 heroes against a set of level 3 baddies.<br />
<br />
BCB punches up the endings a bit better, because rather than constantly bickering with the enemy, it's a race against yourself, a race against the clock. You can feel the ending getting closer and closer, and the tension naturally rises as you move into various phases of play, judging for yourself how much time you can spend in each phase. On the downside, the enemy isn't really in your face as much. Trash-talk, interfering on the hunting grounds, and so on might help to alleviate that distance, but in the end it is an indirect conflict.<br />
<br />
There are a variety of potential avenues towards making something like Marvel's game have better endings, and it all involves building mechanics that pace the ending better. Some of those mechanics might be in-match, such as enemies gaining resources or hitting harder as they get injured or lose team mates. Some of those mechanics might be meta elements, such as a penalty for taking overlevel characters into battle against weak enemies. Either way, they're just imaginary, there's no way to tell how well they would work without trying them out. There is a risk of locking the player into overly strict progressions, which would be just as bad as ending on a fizzle.<br />
<br />
<b>Midgame Management</b> is another important element.<br />
<br />
When you are playing a match-3, there's a lot of focus on the nature of match-3 play. Not only do you want to line up 3s, you'd like to line up 4s and 5s and double 3s and cause chains and so on. If there's no time pressure (like in Marvel's game) hunting for the best move can be as slow and careful as you like. For games with a timer (like BCB), the focus is typically on smaller grids and heuristic approaches.<br />
<br />
Both games make "tending" the battlefield critical. In Marvel, enemy heroes get to take a turn, so it's important not to accidentally leave them with a good move. Done well, you can even trick them into destroying their own attack tiles! While there are only a set number of colors, the weights vary: some times you'll need to absolutely set up greens to insure you can stop rocket attacks, while other times you may want to hunt down that fist icon on that yellow tile. By layering effects on top of colors, the fundamental matching stays the same, but the weight of each color or region of the map changes dramatically.<br />
<br />
In BCB, you add all the colors yourself, more or less. With a smaller battlefield and self-chosen colors, you'd think it'd be easier to manage. However, they take a Threes approach: blue isn't always blue. When you match some blues, they turn into a bigger blue that only matches with other tier-2 blues. And so on.<br />
<br />
Suddenly the smaller battlefield is not "easier" but "more cramped". Every match you make leaves you worrying about how you'll fit in the next ingredient, and whether you can afford to temporarily knock those two tier 4 blues apart so you can make a tier 3 red... or will the pot overflow before you can recombine them?<br />
<br />
These are very different approaches, but they both work. One creates midgame management by adding layers of meaning to various tiles or colors, whereas the other creates midgame management by steadily adding in more and more colors as you make matches. <br />
<br />
Of course, neither is completely focused on their approach alone. In BCB specific colors do have different weights depending on the judges or the main ingredient, and in Marvel's game you do get special tiles like criticals that pop up from time to time.<br />
<br />
Either way, adding depth to the core gameplay is an important part of keeping the player engaged. Both in terms of adding a difficulty curve and in terms of making context pop.<br />
<br />
For example, when you are adding in your ingredients in BCB, you're thinking about whether you can get them to congeal correctly... but you're also thinking about them as Things That Exist. "Should I add more eyeball?" is a question that has both statistical and contextual meaning, and your decision will change how you think about your dish.<br />
<br />
There are many ways of adding depth, too. For example, in addition to everything else, in Marvel's game, whoever has the best "attack value" with a given color makes an attack when you match that color. This also leaves them on the front line, and they'll take any damage thrown at your team. This makes managing high-power attackers with low health a fun challenge which evolves over the course of the game as health values fluctuate.<br />
<br />
<b>Mix-ins</b> are a big part of making simple gameplay support complex contexts.<br />
<br />
In Marvel, your heroes (very high context) are given additional context by their powers. As you make matches, you earn points of various colors, and the various heroes have powers that cost points or are affected by specific colors in various ways.<br />
<br />
The diversity of powers is enormous. For example, The Thing has a power where he'll step in front of squishier characters and also create protection tokens, only moderately affected by board state. Kraven the Hunter will diminish enemy tiles and steal mana if there's a lot of enemy tiles. Hawkeye can create a critical, or wipe out a row of tiles. Storm and Juggernaut both have a green ability to smash tiles: Juggernaut smashes more tiles, but Storm earns mana from smashed tiles.<br />
<br />
These modifications are not technically part of the match-3 game. They're another game layered on top - they affect each other, but are separate kinds of play. The link between the two is quite tight in this case, largely because there's no time pressure, so the player can just sit and think for a bit about the various options.<br />
<br />
In BCB, the alternate game mode is much more distinct: you go out into the wilderness and hack apart monsters for ingredients. Since there's a lot of time pressure, the modes only loosely interlock. That way the player can stay focused - trying to stir your food pot while hacking up a wolf would be considerably more stressful and difficult.<br />
<br />
In an RPG you sometimes think of these sorts of things as the other play loop. Like, you explore a dungeon, fight random monsters, get treasure, level up - and each of these are distinct elements. <br />
<br />
However, in these simpler games we're seeing, the mix-ins are literally mixed in. They weave in and out of the normal play loop. It'd be like if you leveled up mid-fight and had to choose exactly what bonuses to take before the fight continued. In a classic RPG this would be a bit weird, because the battle system is engineered to keep your whole focus the whole time, so bopping off to do something else for a moment would break your groove.<br />
<br />
But with these simpler games, you can wander in and out of the main play without really losing too much focus, since a glance at the board will remind you of where you stand. Moreover, this wandering can be used to radically increase the context of the play and provide additional story beats. When Storm summons hail, it's Storm summoning hail. It's not just a statistical effect: your board and play state is now coated in Storm's story beat. Similarly, killing an eye monster and bringing it back to throw in your pot adds a ton more context to your pot, much more than if you just had a giant stack of eyes on a shelf to throw in.<br />
<br />
...<br />
<br />
I used match-3 games as an example, but I think this can be done with any kind of gameplay. You can even dissect existing complex gameplay as two or three kinds of simple gameplay mixed in - running and gunning is [running] and [gunning]. RPG battles are [initiative] and [math]. It's a fun thought, although I'm not convinced it's a good universal framework.<br />
<br />
But it can be fun to analyze that stuff with this new eye. If your game is [initiative] and [math] mixed together, can you use the lessons learned here to punch up the context, the ending, the midgame management, and the mixin? It might be really interesting to try to create an RPG that's been re-engineered from scratch to focus on in-battle emergent narratives.<br />
<br />
Anyway, those are my thoughts. What do you think?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-79581360208662844572018-01-11T08:32:00.001-08:002018-01-11T08:32:15.264-08:00Designing Inhabitant-Centric GamesThis is an example game design for a person-centric base-building game. Sort of like Rimworld, except the people are the focus and their stories feel more solid, like in The Sims. See <a href='http://projectperko.blogspot.com/2018/01/the-sims-vs-rimworld.html'>the previous post</a> for details of the why and how.<br />
<br />
One thing we need to do is abstract jobs more than Rimworld and other base-building games do. If jobs are simulated in the same space and time as the home, then duties won't be very isolated. This means it's difficult to control the way duties work and the events they cause, and it also makes the duty time 'permeable' - people can swing in and out as they see fit. Those are all bad things.<br />
<br />
Therefore, our first goal is to create workspaces separate from our home spaces. The two obvious approaches are out-map and in-map jobs.<br />
<br />
Out-map jobs are simply duties that take characters out of the densely simulated home area and off to somewhere else. For example, a farmer leaves to tend the fields, which are not part of the same map. Or a superhero leaves to patrol the city, which is obviously not inside the secret base. These remote areas can still be managed by the player - setting up exactly how many of what fields are where, or what the patrol route is - but they're not simulated in the same space and the workers are not available to the people still at home. Of course, out-map jobs are also good in that you can change the remote conditions without needing to change the local conditions, or visa-versa.<br />
<br />
In-map jobs are when the worker is still in the home space, but not being simulated as part of the home experience. This could be something like a woodshop - the worker is technically still on the map, but they aren't wandering around or chatting or worrying about whether they need to go to the bathroom. In a superhero setting, this could be researchers or radio support or training - anything that can be done locally and allows us to lock them into a set pattern for the day. The difficulty with this approach is that it doesn't naturally give a schedule - you can train whenever, you can research whenever, etc. That makes it a little harder to create scheduling frission between different jobs.<br />
<br />
Obviously jobs aren't the only thing that matter in our design, but with this in mind, we know that a big part of our design will be outside the map, or at least abstracted within the map.<br />
<br />
Within our densely-simulated space, we need to design carefully. The purpose of this space is to help build personal stories both in gameplay and in the player's mind. Most of the base-building games that are popular these days are meter-by-meter designs. This has many advantages, allowing the player to express themselves freely while also locking the player into topological challenges presented by both the initial setup and the player's own previous base-building choices. It's a good way to create opportunities for the player to freely create a base with a lot of unusual elements both incidental and purposeful in an attempt to optimize performance.<br />
<br />
But that's a base-centric approach. If we plan to be people-centric, we need our bases to support story and context, both with game mechanics and in the player's mind.<br />
<br />
What can do that?<br />
<br />
Well, if we want to create context, then we have to make the inhabitants relate to the space with context. That is, the people in the world have to want to use the space in specific ways that produce familiar or memorable stories.<br />
<br />
In The Sims, examples of this would be the bathroom. There are rules about exclusivity in the bathroom - it's usually one person at a time, but perhaps family can use it at the same time. You can create different kinds of bathrooms to give the player funny stories about how the bathroom works - for example, sticking a window in it facing the living room. The exclusivity rules are in-game rules that are familiar to the player and create good context, while the funny design alternatives are mostly in the player's head, but still create good context.<br />
<br />
Bedrooms are similar: is it one person's room? A big bed for the parents? A crowded row of beds for a bunkroom? There are in-game rules about the effects of these things, but even more important is how the player has expectations for these things and feels a heavy sense of context depending on how it's built and the people living in it.<br />
<br />
Public spaces like living rooms are equally high-context. These are gathering places where people get together. Sometimes in passing, sometimes to cooperatively do something (eating, watching TV, etc), sometimes to do different things in the same area at the same time (one person cooking, one person dancing). Public spaces are further leveraged by scheduled events such as parties and family dinners. All of the various ways people can gather have context, and the space itself enables those contexts while simultaneously creating additional context in all the ways it doesn't quite fit. For example, if your party can't easily get food, you get more context: hungry guests moving into the kitchen instead of staying in a completely open space, now standing clumped together.<br />
<br />
All that said, The Sims still uses a meter-by-meter construction system. Well, there are some differences.<br />
<br />
The Sims construction focuses on walls to a great extent. Most base-building games have walls that are one tile thick: meter thick walls! But The Sims has paper-thin walls, and this allows the player to carve up map quite densely and with ease. This packs far more useable space into the same size map. This may sound unimportant, but it's critical. Not only can you fit more, larger characters onto the player's screen at one time, but the characters are also substantially closer together, allowing them to interact more regularly and freely. For example, someone in the kitchen can easily chat with someone in the living room, whereas if the walls were a meter thick, that would feel more like shouting range.<br />
<br />
These seem like small details, but when it comes to creating human context, human details like that matter.<br />
<br />
The Sims also has complex standing positions. Rather than "one tile per person", people in The Sims can stand in arbitrary places and in arbitrary groups. Although I don't think The Sims uses proximity as a reflection of intimacy, this is an obvious use: people who stand closely are more intimate than ones that stand meters apart. Similarly, people who sit on a couch together are in a different social situation than people sitting on random chairs.<br />
<br />
In short, a dense space that can be used by people standing in a wide variety of configurations. A dense space with variable publicness and utility.<br />
<br />
Combined with our off-map jobs, this clearly reflects a focus on someone's home, rather than the more widely-scoped mixed spaces of most base-building games.<br />
<br />
Classically base-building games have avoided being solely about someone's home. Statistically, the other aspects of the base are more interesting. But statistically interesting is not what we're interested in. Topologically interesting, yes. But we're simplifying the statistical aspect, and a very easy way to do that is to chop off all the job-related base-building stuff.<br />
<br />
From here, deciding a genre is probably critical, since 'home' has a different meaning depending on the genre.<br />
<br />
If we set it in the modern era, it'll be very Simslike, because we've basically reverse engineered the core features of that game.<br />
<br />
A superhero genre would work well. A team tower or secret base would be our home. Our characters could have night patrols, daytime rescue missions, media reachouts, school, day jobs, investigations - those would be off-site. On-site abstracted jobs could involve training, radio support, research, crafting, etc. This would no doubt be an interesting setup, but there is a weakness in that superhero bases tend to be attacked. This isn't as bad as in most base-building games, because 90% of your assets are locked into your inhabitants, not your facility. Rebuilding or moving is cheap enough. But players would still focus on defenses, and that may be hard to make feel just interesting enough without taking over the game entirely.<br />
<br />
A fantasy setting could go rural or adventurous. A rural setting would allow people to go off map for things like farming, crafting, etc. It would also allow for interesting long-term setups, since sending children away for years would not be uncommon. However, I'm not sure that the feel of rural fantasy life would make much of an impact on the player.<br />
<br />
An adventuring setting could be fun, though. You could run a guildhouse. It would have a lot of similarities with the superhero idea, but missions would often take several days, and managing funds would probably be more important. The medieval lifestyle simplifies the living space considerably, and characters would be far more likely to have to spend their leisure time together instead of separately watching TV or whatever.<br />
<br />
A sci fi setting might be fun. You could create a Mars base or something, with dome bubbles for inhabitable areas. Within each dome, only thin walls would be used for weight and air permeability, allowing for very dense space. The lifestyle of science fiction might not have much impact on the player, but sci fi is more flexible than fantasy, so it's possible to just make their lifestyles more familiar even if it doesn't really make too much sense in the setting.<br />
<br />
Well, you could also do something like Firefly, where it's aboard a space ship. The problem with this is that space ships often have very heavy, environmentally-sealed areas. In addition, there's not really any "off map" to go to, meaning that our job management might be hard.<br />
<br />
A fantasy sailing ship might be fun, too. Job management might be hard due to the lack of 'off map', but I think it could be managed.<br />
<br />
There are a lot of possibilities. I don't really feel the need to push further down any given road right now, though. I'll just let my brain rest a bit.<br />
<br />
What do you think?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com2tag:blogger.com,1999:blog-11758224.post-2661545879099310732018-01-09T11:15:00.000-08:002018-01-09T11:15:37.958-08:00The Sims vs RimworldThere's a new genre hiding in plain sight. A genre about people.<br />
<br />
Base building games are including more and more "personal simulations" about the people in those bases. For example, in Rimworld each member of your crew is simulated in great detail. Not only their stats and skills, but also their moods, personalities, traits, and so on.<br />
<br />
But it's difficult to feel the "story" of these people. Despite getting sad over losing their dog, or having a bad case of the plague, or dating someone, the character stories don't really have a strong impact on the player. <br />
<br />
This is because those events are framed in terms of how they affect the facility rather than how they affect the person.<br />
<br />
If someone loses a pet and goes into a long mourning slump, the player has to try and keep them from going berserk or spending days just wandering around. It doesn't even really feel like "the story of that person", it just feels like one of the cogs in your machine is wobbly.<br />
<br />
Because it is.<br />
<br />
A base building game like Rimworld is about building bases. It's about creating an ever-more-complex self-sufficient machine. The inhabitants, no matter how diligently simulated, are cogs in that machine.<br />
<br />
In contrast, consider The Sims.<br />
<br />
It's a different setting, but The Sims has most of the same kind of setup as Rimworld when it comes to people. Each sim has specific traits and skills and goals, they tend to have specific jobs, things can go wrong - it's very similar to Rimworld in that regard.<br />
<br />
But the house they live in is not a complex machine. <br />
<br />
Although you can build your house with astonishing attention to detail, it is not self-sufficient and doesn't need to be. As long as there's some source of money, everything else is optional, and there's no real need to optimize your performance.<br />
<br />
The role of "day job" is less about optimally making money and more about providing a scaffold for life experiences - it shapes both the character that goes to work and everyone they share the house with. If things go wrong or get delayed, the house will not collapse just because the day job person is being suboptimal.<br />
<br />
Compare this to Rimworld, where it's very likely that half your base will catch sleeping sickness and then whoever is awake will get too moody and start lighting things on fire, at which point a crowd of monsters will attack. Rimworld is about creating a base that can survive all these bumps in the road, even if they pile up. So anything that goes wrong is a bump to your base, even if on paper it's the story of how Anna is depressed and Bob is sick.<br />
<br />
The Sims is just the opposite. If something in the house goes wrong, like a sink exploding, the player will naturally contextualize it as part of Anna's crappy day rather than a systemic setback. Even death isn't a sign that the <i>house</i> is doing badly, it's a sign that someone's particular story has come to an end. That may be very upsetting, but it's contextualized as that person dying, not your overall facility degrading.<br />
<br />
I think nearly all of the difference in this contextualization is simply because the 'facility' in The Sims is not a high-stress facility. You don't have to worry about droughts or animal attacks or hurricanes. It's pretty easy to establish a baseline habitability, and then everything else is just improving things more or having fun with side tasks.<br />
<br />
The lifestyle options for Sims characters are all side options. Some are very dense, some are not, but they are all optional. They provide a stable, steadily-progressing scaffold for the characters' life stories while also providing a steady diet of life events. For example, gardening: you don't have to garden, but if you choose to, it's a steady task that moves forward day after day. Your garden will never be attacked, and even if your whole garden was destroyed, your sims would not die: the baseline habitability would not degrade that far.<br />
<br />
If we want to make a game that focuses on the lives of the characters, it's critical that their support system is straightforward and robust, so that setbacks can be judged as affecting the characters rather than the support system. Similarly, the progression system needs to be character-centric rather than facility-centric.<br />
<br />
As an example, Rimworld's research system unlocks construction options for the whole base once someone researches how to build it. A character-centric approach would be to allow only that character to build it.<br />
<br />
In addition to being character-centric, a character's chosen lifestyle/career/hobby needs to provide a stable, steadily-advancing scaffold, needs to exert pressure on their life and the life of those around them, needs to provide small random events and schedule burps, and needs to respond to a character's own personality/pressure/situation outside of the lifestyle.<br />
<br />
For example, rather than the farming system Rimworld currently has (identical to other games such as Dwarf Fortress and Minecraft), we would instead have the farmer work fields on a schedule. The more fields, the more hours of the day are required, and time spikes at harvest and planting. The result is a nice, predictable, slowly-changing curve as to how much time they have to work and how much time is available for other pursuits. Their early-morning schedule would bump up nicely against someone who gets up later - for example, a researcher or carpenter.<br />
<br />
In theory, the fully-simulated fields work this way. But in practice, there are too many variables. For example, just walking from point A to point B can take a lot of extra time. Also, the characters aren't great at schedules, and frequently get distracted by their overwhelming need to pick up a meal halfway across the map or whatever.<br />
<br />
By <i>reducing</i> the simulation fidelity, we can allow for a more 'readable' character lifestyle. This will help the player to 'feel' the character's life, personality, needs, and so on.<br />
<br />
And I think that is where a genre is hiding.<br />
<br />
Right in there.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-6783494197560880992017-12-13T08:31:00.001-08:002017-12-13T08:39:11.354-08:00Generating Screen TimeThe most underestimated element of characterization is screen time. How much time a character has in front of audience eyeballs.<br />
<br />
The reason it's underestimated is because it's usually mostly automatic. You write characters for a story, you give them traits to help tell the story, you let them help tell the story. Even a first draft will have a fairly suitable amount of screen time for the various characters.<br />
<br />
When generating characters randomly, this doesn't happen.<br />
<br />
There's an urge to generate characters similar to the ones you might write. Similar traits, visual features, and so on. But this is 'cargo cult' character design: you're emulating the sizzle of a character without understanding the meat. <br />
<br />
The meat is screen time. You have to generate screen time.<br />
<br />
In fact, I'd wager generating screen time is cheaper and more powerful than generating characters. I bet you can radically extend and punch up a game by adding in generative screen time without any generative characters. <br />
<br />
Let's show some quick examples:<br />
<br />
In Mass Effect, all of the characters are designed to support the fiction of the universe. As such, even if they aren't chosen to be in your party, their plot arcs still play out. Their roles in the universe are distinct (at least in ME1 & 2), and therefore it's easy to remember who someone is even if you don't pay any attention to them after their introduction. In addition, they are frequently given 'tidbits' of screen time even when not in the main party.<br />
<br />
We can break these methods into a few specific types, each of which can be generated algorithmically. I'll use Liara T'soni from Mass Effect One as an example: she's not a very good character but lots of people love her anyway. Thanks to screen time.<br />
<br />
<b>Concerns</b><br />
The first, biggest mistake is to think about character traits.<br />
<br />
Traits are not what you need, and never have been. Instead, you need concerns that create screen time.<br />
<br />
The two are very similar, but thinking about "concerns" instead of "traits" should help to drive your planning. Concerns can be things the character is concerned about <i>or</i> things the universe is concerned about, or both.<br />
<br />
For example, Liara has a lot of very dull, stereotypical traits: she's cute, inexperienced, has a crush on you, likes Benezia, Spocky, a pureblood Asari, is clumsy, etc.<br />
<br />
Converting these traits over into 'concerns' instantly helps us give her screen time related to them.<br />
<br />
The concern version of that list might be: doesn't realize she's cute, very nervous about her inexperience, nervous about her crush, respects Benezia, wants to use logic to help, is both proud of and ashamed of being pureblood Asari, gets stuck in a lot of awkward physical situations.<br />
<br />
By restating her traits in this way, we can quickly see a lot of scenes suggesting themselves. You can inject 'very nervous about her inexperience' into almost any scene she's in, turning her from a background character into a foreground character - giving her screen time. Any scene. You could be fighting monsters, and you could find some way to use it. "I've... I've never seen mufflebats in person before! They didn't seem quite so... vicious... in the holotapes!"<br />
<br />
In more focused scenes, you'd probably want to use multiple concerns simultaneously - for example, she can be nervous about her crush on you and her inexperience at the same time. Or you can use contrasting concerns - she respects Benezia, but Benezia no longer respects anyone. She wants to use logic, but she has a crush on you. Etc.<br />
<br />
<b>Core Concerns</b><br />
Notice I didn't mention Liara's core character trait: she's a nerd.<br />
<br />
Core concerns are concerns like any other, but they're unique because they exist specifically to drive the story forward, to draw the player into the universe.<br />
<br />
Liara's core concern is her obsession with the ancients. This is a many-pronged concern which allows her to help the player understand the ancient psychic visions, drive the player to explore new ruins, and just generally try to get the player enthusiastic about the plot by being enthusiastic about the plot.<br />
<br />
Unlike more personal concerns, core concerns might be too hard to really generate or embed in scenes on the fly. They're too deeply tied to the story or the universe. It's probably best to simply assign them rather than generate them.<br />
<br />
For example, if you randomly generate some royalty for your fantasy game, you can give them the core concern to pull the player into the world. King or queen, good or evil, old or young, they give the player an excuse to go various places and give the player an introductory letter to important locals. They drive the player's experience regardless of their other concerns.<br />
<br />
<b>Screen Time Types</b><br />
Once you have concerns figured out, you need to convert them into screen time. Keep in mind that screen time requires that a character have the attention of the player. Being in a crowd shot doesn't count, nor does just randomly standing around in a room without having any interactability.<br />
<br />
<i>In-party commentary</i> is probably the most subtle and reliable approach. The character simply has something to say over the course of the player's normal adventuring, without interrupting the player's normal adventuring. For example, they might comment on the place, or an enemy, or banter with another party member. These can be injected seamlessly or they can be queued up by interaction spots - for example, a nice view, or a burned-down house.<br />
<br />
<i>Radio commentary</i> is a more aggressive version: the character has something to say about something, regardless of whether they're in the party or not. This is typically reserved for core concern stuff - Liara will chime in to tell you that the obelisk has been moved even if she's not in your party. Particularly good radio commentary might involve having the out-of-party NPCs doing their own, parallel thing, then radioing to report their own conclusions to their similarly-paced adventure.<br />
<br />
<i>Third-party commentary</i> is when the character isn't necessarily around, but is being discussed anyway. It could be other NPCs talking about them, or a wanted poster of them, or an interview of them, or a note they left, or even just finding a relic and saying "hey, I bet Liara would like this."<br />
<br />
<i>Downtime commentary</i> is a powerful and relatively new technique: between adventures, there's a base of operations, and the NPCs are scattered around in it. You can chat with any number of them before moving on with the story. This is a powerful approach because it allows you to remove most of the rest of the world's context: the chatting can progress the same way regardless of which sector of space you're in, regardless of which planet you just visited, regardless of who's in the party, regardless of who the player likes.<br />
<br />
<i>Fuzzy focus scenes</i> are scenes where an NPC is obviously tangentially involved, but it's not really about them. For example, whenever you meet another Asari in ME1, it will remind you of Liara, since she was the representative of her race at the time. Or when you step in to help a doctor, Liara might step forward with good advice and back-pats, perhaps even have some scene-specific sub-branch such as manufacturing extra medicine. The focus is still on helping a doctor, but Liara is getting some screen time.<br />
<br />
<i>Focused scenes</i> are when the NPC is the focus. Downtime commentary is the most common place to trigger these. It's not necessarily them solo, but they're the focus. For example, Liara might chat with you about your newfound psychic memories, or about her crush, or about the nature of the Asari... or maybe she has a scene where she and Tali are laughing at a technical joke nobody else understands, or she's helping Dr. Chakwas with some basic medical duties. As always, these scenes are built out of the concerns of the characters.<br />
<br />
<i>Arcs</i> are when a series of interconnected events happen which focus on the character. Typically these are contiguous. Liara's introduction is an obvious example - most introductions are arcs. You spend some time chasing her around a facility while learning what's going on, and then you team up with her to finish the facility off. This extremely typical example is something that can be generated (or at least customized) for nearly any character, but make sure their concerns show.<br />
<br />
<i>Rogue Arcs</i> are when an NPC switches sides, usually temporarily. For example, a hero might become a villain for a short while, or a villain could join the hero's side. Or maybe someone just takes some personal time and things get out of control. Because of the impact of this, the focus is usually on the rogue character. It has no other special features, though, and can be treated as an ordinary arc in every other regard.<br />
<br />
<i>Schedule Elements</i>... well, a lot of generative games aren't so big on having a central plot arc, and instead focus on cyclic challenges. A character should have a distinct schedule during these cycles, making it possible to run into them in specific high-context ways. Also, they may choose to change their schedule to react to player activities. The two things to keep in mind are that their schedule should reflect their concerns, and participating in their schedule with them should result in progression, not just repetition.<br />
<br />
<br />
<br />
Anyway, those are my thoughts:<br />
<br />
When generating random characters, you should put a lot of effort into generating how they get in front of the player's eyeballs. Just giving them traits won't make the player care about them.<br />
<br />
Your thoughts?Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0tag:blogger.com,1999:blog-11758224.post-25506100844651351592017-11-07T11:27:00.003-08:002017-11-07T11:31:21.470-08:00Building More With LessIn a "building" game, I always want to use fewer types of parts to build a wider variety of results. <br />
<br />
I want the game to feel expressive, like the player can make a bunch of different things with a bunch of different goals.<br />
<br />
For example, do you have a "gatling gun" component? Even if I am making a war ship, a "gatling gun" is an inexpressive element. It's going to be the same for everyone, take up the same space, do the same things in the same way. <br />
<br />
Which is why you also have a "laser gun" and a "missile launcher" and a "sniper gun" and whatever other weapons you can think of... that's expensive. It takes effort to make them, space to have them in your game, and visual clutter to make them all selectable. Even after all that, they're still not terribly expressive.<br />
<br />
<b>Adaptive Elements</b><br />
<br />
How about a system where you have a "gun" module, and then you can tweak the settings? <br />
<br />
Change the accuracy, the range, the rate of fire, the ammunition type. To keep it balanced, you could use a points system - extra points in accuracy means less points for rate of fire!<br />
<br />
If you allow for this, then players can change their weapon loadout to fit the role they want the weapon to fill... and use a lot of fine grain knobs to do it. As long as combat actually interacts with those stats, you've created a method for players to specialize in different combat roles using a very fluid, adaptive system. Depending on the metagame, players might start using unusual combos that canned one-off weapons would never have though of, like sniper missiles or hyper-accurate micro-range burst lasers.<br />
<br />
If the settings reflect suitability for different roles in the greater game environment, they'll be great fun! Just makes sure your UI reflects their settings so the player doesn't forget what is what.<br />
<br />
<b>Soft Constraints and Constraint Systems</b><br />
<br />
Rather than using a "points" system like above, it's better to use a soft constraint that ties into the greater game environment.<br />
<br />
For example, each shot generates heat - the better the shot, the more heat. This is conceptually the same as a points limit, but since it leans into the rest of the world, other kinds of game concerns can affect it. For example, what about firing in short bursts and letting the weapon cool off manually? What about attaching extra coolant systems to cool the weapon faster?<br />
<br />
In this case, the greater game system we're leaning into is heat management. This makes heat management a "constraint system", and those have to tie into as many different things as possible to make innovative and interesting builds possible. <br />
<br />
For example, attaching "coolant modules" to the gun is extremely dull. It doesn't integrate with anything else. But if you have to actually pump coolant, now you have a topology constraint with a lot of possibilities. For example, maybe you want to run colder coolant? Now you need to build coolers. Is your coolant heating up as it moves between the ten things you're cooling? Hm! What do you do afterwards - vent the heated coolant out of the ship where it's likely to be spotted by enemies, or perhaps use it to pressurize living quarters? Run it around the perimeter of your ship to cool it and de-ice your wings? Use it as a low-grade propellant?<br />
<br />
Depending on the scenario, the external parameters and concerns will vary - and the player's own ideas and goals will also cause parameters and concerns to vary.<br />
<br />
You do need to make sure your UI can handle players grappling with these systems.<br />
<br />
<b>Carry and Produce</b><br />
<br />
A related concept is 'carry and produce'. What we did in the last example was turn "heat" from a fungible number into a tangible good. Tangible goods offer a much more interesting challenge with more opportunities for fun constructions. This is especially true if two systems combine into a single tangible good - for example, heat combining with a specific kind of coolant into a single good.<br />
<br />
While "heat" is simply a number, once we transform it into a complex good, it becomes both a challenge and an opportunity. Is it hot water? Glycol? Cool air? Liquid hydrogen boiling off? Each of these offers different specific challenges, but uses the same fundamental 'piping' mechanic. That same mechanic could allow them to be used in any other situation where either heat or that substrate is used: hot air becomes life support supply. Boiling liquid hydrogen becomes propellant.<br />
<br />
This can be done with almost anything. For example, instead of generating "science points", what if you turn that into a tangible good - a science paper which is only converted to science points upon export? Now the science paper can be manipulated in tons of ways to make it more valuable. <br />
<br />
Some players might specialize in quick-and-easy science papers for a trickle of science. Others might specialize in massive databanks to hold the papers until they are at the maximum possible size. Others might use supercomputers to refine the data until the science paper is small, but potent. Others might choose to generate science in different ways - often tied into other kinds of systems.<br />
<br />
It's critical that the UI supports this - supports the player immediately knowing what is being carried and how it is being massaged. But if you can do that, you can create a wonderful opportunity for depth and expressiveness.<br />
<br />
<b>Changing Conditions and Triggers</b><br />
<br />
One overlooked element in most construction games is changing conditions. Normally you just optimize for whatever the current situation is and that's that. About the only construction games with changing conditions are ones where you have to survive the winter, and that's often not pushed very far.<br />
<br />
To keep using heat as an example: heat in an ice-cold winter is very different from heat under a baking desert sun is very different from heat at the bottom of the ocean or in outer space. Your initial instinct might be to simply make each base have a specific heat condition - this is an artic base, this is a deep-sea base - but that's something only beginners will find challenging.<br />
<br />
Increasing difficulty is much more about the swing, rather than the baseline. Optimizing heating systems is more interesting when sometimes it'll be very hot and sometimes it'll be very cold. Designing a space ship that can fly through the atmosphere as well is more fascinating than simply saying "this is a space ship, that is an airplane".<br />
<br />
In general, I think of three kinds of changing parameters, each of which increases in swing as difficulty increases.<br />
<br />
1) Routine changes. For example, people going home for the night to sleep, or solar power only being available during the day. Combining routine changes can make for very fun results - for example, solar power is only available during the day AND at night a punishing dust storm rushes by, leaving an opaque layer of dust on everything. Now you have to have a setup that cleans solar panels or hides them at night!<br />
<br />
2) Catastrophes. These are things outside of your control (although for game reasons the player may be able to trigger them). Fights. Plagues. Crashes. Winter. Holiday shoppers. Typically these are tests for how "disaster-proof" your design is.<br />
<br />
3) Scheduled changes. These are things the player causes as their plans advance. For example, holding an election. Traveling to a new planet. Choosing to land. Giving crew leave. Refurbishing the facility.<br />
<br />
In order for these situations to be fun, two considerations must be handled.<br />
<br />
1) Soft failure. If the player falls short, they should be able to pull through with damage. This is also where beginners will start, so adjusting for failure should be something players can do manually, while panicking. For example, if a storm hits, players have to be able to order people back inside in order to weather it, and the storms should (at least at normal difficulty levels) not instantly kill anything caught out in them.<br />
<br />
2) Programmable responses. The players should be able to trigger responses automatically using in-game objects. For example, allowing the player to lower landing gear when a particular sensor registers there's ground below, or automatically ordering people inside and barricading windows when a storm hits. These can be used by midlevel players to handle changes automatically, and by advanced players to create absurdly complex contraptions.<br />
<br />
By the way, I am a big fan of moving parts - whole sections of facility that can move around. Normally this is implemented as full-scale facility elements being rolled around, and that's not a great solution because it's extraordinarily bulky. Instead, I recommend parts can fold up and unfold, allowing things to take up much less space when not in use.<br />
<br />
An easy example of this: if you need to charge your laser using a big power cable, but also cool your laser with a coolant pipe, each can be folded away into a wall tile. Both can be folded away at the same time if you need to walk past. Then they unfold and fill the space as needed.<br />
<br />
Anyway, those are my thoughts on base building. Use fewer parts for more expressive results by keeping these things in mind.<br />
<br />
Let me know if you have any opinions.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com1tag:blogger.com,1999:blog-11758224.post-52152424836436797262017-10-05T10:30:00.002-07:002017-10-05T10:36:12.948-07:00DifficultyThere's been a week-long explosion about people tweeting about difficulty. People seem to come down in one of a few camps, none of which is even vaguely similar to my own opinions. So let me make a big essay about it.<br />
<br />
Difficulty is a very messy term with a lot of tangled-up components.<br />
<br />
For example, some people say that some games can't let you skip difficult parts or make them easier because those difficult parts are teaching you some aspect of the gameplay you will need. The part you're having a hard time with is hard because you haven't actually learned how to use the double-jump or balance your theme park budget or something.<br />
<br />
My rebuttal to that is: who cares? Who cares if a player doesn't get some aspect of your game?<br />
<br />
The answer is: the problem with "cheating" (or super-easy difficulty modes) is that most players will end up sliding through your game without enough friction. They won't have fun, because there's no traction to engage with. Super Mario is a lot less fun when you can just fly through every level as Shinypants Mario. Subnautica is a lot less engaging if you have all the modules at the start and can just build anything and dive as deep as you like. These games aren't designed to really be played that way, so there's no player engagement if the player tries to engage that way.<br />
<br />
If an RPG is too easy, the battles still consume time but don't have any depth or payoff.<br />
<br />
This is a valid concern. Your game is designed to be played a certain way. Some players might be better or worse at that kind of play, but how can you pull them up to the difficulty level where they'll enjoy your game? Is it possible? Maybe this player will <i>never</i> learn to double-jump or balance a theme park budget. Maybe they literally can't for some reason. What should you do then? Just sneer and say 'git gud'?<br />
<br />
Rather than sneering, some people try to solve this with adaptive difficulty. If the player fails too much, the game becomes easier. If they succeed too much, the game becomes harder. The problem with this approach is that players have different concepts of what 'too much' is, and if the game interrupts their flow at the wrong time, it's considerably worse than simply being too hard or too easy.<br />
<br />
The New Super Mario games are a good example of that. I like having a hard time with these games, which is good, because I suck at them. I tend to die a few times before I come even close to beating a level.<br />
<br />
Just when I'm getting into the groove, the game goes "BLOIP!" and pops up a bright, shiny thing that follows me around begging me to use it to beat the level as Shinypants Mario. It's "optional", in that I can keep trying without it. But it's there, and it's the game telling me that it has decided it was mistaken in asking me to beat that level, it's clear I can't beat that level, and I should just skip it.<br />
<br />
That's incredibly deflating. The game judged me, and it decided I shouldn't be playing the game like everyone else. I should just skip it.<br />
<br />
So I did.<br />
<br />
After the third time it appeared, I put the game away and never played another New Super Mario game. I couldn't keep interested when it kept derailing my groove just when I was getting into it.<br />
<br />
That's a pretty clear example, but I'll constantly adjust difficulty on my own, regardless of what any game thinks. I might decide to take suboptimal characters into battle because I think it'd be fun to win with them, specifically. I might decide to play as a pacifist. I might decide to climb that clearly-unclimbable mountain. I might throw pebbles at an enemy until it falls over instead of shooting it just because it's fun. I might beat Lavos with a mop.<br />
<br />
How will the game interpret this? How will it auto-adjust my difficulty?<br />
<br />
I can tell you: it gets scrambled and completely drops the ball. I haven't played an "auto-adjusting difficulty" game that didn't actively annoy me by adjusting it wrong, and the first mod I install is one to change how that works.<br />
<br />
Phew.<br />
<br />
So what's my opinion, in the end?<br />
<br />
I think most people's concept of "difficulty" makes a big assumption: it assumes that you, the developer, should dictate how players play your game.<br />
<br />
I understand that you, the developer, have built the game with the intention that it should be played in specific ways. And I understand that there are limits to how far that can stretch. Your puzzle game can't be made easier, because the puzzles are the point. Your score attack arcade game can't have a 'tourist' mode, because that makes no sense.<br />
<br />
... Except puzzles are not the point, and tourist modes make sense.<br />
<br />
What if a YouTuber wants to put together game footage? What if someone wants to play it with their toddler? What if an expert just wants to try one particular thing over and over? What if my controller broke and I'm stuck trying to control it with a keyboard? What if I'm testing a mod? What if I'm teaching a friend?<br />
<br />
I think it's fine to let players play however they want.<br />
<br />
Recommend specific difficulties, sure. Your intended play style is probably the best one, in that it's balanced and has good pacing. But if I want to short-circuit your game and play it in a dumb way... why not let me?<br />
<br />
The games I keep coming back to are the ones with the best options menu. Kerbal, Space Engineers, Skyrim (via mods). Sometimes I completely disable core systems. Some days I play them one way, some days another way... and sometimes the game isn't balanced and the pacing is screwed up. That's OK. <br />
<br />
I made it that way on purpose.<br />
<br />
Because now it's <b>my</b> game.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com6tag:blogger.com,1999:blog-11758224.post-57712335788501907822017-07-24T10:10:00.001-07:002017-07-24T10:10:06.443-07:00The Most Fundamental Fundamental of Game DesignOver the past few weeks I've thrown out dozens of prototypes and agonized over some my current projects. The problem? They're not fun.<br />
<br />
There's a lot of talk about what makes for good game design and bad game design, but let's get down to what a game fundamentally is.<br />
<br />
In concrete design terms, what are most games?<br />
<br />
They're a bundle of systems we've all seen before.<br />
<br />
You can boil down any game to a few simple basics that get reused over and over. This reductive analysis comes in waves, each time a slightly new view on the medium, a slightly different reductive take. Games are about learning skills. Games are Skinner boxes. Games are slot machines. Games enforce a magic circle.<br />
<br />
While developing a game, we also tend to fall into this reductive analysis. We see the game before it's polished and we're too familiar with it to feel the impact of the assets. Since we're not playing it in the same way a player does, our view of the pacing is going to be wrong, too.<br />
<br />
Like a movie editor in the guts of a reel, wondering whether to cut from this to that. Cut on this frame or this frame? Now I can't even tell if this shot is any good, I've seen it too many times.<br />
<br />
Every medium is like this. There are fundamentals. Everyone argues over what they are and how to use them. But any way you slice it, while you're neck deep in creating the project, you end up staring those fundamentals in the face and second-guessing yourself.<br />
<br />
Your RPG is boring and bland, just an oatmeal mush of cities and dungeons and level progression. To you. While you're in it.<br />
<br />
And maybe it's bland to everyone else. You can't tell.<br />
<br />
Just as the problem is universal to all forms of art, the solutions and workarounds are also universal. Anything a movie editor does, a game dev can do. Anything a writer does, a game dev can do. From small things like stepping away for a few hours to big things like making four different versions and having random people try all four.<br />
<br />
But the biggest thing to do - in all forms of media - is to be trying to do something.<br />
<br />
Too many people agonize over whether their fundamentals are "on target" without even knowing where they're aiming in the first place!<br />
<br />
When a movie editor agonizes over cut A or cut B, the solution is to know what fits the movie better. What fits the story, the pacing, the characters, this exact moment?<br />
<br />
When a comic artist hesitates over a page, they stop and think. "Maybe I should try to focus on page flow here to pull the reader back in." "These three panels of this person's face need a cutaway to their hands to keep things flowing." "This page should be spikey and fractured because the hero is on the ropes." "Maybe I should draw a few thumbs and ask someone which one feels loneliest."<br />
<br />
This is obvious and well-understood in other forms of media, but in games it is often overlooked.<br />
<br />
Is part of your RPG boring to you?<br />
<br />
Well, what are you trying to accomplish with the boring part?<br />
<br />
It isn't just a matter of rebalancing or decorating. What is your RPG supposed to feel like here? Why? Are you using the wrong approach? The right approach, but too much or too little? What other facets affect this and might be souring it? Level design? Story progression? Character design? If you have design pillars, what went astray?<br />
<br />
By considering what you're aiming for and what the player should be experiencing, you can figure out which approaches have promise. You can get a grip on what you think is "boring" and pull yourself out of a featureless plain of potential options.<br />
<br />
... it's the same in any medium.Craig Perkohttp://www.blogger.com/profile/13173752470581218239noreply@blogger.com0