Boring Gameplay vs Boring Game

So, over the past week I've created several prototypes, all of which were quite dull. I learned a lot!

Let's talk about boring gameplay. First things first:

Boring gameplay is not bad

There are many genres which rely on boring gameplay - oldschool RPGs, strategy games, train sims, life sims, etc. The moment-to-moment gameplay of these games is incredibly dull. Rather than boring gameplay making boring games, the gameplay simply turns transparent and moves the play density deeper into the world.

These genres have more action-oriented equivalents. Zelda games have action-packed fights, navigation challenges, and even observation challenges. In turn, the gameplay density lies closer to those experiences and Zelda games do not have much statistical complexity. They focus on an endless supply of interesting, unique places and encounters.

Without analyzing it too deeply, it's possible to fall anywhere on the spectrum. I think there's some kind of conservation of complexity, though: Elder Scrolls games have really mediocre action combined with mediocre statistics. I can't think of any game which has both good action and good statistics, perhaps simply because it'd be asking too much of the player to focus on so many things at once.

In the end, it seems to be all about the pacing system. In Zelda, players are paced by the layout of the level and the fluid, attrition-filled fights. In most RPGs, players are paced by the stats - how fast and flexibly you can level and improve gear. In an Elder Scrolls game, the player is paced a bit by each, but it's relatively flat in both cases.

Elder Scrolls games are interesting to analyze, because you can see them steadily drift more towards the action side. Each new game is a little more action-oriented, and the leveling/equipping becomes steadily less complex. They also allow the player to choose where on the spectrum to fall - a more statistically complex mage, or a less complex warrior.

The same holds true of tactical/strategy games. Something like Civ has transparent moment-to-moment play and extremely complex statistical play. Something like Starcraft has a bit of a balance, with much stronger moment-to-moment play but much less extensive statistical play.

The reason I started to think about this is because I created several very boring prototypes. My problem with the prototypes is that I hadn't properly thought of the early-game pacing mechanic. That is, I hadn't bothered to think of what the player would push against. Everything was either easy or impossible.

This got me thinking about diving games.

One of the big problem with games about being underwater is that being underwater is pretty dull. Most modern diving games try to fight this off by injecting action into the moment-by-moment play. OH A SHARK DAAAAMN!

But it never seems to work, because adding in moment-to-moment action doesn't actually provide a pacing mechanic. It just introduces an arbitrary challenge. It comes off as somewhere between annoying, dull, and petty.

What you need to think of, if you're creating a diving game, is what the player will push against. This is how they will express themself, how they will pace themself. It's not quite the same as progression: progression is often a gating mechanic, not a pacing mechanic. IE, the plot of an RPG is not the pacing mechanic, because the player cannot play around with it. The leveling is.

Let's assume a transparent diving mechanic. That is, the player never faces any real interface challenges. They are diving, and hopefully enjoying the experience, but they aren't fighting sharks or being swept around by difficult currents in real time.

Because the moment-to-moment play is transparent, there needs to be a deeper kind of play.

You might consider something like analyzing fish or searching for downed ships or chasing dolphins. While these are underwater activities, they do not allow a player to express themselves. It is difficult to play around with the concept of identifying a fish.

You might consider costume/avatar changes. While this is self-expression, it isn't pacing control because it has no feedback mechanism. The player cannot play around with it because there's not any real interactivity. It's just a bonus.

As I consider an underwater game, I'm starting to consider ways the player can express themself - a system that feeds back as time goes on.

Fundamentally, it's probably not about any particular area of the ocean. Our moment-to-moment gameplay is too transparent to make levels expressive, in the same way that interacting with a town is not a particularly expressive part of an RPG. But, on the other hand, the levels do have to have the kernels which lead to self-expression, as a town has shops and quests and things that make us feel like the world exists.

In an RPG, the progression lies within the growth of the characters. However, we have nothing for our characters to grow relative to, not in any complex manner. There's no fights, so improving our stats and performing special moves is not important. Well, some stats can affect how we might explore, but it's not enough to really count as "expressive".

