Ys: Memories of Crap Writing

I'm going to spoil the ending of Ys: Memories of Celceta. Trust me, it doesn't matter. There is nothing interesting about the plot.

The ending of YMOC is the same as Lord of the Rings. I don't mean that it is similar, I mean it is literally beat for beat identical. You have to destroy the one ring - er, the "sun mask" - in the fires of the hottest volcano. Climbing through fire and quake and goblins, you reach the top and are faced one last time by a member of your own kind, twisted and stretched thin by the dark powers of that you seek to destroy. Then you toss in the ring and the volcano explodes. You are rescued by eagles. Er... I mean "flying mecha".

Now, in the case of Lord of the Rings, the ending was... well, it wasn't the strongest ending ever, but at least it felt like the heroes were doing a task that needed doing.

The problem with YMOC's ending is that there is no reason to do any of it. See, you're tasked to climb the mountain and destroy the mask, and you are forced to accept. But the catch is that "Gandalf" is, in this case, a flying angelic creature. While you could theoretically see him being corrupted by the one ring - I mean the Sun Mask - it's already clear that the "dark" personality of our Gandalf-equivalent is driven solely by the desire to free humanity from his own tyrannical rule and force them to pioneer their own path. So even if he did go "dark", the destruction of the planet would be something he would also want to avoid, and he would be very happy to destroy the mask and claim freedom for humanity.

What, physically moving around a bit much for our crystal dragon Jesus? Well, his main sidekick is a perfectly human lady with a FLYING MECH. She's flown us around on it several times. She's incorruptible - we know because she's held the mask of the sun before and didn't suffer any qualms. And she literally has nothing else to do. She's just hanging around in the background.

Actually, after we're forced to accept the task, she flies up to us halfway up the volcano, kills a few goblins, and then's like "I'll cover the rear, here. Don't worry, if it gets dangerous, I can fly away!" Sigh... then she rescues us from falling into the caldera, so it's pretty damn clear she could have done this whole operation without endangering anyone. I guess Adol could have ridden with her, just for closure's sake.

But is it too much for her? How about the pixie that flies from one edge of the continent to the other dozens of times over the course of the game? No?

Well, we have two rangers on our team - heroes from deep forest villages, masters of stealth and speed. So we can rely on them to - what, they're staying behind to guard Crystal Dragon Jesus? WHY? They're perfectly suited to scrambling up a mountain and not at all suited to holding the line against an army of shadow-goblins. Instead, let's take the child, the hulking brute, and the refined lady in the evening gown. Those are definitely the ones more suited to scrambling up a mountain!

What I'm trying to say is that the ending sucked.

It's not very often that the ending of a game can completely ruin a game for me. Most games have pretty weak endings, and I've come to expect that. But when the ending requires dozens of people to simultaneously fail to notice that three of them can fly, that's pretty sad. It's on the same level as sacrificing yourself in Fallout 3, when you have radiation-proof party members that can do the same task completely without risk.

I don't think anyone is asking for perfection in writing, but this game looks like it took at least a million dollars to produce. Maybe spend one whole day thinking about the ending?

Immediacy in Online Games

Well, the term "MMORPG" is really obsolete, so let's refine how we talk about online games!

There are two pieces to how players interact in online games, and these pieces are simply not talked about much. I don't even think there's defined terms for them. The two pieces are the number of players interacting, and the immediacy of their interactions.

So I'll propose some terms for immediacy, some ways to think about online games.

Pitched immediacy: When lag severely impacts how well players can interact. Usually only matters in battles alongside or against other humans, although some battles are lag-resistant and some non-battle situations might be lag-vulnerable. Due to the difficulties involved with both technology and player awareness, the number of players involved in pitched immediacy is typically pretty low.

Critical immediacy: When players interact in near real-time while tightly bound together. Lag isn't a serious issue, but a player dropping out entirely for a few minutes would be pretty serious. This is typically the "party" part of the game, and may include lag-resistant combat sections. It may also include chatrooms and so on: it doesn't require avatar-on-avatar interactions. The number of players is often quite low due to cat-herding-related difficulties.

Noncritical immediacy: When players interact in near real-time, but loosely bound. If a player drops out, the other players can continue on without much difficulty - or perhaps without even noticing. This typically includes non-party interplayer dynamics, such as wandering around a town where other players are hanging out.

Asynchronous immediacy: When players interact in a way that has a flexible gap between action and reaction, allowing players to interact without being available at the same time or place. Please note this is about interacting with players, not with the game. Skills that grow in real-time, for example, are not players interacting with other players. Messaging someone is, and the giant forum accompanying any large game is also asynchronous immediacy even though the game itself is not actually involved.

Prepared immediacy: When a player doesn't have much (or any) control at the moment of interaction, but has set it up so that things unfold according to their preference. Things like auto-shops, guilds, homes that can be visited, and "NPCified" parties are all prepared immediacy. Creating content and then allowing other players to use/experience it is also prepared immediacy. Actually, drawing fanart or making music videos may also be prepared immediacy, even though the game is not really directly involved.

Incidental immediacy: When a player interacts with other players accidentally or indirectly without really meaning to. Auction houses are a big one, here. Maintaining wikis is another. Also, in some games you can create content that is automatically reshared with others (such as Spore). This "massively single player" style content is also incidental immediacy.

Anyway, those are my suggestions.

As you can tell, every game has more than just the game. The community around the game will start up asynchronous, prepared, and incidental interactions outside of the game itself. But these kinds of immediacies can also be part of the game design from the start.

In many cases, the feel of a game is easy to understand once you start putting numbers into these different tiers. Like in City of Heroes, you could argue that there are typically 1-6 players in pitched immediacy, the same for critical, but several thousand for noncritical immediacy due to the shared cityscape. Functionally, that "several thousand" is more like 80 or so due to the way the city is constructed and the way the servers are sharded.

Those are my suggestions. Let me know what your thoughts are.

Futurism, Google, and Careers

A lot of people have talked about what Google's purchases and recent direction mean. A lot of people have come up with things that make some amount of business sense, but personally I think that Google is run by people who believe in "the singularity".

Well, whatever the reason, Google's proposed product lines sound like a bad scifi movie: "Starting as a simple search tool, over the next thirty years Googdyne released universal translators, always-on augmented reality, self-driving cars, and military robots."

Whatever Google's vision of the future actually is, it's clear that they have one glaring gap in their plans: technology requires cultural infrastructure, and they're radically underestimating how much. For example, Google Glass is a pretty impressive technical feat, but it is basically useless in today's world. The only value it has is first-person video, and that's pretty limited.

It's easy to imagine a world where people use augmented reality quite frequently. In fact, that world makes more sense than this world. But the culture isn't there. People don't have any expectation or interest in that kind of thing, and it'll take a long time before we can drum any up.

It could be that they plan to sidestep this by making things so insanely useful that nobody can bear not using them - for example, decent web search. But I think they're underestimating that, too. They did it once, by luck, and now they seem to think they can do it on purpose. Well, good luck: cultural tech use weighs a lot more and hits a lot harder than most people think.

For example, the concept of a "career" - hell, the concept of a "middle class" - is something that only exists due to cultural use of technology.

This is one reason why I get annoyed whenever anyone says something like "is technology stealing jobs?"

The only reason jobs like that exist is technology. The issue is that the jobs it initially created, it is making easier and easier. In turn, that makes them require fewer people and people who work at a higher level. That's the way technology has always worked: make something possible, then make it progressively easier. In this case, "jobs".

Perhaps there will always be more jobs available to create, but that's a theory that falls flat in our current culture. We've attached ourselves to a specific point on the tech curve and are culturally out of position to deal with it changing.

Anyone who wants to invent the future needs to examine the present. The world is changing in a lot of ways, but humans are not.

You can give humans augmented reality, but if they can't use it to live their life, it's not going to get used. You can give people robots, but if it doesn't put a roof over their head it's not culturally relevant. Hell, you can give them life-saving vaccines and they'll get upset about it.

Self-driving cars, though... that's a keeper.

Player-Generated (Worlds)

The core problem with letting the users control how a generative world generates is how to make those generated worlds have meaning.

In most generated-world games, the world generation is a complicated weaving of content and algorithm that results in a carefully balanced, paced, and gated mess. Trying to change how the world generates will screw up the house of cards. Not just in the sense of things becoming too easy, but also in the sense of things becoming unplayable. Not only would you probably screw up the progression such that you couldn't advance, but you'd probably screw up things like whether the world is even navigable or survivable.

The default algorithm and content for generating the world comes up with millions of variants, but they all interact with the basic gameplay in a way which gives everything meaning. When you see a vein of iron above ground level, you get excited at the prospect of an easy score. When you hear PSSsssst you jump in terror because you know what's coming. When you go into a cave, it's been carefully sculpted such that most of it can be traversed on foot without extensive modification... but sometimes you'll stumble into a ravine which stuns you. That, too, has been carefully sculpted to contrast with the caves, which contrast with the mineshafts, which contrast with the mountain caverns, which contrast with the hills, which contrast with the desert...

Even in games which focus on beauty or relaxation, the worlds are generated with that kind of situation in mind.

