Friday, May 20, 2016

Ghostbusters Review

Since so many people have decided not to review the new Ghostbusters movie, I have decided to fill that gap! Here is my review.

The movie has definitely suffered from its inheritance: like most eighties megahits, the sequels drown under the weight of greedy hands. Forty writers and two hundred producers means the movie was destined to be a patchwork. The question is: how nice is this patchwork?

Well, it's clear that the (editor/DP/sound guys/caterers) did a stellar job, but everyone else on the crew clearly struggled under the deluge of conflicting orders. It was difficult to watch without quipping, given my long experience mocking B movies.

I did enjoy the cast, each distinct both visually and in character. I was especially blown away by (McCarthy/Wiig/McKinnon/Jones), as she managed to actually say the script's driveling with a straight face.

As the movie wore on, it became clear that my biggest problem was not the confused writing or meddlesome production: it was the (racism/sexism/homophobia/objectivist politics). Despite the progressive tint the casting gave this movie, in the end it was poisoned by the same weird old crap that poisons nearly every big-label reboot.

In the end, is the movie good or bad?

I would put this movie substantially above the Transformers reboot (which was unwatchable if you speak English). I would even put it above the Star Trek reboot, as the camera work didn't make me physically ill and the writing didn't actively betray the ideals of the original.

Yes, if I see this movie, it will definitely be in the top 3 new releases I saw this year.

No matter how I order them.

Thursday, May 19, 2016

Tech Economies in The Galactic Line

(This is an essay about a specific, in-development game.)

In most space games, you have science and money. You discover gravitic sensors, now everyone in your space nation has access to them, and you can slap them onto ships as fast as your money allows.

In The Galactic Line, it's a bit different. Every colony has a tech economy, basically a bunch of different economies stacked up. Each one represents a specific level of technology.

You never "research computers" or "research gravitic sensors". If you have an economy capable of producing them, you are producing them. If not, you aren't. To simplify this, individual technologies are clumped into "tech tiers" - you don't track 10,000 different specific production lines, you just have a few "economies" that produce that tier.

This gives us a lot of potential play.

Let's say you start a game as 1960s Earth. The planet has a tech level 0 economy of 100. This represents all the mining, smelting, truck-building, pipe-laying, glass-making, food-growing, etc. The earth economy is more complex than that, of course, especially because the planet is divided against itself. But that 100 represents it.

When we decide to build a space station (say, the ISS) or a space ship (say, a moon landing mission), we assemble it out of ship components using the construction system. Each component has a cost attached to it. So we build a small crew cabin (0.5 T0), the solar panels (0.2 T0 each), the cooling system (0.2 T0), the docking elements (0.1 T0), scanners and comm rigs (0.3 T0), medical chamber (0.2 T0) etc, etc. At the end of it, we have a final cost, something like 3.5 T0.

So our T0 economy drops from 100 to 96.5. If we wanted to, we could have built a much larger station and ground our economy to a halt funding it, but that's generally not a great idea. This also reduces the number of gainfully employed people - a bunch of people now have jobs as advertising execs, instead.

What's the point? Building space ships and space stations actually harms your economy! Why would you build them?

Well, the space station has a number of missions it can take. For example, monitoring the astronauts for medical changes due to micrograv, radiation exposure, and so on. This mission arises from and is enabled by our medical chamber. This mission, if successful, teaches Earth to make more advanced medicines. Functionally, it exchanges 5 T0 economy for 1 T1 economy.

If you spend some time and take that mission ten times in a row, you'll end up with 46.5 T0 economy and 10 T1 economy.

The T1 economy represents computers, phones, lasers, industrial robots, plastics, particle accelerators, magnets, and so on. We are now capable of building a much more advanced space station, if we want, or maybe a new ship.

Of course, losing that much T0 is pretty bad. We probably wouldn't want to just have that one mission running over and over. Mix in a few Earth-scanning sensors - their missions help to bolster T0 economies by finding new resources, monitoring dangerous weather or pollutants, providing phone/TV signal relays, and so on. Each of these is also a mission which has specific constraints and difficulties.

So we might provide signal relays. This is a relatively easy, short mission. So we cycle those while we do our medical research, and in the end we have 100 T0 and 5 T1.

I'm simplifying the actual gameplay process, because we're discussing the back end. In terms of the player experience, these missions are similar to the "day jobs" in The Sims. While they affect the world, the real purpose is to give your crew something important to do while they live their lives. So the explanation I just gave is very similar to having a house in the sims and saying "this guy works a day job as a cop to earn cash for the house, this guy is trying to be a musician."

