Don't make this assumption about your players

Hi, my name is Mark, and I am 
making a video game about magnets.

Okay, so this was the plan: take all of 
the levels I made in the previous episode,

bundle them into a demo, slap that demo 
onto a Steam Deck, fly to San Francisco,

and give the demo to people attending 
the Game Developers Conference.

But with just one week to go 
before my flight, I gave my

demo to a key playtester, and he did not enjoy it.

He found it to be frustrating and tedious 
and gave up before the demo was even over.

And it was in that moment that I realised 
I had made a huge and pretty common mistake

when it came to thinking about 
my game's level of difficulty.

What did I do wrong, and critically,

was I able to fix it before flying out to 
California? Well, stick around to find out.

[Music]

Okay, let me back up a little bit.

In the previous episode, I showed 
you how I used a puzzle matrix to

help generate ideas for about 26 different levels.

Then, after that episode went live, I bundled 
them into a pretty chunky hour-long demo,

featuring three different worlds, two different 
magnets, and a bunch of different mechanics,

like colour-changing panels, 
laser beams, moving platforms,

boxes on wheels, spinning switches, and so on.

As always, the first people to get this 
demo were GMTK patrons on my Discord.

They gave me loads of feedback 
and advice and unearthed bugs,

exploits, annoyances, and inconsistencies.

As always, I am hugely grateful for their help.

Then, completely out of the blue, I get an 
email from one Patrick Traynor, the Patrick

of Patrick's Parabox, the brilliant puzzle game 
I showed in the previous episode of this series.

He thanked me for including his game in my 
video and wished me luck with my magnet game.

And I said, "Want to play a 
demo?" He very kindly said yes,

and then a few days later, I 
get an email with a single word:

"played," and a link to a YouTube video: 
a two-hour playthrough of the game.

Now, if you're wondering why I'm hesitating, 
he gave me no indication of whether or not he

liked the game, and so I would just have 
to watch him evaluate it in real-time.

And so, if he hated the game, I would just 
have to sit there and watch someone become

more and more disappointed in me, which is, 
you know, surely what parents are for, right?

But I finally worked up the 
courage to hit play on the video,

and on the whole, he actually really liked it.

He was laughing and smiling.

He complimented me on some 
of the puzzles and talked

up the potential behind the game's core mechanics.

PATRICK: "These mechanics make me think like, 'Why 
isn't someone else made a magnet platformer

like this before?'"

And any criticisms he 
had came with brilliant help and advice.

For example, I should make it more clear what 
the player can't do in any individual puzzle.

So, if a gap is too big for the player 
to jump, it should be a really big gap.

If a door closes too quickly 
for the player to get through,

it should snap shut immediately, stuff like that.

He also gave me another huge piece of advice,

which was to simplify the levels, even 
if that meant making the game easier.

Advice which I roundly 
ignored, more on that in a bit.

But anyway, there were about 
two weeks to go before GDC,

so I decided to use all of the feedback from my 
patrons and from Patrick to overhaul the demo.

I removed a bunch of levels 
that just didn't quite work.

This one relied way too much on 
quick reflexes to be a good puzzle.

This one had a huge exploit 
which I couldn't easily fix.

I also snuck in one level which 
was not a puzzle but was just

pure platforming to see how players 
would react to that change of pace,

but feedback was mixed, so I've left 
that on the cutting room floor for now.

I also made some new puzzles 
to fill in those gaps.

I worked on improving the readability 
of certain mechanics in the game.

For example, these icons which denote 
when a button is linked to an object.

I also replaced this weird magnet 
sensor thing with a panel on a

pulley which triggers a button when 
the rope hits the bottom point.

I also swapped out these simple green buttons 
for a more satisfying Frankenstein-style switch.

I made a lock and key for certain types of puzzles

which has a pretty satisfying 
animation when you grab the key.

I polished up the pause menu and 
added in a better title screen.

And, oh yeah, I made an 
entire new dialogue system.

There's only one prototype conversation 
in this demo, but it should hopefully

give people an idea of what the story 
might look like in the finished game.

So, the demo was done and dusted.

There was just one week to 
go before San Francisco,

and so I gave the game to a key playtester.

And as I said in the intro, he was not a fan.

He was frustrated and annoyed.

He found levels overly complicated 
and just tedious to play.

And in a lot of cases, he would 
simply hand me the controller and say,

"Can you just, like, can you just do this 
one?" And that playtester, that was my dad.