We could still use characters, but we'd have to change it from statistical growth to personal growth.

We can have both diving buddies and "surface" NPCs. Over time, you can do things to make them happier or better off, and they will come to like you more, their personalities might improve, and they might do interesting things. In order to properly link them to the world, they need to interact with it: these characters cannot simply be talking faces. Diving buddies might help you spot things or extend your air. Landlocked buddies might give you equipment, new locations, tend a reef, send you work, or clean up an area before you go diving. the line between landlocked and diving might be blurry, too.

That could actually be enough, as long as the method this happens is properly paced. That means it'd probably have to be largely done in-level. You might collect science samples, observations, pick up trash, scan/repair infrastructure, mark possible locations, and so on in a level, which would make specific people friendlier. Rather than simply being "friendlier" on some kind of flat scale, it's important for the player to be given options here, to allow them to express themself. So the player would probably spend these "friendship points" on some kind of upgrade tree that affects activities and reactions.

I also like the concept of front-loading it: promising people that you'll do X thing on this dive. If you accomplish it, you get more points. If you fail, you lose points. Choosing what to promise which people on any given dive is a great opportunity to self-express, and it can be done independently of the game's opinions on what a dive should be about.

You could add in a bunch of other things. Cash, sidequests, jobs, "bounties" to locate specific rare species, time limits, team coordination, revisiting locations that you have improved, etc. But I think that if you wanted to take this approach, the core element would definitely and obviously be the people around you.

There are other options. You could make upgrading your rig the pacing mechanic, for example. Or make the moment-to-moment play the focus. But I don't think that has as much punch.

Anyway, just thinking out loud.

Tiny Levels: How To

I was recently looking at some actual extreme environment bases - artic, subaquatic, orbital - and marveling at just how tiny they are. Video games have unrealistically massive levels, it's true, but reality has unrealistically tiny levels a lot of the time.

There are a wide variety of video games, but most video games have the gameplay as the constraint and the levels as the opportunity. IE, you can run around at X speed, jump Y height, have Z weapons, now here is a level to conquer with those constraints. Whether we're talking about PacMan or Battlefield or candy crush, that's how it is.

If you decide your whole game will take place in one tiny location like, say, six people living in a schoolbus for a month, that won't work. The level is too small and has to last too long: it cannot be the opportunity part of the game.

Instead, it becomes the constraints.

If we consider the level as constraints instead of opportunity, we can start to craft a game where a tiny level can work. But we can't have a game with no opportunity: we also need to create an opportunity system.

One option we have is to make the gameplay elements into opportunities rather than constraints, and allow the players to craft their own gameplay. For example, if your base is a deep-space probe scanning the skies and doing science, you can allow the player to create more interesting science experiments and analyze a stream of unique data using customized heuristics. The level would be your constraints: only so many computers, so much memory, so many telescopes. There would be a struggle to do more with the same resources.

Another option is to have two levels: a closed level and an open level. For example, you are on a tiny scout spacecraft landing on a new planet. You only have a small payload for samples and limited time for analysis, so you have to decide what you can analyze and/or bring back. The inside of the space ship is a level, but so is the exterior where you go hunting for samples.

My favorite is the "ratcheted constraint" system, where you build/improve your tiny space between missions. In this form, the tiny space is an opportunity between levels, as you expand it and modify it. Then you have to live with it as a constraint on the missions.

That's the way Gravity Grain will work.

Of course, in addition to simple statistical limits, confined tiny spaces also offer constraints in terms of useability. If there are multiple crew members in the same tiny space, they are going to run into issues with who is using what pieces, when. So if you're building your own tiny base, as it goes from miniscule to tiny and the number of crew increase, the challenges change. Good layout and scheduling becomes steadily more important...

Well, either way, I think it will be fun.

Gravity Grain: Content content content content content content content content