The missions have limits on how strong they can make the local economy. If you're trying to increase the T1 economy, then the difficulty is based on the current T1 economy. Same with the T0 economy and improving it. Higher difficulties not only increase the amount of effort required to complete the mission, but also increases the chance of failure when you do finish the mission. Every time we repeat our medical study, it takes longer and is more likely to fail. Basically, there's an upper limit on how effective these techniques can be.

There are a lot of things that can increase these limits. More people and more medical bays will make the missions go by faster. Adjunct missions can increase your chance of success - for example, a computer core can have a mission to correlate and organize the data, a residential hub can have a mission to account for secondary variables, etc. These also take people and facilities, so you'll need larger and larger space stations. Of course, more expensive facilities have less difficult missions: the T1 medical facility has a lower-difficulty version of the T0 medical bay research.

This is like in The Sims, how your jobs pay more but require more skill as you rank up.

But the scaling isn't linear, and it doesn't makes sense to simply build bigger and bigger stations. Instead, colonization is an impetus.

That crappy T0 medical bay might not be able to get your homeworld above a T1 economy of 10, but it could get fifty asteroid bases up to a T1 economy of 10. Since they all belong to Earth, Earth's local T1 economy might only be 10, but it has a total T1 economy of 510 thanks to 50 asteroid bases. This is like if your Sims houses could share their bank accounts with each other.

"But", you say "that's at least 50 space stations. And if we want more efficiency, we'll have to build hundreds of ever-more-expensive space stations-"

Yeah. Did I mention that The Galactic Line is mostly a space ship game?

Build one expensive space ship, send it to each asteroid in turn, bring their T2 economies up. Or their T1 economies to 50. Whatever you need. And the whole time, the people on the ship have lives and look out the window at the asteroid below and chat with whoever is on the asteroid, talking about how mnamnamumblemna and moomumblemoomum.

Space ships have a lot more capabilities than that, too, because a lot of missions are only available in specific situations. For example, building to T3 economies is really rough. The easiest way to do it is to analyze space wedgies. But space wedgies are temperamental. You might be able to find one or two permanent ones and build colonies nearby, but usually you'll want to send out a well-equipped science ship when a temporary space wedgie pops up. They do the mission, return to a planet for the finale, and that colony gets some T3 economy even though it's nowhere near a space wedgie.

Now, this is the simple version. In practice, there are many things I could do to make things more complex and interesting. But don't you think it's already complex and interesting enough?

Thursday, May 12, 2016

Stellaris' Uncomfortable Spotlights

Let's talk about sci fi, about 4X games, about Stellaris.

In my lifetime I have played a staggering number of 4X games. I even created 4X board games when I was a kid. It's a genre close to my heart, because I like building things and I like science fiction.

Most game genres have slowly matured. They have gone from simplistic simulations to more complex offerings that integrate many layers of player choice and interactive narratives. First person shooters started at Doom but matured into Mass Effect 3 and Just Cause 4. Sure, not everyone wants the added complexity of a cinematic universe, complex skills, construction, leveling, etc. But many people do, and those people have found these new games more rewarding and interesting than the "flat" old games.

4X games haven't done that. They're pretty much the same as they were with Masters of Orion, just with snazzier graphics. Stellaris is just another one in the chain, struggling to make its mark but refusing to step away from genre conventions that were outdated twenty years ago.

I'm not saying Stellaris is bad. Like many retro shooters, there is a place for oldschool games. The genre was invented to serve an itch, and the itch hasn't faded. But there are many of us that play 4X games because they are just vaguely close to what we want, like people that played Doom but wanted Mass Effect.

So let me creep up on the subject. Don't want to scare it off.

I knew I wouldn't like Stellaris too much, because all the marketing is about space battles. When it comes to 4X games, the space battles part is always weak. At first glance, it's odd how much focus these games always put on combat, since it funnels you into playing a warring species even if A) you don't want to and B) that makes no sense.

But the combat in these games plays two major roles, and the devs usually don't want to figure out a better way to accomplish those two roles, so they just keep combat in.

The obvious role is "meat gate". Other species, raiders, and passive alien hazards are all blockades that prevent you from just running roughshod over the whole galaxy. By forcing you to fight, the devs force you to spend time and resources on a navy. This means that non-warlike species don't have an overwhelming economic advantage - they still need to spend a lot of resources on their navy, even though it's not part of what they care about. This economic wall is a negative feedback loop that means star nations will expand at a similar rate regardless of their approach, which is a cheap and easy way to balance the game.

If you've played Stellaris, you probably already understand what I mean. There are a lot of random monsters, especially around high-value stars/black holes. These keep you cut off, force you to move slowly and settle for low-value stars. Eventually, you will need to use an expensive navy to fight those monsters. The earlier you do so, the more economic reward you get for having access to the high-value star and the more the science reward matters. It all balances out.