What'd I say about parents and disappointment? 
But, as painful as that playtest was,

I think it was also the most important 
playtest in this entire development process.

You see, at that moment, it was 
like seeing through the Matrix.

I could see exactly why and 
how I had messed up so badly.

And I also realized that if 
I ever met Patrick in person,

I would need to buy him a drink 
for ignoring his brilliant advice.

So, here's what happened.

Every time I would design a level, 
I would end up with a pretty simple

layout for the puzzle which just tests the 
player on a single, nice little interaction.

But then, I would assume that players 
would solve that puzzle immediately.

They would instantly smash through the 
puzzle and decide my game was too easy

and thus boring, and thus judge me as a 
human being to be inherently worthless.

So, I would be a little bit cheeky and 
add in some extra complexity to the level.

I would add in a whole bunch 
of steps the player needs to

go through in order to actually solve the puzzle.

And I would add in these devious traps 
where if the player did one thing wrong,

they'd be stuck and have to 
reset the puzzle back to zero.

And I would obscure the actual 
solution to the puzzle with

some red herrings or some other elements.

And in doing this devious, Machiavellian 
trickery, I would end up with puzzles

that were messy and convoluted and 
frustrating and tedious to actually play.

I was focused so much on making the levels 
hard, I had forgotten to make them fun.

Oops.

And here's the thing.

I never actually checked that assumption.

That assumption that players 
would immediately and instantly

figure out the solution, was that actually true?

So, I took Patrick's advice and 
remade a whole bunch of levels

in the demo with a core focus on 
clarity, elegance, and simplicity.

Take this level, for example.

In the original version, you have to use 
two magnets to flip two switches simultaneously,

to lift two drill bits, to make a 
laser hit an orb to open a door.

It is tedious just describing it.

The actual puzzle in this level is, I think,

pretty good but it's obscured 
behind so much extra fluff.

So, I remade it to look like this.

It now requires just one magnet, 
has about three or four mechanics,

it's really small, and it's really simple.

Will players immediately figure 
out the trick to this puzzle? Well,

I had literally no time to check.

I had to compile the build, chuck it on the Steam 
Deck, drive to the airport, board the plane,

and then sit in the same chair for 10 hours 
straight like a triple-A Dev in crunch mode.

Is that joke gonna get me in trouble? Is there

going to be an angry 
Twitter thread about that?

Okay, so I land in San Francisco, and after a 
few days of sightseeing - you know, Alcatraz,

the Golden Gate Bridge, the sea lions on Pier 
39, In-N-Out Burger... oh god, no. The chips!

What are you doing? But then it's GDC week, and 
I give the game to as many people as possible:

at mixers, at meetups, at a 
bring-your-own-game event,

at meetings, and during breakfast over 
big stacks of American-style pancakes

(I guess they're not American-style, but 
they're just American pancakes. I'm in America).

And feedback on the demo was really pretty good.

People kept saying, "This feels like 
a real video game," and people would

refuse to give me the Steam Deck back 
until they had finished the entire demo.

And to answer that question 
of, was the game now too easy?

No, the game was actually kind 
of the right level of challenge.

That puzzle I just talked about, for example,

players would get stuck for like a minute 
or two and then figure out the solution

and have that sort of wide-eyed aha 
moment I've always been chasing.

I didn't have any of that 
confusion and frustration.

They just found it to be a 
good, fun, satisfying puzzle.

What turns out, it was completely the 
right—Jesus Christ, that's a big spider.

Uh—where was I? Turns out it was completely 
the right move to make the game easier,

and in fact, I hadn't gone far enough.

There was one level in the demo 
that was still pretty fiddly.

One enthusiastic American described it 
as, "Gee, this one's a real stumper."

And there were also just a bunch of 
basic, fundamental mechanics in the

game that I had never properly taught to 
players, and that was making them stumble.

Like being able to use the magnet to ride up to a

higher platform or change the 
magnet's polarity from afar.

These were things that I felt were 
so obvious about my game that I

didn't feel the need to have them 
as puzzle solutions or tutorials.

But to someone who has never played 
my game before, they have no idea.

And so this is the big takeaway from this video:

American cuisine is pretty bad, but they 
do know how to make a good breakfast.

Wait, no, sorry, that's the wrong video.

This is the big takeaway from this video: always 
challenge your assumptions about your players.

I assumed that players would 
find my game to be too easy,

and so ended up making the levels to be 
frustrating, complicated, and convoluted.

And I assumed that people 
would know how to play my game,