What I'm trying to say is that allowing a player to short-circuit that design and substitute in their own preferences won't make the game better: it'll make the game worse. The balance will collapse. Even though you could surprise yourself by creating a world that is very different, the gameplay wouldn't back it up, except by rare accident. Worse, the act of screwing up the gameplay balance in a few of your worlds probably damages how accepting you are of the original gameplay balance.

Now, if you want to look at player-generated content, start by looking at things smaller than worlds. There are plenty of games where the player can build a wide variety of things... just not worlds. For example, in Minecraft you can build vast castles. In Kerbal you can build space ships. Even in more modestly customizable games such as the Elder Scrolls series, you can still build a very unique character.

The key in all these situations is that the gameplay revolves around building content to fit the context.

You don't just build pretty ships in Kerbal. You build them to go on specific missions in a specific universe. You don't just build castles in Minecraft: you build them to show specific people or to perform a specific function. In something like the Elder Scrolls games, your custom character is a mix of aesthetic options and stats, which fit into two different contexts (cultural and gameplay).

If you go into Kerbal and never launch any missions, designing the ships means nothing. If you go into Minecraft and just walk around without building, the layout of the world means almost nothing. If you remove combat from an RPG, your careful character design will feel flat. These things can still be entertaining from time to time, but it's not enough to support the game. The context has been removed or blunted.

It's the same with world generation. Normally worlds are generated in the context of the game rules to the point where there is one generation algorithm and it is a beast. Allowing the player to change that destroys the context of the game rules, and in turn makes the generated worlds almost meaningless.

There are plenty of ways for people to generate worlds and maps as they like, but unless they are placed in a specific context and given a specific application, there's not a whole lot of interest in those worlds. They're just pretty pictures.

What we need to do is think "why would a player create a world" rather than "how". "How" is easy. There are tons of ways, and even the bad ones work great. But "why" is harder. Why would the player need their own custom world?

1) One option is to tweak the challenge offered by the game. Allowing the players to alter the parameters of a game's challenge can be very entertaining if you build the game with that in mind. For example, a different amount of gravity, or lots of lava on the surface. Obviously, a world creation algorithm that's too tightly fit to the original challenges won't be able to support this kind of variation, but if you aim to allow this from the beginning, it should be possible. It also works well with multiplayer challenges.

2) The player may want to create something beautiful, interesting, or amazing, perhaps to share it with others. This is the "handicraft" world, which is interesting within any one of the game's contexts - gameplay, aesthetics, whatever. This is not about balance, but about astonishment. Therefore, allowing the players a lot of options in terms of theme control, arbitrary "stretchign", recursiveness, and so on can lead to some really interesting results.

3) The world is the gameplay. Rather than walking through the world (character as gameplay), the world is the gameplay. For example, you're trying to raise pet monsters, so you create a world and they grow across its surface according to the environment and mutations and so on. This method can be a lot of fun, but it limits the variety you can achieve because the world has to support the gameplay.

Well, I keep saying "world", but in fact this applies to literally any content. In The Sims, the players build houses as gameplay, and the sims live within them. The sims themselves are a combination of 1 and 2 depending on how much you care about the actual gameplay. I always cheat in that game because the gameplay is annoying, so for me they are only #2.

The real question is how deeply you can layer it. For example, in The Sims you can create your own clothes, facilities, and even meshes if you feel dedicated. And even if you don't, you can download them as mods and add them into your game. In Kerbal, literally half the game is mods. Can you let your player-created content merge with other kinds of player-created content on different levels?

Maybe that's where the "world" part comes in. Maybe the whole point is that the "world" is yet another category we can create content for, in, and with. Maybe the whole point of "creating" a "world" is simply that you are choosing which massive quantities of content you want to mix together today. Unfortunately, you'll need the foundations - the massive quantities of content to mix - first.

Anyway, the thought you should have when considering player-generated worlds is not "how", but "why". Once you know "why", the method will be pretty obvious.

Discovery and the Community

One of the greatest things about games to me is finding something new. In the past, that's always been something programmed into the game - a particular village or awesome plot point or whatever.

But what about games with infinite content?

Games like Minecraft and Dwarf Fortress were the beginning. Now there is an explosion of up-and-coming games that make them look like tinker toys. Starbound and No Man's Sky are today's flavors. Not only is there a massive amount of player-driven construction possible, but there's also a lot of content built right in. Content you will never see if you just play it as you like.

And here is where the trouble starts. How much do you guide the player? How much do you show them, how much do you let them discover on their own?

I want to explore. Telling me where to go, or that some other player was here before, ruins it for me. On the other hand, I don't like futile searches for some required doodad, and would prefer if you told me how to get it. And, hell, a lot of times I just want to see a video of something cool on Vimeo. Every player has different preferences.

In the end, right now, there is a crisp divide. You either know nothing and have nothing to do with the community... or you've read the wiki and know absolutely everything about everything.

In the future, this divide will not be crisp.

The community is starting to be integrated right into every game at the most basic level. Doing this clumsily can really alienate someone like me, because I like playing games alone for the first thirty hours. Getting constantly reminded that someone else was here first, or is running around screwing up the world on his own, that's a big failure in my mind.

On the other hand, there are tons of kinds of content that you need the community for, and even more that benefit from the community even if you don't absolutely require them. For example, the community will produce better tutorials than the game devs, and will show you how to build things the devs never thought of, although both could technically be accomplished without the community.

But giant cities built brick-by-brick or mods that add in completely new functionality are things that no player will ever be able to see without reaching out to the community. There's no question that the community makes high-level play a million times more interesting. The question is: can you get a player involved in the community without destroying the low- and middle-level experience?

For example, in Starbound I can't find a "molten core", which means I cannot progress. There's nothing in the game that tells me what one is, or if there's any other way to progress. So I'm going to have to go to the wiki and read up on it.

How much effort will it take to get just that one piece of data? When I'm there, won't I feel the urge to look up how to make those musical instruments, or read up on the seemingly-useless lever item, or how to use the 3D printer? It's incredibly difficult to not get sucked in. And if I do get sucked in, I'll go back into the game with high-level knowledge short-circuiting my low- and medium-level play. A lot of the joy of exploration will be gone, because I'll know the parameters of the universe.

Similarly, if there's a game where community content is automatically shared into the single-player experience, it's easy to drown in it. That was the real weakness of Spore: content overload. Even in something like No Man's Sky it's a risk, because there's probably going to be a damn popup with the name of the first person to discover whatever planet I'm on, completely ruining it for me.

So... I guess I'm telling devs to be careful. Integrating your community into your game is a great idea, but you have to be careful to let it leak in slowly, in tiny amounts. Augment your game with community content, but don't make your game 100% about community content.

... Also, don't tell me that I'm doing something hundreds of other people already did. That's really dumb.

Many Characters Forgotten

So... playing another tactical RPG. Yyyay. Technically, this one's an action RPG with tactical elements, but that's a flaw that I'll just have to see past.

I really like tactical RPGs. While scifi is the setting I'm obsessed with, I'd say that tactical RPGs are my genre of choice. I haven't designed any in a while, because it's arguably the genre Unity is worst at.

Today I suffered the same problem with this tactical RPG that I always have: they keep introducing interesting (or potentially interesting) characters, but I've already settled on a party and don't need them. This is made worse by knowing that even if I ditch an established party member for the new guy, the new guy's personality won't show up at all. They're just bundles of stats.

FIXIN' TIME.

We want our characters' personalities to matter at the heart of gameplay, and also to push the player to try a wide variety of parties with a lot of different characters. So their personalities need to drive their conflict performance, the way they interact with the world in the core play loop. I'm avoiding the term "battle", because it's actually much easier to do this with a noncombat set of conflicts.

Let's consider the way personality can matter.

The first way is that the core type of the personality can drive interaction. For example, a stoic person and a hyper person would approach a situation from very different angles, and get a different kind of result. This is similar to choosing a technique or move set for a combat class.

Another way is that the mood of a person can drive the interaction. Someone who is stoic or hyper doesn't address the situation differently, but instead feels different things as the situation grows. Those emotions drive their actions, rather than their fundamental personality. This has the disadvantage of being a bit hard for a new player to master, but the advantage of being a whole lot more flexible, tactically speaking. How much of a time delay is required to change moods is a design point: it might be an absolutely immediate response, very similar to how personality alone would work... or it could take longer than the whole battle, requiring careful mood management between conflicts. Or, of course, any length between.

Speaking about time as a matter of importance, we can also talk about not having a single monolithic "personality". Instead, think about it as a series of personality elements. For example, stoic-stoic-romantic, or hyper-lazy-motherly-lazy. Every round, the cursor moves to the next personality element. This creates an ongoing pattern where the overall mood is affected by the current personality element's response to whatever is happening this round. This adds complexity, which means we would necessarily have slower conflicts with fewer participants, but that's not necessarily bad. Differing chain lengths leads to drift, keeping the various participants subtly desynched.

We can also create complexity by layering it. For example, we might layer downward. Below the "stoic-stoic-romantic" might be another set of personality elements. Maybe "romantic-depressed-lazy". In the course of the conflict, you might strip away the surface personality and the one underneath would surface, in which case they might be romantic-stoic-romantic or stoic-stoic-lazy or whatever. This could be considered "damage" if you like, and the way to "win" or "lose" might be to get that lower element stripped away, leaving you unable to properly respond.

