Archive for the ‘Dark Recon’ Category

Dark Recon: Super Bloque


Amazingly, the development of this game is ongoing.

There is a lot going on with Dark Recon, and I’m glad for that. I can tell that the development process is on schedule even when is quite slow. Our main goal of shiping a balanced demo by december is more achievable than ever, at least view from what we have at this moment. We started in january with that goal in mind, and the odds are in our favor.

Our team has official name: La Vaca Mariposa Digital Ensemble (LAVAMADE), it’s something like The Butterfly Cow (check out the end of this post for more) and also we created an official Twitter account, and the website is on the way.

This time I want to share something Christian Chomiak write for you guys. As you may recall, Chomiak is one of the developers who’s helping me in this game. I asked him to briefly explain how things got together in Dark Recon so far. Following, the text.



Contextual Reference in Dark Recon (IV)


I see colors in the sky.

Contextual Reference in Dark Recon (I)

Contextual Reference in Dark Recon (II)

Contextual Reference in Dark Recon (III)

One of the main problem with the mechanics proposed in Dark Recon is the color differentiation skill each person has. Of course, a particular skill, in a particular game regarding a particular person always will be the central problem. How do you balance a challenge in order to be fun enough to a very heterogeneous group of people that might (or might not) share a common skill; that’s the question you are always looking forward to answer. In the case of Dark Recon that skill is pattern searching regarding color, or color differentiation as I call it. (Color recognition might as well work as a name).

To put this into context, let me share the inspiration behind Dark Recon’s mechanics:


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.


Contextual Reference in Dark Recon (II)


Trying to make a point.

Contextual Reference in Dark Recon (I)

Contextual Reference in Dark Recon (III)

As I said in the last post, I don’t like that much to break apart the experience of the player by creating Game Modes inside the main game mechanic.

I’m not saying that it’s wrong or something. Actually, game modes inside the main game mechanic are very useful, but I think that in most games those changes in modes aren’t that coherent with the main mechanic.

But, what’s a game mode anyway and why I’m introducing the term? first of all, a game mode is what you think it is: those options the game gives the player to try different experiences. Single and multiplayer versions of the same game are game modes; each variation of those modes are modes as well, for example, in the multiplayer case Survival, Capture the Flag etc. are game modes. However, it goes further. If you played Bioshock you should remember that you can hack some machines in the game, in order to do it the player has to solve a Pipemania like game. That’s a change of game mode, the kind I’m interested in.


Contextual Reference in Dark Recon (I)


A few comments.

Contextual Reference in Dark Recon (II)

Contextual Reference in Dark Recon (III)

I wasn’t sure about writing stuff about Dark Recon‘s gameplay, because I didn’t want to spoil the experience; but then I realized 2 things:

  • I’m assuming someone will play Dark Recon.
  • I’m assuming someone is going to read this.

So I give up and I will make a few comments about Dark Recon’s gameplay.

As I said in the first post about it, Dark Recon is a top-down shooter puzzle game (whatever that means). The idea is to combine in a seamless experience the thrilling of a well balanced shooter and the pattern search skills required in a puzzle.

What I was thinking when I proposed the design to the team was to avoid a thing I didn’t like in Alien Swarm (one of our references): the lack of unity in some portions of the game.

Alien Swarm is a great game, but I didn’t like how the experience (kinda) breaks apart in some moments. Is not like that’s a mistake, it’s simply that I’m not totally agree with taking a player out of the general experience. For example: sometimes you have to open a door solving some kind of puzzle, and that’s responsability of one player while the others take care of the perimeter. Something similar happens with the medical class an so on. I insist, that’s not a mistake, but I just don’t enjoy it that much.


Contextual Reference


Things are often funny out of its original context.


Contextual Reference is a set of techniques where you provide the tools to the player in the inmediate context of the game, in order to leave them the duty of discovering the means of a particular situation.

Ok, that was kinda confusing, let’s try again:  when you discover the meaning of a word in a book by the paragraph it belongs, that’s contextual reference; when you discover that your little son (brother, nephew, whatever) is crying and you realize why because you see a broken toy nearby, that’s contextual reference; and so on.

