Communication is a Game Developer's greatest skill

I must admit that this article was originally conceived because of a frustrating experience I just couldn’t let go. But the general point ended up strong enough that I decided to keep the article and make it a bit longer.

Some time ago, I participated in the Pirate Jam: a jam hosted by PirateSoftware (on itch.io) twice a year. I only entered very late because I had other deadlines to meet first, which meant I had no illusions about creating a high-quality game or getting a good final result. I only checked the results a week after they were released, because I’d forgotten I participated in the first place. My game ended up middle of the pack (~1000 out of ~2500)—fine with me!

The unique part of this jam is that you’re required to also create a Game Design Document (GDD) and add it to your submission. It’s one of the reasons why I wanted to join: to practice doing this thing that people say is best practice, but I rarely ever did. So I spent a good amount of time on this document, explaining all the steps and considerations in clear and concise paragraphs, sticking to their example document as well as possible.

Then I saw my anonymous feedback: “No proper GDD, which was required”.

What? Que? I checked: yes, I’d done exactly as instructed, the file was there in the right place, nothing wrong. They said no PROPER GDD, which implies they had received the file just fine, but they just didn’t deem it “proper”.

I checked some of the winning games. Their document was often far shorter, with a terrible layout, unclear sentences, and vague statements about what their game was supposed to be. Yet they were judged to be just fine—they won! Despite some having clear bugs or mistakes in the game, I might add. (This will be important in a minute.)

What was the issue?

What was the issue? I don’t fucking know!

The only difference I can see is that those documents had a few more images than I did. And I wrote two informal remarks somewhere about my hardware failing and thus switching to a different workflow last minute. That’s all.

Was I really being penalized for not realizing the magical unwritten rule of “you need to add more images”? Was it so bad to actually update the document with a realistic account of what happened and a joke about how my bad hardware forced me in a different direction?

It seems to be that way, which is my first point of frustration. In the world of making games, where you have 1000s of tasks even for the simplest idea, an image/joke more or less is really insignificant. Focusing on that feels incredibly close-minded, mean-spirited and far away from the spirit of creative game development.

My second point of frustration, though, is that I can’t know.

• The judge felt no need to add a single sentence explaining why it wasn’t proper. (They did add some other sentences specific for my game, so it doesn’t feel like they were rushed or never even played my game, which is why I don’t understand how a single extra sentence would be too much effort.)
• The rules for the game jam have no strict guidelines, tips or “how-to"s for creating that GDD. (It’s like telling someone you will grade them for drawing something, but you don’t tell them your secret requirement that they must draw a lion with a blue pencil. And then, when they made their best attempt at drawing something, you tell them it’s not a proper drawing and get mad.)

If I made an actual mistake with my GDD, now I can’t learn from it. (And yes, it’s certainly possible I did something wrong or made some stupid mistake somewhere, I won’t deny that. I am the king of doing the hard things right and screwing up the obvious things.)

If I made no mistake, and this is just random strictness or a misunderstanding, then this extra communication would’ve helped clear that up for me.

It’s the same everywhere

It reminded me of my terrible days in the educational system. Where, almost every single day, you are graded and judged but they won’t actually communicate what they’re looking for or how to do the thing for which they judge you.

At university, I once handed in a paper (a group project) for mid-semester evaluation, and received the feedback: “looks fine”. Just that. Nothing else. Nothing crossed out, no scribbles from a red pen anywhere, everything was “fine, nothing to add”.

What was our grade? Insufficient, barely. (On a scale from 0 to 10, we received a 5.0, whereas a 5.5 was considered sufficient.)

What? Que? Of course we asked them why, but they told us nothing. They didn’t want to disclose their actual, specific, hardcoded criteria for judging that paper because it would make it “too easy” for us. Or, as we thought, they just didn’t have any and didn’t want to reveal they were making up nonsense grades as they went along. And this was at one of the best universities of the Netherlands and one of the most prestigious bachelor degrees!