We can also layer "upward" or "inward", adding a layer on top of an element, or slotting an element between two elements. These temporary personality elements don't really reflect the fundamental personality of the character, but it is an interesting idea.

At this stage we're still talking as if the conflict will be some kind of winner-take-all battle, with talk of stunning the enemy's personality or forcing them to react a different way. While that may be completely feasible idea, let's also think about what the goal of these conflicts could be. Why would you want to stun the enemy until they are unable to argue against you?

The first thing that springs to mind is that you're deciding something. For example, there's a town meeting and everyone is putting up plans about how things are going to change. The supporters of two conflicting plans argue. The argument is partly about forcing your opponent to see your side and be unable to support their own plan, but the other part of the conflict is convincing the audience that your side is right.

This merges very well with the rest of my design idea, which requires that a steady stream of new characters come in without being simply discarded in favor of your established characters. You're not running a party: you're running a town.

There are no villains, really. Just people who have different visions for the town. On any given day or week, two or three plans will be proposed. The plans always conflict, so you will have to side with one of the teams proposing your favorite plan... or perhaps with the one you don't like, in an attempt to sabotage it.

These will change the nature of the town, surely but steadily. New people will trickle in, and they also find themselves in favor of specific plans, showing up in your weekly town planning meeting. The town itself exists, of course - this isn't happening in a vacuum. If you vote to expand the fisheries, then your town docks will expand, and you'll probably get a few fishermen as immigrants. If you vote to expand the space docks, you'd get more ships landing, and more transient sailors on shore leaves... etc, etc.

However, the town meetings are analogous to the "battle" segments of the game. There would also need to be a lot of between-battle gameplay. And I think this system could support a lot. Ideally you could wander around town as any character, talking to people, chasing sidequests, buying and selling furniture and clothes and stuff, searching for secrets, learning new skills... all the sorts of things you do in RPGs. Plus any multiplayer you may or may not have.

This would help to cement the characters in your mind, as well as allow you to customize them in small ways and feel invested. However, it also allows you to set up the situation for the town hall meetings, because you can get a feeling for what plans are going to go down and who will support what. Then you can attempt to set up certain people with advantageous starting moods, or maybe get other people to take a vacation out of town. Maybe you even start a preemptive argument among someone who is on the fence to get them to join your team in the debate. People's stats will be better the more debates they've had alongside these partners, which is the way you do leveling...

Of course, when it comes to the meeting, you'd have to choose which three of the support characters you'd like to take into the debate, and then juggle them as the conflict goes on and moods slowly shift...

Well, I dunno if it'd be fun, but I think it's an interesting idea.

Claustrophobic Gameplay

I've been thinking about small, dense worlds for gameplay. Most games scale up, I've been thinking about scaling down. A good example of this approach is any game set in one (large) house, such as Maniac Mansion or Gone Home. Of course, me being completely obsessed with scifi means I'd probably think in terms of one small moon base or something.

Most of the time, in games with small spaces, the gameplay is simple puzzles. Pick up A, B, C, twiddle D, insert into E. Classic adventure game stuff. But why? Can't we do other kinds of gameplay?

It's a matter of how long the game can be. In general, you can think of the length of the game as being the density of the space times the size of the space. It's relatively easy to create more space, so most games use larger spaces. Games like Go and Chess have small, static boards and are about as dense as you can get, and still they are rarely more than a few hours long.

Some games use space densely, but still switch it out. For example, a tactical RPG where every meter matters, but you keep getting thrown into new maps. So they have both density and size, and this is reflected in their typically extraordinary length.

Anyway, adventure gameplay can be made extremely dense because it is polymorphic. That is, the same things mean different things depending on what else has happened. The kitchen has a microwave? That's not interesting at the moment, but it becomes interesting when you decide to microwave something as part of a puzzle, or need to unplug it and use the plug for something else, or carry it to the window and drop it on someone's head far below... there's a lot of things it could be used for, depending on the context. By changing contexts continuously, adventure gameplay pushes the play density way, way higher than other genres typically go.

Of course, there are many ways to change contexts, and you don't always need to be adventure gamey to do it. Katamari Damacy is a fun example of simply using size as context, and a single house ends up having many different gameplay paths depending on where you start and how large you are. They attempted to double this by adding in new modes, such as collecting hot items only, but in my opinion it didn't work very well because the whole setup was engineered with size as the primary context, and using other contexts ends up awkward.

I'm more of a Katamari sort than an adventure game sort, so I got to thinking about physical gameplay that changes context, rather than puzzle gameplay.

One aspect I like is the concept of size changing how you interact with the setting. However, rather than a destructive interaction, I started thinking about a navigational interaction. At its most basic level: you can only go through certain places if you're small enough or large enough, due to the layout. But more than that, I want "going through space" to be actual gameplay, not just a simple act of navigating. Like a free running game but upside-down.

For example, let's say there's a narrow space. If you're tiny, you can just go through fine. If you're human-sized, you've got to scoot through sideways, holding your breath. If you're in a space suit, you can't get through... but you can stick your arm through. If you're a quad-copter drone, you've got to flip vertical and float through on pure momentum. That sort of thing.

There's also the matter of gravity and rearranged rooms. The same physical space could be laid out very differently depending on which direction gravity is coming from, or if there's gravity at all. Even the difference between lots of gravity or small amounts of gravity can change how you might navigate a space: with low gravity, leaping and climbing walls is easy. In high gravity, you're stuck to the floor... but you can exert a lot more force without spinning or bouncing, so there are times you'll need that. And, of course, various kinds of obstacles might squash to the ground in high gravity, which can be important.

Back on the subject of topology, I was thinking how to make the layout result in complex gameplay. Simply gating the environment with spaces you can or can't navigate depending on your size is too basic. But I've already mentioned a path to a solution: the ability to stick your arm through.

It's not just your size which matters, but also your flexibility and reach. There are many places a human can't squeeze through, but they may be able to get their arm in, or even crawl in until their butt gets stuck or whatever comical situation you'd prefer. This gives them a certain amount of reach into the restricted space. Combined with a long stick or a bit of wire or something, this could in turn support some more gameplay. A nonhuman of roughly the same size as a human (say, a cargo bot) would not be able to do that.

I like the idea of force being useful. Even if the cargo bot had an arm capable of reaching through the slightly-too-narrow space, it is not a soft device and if it is pulled through by force, it will rip apart. Humans can squash a bit, especially if you play fast and loose with biology. This means that they might not be able to simply slide through, but if they could get their arm to the other side, or grab ahold of something, they could force themselves through. Maybe you use a robot to drag a piece of debris over so you can grab it and pull yourself through... There could be some kind of damage meter or something if you want to make it cost more than time.

But how does this turn into gameplay? I need to make this a game which is interesting, and simply moving through space arbitrarily ain't gonna cut it.

I'm thinking of a "compact roguelike" - a small space station where the point isn't to move on to the next level, but to backtrack across the same rooms while changing their conditions so you can get something done. There would be a pretty loose set of conditions so you could approach it in a variety of ways - this isn't a puzzle game with only one solution. Similarly, the passage of time is often critical, so moving confidently and sleekly would be very valuable.

Balancing your human form, space-suited form, and a variety of remote operated robots would be the key, and a big part of the early game would be finding the places where you can change into a space suit or find and pilot various kinds of robots. A lot of the rest of the early game would be about figuring out what systems can be changed in what way from what locations to change the way the space station is navigatable - gravity, pressure, heat, wind, light, doors that lock or unlock, etc.

But in terms of movement, it's still a bit lacking. I really want movement to feel explorative, not just transitionary. I don't want the player to wedge themselves through a door just to get to the other side. At least, not while counting it as important gameplay.

To get the explorative movement I want, it's important to make the player have to explore constrained spaces "dark" - that is, without a clear idea of exactly what is coming down the line. This means that doors are only valid in terms of whether they are open or closed. So rather than simply exploring from room to room through doors, it's important that we have some very different paths to use. Which means our space station is built a bit unlike most game's space stations: the player will need to spend a lot of time in air ducts, crammed between walls, above ceilings, below floors, squeezing between endless computer pillars, clutching to the underside of walkways, flailing in midair in the wind of the climate control's main pipeline...

In addition, we can rely more heavily on rubble and debris. Collapsed ceilings, desks and chairs piled up against the door - anything to make navigation more difficult while simultaneously connecting the outside and the inside of the rooms. Vents and Jeffrey's tubes would abound, as would elevator shafts and so on.

There are two keys to making this interesting. One is to insure that the paths are never completely linear: the player always has something to actually explore, not just a corridor to squeeze down. There's always a challenge of whether you can turn and squeeze through a side passage, or navigate around a structural beam or something.

The second is to insure that there's always gameplay. When you crawl into an air vent, the standard movement gameplay would be "press forward to go down the air vent". However, this is a pretty dull thing to do if much of your gameplay involves crawling down air vents.

Fortunately, the first thing rescues the second thing. To make it so that there is open exploration in tight quarters, one of the things we'll end up doing is creating a lot of awkward, angled paths off the main path. The challenge is to go down them - not something that is easy, as you know if you've ever been in that kind of situation. The human body only bends in specific ways, and in a confined space even turning over is frequently impossible.

