you are viewing a single comment's thread.

view the rest of the comments →

[–]snauts 1 point2 points


How do you plan/design emergent gameplay? As soon as you foresee something it's not emergent anymore. Emergent gameplay is awsome, but designing your game to have such is matter of pure luck IMO.

[–]TheJunkyard 4 points5 points


You create a rich environment for the gamer, within which he has plenty of agency. You test it enough to know that it's challenging yet not impossible for her to reach the goals you set for her.

If the system is rich enough, you'll find plenty of interactions over the course of your testing that you didn't envisage when originally designing the system. By the time the game is finished, there are probably still plenty more interactions left undiscovered, and players with a different style of play will take great joy in finding them.

You watch footage of your game being played, and you see things that surprise even you. That's when you know you've been successful in creating emergent gameplay.

[–]snauts 0 points1 point


It kind of feels like buzzword. Everybody is talking about it, but only advice anyone can give you - just make it complex enough, give it to playtesters, if nothing emerges, then add more complexity.

[–]TheJunkyard 0 points1 point


It's no empty buzzword, but it's not something you can force. It's not as straightforward as "complexity" either - a system can be incredibly complex, but still really boring for the player.

What you're looking to do is create a sandbox that's so rich in possibility, so exciting for the player to mess around in, they hardly even need a plot or goals in order to have fun with it.

It's about making a player feel like they're part of a coherent system, where every action they take has a logical consequence. It's the antithesis of a point-and-click adventure where you have to constantly guess what crazy illogical puzzles the designer has set up.

[–]_Geo_ 1 point2 points


Just look at Dwarf Fortress, that's a number (a big number) of systems that interact with each other to give unexpected results. When you're playing it you feel like you feel like anything could happen, it feels wild and fun. You 'plan/design' emergent gameplay by creating complex systems that interact with each other.

[–]snauts 0 points1 point


lots of rules and complex systems == emergent gameplay?

[–]WazWazWazHack Developer 0 points1 point


Add and subtract rules until it tests as fun, amplify that fun by further iteration.

[–]Kilometrik 0 points1 point


It's not actually that hard. Over the years i've come to a formula for desining emergent gameplay which only has a couple of steps and it's quiet understandable.

1.- The first and most important thing you should do, if you wish to create emergency in a game is to have a game with more than one system and more than one possible input for each system. I like to call the regular kind of gameplay "Single input gameplay" because, for each systeam there is only one valid input that gives out an output. In other words, for each gameplay system, there should be multiple possible ways of interacting with it and each must generate a different output.

Let's look at Mario, for example. Super Mario Bros. Has multiple gameplay systems in place but each and every single one of them only accepts a few kinds of input and returns, for all intents and purposes, only one kind of valid output (All other interactions return a fail state (death)) Each enemy has only 3 possible interactions: You avoid him, you defeat him (via jumping on top of him, basting him with a fireball or whatever) or he kills you and in practical terms, avoiding or killing them yields the same result: the game continues. In fact, avoiding or killing the enemies in Super Mario Bros. is such a trivial decision in terms of output that it could very well be regarded as the same input into the system.

Now, let's look at enemies in Thief. In thief there are many possible inputs when faced when an enemy. For starters you can either avoid them all together or interact with them. Functionally, that may seem like the same basic action as in Super Mario, but the crucial difference between both lies in the fact that avoiding them yields a different output than in Super Mario. Due to the fact that moving forward is the desireable outcome in mario and that returning to previously visited areas is impossible, an enemy, once avoided, is as good as dead. In thief, however, an enemy, once avoided, is still a possible obstacle but not an active one. Right off the bat we can see that, in terms of game systems, the input of avoiding enemies yields 2 outputs. One: Enemy is still an obstacle. Two: Enemy is still in an inactive state. If we had interacted with the enemy, then the output of the system could have been different. First and foremost because we have another dichomoty as soon as we decide to interact with the system: Lethal and non lethal and Direct or Stealthy. Lethal would remove the enemy as an obstacle if well executed or it could also put the enemy in an active state.

2.- Have more than one game system and have them feed off of each other's inputs and outputs. In the previous example we see that the player, when interacting with an enemy, is not putting input into only one system, but two: The damage model and the IA. In Super Mario, there is no player input into the IA of the enemies, you cannot change their state from active to inactive and the default state of each and every single one of the enemies is "Active hostile". To play mario is to engage the IA in an "active hostile" way. The damage model also has only one possible input: Lethal damage or no input and only three possible outcomes: either the enemy is harmed but alive (which, functionally, is the same as no damage), dead or no output Super Mario, then, has the player interacting with as few systems as possible (usually 2, ocassionally 1)and has no more than one functionally differentiable input and output for each system. Thief, however, does not. Not only are you always interacting with the damage model but the AI, which also has multiple inputs and outputs, as well. There can be numerous permutations between the possible inputs and outputs for both systems and even ways of interacting with the AI without interacting with the damage system (non lethal indirect). So interacting with the damage model yields then an output that is used by the AI as input to yield a different output valid only for the state of the AI. Add the Physics system to the mix and we have a game that's constantly processing a multitude of inputs for a variety of different systems, all of which feed off of each other's outputs to create a very distinctive emergent experience.

3.- Never break the rules arbitrarily. The systems must be constant and inmmutable. Enemy Type A must always have damage model B and IA D everywhere it appears. That way, the player is always aware of the possible inputs he has access to. If a particular type of door was able to be opened once, have it be able to be opened on every opportunity. Never turn off gameplay systems arbitrarily because that reduces the ammount of possible inputs and outputs the player has access to at once.

What this creates are situations in which you have a game that reacts to each possible input the gamer provides it with. So, for example, if there is a damage model and a physics system and the player has access to both, he can use the output of the physics system as input for the damage model (Example: Throw shit at the enemy) and this creates emergency. However, if the game designers decide to arbitrarily restrict one system there, be it the Damage model or the Physics system (Either you cannot pick up that particular type of object for no reason or the damage model of the enemies is not interacting with that particular object for no reason), then he is restricting emergency and thus forcing single system/interaction game design on something that didn't had it before, making it a game with "emergent moments" instead of a game designed around emergent gameplay. In the same way, suddenly giving player access to more systems and inputs in a game that never had them before creates a game based around "single system/interaction" with gimmicks, superfluous mechanics without any real impact or functional importance.