My last project - For SCIENCE! - developed in a pretty straightforward manner. I put it on pause mostly because it turned out to not really be any fun. I learned a lot from it, and starting up my next project really punched me in the face with those lessons. So let's talk about it again!

The reason For SCIENCE! was so easy to develop was because my mood was strong throughout. I never felt uninspired by my game. And a big part of that was the content. By buying content from the asset store, I filled my game with detailed, fully-textured models right from the start. Even in its early stages, every test run felt like I was building something. A lot of devs can get away with placeholder art, but I evidently can't.

When I moved on to Gravity Grain, I knew I'd need a lot of content, so the first thing I did was create a content creation system. But this really distracted me from creating the game. As I should have realized, content creation tools are really something separate from the game. In fact, the concepts are so distinct that I literally packaged my voxel-object tools up as their own library, so they could be used and reused and imported and exported into any game, anywhere.

STOP! Why?

... Why not just import actual models, at that point? Why not just let people make great stuff in Blender or Maya and import it through the standard Unity asset pipeline? Why create a complicated, difficult-to-maintain voxel system?

Sure, the voxel system had some theoretical advantages. Shared materials between all in-game objects. Easy and meaningful deformation and damage. But... it's a TON of work, and the result has a very specific kind of awkwardness even with the cool smoothing mechanics. It would be more rewarding in the long run to give the players and developer(s) the kind of freedom you get with professional modeling tools.

So, I'm throwing it away.

I'm going back to the proven method I used in For SCIENCE!: getting third party content and feeling like I'm making progress rather than struggling to create both a tool and a game simultaneously.

The Hacker's Privilege

I haven't played Watch Dogs, but it has permeated my Twitter feed from both the computer geeks and the gaming geeks. As far as I can tell, it fell afoul of the same problems that plagued my own hacker game prototypes. Well, plus an unhealthy dollop of typical first-person-shooter problems.

Putting aside the FPS issues, the hacker side of the game is plagued by the same issue that always plagues mine:

Hackers are overprivileged little shits.

Fundamentally, hacking is the act of breaking into private places, guarded areas... then using whatever is in there for personal gain. At best, the personal gain might not hurt the target - the hacker might just be doing it for kicks or reputation. But, in general, hackers are going to harm their targets.

This is fine if their targets are simply corporations or other large, faceless entities. A few games have been like this. But those are largely logic puzzles with very little interpersonal interactions. Something like Watch Dogs, where you play a human walking around a human world, is very different. The most interesting targets in that world will be human, because it is a human-centric world.

So you hack people.

In the end, you cannot help the people you hack. You can only either ignore them or abuse them, just like pedestrians in GTA.

Fundamentally, GTA characters are also overprivileged little shits. Even if they are cast as being broke and oppressed by "the man", in terms of actual gameplay they are by far the most powerful people on the planet. They face no real repercussions for their actions, even if their actions are mass murder.

When you add hacking to that, you instantly magnify that problem. Now you don't simply have power over the bodies of unnamed passerbyes. You have power over their minds and lives. It is no longer faceless violence, but directed abuse. You're tormenting someone that has a backstory and personality, however sparse and random it might be. You're tormenting someone with PTSD, or someone that is proud of his olympic athlete sister, or is on parole. You've hacked into their history to learn more about them, and now you're stealing their cash or having them arrested or bringing life to their nightmares.

This is why my hacking game prototypes all lie discarded in my archive directories. As interesting as the mechanics were, the only path forward was to torment individuals. There's not even any real way to help people with video game hacking: at best, your hacks are merely intrusive.

I was thinking about it, and I can't really think of any good way to make a hacking game that isn't about you, the player, being awful. Even if you make the point of the game to hack people's stuff to help them, you're still invading their privacy in a really abusive and dismissive manner.

That's my problem with hacking games.