This is pure nonsense. Randomness. Chaos. There is nothing of value going on here. (Which is also why I maintain the entire system of education is built on meaningless quicksand and should be treated as such, but that’s a different matter.) Yet this is the pervasive structure present in pretty much our entire world.

Parents tell their children to sit up straight, yet never teach them about good posture or useful stretches. Schools tell their students they’ll be graded, but don’t tell them on what or how exactly. Game jams tell you to include a Game Design Document, then do nothing more than give one specific example of a “proper” GDD. As if that means anything. My game is obviously going to be different, so my document will inherently have different content/headings/images, so what exactly does this one example accomplish?

When I saw that, I’d assumed they’d be extremely lenient. I’d assumed that “anything goes, just write down your plan, steps, vision, general approach”. I mean, if you’re going to be so lax and careless about your restrictions, then that is obviously the only way to make it work, right?

I just don’t understand.

It seems such an obvious rule to me. No, it’s not even a rule, it’s the inherent founding principle of “testing” or “judging”. You can’t grade or rank anyone on anything unless you have clearly defined objectives or measurements. You can’t have any judging going on unless you have taught the principles or aspects of the very thing you’re judging.

Yet almost nobody in the world feels the need to actually communicate this.

Similarly, many teachers think that a test should ask “new questions” or “be about something not in the book”. No, no, no! It’s in the word: test. You’re testing if the student has read the book and learned the material. If you assign them chapter 1, then your test can only be about things 100% in chapter 1. Otherwise you’re not giving them a test; you’re giving them a random problem.

Since I was very young, I’ve said that every person only needs two skills: logical thinking (to actually solve problems) and communication (to help the others use your solution). And the older I get, the more proud I am of that statement I came up with long ago. Because it’s true. Almost every problem, frustration, or failed creative idea comes back to incredibly bad communication. Whilst the offenders don’t even realize they have failed so horribly, because communication is just not something many people focus on or think about, so they never see its worth or train to improve.

Bringing it back to game development

Which brings me to my main point.

“A game is nothing more than a set of challenges testing the player. Make sure you clearly communicate what is being tested and the steps to passing that test to the player.”

If you don’t communicate this, the game just becomes random contrived problems to solve. And nobody likes doing that for fun.

If you only communicate what is tested, but give none of the steps to reaching that, then the player will just fumble around in the dark until they randomly stumble upon the right answer. Also not fun.

Practical Example: Puzzle Game

Let’s take a puzzle game, as that’s the simplest example. A popular approach here is to “let the player figure it out completely”. You want absolutely as little text or instructions/tutorial as possible.

In practice, however, this means that many game developers just don’t communicate. They expect the player to try for an hour until they happen to figure out what the game actually wants and which individual components are available to them to accomplish this. Which, as my experience playtesting failed puzzle games shows, is not true. Players just give up after a few minutes—frustrated, not having fun—and move on.

No, the idea is that you communicate very clearly. Just not … with words, perhaps. Or with a big tutorial screen. And certainly not by leaving out key information completely so the player “can have fun discovering them”.

• If the goal of the puzzle is to reach some flag at the end, then make the flag big, and shiny, maybe zoom in/focus on it for the first few seconds of the game. Communicate in every possible way that this is the challenge.
• If you use the arrow keys to move, show that and reinforce that.
  • For example, simply show the keys in the 4 squares around the character. (So the “left arrow” is also on the square to the left of the character at the start.)
  • Make the keys blink/light up when pressed, and make the character respond instantly. (Far better than telling the player the controls … but they must wait to use them/try them out until the tutorial is over and the game unpauses.)
• If eating a berry opens all doors of the same color, design the first level (with the berry) to clearly communicate this and nothing else.
  • Don’t introduce the berry in a level with no doors.
  • Don’t introduce it in a level with multiple doors / doors of multiple colors.
  • Don’t hide the opening of the door: give it a big animation, sound effect, quick response.