The gameplay needs to be fast enough that you never feel annoyed about the slow movement, and the best way to do that is to make the restrictions not about speed, but about orientation and flexibility. Therefore, the controls are not simply "push forward to go forward", because we want to allow the player much more control over how they are bent and pointed.

There's a lot of question as to what kind of interface would work best. Perhaps simple WASD with QE rotation is best. Perhaps a mouse-centric interface where you click on specific surfaces. Perhaps you do some kind of split interface where WASD controls you, but if you hold control it controls your hands instead of your legs. Lots of options, but all the options have to work well when in confined spaces or in the open, when a human and when a quad-copter.

You can also add a lot of complexity to the basic design. For example, having an inventory that actually exists in space, so it changes what you can go through and you may have to take off your belt and throw it through ahead of you. Or having a button to exhale and stay exhaled, so you can squeeze through smaller spaces... but after a little while you're going to get lightheaded, so be careful not to get stuck someplace where you can't breath! Also useful if the atmosphere has been contaminated someplace.

Anyway, just thinking about it. It might be an interesting game.

Sci Fi Navy Terminology

One of the difficulties in creating science fiction worlds is creating a naval setting. Starships are incredibly critical in most science fiction settings, basically replacing trains, ships, and airplanes all in one go.

In most cases, I'll have some idea of how the universe works - a specific set of technologies, a specific kind of culture, that sort of thing. But when I was a bit younger, I had a really hard time putting things into a reasonable military (or pseudo-military) structure. This is because whenever anyone talks about navies, they talk in exceedingly specific terms and concrete examples. I needed general information, and they were drowning me in trivia.

It came up again this month, with a new setting I developed, so I figured I'd go ahead and write a bit about the naval terminology and structures I tend to use.

These aren't really based around any real-world navy, but they are feasible enough and flexible enough to form a scaffold. Obviously, if your starships are so rare that they never form into fleets or task forces, this isn't necessary.

First off, I start with a very quick overview of how shipping works. The reason for this is because military vessels will usually have the same spectrum of sizes as shipping vessels. This is for two reasons. The first is because you build the space frame sizes you're comfortable with, and the second is because it's hard to supply ships that are larger than your supply ships.

If your planets are largely self-sufficient, then there won't be any ultra-heavy space trucks. In turn, that means there won't be any death stars. On the other hand, if you need to ship massive quantities of food and metal, you're going to have massive military vessels. The bigger the freight requirement, the bigger the biggest military ship.

Similarly on the small end. "Space fighter" is a pleasant thought to most science fiction authors, but it only makes sense in settings where there are civilian uses for a tiny interstellar ship. Because of this, I tend to only use fighters in settings where there is no FTL radio - the small ships are essentially messengers. Obviously, you can go against this rule if you like, but I find it makes more sense to follow it.

Similarly on the fast versus slow. Do you have "jet liners" for people to travel from star to star, or are they more like "ocean liners", taking weeks or months? Well, the military's gonna have the same kind of preference, taking into account their additional need to keep an active presence in a given theater for months at a time.

With that out of the way, you can begin to think about the kinds of combat encounters that might crop up, and begin to think about the kinds of ships which fit the role. In general, the terms used by real-world navies are pretty adaptable. You might get looked at a bit funny initially, but once it becomes clear that the role is warped by the technology, the players will accept that the real-world name still fits okay.

Now, I can list a bunch of kinds of military operations you might want to have - for example, orbital domination (requires a vehicle that can deploy and control thousands of satellites) or blockade running (requires vehicles that can stealth and vehicles that can detect that). However, the encounters you want in your world will shape the world you build.

Not every setting has blockade running. Not every setting has orbital domination. Not every setting has mines. Or drop-pods. Or interdiction. Or even carriers. It all comes down to the kinds of battles you want to happen in your setting. You can always retroactively add more if you feel the need.

The key is to identify the kinds of scenes you want. Do you picture marines rushing out of a smoking drop pod? Do you picture bombers harassing a burning supercarrier? Do you picture a destroyer floating above a frigate, pulling it in with tractor beams? The vivid imagery you have in mind will immediately tell you the kinds of ships you need.

Then it's just a matter of giving that class of ship a vaguely suitable name. For this, you can read up on military classes like "destroyer" and "battleship" and so on, but remember that those are typically roles not sizes. For example, a "destroyer" isn't defined by its size, but by its role as an anti-submarine escort to larger ships. A "cruiser" isn't "bigger" or "smaller" than a "destroyer" - it's a vehicle that's built to operate for a long time unaccompanied.

By these rules, the Enterprise of Star Trek fame is a cruiser. See?

You could also just invent your own names, of course. Don't know what class the psychic vortex ship is? Just call it "psych-class" or whatever.

Anyway, that's how I do starship design in scifi settings.

Characters that Push and Pull

Recently I've been developing a lot of prototypes that have characters in them. In creating various kinds of gameplay, I've noticed something interesting. I've been trying to come up with a short description of it, and here's my best attempt:

The more a character forces the player to adjust to the character, the more the character feels like an interesting person.

This is a bit of an unsupported statement if I just let it stand, so let me go into a bit more detail.

I developed two Power Rangers ripoff prototypes. In the first one, you controlled the heroes - told them which fights to fight and gave them turn-by-turn orders. However, because the rangers were basically faceless spandex stuntmen, they didn't feel like people. The monsters ended up feeling significantly more interesting!

The second prototype I created was about supplying the rangers with gear. You didn't get to choose their fights - they showed up, told you what enemy they were fighting, and you had to decide which equipment they should take into battle and how quickly to make their robots available. The equipment wrangling was actually kind of interesting, especially the robot side, since every new system you attached took more prep time... but a surprise side effect was that the heroes ended up feeling like characters. Although their traits and behavior were both simplistic and largely random, it was very easy to start to empathize with them and their efforts.

I think this was due to the afterbattle briefings I put in. You could debrief a ranger and it would show how well the various pieces of equipment and systems performed in the last fight - a necessary method of getting feedback. In turn, you would be able to refine your loadout so it would be better next time. In the background, the other four rangers would chat while you did this - randomized nonsense driven by their three traits. It made them feel surprisingly alive while also giving you information about what kinds of gear and systems you might want to give them (to match their traits).

Struggling to adapt my gameplay to the characters made it important for me to understand what the characters needed, statistically speaking. In turn, they became interesting characters to me, even though they were randomized nonsense in reality.

The Sims showed this to the extreme. While you do control your sims to a large extent, you spend a lot of time trying to rearrange your world to perfectly suit their needs. And, of course, people got really into it, even though the sims' "personalities" are basically randomized nonsense in reality.

You can even see this in things like Half Life, where the most popular character is the woman that leads you through a few tutorial sections. She's interesting not because she has anything valuable to offer, but because you have to play by her rules for a while. And, importantly, it's not just an escort mission: an escort mission is not about adapting to the character, it's about treating the character as a thing.

I'm sure you can see a lot of other examples, including perhaps partially explaining why boring villains (such as Sephiroth) become so popular.

So now I'm thinking about a whole slew of possible games where the point is to integrate well with characters. Hm!

Droning Misconceptions

When Amazon announced their drone delivery experiments, my Twitter stream filled with people who made incredibly misinformed comments. So, uh, I made this FAQ about basic stuff so that nobody ever has to make uninformed judgments ever again. There, that's that problem solved.

I guess it's not a FAQ so much as a FMUSS (Frequently Made Uninformed Snarky Statement).

Q) Amazon is doing drone delivery!

A) Well, technically they're looking into Quad Copter Remote Operated Vehicle delivery systems, which is technically not... well, okay, the word "drone" is damaged beyond resurrection, so sure, they're drones.

It's uncertain that the technology exists to do this just yet. Personally, I don't think it's ready. But, yes, Amazon's apparently looking into it.

Q) They should just pay people to deliver!

A) This is wrong in two ways. First off, they are paying people. These are not fully automated, they're semi-automated ROVs. An operator can probably fly several at once, but they're still going to have to pay pilots. And mechanics. Fucking tons of mechanics.

Secondly, humans literally cannot deliver in this manner. There are no humans that can fly through the air to deliver a single package. The closest we might be able to do is motorcycle deliveries, which are dangerous and slow in comparison.

Q) They're going to fire all their delivery staff!

A) This is a short-range small-parcel delivery service. Quad copters cannot go far, nor can they carry heavy loads. This cannot replace their ordinary shipping.

Eventually, it might. Automated/ROV trucks are on the horizon. You can get upset then.

Q) Free Amazon stuff if you're a good shot, HUR HUR HUR

A) This was the one that made me quit Twitter for the night. That anyone retweeted it boggles my mind, because it's so badly thought out it makes no sense.

First off, these are deliveries in an urban area. Are you planning to fire a rifle in the middle of a city? HUR HUR HUR

Second off, these are short-range deliveries, meaning that another drone will be by to see what happened to the first drone before the cops could even arrive.

Third off, they have ground-facing cameras, and will almost certainly be able to see muzzle flashes. Even if you took one down, they'd probably know exactly where you shot from.

Fourth off, these are unscheduled deliveries. I'm unsure how you'd be ready to shoot one.

Fifth off, they have on-board GPS and constantly-streaming audio video. Unless you knock those systems off-line, they'll certainly be able to see anyone who comes by to visit their downed drone.

Sixth off, if you want to be a moronic criminal, just rob houses. You're less likely to get caught and the payoff is far greater.

