A General Perspective On Game Design. Case Study: Caracas Game Jam 2012 (and II)

And more of this.

In the last entry we made a short overview about Game Design from the perspective of one of its fundations: problem solving. We will continue from that point.

First of all, one thing anyone could point out is that “Problem Solving” is the purpose of any design process, so the point made in the last entry is vague, ambiguous and even redundant. Actually, that’s kind of true. Even though, remember that we are making a very general overview, but more over, I specifically choose a concrete example to write about: Caracas Game Jam 2012 (CGJ); any vaguity, ambiguity or redundancy could (and should, when needed) be ignored because there is a case study at hand.

Cleared that, let’s remember what our main premise is:

See, Game Design is, fundamentally, about two things: problem solving and teaching stuff.

We stated the following about the Problem Solving half of game design:

Game design is about problem solving. The first problem is stablished by the conditions in which the gameplay solution has to be develop, and the other one is how to deliver that solution to the player.

But, what is exactly a gameplay solution of the initial conditions of development? If you think about it, your gameplay solution is a procedure that takes as inputs those initial conditions and give us another set of problems, the ones that represent the challenge players have to face. At this point it’s quite obviuos a concrete difference between a game design process and any other design process: you solution is actually a number of steps thought to create even more problems.

(So, any vaguity, ambiguity or redundacy should be overcome by now).

It’s beyond the scope of this post to go deeper into the details of the last paragraph, but in order to clarify even more, a gameplay solution is a pattern stated by the game designer as a response of the initial conditions of development. That pattern (or set of) is used as a general template to create problems included in the final implementation of the game (whether is a analogical or digital, implementation here refers to the creation of the actual rules and assets of the game and in the digital case it includes the code).

On the other hand, that pattern requires a fundamental condition: that the problems created from it can be solvable, in general. A pattern can create non-solvable problems in human terms, or in most cases a set of non solvable problems can be stated from any pattern. The game design process is created to rule out any chance for those cases to actually happen.

So, there is nothing new under the sun, what I’ve done (since the last entry) is to point out some intuitive notions that aren’t that hard to see (but easy to forget).

In the case study, the pattern to be created as a gameplay solution is the result of the extreme conditions in the CGJ, when the main goal of maximizing funtime (as a general purpose). Possible solutions? gameplay mechanics based on randomness, time consumption, player competitivity to mention a few. Is now more clear why a level based game isn’t (by far) a solution: a level, in the platform sense, is a pattern (in the gameplay solution) so concrete that needs a lot of work (design, assets, balancing) in order to be created, a quite hard task to accomplish in only 48 hours. A set of more abstract patterns, as the one I’ve mentioned, is more likely to be a solution.

But, what happens next? once the pattern gave us a set of problems, what’s the following step? the next step is fulfilled by the player. And that’s where the 2º half of the design process lights out.

The important observation here is: the player is untagling this process in the opposite direction, from the actual problems to the general pattern. Players don’t even care about what initial conditions were set, the whole idea of a game is to discover the pattern that every problem in the implementation is an example of.

So, what happens if the player doesn’t discover the pattern? nothing happens, that’s what; you just wasted your time making a so called game.

From a very intuitive point of view, the result of any design process requires the final user to understand it in some way and measure, but in our case, a game the design process is not finished until the player plays the game and validates that a general pattern can be discovered from it, while taking part of the actual process of discovering.

In other words, the general pattern needs to be teach. The tools to discover that pattern need to be given to the player, in some way.

Any game teachs something, because any game is a pattern waiting to be discovered. Please, kill that mindset that tells everyone a game only teach something if it is a realistic medieval or World War II  era videogame or a thing like it.

Some games (and specifically, videogames) teach deep things, other not so much. Every single one of them teach something that requires the player to be a living part of the discovering process. The power of gaming lies in that fact.

Game design is about teaching stuff. If you are not teaching anything, then you are not game designing.

The other thing  I noticed in the CGJ (besides the level based games trend) is that every single team just dropped the idea to teach the pattern they choose as a gameplay solution, and I need to say it in the exact way I’m thinking it: that’s just fucking stupid.

They were in the edge of not making a game at all, but a thing with the potential of being a game.

The “teaching” part of the process is also a problem to be solved. A very important part, as you might recognize by now.

What happened then? teams confused level progression with teaching a pattern; they are closely related, but aren’t the same thing. I can teach a lot about a pattern even when I’m not showing anything new about it in each iteration of the game (not making progress in it); I can show (very literally) a lot of details of the patterns, by increasing difficulty for example, and not teach anything at all.

Level progression is just a way to teach a pattern, the most intuitive one I think, but not the only way (and actually, when badly putted together could be the worst way to do it).

Teams in the CGJ barely accomplished the duty of teaching something because they included some level progression in their games, but that’s it. Some teams actually refused the idea of teaching with no good reason (or reasoning) behind it. They focused in the solving problem phase of the process. There was no planification in teaching the pattern, it was teached almost by chance in many cases.

So, player, here there are some assets, some controls, you have to figure out how to use those things. No, that’s not the way this process works. At all.

And, stay with me in this one, I’m not saying I haven’t enjoyed every single game made in the past CGJ. They were wonderful, but they can be improved in very fundamental ways, and there’s no reason I can’t criticize that. It’s my duty, as a game designer, to do so.

So, to conclude this (supposed to be) short comment on game design, I just have to repeat our premise:

See, Game Design is, fundamentally, about two things: problem solving and teaching stuff.

Keep those things in mind. Always.

More on the details of these subjects in further posts.

Tags: caracas game jam, teaching