• If entering a red square makes you slower, don’t expect the player to magically figure that out.
  • No, I can tell from experience that players NEVER notice subtle tweaks in numbers. It’s incredible how quickly you get used to changes if they’re permanent. (If the slowdown was only a few seconds, for example, and then it’d snap back to normal—that would grab attention far more easily.)
  • Play a sound effect that communicates something happened.
  • If possible, show the player’s speed with a progress bar / meter / number / icon at all times, so the player can see it go down.
  • Also design that red square to somehow look like a clock, or some speed slowdown symbol. Even better, theme it around something that intuitively slows you down: maybe the red square is quicksand or some sticky surface.

You can absolutely teach someone how to win the puzzle and how every building block to get there works without using a tutorial or any words. In fact, it’s probably the best and most engaging way for most games.

But you must still teach it. You must still communicate how the player is being tested and which specific, exact conditions mean they’ve passed/failed. Just leaving it a mystery, or “figure it out yourself”, will never work. It just leads to frustration and the remark “WHAT? (QUE?)” :p

Practical Example: from my own work

Now, I might sound harsh or like I’m screaming from my ivory tower. But no, I also write this article because I need to learn this lesson from time to time.

I participated in another game jam and made this mistake of “oh, once players have seen this happen a few times, they’ll figure out the rule/how it works”. No! No they don’t! The game did very poorly in the jam, people called it not fun, and they were right. The fix? Simply commmunicating that hidden rule.

More specifically, the issue was that the terrain players walk on ( = the specific color under their feet) changed something. The terrain is incredibly visible, and it changes all the time because bombs erase part of it, which is why I thought: “Oh, once they’ve walked over blue terrain a few times, they’ll notice it changes you this way.”

This change, however, was very subtle. It was a tweak of some numbers, a disable/enable of a few mechanics/rules. It wasn’t communicated in any other way than the end product of these changes. The players become doctors trying to diagnose themselves by looking only at a few superficial symptoms.

But I knew the game had potential. I knew it could be far more fun than its current ranking/playtest feedback.

In a later update, I removed a few of those hidden rules, and kept only one. The one I kept was now communicated clearly in every possible way I could think of: changes in your visual, a quick text feedback, a “tutorial marker” in the world that explains the rule. Everything it tweaked/disabled was made outwardly visible, instead of being a hidden number in the code.

Yes, this meant adding a few more sprites or numbers to the screen. Which is probably why I didn’t do it in the first place: the fear of overwhelming the player and adding too much UI or too many changing sprites.

Now I learned, however, that this is just another part of communication: getting your priorities straight.

Good communication also means knowing what’s so important that you need to say it in 10 different ways, and what is so unimportant (relatively speaking) that it should only be communicated one way.

In this case, that rule (about terrain determining some properties) was a core rule of the game. Something I added expressly to fix glaring issues and actually solve the game loop. As such, it was important enough to add the extra UI elements or sprites to communicate it in six different ways. Other rules of the game, which I now saw were far less important, could perhaps make space for that if needed.

Practical Example: Books!

For something different, a quick example of how this usually works in novels or storytelling in general.

Many beginning authors try to create “mystery”, and open “questions for the reader”, by simply not communicating anything. Hopefully you see now that this doesn’t work.

If you don’t tell the reader about suspect A at all, then it doesn’t feel satisfying if that person ends up being the killer at the end of the novel.

If you never actually explained how magic works to the reader, then it feels like cheating if the intricate specifics of magic suddenly save the day in the end.

No, if you ever saw any writing advice, you heard of terms like “foreshadowing” and “worldbuilding”. Pepper the book with hints and clues to the solution of the mystery (before you reveal the mystery of course). If any part of your world/magic/backstory becomes important in a later event, the reader needs to know beforehand. It needs to be communicated, because then it feels satisfying and coherent when this communicated information becomes relevant. If not communicated—if there’s simply a gap in the narrative—then this event comes out of left field and leaves a bitter taste in the reader’s mouth.