Watch Dogs, of course, has a lot of other problems. Horrible writing, deeply embedded misogyny, glorifying torture, boring gameplay, and so on. But even in the absence of those, a hacking game revolving around people will always be problematic on its own.

Gravity Grain: Mining is Hell

Mining is the most boring game mechanic that was ever thought up. You trade time for a dribble of resources. In the most boring exchange known.

It's boring in Eve. It's boring in Space Engineers. It's boring in FarSky. It's just boring.

Gravity Grain features mining!

HA HA HA HA... ha...

No, it's not nearly as bad in Gravity Grain.

My philosophy is that player time should only be spent on personalization, and then only as much as the player wants. So you can spend any amount of time designing a ship. Then you can put it together largely automatically while you do other things... or you can participate in putting it together in order to customize some of the details. While putting the ship together does take time, Gravity Grain has a time-acceleration system so you don't have to actually wait through it if you don't want to.

Similarly, a player goes on expeditions and missions with the ships they designed. I want them to have to spend time with the things they personalized, and only on those things. So they spend time managing the crew and the crew's resources. They spend time trying to repair damage from a meteorite hit, or running from a pirate. These things reflect on their ship design, their crew choices, the cargo they carry...

But the actual act of mining does not reflect their choices much.

So I don't want them to spend time on it.

I want them to spend time on the mining expedition, the mission, but not the actual act of mining.

Fortunately, there's an easy way out: time acceleration!

When the player goes to mine an asteroid, she has to park her ship on the asteroid using landing clamps. This is done in real time, because it reflects upon the ship design. It's affected by her customization. Then she starts up the gravity auger. This, too, is done manually. But once the gravity auger has punctured the asteroid, there's nothing more for her to do and she is encouraged to accelerate time and get it over with nice and quick.

There isn't any need to choose exactly which square foot to mine: the asteroid is considered a unit. And when you've sucked it dry, it breaks into much smaller pieces that float away. In theory you could mine them, too, but unless your first asteroid was quite huge, they'll probably be too small to deal with.

But, as you can see, it's an automated process. You just let it run until it's obviously finished. Then you can make the choice and customize your mission: do you pursue some of the fragments, too, or just head back with your current haul?

In this way, mining is made painless.

...

Now, unlike something like Space Engineers, FarSky, Terraria, etc, valid mining spots aren't something you just stumble across. Asteroids are scattered tens of thousands of kilometers apart, or further. You'll need some kind of survey ship in the region to scan the area with a telescope to identify likely good mining targets. Then you can either take a scout ship out to sample them for actual good targets, or just cross your fingers and head out with a mining ship without the local survey. Scanning takes time... but is it something that takes the player's time?

Well, it runs automatically in the background, continually scanning. If you want to focus it on specific regions, you can. That doesn't take much time, though. So it doesn't really take the player's time. The player can time-accelerate, or build a ship, or customize the crew, or whatever.

Anyway, all this talk about a game that's still just a voxel tech demo is obviously just hot air. But I wanted to make it clear that wasting a player's time is pretty high on my shit list.

A player's time should be spent on the parts of the game that let them express themselves, rather than bled away on some arbitrary treadmill desperately forcing them to slow down. That's just a sign that your game can't keep players without resorting to cheap tricks.

Gravity Grain: Gangly Ships

One of the things I hate about modern space-ship building games is that they always produce the same kinds of visual profiles: boxy, utilitarian. 45-degree angles are considered the height of fashion. People can go out of their way to build interesting ships, but if they do, it is at the price of lower efficiency: more weight, more vulnerabilities, etc.

Now, I don't actually hate boxy ships. I just don't want every ship to be boxy.

Gravity Grain features a similar kind of construction system. If I don't go out of my way to make another kind of layout preferable, Gravity Grain will have boxy ships.

The major mechanic Gravity Grain will use is "exclusion zones" - (usually) spherical zones of danger around specific modules. For example, a fusion reactor might have a 200m heat exclusion zone, while an inertialess drive might have a 300m "gravity wobble" exclusion zone. In theory I could model propagation and stuff, but it's easier to both model and understand these things as spheres in space, regardless of how full or empty that space is.

