Contextual Reference in Dark Recon (III)

Spoiling everything.

Contextual Reference in Dark Recon (I)

Contextual Reference in Dark Recon (II)

As I said  a bunch of times before, what we are trying to do with Dark Recon is to merge two kind of experiences seamlessly into one piece of game. I didn’t want to spoil the mechanic, but what the hell, I’ll try to explain it on paper and  later on we will provide you the first gameplay demo in order to do it for yourself.

Long story short: you have to find the little grid pattern inside the big one (as I pointed out in this image using the yellow frame), by clicking in each indiviual solid colored square until complete the patttern. If you do that correctly, the big grid updates changing the patter just discovered; if you didn’t do it correctly a big alarm sounds and kills you… nah, for the moment you can click on the squares to erase a particular choice, so you can choose again until you find the pattern.

(Notice that this time the pattern inside the big grid is actually rotated with respect the original one outside of it).

This is the first experience we want to merge in a single one (the other is the top-down shooter).

So, is this game so easy to design? the fact is that it isn’t that simple for several reason. We actually are creating Dark Recon as two games initally separated from each other; we think in that way we will be able to decompose each one of them and do a better polish work that if we try too create one experience in top of the other right away.

The first thing to worry about (as I pointed out in this entry) is how to teach the mechanics. This is the screen progression of our try in doing so;

(I probably should made more effort in putting this image together)

By trying to teach your mechanics to the player you are actually in the path towards two goals: to teach the mechanics to the player and to understand your mechanics better, which are two things you have to do as early as possible in the design process. Seriously.

Let’s put some attention on the screens. They are ordered with the first one above, and going down from it.

In the first screen you have one red square in the upper left corner of both grids. That’s intentional: it creates some kind of affinity that relates two separated parts of the screen. The cursor can’t be placed outside the big grid, that’s intentional too: that focus the player where the action occurs. In conjunction, those things most of the times are enough to suggest to the player to click on the red square. When that happens, the square is marked with a big white frame and a sound is played. By now, nothing happens if the gray section is clicked; we are using gray as a safe zone color.

The color and position affinity, aswel as the cursor limitation is what designers call Indirect Control; the general idea is: you should never take away total control from the player, but you could take a little bit of control just to point out somehow what to do. Sometimes you don’t take any amount of control, sometimes you need to actually take a big part of it. It depends on the situation, but the intention is to take away the right amout of control so the player can conclude what to do without being told.

Indirect Control is related to Contextual Reference, but is even broader; you can define Indirect Control by using a lot of tools (basically including those not considered by the definition of Contextual Reference). For example, the color and position affinity is contextual, the cursor limitation isn’t. See, that’s important; there is a limitation right there: you can’t move the cursor outside the big grid, but you can move inside of it. That’s why that grid is the bigger one, you can perfectly (in order to increase difficulty, for instance) inverse the functions of those grids, but that would ruin the sense of control the player needs to feel. “Ok, I can’t move outside this box, but it is big enough to actually move. That’s cool” Is exactly the way you want the player to think. They have control, but our intention is to take away the right amount of it in order to point out what to do.

Also, a counter named Correct is presented and updated by one every time the player completes a pattern. For now, it just works as a way to remark the idea of progression. The square is in the left corner for the obvious reason: if the first thing you see while checking.

In the second screen there are two squares intentionally very contrasting. The player should have an idea of what kind of color spectrum to expect in the game. Complementary colors, most of the times, imply a bigger distance in the color wheel, which says to the player “There will be a lot of colors”. Now the player has to click twice in order to advance, this will player the chance to choose what color to select first, and in this game that doesn’t matter, so the freedom of doing it in whatever order they want is left untouched. When clicked, the square is highlighted with a white frame that doesn’t disappears until the square is clicked again (deselecting it). The freedom to click again in a square is also there. The player can experiment with those actions in this screen.

The third screen shows the same pattern in the big screen, but it is rotated in the little one. Why? in this way we want to remark that the order of clicking doesn’t matter (by leaving the same colors, we could have changed the color), and introducing a new idea: the rotation doesn’t matter either. You have to complete the pattern no matter how is presented. Notice that this time the red squares don’t share positions (one is in the corner in the little grid, the other one is not in the corner). We want to break the affinity aswel to, again, remark that the order or the rotation aren’t being considered for the challenge.

Three squares are shown in the little grid on screen number four. Why three instead of four as presented in the big grid? to introduce the idea of failure. This time, both patterns are position related (by the same reason exposed above). No matter whether the player completes or not the pattern correctly in the first try the idea of failure is introduced. If the player did complete the pattern correctly, the game advances, giving the idea that clicking the green square wasn’t necessary. If the player clicks on the green square, a sound is played pointing the mistake. At this moment the player can apply the deselecting skill learned before, or try it for the first time here.

As I said, the player have to click again to deselect the square. The other option (to not frame the square at all in the first place, just play a sound) is equally valid, but I think it unnecessarily takes away control from the player and forbids to create further challenge in the game.

The remaining screens show the big grid being colored until is full, and by that moment the game begins. The fifth and the sixth screen show contrasting and not that contrasting colors (respectively), and then the last screen a mix of them. What we try to communicate is which kind of colors in the color spectrum to expect, as I said before.

The music we are using by now is choosed in order to, again, remark the idea of  clicking and then go with the flow. Listen by yourself.

I found in playtesting that these elements work quite well to show the mechanics to the player: it never takes too much control away from the player, remarks every single action and skill needed;  it is inmmersed in the real gameplay and it never feels as what it is, a tutorial (again, based on early playtesting). Actually, we count as correct every each of those steps (even when there is no real challenge whatsoever) to remark the idea that player is playing from the very beggining.

I mentioned a use of contextual reference in this entry, so you can realize the way we are using it in general. In the next post of this series, I will talk about the problems we are having in the design of this game, and how we are trying to overcome them with the use of game design tools, specially contextual reference.

Note: if you check carefully, you will notice that the Correct counter doesn’t match the number of screens showed. That’s my mistake doing the screencapture, while playing it works fine.

Tags: , , ,

3 Responses to “Contextual Reference in Dark Recon (III)”

  1. Contextual Reference in Dark Recon (II) « Lakitu's Dev Cartridge Says:

    […] Contextual Reference in Dark Recon (III) […]

  2. Contextual Reference in Dark Recon (I) « Lakitu's Dev Cartridge Says:

    […] Contextual Reference in Dark Recon (III) […]

  3. Contextual Reference in Dark Recon (IV) « Lakitu's Dev Cartridge Says:

    […] Contextual Reference in Dark Recon (III) […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: