Recon Tabletop Game.
A little late, but as I said in the last post, a lot happened to me and the country I live in.
One of those things that had a lot of work these months is Dark Recon. I’ve been very low profile about it, but the truth is that Dark Recon suffered a transformation for the good, and I’m very excited. Of course I will update this blog with all the information regarding design and development of the game, but for now you can check Christian’s blog (remember that Christian is one the programmers in my team): Bonus Disc. There is a few post dedicated to Dark Recon and game design/dev in general worth reading.
I’m studying Game Maker and Unity (UDK is on standby for now), because I need a tool to express my ideas. I huge mistake I made is to rely on others (like my friend Jorge) to prototype, and that’s just simply stupid. You, as a designer, need to have the skills to prototype (and even complete) games with any tool you think is suitable. I’m not a programmer in the sense of computer scientist, but as a matematician I have a solid background in coding (and right now I’m working with PyMEL and starting with the Maya API), I need to redirect part of that energy towards tools that allow me to express my design intentions. Right now those skills are somewhat limited.
(It’s worth mention that my postgraduate studies will be directed to computer science. Working on it, more on that later)
That said, this game is a wildcard I’m using while I’m improving on Game Maker.
Recon Tabletop Game is a, quite simple, tabletop game created to share my ideas about Dark Recon to the team I’m working with. One main mechanic of the game is described in this game, and the tabletop version has the purpose to communicate that mechanic, to brainstorming about it and to think in the best way to start the implementation.
At this moment, this mechanic is waiting to be implemented. As I will tell you later on, Dark Recon is focused in other aspects of the experience that the programmers found more fun to work on. Literally, that’s the reason why. So, if we won’t find any reason to include any other mechanic, we won’t. My job as a designer is to create the best possible experience given a set of resources. If the energy of the programmers isn’t well spend on this or that feature, because is too hard to implement, or too expensive or just not that fun to create, there is no reason I could fight that. Remember that game design is suppossed to be an experimental process, you should come to the best solution with a given set of constraints. Our constraints are those mentioned.
I have to say that it’s very liberating and fun to work that way. Seriously.
Given all of that, let me share with you the basic rules of Recon Tabletop Game and a few notes about it afterwards.
These game is not, by any means, a balanced or even finished game, is an idea that could (and should) be improved by those interest in it. We made this game as a mean of communication, not as a game by itself. These are the main instructions:
You can build the very basic version of this game using two sheets of paper, a ruler, a scissor, a clock and a lot of colors, but I highly recommend to use a computer package to print the board. You could use from Photoshop to Illustrator, Paint, Word or Excel.
You will need the scissor and the clock nonetheless (or equivalent tools).
The details are as follows.
Instructions to create the board:
1.- Whether you are making it by hand or in the computer, you have to reproduce two grids filled with colors, the point is those grids have to be exactly the same (that’s why it’s easier to create the original and the copy in the computer). This is an example.
I used MatLab, which is a specialized math package that I’m very used to. I literally wrote two lines of code that can create grids of any size and any distribution of colors. If you have any experience with a computer language you should be able to create a similar result; but as I said, you can even use Excel for this task.
If you want to create the grid by hand these are my suggestions:
- Create both grids in each paper sheets using the rulers.
- Once that’s done, fill them with colors one at a time in both grids. That would reduce the effort necessary to create two exactly equally distributed grids.
Sizes?, number of colors? I leave that to you for now, a few comments at the end, but you should start with a number that is multiple of 4 for the grid, and the number of color should be proportional to the size of the grid.
Lets name those grids, one is grid A and the other is grid B.
2.- Now, take grid B and cut in to pieces of at least 2 by 2 squares. That’s why it’s very convenient a multiple of 4 grid size. Put those pieces in a bag or a box. I will call these little pieces Patterns.
Instructions to play:
The main idea of the game is to find the greater number of patterns in the grid A given a amount of time. More specificly:
- Put the patterns in a box or a bag.
- Set the clock to a given amount of time, I suggest one minute and thirty seconds to start with.
- You should ramdonly pick a pattern from the bag, and find it in the grid A. To validate the finding you have to put the pattern where it belongs in the grid A, and then put it apart from the original bag.
- Repeat the process, as quickly as possible, until the time is over.
You could play this game in a solitary mode, or in group either of individual players or teams. The idea is to set the conventions before start the game. Of course, the winning condition is that individual or team that has the greater number of patterns found.
As I said, this is not a finished or balanced game, the idea was to give the programmers a comprehensible set of rules to implement the basic mechanic and start the work from there on code. Of course, I have some basic notes about the initial setup.
I recommend to start with a multiple of four grid size, better is the grid is exactly squared, and a proportional number of colors. Example: if you start with and grid of 16 squares (4×4 grid) you should use 4 different colors and try to distribute them as randomly as possible. If you start with a grid of 64 squares (8×8 grid) you should use at least 8 different colors, but a number of 6 proved to be suitable if you ensure a ramdon as possible distribution. The numbers are based in playtesting (a very limited one) and how playtesters responded to the game experience, but those numbers aren’t written in stone. (See the link in the next line for a very important remark)
There are some very technical mathematical considerations you could take into account, like this one, but I won’t get into that in this post
The main advantage of these design is that it is the canvas for a lot of variations. Grids don’t have to be perfectly square, neither the patterns (but you should respect the restriction of at least 4 square per pattern). Actually, the grid could have any shape you want, and doesn’t have to be restricted to squares.
A powerfull idea of scalability and ductility is want interest us the most. The basic skill is pattern recognition, you can’t get more basic than that, so the result of that basic skillset is that you have a very big space of possibilities for gameplay. We are working with that frame in mind.
A closing comment:
I don’t want to extend this post any further, this was sort of an introduction. If you are interested in game design and balancing, I encourage you to start balancing a set of rules for this game, and moving onto other thing when you are glad with the result. You can publish that set of rules (when sufficiently balanced) and if you like, share it with us.
One big part of Dark Recon is the mechanic explained above, so we have a basic balanced mechanic based of this board game, and the videogame implementation will start with that.
I hope this could be a start point for any of you, and a fun game to play (if you have a little patient the first time you play it trying to find the better configurations)