Medieval Misstep

A while back I tried to write about Medieval Engineers, and I don't think I quite managed it. I put it off for later.

Well, there is no later, they just ruined it. So let's talk about what was.

Medieval Engineers had no inventory system.

A construction game with no inventory system!

It felt like a good match. The medieval setting combines well with every component having a physical presence. The weight of all the stone and lumber exists in the real world, and it felt real, it felt right. Building a house requires a houseload of lumber!

You would have to hew the lumber, then put it in a cart, then drag the cart - perhaps along a road. Then unload the lumber. It was a chore, but one that felt real, and could probably have been mitigated using NPC workers (which already exist).

Moreover, staging the construction became a major, interesting challenge. Those logs and stones have to be within a few meters of the thing you're building. So if you're building a five-story-high stone wall, you need to create a scaffold, haul the stones up, and put them near the next floor.

It really felt like medieval engineering. It was a hint of a powerful idea that could have been absolutely unique.

Well, I don't know if people complained or what, but they removed that idea. Now you have an inventory.

Even at its smallest, in the demo, it shows you being able to carry around 20 sledgehammers. So, yeah, stuff your pockets full of boulders and logs, who needs staging? Who needs carts? Who needs cranes or roads or quarries?

...

In any engineering game, the question is: what are you engineering around? What challenges are you trying to solve?

For two weeks, Medieval Engineers had a new challenge. One I've never seen before. You were trying to engineer around your own engineering. It was a wonderful seed of an idea, and it felt so promising, matched the setting so well.

But it is important to be generic. If you're unique, some players might complain that you're not exactly like the last game they played, and you wouldn't want that. It's got to be exactly the same, down to the exact flat-slot inventory model.

Abusing the Pipeline

One of the things I've done a lot of work on is allowing player content - whether through mods or in-game creation tools. More and more, I've come to think that in-game creation tools are not an efficient way to do it. I mean, if you can manage it, sure, but there are a lot of reasons to avoid in-game creation tools.

First, they are effectively duplicating tools. If you use Unity or Unreal, those come with powerful content and scene editors. Creating an in-game editor literally duplicates that functionality. It's far more efficient to allow players to create their content in Unity or Unreal, and then distribute those packages. Giving your players a subset of the game that they can open in Unity or Unreal is a powerful idea.

You have to adjust your pipeline, teach modders to pipe output to an import-friendly asset pack. Unity makes that pretty easy. Not sure about Unreal. But compared to recreating the entire editor and save system, creating a runtime compiler, bugtesting... well, it's much easier to teach a modder to create asset packs than all that!

But that got me to thinking. Once you think about using Unity or Unreal as a mod creation platform, you start thinking about the asset pipeline into them. And out from them.

There's a lot of potential here, I'm just starting to wrap my head around it. Let's start with the basic act of creation.

We're creating star ships. We create them in the Unity editor. As a player, we use the Unity editor. We find the various prefab starship components we want - engines, generators, chairs, beds, landing gear. We put them in the scene, tie them together as a new prefab, maybe rig the system to point to itself in various ways so that, for example, the turrets can't turn on if the landing gear is down.

Export the resulting prefab (or pack of prefabs, maybe you built a fleet) into an asset pack. Share the asset pack with whomever you like, and suddenly it's in our game, Space Ranger Example Game 2000. Your ship is in the game, performing quite well. The turrets only turn on when the landing gear is up, the engines draw power from the reactors and push the ship around, it's all great.

This allows players to build starships without a grid. They use Unity's powerful tools (including optional grid-snap or vert-snap) to lay their ship out with incredible freedom. Collision boxes are automatically computed.

This allows players to build custom variants. New materials. Different animations. Just swap that stuff out and the custom variants will get included in your asset pack, free from any chance of collision with other animations and materials from other star ships.

It also allows players to build custom code or UI, easily packing it into the asset pack. If you want to use AntiSpaceRanger's Cool-Ass-Holographic-Ship-UI, just throw it in and it'll be included into the prefab, whether or not the next player down the line downloaded ASR's CAHS-UI on their own. Create your own UI, if you like.

But... this is not the limit. Not even vaguely.

See, since you're using Unity or Unreal, you can import new assets. A new Blender file. New sounds. New video clips. New textures. Let's focus on Blender.

