Sympathy for Call of Duty: Black Ops

I don’t have any talent to make titles.

This entry was intended to be the third part of the last two posts (1 -2), but I just dropped the idea.

If you read carefully the last entries you would notice that I didn’t mention a particular game of the Caracas Game Jam, I just talked in general about them. And there is a reason for it: It’s kinda stupid to point out flaws or achievements of games in an event that wasn’t a competition. The whole meaning of the Game Jam will be ruined if I say something like “this was the best game” even when I do have an opinion regarding that  matter. The point is, I need and example to illustrate this entry and using a game related to the last Game Jam is not a option.

That’s why this is another entry. Related to the last ones, but not attached to them.

And this is the example I want to use.

I don’t like Call of Duty: Black Ops (CoD: BO), at all. It’s not a bad game, but I think it’s just another iteration of a formula.

A product in an assembly line.

And even though, that particular scene, when the team sneaks into Laos and Sympathy for the Devil kicks in the background, is one of the finest experiences I ever had in a videogame.

It just feels right. In every way.

Why? well, the on rail experience is quite a tool these days, a well understood one. It focuses the player in the targets, not in the driving, so a fast paced target recognition – aiming – shooting  (and resource use if you add the heat that locks the machine gun or the RPG temporary limited ammo) mechanic can be assembled easily. The duration and timing of event is suited to a very well balanced ascending-descending pacing curve, both globally and locally: the whole scene and each individual action. The graphics and visual effects are compelling. The sound effects are great. The background music is awesome.

This scene is so well created that even the song gets a whole new dimension in it. And not only in this particular scene, but in the previous ones when is also used.

We call something a formula because when used properly it gives us the same result every time.  CoD: BO is that result in this case of this particular formula. And there is where the merits of Activision/Blizzard and Treyarch reside. No matter how much money or talent you put in a game, applying a formula is not necesarily easy, and you have to give those guys some credit for that. CoD: BO actually had a lot of problems and flaws, but when analyzed objectively is a good installement of the Call of Duty franchise. A formula, but a good applied one.

And that’s the point: even when we can argue that CoD: BO is a disposable experience, there is a sequence that at least for me it is worth the price of the entire game.

What your player has at hands to dicover the pattern you stablished as your gameplay solution is a lot of sensory information. It’s what players feel what tell them how the pattern need to be discovered and used afterwards. A game, and specially videogames, is about what players feel, and how we can drive those feelings towards discovering a pattern.

As I said, players follow the game design process in the opposite direction. We have a set of initial conditions that lead us to a pattern solution, which help us to create challenges that we need to teach/communicate somehow. Players, on the other hand, feel something the game is trying to teach/communicate, and then they decide whether or not they follow those sensory clues in order to discover and learn the pattern. In order to have fun while doing it.

From graphics to sound (or the lack of), from human to haptic feedback; everything the players are feeling is what drives them to play. And is not only restricted to sensory information, it is powerful enough to go deeper than that, to intuition, instincts, volition and cognition.

It’s so powerful that an overused and simple mechanic on a assembly line product can create very climatic moments, as the above example shows.

So, the third part of these shorts comments on game design is completed by: at the end, it’s all about what your players are feeling.

You not only could, but should focus your problem solving an teaching skills on that, in every way possible.

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.

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

Because is what this blog is about.

I noticed in the past Caracas Game Jam that a particular trend of creating level based games was the norm. That’s totally not an issue, at all, but it says a lot about people’s perspective over game design.

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

A Game Jam is restricted to 48 hours of development, time in which you have to create a game that fullfils the expectations of fun of anyone (as a general purpose). Such a restrictive environment is set in order to serve as a start condition for gameplay solutions that maximize the time players have fun (funtime), in consequence encouraging creativity and collaboration in the making process. One way not to achieve that goal is to deliver level based games: unless a procedural way to create levels ingame is proposed, you do not have the time to include enough handmade levels in your gameplay solution. You just don’t have that time.

Of course, that’s not an issue in this case because a Game Jam is a place where you can do whatever you want, but if you (due some weird circumstances) are working for a client in the frame described above and your gameplay solution doesn’t maximize funtime then you failed. As simple as that.

And let me tell you something, those “weird circumstances” aren’t that uncommon.

This point of view can be criticized as subjective. Funtime is not necessarily a thing to maximize in a Game Jam, it can be, let’s say, player impression (based on fear or stress); collaboration and creativity aren’t the only skills that can be tested (programming expertise could be another), even the sentence “ you do not have the time to include enough handmade levels in your gameplay solution” is a matter of how the team is creating those levels. But what I want you to notice is that a general frame is offered: the one I’ve described a couple of paragraph above. That frame represents a problem, one that can be solve optimally in order to maximize funtime.

And a level based game, in that frame, is not a solution. Not an optimal one at least.

