6th May 2014

Technologies and game mechanics – a tentative first draft

At the moment, my absolute favourite game in the whole world in “Castle Dice”.  I bought it about a month ago and I don’t think I can count the number of times we’ve played it since then.  Kids love it.  Adults love it.  I wish I’d made it.

When playing a game it is sometimes hard to put your finger on what it is that makes it so compelling, and maybe trying to analyse it, I guess, might suck some of the fun out of it.  But, being in the business of making games myself, I really have to be able to work it out.

I think the best way that I can describe it is that I feel that Castle Dice is:

  • Elegant
  • Self-contained
  • Well balanced

By elegant, I mean that it feels as though nothing is superfluous or wasted.  Each element in the game serves a definite purpose, which in turn contributes seamlessly to the theme of the game.  Nothing feels like it has been spliced on at the end to make the game more ‘castley’ or anything like that.

By self-contained, I mean much the same thing, but it is more to do with the way the different elements interact with each other.  For example, gaining more farmers will enable you to gain more animal resources or even choose which animal resources you collect.  These animal resources give you the ability to use special abilities which might let you:

  • Take your turn first
  • Hold more cards in hand
  • Gather more resources
  • Change the kind of worker you have placed

In turn, having more resources enables you to build more castle parts (the main purpose in the game).  Some of these castle parts also give one abilities or interact with other elements.  One of the ‘Wall’ parts will give you a victory point if you end the game with three farmers.

This is an example of the Tableau Building mechanic, where permanent or semi-permanent elements come into play which influence your capabilities in further play, or the way the game is played.

There are many examples of these circular co-dependent relationships between game elements, which give the potential for many different, and quite complex, strategies to be played.  Having said that, the basic rules are simple enough for my 7 year old to grasp and understand, so the game can be played simultaneously by players of different ages with equal enjoyment.

The balance within the game, whereby none of these capabilities is more powerful than any other, but can be played in many interesting ways, speaks of extensive and very thorough play-testing, and game designers who really care about the experience they deliver.

Well I can’t create “Castle Dice”, but I do have a game of my own to make.  At the moment I am compiling a list of the technologies, mechanics, story element and aesthetics I want to include – as per Schell’s Elemental Tetrad.  This work continued apace on Thursday and Friday – admittedly without any blog posts about progress, but then a Bank Holiday happened – with all the gardening, barbequing and geocaching than inevitably brings – so I feel like I’m regrouping somewhat this morning.

The technology seems on the face of it to be the simplest element to tie down.  I want this experience to be a face to face event with visually pleasing physical elements that the participants can interact with.  The participants will be playing alone or in small teams and will have a tabletop to work on.  They will be completing records.  From this information I can make a first stab at the technologies I want to use.  A board or similar playing surface will act as a graphical representation of the business they are running.  Counters or similar markers will be used to represent the ‘state’ of the business in numeric terms by being placed on specific positions on the board.  Participants will need to write down certain parts of the business ‘state’ to create financial records and will need to carry out some calculations to create metrics form this data.  So my technology list looks like this;

  • Boards
  • Tokens
  • Pen and paper
  • Calculators

To come up with a first draft for the Mechanics for the game was a little more challenging.  I have a list of game mechanics, compiled from other peoples’ list and from my own observations.  There are well over 100 of them and the list is growing daily.  I keep them on a Rolodex (there’s some cutting edge tech for you).  But how to go about deciding which ones I want to use for this game.

In the end, I just took the whole list and picked out the ones which ‘felt’ right for my game given the theme and the learning outcomes.

Half an hour later I had a pile of more than 50 game mechanics in front of me – clearly far too many.  I needed to come up with a way of whittling down my long list considerably.

I returned to what I had written in my blog post of 29th April, about the experience I wanted my learners to have.  I then created a list of ‘experience categories’, top-level experiences the participants would have.  These were:

  1. Goal setting
  2. Taking Action
  3. Resources
  4. Randomness
  5. Problem Solving
  6. Feedback
  7. Ways of Working
  8. Values and Attitudes
  9. Constraints and Obstacles
  10. Structure

The last one is not really an experience category, more a category I included to help myself, the designer to think about the structure of the game, the glue that will hold the experiences together.

For each of the 50 odd mechanics in the pile I placed it into one or more categories as I felt appropriate. For example, ‘Economy Management’ was placed under the categories 1, 2, 3 and 5, whereas ‘Branching Scenario’ found itself only under ‘Structure’.

By this method, each mechanic received a number of ‘votes’, which I could use as a basis to whittle down my list.  I started with the pile of mechanics which only had one vote (only support one category), looked at each in turn and rejected them if they were unsuitable.  It is important to note that it was not simply a case of throwing out those with the least votes – the numbers were simply a basis for starting to look at what might go.  The important aspect is to examine each one in the light of the already stated learning objectives, theme and desired experience.

Tableau Building was an early casualty, and proved to me the value of this examination process.  Because I am so fond of Castle Dice at the moment, and see Tableau Building as such an attractive and elegant mechanic, I included it in my long list.  On close examination, it has no place in my proposed game (although I really hope I will get to use it in another game).  This highlights the importance of having an objective approach which constantly references what is important, the experience you want, and in the case of a game built specifically for learning – the learning objectives.

The only way to arrive at something as elegant, self-contained and well balanced as Castle Dice is to strip out all the extraneous stuff.  Don’t become seduced by a cool mechanic or whizzy bit of kit.  If it doesn’t add anything – leave it out.


Author:

[social_buttons url="http%3A%2F%2Fwww.gamesforgood.co.uk%2Fblog%2F2014%2F05%2F06%2Ftechnologies-and-game-mechanics-a-tentative-first-draft%2F"]
Leave a comment