Your starship can be any shape using the prefab starship components. You can scale them, tilt them, place them in any way you like. But there's no reason to limit yourself to those prefabs, especially when it comes to interiors or complex, smoothed hull shapes.

Why not take to Blender (or Maya or whatever)? Use the library file included with the modder package, and you can import those prefabs into a new Blender file, arrange them in Blender, scale them in Blender. Save it, and in Unity, a finished ship will pop up. A minimal amount of processing can match the Blender objects to their identically-named prefabs and swap them out in the ship prefab - essentially translating your Blender file into the exact same ship you would have gotten by dragging and dropping Unity prefabs.

Except...

You can add more things in Blender. A hull that is any shape and texture you please. New animations. Skeletons. Unity understands all these things, and we can process some of them into game logic - for example, our custom hull elements can be correctly classified and prepared for damage effects.

How far the modder wants to go is up to them. A new animation controller. A ship that flexes and ripples like an organic creature. A ship that grows or shrinks on command. There's a lot of possibilities, limited only by how well the game code copes with weird-but-valid Unity objects.

The ability to shape your own hull really can't be overstated. Passive elements such as rails, running lights, steps, windows, and simple smoothed hull elements are incredibly valuable to the average person. Voxel-based approaches give you some freedom, but there is absolutely nothing like being able to arrange them freely. That requires us to be able to distort and reshape them - something that is easy in Blender and extremely annoying in Unity.

A long, curving hand rail is easy in Blender. Import the hand rail object, stretch it, and curve it. Fit it to your ship perfectly. Unity imports it and it's in your ship! Bang!

More than that, assuming your naming convention is good, Unity understands that it is a hand rail, and will use IK to have nearby astronauts automatically slide their hands along it. That's super-easy, I've done adaptive animations like that a lot. You just need to have the object properly tagged!

(Making custom spaces feel real is incredibly important - I would pay special attention to making adaptive character animations, including things like turning sideways to move through tight areas or stepping easily to the side as you approach furniture.)

Pretty neat, right?! RIGHT!?! yeah.

...

Oh, right, I forgot the other half.

It's possible to make game assets viable to import into any similar game. SREG2000 assets could be imported into Shooty-VR-Game-Ultra. The only limit are class and library dependencies built into the asset package.

It is possible to minimize library and class dependencies by having the ship focus internally. While it's unlikely the same asset pack would load up in both SREG2000 and SVRGU, it would be relatively easy to import SREG2000 content into the SVRGU mod editor (both Unity projects), then winnow out the dependency errors and re-rig the ship for SVRGU use. The core - the meshes, materials, animations, etc - would be the same.

It is possible to create a database of, say, complex space ships. Not simply models: high-functioning ships that contain dozens of internal logic objects. For example, a class that opens and closes a hatch when triggered. A class that runs a specific trigger name on someone's mecanim animator if activated by them. A class that displays the state of that hatch. Because these classes are internal to the ship, there's no real chance of them colliding with game logic. Therefore, these classes can be packaged with the prefab, or packaged with the core idea of the mod editing system for both games.

Sounds interesting!

And, more importantly, sounds viable. Even if you remove all of the advanced features, simply allowing players to create new prefabs out of stock prefabs is incredibly powerful, especially if you can wire components together with references and events and delegates.

Heights of Engineering and the Soft Constraint

I've been thinking about the curve on construction games.

In nearly every construction game, there is a wall and a plateau, and they aren't very far apart. That is, it's hard to learn how to build, and once you've learned how to build, there's relatively little engineering skill to learn past that.

In Space Engineers this is particularly pronounced. You need to learn that you need to arrange all your thrusters, need gyros, need reactors, need assemblers, etc. That's the wall: you need to learn all the hard constraints before you can make anything that comes even close to working. You can pilot included ships, but that doesn't help you learn how to make them!

Once you've got the basic hard requirements down, there's nothing to push against. You can do small topological and mass optimizations, but there's not much reach. Really, the only place to explore is aesthetics, and few players will feel strongly enough about it to want to spend real time on it.