As you enter the heat exclusion zone, your suit would have to work overtime to keep you cool - your time here is limited to your battery life. Similarly, there are many kinds of things that can't function while in an exclusion zone. A bed can't be slept in. An IR transceiver can't broadcast. A telescope can't focus.

More critically, if any two exclusion zones overlap, that area is destructive. If you have two reactors close to each other, or a reactor and an inertialess drive, the place where they overlap will quickly cause damage to anything in that area, whether it's a tile or a person. You can easily rip your own ship apart, and you probably will do exactly that at first.

Obviously this means you have to spread your ships out. That'll be the first thing people learn when building a ship, and I imagine we'll see a lot of long, cylindrical ships from newbies.

But there are a lot of clever tricks hiding under the surface, if you want better performance. Use nacelles: the space between them might have overlapping exclusion zones, but it's just empty space, so it's fine. Use ship modes: balance modules that produce exclusion zones so they either scale back as another one scales up, or turn on and off such that no two ever overlap. And, of course, the ever-popular mechanical extensions - swing things far from the ship to turn them on...

You can even creatively use exclusion zones as shields or weapons, if you're clever. Fire an "inertialess missile" at an enemy, and wherever its field overlaps with an enemy's own internal fields, the enemy takes damage. Doesn't even have to hit - actually, it'd be most effective if it was fired at great speed, then decelerated to a relative stop and just sat near an enemy. Gatling turrets are your best friend, I guess.

All of these reasons lend themselves to spread-out ships. In addition, mass is not as big a concern in this game - structural elements are very, very light, so wasting space on them doesn't really affect your performance characteristics. Of course, those kinds of lightweight elements are also very, very easy to rip apart...

And there are reasons to want a dense ship. First off, a dense ship is easier to land. Also, FTL speeds are based on bounding boxes, so dense ships are faster at warp, if only modestly. Lastly, dense ships tend to have their critical systems in the center, well-protected against meteorite impacts or weapons fire, and are very hard to physically sunder, unlike ships that are mostly long, frail connections. Obviously, a dense warship is also much easier to properly armor, as you need much less armor.

The warp speed thing alone should lead to some fun "fold-out" designs, where the ship is sleek in warp mode, then drops into realspace and extends various kinds of projections, wings, and so on, unfolding for better exclusion-zone performance.

Fun Damage

I've been playing some Space Engineers recently, and I didn't get any sleep last night, so let's talk about the square-cube law. Keep in mind that I'm developing my own space-ship-game prototype right now, so this isn't necessarily commentary on what Space Engineers should do as much as me analyzing gameplay tidbits for future use.

It hasn't really been talked about much, but Space Engineers is really a game about the square-cube law. As your ships get larger, they quickly become too large to destroy. A fighter can be destroyed with one missile. A frigate with two or three. But even a middling-size capital ship can survive dozens and keep going - missiles are more of an annoyance. This is especially nasty given the relatively high manufacture cost of missiles and the manual reload required for fighter missiles. Antimissile systems are in the works, so that means it's going to get even worse!

Basically, it's unfeasible to blow up a capital ship. Aside from disabling missile turrets, it's clear that taking large ships is going to have to be done on foot.

There's a lot of flaws in how Space Engineer does this - for example, the best ground assault is to build a cockpit on the outer hull. That's a dominant strategy that shortcuts nearly all combat. Also, there are no subsystems or systemic failures - a large ship remains one completely intact ship except in the most astounding of situations. That means taking a ship can never be piecemeal, and is always all-or-nothing.

Anyway, there's also the ship after the battle. Space ships built brick by brick have a lot of emotional presence to them. Every brick means something. These are the crew quarters you build. This is the gyroscopic center, it looks cool. That double-command-bridge thing was an awesome idea.

