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.

Sun Wing

I've been really thinking about the concept of travel, control, and time. I've been trying to think of "slow control" methods of travel. That is, methods that are more introspective than the standard rapid running & platforming segments.

Things like sailing, orbital transfer, gliders, leaping long distances, swinging, and "quick climbing" (dashing up the side of things) are all good examples of what I'm talking about. These methods of travel rarely challenge your reaction speed or require you to dodge obstacles. Instead, they're about looking ahead and tweaking a bit so that you end up where you want to be in the future.

I wracked my brain trying to think of a method of travel that really seemed interesting and tangible. Something that would involve a few different modes, an organic feel, and that "slow control" method.

And I came up with the Sun Wing.

This takes place in a slightly fantastical future where there's not really any rocket fuel left. Reaching space is only possible via Sun Wing.

The Sun Wing is a very adaptive, technologically advanced not-quite-glider. Near the ground, it operates like a glider.

However, it has several engines in it.

One is the electrical jet turbine. This can't keep the vehicle aloft forever, because it eats through electricity faster than the solar paint can replenish it. It mostly serves to increase speed in the upper atmosphere, helping take you into suborbital arcs. It can be used low and close to the ground, if you like, but it's less effective there.

Another is the afterburner. The vehicle wicks water out of the air and converts it into hydrogen and oxygen. This happens really slow, so the vast majority of this happens on the ground in time acceleration. You can use that and the jet turbine to create a powerful "afterburner" effect, normally used to launch off the surface and into the air. Used effectively, this will last long enough to get you high enough for your jet turbine to take over. Used ineffectively, it's a fun way to give you a little added duration to your flights. It can also be used to help land by firing retrojets just above the ground.

At lower altitudes, you'll use a hydrogen-heavy mix, preserving oxygen for breathing purposes. You can use it in the upper atmosphere or even in deep space, but you'll burn your oxygen very quick.

The third and final engine is the ion drive, which is used for non-atmospheric maneuvering. IE, going from sub-orbital to orbital and back. The ion drive can be as powerful in space as the jet turbine is in the atmosphere, but you aren't going to have the electricity to run it at that level: it's even more energy-hogging than the jet turbine.

These three engines combine to give the player a lot of control over how they get around. They can glide around near the surface, fly in the middle altitudes, or even enter space. In theory, you could even reach the moon on a Sun Wing... except, of course, for the pesky need to breath. Even with scrubbers, the oxygen you take with you is pretty limited. You have to watch your weight, after all.

There is another facet of the Sun Wing: it has a very adaptive surface. The higher in the atmosphere it goes, the wider its wingspan becomes. This keeps your lift pretty constant even as your air pressure decreases. It also radically increases the solar paint's surface area, so you get a whole lot more electricity, making your jet turbine and ion engines feasible to run continuously.

When you leave the atmosphere, your flying rig stops looking like a sleeping bag with arms and inflates into a small but comfortable little tent. You can do this when parked, too, but like the extended wings, you can't really do this in dense atmosphere because it'll tear apart. Anyway, you can go from "rigged for flying" to "in the tent" whenever you like once it's open, and when you're in the tent you can see orbital paths, science experiments, emails from the surface, and so on.

...

The actual GAME part of this thing involves interacting with people on the surface. There are still plenty of people in this fantastical future, although there are very few compared to the 8 billion we have. More like a million, living relatively easy lives with an incredibly high level of technology. Most of them are interested in trading, or in giving you scientific missions.

There are five categories of task, although they certainly aren't exclusive and you can often do several at once if you figure out how.

Salvage/survey is the most basic mission. Because the population is so low, most of the world is empty of humans. While the maps of these areas are generally accurate in a topological sense, you can often find things that aren't topological. An old computer that still works, a junkyard nobody's raided, a cache of DVDs... some you can actually load into your cargo pocket and fly away with, while others you'll need to tag for pickup by whoever is closest. The advantage of loading it into your cargo pocket is that you can deliver it to wherever you like, while tagging always benefits the person closest to you rather than whoever you like. Either way, you get credit.

Cargo missions are pretty straightforward. Everyone is willing to trade, whether in credits or barter. Sometimes you'll run with whatever cargo you happen to want to, other times you might get a specific cargo with a specific delivery requirement. Because every pound added to the Sun Wing makes it harder to travel, you'll usually carry very low-weight goods such as data chips, computer components, spices, genetic samples, DVDs, and so on. You can carry heavier goods, but to do that you'll generally want to take off from a zeppelin or carrier, which limits where you can start from. Of course, not all places are easy to land in, either...

Data missions are a staple. Because of the heavy debris fields in orbit, there are few satellites. Therefore, you'll often find it useful to stand in as a temporary satellite, relaying transmissions, taking pictures, and so on. You may even be asked to deploy a temporary satellite as cargo. There are a few similar missions that happen in the atmosphere, normally wind-mapping, but this is primarily an orbital/suborbital thing.

Manufacturing missions might be possible when you've upgraded your wing, or launched from a zeppelin. The rig for manufacturing things is sometimes a bit heavy, but the point is that certain things can only be manufactured in orbit, whether because of the zero gravity, the magnetic fields, or the radiation. Manufacturing normally has strict requirements about the conditions - for example "only in the shadow of the planet" or "only when passing over the poles". Because of this, an understanding of basic orbital mechanics and a steady hand on the time accelerator is required or you'll end up corrupting the batch.

