Monthly Archives: July 2013

Procedural detective/forensics game plans

I’ve been finalizing my Infected card game, currently getting more people to test it out… (who would have guessed this takes time with physical decks).

Meanwhile, I’ve been doing research for a procedural murder/crime/detective game. A game where crime would be procedurally set up. Here’s an example story that might happen…

(Please notice this is a murder story. Just letting you know, in case you happen to be sensitive about that sort of stuff)

You are a fresh investigator: newly promoted detective who has just arrived to his first murder scene. Victim is Mary Arrington (a 33 year old white female. The person who found her body is Peter Ash (41 year old white male). Peter is in shock. The victim was shot once to head (front).

There’s Peter’s fingerprints all over the place.

You can choose to discuss with the suspect (everybody is a suspect), Peter, about what happened or examine crime scene.

By looking around, there’s several clues to be found:
- sock prints (unidentified)
- place is clean: no breaking & entering
- not a burglary: no jewelry, or wallet taken
- Peter’s fingerprints
- Hair prints (unidentified)
- Bloodstains

After talking with Peter, you found out some other information about relationships:
- She had no enemies.
- Peter was Mary’s new boyfriend (begun 2 weeks ago)

Interviewing Mary’s closest friend Joan reveals:
- Mary broke up with Rick (white male, 33) couple of weeks ago or so
- Rick still loves Mary
- Rick hated Peter

From this evidence, the investigator might conclude that Rick should be interviewed: he has a motive (hurt Peter by killing Mary. Use of gunshot so that no pain would be caused, as Rick still loved Mary and didn’t want her to suffer).

Sock prints and bloodstains suggest that Mary knew her killer – there was no fighting.

Of course there could be further clues, evidence and other things to examine but anyways the main points of the story are listed above…. and this is something that could be procedurally generated.

Back to development
I was wondering how could a murder story be procedurally generated, and first obvious problem is dialogue. I concluded that it might be worth trying by having no dialogue at all.

Then I proceed planning the characters & relationships generator: it’s quite straightforward to procedurally create characters (gender, age, appearance, history and so on), their relationships with each other (A hates B, loves C is neutral towards D etc). Then there can be some event or series of events (Mary breaks up with Rick). So far so good.

By creating a motive, the system could then generate more facts on how the murder was done. Planned? Unplanned? Was the person careful or reckless (=reflects killer’s personality). What’s the weapon of choice (did killer want victim to suffer? do the kill silently?) – all these could be based on the generated character.

Then there could be procedurally generated murder location & place.

And so on.

The main focus would be on variety of objects, events, characters and relationships. Not with graphics (graphics, as far as I’m concerned, could be just colored rectangles or something).

The nagging thing that remains in my mind is: would it be interesting to play? With procedural content, you will get some silly cases too… who knows if at some point the system generates a story where grandpa murdered his wife using a cane because grandpa hated flowers grandma brought to home because of traumatic flower incident grandpa had at his childhood.

I keep thinking a bit more.

It feels this might be worth prototyping.

A lesson about dependencies when creating a physical board or card game

I’ve been designing, re-designing, re-re-re-designing my The Infected card game, and I’ve come to realize there’s one huge challenge that I could have tackled differently. Now it’s too late to do pretty much anything, but to my future self: read this blog post.

Use icons, symbols rather than text
This is hugely important lesson. This way you can create a layer between card (or piece) and the action that occurs after use of the card. Rather than having “card -> action” (e.g. “card states heal 2 wounds”, you’ll have “card -> icon -> action” (e.g. card has an medkit icon, which meaning is explained in a rulebook: “medkit icon: heal 2 wounds”).

The reason is simple: Whenever I’ve made changes to the game rules… I might end up needing to alter several card texts or reprint some of the cards.

Helps you test & change rules
Here’s a simple example: rather use “Heal 3 wounds” as the description text of a medkit, simply have a medkit icon there. And write to the game rules that “medkit icon” means you get to heal 3 wounds. If you later want to adjust the medkit to mean that you can heal “2 wounds”, you can simply do this by adjusting the rulebook. No need to touch the actual cards.

Sure, later you might still need to ensure that medkit also means “draw a card”, and then you must add a card drawing icon on the card… so there’s cases when icons won’t save you. Many times they can though.

Translation
And what happens if you want to translate the game to other languages? With symbols or icons it’s pretty simple: you only need to touch the rulebook. With text written on the cards… not so straightforward.

Playtesting
And then letting others test your game: if you can improve your game by changing the rulebook, that’s pretty handy.

Updates!
And let’s not forget game updates later: if you want, you can tweak values of certain cards even after publishing the game. If medkit should have been “heal 2 wounds” instead of “heal 3 wounds”, it’s really simple modification to do & share to the players of your game.

This approach doesn’t necessarily work for all type of games, but for many games this type of thinking probably can come handy.