I like to browse game forums for titles that I play, and it’s really common to see people saying things like “hey I just had a great idea, I hope the devs are reading this.” Then they write a few paragraphs about their great idea, as if they’re expecting the game’s developers to look at their post and go “Holy shit we gotta do this now!”
And it’s not just a gamer/consumer thing, either. A lot of game developers are still wrapped up in the value of ideas. They think a good idea is valuable, and in particularly bad cases they think someone can be hired and paid to just sit there and think of good ideas. I’ve already written about why game designers are not just “idea guys.”
The thing is, it’s good to be critical of the games we play. It’s good to think about ways to improve them as we play them, or after we’re done playing them. But when you start thinking “why didn’t the game developers do this idea,” you start falling into an unknowingly destructive mindset that can hold you back from realizing your full potential.
There are enough game designers out there who will tell you that ideas are worthless because execution is everything. And it’s definitely true, but I hope to bring in a new perspective about ideas in game design and their overall value in the development process.
Principle of Charity in Philosophy
When you have an idea that you want other people to think of, you are essentially turning that idea into an argument. And once it becomes an argument, it becomes a construct of logic, and standard rules of logic begin to apply. Here, I don’t mean logic as in cause-and-effect and flowcharts, but rather I mean logic as in philosophical argumentation. Rhetoric, persuasiveness, all that jazz.
And in the world of philosophical argumentation, there’s this thing called the “principle of charity.” The principle states that when you’re hearing out someone else’s argument, you need to think of their argument in the best possible light. You should not be trying to nitpick at the small details in their argument, and you shouldn’t think of their argument in worst-case scenarios to make it easier to defeat. If you can defeat their argument at its best possible interpretation, you have truly won. Otherwise, it’s too easy for the other person to say “no, you don’t understand what I mean, so your rebuttal is invalid, here’s what I actually mean” and the cycle just keeps going on.
So if I say something like “Dishonored‘s hats have the best animal behavior in modern games,” you could say “what do you mean Kenneth, that makes no sense whatsoever,” and you would be right. Or you could give me the benefit of the doubt and assume that I meant rats, which are very prevalent and symbolic in Dishonored, and do indeed behave very realistically. Of course, everything would be fixed if I hadn’t been an idiot and mistyped “rats” in the first place, but that’s kind of the point. That was a pretty bad example because it was a physical misspelling, but the same thing happens with mental arguments. People don’t always present their arguments in their best possible light, so if you want to have a meaningful debate, you need to take on that burden even as the argument’s attacker.
If you have a cool idea for something that should have been in a game you recently played, you are essentially making an argument. Your stance is “This game would have been better if the developers did this thing,” and the opposing stance is “No, this game would not have been better (it possibly could have been worse) if the developers did that.”
Let’s take Towerfall Ascension as an example. Imagine if you said “Towerfall would be better with networked multiplayer” and I said “Towerfall would not be better with networked multiplayer.” The same argument happens for games like Samurai Gunn which are criticized for being local multiplayer only. So we’ve created our arguments and we’re about to have a logical debate, and there are two ways we could go about doing this.
One, we could strawman each other’s arguments to hell. You could say “Towerfall doesn’t have networked multiplayer because the dev is a lazy bum who doesn’t want to bother programming it.” Then I would say “Towerfall doesn’t have networked multiplayer because you stupid little gamers only want more features, you don’t want to appreciate the game as it is.” We would both see each other’s arguments in their worst possible lights, and the debate would quickly become meaningless.
Two, we could follow the principle of charity. You could say “Even though Towerfall is meant to be a personal experience shared with others in close proximity, that could still be done through networking if you also implemented a voice chat or smart ping system, and you would also get a larger target audience which means more personal experiences shared, thus fulfilling the vision that the game was supposed to achieve in the first place.” And then I would say “that’s a great argument, but then we run into the problem of internet trolls, the community nature of the game is important to get people into the game.” No name calling, no negative assumptions. Everyone takes the opposite argument in its best possible light.
And yeah, conversations don’t usually get this dramatic. Sometimes, they do (especially recently with the Phil Fish thing, the Gamergate thing, the Flappy Bird thing… way too many things) but when you’re just saying “hey devs I have a great idea, I hope you’re reading this,” it feels like just an innocent little blurb. But if you make an offhanded, absentminded comment about how much better a game would be if it added just this one tiny little thing, you’re making a pretty rude assumption without realizing it: you’re assuming that the game’s developers didn’t already think about your idea.
This is the opposite of charity. This is taking the other side’s perspective in the worst possible light. “They didn’t do this idea because they didn’t think about it,” or “they didn’t do this idea because they couldn’t implement it,” or “they couldn’t do this idea because they didn’t have enough money.” All of these assumptions are casting a negative light on the developers. You are thinking yourself to be better than they are, by assuming that your ideas are better than theirs.
Who knows, maybe some of those reasons really are true. Maybe they really didn’t have the budget or the technical know-how or the idea in the first place. But remember, the point of the principle of charity is not to maintain 100% veracity. The point is to make sure that your argument develops into its best possible form.
Try to think about why they didn’t do your idea. Assume that they thought about it, they had the budget, they had the ability, and despite all of that they still didn’t do it. Why? Maybe they had discussions where someone brought up a good point that shut the idea down. Or maybe they went even further and built a prototype for the idea, only to find a crippling problem with it. These are the kinds of things that you cannot find just by thinking about an idea.
If you can understand why another studio didn’t put your brilliant idea in their game, you can evolve as a game designer because you’re starting to understand more points of views than just your own. It’s too easy to just say “my ideas are brilliant” and go with that, but if you can recognize the flaws in your own thinking, you can fix them and get better. But if you just assume that the game developers didn’t use your idea because they didn’t think about it, you’re not challenging your own position to its maximum stress limit, and you’re not getting as much out of it.
I realized all of this the hard way. I was one of those people who sat there and said “man, why didn’t the developers do this instead, it would have been so awesome.” Then one day, I decided to get up and make those ideas myself. By doing so, I learned that there are reasons why armchair design doesn’t work out.
Case Study: Difficulty in The World Ends With You
So The World Ends With You on DS was my favorite game to think of ideas for. Its mechanics were just so novel and innovative, but the game itself didn’t really hit the ball out of the park with their delivery. Wouldn’t it be cool if there was a pin that was like a Scorpion hook to pull Noise towards you, or wouldn’t it be cool if you could use imprinting on your ally, or wouldn’t it be cool if you could switch controls between you and your partner mid-battle, or… my friends quickly got tired of me talking about TWEWY.
All along, I felt that the main problem with TWEWY was that its difficulty curve was way too punishing. The mechanics were completely alien to fans of action-RPGs, fans of hack-and-slashes, fans of fighting games, fans of anything at all because no game had really done anything like it before. In TWEWY, you control one character on the bottom screen with the stylus, and you control another character on the top screen with the directional pad, and you do it simultaneously in real time. In the heat of combat, it becomes really easy to lose your focus, so usually you just focus all your attention on one character and control the other one by mashing buttons.
The thing is, the difficulty was symbolic. Connecting to other people, understanding other people, matching other people’s rhythm is hard. That was like the whole point of TWEWY, and the mechanics made sure you lived through it. Every time you blamed the second character for dying when your primary character was doing just fine, you felt like the game would be so much easier (and less frustrating) if you only had to control one. But later, as you get better at the game and figure out the controls, you begin to figure out how to use the dual character setup. You start switching your focus back and forth, rather than only concentrating on one. At the highest level of play, you wield both characters simultaneously with equal force. It’s just that that never actually happened, because the game was so difficult.
Then they remade TWEWY. They called it The World Ends With You: Solo Remix and published it on iOS. Obviously, there weren’t any more physical buttons, so I was very curious to know how they were going to implement the control-your-partner system, and it turns out they didn’t. In Solo Remix, you control your main character with your finger exactly the same way you did with a stylus on DS, and your partner was controlled automatically.
Solo Remix was a lot easier to pick up, and arguably a lot more fun to play. However, the original TWEWY was much more symbolic and meaningful within the game’s overarching message. As a designer, this contrast interested me deeply. Frustration and fun are practically opposing concepts, but TWEWY was inherently a story about frustration: the frustration of being unable to relate to other people, which later evolves into the acceptance that different people are different and that we cannot ever simply “understand” each other. Was there possibly a way to blend the two, to create a game that maintains the symbolism but is still intuitive to pick up and fun to play?
These were the kinds of things I liked to think about, and I had whole systems planned out to tackle the problem. I had tons of ideas, and I honestly believed that somewhere in those ideas was the solution. So one day, I decided to make my masterpiece TWEWY rework.
My masterpiece was called Psychic and Gangster. PaG is a one-player, two-character game with simultaneous real-time control on a single screen. It’s played on a PC, so you have mouse and keyboard controls. The game was a combat system proof-of-concept about a psychic and a gangster in a snowy forest fighting off a pack of wolves. And yes, the story was ridiculous, but the point was that I was trying to create game mechanics that were meaningful and fun.
When I was developing PaG, I had three design pillars that I wanted to orient everything around. These design pillars were the major flaws I saw in TWEWY‘s systems and ways that I could solve their problems. My belief was that with these three pillars, PaG would be both fun and symbolic. It would be everything I wanted TWEWY to be.
The first pillar was simplification. In TWEWY, your main character can have up to six different attacks, whereas your secondary character essentially only has one. That’s too much cognitive load to balance simultaneously, so it promotes button-mash gameplay for the secondary character rather than encouraging you to devote attention to them. To balance this out, I drastically reduced the amount of possible actions each character could take at any time: no defensive ability, and only two attacks, a light attack and a heavy attack.
The second pillar was indication. Enemy attacks in both versions of TWEWY happened very fast, so it was too difficult to react to them, especially so when your concentration was split up between two characters. Likewise, both versions of the game compensated by giving your characters extremely powerful defensive maneuvers which only incurred concentration cost, but that just meant the preferred strategy was to have one character spam defenses while the other character attacks. Instead, all of the wolves in PaG have a long windup phase that clearly indicates their striking zone, so you can actually react with a defense rather than having to dodge all the time.
The third pillar was synchronization. Characters in sync with each other are stronger, and characters out of sync with each other are weaker. TWEWY had a “light puck” system that made alternating attacks between characters increasingly more powerful, and Solo Remix had a “sync” system that would charge up your super attack when you attacked a single target simultaneously. However, these were still only numbers: I wanted to build synchronization into the mechanics. In PaG, each character’s light attack knocks enemies back, so it’s viable to just pinball enemies back and forth with alternating attacks. However, if you screw up, you can knock an enemy away from your own threat zone, so you can gimp yourself if you’re not synchronized with your partner.
So PaG was built with all these fancy design pillars and it was totally gonna be a better version of TWEWY. Only it wasn’t. It was still too difficult and new players were getting overwhelmed. I could try toning down enemy health and spawn rates and all that jazz, but it didn’t fix the core problem: the mechanics weren’t working out. It didn’t feel symbolic and it didn’t feel fun.
Why wasn’t it working? Maybe I wasn’t a good enough programmer, and the controls didn’t feel smooth enough. Maybe I wasn’t a good enough artist, and the hit effects weren’t satisfying enough. If I was the head of TWEWY‘s development and I had fleets of experienced artists and programmers to command, I would surely be able to do my three-pillar simultaneous-control battle system justice, right?
But no, those weren’t the answers. As bad as the art and the programming on PaG were, the problem was with the underlying design. I thought I had it all figured out, but the design was still not working out. In order for simultaneous action gameplay to work, each character would have to be so extremely simplified that the game would be unable to support RPG-style character progression.
The TWEWY devs didn’t use a system like mine because it didn’t work. They probably had someone bring it up. They probably had someone write a giant treatise about a two-player simultaneous control system. They probably even threw together a quick prototype to try it, and they probably came to the same conclusion as I did: that simultaneous control does not work in an action context. That’s why they designed both TWEWY and Solo Remix around alternating individual control, rather than constant simultaneous control.
All of my fancy three-pillar theories and ideas ended up not working out. I got to find out firsthand why they would not work out. And that’s just how game design works. Some things turn out awesome, way more things turn out horrible. But I didn’t come up with a revolutionary brilliant system that could make better gameplay than a triple-A studio’s flagship title. Someone up in TWEWY‘s development team was probably as attached to the concept of simultaneous control as I was, and they were probably very sad when they found out that it didn’t work, but in the end they had to do what they did in order to make the game good.
Always Ask Why
Instead of saying “the game developers should have done this,” try saying “why didn’t the game developer’s do this?” And really think about it. It’s hard to simulate a game development environment in your head, but think about all the possible counterarguments, and think about all the possible things that could go wrong with your idea. If you just sit there thinking that your ideas are brilliant, you’re doing armchair design and that does not work.
I still believe it’s very important to be critical of games, but the principle of charity encourages us to be critical in a different way than we would be if we just assumed that the game developers didn’t think of our ideas. Even outside the realm of game critiques, anytime there’s an idea floating around, you can turn it into an argument against an imaginary opponent, and you can start honing the idea down.
A good point I like to ask myself is “would this change make this game better, or would this change push the game in a direction that it’s not supposed to go?” Most games revolve around a core theme, and if you think a new element should be added or changed, it might be a good idea in isolation but it might actually disrupt the whole theme. For example, I like to trend away from random elements as much as possible, but if you took random elements out of a game like Fire Emblem it would completely change the theme that the game is trying to convey. That’s something you can learn by applying the principle of charity to your arguments.
Basically, ideas are still worthless, but they can be made slightly less worthless by applying the principle of charity. And for people who go heavy on theory like me, that can be really helpful. But the lesson to be learned is to iterate, be ready to throw things away, and build quick prototypes to test concepts that you can’t masticate in your brain alone. The principle of charity should be an important piece of a game designer’s concept refinement process.