I spend my evenings designing and making games and so far I’ve finished two of them. One board game, and one video game. It’s fun showing people the finished products, but as each of these games took more than a year of my evenings to complete, I thought it would be nice to document and share some of the things I’m doing and learning as I go. Otherwise it’ll be a year before you hear from me again. And in this particular case, it’s a project that will probably never see the light of day – as I’ve decided to kill it.
After shipping CAAARGH, doing a little bit of zero-budget marketing, and taking a couple of weeks rest from working every evening I was itching to start on my next game. I have a backlog of designs ranging from CAAARGH scale projects (equivalent of about three months full time work) through to projects that would need many people and much time and far too much money. And I wasn’t ready to commit to one in particular yet.
Then I saw an email from the Game Crafter, mentioning a couple of new design competitions running on their site. I decided to look at the Minion Games competition to design a dice game for the Manhattan Project series of games. The scope was reasonable. The deadline was close enough to focus me, but far enough out that I could get something together and do a few play-tests and design iterations.
Also, I’d been dipping into Reiner Knizia’s Dice Games Properly Explained, so had been toying with some dice mechanics in my mind and thought this would be a good place to try them out.
The existing Manhattan Project games pride themselves on having low-luck mechanics which I thought could pose a challenge for a primarily dice driven design. The angle I thought could make this work would be to focus the gameplay on the people of the story (as people are individually unpredictable, but mostly predictable as a group).
The loose design in my mind was that you would use the dice to hire people, and other dice to apply their skills towards building weapons, and then use agents / spies to compromise the hired people to learn the location of weapons, which in turn could reduce their final threat level / score. Or something like that.
I’d been trying to keep short notes about what I worked on each night, with the intent to write more blog posts like this. Some nights I do 30 mins work, some nights it’s a couple of hours. But it’s mostly progress by lots of small steps.
15 June
- The blank dice I’ve ordered arrive in the post and I start playing with components and sketching cards.
- How can constructed weapons be linked to an individual scientist / engineer?
- All constructed weapon cards have to be placed on an engineer or scientist to identify their knowledge of the weapons location
- If the knowledge of the weapons location is linked to individual, it encourages players to hire more people to distribute their risk
- If some scientist has more skills and a player risks them having much knowledge, how can a player protect them? How can this come with a risk / reward mechanic?
- What if you can sacrifice an agent to try and prevent a compromise? But roll of a dice determines if you are successful?
- Can the back of the agent card double as an icon to show someone has been compromised
- Can a compromised person still contribute to new weapon construction? Maybe yes, but it affects where you can place the cards
- How to make different scientist / engineering cards interesting and worth considering?
- Idea: Each comes with a number of skills and dice powers – or a dice roll needed to unlock
- How to get risk reward into the play?
- Maybe need to declare which weapon they are trying to build before rolling
17 June
Looking at some basic calculations to work back from competition brief to think about possible number of cards and dice
|
Max play time
|
60
|
|
Turn time
|
0.5
|
|
Total turns
|
120
|
|
% of time spent building weapons
|
50%
|
|
% win rate for building weapons
|
50%
|
|
Max weapons everyone can build in a game
|
30
|
|
Weapons built per player (in 4 person game)
|
7.5
|
- In a typical game you should expect each player to build up to ~7 weapons cards
- This gives us an idea of how many staff each player would hire, if weapons are assigned to staff in some way. Approx 5.
18 June
- Looked at possible distribution of Victory Point values across weapon cards
- Assuming a threat value and a defensive value gets to an idea of relative cost
- This can later be used to work out probability for dice combos per card
- Also realized that the Manhattan Project era is earlier in the nuclear arms race than I was picturing in my head
- Weapons probably need to be variations of atomic bombs rather than subs / facilities etc
- Need to research categories and ratings – e.g. Mega-tonnes
- I also found the rules for the main Manhattan Project game which gives a better understanding of the universe and the tone: http://www.miniongames.com/rules/Manhattan_Project.pdf
19 June
- Picked some starting points for number of cards and number of dice to use in the game
- Working back from the target playtime, this ends up being smaller than it maybe was in my head
- Currently at
- 30 VP cards
- 26 people cards
- 17 dice
- Might also end up with the people forming a single deck for hiring from, rather than one per class as the total number of cards available is small
- Pretty happy with the hiring costs and hiring die calculations, but need to work out how those relative strength scores map to fair abilities to gain victory points
20 June
- Worked out a system for turning dice rolls into building / purchasing power in an interesting way
- Now need to work out how to balance this systematically WRT to purchase / value
21 June
- Debated trying to balance the cards using brute force software iteration, or building up the values from a spreadsheet
- Built a spreadsheet that lets me evaluate the value of individual staff cards in relation to the VP cards, but not sure if I’ll need to do more to get this to work with combinations of cards. This might be enough with some eyeballing of combinations.
- Need to plug in more values now and work out how to turn these scores into hiring costs
22 June
- Allocated skills to scientists cards
- Decided we need 16 (10 jnr, 6 snr)
- Used these to calculate probability of each card scoring against each symbol combination
- Used the average likelihood of scoring a given combination to assign values to each combination
- Decided to use 2 of each possible combination to create 30 science halves to the bomb cards
- Multiplied the value of a combo by the likelihood of each card getting it to create a per combo value for a card
- Summed these, and normalized them against a scale of 1-4 to create a hiring cost
- Tweaked some card values to get a better distribution of hiring costs across the pack
- The combined score of this with the engineering equivalent will give the total card score
- These will need to be even combinations to
- Added some non-scoring variants / impacts to the dice
23 June
- Worked on the card variations for the engineers following the balance model used for the scientists
- Did some spreadsheet jigery pokery to get the balancing view of the data into a simpler format for CSV export and use with nanDECK
- Installed nanDECK
25 June
- Read the nanDECK manual
- Got the data from my spreadsheet hooked up and started learning how to layout the content
- It’s pretty great how quickly it turns data into a printable set of cards for prototyping. Would have saved me a few nights of work spent on Moving Out card testing.
- Also, it’s so quick to make changes that I think it will support quicker (and therefore more) playtesting and design loops
26 June
- Fought with nanDECK syntax
- I’m sure it can work, but it felt like too much effort
- Trying to use Squib instead but fighting with installing Ruby versions on Windows
29 June
- Squib is up and running
- Setup git repo and project directory etc
- Worked through some examples to get a better feel for how Squib works
- Being Ruby based there’s no new syntax for me to learn, and the documentation is really good.
1 July
- More Squib learning
- Setup data, basic layout and some card background colours
2 July
- Get some icons rendering dynamically on the science / engineering cards
- Choose 8 icons for initial playtest (using game-icons.net)
3 July
- Finished reading the excellent book The Art of Game Design and was playing with the Deck of Lenses app as a way to review the design so far.
- Got to The Lens of Love
- Do I love my project? If not, how can I change that?
- Decided to think about this
4 July
- I like a lot of things about the mechanics, and I think this could be turned into a viable commercial game fitting the design brief. But I was still pondering the question. Do I love my project?
5 July
- North Korea tests a new missile, and it dawns on me I don’t want to spend my evenings designing a game playfully themed around building Nuclear Weapons
- So I stop.
- That’s not to say there shouldn’t be any games about this.
- There are already many, and some are especially good. And games can be a great way to teach people about nuclear proliferation and dynamics of power and so on, but that’s not what I’m motivated to do in my free time.
6 July
- Write this blog post.
- Start on the next game.