(You can do a lot of stuff with moving parts, but those aren't part of the core ship design loop.)

Both of these problems can be solved by adding one simple thing to our construction game: soft constraints.

Hard constraints are when something won't work unless X is met. For example, reactors don't work without uranium, engines don't fire without fuel.

Soft constraints, conversely, are about conditions that gently change how the systems work. For example, an engine will burn all the fuel you pass to it, so you can change how much thrust an engine produces by passing it different amounts of fuel. Maybe the efficiency is best at a particular rate, but it'll work with a trickle or torrent.

Perhaps your space jump system requires 100 gigawatt-hours of electricity to fire. But you don't have to pipe that in all at once: the system can absorb smaller amounts of energy until it reaches its requirement.

On the introduction side, this lets you start new players off in a battered, badly-designed ship. Rather than trying to build a new ship from scratch, players can spend their first few hours repairing and upgrading, allowing them to learn how a ship works before trying to build one. This is a good solution because they don't have to be perfect: the player doesn't have to understand how to make things work in order to repair things. He'll repair things in order to understand how to make things work.

On the advanced skills side, players now have a lot more options on how they want to engineer their ships.

Do you shut down all other systems to get that fast charge on your jump drive? Do you put in additional heavy reactors, slowing your ship down in realspace for the advantage of a faster jump time?

Do you use thin fuel pipes, which are easy to work with but can't pump much fuel to your engines... or do you use the thick, annoying fuel pipes to supply your thrusters with overdrive capacity?

Multiply these questions times a thousand. Every system has soft tradeoffs. It works better if you do this or that better, but that requires other resources or space and so on.

Engineering is all about balancing tradeoffs and finding opportunities in constraints. Soft constraints are better for this than hard constraints. They let us do a lot more engineering, a lot more flexibly!

Just off the top of my head, those system optimizations can involve topological configuration (larger pipes), mass considerations (more reactors), temporal considerations (long boot times), intermittent optimizations (changing how things are laid out/enabled over time depending on requirements), and more.

Put in some soft constraints today!

Machinima as Gameplay

I've been thinking about how to let players create context-conveying content. Obviously, players should build physical content - space ships, maps, etc. But it's hard to explain what is cool about a space ship or a map if that's all that gets shared. Players need another option, another kind of content: procedural.

Procedural is a bad word, because it normally means "algorithmic content" such as roguelike dungeons. In this case, however, I am talking about purposeful changes over time. Processes. Maybe I should call it routine..ual... routinual? Ritual content? Probably best to call it "behavioral content" or "operational content".

Machinima is already a big thing, but it's normally outside of the game. Even if you record it while playing the game, such as a Let's Play with a story, the content itself is outside of the game and cannot really be distributed inside the game. The closest we've gotten in the past is with The Sims, where you could share photo albums.

If we bring it into the game, we can allow players to record something, and then we can chop it up and play it back as content allows. Duplicate it, move it, alter it to fit a scenario.

As an example, let's say you're playing something like Space Engineers or Kerbal. You create a ship with dozens of docking bays, all identical. You can get in a fighter, hit "record", and then record yourself approaching and landing on a docking bay. Now, whenever you or the game wants, a similar fighter (same basic bounding box, same basic thrust capacities) can come in on the same vector and land in precisely the same way.

But because the game understands the context of the objects, the game can easily flag specific locations and relationships. The point where the ship touches the bay is automatically considered the critical element. Other bays with the same layout and flagged as being the same thing can therefore automatically adjust the flight profile to perfectly match their position and orientation. This means, with no extra work, any bay can have a fighter come in and land automatically. And, if you cut and paste the bays, however many more bays, all of them can have fighters come in for a landing.

I want you to really imagine how powerful this is. Imagine you're just playing Space Engineers for the first time. You build a space station with some landing bays, and then you shakily pilot your starter ship over to a bay and park it. Now the game will instantly be able to have any ship of roughly that size warp in and shakily pilot over to your other bays. Noticing this, you cut and paste your bays, creating a massive wall of bays.

And now, there are fleets of small ships scuttling in, eager to stop in. They all line up and slide into place, many so distant they're like a swarm of butterflies.

Moreover, this behavior automatically links into other behavior. You notice that sometimes huge motherships will warp in and disgorge shuttles of the proper size. That's because when you build a carrier, you record the behavior of the shuttles leaving. They then become their own entity and can therefore pick up behaviors related to shuttles. It's a simple logical chain: your station allows for shuttles to land, these motherships have shuttles, therefore these motherships can use your station.

On the other side, things keep chaining. Once they've landed, the ships can chain into new behaviors such as trading, repairing, refueling, passenger exchange. Each of these is fueled by whether you've recorded the process in the machinima engine. And if you haven't, you can always turn it to "request mode", where they will request you to do something, and you can record machinima of it right on the spot with them.

Suddenly, the universe is alive. You've tapped into the shared behavioral engine.

We're using machinima as gameplay.

It's not just floating in the ether, either. Exactly how you land will depend on the layout of your ship, the size of the docking bays, and other gameplay considerations. When you record the machinima, your max acceleration and bounding boxes will determine the kinds of ships that are considered fit for the same behavior. And you'll also want to rig the behavior into a smart system - for example, point small ships towards small bays, but allow them to fill larger bays if your small bays are full. Set trading prices so that you can adjust the price without rerecording the behavior, or even adjust prices automatically based on supply and demand.

Basically, we've gone from just creating a ship to also creating the space and time around the ship, and the operations of the ship. These allow us to tie everything together - everything from a lot of different players. We can even embed mods into this, if we frame mods in the right way.

Normally, machinima is used for narrative content. You tell the story of two dudes on a road trip using the Space Engineers engine. By adding context that doesn't exist within the framework of the game, you make the game seem larger.

By allowing machinima sharing and reproduction within the game engine, we also allow for that. Not all behavioral recordings result in a significant in-game statistical change.

Sure, landing a ship and trading are valuable in-game functions and the behavioral recordings for those are likely to be spartan and utilitarian. But you can do so much more: record crew wandering around your ship, going to bed, changing shifts, eating in the canteen, bullshitting in the halls. Record conversations and missions that have nothing to do with any statistical in-game thing, but give your crew and ship uniqueness: when someone contacts your ship, the captain will pop up and be a specific person asking about specific things and telling a specific story about a specific ambush in a specific place.

Moreover, behavioral recording can be modded just like normal content. If we forget to make medical treatment a thing, people can mod in some new animations and record themselves interacting with various medical blocks in various ways and - poof - we have a new block with new functions that NPCs can automatically interact with. Tie the statistical operations of the block into the machinima, and you can actually have real function. The medical bay has a function for treating illness, and you can trigger that function during your machinima, meaning that playing that behavioral tidbit will actually treat illness. Conversely, anyone with an illness can automatically search for behaviors to play and for blocks in the area that will allow them to perform the behavior.

I think this is an interesting idea.

Social NPCs and the Old Guard

I talk a lot about social NPCs, but I'm obviously not the only person who thinks game characters could be more alive and interactive. My approach is "world centric", but that's not the only approach.

One person who shaped some of my ideas is Chris Crawford, a game designer who was active mostly at the turn of the 90s. His books and essays were always interesting to me, and his approach was "character centric". That is, he focused on making the characters themselves more interesting and nuanced, rather than integrating them into a complex world.

The reason I'm talking about this now is because Crawford came out of the shadows and, like many of the old guard, launched a KickStarter campaign. https://www.kickstarter.com/projects/544670315/siboot

Obviously, I backed it. But it got me to thinking about that world/character dichotomy, and why I decided to go the exact opposite route: I want the exact opposite thing he wants.

I don't particularly want mysterious characters that you push against. I want a world full of people you live with.

That said, I wouldn't mind seeing what he can do with his approach.

Content Reuse and the RPG

A few genres of game rely very heavily on content. Adventure games are the most notable: many locations are only seen once, dialog is rarely repeated, and each puzzle element is unique. In fact, the basic gameplay of an adventure game is intended to gate and pace your progression through the content: there's not any significant statistical or skill progression, it's all about moving through the content.

This makes it a constant balancing game: how fast do you encourage players to move through the content? Do you let them skip cutscenes, even though the cutscenes are literally a third of the game? Do you let them fast-travel, even though walking through the setting is a huge part of the game? Do you let them get hints in-game, even though being confused and searching through previous areas is a big part of your content pacing strategy? And, of course, all of this depends on how dense, layered, and interesting your content is.

Role Playing Games are another genre that burns content to provide game. RPGs progress much like adventure games, and sometimes they borrow from each other. But, fundamentally, RPGs are about pacing and gating using mechanics instead of puzzles.

Method 1: Grinding
Fights are a common gating mechanism, and they are decided mostly by stats. You gain stats by fighting, both intrinsically (level-ups) and through secondary methods (buying better gear). Player skill does matter to some extent, but it can always be offset by more grinding.

Method: Hunting
Like an adventure game's "pixel hunt" challenges, maps in RPGs are embedded with resources to uncover. These are not puzzle elements and are almost never needed to proceed: instead, they simply exert pressure to slow the player down, convince them to spend time searching the setting more carefully. In most cases, this is a bounded and easily managed challenge, so the content stretching is a controlled factor... unlike a pixel hunt, where it could take a completely random amount of time to accomplish per player.

Method: Sidequests
Sidequests are usually manually programmed, but the amount of effort and content it takes to create a sidequest is relatively small. Nearly all sidequests are either fetch quests or kill quests, and literally just hook into the first two methods of extending content. Sidequests do change the context of that content slightly, so they are more efficient extensions than simply leaving the player to walk through the same content again without a goal. Sidequests can also highlight specific high-density content areas and serve as an introduction to confusing or overly dense areas by anchoring you on a single objective even when there are dozens of potential distractions.

Method: Minigame
A minigame such as a card game can add to a player's play time by literally making them play a different game for a while. It is rarely hooked into the core game in any meaningful sense, but as far as tricks to extend play go, it's a good one.

Method: Algorithmic Maps
Randomly generated maps extend gameplay considerably. The content required for generating maps is still considerable, but it is chopped into tiny pieces and combined over and over into theoretically infinite variations. On the plus side, this is a great way to hook a player directly into the content extension system without actually needing very much content. The downside is that it isn't nearly as potent as carefully crafted contiguous content: you won't have the carefully laid out, carefully scripted interactions with real-feeling characters and places since it's all chopped up.

Most algorithms have a method to insert larger chunks into the game. Nethack will drop preconfigured levels on you from time to time. You might see a character over and over throughout several randomly generated maps, each time evolving slightly. You might have a radio contact whose story evolves independently of the maps you pass through, but affects them somewhat. There's a lot of options to thread in dense, contiguous content among the chopped-up level pieces.

The issue
The issue right now is that most RPGs are stretched out too much, and along the wrong axes. We've gotten very good at using the aforementioned content stretch techniques, especially since the advent of the MMORPG. Too good: every RPG is full of so many sidequests and collectables and minigames and random maps that only a tiny, tiny fraction of players ever reach the end.

When an RPG boasts that it takes 40 hours to do "just the main questline", you have to consider whether their priorities are in the right place. We're looking at a game built on content tourism: the heart of the game is to visit interesting places and interesting people. If it takes more time to interact with them than it would in real life, you've stretched that out too thin.

I think we need to consider other methods of stretching, and stop pulling quite so hard in the one direction we've been pulling. None of these methods are new: they are simply hard to put in an MMORPG, so they were avoided in non-MMORPG RPGs as well.

Method: Adaptive Content
Right now, all our content is "fire and forget". The NPCs we meet will give us a quest, we'll do it, and we'll go on our way, never to see them again. Our towns serve as a hub briefly, but then we move on and never really come back. Revisiting NPCs is extremely rare.

Rather than focus on creating more thin towns and NPCs, it's worth considering making fewer, denser asset that can be stretched further without fraying. Make it so every NPC can join your party. Make it so you never leave your hub town, you just evolve it piecemeal. Make it so that NPCs can have relationships with other NPCs.

The key to this is to embed stretching methods straight into the content from the start. Rather than creating a town that exists to be traveled through, we're creating a town that exists to be gripped by the player's time. We want to let the player sink time into our town, our NPCs.

One method is to allow the player to grind NPCs - level them up, change their gear, and so on. The more you make this pay off, the better - we can easily learn from "raising games" like Pokemon. Another method is to let the player socially adjust NPCs - changing how they dress or act, where they live, who they spend time with, who they like, etc. It doesn't need to be player-centric: having the player able to hook NPCs up with other NPCs is actually more powerful because we are squaring the content rather than just linearly extending it. A cyclic method of bringing NPCs into the highlight is also valuable, such as birthdays or aggressive sidequests.

Similarly, the town can be grown and altered, has lots of weather effects, holidays, etc. We can learn from farming games such as Harvest Moon on this front. These should be tradeoffs rather than a linear progression, and we should allow the player to undo and redo the allocations to experiment in a bunch of directions. The city needs to have a powerful personality, but also needs to have statistical effects depending on how it is arranged. Using this in conjunction with more complex NPCs can extend both of them.

Moreover, these also stack with our well-established stretching methods. NPCs which create new challenges depending on their mood, place new collectibles, adjust maps...

Method: Reusing Content
I think short RPGs are also more powerful than people give them credit for. I'd like a bunch of 6-hour RPGs over one 50-hour RPG. But creating enough content for an RPG and then having it be only six hours long is a huge waste.

Well, now we have a lot of ability to reuse content. Instead of content being developed and used solely by one team, we have a good baseline of content available to everyone.

Each game is short enough to be achievable by even a relatively unskilled group. Because they can share assets between them, each one has a much lower content creation load.

They can focus mostly on creating the personality they need to create: the unique NPCs, the stories, the layouts, the missions. The trees and roads and minor NPCs and so on are all inherited from a common repository.

This is the "RPGMaker method", I guess you could say. Except that RPGMaker came out at the wrong time and has the wrong feel. A new tool would be 3D (2D RPGs are niche) and have a much stronger, more adaptable content system. Basically, Unity or Unreal if they had a really good RPG plugin: applying morphs and recolors to content, plugging it in, scripting up dialog... yeah, it's viable.

Method: Sharing Content
The big thing coming down the road is obviously player-created content. There's a lot of different kinds of content: mods, content packs, custom quest lines, character sharing, guilds, role play events. From a dev perspective, it's almost entirely free, depending on how much tech support and policing you want to do.

This is a neverending stream of content. If it could be harnessed, you wouldn't need to ever stretch content! In fact, you have the opposite problem: content swamping. Like Spore. Too much player content shared too aggressively means that everywhere you look is a dense collage of context-free content spam.

I personally think we'll see a growing amount of "contiguous player content". Right now, player content is treated like randomly generated content. It's chopped up and recombined largely at random, presented with little context. But that's a stretching mechanic, and we don't need it any more. Instead, we can focus on allowing players to create a flow of experience, a thread of content as they prefer, and sharing the whole thing with interested others.

Let me repeat that:

Randomly generating levels is a method of stretching a small amount of content to fill a large amount of player time. We don't need to randomly include player-generated content into our randomly-generated levels, because we will never need to stretch player content. There will always be plenty more.

Instead, we should generate levels unrandomly. Unstretched, uncompressed.

Anyway, maybe food for thought.

Unbounded Construction: Construction Elements

Last post, I talked about the "unbounded construction" genre. Today I'd like to hammer out some of the nitty-gritty details.

The genre requires small, modular pieces that can be combined in a lot of ways. The constraints imposed on these pieces are partly from the game (engines require power) and partly from the player ("I'm building a luxury liner!") These constraints shape and are shaped by the player's vision, and different players will choose very different constraints.

The pieces and the interface are both critical in allowing the player to build their vision.

First, component size is critical. Humans are a specific size, and therefore most of the things we care about are a similar size. It varies from player to player, but most players have instincts in line with their life experiences and media habits. That is, most players want to build something between the size of a car and the size of a mansion. Larger or smaller things are generally reserved for advanced players.

The component size reflects this.

If we're talking about voxels, the ideal size seems to be about 2/3 a meter per side: roughly a 2x2x2 foot cube. Any smaller, and it becomes annoying to micromanage the shapes. Any larger, and it becomes difficult to get the result you envision.

But that's not an absolute. Most voxel-based games have objects larger or smaller than a voxel.

Moreover, the tool you use to lay down structure matters more than the size of the modules. When we're laying out chairs and windows and desks, we want to have control over things at a human scale. But if we're laying out the house or starship or a castle, we need control over the mass of the structure. Laying out the halls and rooms and walls and floors needs to be largely painless.

In Space Engineers, the large ships use a 2.5m voxel. This is great for laying out the ship - you can lay out a mansion in space with ease. However, you are then stuck using 2.5 blocks for interior layout, which is not ideal. Their small ships use an almost ideal size for interior layouts... but is it troublesome to lay out?

Not really. The UI allows you to put down lines and fields of blocks, so the only shape that is difficult is a slanted or filled area. A slightly more advanced UI could even polish that away.

It's no wonder that "overgrown small ships" have become popular. You can get really beautiful human-scale shapes with them. The downside is that they take a lot of processor speed due to the high voxel count, but that's not really a fundamental problem, it's just sloppy implementation.

Still, it's a bit difficult to lay out the structure of an overgrown small ship. It would be better if there were a different interface for laying out structure and laying out the interior.

Apparently Keen thought so as well, because their next game, Medieval Engineers, has just that. Using the same 2.5m blocks for structure, they allow you to lay out interiors using arbitrarily sized furniture elements.

This is a promising approach, but it also has some idiosyncracies.

The first one is that the game is built around structural integrity. This unfortunately means that if you are building in "physics mode", you can't simply tear out walls to replace them with windows: the building will collapse between those two actions. Moreover, the roof is quite hard to get right, meaning that even if you lay the space out properly, you will find a last-minute constraint has made it difficult to complete your construction.

You can argue that these are good things, that they make the game more interesting. Maybe. However, the average player will take substantially longer to learn the skills required to complete a basic house. Generally speaking, that's a bad barrier to entry.

If that issue is with the "engineers" in "Medieval Engineers", the other problem is with the "medieval".

Fundamentally, medieval buildings are not space ships. The inhabitants are largely integrated into the world around them, and medieval folks spent most of their time outside rather than slouching about in their huts. Conversely, a space ship is an integrated environment that has to take care of all the inhabitant's needs all the time.

When you build a space ship or space station, you are building someone's lifestyle. The interior is where the crew will spend every waking minute, and the systems you install are what keep the crew alive as they do their tasks. Their air comes from a known source, their entertainment from a known source, their food from a known source, their health care from a known source. If you think of it, you'll have a plan for how the space ship provides for every aspect of their life and lifestyle.

But if you build a medieval house, you are building only a small portion of someone's life. Basically, that's where they eat, sleep, and store their potatoes. Maybe they get stuck inside on rainy days.

They get food from the local shops staffed by hundreds of people. They get health care from a doctor on the other side of the town. They get their entertainment by gathering in public spots with other people.

The simple truth is that sci fi settings give you an excuse to package up people's lives into STUFF. Since you can place stuff, you can place lives. You know the sort of lives people will live on your star ship because you've placed all the aspects of that lifestyle as you created the ship.

Fantasy does not give you that leverage. If you build a house, you have built only a tiny fraction of someone's life. You need to build a whole village, or a whole farm, or a whole encampment. A building is only a tiny fraction of the puzzle.

This isn't too hard to understand once you start considering it. Most of the good Medieval Engineers shared worlds are villages, and as you wander through them you see all the same pieces you would have put in a star ship as a component. The forge is its own building. The grocer's, the butcher's, the doctor's, etc.

This has huge advantages over sci fi, too. You can create a village where the butcher is also the doctor, or a village where the town teacher is married to the town carpenter, etc. Rather than a machine that is always shaped a specific way and takes up a specific amount of space, the roles of people in your village are flexible and can adapt to your vision.

But...

Medieval engineers does not have even the smallest allowance for describing people. Only buildings.

Yes, you can build a village of hunters by creating all the buildings hunters need. But you can't put even one hunter in the game, let alone describe him as living in a specific building, doing specific tasks, having a specific lifestyle, having relationships with specific other villagers...

Unbounded construction in a fantasy setting needs to allow you to construct the one thing that gives it power: people.

Once you allow for that, there's really very little reason to do any kind of complex structural simulation. Buildings exist to support the people of the village, not on their own.

So... what's the UI for placing and relating people? Is each building and inhabitants a construction that can then be slotted easily into village frameworks, or do you build the whole village at the same time, like you build an entire starship?

So many questions.

Those are today's thoughts on Unbounded Construction.

Unbounded Construction: An Emerging Genre

The genre is outpacing the fore-runners.

Space Engineers, Kerbal, Medieval Engineers, Minecraft, and many similar games have started to create a pair of new genres. We're going to ignore the "survival crafting" genre, and instead focus on the "unbounded construction" genre.

Players have always wanted to build anything they please, and devs have always struggled to let them. But it requires three things, and only in the past few years have all three become widely available. The raw power to render and simulate large constructions. The fast, fluid UI to allow players to quickly build, refine, and import their constructions. The easy, integrated sharing of constructions.

These three recently came together to form a new genre.

It's becoming clear that the fore-runners of the genre aren't what the genre will look like in the long run. Let's see if we can talk about what the genre might become.

(Of course, maybe I'm the only one seeing this genre, but let's look at it anyway.)

The genre's name gives away what I consider the core concern: unbounded construction. But we've always tried to create unbounded construction. What makes something like Minecraft different from something like Sim City or Civilization?

Well, when I say "unbounded", I mean unbounded in the logical sense, not the logistical sense. I don't simply mean you have a limitless plain to plunk down physical blocks. I mean that you can invent your own purposes, build to meet your own goals and tell your own stories. Your visions can be pushed into the game, and the game can inform your vision.

In Sim City, you could build a big midwestern city. Just that. You couldn't build anything else you wanted. If you want to build a replica of ancient Greece, you can't: the buildings are clearly modern midwestern American. You want to make a Martian city? No dice. The pieces just don't match up.

But if you make the pieces small enough and the canvas large enough, you can get a lot closer to your vision. You can pack more customizable details into more space.

In Minecraft, you can build a replica of ancient Greece. Sure, the pillars are weird and square, but you can get pretty close. In Space Engineers, you can build a Martian city. Sure, the cargo pods look different than you would like, but you can get pretty close.

Each individual piece might not match perfectly, but you can choose where to place which pieces, and the result is pretty good. It's the Lego approach.

Moreover, modding is a lot more powerful at this scale. If you want to simulate ancient Greece in Sim City, you have to find an ancient Greek buildings pack, which is awfully specific. But in Minecraft, you can scrounge together a variety of generic medieval parts and come out with a pretty convincing Greece. Similarly, if the cargo pod in Space Engineers bothers you, you can replace it. You don't have to find a "Martian city" mod pack, you can just find a slew of random parts that are closer to your vision.

This "small parts" approach is very powerful for those reasons and more, but it requires some things that weren't available until recently: a massive amount of computational power, flexible UI, and integrated networking.

Computation allows us to combine the many small pieces into an integrated whole, including functional pieces such as doors and machines. Moreover, computation allows us to execute code on the fly, integrate new models and textures, and do other things that used to be too difficult to really allow. This allows modding to be plausible, allowing us to create new parts.

Computation also allows us to have much more intricate emergent scenarios. This is just starting to come out, because it requires a whole new class of play. You can see hints of it in Space Engineers when ships collide, or in Kerbal when you try to use 60 mods at the same time.

The flexible UI is absolutely necessary as well. When you have a lot of small parts and a big canvas to paint them into, you need average players to be able to do so without getting confused. Without a tutorial.

This is partly accomplished through a new class of UI controls involving flexible lists and adaptive spatial interactions, but it's also accomplished by simply evolving player familiarity with controls. Modern FPS controls are extremely complex and opaque, but because the audience has played so many of them, they quickly grasp whether this game allows for parkour, what the weapon switch button is, whether the reload has a timing event, etc, etc.

We're seeing the same thing here. Minecraft's clunky construction controls have given way to Space Engineer's more powerful, fluid interface. But even that is clunky compared to where we're going: the emergence of VR and AR will create a new class of immersive interfaces that will rapidly evolve. While unbounded construction probably won't be explicitly VR/AR, it will benefit from those UIs and steal them wholeheartedly.

The integrated networking is necessary in order for the game to have a powerful, flexible metagame. This is not simply a nice perk: it's a core part of the genre. You need to be able to show off your creations, and see where your creations fit into the grand scheme of things. You need to be able to see the wonders other people have created in order to be inspired to create your own. You need to be able to steal techniques. You need to be able to cooperate and compete in construction, not just in gunplay. You need to be able to get mods or even whole worlds to integrate into your vision.

At the moment, Space Engineers has the best integrated networking around - automatic mod sharing, quick and easy ship/world sharing, a place to chat and share pictures/vids, all built into a reasonably large existing user base (Steam users).

But, again, Space Engineers is already showings its age. The content isn't properly integrated into the game experience, and it isn't properly partitioned away. In the end, we will see unbounded construction games where mods are local to each ship or town, not to each universe.

It's not that Space Engineers is bad, it's that the concept is bizarre and wasn't even on the radar when the game was laid out.

... I should stop playing Space Engineers and finish programming some of this stuff, I guess.