Q) Amazon is evil! They shouldn't do this!

A) Yup, they are evil. But, uh, that has nothing to do with using drones.

If ROV tech is ready to hit prime time, then it's going to hit prime time. Amazon might be the first adopter, but it hardly matters who does it first because everyone will follow. It's like smart phones - it took a while for the technology to arrive, but when it did, smart phones became dominant in a flash.

Personally, I don't think the tech is ready, yet. I think the tech is only at the level of murdering civilians at $10,000,000 a hit, which is not Amazon's typical business model. But it'll be interesting to see Amazon's experiments.

Play in vs play through

These days, I see a lot of games making the same mistake. I think this mistake is only really possible because of changes in technology, because I'm sure it would have been made decades ago if it were possible back then.

The mistake is trying to be cleverer than your players.

This is a difficult thing to discuss, because in nearly every case you are actually going to be considerably cleverer than your players. Not because of any innate cleverness or stupidity, but simply because you can see everything and have spent a lot more time on it. So there is an urge to leverage that.

But it never works out. In trying to be cleverer than your players, you inevitably end up being annoying. Instead, try to be clever with your players. Instead of getting in front of them and showing off, get behind them and push.

The simplest example of this is the concept that you need to "punish" your players for playing badly or wrong. That's not a very good concept. Players never need to be punished by you. Ever.

Players do need a system of reward and punishment, failure and success, yes. But here's the thing: it's not you, the designer, that needs to punish or reward. Instead, think of your job as helping the player figure out how the game rewards and punishes.



Let's start giving examples!

In Rune Factory 4, along with many other games from Japan, the game is structured with a simple save point system. With saves before every boss, the game is obviously intending for you to try the boss again and again, loading from the save until you get it right.

But the developers of RF4 have decided they should "punish" the player for "failure", so instead of asking you to load a game when you die, they resurrect you back at town. For a huge fee. This is an inferior option in every circumstance: not only does it move you out of the deep dungeon, it also costs you time and money. You start the game with an "escape" spell that can get you back to town instantly anyway, so there's not even any advantage to that aspect of it. It is simply a punishment that the developers have decided to inflict.

To try to force you to accept their punishment, they actually remove the "load game" option from the game. You can only load from the title screen, and there's no way to quit to the title screen. Unfortunately, the punishment is so severe and runs against the grain so badly that you'll end up force-quitting and rebooting the game to load it like you intended.

Now, the problem here isn't the punishment itself. A punishment for dying is fine, but it needs to be part of the structure of the game.

For example, in any given Mario game, you certainly die. And there is a punishment - starting from the checkpoint or even getting kicked out to the world map. This does not make Mario hardcore or difficult. It's just a failure or success built into the structure of the game.

Moreover, the developers are always careful to try to set you up to understand how the punishments and successes are going to arrive. Challenges are often predated by an earlier "prep" challenge of the same type but less difficult or lethal. Rewards are set up so that you almost have to get them the first time you see them, just so you understand that getting them results in something good.

In games which are difficult, such as Kerbal or Dark Souls, failure is often quite stark and punishing. But the structure of the game revolves around that. The game is hard. The developer is on your side - even in Dark Souls, the developer is on the side of the player. Always dropping little clues, hints of what challenges await, the resources you might need. In Kerbal, the developer is more hands-off because there's not really any level design, but the forgiving "revert to launch" function essentially allows you to undo any mistaken missions.

That's how you design a game. The game rewards and punishes. The developer sides with the player against the game.

It's certainly possible to take it too far. For example, I recently tried to play a Mario game on my 3DS and found it to be unplayable, because every time I died a few times trying to get a particularly difficult collectible, the game would force me to take an infinite-flight invulnerable coin-creating tanuki suit.

This goes beyond siding with the player and straight into destroying the entire game. This would be like if you died 3 times in Dark Souls, it gives you the ability to fly and invulnerability. It subverts the structure of challenge, reward, and punishment. That's bad game design.



Here's another type of example:

There's a fair number of games where the developer obviously takes their game quite seriously, and seems touchy about letting the player goof off or be silly. If the player tries, the game punishes them.

Take something like COD Ghosts. If you stop for a moment to look around, you fail the mission. If you walk the wrong way, you fail the mission. If you interact in the wrong way, you fail the mission. The actual structure of the game doesn't contain any of these punishments: fundamentally, the only rewards and punishments built into the gameplay are those of shooting and getting shot (or sneaking and getting caught, etc).

But the dev adds in all of these additional restraints, either because they are completely full of themselves or because they think the player is deeply, deeply stupid. Well, whatever the reason, the result is that the player is not allowed to play in the game. They are only allowed to play through the game.

Contrast this to a game like Mass Effect. ME's missions are just as confined, but the confines of the mission are built into the level design - they are part of the structure of the game. You very rarely run into any arbitrary "you fail!" conditions. In turn, this means that all of the Mass Effects were entertaining to play in rather than just play through. Halo was like this as well.

If you want to experiment with grenades, go ahead. If you want to stack your party members on top of each other until they resemble a monster with four arms and four legs, go ahead. If you want to try to take on the whole mission with just a pistol, go ahead. The developers are on your side: if you come up with something you want to try, they go "oh? Sure, go ahead!"

Not only does this freedom allow players to play in the game, it also allows players to create new kinds of play - such as beating the game solo, or with an all-biotic team, or never equipping any armor, or whatever.

Now, Mass Effect comes with a huge amount of dull, pre-scripted content that it forces you to push through. All the renegade/paragon options, the badly written dialog with obvious endings, all that stuff is not really gameplay. It's the same as COD Ghosts' restrictions.

So they added in triggerable events - renegade or paragon interventions which radically change the flow of the conversation. And even though these, too, are carefully pre-scripted, they really spiced things up. Why did that work?

Well, the whole conversation thing was sculpted so the player would think of everything in terms of paragon or renegade. So when the conversations got sluggish, the player got annoyed and knew they were just going to choose paragon or renegade and impatiently waited for the chance to choose. The flow of conversation was extremely predictable and dull, and the choice was extremely predictable and dull.

The devs heard the players and let them express themselves much more quickly with these paragon/renegade action cues. The devs took the player's side to help them within the framework of the conversation. In doing so, they actually improved the conversation mechanic dramatically: now the flow of the conversation was always spicy, because the player knew that at any moment they might get the option to kick it in the face.

The conversation mechanic is still pretty dull, of course. The actual amount of player agency is pretty low. But it's way, way better than just an endless conversation tree.




Side with your players. Help them play your game in the way they want.

Motherships

Let's design another space game! There's so many options. This one is about building starships for multiple phases with multiple nested vehicles - like Kerbal, but instead of discarding earlier stages, you use them as motherships.

The game's most core activity is definitely travel. Travel from star to star, planet to planet, moon to moon, continent to continent. Although there are fuel constraints, the fuel constraints are not the focus. Instead, the focus is on different types of travel and the hazards associated with them. In general, traveling doesn't require a tremendous amount of effort, and time acceleration can be used to make it pass more quickly, but the hazards involved can require some careful planning or intervention.

For example, a particular star might throw out massive amounts of radiation. In your mothership this isn't be a problem - the way the saucer hull is designed specifically protects it from all sorts of radiation. But in a landing craft, your heat will rise rapidly. There are a lot of ways you can deal with this. Design a ship with good cooling. Land on the dark side of the planet. Have a coolant system which can be discharged to cool you down but uses up some amount of coolant to do so.

Combine this with a much wider variety of planetary difficulties - active volcanoes, sand storms, liquid methane clouds, acid atmosphere, science to do on the bottom of the ocean... some are planet-wide, some are biome-wide, some are system-wide. All require you to plan your missions a bit more carefully, especially since the way the rewards are structured will push you to visit as many different planets and biomes in one trip as you can manage.

Piloting vehicles is the "core" challenge, but there are three other play elements which crop up, all of which use the same mechanic. These require me to explain the camera:

This is not a proper 3D game. It's a 2D game, with very simplified spritework. Not pixelated, but more like simple vector art. This means that the camera can be zoomed and panned, but not tilted. So your mouse cursor doesn't control the camera in any meaningful way. Instead, the mouse is used to interact with the screen. Because the ships are designed in a psuedo-2D, no element of the ship is ever completely hidden by other elements, although obviously a cross-section must sometimes be shown in order for you to see through the outer hull of something like a saucer.

So you can easily click on specific elements of the ship.

For something like our coolant system, you could click on it to discharge coolant, PSSSH. Right click for a single large coolant spray, or left click and hold to continually spray until you are cool enough by your standards.

This same method can be used for many other kinds of interaction. For example, if you click and drag on a satellite dish, you orient the dish towards your mouse. By gently tweaking the exact orientation, you can "tune" for a precise connection to other dishes you've installed in the system (or even between systems). This is shown via a static-covered icon of the target you're connecting to, so you can both choose a target and fiddle to try and clean up the static.

Something like a robot arm no longer needs to be painstakingly controlled joint-by-joint. Just click and drag to move the arm around. Want to dock? Get close, then click and drag your docking port to either extend an umbilical or allow autopilot to take over and line you up.