The other big role of combat is "storytelling". Humans are really great at weaving stories out of a few clear data points, and there's nothing clearer than a fight. We build a story in our head of our struggles against the Klarthians or whatever. This story keeps us connected to the situation, invests us in the universe. It gives the game punch.

It's easy to test this theory out: just play Stellaris after typing "invincible" into the console. You'll see how quickly the game falls apart. The pace and punch are gone, and it's just not very fun to play.

But I'm not holding that against Stellaris: every 4X game is like that. Stellaris has a few cool features to try and keep the game focused even in those situations, such as districts and such. But Stellaris is interesting because they accidentally stepped into my world, accidentally created a shadow of the game I actually want to play. A post-4X genre.

So, I settled on a big desert world named Dnar.

After a short while, my species evidently decided a desert world was a pain in the ass so, without asking (and without me having access to the tech) they genetically engineered themselves and called themselves "post-humans". Fine, neat!

This began what was obviously a scripted arc where tensions grew and then war bloomed between the standard humans and the post-humans. This is a really neat idea, meatily supported by the detailed population system, which allows for subcultures and subspecies to be clearly marked on the world maps. It was hampered by the way I didn't really get any options, couldn't really do anything. With every new event, the only option I had was "that's concerning".

Well, that was a bit disappointing, but it's a neat idea, right?

Here's the monkey wrench.

See, turns out Dnar wasn't an uninhabited world. There was a subterranean species and, after a short while, they joined me on the surface. Some kind of slug thing.

Then all the baseline humans left. The post-humans were suited to the desert environment, and the human-humans weren't, so all the human-humans just... left. Dnar was populated by post-humans and slug monsters only.

Still the scripted arc continued. The humans sabotaged the post-humans. The post-humans clashed with the humans.

But there were no humans. Everyone on Dnar was post-human or slug monster.

And there's the highlight.

This is real sci fi. This is where you let me shape the stories of whole populations, this is the story of people and places under the pressures of technology.

Of course it's all scripted and the script falls flat. It would have to: the setting is too diverse and chaotic to simply use a canned script.

But... you could use an algorithm.

The way the universe of Stellaris is set up, you know exactly what populations on what planets are what species, how happy they are, how strong their cultural drift is, and so on.

It would be possible to write an algorithm for how these species behave, how their events spool out.

The post-humans are considered travesties by the general population? But there's no general population on Gnar. The post-humans would have no outlet for that. Instead, it'd be about how they get along with the slug-monsters, with the human governor. How they emigrate.

Do they drift away from the core culture? Do they start to talk about succeeding from the empire? How does the governor deal with that? The president? The slug monsters?

To me, trying to govern that world, massage that situation is 100x as interesting as sticking pins in a map.

Now, that isn't to say that sticking pins in a map is bad, or even off the table. Sticking pins in a map is a great way to feel like you're part of the universe, a great way to manage your overall resources and the flow of your civilization. But the challenges and opportunities and complexities of a galactic empire stem from the isolation of space, the chaos of technology being adopted willy-nilly, the wealth and poverty to be found at each new colony...

That's the 4X game I want to play. One where you struggle to keep your empire intact. Not against the threat of war or random monsters from space, but from the simple threat of people under the pressure of technology. There's a huge space for this kind of game.

Friday, April 22, 2016

Screenshots that Clear a Path

Recently, I've been thinking about UI, about presentation, about gifs and screenshots.

When I think about screenshots and gifs, I assumed I would think about visually impressive games. But normally, that's not what I see at all. I see a deluge of charming images from smaller, indie games that happen to fit well into a screenshot.

I think this is easy to explain: indie devs are naturally attracted to games that make for good screens and gifs. They tend to develop those games, because when they share an impactful screen or gif, they instantly get feedback on how cool it is.

And I think that's great. A powerful screenshot is forever. It doesn't require you to be curious, or interested, or click through, or even care: you just happen to see it and you're drawn in. A video ad or an LP requires you to already be interested, to be willing to start up a video and sit through it. In the long run, I think a screenshot might be better than a video if you want to try and get strangers interested in your game.

I started thinking about what screenshots and gifs I like to see, and the answer was simple: I like the ones that show me the game's potential.

Whether the game is a tiny indie title or a huge blockbuster, just showing off a game's visuals or basic appeal doesn't affect me at all. I need to get a feel for what it would feel like to play the game.

This doesn't mean taking a screenshot of a cool moment, necessarily. For example, Among Thorns doesn't have any screenshots of "cool moments". But it does have evocative screenshots that make an impact.

The screenshots show hints of what the game contains. Mood, story, play - it's all hinted at, at least in the first and last screenshot. You get a feel that the game contains many subtle, cool things, even though there's not really anything amazing shown right up front. No boss getting shot, no diving from an airplane, not even any real UI.