Lastly, there's space ops. This generally involves refueling and maintaining the few satellites there are, although you can also salvage from debris fields, perform debris cleanup, and even launch new permanent satellites if your wing has been upgraded to the point where it can carry that kind of payload.

It needs to be stressed that these missions aren't for the sake of doing these missions. Every mission you do, whether it was a request or just something you wanted to do, improves the life of a local. The more resources and connections a local has, the happier and healthier they are, and the more friendly they are to you. Obviously, with a million random people, it's not like every one of them then turns around and gives you an upgraded Sun Wing module, but everyone at least contributes what they can. Whether it's a paint job, a pretty picture, some clothes, or just agreeing to store your stuff for you. And, of course, they help each other out - someone who can't give you anything will still help all their neighbors, which effectively means you went on a bit of mission for them, too.

The world is large, so part of the fun is exploring the surface bit by bit, and finding some places to call "home" with people you like to help and hang out with between missions. Of course, you can use time acceleration to blitz through every landing and spend almost all your player time in the sky, it's up to you.

...

All combined, the idea is to have a kind of movement that is a lot of fun, transitioning organically between glider, jet, and spacecraft. The somewhat complex array of resources to manage during flight gives you a level of fine control over things like how long you can stay in space, and there's enough skill involved that you can polish your skills for a while.

The setting gives you a bunch of resources in a lot of places - some reliably in a given place, some that need to be stumbled across, and some that are midway between. The steady improvements to yourself and the human inhabitants gives the world some constructive longevity.

There is also a lot of opportunity for multiplayer, whether with NPC Sun Wings or other players. Docking up in space, landing together, trading tech modules, transferring cargo or fuel in midair, creating transmission networks out of spaced-out Sun Wings so that people even further apart can communicate...

In the end, the point is to have a design that can be easily implemented at the most basic level (the mechanics of the glider) and then easily expanded to include the rest of the stuff. Hopefully, that will allow me to release iterative demos, each of which is fun to play in its own right.

Doing Animation Wright

I like the new Phoenix Wright game. It translated everything into 3D, so all the characters are 3D models (or very convincing pseudo-3D models). The art style survived almost entirely intact, aside from some damage to the way that hair looks.

But there is one big change that I think I finally figured out.

The motions inherited from the old games (TAKE THAT! WHHAAAAT!) look robotic and excessive. But not all the animations look robotic: a lot of animations originating in this game seem very natural and powerful. It's not universal. Some old motions translate very well, and some new motions are awkward.

It took me a while to figure out why that is.

It's the framerate.

The old games literally used animated GIFs. The frame rate was very low. Because of this, you couldn't really create secondary nuances very easily. Instead, you usually take advantage of the low framerate to put serious "pop" into your animations, the same way you might cut a frame out of a cartoon to give it some extra pop. So the classic style was to cut to just before the primary stance and use a simple "pop" animation to bring the stance to the fore. You put in plenty of exaggeration to make it pop properly.

The classic example is the "TAKE THAT" finger point, along with most of the other lawyer animations such as lashing a whip, pounding on the table, having toupees blown off, and so on. The panicked animations for various witnesses are also done like this. These are perfectly suited for the low frame rate - they take a simple stance and use a POP animation to transition into the final stance.

There are a lot of examples of nuanced animations in the old games, too, usually on the part of people who don't get excited. The most iconic is probably Trucy's bounce. Put her in her primary stance and then just create a subtle bounce. The secondary animation of her hair and cape follow in turn, and make it a very engaging animation. There are other examples, such as Gumshoe's head-scratch, but in all cases these subtler animations were fighting against the GIF format, squeezed into a low framerate and with a significant file size cost.

But in the new game, those are the animations that shine. With 4x the old frame rate and no significant file size problems, the animations can be as subtle as you like. Moreover, nuances and secondary events can easily be put in.

You can easily see this with Trucy's new bounce, which is identical to the old bounce except that the secondary animation is a really intricate ripple. Another clear example is the first witness' hair-pull action, where she tugs on her long braids and causes them to stretch. The new heroine's BLEAH face also has some really great nuanced animations that shine in this new format.

But the old animation style looks awkward and stilted. Just compare the hair pull animation from our first witness to two of her other animations: letting the hair bounce into her eyes, and pulling down a flower inhaler off her hat. Both of these are obviously done in the old style, with a simple starting pose followed by a straight-through exaggerated motion into the final pose. At eight frames a second, they would look great. At ~32, they look clumsy.

It's clear to me that the animation team was working through this same thought process and will probably continue to polish their presentation in later games.

I don't think that big gestures are coming to an end in Phoenix Wright. It's not the big gestures that are bad, it's the oldschool "pop" animation style. There are big gestures which work, such as Trucy's magic trick. But these gestures don't pop into exaggerated existence. Instead they follow a more refined style with standard pre-motion countermotion and a feeling of weight and substance. It is a better animation style, and it's the one they'll use now that they're no longer trapped by GIF.

Of course, the "POP" of the old animations will be missed... they'll have to find some way to make the new animations as explosive and iconic.