You can also use this method to draw resource flows and circuits, remove or attach modules, and so on. Just click and drag, or just plain click to activate. Some of these will be things the ship needs to deal with hazards or day-to-day operations, others are ways to fine tune interaction between the ship and the nearby universe.

So the three play elements that use this method are:

Ship management. This includes things like coolant, turning on or off various expensive systems such as labs, accelerators, hydrogen harvesters, etc. With these, right-clicking typically does a quick burst or toggle, while left-click-and-hold cycles it for as long as you hold the button. This is also important for deploying or drawing components, such as setting up land bases using local regolith or inflating a hab module.

Intership management. This includes docking, grabbing things, moving modules or resources from ship to ship, connecting beams or antennae - anything where a click-and-drag allows you to specify a target ship, ship component, or world.

Non-ship management. This is when things that aren't mapped to a ship module show up on the screen to be interacted with. These are usually HUD elements which are only on-screen when you activate a module that has complex interactivity. For example, a fleet command module will show pictures and status on all active vehicles in the area, and you can interact with them in basic ways by clicking on their icons. Similarly, this is how you program a flight computer or designate duty cycles with astronauts.

To facilitate the need to travel from place to place, a large part of the game features resources that can only be created or used in specific regions, and therefore have to be transported. This could easily involve all four kinds of play. Travel, obviously, to pick up a resource from a ground station and carry to the mothership. Ship management, to turn on the processor for that resource when you need it, but not leave it on eating fuel when you don't. Intership management, to reach out and grab the resource, then load it into the transport bay. And non-ship management, to receive an alert that the ground base has finished production of that material.

You could also do the whole thing while cutting those away. For example, you could use a mass cannon to fire the resource without needing a transport ship.

You could also do the whole thing by leveraging those significantly more. For example, recording the flight profile of you fetching the resource, then simply dictating that the flight computer do the flight for you the next time, playing it at 100x speed.

There's also no particular restriction on how you do it in the first place. Maybe instead of a base and a mothership, you just have a saucer that lands, processes materials from the ground, then launches into the sky and does the orbital processing, all in one ship. Of course, that means you have a very large, complex ship, since each of those steps is fairly large. The advantages you could have gained by having two stationary ships is that you could deploy very heavy or fragile extensions knowing those two ships would never need to move again. If you have to pack it into one ship that has to move, you have all that weight and required reinforcement loaded into one chassis.

This also has the added benefit of pushing the player to include several different classes of vehicle in the same mission, beyond the simpler "visit A then B" ship designs they might have defaulted to.

Combined with a tech tree to make the various components and sizes come out in a lumpy fashion, I think it sounds like a fun game.

Anyway, that's it.

Tailored Spaces

So, Unity now supports shape keys. This is really good - previously, it was a bit of a chore to get them working. I've started to create all sorts of keyed assets - for example, beds and chairs which dent like real cushions when you sit on them. Not using physics, but just using shape keys and knowing where people will sit/lay down.

All this has brought me back to one of my biggest difficulties: designing interior spaces. I've started to take it on, so I'm toying around, creating all sorts of rooms and assets just for fun.

My problem with designing interiors stems from my extremely long history of graph-paper dungeons. I think in grid tiles viewed from above. All the games I used to play were based around tiles and turns, so those kinds of maps were ideal.

But in a world with 3D and a real-time situation and a controllable camera and walking up and down stairs and... well, the grid is very obsolete. There's a lot of interesting layouts to explore with looser restrictions, vertical regions, and non-right-angles.

In the end, it comes down to how the player (or other in-game thing) interacts with the world. And now that I've started to understand this, I've started to come up with some reasonably interesting ideas and layouts. This is really helped along by the ease of creating super-interactive/adaptive settings thanks to the immense power of modern computers and the ease of middleware like Unity. The environment can adjust in tons of subtle, passive or active ways.

The difficulty is how this interacts with gameplay. Lara Croft's mansion has beds and chairs and all sorts of other things in it, but they're just passive, noninteractive pieces because there is no gameplay to be found in using them. The gameplay in Tomb Raider is about going from point A to point B, often over difficult terrain. Laying down for a bit or having a sit... not part of the theme. So in Tomb Raider, the internal spaces are designed to interact with your attempts to go from A to B, with setpieces added in for flavor.

This is not quite as simple as it sounds. A to B can be made challenging or simple in a variety of ways, sure, but there's also all the meta stuff. You might design this area so it overlooks another area you'll be reaching soon, giving the player some anticipation and a chance to plan ahead. Or it might be all tight, confined, opaque spaces until - surprise! - it opens into a massive new challenge... there's lots of things that affect how you create your levels, obviously.

But, in Tomb Raider's case, the core of interactivity is running and jumping. Fundamentally, running and jumping is not how we normally use interior spaces. If we want to design internal spaces where the furniture matters and the layout can be a bit cramped, we need a completely different kind of gameplay.

Anyway, just thinking out loud, but here's a simple idea for a game with a kind of gameplay that allows for dense internal spaces:

You're a tailor. Your job is to make outfits for adventurers who are trying to integrate back into society. As you might expect, the gameplay is primarily about planning outfits, with a secondary focus on finding the resources you need for those outfits. This can be quite complex due to the wide variety of social and physical situations each adventurer can be in.

The obvious way to do the gameplay is menu-based - pick X cloth, Y blueprint, assign it, etc. That is, after all, what you're doing. But when the gameplay is so heavily mired in setting color and social norms, it makes sense to make the outfits you create feel real, and the people you create them for feel compelling. Therefore, let's presume we set the game inside our little shop.

How do we design our shop to be compelling? Well, it has to present our world, and our gameplay. Of course, in terms of functionality, there's not much needed. At most, we map specific furniture to specific menulike actions. The shop is not to enhance gameplay, but to enhance feedback. Our shop needs to make the world and the people feel real. Therefore, there are a few objectives:

1) Highlight the personality and body type of the heroes. This can be done by allowing them to wander around and interact with things. A huge warrior would constantly hunch over and scoot sideways, where a tiny gnome might bounce energetically from thing to thing. Therefore, our shop needs to have a lot of things for adventurers to do while you're designing clothes - when you're selecting stuff and trying variants, they're passively wandering around reading things, eating snacks, doing pushups, taking naps, watching the sun set, doodling... of course, you may periodically call them over to try something on and see how it looks "for real", get their opinion on it. All adventurers will need to make small talk, too, but that's got nothing to do with the room design.

2) Highlight the clothes you create to give a sense of history and accomplishment. This should be a combination of clothes hanging on racks or from walls as well as pictures of heroes who did particularly well thanks to your outfits. This takes a lot of wall space and is intended to be shown off, so our shop design should have several jutting regions you can fill with knicknacks as well as random things to do.

3) Highlight our supplies. Our needle room should feature cubbies with cloth ready to use, shoes neatly stored in pairs, etc. This, too, gives you a feeling for the world having weight - as you progress, your workroom fills up.

4) Give strong feedback as to what people think/thought of our design decisions. To this end we need a table for correspondences, a place to chat with visitors that don't need tailoring, and a retired old tailor who gives design feedback both during and after, helping you to interpret stuff. Obviously, this could be accompanied by a large calendar if things like weather, holidays, etc matter.

All told, we don't even need to exist in our world. We don't have to walk through the environment, or interact with a chair, or any of that stuff. Our camera is limited to simply panning left and right through our shop to look at various rooms, and even then which room we're looking at doesn't matter much - we can overlay our design menu on top of whatever we're looking at regardless. The layout serves to remind us of our accomplishments and capabilities, as well as giving us an opportunity to watch the adventurers wander around and express their personalities.

Interacting with our home is limited to panning around and clicking on something to tell the current client to interact with it (or to select a client directly). The only other thing you'd do is if you go to your back room, you can ask the retired tailor questions and pull up reference materials.

Anyway, it seems like it'd be a pretty easy setting to make. Easier than the technical difficulties of dressing adventurers in arbitrary costumes, at any rate.

The good news is that shape keys help with THAT, too.

Pixel Aesthetic

So, lots of 2D sprite-based games coming out these days. Hm. Super academic mode: activate!

Have you noticed that sprite art is, technically speaking, sliding backwards? I don't mean in terms of actual quality, but in terms of fidelity. Throughout the eighties and nineties, sprite art struggled to be more and more realistic, higher and higher resolution. One of the big draws of Mortal Kombat and Street Fighter was that they had ludicrously detailed sprites.

But these days, nearly everyone is going the opposite direction. Fewer details. Characters that are only a dozen pixels tall. In terms of pixels per character, we're almost back to the time of Atari!

Except, uh, this shit looks fantastic.

Here's the thing: freed from the need for realism, art can explore along other axes. So we see our pixel art stretching out and exploring mood, lighting, color, composition, exaggeration - all the other aspects of art. Without the need for realistic detail work, we can leave off the difficult and confining requirements that high definition brings with it. Just as the easiest of the easy examples, we don't have to move the camera and light the scene to keep the faces clearly distinguishable... which allows us to move the camera and light the scene however the hell we want!

This is also why many of the most recent pixel games don't just have small characters: they have small characters with real-sized (small) heads.

Classically, sprites were given large heads so you could tell what their faces looked like. This wasn't some anime-style choice, it was a requirement if you wanted your character to have a face. But these days, if you want your character to have a detailed face, you can just increase the realism of the art. In turn, if you don't need them to have a detailed face, you don't need them to have an inflated head.

