Have you ever played a game and thinking that you could improve it, not realizing that your “improvement” made the game worse or caused problems you hadn’t foreseen?
I know I have and there’s a lesson here for those who make solo modes for other designers’ multiplayer game.
I’ve experienced the same thing, I’m a playtester and make a suggestion, thinking it would improve the game only to learn that the designer had already considered the idea and found out that it doesn’t work.
I’ve experienced the exact same thing, when playtesters have given me suggestions on a design I’ve made.
I’m in no way saying that I’m less intelligent than the designer I’m giving suggestions or that playtesters giving me suggestions are less intelligent than me.
Instead I’m saying that a designer who’ve spent a year or more working on a design, likely knows it better than someone who has played it a few times. I’m also saying that the designer is likely to have considered the majority of the ideas that someone who has only played a few times will come up with and since he has chosen to discard those ideas, it’s likely that he has found that, while they sound good on paper, they don’t work out for one reason or another.
This doesn’t mean that when I’m a playtester I shouldn’t make suggestions. Suggestions I make as a playtester can be a good thing – if the magnitude of the change suggested is consistent with the point the development is. E.g. suggesting major changes at the point where the game is in the final balance tweak phase is a waste of my and the designer’s time.
Instead, it means that there’s a good chance that most of my suggestions won’t be implemented, because the designer is naturally way ahead of me and has already considered the same idea.
I’ve seen the exact same thing more times than I can count, when I’m the designer – and believe me, constantly rejecting suggestions from people who’re giving their time freely to help you is not fun, but it’s a necessary part of the game development process.
Exacerbating this issue is the fact that most possible changes to a design will be detrimental, just like the majority of changes to other things, that already work, are detrimental.
Do I really know better than the designer?
When I implement solo modes it’s often tempting to implement “improvements” for the game, while developing a solo, but the exact same thing apply here that I described above. This also includes stuff that’s not rule changes, but making artificial opponents that completely changes the feel of the game.
The game’s designer might have spent years or more working on the game, while I spend a few months.
The game has been through a long period of playtesting, which has informed the designer about what works and what doesn’t.
The game’s designer has focused on the multiplayer game, while I’ve been focusing on making a solo mode.
Furthermore, the game’s designer is likely a much better and experienced game designer than me.
Thus, it stands to reason that the game’s designer knows the game itself much better than me and at the point in the process, where I come in, he’ll have considered and rejected most of the ideas I come up with.
So, for me to change the game itself basically amounts to me barging in and telling the designer that I know much better than him how to make his game, even though I clearly have much less knowledge and understanding of the game he made.
Changes I might make are not only most likely to make the game worse, but in my opinion it also amounts to disrespectful hubris.
To use an analogy that exaggerates in the extreme: The people designing the dashboard of a car, shouldn’t start modifying the finished engine, because they think they know how to make an engine better than the engineers .
This example is so exaggerated so much it’s not even funny compared to what we’re talking about here, but as we all know exaggeration is the path to truth. Well, OK it isn’t, but it can make a point clearer .
A picture of bacon.
What we can learn from IT
A mantra in software development “is don’t mess with a working system” (also known as “if it ain’t broke, don’t fix it). The mantra comes from decades of failures where someone made an “improvement” to the code base only to introduce problems into software that was already working well.
The mantra is even more relevant at the end of a project. The reason for this is that there’s less time to check whether errors has been introduced and so the more changes you make the larger the chance that bugs slip through.
The same goes for my work. I come in at the end of the project and the playtesting of the solo mode made by my team and I is focused on the solo mechanics, not the mechanics of the game itself.
The means that if muck too much around with the mechanics of the core game there is a big risk that something nasty will slip through.
It’s not my baby
As mentioned the work I do is on other people’s games. To me this means that I’m a guest in their home and just like in real life, I don’t start remodeling other people’s homes to my tastes, when I’m a guest, I also don’t start to remodel their games to my liking. That would be disrespectful
So, even if I knew with 100% that a game change would make the game better according to my tastes and wouldn’t introduce any problems, then I wouldn’t make that change for the solo mode, since it’s not my game.
The game is another designer’s game and so I should stay true to his vision of the game.
A solo game of Scythe. Image credit: Rudy Priecinsky
As with all other principles there are exceptions . Solo gaming has some differences to multiplayer games that in my opinion can make changes OK or even required. E.g. in Scythe I made the Automa a bit more aggressive than most human players are.
The reason for this change in Scythe could likely take up a full blog post in itself .
A blog about solitaire games and how to design them. I'm your host, Morten, co-designer of solo modes for games such as Scythe, Gaia Project and Viticulture.
- [+] Dice rolls