A Dangerous Precedent

Hey all,

So, I was watching a friend of mine (also a game designer) play The Legend of Zelda: Ocarina of Time, and he had various... complaints. Complaints that I thought were not... accurate.

He was complaining about how the game wasn't telling him how to solve the puzzles, where to go exactly, what room to be in, even to the point that the camera wasn't accentuating certain waypoints enough.

One token example, he was stuck in Dodongo's Cavern, unaware that he needed to drop bombs into the eyes of the giant Dodongo skull, despite there being a sign cryptically saying that the Giant Dodongo needed to see red to open the path, and there being holes in the bridge directly above the eyeballs, and the camera looking down (admittedly slowly) when the player walks near said holes. He had just acquired the bombs, the dungeon treasure, and had seen that the bombs explode in a red cloud.

The game was giving him the pieces, but didn't tell him EXACTLY what to do; the game led him to the location, but didn't tell him the solution, you know, a puzzle.

I still enjoy this dungeon.

So after talking to him about these complaints thoroughly, I came to a conclusion that a lot of younger designers fall for a particular design paradigm. The paradigm that I'm talking about, to avoid being vague, is...

"The player must know everything" or "The player must be told everything".

Modern video games have a tendency to overexplain and overcompensate in detailing scenarios and puzzles, in an effort to maintain the game's flow and minimize the player's boredom.

I disagree with this style of design, for many reasons, but primarily it goes against one of my game design rules:

Exercise the Brain: Learning is fun!

Players do not like to be talked down to, especially in a puzzle situation. How many times do you remember when people made fun of Fi from The Legend of Zelda: Skyward Sword? Getting all of the puzzle solutions and directions really killed the mood, at least for me, and a large portion of the internet.

"Master, a playtest in Japan shows that you have a 46% chance to solve this puzzle that you just saw on your own, so let me tell you the answer."

Disclaimer: I don't hate Skyward Sword, I just think there are some dumb things about it.

Why do I think that learning is fun? Good question. To me, I like to explain the fun of learning in this way: Remember the first day of school or work? Everything was new, including the trip there, and it certainly wasn't boring, now was it? That's because the human brain is good at consuming new information, in fact, it loves it! Learning new mechanics, learning about new countries or regions, or even learning about the trip to work, to your brain, it's all interesting, because it is LEARNING. Now, what about the 100th day of school or work? You need to find distractions away from your trip, because you know everything already, your brain doesn't want to waste precious energy on seeing the same stuff. Heck, you can probably do your trip without looking!

That's called "grokking", by the way. Also, that's why backtracking tends to not be fun.

For more details about this, I highly recommend reading Raph Koster's "A Theory of Fun for Game Design", it's a fast read and full of information.

Anyway, players like new information, and being told everything about a game, puzzle, etc. is the antithesis to that.

The goal should be to give the player just enough information, and then GUIDE them towards the solution.

A great example? Super Metroid. Remember the door that looked ominous and you couldn't get through without the High Jump Boots, well, without bomb jumping? That searing memory that you KNEW you needed something to help you through there? That was the hand of the designer leading you, not TELLING you!

Gunpei Yokoi will be missed.

Imagine how different this moment would have been if the game told you that you needed the boots here, or once you got the boots, told you to come right back here? Getting through would not have felt as good, now, would it?

You didn't know everything, and that was fine!

It's okay to not know everything about a game, in fact, I recommend it. But what things SHOULD the player know? In my opinion:

The player should know just enough to know what can be done, and enough to infer what needs to be done.

Great examples include:

• Super Metroid
• The Legend of Zelda: Ocarina of Time: Dodongo's Cavern bomb puzzle
• The Legend of Zelda: Ocarina of Time: Forest Temple's painting puzzle
• Catherine
• Dark Souls 

A bad example would include:

• Dr. Jekyll and Mr. Hyde

If I had to summarize this post, it's that treating your players like they have no memory, nor awareness, is not fun, for you nor the player. Leave a little mystery in there, players will love you for it.

Anyway, it took me forever to write this post, and for that I'm sorry. I've been busy handling Studio Kumiho stuff, you can check the website here. We have some exciting developments coming up, and I'm excited to share it with you all.

Next post will be another design focused one, and it's in everyone's favorite format: a top 10 list! /sarcasm

