The Magnate Kickstarter is still in full swing and is very close to raising $50,000 with about 5 days to go. In this post, Jaya Baldwin takes over the reins and writes about what Developers do – one of the most poorly understood roles in the game world.
Wherever you see the game Magnate, you inevitably see the name James Naylor. He’s the game’s designer (and an all round great guy
If a game designer is responsible for the overall vision, design goals and fundamental mechanics of a game, the developer is there help refine and polish that vision. Where a designer might think in broad strokes, a developer will be looking more closely at some of the little details. That description is at least a rough overview of the role. In reality though there is a lot more overlap between the two. The following is a list of some of the core ways in which a developer can help a designer:
A developer can act as a sounding board and a trusted source of immediate feedback
Sometimes a design process can be greatly accelerated just by simply having someone to speak ideas aloud to. It’s an opportunity for the designer to hear their own thoughts and think them through. But of course a developer can do more than just listen, they can respond too. Ideas can be explored and discussed at twice the speed, which means the bad ones are filtered out and the good ones get found faster and then built upon. A designer working alone wouldn’t be able to necessarily verify if something definitely worked or not until someone else tested it. It is very common for James and I to get too carried away here and go down a rabbit hole of fascinating game design ideas until we realise we’ve become completely distracted from the more specific task we had set out to do!
A developer can be a player
This point is as simple as it sounds. For a designer, having someone around that can actually playtest the game with them at any time speeds things up significantly. There are always little hidden problems to ideas that you can’t necessarily see when you’re discussing them academically. Yet playing even just a few turns with a new rule or mechanic can often reveal said problems allowing the team to iterate and move forward. It is also the best opportunity to put oneself in the shoes of the customer. For example, I once lost an early game of Magnate because of a long series of statistically unlucky ‘attract tenant’ rolls. There was an advertising option in the game that could help me manipulate the odds to some degree but it wasn’t very efficient and even then could have still failed. I felt frustrated and like it made some of my decisions irrelevant. Obviously Magnate was not designed to make people feel bad, the dice element of the game is supposed to introduce risk calculation and playing the odds, not blind luck. So we revised the mechanic so that each payer started the game with advertising tokens that could rig your dice rolls completely if spent in advance. This kept all the joys that came with calculating risk assessment and chance while removing the emotional sting brought on by bad luck. The players were now choosing which of their rolls they were willing to take more of a risk on and which ones they wanted more assurance on. This meant when plans went awry, it was more a consequence of their choice, rather than just bad luck. Without being James and I being able to play the game as readily and as often as we have, we wouldn’t have had anywhere near as good an insight into the play experience and Magnate is much stronger for it.
A developer can kill your darlings
Sometimes a fresh set of eyes or even just an outside perspective can help a designer to question elements of their project that they had previously deemed completely finished or immovable. A good example of this in Magnate is that during setup, industry tenants were placed on the neighbourhood tiles rather than the city centre. James had done this because thematically and aesthetically, it makes more sense to have a town’s industry further out. There were some problems that came up as a result of that decision though, it made the setup slightly longer, limited the number of different layouts the neighbourhoods could take and very occasionally created situations where it became impossible to attract tenants. The aesthetic and thematic gain were in line with the design goals, but baggier setup and decisions that could leave players trapped were not. Shortly after I joined the project I asked why the industry wasn’t in the centre with all the other starting tenants for the reasons stated above: It turns out James had designed it that way originally because he liked the theme much more and hadn’t questioned it since. At that point, after some mutual wincing and sadness at the slight hit to aesthetics, we both decided that this wasn’t a good enough reason to keep it that way. Thanks to my question, James realised however much of a wrench it was, it was absolutely the right decision. We made the change and the player experience was improved as a result.
A developer can design too
Some of the earlier examples already hint at this but sometimes if a mechanic or game element just isn’t quite working, a developer can propose a new mechanic or idea that could work instead. They still adhere to the overall effect desired by the designer but they use their own design skills in the creation of an alternative. For example with Magnate, the design for the crash system used to be determined via dice that were generated and lost each round. This generally worked well but could occasionally cause the game to end either too predictably or too unexpectedly. I proposed an alternative involving a deck of cards that involved shuffling steeper crashes in as time went by. We workshopped it for a bit, tested it and it had some of its own problems. James then proposed we split it into 2 decks and remove the shuffling element… the process went on through many iterations until we eventually landed on the crash system we use today. James came up with the very first idea, but after that our roles were very similar, bouncing off each other’s ideas and designing or developing as required till the mechanic served the purpose of the design goal we wanted.
Final thoughts
So that’s just a few ways in which my role as a developer has bolstered Magnate and, indeed, just an outline of the many things a developer can add to a designer’s creation process. There’s plenty more to be said than can possibly fit into one article. However, if you’re left with more burning questions, I’d be happy to answer them. Just let me know in the comments!
Leave a comment