If a team makes a level based game then they didn’t solve the problem that a Game Jam offers as a general frame. That team solved another problem, one that actually can be (and probably is) even more difficult that the one at hand to begin with.

And that’s the point: 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.

In our particular example a group of people solved the general problem a Game Jam offers, other group of people decided to stablish an inner problem inside the general one.

Some people solved the problem offered by the Game Jam as a general frame. Other people just didn’t solve it, they solved another problem.

As a game designer you need to realize that difference, because the first step to solve problems is to know exactly what the problem is. And if you don’t understand that subtle differences then you have a problem. A big one, by the way.

To be honest, I enjoyed the most those games that solved the general problem. I know that perhaps that’s a matter of taste (and it is, in part), but what I think is that the general problem actually represents the spirit of the Game Jam itself: an effective way to encourage creativity and collaboration, and I see no reason to change that fact.

But as said, in a Game Jam you can do whatever you want, and that’s awesome too. All games made in the past Caracas Game Jam were simply fantastic. I’m just trying to make a point on game design out of them.

Delivering the gameplay solution to the player is the second thing game design is about: teaching stuff.

I want to share a short comment on that tomorrow.

If you haven’t yet, you can check out my post about Caracas Game Jam 2012.

Caracas Game Jam 2012: El Potrero

The title translates as: The Paddock. We were asleep at the end of the event, you know.

I won’t write too much about the event itself (I don’t want to write too much to be honest), if you are an spanish reader you can read a review here. I’ll be writing a lot about things we have done there in further posts, because what happpened that weekend was interesting in many ways.

First of all, I want to inform that the Caracas Game Jam 2012 (CGJ 2012) grew up quite a lot. And that’s a good thing. I was having a conversation yesterday with @chiguire and @justyole (founders of the event here in Caracas) and I said growing up is not (only) a matter of numbers, and this CGJ was a proof of it. Last year we had more people and more games (including a board one), this year the numbers weren’t quite different, but it was the experience as a whole. The last 3 years we had a facility specially designed for developing, this time wasn’t the case, but the desire to expand to other universities was a major goal this year so we decided to take the risks. We did it in the best way we could. But it wasn’t easy at all. We, as organizers, had to confront a million problems in order to keep the event going without much noticing by the attendees: from electric power problems to some douchebag claiming rights over some space we used those days, everything made CGJ better. Everything made us better.

See,  we as organizers were producers of 12 games completed that weekend. And I proud of it. Don’t missunderstand me, I’m not claiming any right over any game (except the one I was directly related), but if you are an old follower of this blog you know I just have to be very sincere about what I think, and that’s what I think: We helped over 40 people to transform their visions into playable and finished games. And that’s good not only for the obvious personal consequences, but for the global ones: most of those developers had never worked with such a figure as a producer (or did it just a few times), and now they have. They now know how things should work inside of a well planned game developing team. Now they know how duties have to be distributed. And that’s good. Their standards are higher, their experience is wider and their knowledge is broader.

From a logistic point of view, it was exactly like leaving home to go to college: you suddenly realize those details that make a lot different your experience when you are with your family and when not. We got that, and the next year is going to be even better.

Because, by far, this was the best GCJ: the event, the community, every single attendee grew up in a way we can’t imagine the last year.

In second place, El Potrero is not my game at all, the credits go to Osmel Briceño, René Espinoza y Hernán Ruiz. As that last link says, I was more like a game designer consultant and moral supporter. The team decided to recognize my contributions in the game by including me in it, but make no mistake: the game is not mine, I just watched out the process.

From left to right: Hernán, Osmel, me and René. Thank you guys, I really appreciate what you have done for me

This game is an old school platform game made in Autodesk Maya. Literally, you need to install (and to know how to use) Maya to play it. The reason: the team had no programmers, at least in the usual sense. Actually, the name of the team was NTP: No teníamos Programador (Something like WHNP: We Have No Programmer). Osmel and René are my coworkers in a 3D animation studio, we are part of the technical directors team, therefore their knowledge is focused in making tools inside Maya, and given that no team in the event absorbed them, the final decision was to make a game with what they know. Hernán provided the concept art and general modeling.

The workflow created by the teamt that day gave me an idea. Right now I’m working in expanding the tools inside El Potrero to give artists (maybe basic) tools to sketch their games ideas. I think it is a good way not only for sketching and prototyping, but also to make easier the switch to real game engines such as UDK or Unity whether or not the game is part of a professional or personal project (and also for the work in our animation team).

That last paragraph is a long term goal, but I’m very glad about it because is the result of, as I said, the best CGJ I ever been a part of.

I want to thank all the participants and specially to the fellow organizers of this year: @chiguire, @justyole, @vtrujill0, @lavz24 and @pctroll 

Global/Caracas Game Jam 2013 will be held between January 25-27 . We will be expecting you there.

A couple of videos related:

Global Game Jam 2012 Keynote

Caracas Game Jam 2012 Keynote (spanish)