So, you are actually deducing a statement given some clues (which isn’t impressive as a concept), but the idea behind the definition is why or how you deduced that statement. You could derive by deduction the meaning of a word because you have knwoledge about linguistic; you also could derive why your little son is crying because of his behaviour (beyond the act of crying). Those sort of things aren’t contextual.


Puzzle Making vs Puzzle Solving


When a good game designer is not a good player.

Let’s put a thing aside from the very beginning:

Every game out there is a problem solving experience,  so puzzles are involve as a fundamental part of any game in existence. I wrote a post about that point a few weeks ago. On the other hand, it is common practice among game designers to create problems that can be solved in a number of different ways. When you play football there is a lot of possibilities at hand to score. Other games aren’t that open, but still offer a fair amount of freedom to the player.

The idea behind that is to avoid First Order Optimal Strategies (FOOS). Here there something about FOO’s (and related subjects) I posted months ago, but summarizing a FOOS is a strategy that represents the optimal way to solve the problem the game has to offer. If a FOOS exists, there is little the players can do to play the game in a different way,  or in other words: as the problem has been solved, the game doesn’t have anything more to offer.

An excellent example is Tic-Tac-Toe as described by Raph Koster in his book A Theory of Fun. When you realize that any starting position have a very definitive answer in order to win, the game have nothing to offer from that very moment.


Indirect Playtesting


I have a lot to write about, but I will do it about this because it’s easy.

Something weird happened to me these days. Something that has to be noted, because is helping me designing my games.

I did not make this game (just in case).

A friend of mine visits me from time to time with the only purpose of playing games in my laptop. She loves videogames, but right now she can’t afford a console, moreover a PC suited for gaming. So, she comes, we chat, we share, and she plays.

And even when I do think she’s a very good player, it is simply annoying watching her play. It makes feel nervous, angry, stressed and everything which is bad in the world.

So, why I watched her play?.

Because I realized that, somehow, she is validating (or not) my points of view of a particular game, in this case the Half Life series.


Dark Recon: First Milestone


Achievement unlocked!

It’s been a while since the first time I wrote about this project, but by now we have the first milestone in our hand, and even when it doesn’t look impressive it has everything we need to start the next step in the development cycle.

We have divided the process in two big sections: the one concerning the 3D gameplay, and the one concerning the 2D gameplay. Remember that our idea is to merge two different kind of experiences in order to achieve a well integrated puzzle-shooter game.


Project Dark Recon: First Post


There is a post on deck I know  I have to finish it. I’m about to do it.

Because we are game developers, not graphic designers

I finally announce the development of a game project a few friends of mine and I are working on. Project Dark Recon is a humble demo which we want to use to introduce ourselves as game developers.

The main design purpose is to create an isometric puzzle-shooter to show our development skills and attention to detail.

To be honest, the lack of resources we suffer as an indie team won’t allow us to actually create a complete game, the goal is to create a demo in which the gameplay proposed and the execution of it can be evaluated by every each of you and anyone interested.

So far you have seen updates of this game before (here and here), so let summarize a little bit about it.

Our friend Dislocacion (María Alejandra Niño) is giving us a hand with the concept art. She is a very talented artist and I love her work pretty much (I also speak in the name of the whole team). You can see more of it in her Flickr account, and follow her both in Twitter  and Tumblr. (Most of her updates are in spanish I have to say).

The concept art is now focused in defining our main character. Once we have done it, we can pivot the design of the rest of the elements based on that.

We will talk about this later on

In the programming department my friends Jorge Palacios (@pctroll) and Christian Chomiak (@cchomiak23) are doing the deeds using XNA. As mentioned, what we want to do is to integrate 2 different experiences of gameplay: a simple puzzle and a pure shooter. The first gameplay problem that have been taken care of is the puzzle; we decided to define all the elements in a 2D game completely separated of the main game (at first), and that’s exactly what Jorge is coding.

The above image describes the state of the gameplay right now.  We are developing a (literal) pattern search and recognition game: the big grid is a field presented to the player in where he (or she) have to find the color pattern shown in the little grid. By clicking on the squares on the big grid the player (depending if the job was done right) will advance throughout the game.