Similarly, many beginning authors start their book with “just another day in the life of character X”. They waste twenty pages (and perhaps much more!) before introducing the actual narrative. The actual goal the main character is trying to accomplish—the thing at which they’re being tested. For most readers, this is an exceptionally boring start, and they’ll never get further than those twenty pages.

A simple way to instantly make your story much more professional, is to simply communicate from page one.

• The reader knows the goal we’re trying to reach.
• And you’ve given concrete hints and tidbits of information that will be some of the puzzle pieces.

That’s the skill, I guess, of being a creative person. How to communicate specifically and clearly, while leaving room for intrigue, mystery and exploration.

Really, as an author, you’re chasing the golden goose every day of “how do I phrase this to sound interesting now, without giving away everything too soon?”

For example,

• In this detective/crime story of ours, some pink mirror in the bedroom turns out to be the murder weapon.
• You want to COMMUNICATE, so you want to introduce the object on one of the first few pages.
• But just saying “A pink mirror hung on the rear wall” has no intrigue. (Who wants to read words describing some boring made-up mirror?)
• While saying “The pink mirror had a corner covered in blood” is too much. (99% of readers are taken out of the story and know the author said this on purpose to give the solution.)
• Instead, you search for some middle ground. Perhaps you describe the bedroom as incredibly orderly. Everything is perfectly straight, at equal distances, exceptionally clean, neurotic. And then you say “The pink mirror hung on the rear wall, slightly slanted and dull.” You merely described the mirror—but most readers will pick up on the discrepancy and be intrigued, albeit subconsciously.

It’s the same with games. From second zero, communicate the player’s goal clearly and possible ways to fail/succeed. Don’t be mysterious here, don’t leave gaps. Don’t be afraid this will ruin the game or make it too restricting.

A good game will be designed such that this does not ruin the fun or intrigue, but rather adds to it.

Perhaps that’s a good test to take away from this!

If explaining exactly how you play and win/lose the game ruins the fun, reconsider your game’s core design.

When you tell people that you move with the arrow keys and secret treasures can be found underneath oak trees, they should be excited to try it out and play the game (because of the rest of the design), instead of shrugging and having no reason to play anymore.

And yes, as seen in my pink mirror example, usually this is a two-punch approach. One part of the game clearly communicated, one part made fuzzy and random on purpose, to both communicate and create excitement when merged together.

Final Example: a shooter/bullet-hell game

You know the ones. You stand in the middle of the screen (or some random map/dungeon), enemies come in from all sides, and you’re fighting for your life to survive.

I think one of the reasons these are relatively simple to make, and simple to make fun and easy to pick up, is because good communication is inherent.

How are you being tested?

• Usually, dangers automatically spawn in, closing in on the player and removing lives on touch. (And of course, your number of lives being the big test, they should also be the biggest and most prominent element on the screen.)
• So, if the player does nothing at all … the test is automatically communicated. You lose lives, then you die. That’s what you’re graded on: how many lives you have left.
• If the player does random stuff … the test is still automatically communicated.

What are the crucial steps to scoring well on that test?

• The first control you learn ( = moving around) can be used at all times. It always has a direct impact on the test (either getting closer or further away from danger), and there’s nothing more intuitive to humans than how physical space and walking around works. The result of this is instantly communicated, of course, by the actual change of position taking place.
• The second control you learn ( = shooting) is similar. It directly impacts your test (killing the dangers = staying alive), shooting targets is intuitive to humans, and any game dev knows the hundreds of effects you can add to guns and bullets to communicate what they do and how they do it. (Sound effects, recoil, muzzle flash, trail, blood spatters, enemy explodes on impact, bla bla.)
• With every single step and shot, you get immediate feedback about how this helps (or hinders) getting a good grade.
  • If every single monster death has a sound effect and big animation, then your bullet flying through a monster and doing nothing clearly communicates that bullet can’t hit that specific monster.
  • If you step close to a giant monster and lose a life, this clearly communicates that monster has a large hit range, as long as the monster itself is large and the hit range is perhaps shown on the floor/around it.
  • If you walk onto loot, which you probably do by accident pretty quickly, you automatically get it. Sound effect, animation, bump in your backpack, etcetera. This happens once or twice? The player has clearly received the communication that this is stuff they can and should pick up by visiting it.