And I started to think: what if we design our games specifically to always look good in screenshots? Specifically to always gif well? What if there was literally no way to take a screenshot or gif which did not give a casual viewer a sudden attack of curiosity?

Inside a good screenshot or gif are a few common elements. Obviously, it might be of something funny or moving, like a dog glitching through a floor or whatever, but let's put that aside and look at universal elements.

A good screenshot is visually readable, even at lower resolution than the game. Even if we don't know what's going on in the play of the game, we have to know what's going on in the world of the game. We don't know if the player set up the two people at the noodle shop, but we know there are two people at a noodle shop.

A good screenshot shows the mood of the game. The cool lighting and dark night immediately speak to us, as would a cheerfully primary-colored children's game. Screenshots with generic tones or giant spreadsheets don't appeal.

A good screenshot shows us hints of what we can accomplish or experience. Not necessarily as play, but during play. For example, we don't know whether we can choose to stop by the noodle shop and interact with it. We just know that we will stop by the noodle shop and interact with it. The distinction is important, because it means we don't have to show interaction cues or whatever. We can just show, by context, that you're going to be involved in these things.

Let's talk about a game that does this really well: Minecraft.

In Minecraft, it's almost impossible to take a screenshot without accidentally showing all these things. If you take a picture of an empty landscape, you know that Minecraft is about vast expanses of land that you can freely explore, and the open, adventurous mood shines through. If you take a screenshot of a deep cave, you know you can explore scary caves. If you take a screenshot of a little hut you built, you show that Minecraft is approachable at a small scale - anyone can bung something together. If you take a screenshot of a vast city, you show the upper limits of what Minecraft can achieve.

But that's not the limit.

If you take a picture of a multiplayer game, you can immediately tell it's multiplayer rather than containing NPCs, because of the subtleties of how multiplayer characters are portrayed (name tags, unique costumes, off-kilter pathing, etc). If you take a picture of your inventory, you can immediately see the scope and scale of the item management and crafting. If you take a picture of the title screen, not only is there a world in the background that shows you what's up, but the actual title elements show you can do mods and stuff.

In fact, the screenshots of Minecraft are much more powerful than the actual play. When you're actually playing Minecraft, it starts opaque and confusing and you punch trees. I mean, they've softened it recently, but when it was getting popular, it was almost unapproachable. But because you knew what Minecraft could do, you stuck with it.

I think there is merit to designing a game specifically to force this. Specifically so that whatever screenshot the player takes, it will plant the play and tone and experience of your game into everyone's head.

"Aren't all games like that?"

No. Think about GTAV. A lot of people really love this game. But screenshots of GTAV are almost universally of scenery. You sometimes see hints that your player can drive, or hang-glide, or shoot guns, but you don't get a feel for what it feels like to do those things or what effect it has. Moreover, despite the beauty of the scenery, interacting with that scenery is not a core part of the game, it's just space you can cross.

On the other hand, Minecraft is about half scenery and half houses. Even just taking the shots of scenery into account, you can clearly feel the interactability of the scenery because of its voxel nature and first-person perspective. Anyone with an experienced eye can tell that GTAV's scenery is canned, non-interactive. But Minecraft's scenery is weird and clunky, and even if you didn't know anything about Minecraft you can still tell there's something unusual about it, and it doesn't trigger your "oh, it's just canned shit" sense.

Whether accidentally or on purpose (almost certainly on accident), Minecraft has nothing in it that is just glitter. Every screen shows something you can do or feel or experience. Even menu screens, even "sleeping at home" screens, even "just loaded up the game for the first time" screens. Moreover, none of the screens show something tropey or standard (well, except in that they've been cloned since then).

By either cutting out all of the fluff or engineering the fluff to reflect the unique things you can do, I think we can have the same sort of result. No more noninteractive worlds that are filled with set pieces nobody cares about. No more menus that show you can "equip guns". Those say nothing about what makes the game new or interesting or unique.

Anyway, I've been thinking about it a lot, because I'm making The Galactic Line, and in my head it was not screenshotting well. Now that I've started to think about it, I've suddenly found my path forward is super-clear. I've come up with ways to present gameplay that was foggy and spreadsheety before. I think I've found a great basis for how to make the game look and feel great - by simply imagining how any given system would look if someone screenshotted it and put it on Twitter with the caption "hey, anyone want to play this game?"

And part of that came from looking at other space games, other Sims games, and seeing what screenshots were the most powerful and evocative.

I think it's really improved the game. It's certainly improved my vision and motivation!

... next step is making it gif properly, but I'm not sure I can manage that with The Galactic Line. It's not exactly an action game.

What are your opinions?

Friday, March 25, 2016

Making NPCs Into Feedback

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?

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.

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.