Yesterday I wrote a cluttered essay about making construction games that have NPCs in them. The basic idea is that construction games generally have bad/nonexistent feedback on player activities, which means they have no real traction. However, if we put NPCs in the game, they can react to the player's actions. They can react to the things the player constructs, react to the actions the player takes outside of construction, and react to how the player's constructions fare as the world weighs down on them.
It's easy to think of this as "creating a game where NPCs live their lives in the player's constructions" - think The Sims. However, that's the opposite of how we should think of it.
Normally, we use smoke and mirrors to make convincing NPCs. Now we will use the NPCs as smoke and mirrors to make a convincing game.
Let's consider some methods.
First, when the player installs something new, it needs to be acknowledged by the NPC population. One way to do this is the Sims' method: NPCs walk over and admire or disdain the new purchase. This is too small and shallow, although it's probably worth implementing. The real response needs to be deeper: NPCs need to adopt the new purchase as part of their lives or work.
This is more flexible and immersive than it sounds, but it requires us to make every component of our construction human-centric rather than intersystem-centric. That is, we can build a power station, but it has to be something a person works with or at, not just a passive device that adds N power to the ship/base.
We have some wonderful opportunities here.
A) The NPCs can openly discuss who should have control over the new system (or how they should share it). Someone says their job needs the new computer, or decides they maintain the engines, or that this is their new quarters.
B) The player can manually assign those duties instead of allowing them to be automatic, changing the dynamics of the NPC's lifestyles manually.
At a low level, this means that the most critical thing you'll need is workers. As you build stuff in your base, you'll need to have enough workers to use/maintain it. There's a natural tendency to make that a serious constraint, so that you'll need hundreds of workers to manage any decently-sized base. However, the human brain can't really keep track of that many people at once, and therefore their responses will start to feel random and arbitrary instead of purposeful. We need to keep the number of workers manageable. That's more complicated than it sounds, but at this stage it simply means that NPCs should be allowed to take on a truly staggering number of duties without suffering.
Instead of requiring more NPCs, the NPCs can take on more duties. This will shape their lifestyle and prominence in the facility: someone responsible for more things is busier, but is also respected more and has a lot more social clout. Not all duties are considered equal, though, and there's a lot of complexity we can add in as we please. For example, some jobs give you social prominence, others give you happiness, others give you cash, others increase your stats...
Working out the NPC response to a newly installed segment is an opportunity for us to make a fun and details bloom out of our game, but it's only the first step. We also need to consider non-constructive gameplay such as damage/degredation, missions, daily life, etc.
How we make our NPCs react to these other systems will further shape our game, but first we need to figure out what kind of systems we're talking about.
I rather like the idea of having multiple concurrent missions at all times. For example, your science team could be searching for allergens in the local flora, your political time might be trying to learn the Xargiblot language, your political team might ALSO be struggling to keep a neutral peace going until they finish learning the language, your exploration team might be collecting rare samples from the artic poles, your engineering team might be optimizing the atmospheric thrusters to work best in this atmosphere, etc.
All of these missions take different amounts of time to complete, and have different drivers that push them forward. The idea is that the player can focus on any given mission for a short amount of time, optimizing things and polishing and manually setting things up, but the missions also proceed automatically in the background. This allows the player to choose which missions they want to focus on, and switch missions if they ever get bored.
This also means our NPCs are split into teams. This is good, because it's an excellent way to "chunk" our NPCs. Characters with no structured relationships are hard to remember, but if we split them into teams, the player can partition them up and remember them relative to the team rather than to N other NPCs.
Teams can have high or low status to other teams just like NPCs can have high or low status compared to other NPCs. Most of an NPC's relationships will be within the team - interteam relationships are hard to remember, so they should only happen when specified by the player.
Chunking teams is a big, easy thing to do in order to make our bases or starships more interesting. For example, your instinct might be to have a big dorm room for all your workers, but team cohesion suffers. It's better to have different dorm rooms for each team, especially since you can then decorate the room or have nearby rooms that enhance that team's performance but wouldn't benefit teams with other priorities.
Combining and splitting teams is also a ripe fruit. For example, the political team needs to talk to the natives of this planet. However, you don't know their language. So you split the team into two: a xenolinguistics team to research the language, and a social team to try and mime their way towards peaceful coexistence. One team, one mission. Once the language is learned, you can merge the teams back together.
Not everything is a mission. You don't split the engineering team into an engine maintenance team, a life support maintenance team, etc. Those are simply duties that happen in the background. The mission would be optimizing engines or something similar. Something that has an end state.
Because the missions move at different rates, each team is under a different amount of stress and a different phase of their work. As missions get near completion the stress is at its peak, so the players will naturally tend to focus on missions near the end of their run as they have to step in to massage stress problems.
We can also have personal missions, resource allocation challenges, etc.
All of this leverages the player's ability to choose missions. While some games are completely open, allowing the player to flat-out make up missions, my approach does require explicit missions. But since there are so many missions and so much flexibility about assigning them, it should feel pretty open. There's nothing that requires you to learn the alien language, or even to negotiate with them. You can create an overall mission profile based on your own personal approach.
The combination of NPCs working on the mission and the devices supporting them gives you strong feedback about your design and whether it works well to support the NPCs. Should be pretty clear and rewarding.
Anyway, that's my concrete thoughts on using NPCs to provide feedback. What are yours?
Friday, March 25, 2016
Thursday, March 24, 2016
Multiplayer and Fake Multiplayer Nonviolent Games
As you may know, I do a lot of prototypes of nonviolent games, especially construction games. However, they don't tend to make it past the prototyping stage, because they never pass my "is it fun" test.
The biggest problem with nonviolent games is providing juicy feedback. Violence is very juicy: you can immediately tell how things are going and what effect you're having on the game world. It's not inherently more or less complex than any other kind of gameplay, but it is very clear and easy to see. Puzzle games can also be made juicy: pieces appear, merge, etc. You can tell the effect you're having and get a strong feedback with each action.
But construction games are not inherently juicy. They almost can't be, because there's no clear goal. Violence has a clear set of objectives - defeat the other guy. Racing? Clear objectives. You can immediately tell if you're doing well or poorly based on whether your car is zooming along or stuck in a ditch. Puzzle games? Clear objectives, although the feedback may or may not be clear.
Construction games are open-ended. If I want to build an artic base, what sort of objective do I have? How do my objectives break into goalposts? How do I get feedback?
It's possible to engineer all of this into a juicy system. City building games do this: while they are open-ended, you are led by the nose to fulfill the statistical requirements of the system. First you need residential and roads. Then you need to add in commercial and industrial. More residental. Now you need schools. Police stations. Fire stations. Sewage. Happiness. Pollution control. As your city grows, the game gives you more and more statistical requirements to fill, so your objectives are always pretty clear.
As a result, those city building games don't really pack much punch. If you look at a hundred cities and compare that to a hundred cities doodled on paper with no constraints, the paper maps will have more breadth, be more interesting, and represent the author's personal interests and choices more clearly. By introducing clear objectives, city building games make it more difficult for a player to build an interesting, unique city.
That isn't a universal rule, though. Sometimes, objectives and constraints can lead to more creativity rather than less. A good example of this would be Minecraft's ugly voxel construction system. It's clunky and raw, archaic-looking, but working within those constraints has led players to build whole cities, reproductions of real-life areas, massive computers, and so on. Each of these is a work of art within the context of the game, and many of them are easily recognizable as works of art in general. When you look at a redstone contraption the size of a football field and it plays a song, you can admire the work and cleverness that went into it even if you've never played the game.
One of the keys to this is simple: the goals are self-chosen and self-judged. Unlike Sim City's popups telling you to add more residential, more fire safety, more schools, you are responsible for your own goals.
The problem with this is that self-chosen and self-judged goals are not reinforced by the game.
In a shooter, every time you fire a gun you get a game-provided satisfying feedback. The crack of the muzzle, the flash, the ammo counter draining, the explosion in the distance, even trying to manage the kickback and drift. The game tells you very clearly that this gun feels like this and that gun feels like that. It tells you whether you hit an enemy or wasted your ammo on a wall. It tells you a lot in a constant stream, because the game knows precisely what each weapon is and how it works and how it should feel to use.
This isn't the case with open-ended goals. Can Kerbal Space Program know what your goal is? Sure, there are implicit goals like "land on the Mun because it's there", but can KSP really tell if what you're doing is going well or poorly or entertainingly? Should it celebrate you landing on the Mun, even though you crashed, or landed in the wrong spot, or the main system didn't work out, or the ship is not going to function as intended and you're stranded on the Mun forever?
More importantly, the juice comes from celebrating progress towards, away from, or tangential to that goal. KSP gives a pretty juicy response when you jettison rocket stages, but it has no way of knowing if that was good, bad, funny, accidental, or intentional. It gives a good response when things explode but, again, no way of knowing the intention behind it.
On the other hand, there is a very easy source of juice. There is something that responds very accurately and powerfully to your progress, missteps, and intents:
Other players.
Other players provide running commentary on what they see, and can get excited about the smallest things. If you try a moon landing as a group, you'll invariably have a good time even if you crash and burn. If you invent an interesting new toy that the game doesn't know what to do with, other players will have a fun time interacting with it until it explodes. Right now, multiplayer games are focused on combat or PvP sporting games, but in truth cooperative or mixed-cooperative multiplayer is at least as powerful, if you can find the right kind of people to play with.
Here's the fun thing: there don't have to be any other players.
Think about The Sims.
99% of the people that play The Sims never played it multiplayer, and the last 1% played it by handing off control and snarking. But The Sims was very compelling because of its multiplayer elements.
One obvious multiplayer element is the sharing of content. All versions of The Sims allow you to share characters, clothes, houses, albums, videos, etc. This really helped to create a community and it's worth considering.
But the secret multiplayer element is also worth considering. Have you figured it out?
The Sims themselves.
Or, more accurately, the stories the player makes up from their point of view.
When you put friends, celebrities, or famous characters into a Sims house, you immediately and automatically start imagining how they feel about the situations they find themselves in. It's great fun to mock your friends for their behavior in your video game, or to imagine your own little fanfic about Snape shacking up with Dumbledore.
Because you have a clear feel for how these characters should and would act, you get a clear feeling of how they would feel about any given situation in the game world. It's very juicy.
It's powered by the frission between the expectations you bring (self-directed goals) and the constraints of the game (processes and interactions). Bringing Wolverine and Captain Kirk into the game world brings in your expectations of what they would do and how they would act. The game's interference as it pilots the two around creates an opportunity for you to take inspiration from the new actions, laugh at how off-base they are, or explain why they would do that given their personalities. In only a short while, you suddenly have "your" Wolverine and "your" Captain Kirk, and now you're inventing objectives and goalposts for them.
The game has no idea about any of this, of course. The game doesn't know who Captain Kirk or Wolverine are. It doesn't know your friends, it doesn't know Dumbledore or Snape. At best, it has a vague impression of things like age, profession, and fundamental personality traits.
The player does all the heavy lifting on their own. Along with the player's self-directed goals and constraints, we now have self-directed multiplayer. Multiplayer that happens in a single player's head.
The Sims had a number of other features to it, of course. They put in a variety of treadmills to give you something to do while the characters got traction on your brain. All told, it was an extremely powerful and successful series.
I think it might be possible to use this same idea in other kinds of construction games.
By convincing the player to feel what the characters should feel, it should be possible to allow for juicy feedback on construction. This requires tying construction into the lives of the characters, which can be tough. If you're building a space ship, you need to be able to feel what characters would think about a new engine or a new life support module or whatever.
This sounds weird, but it's no more weird than buying your sims a bigger TV or building a pool for them.
Fundamentally, sims are interesting mostly because of the lives they lead. Big chunks of that are how they interact with other sims, but equally big chunks are how they interact with the environment. Is Wolverine forced to work at a day care? Does Dumbledore burn his breakfast and leave dishes everywhere? Is your buddy slacking off on the couch AGAIN?
Doing this intentionally for a different kind of game shouldn't be impossible. The level of character customization required is a hurdle, but not insurmountable. It's worth trying.
Just remember the treadmills and asynch multiplayer. Those are still critical elements of the puzzle.
Anyway, that's my first essay in a few months. Let me know if you have any opinions on the matter.
The biggest problem with nonviolent games is providing juicy feedback. Violence is very juicy: you can immediately tell how things are going and what effect you're having on the game world. It's not inherently more or less complex than any other kind of gameplay, but it is very clear and easy to see. Puzzle games can also be made juicy: pieces appear, merge, etc. You can tell the effect you're having and get a strong feedback with each action.
But construction games are not inherently juicy. They almost can't be, because there's no clear goal. Violence has a clear set of objectives - defeat the other guy. Racing? Clear objectives. You can immediately tell if you're doing well or poorly based on whether your car is zooming along or stuck in a ditch. Puzzle games? Clear objectives, although the feedback may or may not be clear.
Construction games are open-ended. If I want to build an artic base, what sort of objective do I have? How do my objectives break into goalposts? How do I get feedback?
It's possible to engineer all of this into a juicy system. City building games do this: while they are open-ended, you are led by the nose to fulfill the statistical requirements of the system. First you need residential and roads. Then you need to add in commercial and industrial. More residental. Now you need schools. Police stations. Fire stations. Sewage. Happiness. Pollution control. As your city grows, the game gives you more and more statistical requirements to fill, so your objectives are always pretty clear.
As a result, those city building games don't really pack much punch. If you look at a hundred cities and compare that to a hundred cities doodled on paper with no constraints, the paper maps will have more breadth, be more interesting, and represent the author's personal interests and choices more clearly. By introducing clear objectives, city building games make it more difficult for a player to build an interesting, unique city.
That isn't a universal rule, though. Sometimes, objectives and constraints can lead to more creativity rather than less. A good example of this would be Minecraft's ugly voxel construction system. It's clunky and raw, archaic-looking, but working within those constraints has led players to build whole cities, reproductions of real-life areas, massive computers, and so on. Each of these is a work of art within the context of the game, and many of them are easily recognizable as works of art in general. When you look at a redstone contraption the size of a football field and it plays a song, you can admire the work and cleverness that went into it even if you've never played the game.
One of the keys to this is simple: the goals are self-chosen and self-judged. Unlike Sim City's popups telling you to add more residential, more fire safety, more schools, you are responsible for your own goals.
The problem with this is that self-chosen and self-judged goals are not reinforced by the game.
In a shooter, every time you fire a gun you get a game-provided satisfying feedback. The crack of the muzzle, the flash, the ammo counter draining, the explosion in the distance, even trying to manage the kickback and drift. The game tells you very clearly that this gun feels like this and that gun feels like that. It tells you whether you hit an enemy or wasted your ammo on a wall. It tells you a lot in a constant stream, because the game knows precisely what each weapon is and how it works and how it should feel to use.
This isn't the case with open-ended goals. Can Kerbal Space Program know what your goal is? Sure, there are implicit goals like "land on the Mun because it's there", but can KSP really tell if what you're doing is going well or poorly or entertainingly? Should it celebrate you landing on the Mun, even though you crashed, or landed in the wrong spot, or the main system didn't work out, or the ship is not going to function as intended and you're stranded on the Mun forever?
More importantly, the juice comes from celebrating progress towards, away from, or tangential to that goal. KSP gives a pretty juicy response when you jettison rocket stages, but it has no way of knowing if that was good, bad, funny, accidental, or intentional. It gives a good response when things explode but, again, no way of knowing the intention behind it.
On the other hand, there is a very easy source of juice. There is something that responds very accurately and powerfully to your progress, missteps, and intents:
Other players.
Other players provide running commentary on what they see, and can get excited about the smallest things. If you try a moon landing as a group, you'll invariably have a good time even if you crash and burn. If you invent an interesting new toy that the game doesn't know what to do with, other players will have a fun time interacting with it until it explodes. Right now, multiplayer games are focused on combat or PvP sporting games, but in truth cooperative or mixed-cooperative multiplayer is at least as powerful, if you can find the right kind of people to play with.
Here's the fun thing: there don't have to be any other players.
Think about The Sims.
99% of the people that play The Sims never played it multiplayer, and the last 1% played it by handing off control and snarking. But The Sims was very compelling because of its multiplayer elements.
One obvious multiplayer element is the sharing of content. All versions of The Sims allow you to share characters, clothes, houses, albums, videos, etc. This really helped to create a community and it's worth considering.
But the secret multiplayer element is also worth considering. Have you figured it out?
The Sims themselves.
Or, more accurately, the stories the player makes up from their point of view.
When you put friends, celebrities, or famous characters into a Sims house, you immediately and automatically start imagining how they feel about the situations they find themselves in. It's great fun to mock your friends for their behavior in your video game, or to imagine your own little fanfic about Snape shacking up with Dumbledore.
Because you have a clear feel for how these characters should and would act, you get a clear feeling of how they would feel about any given situation in the game world. It's very juicy.
It's powered by the frission between the expectations you bring (self-directed goals) and the constraints of the game (processes and interactions). Bringing Wolverine and Captain Kirk into the game world brings in your expectations of what they would do and how they would act. The game's interference as it pilots the two around creates an opportunity for you to take inspiration from the new actions, laugh at how off-base they are, or explain why they would do that given their personalities. In only a short while, you suddenly have "your" Wolverine and "your" Captain Kirk, and now you're inventing objectives and goalposts for them.
The game has no idea about any of this, of course. The game doesn't know who Captain Kirk or Wolverine are. It doesn't know your friends, it doesn't know Dumbledore or Snape. At best, it has a vague impression of things like age, profession, and fundamental personality traits.
The player does all the heavy lifting on their own. Along with the player's self-directed goals and constraints, we now have self-directed multiplayer. Multiplayer that happens in a single player's head.
The Sims had a number of other features to it, of course. They put in a variety of treadmills to give you something to do while the characters got traction on your brain. All told, it was an extremely powerful and successful series.
I think it might be possible to use this same idea in other kinds of construction games.
By convincing the player to feel what the characters should feel, it should be possible to allow for juicy feedback on construction. This requires tying construction into the lives of the characters, which can be tough. If you're building a space ship, you need to be able to feel what characters would think about a new engine or a new life support module or whatever.
This sounds weird, but it's no more weird than buying your sims a bigger TV or building a pool for them.
Fundamentally, sims are interesting mostly because of the lives they lead. Big chunks of that are how they interact with other sims, but equally big chunks are how they interact with the environment. Is Wolverine forced to work at a day care? Does Dumbledore burn his breakfast and leave dishes everywhere? Is your buddy slacking off on the couch AGAIN?
Doing this intentionally for a different kind of game shouldn't be impossible. The level of character customization required is a hurdle, but not insurmountable. It's worth trying.
Just remember the treadmills and asynch multiplayer. Those are still critical elements of the puzzle.
Anyway, that's my first essay in a few months. Let me know if you have any opinions on the matter.
Thursday, January 28, 2016
Programmable NPCs
I love programming games. In theory.
In practice, programming games are too esoteric, too separated from anything that feels meaty and fun. In the real world, the "programming" games I love run without any programming at all, and I wedge programming in for extra fun. Kerbal, Space Engineers, and so on: all work fine with no complex staging or programming.
I've been analyzing the concept. Thinking a lot. I think what we need is a way to allow the player to program easily and freely, but more than that, to smoothly slide in and out of non-programming, full-programming, and simple scripting elements.
What do I mean?
Imagine a game like Minecraft or Medieval Engineers, except that you have an unlimited number of NPCs to help you out. The idea is that they can help you build, operate, and maintain your world. You can create villages and so on and so forth. But the implementation is more open-ended: these aren't people with set jobs. They're state machines.
There are a few ways to let players program NPCs. Since AI is complex and depends on wrangling thousands of inputs, most of those methods revolve around picking big chunks of functionality. This NPC is a guard. This NPC is a farmer. This NPC lives here. This NPC lives there.
Let's turn that around a bit. The big difficulty is the huge number of inputs. NPCs need to analyze the terrain, their resources, threats and opportunities, their tiered goals, pre-established schedules, the weather, their equipment, alert/damage states... programming for all these things is why AI is normally supplied by the dev rather than given to the player to fuss with.
But what if we stop thinking of an NPC as an independent agent? What if the NPC is considered as part of the player, augmenting the player's capabilities?
Overlord was a good example of this, allowing you to point and send off your minions in a very easy, fluid way. However, those NPCs are a bit too simplistic and the gameplay was not constructive. Is it possible to do something like this, but with radically more complex, programmable NPCs?
One challenge is how the player interacts with the world. For example, in Minecraft you can build a house, it's very constructive. But building the house is very low-constraint: you rapidly plonk down voxels in any configuration you want, and you can even have a physically impossible floating house without difficulty. Having assistants wouldn't help in this situation, because there's not really any pattern for the NPCs to work on. They can't tell what you intend to build based on what you have built so far, so they can't help.
We could exchange the player's actions and require NPCs to execute them. For example, the player just puts down virtual blueprint voxels and the NPCs have to do the work. But this isn't any better at making complex, programmable NPCs, it just makes the game slower and the player unable to directly affect the world, both of which are bad.
Instead, what if we designed our creative systems specifically to have patterns? Then, when the player starts to create, the NPCs would be able to predict what the player is doing and build as well.
For example, if you build a road, you probably want to build another segment of road one road-segment along the path.
The road example is an easy, clear example. Let's say you dress an NPC up in road-worker costume and link them to you. Now they follow you and read your activities as their input. When you build a section of road, they read your vector and the position of the road, and move one unit further in that direction and build another segment.
Now you have augmented your power. When you build a road, two road segments get built.
You can extend this. What if you link another 50 road workers to yourself? Well... they still only try to build one block along, so you still only have two blocks of road per one block you build.
One way to fix this is to have them move N blocks ahead instead of 1, and then specify each individually. However, a more interesting option is to simply daisy-chain. The NPC's activities are also readable as inputs, so you make the second worker link to the first worker instead of you. And the third worker links to the second, and so on. Now, when you build a road segment, each worker moves along in a chain of single steps, and you can break the chain by simply unlinking the Nth worker.
This works great, especially since there's an obvious physical representation of who is linked to who: a line. The workers form a line. All linked to you, they cluster in your wake as a chaotic mishmash. But daisy-chained, they stretch behind you like a conga line.
Of course, this is really wasteful. In reality you only need one worker, as long as you're patient.
See, like any Turing machine, our workers have an input stack - a "tape" to read. When we linked them to us, we simply put ourselves in the first spot on that tape. We can add themselves as additional entries on the tape, and tweak the road-builder state to move to the next input on the tape.
This means that we build a road segment. This triggers them to build a road segment and also move their input tape, making themselves their own input. Since they just built a road, this triggers them to build a road and move their input tape... it's not an infinite loop because the tape eventually wraps back around to using us as an input.
This works, but the worker will have to complete each segment before moving on to the next, which might be too slow for your taste. It's already a relatively interesting space, with tradeoffs built right in. We're touching on the concept of parallel processing, Turing machines, IO...
Roads are an easy example, easy to use as a demonstration. But they are fundamentally pretty straightforward. While you might like a wider road, or a road that curves, it's pretty "flat" and there's no real constraints on it.
So let's talk about walls.
Rather than the physics-free voxel walls of Minecraft, what if our walls have physical presence, and roofing is actually a challenge? Sort of like Medieval Engineers?
If we we want to build a three-high wall, it's not just plonk-plonk-plonk. We need to have the resources lying around nearby. We need to build a scaffold so we can reach the upper wall areas. We need to lift the resources up the scaffold. The player can do these steps on their own, manually, but it makes sense to use NPCs to help.
For example, you build a wall, and then NPCs are set up to build a scaffold, lift resources up the scaffold, build a wall, build another scaffold, lift resources... you can do this with daisy-chaining, input cycling, or a combination of the two.
To use only one worker, you would equip the worker with gear/clothes representing scaffold-building, wall-building, and resource-toting. You would make yourself the first notch in his input tape, then himself. The order of the states is determined by the order you equip the gear, so the last one on would be the scaffold-building equipment - say, a hat. He sees you build a wall, builds a scaffold - then moves the input tape (to target himself) and switches to the next state - hauling. He saw himself build a scaffold, so he now hauls materials and switches to the next state - wall-building. He saw himself haul materials, so he builds a wall, then loops back to the first state - scaffold-building. He saw himself build a wall, so he builds a scaffold, etc, etc.
This kind of dependency simply makes the world more annoying rather than more complex, but it's a good example of the concept. In reality, the constraints I would want to introduce would be more than mindless busywork.
For example, if you want to build a 20m-high wall, the wall material will tip over under its own weight. So you have to shore it up. You could simply build it thicker, but a clever designer will instead build it banded - some areas have large windows to lighten the wall, and others have flying buttresses and thicker columns. How about supporting the tall wall with scaffolding, knowing it will fall over when the scaffolding is removed... and then putting in crossbeams before removing the scaffolding?
Multiphase and open-pattern construction are powerful features. Not only do they make programming the NPCs more interesting, they also make the world more interesting to inhabit. A skilled player will come up with interesting ways to build taller, wider, deeper, more interesting structures. Another skilled player will come up with a way to build hundreds of miles of structure, although perhaps not as impressive per meter. Yet another player will build something that isn't technically challenging, but feels real and inhabited because the NPCs are programmed to live life convincingly instead of build walls convincingly.
I've left out some details. For example, location flags/vectors are pretty important, and I didn't mention them at all. I didn't talk about how to build or edit gear to perfectly suit your needs. I didn't talk about the idea of maybe building ships, or setting it in space. I didn't talk about harvesting and transporting materials.
But I think I talked about enough. What do you think?
I think the concreteness of allowing the player to physically build things makes the game easy to get into. Combined with easy basic state editing, the player can ease into the idea of telling a wall builder or stack of road workers to follow along and help them. The more complex powers of NPCs with multiple states, state tweaking, recursive NPCs - those can be left for the people who actually want to do them.
Moreover, this makes for a truly excellent semi-shared world. Import a wall crew from your friend Alice, she's programmed them to build that 80m-high megawall wherever you plant a blue flag. Import a city from your buddy Barry. Import a ship - no, a whole shipping lane - from your half-cousin Chip. It can be done automatically, manually, or half-automatically (for example, an in-world "for hire" bulletin board).
That's what I envision.
In practice, programming games are too esoteric, too separated from anything that feels meaty and fun. In the real world, the "programming" games I love run without any programming at all, and I wedge programming in for extra fun. Kerbal, Space Engineers, and so on: all work fine with no complex staging or programming.
I've been analyzing the concept. Thinking a lot. I think what we need is a way to allow the player to program easily and freely, but more than that, to smoothly slide in and out of non-programming, full-programming, and simple scripting elements.
What do I mean?
Imagine a game like Minecraft or Medieval Engineers, except that you have an unlimited number of NPCs to help you out. The idea is that they can help you build, operate, and maintain your world. You can create villages and so on and so forth. But the implementation is more open-ended: these aren't people with set jobs. They're state machines.
There are a few ways to let players program NPCs. Since AI is complex and depends on wrangling thousands of inputs, most of those methods revolve around picking big chunks of functionality. This NPC is a guard. This NPC is a farmer. This NPC lives here. This NPC lives there.
Let's turn that around a bit. The big difficulty is the huge number of inputs. NPCs need to analyze the terrain, their resources, threats and opportunities, their tiered goals, pre-established schedules, the weather, their equipment, alert/damage states... programming for all these things is why AI is normally supplied by the dev rather than given to the player to fuss with.
But what if we stop thinking of an NPC as an independent agent? What if the NPC is considered as part of the player, augmenting the player's capabilities?
Overlord was a good example of this, allowing you to point and send off your minions in a very easy, fluid way. However, those NPCs are a bit too simplistic and the gameplay was not constructive. Is it possible to do something like this, but with radically more complex, programmable NPCs?
One challenge is how the player interacts with the world. For example, in Minecraft you can build a house, it's very constructive. But building the house is very low-constraint: you rapidly plonk down voxels in any configuration you want, and you can even have a physically impossible floating house without difficulty. Having assistants wouldn't help in this situation, because there's not really any pattern for the NPCs to work on. They can't tell what you intend to build based on what you have built so far, so they can't help.
We could exchange the player's actions and require NPCs to execute them. For example, the player just puts down virtual blueprint voxels and the NPCs have to do the work. But this isn't any better at making complex, programmable NPCs, it just makes the game slower and the player unable to directly affect the world, both of which are bad.
Instead, what if we designed our creative systems specifically to have patterns? Then, when the player starts to create, the NPCs would be able to predict what the player is doing and build as well.
For example, if you build a road, you probably want to build another segment of road one road-segment along the path.
The road example is an easy, clear example. Let's say you dress an NPC up in road-worker costume and link them to you. Now they follow you and read your activities as their input. When you build a section of road, they read your vector and the position of the road, and move one unit further in that direction and build another segment.
Now you have augmented your power. When you build a road, two road segments get built.
You can extend this. What if you link another 50 road workers to yourself? Well... they still only try to build one block along, so you still only have two blocks of road per one block you build.
One way to fix this is to have them move N blocks ahead instead of 1, and then specify each individually. However, a more interesting option is to simply daisy-chain. The NPC's activities are also readable as inputs, so you make the second worker link to the first worker instead of you. And the third worker links to the second, and so on. Now, when you build a road segment, each worker moves along in a chain of single steps, and you can break the chain by simply unlinking the Nth worker.
This works great, especially since there's an obvious physical representation of who is linked to who: a line. The workers form a line. All linked to you, they cluster in your wake as a chaotic mishmash. But daisy-chained, they stretch behind you like a conga line.
Of course, this is really wasteful. In reality you only need one worker, as long as you're patient.
See, like any Turing machine, our workers have an input stack - a "tape" to read. When we linked them to us, we simply put ourselves in the first spot on that tape. We can add themselves as additional entries on the tape, and tweak the road-builder state to move to the next input on the tape.
This means that we build a road segment. This triggers them to build a road segment and also move their input tape, making themselves their own input. Since they just built a road, this triggers them to build a road and move their input tape... it's not an infinite loop because the tape eventually wraps back around to using us as an input.
This works, but the worker will have to complete each segment before moving on to the next, which might be too slow for your taste. It's already a relatively interesting space, with tradeoffs built right in. We're touching on the concept of parallel processing, Turing machines, IO...
Roads are an easy example, easy to use as a demonstration. But they are fundamentally pretty straightforward. While you might like a wider road, or a road that curves, it's pretty "flat" and there's no real constraints on it.
So let's talk about walls.
Rather than the physics-free voxel walls of Minecraft, what if our walls have physical presence, and roofing is actually a challenge? Sort of like Medieval Engineers?
If we we want to build a three-high wall, it's not just plonk-plonk-plonk. We need to have the resources lying around nearby. We need to build a scaffold so we can reach the upper wall areas. We need to lift the resources up the scaffold. The player can do these steps on their own, manually, but it makes sense to use NPCs to help.
For example, you build a wall, and then NPCs are set up to build a scaffold, lift resources up the scaffold, build a wall, build another scaffold, lift resources... you can do this with daisy-chaining, input cycling, or a combination of the two.
To use only one worker, you would equip the worker with gear/clothes representing scaffold-building, wall-building, and resource-toting. You would make yourself the first notch in his input tape, then himself. The order of the states is determined by the order you equip the gear, so the last one on would be the scaffold-building equipment - say, a hat. He sees you build a wall, builds a scaffold - then moves the input tape (to target himself) and switches to the next state - hauling. He saw himself build a scaffold, so he now hauls materials and switches to the next state - wall-building. He saw himself haul materials, so he builds a wall, then loops back to the first state - scaffold-building. He saw himself build a wall, so he builds a scaffold, etc, etc.
This kind of dependency simply makes the world more annoying rather than more complex, but it's a good example of the concept. In reality, the constraints I would want to introduce would be more than mindless busywork.
For example, if you want to build a 20m-high wall, the wall material will tip over under its own weight. So you have to shore it up. You could simply build it thicker, but a clever designer will instead build it banded - some areas have large windows to lighten the wall, and others have flying buttresses and thicker columns. How about supporting the tall wall with scaffolding, knowing it will fall over when the scaffolding is removed... and then putting in crossbeams before removing the scaffolding?
Multiphase and open-pattern construction are powerful features. Not only do they make programming the NPCs more interesting, they also make the world more interesting to inhabit. A skilled player will come up with interesting ways to build taller, wider, deeper, more interesting structures. Another skilled player will come up with a way to build hundreds of miles of structure, although perhaps not as impressive per meter. Yet another player will build something that isn't technically challenging, but feels real and inhabited because the NPCs are programmed to live life convincingly instead of build walls convincingly.
I've left out some details. For example, location flags/vectors are pretty important, and I didn't mention them at all. I didn't talk about how to build or edit gear to perfectly suit your needs. I didn't talk about the idea of maybe building ships, or setting it in space. I didn't talk about harvesting and transporting materials.
But I think I talked about enough. What do you think?
I think the concreteness of allowing the player to physically build things makes the game easy to get into. Combined with easy basic state editing, the player can ease into the idea of telling a wall builder or stack of road workers to follow along and help them. The more complex powers of NPCs with multiple states, state tweaking, recursive NPCs - those can be left for the people who actually want to do them.
Moreover, this makes for a truly excellent semi-shared world. Import a wall crew from your friend Alice, she's programmed them to build that 80m-high megawall wherever you plant a blue flag. Import a city from your buddy Barry. Import a ship - no, a whole shipping lane - from your half-cousin Chip. It can be done automatically, manually, or half-automatically (for example, an in-world "for hire" bulletin board).
That's what I envision.
Monday, January 25, 2016
Construction Genre
So, I just backed another "survival construction" game on Kickstarter. "Survive a crash landing on an alien planet and build-"
Beautiful game. BAD GENRE.
Since Minecraft came out, the "survival construction" genre has been booming. Unfortunately, it's a terrible genre, since it's at war with itself. Minecraft's success is not a sign that it is well-designed, it's just a sign that it had great timing and positioning.
Here's the heart of the problem: "survival" is a specific and shallow objective. Games which are about surviving require the game devs to constantly introduce new threats to you. Most games are about surviving, and the game devs spend a huge amount of effort on introducing those threats. That's the basic idea of "levels", after all.
Open-ended construction is fundamentally a player-driven kind of play. Trying to offer well-paced survival challenges to a player that is doing things at their own pace is very difficult, especially since so much of the player's resources will revolve around the specific things they've built and the specific way they've built them.
For example, in Minecraft, a player might build a wonderful base that is immune to creepers, but when you introduce those block-grabbing Endermen, it's a crapshoot. Some players, especially those that know what's coming, will have bases that don't get affected much at all. But other players, while their base is 100% proof against spiders and creepers, will collapse if even a few blocks are removed - torches go out, gaps for spiders and creepers are introduced...
This is nearly impossible to calibrate. Games where survival is key keep the calibration easy by not allowing the player to have different resources than the devs expect. You have access to X, Y, and Z guns. You have health, your speed is exactly this fast, you can see exactly this far. Because the devs know what you've got, they can present you with challenges. When the players build everything as they like, the devs have no idea what you've got!
Obviously, you can try to limit the player. But that's the opposite of what I would recommend. I like giving the player more freedom.
Letting the player construct whatever they want is really the heart of the construction genre. I don't mean constraint-free, I just mean letting the player create in the direction they want. Every player will approach the situation differently, and that's great.
But how do you create a compelling framework for this "construction" genre?
If you ask a normal dev, you'd hear two basic ideas. 1) Tiered resources: drive the player to find more useful resources in more dangerous places. 2) Phased challenges: introduce enemies, weather, and events on a schedule such that the player has to react to them.
These are good starts, but they're inherently "survivally". Let's look at a different way of thinking about it: optional constraints and challenges.
Kerbal is a good example of this. Putting aside the weird career mode they bunged in recently, there's no in-universe reason to go to any particular planet. But the fact that the planets exist is enough to make you want to go. Moreover, you can plan any kind of mission to the planet that you want, with any number of stages.
You don't simply decide to "go to Juul". You decide what kind of ship will go, manned or unmanned, what science stuff to include, whether it's a round trip or one way, what kind of landings you plan to try, whether to set up a permanent station in the area, whether to use a Kerbal-orbiting station to construct the ship and refuel before setting out, whether you want to take it slow or rush to Juul, whether you want to slingshot off the Mun or off of another planet on the way to Juul... and if you start including mods, the number of options goes up dramatically. How about an airship permanently stationed in Juul's atmosphere?
This freedom allows people to construct as they please. While it may not appeal to all players, I don't think the construction genre needs to appeal to everyone any more than the first person shooter genre does.
The way Kerbal is constructed is very clever, but there are a lot of things to learn from other games. For example, Space Engineers offers an options menu where every constraint is toggleable and tweakable. This includes things like inventory size, sure, but also things like whether there are days and how long they are. This complexity allows players to develop for radically different environments without actually having radically different environments in the game world. It also allows players to change those options during play, allowing them to develop in one set of constraints, then switch over to test or "play out" in another set of constraints, something made easier by blueprints which can be pasted into or built in other worlds.
This is a powerful concept: you can create a ship in "creative mode" with no enemies or materials requirements, then switch over to a hostile, limited world to test your ship. You can then copy it and go into a friend's server and paste it in and have a battle royale or a work together as a team...
This isn't a completed implementation. It's not very fluid, switching modes or transferring constructed content is a huge pain, and the multiplayer functionality is so bad it's actually hilarious. But it's easy to see the beginnings of a genre there.
And it's not a "survival construction" genre where you crash on a planet and have to build your own base to survive. That's just one vaguely-implemented scenario. The power of the game comes from the unfettered construction the player is allowed. Players will accept challenges and constraints just for the fun of it, and they'll come up with objectives and complex multi-phase missions that you never would have thought of and certainly couldn't organize.
So, that's my thought. If we're going to do construction games, we should have a flexible way to accept a variety of constraints and challenges, and allow players to pick and choose what they want to approach in what ways. A big part of this is making it easy to switch constraints and challenges midstream, since many players will want to build and test and iterate instead of just grinding it out in a survival challenge.
You don't need to make the game about survival. It will naturally become about survival if and when the players want it to. It might also be about building cathedrals, or putting together a fleet for a dozen players to work together.
There's also no limit to the kinds of challenges and constraints you can offer. It's popular to just use the basic construction ideas - some facility-wide resources, some physical constraints, some topological challenges, and realtime combat.
But you can define your game with a lot more creativity if you offer a wider range right up front.
For example, what about if you could "weather" your facilities for N years, turning them into ruins or seeing them adapted by NPCs? What if you have missions other than fighting, such as transport, medical, research - if you make them as complex to manage in real-time as combat is, you can have compelling noncombat challenges. How about simulating the people inside the facility?
Any one of these additional "modes" would make your game unique on the marketplace today, but in ten years, I expect they'll all be considered standards in the genre.
That's what I think, anyway.
Beautiful game. BAD GENRE.
Since Minecraft came out, the "survival construction" genre has been booming. Unfortunately, it's a terrible genre, since it's at war with itself. Minecraft's success is not a sign that it is well-designed, it's just a sign that it had great timing and positioning.
Here's the heart of the problem: "survival" is a specific and shallow objective. Games which are about surviving require the game devs to constantly introduce new threats to you. Most games are about surviving, and the game devs spend a huge amount of effort on introducing those threats. That's the basic idea of "levels", after all.
Open-ended construction is fundamentally a player-driven kind of play. Trying to offer well-paced survival challenges to a player that is doing things at their own pace is very difficult, especially since so much of the player's resources will revolve around the specific things they've built and the specific way they've built them.
For example, in Minecraft, a player might build a wonderful base that is immune to creepers, but when you introduce those block-grabbing Endermen, it's a crapshoot. Some players, especially those that know what's coming, will have bases that don't get affected much at all. But other players, while their base is 100% proof against spiders and creepers, will collapse if even a few blocks are removed - torches go out, gaps for spiders and creepers are introduced...
This is nearly impossible to calibrate. Games where survival is key keep the calibration easy by not allowing the player to have different resources than the devs expect. You have access to X, Y, and Z guns. You have health, your speed is exactly this fast, you can see exactly this far. Because the devs know what you've got, they can present you with challenges. When the players build everything as they like, the devs have no idea what you've got!
Obviously, you can try to limit the player. But that's the opposite of what I would recommend. I like giving the player more freedom.
Letting the player construct whatever they want is really the heart of the construction genre. I don't mean constraint-free, I just mean letting the player create in the direction they want. Every player will approach the situation differently, and that's great.
But how do you create a compelling framework for this "construction" genre?
If you ask a normal dev, you'd hear two basic ideas. 1) Tiered resources: drive the player to find more useful resources in more dangerous places. 2) Phased challenges: introduce enemies, weather, and events on a schedule such that the player has to react to them.
These are good starts, but they're inherently "survivally". Let's look at a different way of thinking about it: optional constraints and challenges.
Kerbal is a good example of this. Putting aside the weird career mode they bunged in recently, there's no in-universe reason to go to any particular planet. But the fact that the planets exist is enough to make you want to go. Moreover, you can plan any kind of mission to the planet that you want, with any number of stages.
You don't simply decide to "go to Juul". You decide what kind of ship will go, manned or unmanned, what science stuff to include, whether it's a round trip or one way, what kind of landings you plan to try, whether to set up a permanent station in the area, whether to use a Kerbal-orbiting station to construct the ship and refuel before setting out, whether you want to take it slow or rush to Juul, whether you want to slingshot off the Mun or off of another planet on the way to Juul... and if you start including mods, the number of options goes up dramatically. How about an airship permanently stationed in Juul's atmosphere?
This freedom allows people to construct as they please. While it may not appeal to all players, I don't think the construction genre needs to appeal to everyone any more than the first person shooter genre does.
The way Kerbal is constructed is very clever, but there are a lot of things to learn from other games. For example, Space Engineers offers an options menu where every constraint is toggleable and tweakable. This includes things like inventory size, sure, but also things like whether there are days and how long they are. This complexity allows players to develop for radically different environments without actually having radically different environments in the game world. It also allows players to change those options during play, allowing them to develop in one set of constraints, then switch over to test or "play out" in another set of constraints, something made easier by blueprints which can be pasted into or built in other worlds.
This is a powerful concept: you can create a ship in "creative mode" with no enemies or materials requirements, then switch over to a hostile, limited world to test your ship. You can then copy it and go into a friend's server and paste it in and have a battle royale or a work together as a team...
This isn't a completed implementation. It's not very fluid, switching modes or transferring constructed content is a huge pain, and the multiplayer functionality is so bad it's actually hilarious. But it's easy to see the beginnings of a genre there.
And it's not a "survival construction" genre where you crash on a planet and have to build your own base to survive. That's just one vaguely-implemented scenario. The power of the game comes from the unfettered construction the player is allowed. Players will accept challenges and constraints just for the fun of it, and they'll come up with objectives and complex multi-phase missions that you never would have thought of and certainly couldn't organize.
So, that's my thought. If we're going to do construction games, we should have a flexible way to accept a variety of constraints and challenges, and allow players to pick and choose what they want to approach in what ways. A big part of this is making it easy to switch constraints and challenges midstream, since many players will want to build and test and iterate instead of just grinding it out in a survival challenge.
You don't need to make the game about survival. It will naturally become about survival if and when the players want it to. It might also be about building cathedrals, or putting together a fleet for a dozen players to work together.
There's also no limit to the kinds of challenges and constraints you can offer. It's popular to just use the basic construction ideas - some facility-wide resources, some physical constraints, some topological challenges, and realtime combat.
But you can define your game with a lot more creativity if you offer a wider range right up front.
For example, what about if you could "weather" your facilities for N years, turning them into ruins or seeing them adapted by NPCs? What if you have missions other than fighting, such as transport, medical, research - if you make them as complex to manage in real-time as combat is, you can have compelling noncombat challenges. How about simulating the people inside the facility?
Any one of these additional "modes" would make your game unique on the marketplace today, but in ten years, I expect they'll all be considered standards in the genre.
That's what I think, anyway.
Tuesday, January 19, 2016
Game Systems and Reboots
Any of you ever play Rifts?
Now there was a tabletop game that creaked and clanged. A byzantine rule set full of weird exceptions, nonexistent balancing, and an endless parade of expensive expansion books.
Was it a bad game? Well...
Let's compare it to D&D. D&D underwent a series of reboots over the years.
While it's a bit uneven, D&D reboots about every five years, invalidating all the books of the previous version. This is a serious move for the creators, since it means all the expansion books to date are now worthless. Expansion books are a huge part of the income from that IP - core books are just the start.
But it looks like around five years after the core books come out, people stop caring to buy expansion books, so it's time to roll out some new core books and start again.
Each iteration of D&D uses new rules, and all the elements of the game (monsters, settings, treasure, classes, skills, etc) are rebalanced and recreated anew. While people have versions they prefer, by and large each version is cleaner than the last version, if just because it hasn't had time to accumulate much cruft.
Rifts didn't reboot. At all. For 25 years, Rifts has kept the same core rules, skills, classes, etc.
Why?
Because Palladium Books likes expansions. The idea of invalidating expansions is just not in their business plan, especially since their expansions are "half core" - nearly every Rifts setting book adds core features to the game's rule set. If you create a tattooed man or a blind warrior maiden or werewolf or Glitterboy pilot, you have a character with radically different rules from most other characters. If those expansions are invalidated, then those concepts don't even exist any more. It's not like invalidating an "elves in detail" book - if you do that, there are still elves.
This is not just speculation - Palladium Books insisted that EVERY expansion book from all settings was theoretically compatible with every system. So you could play a Teenage Mutant Ninja Turtle in Robotech.
This approach made reboots nearly impossible, and power creep inevitable. The best character to play in Rifts was whoever was in the most recent expansion book. The rules grew more cryptic and arcane as exceptions became the norm.
This is an interesting situation to compare. D&D, with its frequent reboots that recentralize and condense vs Rifts, with its infinite expansions, the only new versions being to rerelease the core book with some important expanded content stitched in. Comparing D&D 5e to Rifts is really revealing.
Now, the reason I bring it up is actually a bit different than you might expect.
See, each Rifts expansion book should have just been its own game.
The problem with tabletop publishing at the time is that people played games by having a group of dedicated nerds sit at the same table for years. If you played Rifts, you kept playing Rifts more or less forever. If it was D&D, you played D&D forever. You probably didn't even switch editions!
My opinion was always the opposite. Games should have an arc. They should have a finish. Whether it takes one session or twenty, there is a trajectory and the end is always drawing closer.
If you do this for a while, you notice that the rules and extraneous content make a huge difference. A game can be dramatically weakened by using a rule set that doesn't highlight the core draw of the game. A game can also be weakened if there's random content stuffed in that draws attention away from the core of the game.
Now, if you are playing in the way the old publishers decided everyone was, maybe that's not a big deal. You're attached to the characters and setting, rather than to the game or the core draw.
But if you play games that have an end, you quickly start to notice these things. And when someone says "hey, want to play this d20 game?" You find yourself shaking your head.
"D20 doesn't have much to say any more," you reply, and they stare at you blankly.
Now there was a tabletop game that creaked and clanged. A byzantine rule set full of weird exceptions, nonexistent balancing, and an endless parade of expensive expansion books.
Was it a bad game? Well...
Let's compare it to D&D. D&D underwent a series of reboots over the years.
While it's a bit uneven, D&D reboots about every five years, invalidating all the books of the previous version. This is a serious move for the creators, since it means all the expansion books to date are now worthless. Expansion books are a huge part of the income from that IP - core books are just the start.
But it looks like around five years after the core books come out, people stop caring to buy expansion books, so it's time to roll out some new core books and start again.
Each iteration of D&D uses new rules, and all the elements of the game (monsters, settings, treasure, classes, skills, etc) are rebalanced and recreated anew. While people have versions they prefer, by and large each version is cleaner than the last version, if just because it hasn't had time to accumulate much cruft.
Rifts didn't reboot. At all. For 25 years, Rifts has kept the same core rules, skills, classes, etc.
Why?
Because Palladium Books likes expansions. The idea of invalidating expansions is just not in their business plan, especially since their expansions are "half core" - nearly every Rifts setting book adds core features to the game's rule set. If you create a tattooed man or a blind warrior maiden or werewolf or Glitterboy pilot, you have a character with radically different rules from most other characters. If those expansions are invalidated, then those concepts don't even exist any more. It's not like invalidating an "elves in detail" book - if you do that, there are still elves.
This is not just speculation - Palladium Books insisted that EVERY expansion book from all settings was theoretically compatible with every system. So you could play a Teenage Mutant Ninja Turtle in Robotech.
This approach made reboots nearly impossible, and power creep inevitable. The best character to play in Rifts was whoever was in the most recent expansion book. The rules grew more cryptic and arcane as exceptions became the norm.
This is an interesting situation to compare. D&D, with its frequent reboots that recentralize and condense vs Rifts, with its infinite expansions, the only new versions being to rerelease the core book with some important expanded content stitched in. Comparing D&D 5e to Rifts is really revealing.
Now, the reason I bring it up is actually a bit different than you might expect.
See, each Rifts expansion book should have just been its own game.
The problem with tabletop publishing at the time is that people played games by having a group of dedicated nerds sit at the same table for years. If you played Rifts, you kept playing Rifts more or less forever. If it was D&D, you played D&D forever. You probably didn't even switch editions!
My opinion was always the opposite. Games should have an arc. They should have a finish. Whether it takes one session or twenty, there is a trajectory and the end is always drawing closer.
If you do this for a while, you notice that the rules and extraneous content make a huge difference. A game can be dramatically weakened by using a rule set that doesn't highlight the core draw of the game. A game can also be weakened if there's random content stuffed in that draws attention away from the core of the game.
Now, if you are playing in the way the old publishers decided everyone was, maybe that's not a big deal. You're attached to the characters and setting, rather than to the game or the core draw.
But if you play games that have an end, you quickly start to notice these things. And when someone says "hey, want to play this d20 game?" You find yourself shaking your head.
"D20 doesn't have much to say any more," you reply, and they stare at you blankly.
Wednesday, December 30, 2015
Star Wars Review
Finally saw Star Wars. This will be me talking about it, because I'm sure everyone wants to hear my opinions!
Well, they might be a bit unusual.
First, though: spoilers ahead!
All the spoilers.
...
Force Awakens is by far the best film JJ Abram's ever put out. The movie is... not bad. The DP is great, the effects are mostly great, the actors are mostly pretty good, the sets are great, the music was fitting, and the directing has been carefully cut into pieces and arranged to be as unbad as could reasonably be managed. The writing is awful, but in an inoffensive way.
It is radically better than I expected, which is nice. It is... not bad.
Now, let's talk about some thematic stuff, because this is where the movie interests me most. Obviously, any thematic stuff is in here on accident or because JJ Abrams saw the cover for a book or something, but there's still some meat here.
First, the villain. I like him.
Now, let's be clear. The guy is a doofus. He's a pale shadow of Darth Vader. But that's the point! That's great! There's no way for a new dragon to step into Vader's shoes, and this is an open, in-world admission of that. I like the fact that the mask makes him look vaguely intimidating, but he's a snot-faced kid inside. I think that's fantastic. It fits in-universe as a scared boy stepping into radically outsized shoes, and it fits in the metafilm as an admission that nobody's gonna match Vader, and it fits in the mythology of the Force: villainy isn't born from strength.
I like the overall arc of him killing his father, and his father basically letting him do it. I think the progression was bad, the dialog was incredibly overweight, and the moment-to-moment writing/directing was pretty abominable, but the overall arc is fantastic. The idea that a scared kid needs to kill his father to prove himself, and his father just lets him? That's powerful. That's good.
Unfortunately, it's extremely hard to build a villain up from "scared little kid". It takes a lot of screen time to grow up, and they aren't going to give this kid that amount of screen time. So he's never likely to feel like a real threat. It's easier to work backwards: show a badass, reveal he was a scared little kid. Because of that, I don't think this villain will ever really work. This is especially true since they gave the heroes a massive power boost and brought them up to his level already, meaning that he has to grow substantially faster than the heroes, but with a fraction of the screentime.
...
The overall concept of the movie was good. JJ Abrams is no good, and everyone knows it. Forcing him to recreate the original Star Wars movie is a great way to keep him pinned and reasonable, and then you can rely on editors to save the film. A tried and true Star Wars approach.
Unfortunately, it doesn't make much sense. It undoes the original trilogy, and nobody in-world has any explanations or concerns about how it happened.
I understand that Disney needed to use their existing actors before they die of age, and that Disney needed to make a "return to Star Wars classic" movie. But I just can't accept this nonsense setting. You have to reaaaaally stretch to explain it, and even if you do, it ends with "and that means the original trilogy basically accomplished nothing."
The big bad is awful, just the least interesting villain I've ever seen. Clearly they just wanted the Emperor again, but it's really dull. It's made worse because it makes no sense. Where did this ultimate big bad come from? Everyone talks about him as if he's always been around, but that again degrades the original trilogy.
It's a very "Dragonball Z" plotline.
Now, I think it would be really interesting if the villain turns out to be making Kylo suck on purpose. The idea of training a Sith lord wrong in order to bring his fear and anger to a peak, then fixing the mistakes... is an interesting one. I don't think that's what's in store, but it could have been an interesting idea. Still, the villain is nonsense.
"But where are they supposed to find a villain if-"
Uh? Exar Kun? The backstory could have been "Kylo Ren was in training, stumbled across a Sith holocron, and OH SHIIIIIIIII"
I think that could have been equally compelling. And there's a lot of cool reveals built into that. For example: Kylo Ren keeps asking for guidance from a hologram. Then it's revealed it's just the holocron, and he's just searching it. There is no super villain Emperor equivalent: everyone just thinks there is, because Kylo keeps bringing them in to see this really intimidating holocron. And it's really good at administration: they ask it what to do, and the computer spits out an optimal answer. Everyone thinks it's a real person - maybe even Kylo.
This would be an amazing way to instantly level him up, a real Bates Motel moment. We go from thinking "how is this Sith Lord so bad at everything" to "HOLY SHIT HE'S HELD THE WHOLE EMPIRE TOGETHER WITH THE POWER OF HIS DELUSION!"
Look, if we're gonna talk about movies that Could Have Been, let's talk about the nonsense map. Of the many things in this movie that didn't hold up, this was a biggie. So, here's a simple alternative:
Luke's teachings failed, and Kylo was seduced by the dark side of the Force. Everyone was killed. So Luke goes in search of the original temple to try and find clues as to how to teach better. Fine, great. The original temple is in the galactic core. Nobody can get in safely without a map. Luke left R2-D2 behind as an anchor, to help keep him oriented and to "catch" his messages. R2 has spit out a number of map fragments over the past decade or so, but rather than saying "we can't pick out these stars", they say "we know which stars they are, but we can only get this far. We need the map for the black holes deeper in to get any further."
And BB8 holds the first piece. The one that just gets you started. The rest is already complete.
This offers a lot of cool ideas. Diving through stellar debris. The Empire - oops, 'Order' - trying to brute-force find a path by sacrificing ships. Our Jedi-to-be having to feel her way through an area that's drifted since Luke went through, using the same techniques he used. This is a good, concrete-but-not-blatant "following in his footsteps" analog.
Look, the movie could have been a lot of things. Thousands of people have given their suggestions on what the movie should have been or how it could have been made better. Adding mine to the stack is no big thing, but I did want to say one more thing:
This is the first sci fi movie in a while that made me want to write my own stuff. Not fanfic, but things with some of the same themes, or pieces inspired by the holes in this movie.
That makes this at least a successful sci fi film. I know the director is worthless and any new ideas were included on accident, but at least I was inspired.
Well, they might be a bit unusual.
First, though: spoilers ahead!
All the spoilers.
...
Force Awakens is by far the best film JJ Abram's ever put out. The movie is... not bad. The DP is great, the effects are mostly great, the actors are mostly pretty good, the sets are great, the music was fitting, and the directing has been carefully cut into pieces and arranged to be as unbad as could reasonably be managed. The writing is awful, but in an inoffensive way.
It is radically better than I expected, which is nice. It is... not bad.
Now, let's talk about some thematic stuff, because this is where the movie interests me most. Obviously, any thematic stuff is in here on accident or because JJ Abrams saw the cover for a book or something, but there's still some meat here.
First, the villain. I like him.
Now, let's be clear. The guy is a doofus. He's a pale shadow of Darth Vader. But that's the point! That's great! There's no way for a new dragon to step into Vader's shoes, and this is an open, in-world admission of that. I like the fact that the mask makes him look vaguely intimidating, but he's a snot-faced kid inside. I think that's fantastic. It fits in-universe as a scared boy stepping into radically outsized shoes, and it fits in the metafilm as an admission that nobody's gonna match Vader, and it fits in the mythology of the Force: villainy isn't born from strength.
I like the overall arc of him killing his father, and his father basically letting him do it. I think the progression was bad, the dialog was incredibly overweight, and the moment-to-moment writing/directing was pretty abominable, but the overall arc is fantastic. The idea that a scared kid needs to kill his father to prove himself, and his father just lets him? That's powerful. That's good.
Unfortunately, it's extremely hard to build a villain up from "scared little kid". It takes a lot of screen time to grow up, and they aren't going to give this kid that amount of screen time. So he's never likely to feel like a real threat. It's easier to work backwards: show a badass, reveal he was a scared little kid. Because of that, I don't think this villain will ever really work. This is especially true since they gave the heroes a massive power boost and brought them up to his level already, meaning that he has to grow substantially faster than the heroes, but with a fraction of the screentime.
...
The overall concept of the movie was good. JJ Abrams is no good, and everyone knows it. Forcing him to recreate the original Star Wars movie is a great way to keep him pinned and reasonable, and then you can rely on editors to save the film. A tried and true Star Wars approach.
Unfortunately, it doesn't make much sense. It undoes the original trilogy, and nobody in-world has any explanations or concerns about how it happened.
I understand that Disney needed to use their existing actors before they die of age, and that Disney needed to make a "return to Star Wars classic" movie. But I just can't accept this nonsense setting. You have to reaaaaally stretch to explain it, and even if you do, it ends with "and that means the original trilogy basically accomplished nothing."
The big bad is awful, just the least interesting villain I've ever seen. Clearly they just wanted the Emperor again, but it's really dull. It's made worse because it makes no sense. Where did this ultimate big bad come from? Everyone talks about him as if he's always been around, but that again degrades the original trilogy.
It's a very "Dragonball Z" plotline.
Now, I think it would be really interesting if the villain turns out to be making Kylo suck on purpose. The idea of training a Sith lord wrong in order to bring his fear and anger to a peak, then fixing the mistakes... is an interesting one. I don't think that's what's in store, but it could have been an interesting idea. Still, the villain is nonsense.
"But where are they supposed to find a villain if-"
Uh? Exar Kun? The backstory could have been "Kylo Ren was in training, stumbled across a Sith holocron, and OH SHIIIIIIIII"
I think that could have been equally compelling. And there's a lot of cool reveals built into that. For example: Kylo Ren keeps asking for guidance from a hologram. Then it's revealed it's just the holocron, and he's just searching it. There is no super villain Emperor equivalent: everyone just thinks there is, because Kylo keeps bringing them in to see this really intimidating holocron. And it's really good at administration: they ask it what to do, and the computer spits out an optimal answer. Everyone thinks it's a real person - maybe even Kylo.
This would be an amazing way to instantly level him up, a real Bates Motel moment. We go from thinking "how is this Sith Lord so bad at everything" to "HOLY SHIT HE'S HELD THE WHOLE EMPIRE TOGETHER WITH THE POWER OF HIS DELUSION!"
Look, if we're gonna talk about movies that Could Have Been, let's talk about the nonsense map. Of the many things in this movie that didn't hold up, this was a biggie. So, here's a simple alternative:
Luke's teachings failed, and Kylo was seduced by the dark side of the Force. Everyone was killed. So Luke goes in search of the original temple to try and find clues as to how to teach better. Fine, great. The original temple is in the galactic core. Nobody can get in safely without a map. Luke left R2-D2 behind as an anchor, to help keep him oriented and to "catch" his messages. R2 has spit out a number of map fragments over the past decade or so, but rather than saying "we can't pick out these stars", they say "we know which stars they are, but we can only get this far. We need the map for the black holes deeper in to get any further."
And BB8 holds the first piece. The one that just gets you started. The rest is already complete.
This offers a lot of cool ideas. Diving through stellar debris. The Empire - oops, 'Order' - trying to brute-force find a path by sacrificing ships. Our Jedi-to-be having to feel her way through an area that's drifted since Luke went through, using the same techniques he used. This is a good, concrete-but-not-blatant "following in his footsteps" analog.
Look, the movie could have been a lot of things. Thousands of people have given their suggestions on what the movie should have been or how it could have been made better. Adding mine to the stack is no big thing, but I did want to say one more thing:
This is the first sci fi movie in a while that made me want to write my own stuff. Not fanfic, but things with some of the same themes, or pieces inspired by the holes in this movie.
That makes this at least a successful sci fi film. I know the director is worthless and any new ideas were included on accident, but at least I was inspired.
Wednesday, November 25, 2015
The Resurgence of the Civil War
So, apparently the new superhero megamovies are going to be about the civil war arc. HAHAHAHAHAHA HAH HAHAHAHAH HA-
sorry, lemme 'splain.
I last dived into superhero comics just when that arc came out, because it was sort of a concrete arc with a definite beginning. Before, after, and during that phase, I was pretty much done with superheroes. However, it was entertaining to read what I did, because it was so amazingly bad. Then the video game about it came out, and it was so amazingly bad.
If you are a comic nerd, you probably know all about the civil war arc. For everyone else, here's the basic idea:
A terrorist attack convinces the government that people with superpowers cannot be allowed to run rampant, and they decide it's time to register them. The heroes split down the middle, half of them siding with the government's programs, and half against. Hence the title.
Now, this is a concept with an incredible amount of potential. Especially nowadays, with our hilariously racist and ineffectual "anti-terrorism" activities. Since it's a fictional universe, it could be played either way, with either side being "correct", or with both sides having merits, etc, etc.
But it's important to remember that fictional universes don't exist in a vacuum.
First, this is a non-mutant thing. Captain America and Iron Man and all those people. But Marvel and mutants are the progenitor of the "mutant registration" storylines. In fact, Marvel's universe is stained bloody red with the concept of registration from the start: Magneto is a concentration camp survivor.
Mutants not only have the chops to tell these stories, they did tell these stories. They started off with these stories and kept bringing them up. The entire nature of mutants gives credence to these stories, anchors them in believability.
On the other hand, with non-mutants, the universe is set up to tell stories of individuals proving their personal merit. Each hero chooses on their own to fight evil with whatever power they have personally managed to obtain.
So as you might expect, it quickly went awry. It felt like the "civil war" was between the writers, with half staunchly backing the registration as the right move, and the other half staunchly against it. Each writer obviously believed his side was right and the other side was bullshit, but since writers constantly rotated in and out of view as each new issue was released, the result was a chaotic mishmash.
In the end, the storyline went off the rails with cybernetic villains and corrupt prisons and so on. This could have been very interesting... But it was very rushed and was obviously just a way to get all the heroes to drop the issue and work together for the climax.
So... what do you think this movie will be about?
I bet it will be carefully washed out. We wouldn't want to draw any parallels to modern society, to our treatment of Muslims and anyone that looks vaguely Muslim. We wouldn't want to have any meat in our popcorn movies, or accidentally make anyone think!
Water it down, water it down.
From watching the trailer, it looks like they've watered it down to the extent where all they've kept is the nonsense writing, with all the heroes acting out of character for no reason. Without the social commentary, I wonder how well that will go over?
Edit: An earlier version of this essay forgot that DC basically doesn't exist, and that Marvel's responsible for literally everyone.
sorry, lemme 'splain.
I last dived into superhero comics just when that arc came out, because it was sort of a concrete arc with a definite beginning. Before, after, and during that phase, I was pretty much done with superheroes. However, it was entertaining to read what I did, because it was so amazingly bad. Then the video game about it came out, and it was so amazingly bad.
If you are a comic nerd, you probably know all about the civil war arc. For everyone else, here's the basic idea:
A terrorist attack convinces the government that people with superpowers cannot be allowed to run rampant, and they decide it's time to register them. The heroes split down the middle, half of them siding with the government's programs, and half against. Hence the title.
Now, this is a concept with an incredible amount of potential. Especially nowadays, with our hilariously racist and ineffectual "anti-terrorism" activities. Since it's a fictional universe, it could be played either way, with either side being "correct", or with both sides having merits, etc, etc.
But it's important to remember that fictional universes don't exist in a vacuum.
First, this is a non-mutant thing. Captain America and Iron Man and all those people. But Marvel and mutants are the progenitor of the "mutant registration" storylines. In fact, Marvel's universe is stained bloody red with the concept of registration from the start: Magneto is a concentration camp survivor.
Mutants not only have the chops to tell these stories, they did tell these stories. They started off with these stories and kept bringing them up. The entire nature of mutants gives credence to these stories, anchors them in believability.
On the other hand, with non-mutants, the universe is set up to tell stories of individuals proving their personal merit. Each hero chooses on their own to fight evil with whatever power they have personally managed to obtain.
So as you might expect, it quickly went awry. It felt like the "civil war" was between the writers, with half staunchly backing the registration as the right move, and the other half staunchly against it. Each writer obviously believed his side was right and the other side was bullshit, but since writers constantly rotated in and out of view as each new issue was released, the result was a chaotic mishmash.
In the end, the storyline went off the rails with cybernetic villains and corrupt prisons and so on. This could have been very interesting... But it was very rushed and was obviously just a way to get all the heroes to drop the issue and work together for the climax.
So... what do you think this movie will be about?
I bet it will be carefully washed out. We wouldn't want to draw any parallels to modern society, to our treatment of Muslims and anyone that looks vaguely Muslim. We wouldn't want to have any meat in our popcorn movies, or accidentally make anyone think!
Water it down, water it down.
From watching the trailer, it looks like they've watered it down to the extent where all they've kept is the nonsense writing, with all the heroes acting out of character for no reason. Without the social commentary, I wonder how well that will go over?
Edit: An earlier version of this essay forgot that DC basically doesn't exist, and that Marvel's responsible for literally everyone.
Subscribe to:
Posts (Atom)