“YOU WANT PLAYER INTERACTION, DO YOU?”, I screamed silently at a playtester at the UK Games Expo, “THEN YOU’LL HAVE IT. SO THERE.” We were coming to the end of our playtest and I had enjoyed it immensely: the meet and greet, the uncertain rules explanation, the lightbulb moments, the bottlenecks, the frowns, the smiles. Finally one of my new friends looked me in the eye and challenged me to include take-that style player interaction in the game. I felt motivated and excited in a way I had not experienced for a year and a half.
Lockdown had accelerated my descent into what I call the “eurogame tunnel”: a mindset in which designers prioritise mathematical rigour over the needs and wants of their players. I’m not knocking the solid mathematical basis of most (all?) eurogames; I’m saying that time spent perfecting it could be better spent out in the community understanding the emotional effect it has on players. The latter was hard to do in the online echo chambers we occupied during lockdown.
Here are some other eye-opening moments from the UK Games Expo:
- “We don’t need more game designers; we’re looking for scenario designers to develop our upcoming game.”
- “We’re looking for lightweight eurogames to fit into this series.”
- “We sell novels set in the universes of published games. Here’s a list of the authors.”
- “Companies commission me to design expansion packs.”
- “I’m thinking of starting a podcast.”
- “We commissioned someone to run a computer simulation of our game.” (click here)
My response to all of these was “I could do that”. Not right now, perhaps, but time and patience are both on my side. Are simulations really that different to the exercises I’m doing in my coding course? Are these crowd-pleasing fantasy novels really so hard to write? I was about to try and sell myself as a freelancer when I found a job I actually liked and was bought gently back to Earth. For the time being.
Perhaps game designers can define themselves based on the contributions they make to the community, rather than the games they themselves design. We often equate “community” with “industry”, which might explain the slow creep of eurogame concepts into my designs. I’m happy with this: I can do resource-based games now, engine builders too; I have learnt what a “stock market” is. But before I lost sight of my roots all together I decided to give free reign to a very silly asymmetric area control idea:
Island project: making the prototype
What’s this, a diary within a diary? I’m afraid so: this blog, as you may have noticed, is more about reflection and entertainment than actual notes on a game. I’ve been meaning to rectify this and Island seems like a suitable project. Have you read what Alex Sayenko of envatotuts+ has to say about development diaries (click here)? I haven’t but maybe I should, even if it is about a team of people working on a video game. Or perhaps you can recommend something to me.
My objective is to replicate an aspect of the Total War video games (click here): the exciting fusion of tactical battles with a grand strategy world map. Eventually an idea walked into my head: what if I fused the two aspects by setting both on the same board? The island of Sicily circa 250 BC would make a good, finite setting and provide opportunities for three asymmetric factions. Players would essentially be playing a game of X Wing: the Miniatures Game directly on top of a game of Go, and wrestling with the least realistic farming mechanic I’ve ever encountered.
[syracuse] = syracuse.png
[temple] = temple.png
[gold] = gold.png
I started by collecting all of the symbol files I would need in one folder, and writing the above chunk of code to allow Nandeck to refer to them. Writing this was very inefficient: in hindsight I could have generated it on Excel or, even better, defined a Nandeck “macro” and simply fed the file names in. Despite their flaws I could copy and paste these lines into any code used for the project.
Next I worked on the asymmetric (different for each faction) aspects of the player boards. I taught myself to extract specific values from an Excel file using Nandeck. In the past I have done this with image file names and then written the image coordinates in Nandeck; here I was essentially creating a “coordinate file” which did the opposite:
The advantage of this method is that the coordinates of each image are linked to the others: move or resize one and they should all adjust accordingly. It would also be easy to distinguish between images unique to just one player board and those present on all three.
I decided to put the information relating to the three troop types on cards and the troops themselves on blocks. The latter proved a challenge because my usual supplier of board game pieces is based in Germany and no longer ships to the UK (I wonder why). Once again my old Lego collection came to the rescue:
The next coding challenge was to reproduce each troop eight times to give players the correct number of pieces. This was surprisingly hard on Nandeck: the “Copycard” function assumes you want a row of originals followed by several chunks of copies (a pain when cutting out) and is executed right at the end of the process (giving you less control). After a mess of “start block” and “end block” variables I was happily generating eight blocks at a time; Nandeck inexplicably crashed when I tried upping it to twelve blocks.
Seeing the blocks in the flesh I was reminded of a problem I’d encountered in Master of Olympus: crowds of 3D pieces can make it difficult to see information printed on the board. I would have to make the boundaries between regions very clear; my (low tech) solution was to cut them out by hand and stick them together. The board would need to be modular for practical purposes anyway, and this approach would make editing or resizing the board quick and easy.
There was still drawing, sticking and laminating to do; this had turned into the most laborious prototype I’d ever made. Luckily I had some playtests scheduled to keep me motivated, and the outcome of these will form the next diary entry. Thanks for reading.