The spidery proportions we're starting to see in pixel art these days is not solely because people were impressed by Superbrothers. It's because the "spidery" style is a powerful aesthetic for exploring new kinds of composition, mood, and exaggeration. People are flocking to it because there's actual art to be done in that style.

Me, though, I'll stick to 3D. I've become fast enough at 3D art that it actually takes more time and overhead to do pixel art. I won't have an easy time exploring the artistic options that the pixel artists can tackle... but that's okay. I'm a mechanics-focused game designer, so I don't have much to say on those matters anyway.

Still, if you see a pixel-art game, don't dismiss it as "lazy" or "retro". Take a look at how it pushes other aspects of art.

Crew Play

This post has been a long time in the making, because I wrote half a dozen essays on the nature of gameplay, science fiction, and open-ended missions and ended up here. However, those essays were all pretty academic and dull, so I didn't publish them... instead, I'm just going to talk about one set of mechanics that arose from that thinking, and why.

Because that won't be dull at all... sigh...

My big problem with most science fiction games is that there's no human element. Science fiction, in any medium other than video games, is used to explore the human condition. You can highlight some aspect of human life by creating some slightly magical setting that lets you focus on just that. In video games science fiction is used, exclusively, to shoot aliens. In every other medium, the aliens are standins for other humans that you don't know very well, so this makes video game sci fi pretty annoying to me.

In the past I've created some nonviolent sci fi prototypes, but I never really considered how to make the human side of things feel more human. How can you create gameplay around being human? I mean, you can script in some stuff, but I'm talking about core gameplay.

There are a few options. For example, you could make an entire game around parenting an android you built - sort of a Princess Maker: Android edition, or something.

But what if we wanted to have really open gameplay? I mean reaaaaaally open. Kerbal-level unguided play.

Okay, let's make it about starships. We'll set it in a zeerusty 60s space serial sort of environment. Science fantasy.

The core mechanic is not about creating the ship, but about creating the crew.

Let's start with the foundation: the chain of command. Or, rather, the tree of command, because below the leader it splits into three branches: security, science, and culture.

As your crew parades around the universe, they are exposed to stresses. For example, they might be chased by an angry dinosaur, a situation worth 80 "danger" stress.

It starts at the captain, who bites out a big piece, say 50%. This reflects her quick judgment: "RUN!" The remaining 40 danger is passed down to the security branch, since it's a security situation. The head of security takes another bite, say another 50%. This reflects him blasting at the dinosaur to try and scare it off. The remaining 20 danger is passed down to the final person on that branch, who similarly reduces it to, say, 10.

The 10 remaining danger is standing stress, and therefore reduces everyone's inspiration (basically health) by 10 points. Everyone starts with a lot, but you never regenerate any, so every point is valuable. More than that, however, one of the scientists is "clutzy", which means he is injured by danger-type stress, and receives a 10-point injury as well. IE, he got bitten or trampled or fell in a hole.

This will slowly recover, but while injured the scientist cannot participate in the chain of command.

Let's say the next stress is a scientific one - trying to figure out whether these dinosaurs are proper earth dinosaurs or what. The stress of not knowing is 80 points of science stress.

The captain's actual class is "scientist", so she takes a big bite out of that - say, 75%. Normally, she would then pass it down the chain of command... but the other scientist was injured, and can't participate. So the 20 science stress slips through and stands. This reduces everyone's inspiration 20 points, but the lead security guy is "dense" and takes "injury" from science stress. So he gets confused and panicky because of this weird, unknown situation, and will be useless until that "injury" heals and he calms down. This is a very bad injury, and will take quite a while to get over. So wandering back out into the badlands might be a bad idea.

You can see the bare foundations of the gameplay in this, but let's explore some more.

The key to making this kind of challenge interesting lies in making it predictable. The player has to know more or less what she's in for so she can create her crew for that purpose. This is not a game where you have a starship full of hundreds of crew that goes on interminable missions - it's more like Kerbal, where a mission is a huge event with a custom ship and a custom crew. Similarly, it is possible to chain and combine missions in interesting ways - the game doesn't ask you to, but it lets you. Hopefully this provides a graceful and endless learning curve as you choose to tackle ever more difficult and complex combinations of missions.

This means that if you land on Venus' plains, you'll always be chased by an angry dinosaur. But there are a lot of variables: you'll keep getting attacked by dinosaurs if you keep wandering around the plains. So you might venture into hills or forests, where different challenges await. Similarly, you might do research while in orbit to become adept at fighting dinosaurs, or keep someone in the orbital craft to watch for dinosaur herds and mark them on your map so you can avoid them...

But there need to be clear "success" states, not just an endless array of challenges. When you go to Venus, there has to be a reason. In Kerbal, the reason is always just to land on the surface. In our game, the conditions are a little more complex, so I think we can determine "success" by having specific modules on our starships or landers and fulfilling their requirements. For example, a zoology bay where you can examine dinosaurs in detail. A zoo bay for shipping them back to earth. A bacterial analysis chamber, a cultural exchange center, a gravitonic research chamber...

In this way we don't force the player to have a specific mission - in fact, they could just fly out there and dick around to learn the patterns of the world. But they can also choose which mission to undertake by attaching the proper module to their starship. And they can attach multiple modules. Or fly multiple starships out. Or use the same module on several different worlds. It's all very open.

The actions required to fulfill a mission module are predictable but not necessarily easy. For example, the zoology lab might require you to collect 3 samples from each Venusian terrain type - IE, survive 3 stress events from each terrain type. Others might require you to win by a certain amount, or leave crew behind, or get infected and then get healed, or any number of other conditions. These apply evenly to all applicable worlds - if you fly to Mars, you have the same kinds of requirements. Of course, not all worlds support all missions. Venus might not have any intelligent life, and a science base in the asteroid belt won't have different terrain types.

To reiterate, one of the biggest advantages of this approach is allowing the player to choose which mission modules to bring and letting them decide how to try to achieve them. This is powerful and easily modded, and a very good way to push the player to take on difficult challenges.



As you can tell, this isn't some kind of heavy-hitting plot generator. The stresses are pretty much limited to "in this kind of terrain, you get this kind of stress", with occasional bouts of "if you have X on you or Y with you, you get that kind of stress". The core challenge is to survive the stress you are exposed to. Since you never regain stress, it's basically the "fuel" of our game, and how quick you burn through it will determine how much you get done. Since everyone on the team suffers the same inspiration damage when stressed, it also really rewards you for breaking the team into smaller teams.

But the gameplay isn't simply building a hierarchy and then sending them out to the planets you want. There's a lot of other factors involved to make it more interesting.

One of these is technology, of course. Ships are built out of modules. The exact topology doesn't matter, so starships are just spines with each module as a donut, and shuttles are just tablet-shaped jets with a certain number of cylindrical internal slots. It's pretty simple, because our complexity is in the crew creation. Although simple, it is important and full of tradeoffs.

The heavier your ship, the slower it goes and the more fuel it burns - fuel regenerates, but you have to stand still to do that, so it comes down to more time wasted. And being stuck in space slowly eats away your inspiration, so it's best to minimize wasted time.

Many of the ship modules are about crew management, from simple crew quarters to security stations and even chapels. Some of these reduce the inspiration penalty for time passing. Others change the crew's stats (for example, giving them +10% against danger-type stresses). Others allow them to change relationships. Some of them help to repair injuries. Obviously, some of these are really nice to have on shuttles, but space is even tighter there.

Many of the modules are about interacting with the world. Sensors, cultural exchange centers, dissection labs, hospitals. And, of course, shuttle bays.

Many of the modules provide resources that allow other modules to function better. Computer stations, comm centers, gardens - these provide resources that other modules can burn to work faster and more efficiently.

Even though the ships are quite simple and abstract, they can get quite complex if you want them to. It might even be worth sending out unmanned ships/shuttles and connecting with them later...

But the ships are not the focus.

The crew is a bit more complex than a simple chain of command.

First off, each crew member has two aspects - a job and a weakness. Any crew member can try to deal with any kind of stress, but each job is best at a given kind. For example, a scientist will absorb 75% of science stress, 30% of culture stress, and 10% of danger stress. Or maybe you would prefer an academic? They absorb 50% science, 50% culture, and 10% danger. You can choose how focused or general you are. Certain kinds of very advanced modules can only be operated by a specific class, but that's unusual. It has no effect on their place in the chain of command - you can put anyone anywhere.

The weakness, of course, determines what injures them. Now, if someone's inspiration hits 0 they're disabled anyway, so nobody is completely immune to stresses of any kind... but everyone is also very vulnerable to particular stresses. There's actually more than 3 stresses - probably 9, although I haven't really settled on anything - so it's possible to have quite a large crew without repeating a weakness if you like.

Of course, each crew member also has an appearance and gender, which are only aesthetic.

Aside from their personal statistics, you also have interpersonal relationships. The chain of command is the biggest one. It can be reconfigured whenever you return to your ship, so it's pretty malleable. However, you can also define one personal relationship per crew member. For example, you can define person A as being the son of person B, person B as having married person C, person C being ancient rivals with D, and D being the mentor of A.

While each person can only spawn one relationship, relationships are two people, so people can and will be part of more than one relationship.