Thanks,
Jimmy

Playtesting

Hey all,

Presented without context.

This is a picture of my notes during a playtest, it's a combination of user suggestions or my own findings. I tend to keep my notes a bit scrambled like this, and create tasks from these notes in JIRA.

Why am I presenting this to you? Well, I want to talk about playtesting, of course!

Basically, playtesting is letting people test your game, to aid you in identifying what is fun, and more importantly, what isn't. Some people misconstrue playtesting as the practice of writing down and implementing EVERYTHING the user says, this simply isn't true.

So, how do you playtest? Easy, get your game out there and make people play, your family, your friends, your enemies, your dog, and that weird drawing your cousin made you keep on the fridge: EVERYONE. When the player starts playing, try to keep the explanations to an absolute minimum, your game should speak for itself. Record what you notice, about lost messages in communication, or parts that are too easy or difficult. Try to find ways to keep the player engaged in the next iteration (i.e. Do they level up fast enough? Do the platforms move fast enough? etc.). Show your game as soon as you can, try to find that hook in your gameplay.

Also, provide your own equipment, and maybe even bring snacks for your guests.

It's really hard to get your game out there, I know, but think of it this way: this is part of making your work better, it makes you better! Your game may not seem ready, but it probably is, really. Have confidence in your work, you made it, after all!

Something that helps me when playtesting is that I tell myself: "I'll never present this product in this state ever again, it can only get better." In a way, it makes me look forward to the future. It may not work for you, but take comfort in knowing that your game will get better.

Part of being a game developer (or a creator of ANYTHING, really) is that you have to learn how to take feedback. Ultimately, the vision of the project is yours, and the feedback will help you accomplish that vision. Always listen, but know what advice to keep and what isn't necessarily helpful.

You may also have to deal with hecklers or haters, just be an adult and accept their feedback, I mean, what else CAN you do? Even the most hateful people can impart a good idea or two!

That's my talk this time. If you have questions, feel free to post a comment!

On another note, I've been working on my drawing, and I plan to draw something everyday in October. Not Inktober, I'm not good enough for that, I'm awful at art. Ironically, I wrote earlier about having confidence in your work...

I may or may not love Gurren Lagann.

Still working on it.

Also provided without context, a picture of Daigo.

That's it, go home. Oh, you are home? Then leave, go somewhere else, and then go home.

Jimmy 

Another Short Development Update

Hey all,

Sorry for the long list of short updates, I've been busy working on two titles at the same time and kind of lost track of some things.

Speaking of which, if you aren't using JIRA or some other software to manage your tasks, I highly recommend it.

Anyway, development on Chang-e has been going smoothly, with a UI update for the battle menus rolling out this past weekend, check it!

You know EXACTLY what that means. The face / concept art is due to change.

The plan is to have the battle system ready for playtesting in the near future, so stay tuned...?

Development on the Zombie Game (now tentatively named "A Sound Plan") is going smoothly as well, tentatively slated for Gold by August. By that time, no online multiplayer will be available, but single player and local multiplayer will be available. Online multiplayer will be in development as a patch, after gauging player interest.

Different pic, same rules, yo.

 That's all for now, look forward to more news on Chang-e and A Sound Plan in the coming weeks, I'll try to keep this blog updated more.

Thanks,

Jimmy

Surprise! Second game announcement!

Hey all,

I'm very excited to tell you that I've started a second game project. Development on Chang-e is still going, as you can see here:

Chang-e music playlist
(Yeah, I know the music sucks, I'm practicing, okay?)

Now, as for this other game, tentatively and lovingly named "ZombieStealth", will be about trying to get zombies to eat your friends, using only sounds generated by throwing rocks against the environment. The players can also generate sound by sprinting around the arena, look out though, that means the zombies are trying to eat you!

This project is a collaboration between UltraDudez and myself. At some point I'll link to his Twitter or something, for now, just believe he exists.

(Edit: He does exist.)

Anyway, it would be better if I showed you a video, so here goes.

Totally official and professional playtest footage

I learned something from this playtest as well: SDL causes a memory leak on Mac when the application is run through XCode. If you are having a problem like this, try running your app without XCode, see what happens.

Let me know what you think!

Thanks,
Jimmy