and so forgot to tutorialise 
about half of the mechanics.

Now I don't feel too bad because I know

that this is actually a really 
common mistake in game design.

It's so easy to assume that players 
will have the same skill, knowledge,

and understanding as you, the uh designer who's 
been playing the game every day for months on end,

knows literally all of the solutions to all of the 
puzzles and literally wrote the rules of the game.

Mark, you fool!

And so it's no surprise that developers can 
end up tuning the game to be too difficult

or to not properly communicate 
some of the game's mechanics.

And as a game designer, it's one of your key jobs

to fight this urge and to really try and 
put yourself in the shoes of the player.

So, I want to close out this video with some tips

and techniques that I have learned for 
doing a much more effective job at this.

For one, Mario's maker Shigeru Miyamoto 
tells his new designers to try playing

the games with their left and right 
hands switched on the controller,

which should hopefully give you an 
experience of being an inexperienced player.

That's quite a bold one, but perhaps you 
can think of ways to simulate the experience

of being someone who doesn't have all of 
your skills and knowledge about the game.

Also, Patrick, we actually did meet up 
at GDC, and I bought him that drink.

Patrick assured me that thinking like a player is 
a skill that you can hone and develop over time.

And as I've shown in this video,

I think the best way to achieve this is 
to watch other people play your game.

If possible, you want to be 
in the same room as them.

There's nothing more humbling 
than sitting next to someone who

absolutely doesn't understand what 
the heck your game is even about.

You also want to play with people of all 
sorts of experience levels and skill levels.

Some of my absolute best playtests come 
from my two nephews, aged seven and ten,

though I do have to watch out for bias.

MARK: "Jack, what are your thoughts on the game?"
JACK:"One million out of-- I love it!"

MARK: "Thank you. Rory, what do you think of Untitled Magnet Game?"

RORY:"I love it".
MARK: "Thank you".

That is, of course, a good reminder 
to spend more time watching how your

playtesters play than listening to what they say.

Oh, that's like I should put 
on like a t-shirt or something.

Another tip is to think about your 
target audience for your game.

Have an idea of the sort of person,

the sort of skill level, experience 
level, and games they like to play.

Have that in mind and make sure 
you're designing the game for them.

And make sure you're picking 
appropriate playtesters.

A big part of this problem was that I was 
getting really worried that puzzle game experts,

people who played and completed 
Stephen's Sausage Roll and Baba is You,

that those people would play my game and 
think it was simple and dumb and bad.

But they're not in my target audience.

I want this game to appeal to a much wider 
group of people and players who have enjoyed

more gentle puzzle adventures like Toki Tori, 
Box Boy, Inside, Limbo, and Portal.

Having a target audience in mind is a 
great way to keep your design on track.

And of course, there are ways to 
appeal to a broader audience, too.

If you've made a really hard game, 
you could chuck in an assist mode.

If you've made a really easy game, you could put 
in optional harder content or post-game stuff.

And finally, don't be afraid 
to start stuff from scratch.

When you're making a level, there's a lot of 
discovery involved, and that usually ends up with

you accumulating a lot of fluff and other garbage 
as you're figuring out what this level even is.

My recommendation, then, is 
to start the level again but

with the knowledge you have acquired 
while doing that rushed first draft.

You will no doubt end up with a much more 
elegant and coherent version of the level.

I mean, I always do this with 
episodes of Game Maker's Toolkit.

The script goes through five or six 
different revisions before I hit record.

Why wasn't I doing this with the level design? 
So, I came back from GDC with loads of motivation,

great ideas for where to take the 
game next, and really bad jet lag.

I want to say a huge thank you to everyone 
who said hi or hung out with me at GDC.

It was amazing to meet so many people 
who watch Game Maker's Toolkit,

participate in the game jam, or are following 
me here on this game development journey.

It was even cool to meet that one 
guy who kept showing me his NFTs.

Cool dude, you're killing it, bro.

I was also just made to feel like part of 
this wonderful community of game makers,

and so I can't wait to go back next 
year with hopefully maybe a finished

game or something much closer 
to being done than it is now.

Until then, my next job is to take 
another step back and make a demo

that explores even more basic, 
fundamental concepts of my game,

and then get that demo in front of 
people in my key target audience.

For now, if you want to play any of the 
three demos I described in this video,

they're available for free on itch.io.

I'm not taking any more feedback on these demos,

but it might be interesting to 
see how the game is coming along.

Thank you so much for watching, 
and I'll see you again soon.