In the last post, I mentioned the possibility of turning the act of building something in a construction game into gameplay. Normally, building something is just a choice you make: the gameplay is how what you've built works, whether you can afford it, whether it fits - the actual construction is just click and maybe wait a bit.
But turning the act of construction itself into gameplay may make for a more interesting game, and result in more interesting constraints and results.
There are three aspects to this. Let's give a quick demo of each.
The first is the the idea of constraining the physical act of constructing. For example, in Minecraft you have to be within a few meters to mine or place a block, which makes it difficult to build large things or things in awkward locations. However, this doesn't mean players don't build large or awkward things: in fact, that's what they love to build most. It's a great test of skill, and very popular.
Contrarily, modders that use construction aides can build at any size pretty easily. Their challenge is in how dense, realistic, and interesting they can make their constructs. So that's what they focus on. Obviously, they also build very large things, but they don't typically challenge themselves to just build something as big as possible, because that has very little meaning once the in-game construction constraint goes away.
The second aspect is constraining the resources or space available to construct with. In Kerbal, this is the launch constraint: if you can't launch it, you can't use it. So whatever you build has to resist launch forces, and is therefore constrained. Building larger, less launch-friendly ships or ships that combine in orbit is a fun challenge a lot of people get into.
In Minecraft the situation is often reversed. In survival mode, if you are hunting diamonds, you'll build up a massive stockpile of lesser ores like iron. The sudden over-availability of this ore means you'll often get the urge to embark on significant construction projects and, say, build a house out of iron. Dirt and stone are so common that they actually surpass that and become gauche, worth less than the time it takes to place them. It's a balancing act.
Starbound uses a pixel furnace that turns ores into cash. This really helps when crafting things, since crafting requires a lot of cash. But it's detrimental to constructing things, because construction requires resources. If Starbound wanted to be more construction-focused, it would let the player drown in a glut of low-grade metals and thereby make them want to construct things with them - not necessarily out of iron blocks, but out of iron-derived elements such as iron beds or doors.
Either way, it's not just materials, but also topology. For example, if you build a house in Minecraft you may find that when you go to wire it, the size of your wiring basically destroys the house you built. Similarly, building a rocket in Kerbal sometimes runs you up against the maximum hanger size, or you find you can't do something because it'd put an object inside another object. Maia and other base-building games often have specific places you can build specific things.
The third aspect is how extensible the construction is. Basically, anything which allows players to make things they put in the game world do stuff later, relate to things strangely, or be important in a unique way.
Extending the function of your constructs is a huge part of personalizing them. Whether this is a redstone circuit or a book you can write in, Minecraft allows you to extend your construction a lot. Some of this might be in construction phase, such as redstone and pistons needing to be constructed the same way as doors and walls. Other times, it might be in an alternate mode, such as typing into a book.
The programming may be passive (adding setting details such as text in a book), automatic (sensors wired to a logic system), or manual (switches that need to be manually flipped). Of course, these things can all combine, and you can do something like display text (passive) with a series of logic gates (automatic) wired to a button (manual).
On the other hand, it can be quite simple.
To show how simple this can get, Kerbal's docking system is an extensibility mechanic. It's super simple to set up, but it can be used in a wide variety of ways. It doesn't involve any upfront programming, but it allows for very complex interactions and operations during the mission via manual activation.
Extensibility is addictive, and once you give a little bit, people want more. This is why so many of the early functional mods for Kerbal were docking-related - docking assists, hardpoint locks for docked ships, short-range fuel-beaming without docking, modular magnetic docks for base construction...
Later on, the extensibility was extended to things like cargo, power and data relays, life support requirements, fuel and materials manufacturing... all of these are individually very simple elements that require basically no upfront "programming" - you just stick them on your ship. However, it requires you to use that ship properly in complex and varied missions.
Similarly, many of the "extended" spaces in Minecraft are levels generated for people to play through. The vast engine of redstone machinery orchestrates a complicated story where players explore a space, solve puzzles, and face challenges. Well, this kind of programming requires a whole lot more care and effort in the construction phase, but the idea is the same: you give players the ability to make their construction mean more, and they'll run with it.
It allows for very high-level self-expression.
This essay was mostly for myself, since I'm thinking about how to use these methods to give a strong feel to my base-repair game prototype. Haven't got it sorted yet.
No comments:
Post a Comment