Each kind of relationship has a specific effect on the way stress and inspiration propagates. For example, a married couple will always "equalize" their inspiration. While no added inspiration will be gained, you could have one person exposed to a lot more stress and it would equalize to half on each. Because of this, married couples are usually split up into different teams so they suffer different amounts of inspiration damage. A parent and child relationship works such that the injuries they suffer regenerate faster when they are on the same team, and so on.

These relationships cannot be changed easily. However, it is possible: several modules produce social points, which can then be spent to establish new connections or break old ones - although which kinds of relationship depend on the module in question. This is invaluable on very long missions, because you'll lose a lot of inspiration on the flight and you'll need as many perfectly configured social links as possible to survive.

Anyway, that's the idea.

The core point is that we let the player create her own arbitrarily complex missions, but with crew instead of rocket parts.

Player Generated Functional Pixel Art

I'm going to talk about something slightly nebulous.

I think plenty of you appreciate the "pixel art aesthetic", while some of you probably think it's really tired. Putting aside nostalgia, to me the real value of pixel art lies in the fact that it is low resolution.

There are two reasons this advantage is important. The first I won't go into detail about here, but in essence when the art style does not demand realism, you can really go all out on all the other aspects of the art - color, composition, lighting, animation. That's nice, but for this essay the second advantage is more important: it lets people create a lot of content, quite easily. You don't need to worry about 3D, or meshes, or UV maps, or any of that complexity. Anyone can create a pixel art wall, and even if it isn't very good, it's still serviceable.

This is valuable because it means we can let players create pixel art within the game world.

Other art styles also allow this. Voxel-based engines offer ever-more creative control to the player. Some allow the player to even design their own swords or characters out of mini-voxels. However, voxels have a lot of constraints - difficulty animating, rotating, squashing, having to wrangle the third dimension, and so on. Vector art style offers a lot of the freedom that pixel art does, but it's not as popular or entrenched, so players will have a harder time bringing it to life. Also, vector art's strength is in nuanced animation, which is another topic. For now, let's presume pixels.

Putting pixel art in the hands of the player is actually pretty rare. Some games let you draw a bit of your character, but that's not the side of pixel art I'm interested in handing over.

I want the players to be able to create complex, interesting worlds and challenges and plots out of pixels.

There are a few games that are slightly similar to this, but I think there's a level beyond them. So we're going into use cases here.



I think the core issue in content creation is scripting. We always think of scripting as something that you do to content, rather than with content. So it's always a bit complex for the player to grasp and rarely feels very intuitive, rarely feels linked to the style and feel of the game. Scripting is scripting, right?

Well... what if we take the basic tenets of our art style, and use them to allow for scripting?



You're wandering through a pixel art clockwork building. You ride an elevator up, and the grated elevator doors close and open with a shaky, rickety motion. As you approach the empty dais, there is a crank-wheel. You turn it, and a control panel rises out of the floor, dust shaking off. Your character sneezes.

This is a reasonably compelling scenario, and you can imagine the developer creating it. But can you imagine a player creating it?

Why not?

Well, the biggest barrier to allowing the player to create this content is all the animated and interactive pieces. The players needs to know how to animate an elevator door, hook a rising controller up to a crank-wheel, and create a dust effect (or abuse an existing dust effect).

In our current generation of player content, we normally think of player content as glitter rather than function. It's pretty easy for us to imagine a player drawing a pixel elevator door, a pixel control panel. But interactions and animations are not usually on our list of things players might be reasonably expected to do. Even in something like Minecraft, functionality is considered a very high-level concept and laying down redstone is an example of a painfully opaque, cumbersome method of creating interactivity.

This is where pixel art comes to the rescue. Unlike most other art styles, pixel art is laid down chunk by chunk. Other art styles are typically "tweaky": you don't lay down part of a 3D mesh with a click, but instead steadily refine and refine and refine. But with pixel art? Click and there's a pixel.

We can really leverage this. Imagine that when you paint a pixel art object, you're actually recording a progression. Let's say you draw a bush. You draw the gray-brown stalks emerging from the ground, then you draw the green leaves, then you draw the red berries. That is an animation. You can hit "play" and watch it happen. If you decide you want to refine something, you can always rewind or fast-forward through time to wherever you like, and insert another sequence... or a tempo change, a delay, an event, a sound effect...

Let's say you draw the bush with animation in mind, so rather than just drawing red berries, you draw golden blossoms that turn into red berries as the petals fall to the ground. If we want to add a bit of fantasy to it, we could massage the appearance of the flowers - start them as little white buds, then they pop into full golden flowers. We can massage the tempo so they all pop at once, or in sequence. We can add in an event so that when they pop there's a puff of golden dust that enters the game world proper. Or simply make it register a new resource ("golden flower") for any other AI hooks out there that might care.

This allows you to create a lot of complexity but here's the key: it all happens in the paint window.

If you were doing thing to a 3D model, for example, you would have to script each of these things in a different environment. Create the model, create the animations, add the flower objects, synch the events to the animations... but here in pixel-art land, you simply paint the blossoms on, then click on the "paint event" button, select "dust" like you're selecting a paint color, and click on the blossom you just painted. It all happens right in the window. Moreover, it never requires you to magically connect point A to point B - everything happens on a specific pixel, optionally spreading to every pixel sharing the color. This removes much of the complexity associated with scripting.

Integrating it into a wider worldscape might seem a bit difficult. How do you tell the dais it should rise when someone cranks the wheel? How do you tell the elevator it should alternate between the fifth and third floor? How do you tell the door to open and close at the right times?

The answer is: never leave the paint window.

The paint window lets you paint pixels... or sprites. Events, triggers, all of it.

Let's say you want the elevator to go up. You've painted an elevator. If you painted it on the level, it's already there. Otherwise, drag it onto the palette, open the level, and drop it into the right spot. This is exactly equivalent to painting a single pixel.

Add a trigger - "player enter" trigger onto the elevator sprite. It's exactly equivalent to adding a "pollen dust" event to a flower. What's it do? Well, you just pause the timeline until it gets triggered. What happens after the player enter trigger? Drag the elevator to the place you want it. Just like painting a string of pixels, the animation will mirror your drag. At the top, add another "player enter" trigger with a "play backwards" event attached.

Okay, okay, that's just a warmup. What about the dais and the rising controls?

Well, obviously you first drop the dais and the crank onto the level in the right spots. For now we'll assume the crank is already a crank and we don't have to script that. But how do you tell the level that the dais is connected to the crank and should rise as the crank is cranked?

First the rising part. Just like the elevator: drag the dais up to create that animation. Instead of just triggering it, we need to link the progress along that animation to the crank's crank animation, allowing the player to organically control it. How?

Classically, you would select it and add events between the two objects... but that breaks our rule of pixels. There should never be any "magic" eventing, because that makes it difficult for the player to conceptualize and maintain. Instead, we... yeah, we draw pixels. We draw a line of pixels (or sprites) between the dais and the crank, connecting them. We just draw them on another layer - the background. The wire exists in the game world, and we hook our new line of pixels to inherit the value of the crank's crank animation. Easy to do: the crank and the wire overlap at some point, and that is the pixel we paint with our "inherit" function. On the side of the dais, we do the same, except that the dais inherits from the wire instead of visa-versa. That becomes an event that you can synch with, and therefore you can drive your animation with it.

Because of the fluidity of the editor, you can do a lot of complex stuff with this. It's not simply a system of wiring.

For example, your painting of the wire is, in itself, an animation. Normally you would just tell the timeline to start at the end and remain there, but you could set it up so that you have to push a button to start the wire's animation, at which point it will crawl across the wall or through the floor in the same way that you drew it... forging the connection. The fact that you inherit from/to pixel positions means that the dais will wait patiently until some background sprite - anything - arrives in the specified position. As the dais rises, the pixel it is looking at will also slide upwards, so your wire has to have a vertical section to keep the connection static (or a clever person could animate the wire to rise with the dias by making the crank value force both animations). However, this sliding input means that the dais can also SWITCH inputs by just wiring things up a touch differently and letting it slide onto the new inputs.

This is, coincidentally, how the console can be rigged to control other things, like doors. Individual pixels can be hooked up to different inputs and outputs, shared through contiguous color areas. Since every sprite has a foreground and background, you can wire contiguous colors "behind the scenes" if you really want to have a complex foreground mask. When the player interacts with the console, he'll have to choose which place to press, reflecting the fact that several wires are connected.

Things like dust are also easy to explain. While we might paint a dust event to trigger at a certain time, that may not be what we actually want to do in this case. Instead, we would paint a "dust" pixel on the foreground. The dust pixel is a special pixel which increments over time, becoming grayer and more opaque. However, whenever any animation affecting that pixel or the whole sprite happens, the dust pixel dumps all its stored-up dust as a dust event.

There's nothing special about the dust pixel. It's just a 1x1 sprite whose timeline plays very slowly, connected to a few basic triggers that cause it to reset its timeline while also dumping dust events into the world. You could create something similar yourself - for example, pixels that heat to red, or get steadily wetter in the rain.

Anyway. I don't claim this system is ideal or polished, but I think it shows that you can give a lot more control to the player than they are normally given. If you leverage the basics of your art style, you might be able to expand those basics into a content creation system that allows for more than just a bit of visual glitter.