Seeing those places shattered, walls twisted, pieces floating free - that's freaking amazing. I still say the most interesting part of Space Engineers is wandering through devastated ships, and I would love to see a game mode where you rescue survivors or look for dropboxes or something.

But, again, the redundancies and all-or-nothing nature of these ships make it difficult to get that kind of gameplay. Even after being battered to hell and back, a large ship probably has all the things it needs to be a ship - power, engines, gyroscopes, control chairs. Board a large ship devastated by battle and you will usually find all the lights are on, all the engines are raring to go. This gets more and more likely the larger the ship gets.

In both situations, the game would be a lot more interesting if the ship could be divided up properly, with various subsystems, actual pipes and wires, and the chance of systemic failure. Destroying all the engines of a decently-constructed capital ship is quite a task, involving saturation-bombing many areas of the ship. If you don't do that, the ship can still move under its own power. If you DO do that, the ship takes forever to repair because you literally have to build the engines from scratch again.

Imagine if you could knock the engines off-line by aiming for a power conduit. This would be a better situation all around. It would make combat against capital ships more skill-based. It would make capital ship designing more interesting with more tradeoffs. It would allow damaged ships to have systems knocked off-line and require players to route around damage or jerry-rig them back on-line. It would allow people storming the facility to break internal connections.

Required connectivity also allows for subsystem management - wire certain consoles up to certain things and that is all they can control. If some weirdo builds a console on your outer hull, they aren't wired into anything. Maybe use wifi to communicate without wires... but then you can get hacked by someone using wifi on a fighter nearby.

I would also argue that there needs to be more focus on shockwaves rather than blast radii. A missile completely destroys everything within its blast radius and leaves everything beyond that completely unharmed, with the result being that a tiny tick-bite is made. Instead, there should be a shockwave that spreads out from the contact point and deals partial damage to all nearby tiles with a dropoff rate as they are further away. This would allow you to knock components offline with a "near miss". Engines disabled in this way would go dark but not vanish, and you could feasibly repair them. The wider "hit" radius makes the missiles more effective, bringing space combat back to the forefront for another few size classes. It would also "spread out" ship designs, making sprawling, fluted, nacelle-based designs more useful due to shockwave negation.

Both of these changes (connected subsystems and shockwaves) increase the number of things that can go wrong and be repaired afterwards. This has the potential for a lot of fun in combat and in the cleanup afterwards. It also makes ship design matter a lot more, opening up a lot of more advanced tradeoffs. It will also give the inside of the ship more of a function besides "large empty space".

Anyway, the reason I'm considering this is for my new prototype, which involves building space ships out of bricks. I'm trying to keep an eye on the long game, with the idea that the game be fun in many scales. The square-cube law is an important factor. In Space Engineers it appears to crush space combat into a singularity. I think I can avoid that if I keep my eye on the ball. Moreover, the techniques used to bring the square-cube law under control can also provide gameplay at the smaller levels. For example, if you're in a scout ship and get hit by a micro-meteorite, you could suffer secondary damage to several of your tiles, then have a system failure that knocks your main power off-line. That'd be kind of fun.

The planned structure of my prototype involves missions. If you are in a small scout ship, you probably deployed yourself from a larger mothership with a specific mission in mind. You aren't struggling to build a mothership from a scout ship: you're struggling to complete the mission and return to the mothership for more resources and points. Because of this, the way you build and repair things is not the same as in Space Engineers.

You probably would not make any large structural changes to your ship, or put on a new engine. Your repairs would be limited to jerry-rigging, because your ship is task-focused. When you get back to the mothership, yeah, then you can refit and transform your small ship, or build a new one. This mission-based system means you will have large patches of time where you don't have access to your best tools, resources, or facilities. This makes your design (and the ways it fails) much more important, because it is 90% of what gets you through the missions.

Anyway, you can probably tell by how I wrote this essay, but I'm working on no sleep. So I'm done talking.