You can’t help but communicate well! Accidentally, perhaps! (At least, if you stick somewhat to the general template of this genre of games.)

As you see, this example also shows lots of related advice.

• Make every mechanic in your game as directly connected to the core challenge as possible.
• Give every event outward, clear, obvious, consistent feedback (visual, audio, consequences).
• Even if the player does nothing, or does random stuff, this should still communicate the core test and how to get there.

But all of that stems from good communication.

These games usually do that well because you can’t really make the game without already communicating all the important things. (If you shoot monsters and they don’t die, or monsters touch you and you don’t lose a life, then the game simply isn’t finished—or not in this genre :p You’ve made a ghost simulator or something.)

Conclusion

Those were my thoughts on communication. Why it’s important and what that means specifically.

• Communicate to your player how they’re being tested. (What means failure and what means success?)
• Communicate every single step along the way towards that final “grade”. (Any component that is used for deciding the grade, should be communicated. If understanding how element A works is crucial to winning this level, then it must be communicated. If element A is just some extra spice that is not used (much) for the check whether the player won, then let it be more mysterious or “to explore”.)

Such principles are always nice to think about, but how do you apply them? You can put it on a post-it on your monitor, glance at it every five seconds while trying to develop your game … but that’s obviously just going to be distracting and exhausting.

No, all of this also leads into the following secondary advice.

“Spend your dev time improving your logical thinking and communication, first and foremost.”

Don’t spend it on art, or animation, or marketing, or more code, or more content for the game, or anything else. With every decision, try to train and challenge those two skills. Any time you need to pick what to work on next, pick something that will challenge and train your communication. Pick an aspect of the game that will improve communication.

Most game developers will not have a problem with the first one. They already (“accidentally”) train their logical thinking by writing code all the time.

But communication? That lags behind. Which is a shame, because as my examples illustrated, it touches all aspects of game dev. Being a good communicator will help with better sound effects, better art, better UI, clearer game rules, everything!

I think your game will improve more by asking yourself “how can this one image of a door better communicate how it works and how it helps you reach your objective?”, than saying “I will make the prettiest door ever!” or “Let’s add 10 different doors to this game! Content, baby!”

Let’s close it out by coming back to my opening anecdote. The GDD that wasn’t “proper”. Hopefully you can understand how infuriating it is to hear that something is “wrong” or “insufficient”, by someone who never actually told you how to do the thing or what they’re using for judgment. It teaches you nothing, and you feel powerless—both before and after the grade—to do anything about it. And all that while a single list of “these specific things must be in your GDD” would’ve prevented the whole thing. The quick, simple communication of a single sentence stating “X and Y is exactly why your GDD wasn’t proper” would’ve prevented this entire article.

And that’s why I think the most important skill of a game developer—or anybody in the world, really—is communication.

And please, if you’re creating a game jam (or any contest/ranking/competition of any kind), be specific about how you’ll end up with the final grade, and the exact steps people can take to improve that. Don’t tell them to include a certain document, give absolutely no other guidelines or instructions, then punish them for not making the exact document you wanted. That’s a communicative gap so large I wonder if the judges have ever tried to design a game themselves. And just as in games, this breeds frustration and makes people quit in the real world.

I hope I explained this well. I still feel like I could’ve picked stronger definitions and examples, but I wanted to get my thoughts out for now. I’ll probably continue on this topic in later articles. Especially as I am finally able to make video games again and will be experimenting with (and learning about) good communication as I make my own stuff.

Until the next time, hopefully not because a game jam made me mad,

Pandaqi