CaddieOpen in CaddieDownload for Mac

Why is it so hard to make game design decisions? (Developing 3)

Shared by Caddie Library · Updated
Game Maker's Toolkit21:24Open on YouTube
Chapters show their main points

The bottom line

Indecision over what a game should be is cured by committing to a small, deadline-bound minimum, and this magnet game's commitment is to be a puzzle game. Without that commitment, a developer keeps testing ideas and never leaves the start line.

Key takeaways

  • Splitting the magnet from the character pushed the game from platformer toward puzzle. 1:15
    • Carrying the magnet back and forth slows progress, and an instant recall would look odd in a 2D game.
    • Two objects with different positions and abilities naturally create problems to solve together.
  • A platformer level and a puzzle level cannot share one game. 12:43
    • It would be like playing Super Meat Boy and suddenly facing a round of chess.
    • Puzzle fans get put off by harsh platforming, and speedrunners get slowed by puzzles.
  • The game is best as a puzzle game with platforming kept secondary. 14:39
    • This is the "kill your darlings" choice: drop the platformer he wanted, because the game pulls toward puzzles.
    • Limbo and Portal show puzzle games can have long, continuous levels and platforming sections.
  • The real problem is analysis paralysis, not scope creep. 17:29
    • He kept asking what-ifs, such as a rope, enemies, boss fights and a magnetic trajectory arc, and never committed to one.
    • Scope creep extends the path. Analysis paralysis takes small steps down many paths and never leaves the start line.
  • A short deadline and a minimum viable product force commitment. 19:07
    • Designer Oliver Granlund advises a game jam mindset: one month, and only the core actions of carry, drop and switch polarity.
    • The plan is 30 days in total to make five levels with the basic mechanics.

I'm not moving along that path! Instead, I'm making small, tentative steps into lots of different paths but never making the decision to go down in any one direction.

Mark Brown

Chapter summaries

0:00 From platformer toward puzzle game

The game began as a speedrunning platformer, and making puzzles is harder and slower than making platforms.

  • The first vision was a fast, precise platformer. 0:56
    • Influences were Mario, Super Meat Boy, Celeste and N++.
    • He wanted speedrunning, mid-air moves and button combos.
    • Instant recall works as in the Super Mario Odyssey cap and the God of War axe.
    • A magnet that ignores magnetic fields and metal surfaces would confuse players.
  • Puzzles cost more to build than platforming levels. 2:38
    • Designers he interviewed for an earlier video had no formula, only a shrug.
    • Platformers reuse setups with small twists, but puzzles must be handmade and unique.
    • Once a player knows the solution, a puzzle is no longer fun, so it cannot repeat.
    • He calls himself a newbie designer, and this feels like a lot to bite off.

3:27 Building the puzzle version

Rebuilding the prototype to puzzle game conventions
Platformer prototypePuzzle prototype
CameraZoomed out, follows playerZoomed in, one fixed screen
MovementFastSlower
JumpHighReduced
LevelsOrganic layoutsTile-map grid
ThrowingNo aim guideTrajectory arc
AbilitiesAll at onceGrab, then polarity, then recall
One screen per level matched the grid-paper notebook and removed the need for a camera system.

Making puzzles meant cutting abilities, rebuilding the prototype around a grid, and settling unforeseen interactions.

  • Too many abilities make puzzles hard to design and to learn. 3:54
    • Pick up, throw, polarity and recall leave no walls that can hold the player in.
    • Recall is like the Half-Life 2 gravity gun, which belongs at the end.
    • He sketched puzzles on grid paper with conveyor belts, pistons and saw blades.
    • The Portal-style fix: grab the magnet first, then polarity, then recall.
  • The prototype was rebuilt to puzzle conventions. 4:52
    • The camera zoomed in, the character got slower, and jump height dropped.
    • Unity's tile map put everything on a grid, one screen per level.
    • A trajectory arc now shows where a thrown magnet will land.
    • Single screens let players see every element, matched the notebook page, and needed no camera system.
    • The arc comes from a tutorial equation using gravity, force and mass, and ignores magnetic fields.
  • Interacting elements force the designer to decide the outcome. 6:53
    • A one-way platform lets the player through but blocks the magnet.
    • He chose to rip the magnet from the player's hands.
    • In immersive sims, the systems can design the outcome for you.
    • Otherwise it becomes a glitch he has to code a solution for.

7:50 Panic and a platformer relapse

Dread about the demo sent him back to the platformer he first imagined.

  • The demo felt not good enough. 8:25
    • He woke at 1 a.m. panicking about showing people the levels.
    • The puzzles felt bad, small and claustrophobic, far from his speedrunning idea.
    • The demo was nearly ready, with pause, mouse control, a title screen and scene management.
    • He asked: Is this really what I wanted to be making?
  • A 3 a.m. platforming level felt much closer to the goal. 9:09
    • He combined the tractor beam and one-way platform to climb by letting go and recalling.
    • He then chained a long route through weight, door, button, block and a second beam.
    • He decided to scrap the old levels and make a platformer.
    • The level is very hard and depends on recall, a late-game ability.
  • That level becomes the finale, with small levels teaching the skills. 10:30
    • Earlier platforming levels teach the mechanics, button presses and abilities.
    • The player would unlock recall only near the end.
    • Each lead-up level introduces one ability they will need.

10:42 A first level that turns into a puzzle

Fixing one tutorial problem accidentally created a puzzle
Each fix added a constraint, and the constraints added up to a puzzle built around a slow-moving cover.

Designing a tutorial room for the tractor beam shows how the game keeps drifting toward puzzles.

  • The first level must teach the tractor beam while the magnet cannot be recalled. 10:54
    • The magnet starts stuck to the beam. A button drops it, and the player carries it up by riding the beam.
    • Getting the magnet back down is the problem, because recall and polarity unlock in later levels.
    • A second beam button is rejected, since two buttons would do the same thing.
    • A ladder solves it but makes the beam pointless, so the cover starts over the ladder instead.
  • Fixing that one problem produced a puzzle built around a slow moving block. 12:09
    • The player can slip through a gap while the cover moves. That became the solution.
    • Persona 5 mixes a life simulator with a JRPG, but this would ask players to switch between two different games.
    • Making the puzzles optional is dismissed as deluding myself.
    • He leans toward platformers because he likes playing them and feels surer about building their levels.

14:42 Relief, then the bigger problem

Analysis paralysis means never leaving the start line
His problem was not adding too much but committing to nothing, so the game was never really started.

Choosing puzzle feels right, but the same indecision runs through every part of the game.

  • Choosing puzzle feels good because the puzzle work has already proved itself. 14:42
    • He has shown he can build a cool puzzle and found some formulas for making more.
    • He had been too narrow, picturing only tight single-screen grid puzzles.
    • The mood is far better than during his 1 am freakout.
    • Platforming sections, enemies and long levels can stay, as long as they serve the puzzles.
  • Genre is only one symptom of a much larger indecision. 15:53
    • Over weeks in Unity he kept trying and changing ideas while searching for the game's identity.
    • Stopping at the genre decision would miss the wood for the trees.
    • He fears that committing to one idea will block another that might be amazing.
    • Never committing means the game is never finished, or even started.

17:55 Borrowing a game jam deadline

An outside designer's advice is to set an arbitrary limit and ship something small first.

  • Having infinite time is both lucky and unlucky. 18:38
    • Oliver Granlund worked on the magnet-based snow globe level in It Takes Two.
    • Mark unloaded his design problems on him like an impromptu therapy session.
    • In a game jam you ask what you would do if you had one week. An arbitrary limit forces that question.
    • The limit will probably be overshot, and that is fine.
  • A minimum viable product should ship before anything else is added. 19:27
    • Continuing afterwards, for the series or out of passion, is fine, once a small dent in the game is made real.
    • A made-up deadline still blocks indecision, because there is a date to hit.
    • The 30 days are not consecutive, with breaks, other videos and Christmas in between.
    • The result is due sometime in January, when Oliver will see it.

In the growth library

Mark Brown, creator of Game Maker's Toolkit. Shows how a changed core mechanic can push a game toward a different genre, and how that left the designer stuck choosing between a platformer and a puzzle game. The worked example is Mark's own magnet game, plus Oliver Granlund's advice to beat analysis paralysis with a deadline and a minimum viable product.

Lessons that draw on this:

More from Game Maker's Toolkit · The whole library, and ask it anything

Transcript253 lines
0:00

Hi, my name is Mark and I am making a video game about magnets. Now, in the last episode of this series, I talked about the power of prototypes. I talked about the original idea for my game: which is to have a game where your character is magnetic. But then, as I prototyped that idea, I stumbled upon an even better one: the character is not magnetic, but they can pick up and throw these giant horseshoe magnets. That felt a lot more interesting.

0:30

But here's the thing: I didn't just change the game's main mechanic. I think I also ended up changing the game's genre. And that has caused me nothing but problems for these last few weeks. Let me show you what happened. Okay, so the original idea for this game was very much for it to be a platformer. I was taking influence from Mario and Super Meat Boy and Celeste and N++. I wanted to have speed running and mid-air manoeuvres and button combos and precision input… all that fun stuff.

1:15

But as soon as I separated the character and the magnet, the game started to veer away from being a platformer. And it's mostly down to this: when you have to babysit this magnet, it really slows down your progression through the world, because you have to stop, go back, pick up the magnet, and bring it with you. Repeat over and over again. The only real way to fix this is to be able to instantly recall the magnet to you from anywhere in the world, through any surface. Which is basically how the cap works in Super Mario Odyssey or the axe in God of War. And it's fine for those games, but my game is 2D so I think it would look a bit weird. Plus I think players might be wondering why the magnet is ignoring magnetic fields or metallic surfaces.

2:02

But it's not just that, it's that the game is also veering closer towards a different genre. It feels like this game wants to be a puzzle game. That's because when you have these two elements, you end up with these interesting problems to solve that you can overcome by thinking about the unique position and abilities of these two objects. Maybe you put the magnet down here, then manoeuvre the character up there, do something with the magnet, do something with the character, work together to solve this problem.

2:32

So it feels very much like this game should be a puzzle game. And I'm a little bit cautious about that because a few years back I made a video about puzzle game design and I talked to a number of game designers, and asked them “how do you make puzzles?”. And was kind of hoping for a nice easy formula or template to follow, but they kind of just gave me a slow confused shrug, because as it turns out… puzzles are really hard to make. They're also very time consuming. I mean, platformers can reuse the same setups over and over again with just very slight twists. I mean, you can randomly generate platformers at this point. But puzzle games have to be hand crafted and unique and they can't be repeated because once you know the solution they're no longer that much fun.

3:17

So that doesn't fill me with a lot of confidence. I mean I'm very much a newbie game designer and it feels like that's a lot to bite off. But I'll give it my best shot. I started by drawing some puzzle ideas in my, uh, Hyrule Warriors: Age of Calamity notebook. It's actually quite useful because it's got grid paper. I drew out puzzles with all sorts of different elements like conveyor belts and pistons and spinning saw blades.

3:42

You know, the classics! But, also, at this point I realised something quite important. You see, in my prototype I have given the player a lot of abilities: they can pick up the magnet, throw it, change its polarity, and recall the magnet back to them. That's a lot of abilities and it makes puzzles really hard to design. You see, puzzles are often about constraining the player within walls, and then they have to think critically about how to get around those walls. But if you give them way too many abilities, it's really hard to make walls that can hold the player in. Especially that recall power-up: it's just way too powerful. It reminds me of the souped-up gravity gun at the end of Half-Life 2. Like, it's really fun and satisfying but it has to be at the end of the game, otherwise it would make all of the puzzles and combat encounters… uh, you know, pointless.

4:30

And, besides, if I start the player off with all of these different abilities, it's going to make the game very difficult to learn. So maybe I should take a leaf out of, say, Portal’s book and slowly introduce these abilities over time. Maybe at the start the player can just pick up the magnet. And then later I give them the ability to change its polarity. And then later still, give them the ability to recall it. Okay, so now that I've got some puzzles drawn out it was time to remake my prototype in a new Unity project. That's because the prototype was built to platformer spec: you know, a big zoomed out camera, fast movement, organic level design, stuff like that. This new one had to be made for puzzle game conventions, so I zoomed the camera right in. Slowed down my character and reduced its jump height. I scrapped the organic level design and used Unity's tile map system to put everything on

5:23

a nice, neat, and orderly grid system. And I also made it so that each level was basically a single screen in the game. Partly because I like puzzle games where you can see all of the elements on screen at once. Partly because I was drawing each puzzle on a page of this notebook, which certainly influenced how big the levels would be. And partly because it meant I didn't need to make a camera system to follow the player if the camera never moves. So, you know, laziness always wins out.

5:51

I made one more change to this project that the prototype desperately needed, which is a trajectory arc showing you where the magnet will go when you throw it. I followed this great tutorial which basically just uses this mathematical equation, which can produce an arc based on things like the gravity, force, and mass of the object. It doesn't account for things like magnetic fields, but it's it's good enough for now.

6:16

So now that I've got the fundamentals coded into the game, it was time to build some game mechanics and level elements that I would need in order to recreate the puzzles in this notebook. So I made a big magnetic block which can move left and right. And then I made a button you can jump on in order to move that block to different positions. I made a tractor beam that can draw the magnet up, and you can use that to get to higher platforms. I made a weight and pulley system for creating doors and platforms. And I made a one-way platform.

6:47

Which actually led to a really interesting game development discovery. You see, this platform allows the player to pass through it, but it blocks the magnet. Which is good for puzzle design. But what happens if the player is holding the magnet when they pass through it? Well, the answer is that I have to decide what the answer is! You see, game development has all of these kind of unforeseen interactions between different elements in the game.

7:14

And a lot of the time you have to actually decide what the outcome should be. Now if you're lucky, the outcome will be kind of designed for you, and that's interesting. That's kind of how a lot of, like, immersive sims work. But a lot of the time it will just lead to, like, a glitch, and you have to code in what the actual solution should be. Like, should I block the player from moving through a platform if they're holding a magnet? Or should I rip the magnet out of the player's hands? I went with that one. that seemed like the neatest way of doing it. But it turns out that game development is just full of these tiny, unforeseen, micro decisions to make.

7:50

Anyway, at this point I had built myself a number of small, single room puzzles and I thought perhaps I could string these together in order to make a demo to give to some people to get some feedback on what they think about the game. So I started putting it together and added in some elements I would need in order to make a demo. Like being able to pause the game, mouse control if they don't have a controller, a title screen, scene management for moving between levels, and, you know, clean up some bugs and bad code.

8:20

At this point I was almost ready to compile a demo to give to people. But then… there's always a but then in these videos. But then I woke up at one o'clock in the morning, unable to get back to sleep because I was panicking about my game. The truth is, the thought of giving these levels to people to play… to say that “this is what I have made” was just giving me anxiety. Because it wasn't good enough. These puzzles were just bad and uninteresting, the levels felt small and claustrophobic, and it had just gotten so far away from what I originally wanted to make.

8:54

Remember: I wanted to make a game about speedrunning. About speed and precision and fluidity. And I made this game that was claustrophobic and small and plodding and slow. Is this really what I wanted to be making? So I went downstairs at, like, 3 a.m. Opened up Unity, and tried to make a level that would show me what would this game look like if I had made it be more like a platformer. So I combined the tractor beam and the one-way platform into one thing so that you can ride the tractor beam up, let go of the magnet just before it hits the platform, that allows you to rock it out the top. Then you can recall the magnet through the platform, manoeuvre yourself into another magnetic field, and repeat this until you get to the top of the level.

9:38

That was pretty cool, so I decided to iterate on it a bit further and ended up with this crazy level. So you grab the magnet, ride up this tractor beam, let go, recall the magnet, throw it at this weight to open this door, thread through this needle, press this button, ride this block up, jump, recall the magnet into your hand, sail over into this other tractor beam, ride it up, let go, and land at the exit. This felt really cool! This was fun. This was a lot closer to what I wanted to make in the first place. So maybe I'm not making a puzzle game? Maybe I am making a platformer. Scrap all those old levels, we're doing this now!

10:14

Now this level does have a problem, which is that it's very difficult. You need to understand all of these different mechanics in order to be able to do it, and also it revolves around the recall which, as I said, does have to be a late game ability. So I also need to unlock that for the player. So how about this: this platforming level is the last level in the game, and then I make a bunch of small platforming levels that lead up to it, and in each one I'm teaching you the mechanics and button presses and unlocking the abilities that you will need in order to ace this final level when you get to it. That sounds like something I can do.

10:51

Time to head back into Unity and start making it. So the first game mechanic I wanted to introduce the player is the tractor beam. So how about this: you start in a room with a magnet that's already stuck to a tractor beam. You press a button and the tractor beam turns off, and the magnet drops down to the floor. You can then grab the magnet, press the button again, and ride the tractor beam up, drop down onto the higher level. That is cool… but the magnet is stuck. Remember, we can't change its polarity or recall it yet, because I'm going to unlock those abilities in later levels. So how am I going to get the magnet back down?

11:26

Well I could add another button up here for the tractor beam, but that's a bit inelegant. I don't like having two buttons do the same thing. And, besides, the magnet will just drop all the way down to the bottom anyway. So perhaps this top button actually sends across a cover. Okay that's cool. But I'm a bit stuck up here now. Okay, if I add a ladder here I can go down, press the button, the magnet will drop onto the cover, and then go back up the ladder.

11:52

And that does work, but I'm not sure I really like it because if you can just take the ladder up, why would you need the tractor beam? Okay, so maybe the cover starts over the ladder, and then moves across to give you access… but this is actually kind of cool: I can slip through here while the cover is moving. Actually, that's really cool… what if that was the solution to this puzzle? Wait. Puzzle?! I didn't think we're making a puzzle game anymore! I thought we were making a platformer.

12:17

Ugh! And now I'm more confused than ever because I iterated on this puzzle game level for a while, and added in some new elements, and made it into this really cool puzzle where you have to manipulate and exploit this slow moving block to solve the puzzle at hand. But on the other hand I really like this platforming level that feels fun and fast and fluid and fits all of the ideas I had at the beginning of the game. And so I've got this awesome platforming level and this awesome puzzle level and I've come to this realisation that they can't both be in the game. I mean, look, you can have multiple genres in a game. You know, Persona 5 is a life simulator and a JRPG. But this is going too far. This is asking the player to jump between two distinctly different games. This is like playing Super Meat Boy and then suddenly having a level where you have to play a round of chess. It just doesn't work. I'm going to have people who want to play this game for the puzzles,

13:09

who then get put off by the harsh demands of the platforming levels. I'm going to have people who want to speed run through the platforming levels, and then get stuck and slowed down by these puzzle levels. It just doesn't really work. And, sure, I could probably find some way to keep them both in the game, like making the puzzles optional. But, at this point, I'm just deluding myself and I have to ask the question: what genre is this game gonna be?

13:32

Now it kind of reminds me of this interesting phrase: ‘kill your darlings’. It comes from the world of writing books, and it's this idea that sometimes you have to make the hard decision to remove an element from your work, even if it's something you really like. Even if it's something you worked really hard on. Because its very existence is to the detriment of the overall work. And I think this is what's happened with the platforming parts of my game. You know, I think I want the game to be a platformer: I really like playing them, it was my original idea for the game, I've made a really cool platforming level that I want in the game, and I feel more confident about making lots of platforming levels than I do about making lots of puzzle levels. But the game is desperately telling me something else.

14:20

If this game was a giant magnet, it would be constantly pulling towards a block that says puzzle on it. And I am pulling it away and trying to move it towards platformer, to no avail. It keeps snapping back. And at this point I need to be real with myself. Because does it really matter what I want to make? Surely the most important thing is what's best for the game, and the game is best when it's a puzzle game. But I feel a lot better about this now than I did during my 1 am freakout session, because I have proven that I can make a cool puzzle. And I feel like I might have hit on some interesting formulas and techniques for making good puzzles. More on that in the future.

14:56

Plus, the more I wrangled and wrestled with these ideas about genres, I realised I was being perhaps a bit myopic about what a puzzle game is. If I move away from these tight, single screen, grid-based puzzle games, and go towards more of the puzzle platformer type thing, we can see games like Limbo, which does have these long continuous worlds to explore. Or Portal, which does require platforming prowess to solve some of the puzzles.

15:23

So perhaps I can keep some platforming elements in my game… I can have enemies, I can have long continuous levels, I can have platforming sections. As long as they always run secondary to the puzzles, which have to be the dominant part of the genre. Now I could end the video there and say that this was a video about being indecisive about the genre, before finally coming to the realisation that it has to be a puzzle game. And then, you know, next episode I make a bunch more puzzles. But I think that might be missing the wood for the trees.

15:53

You see, this is actually just one small symptom of a much larger problem. I've talked about how I'm being indecisive about the game's genre, but if you watched me making the game in Unity these last few weeks you'd see me being indecisive about everything. I'm constantly trying and changing and messing around with different elements and ideas, as I struggle to understand the identity of this game. I keep asking myself questions like: what if the magnet was attached to the player by a rope and you can swing around with it? What if this game was more physics based and you could attach the magnet to things to make them topple over? What if this game had enemy encounters or even boss fights? What if, instead of the magnet going to objects, objects come to the magnet and I can move blocks around like that? what if I make a trajectory arc that is affected by the magnetic field? And, of course, what if this game was a platformer? What if this game was a puzzle game?

16:46

I just can't make decisions. Now some of this may be related to scope creep. This is when we have a small idea for a game, but we get excited about it so we start adding on new content and mechanics and ideas and it balloons to the point where we can never actually finish the game. Scope creep is when you are moving along the path of game development, but you keep extending that path further and further to the point where you never reach the destination.

17:14

But I think I'm doing something a bit different here. I'm not moving along that path! Instead, I'm making small, tentative steps into lots of different paths but never making the decision to go down in any one direction. And so ultimately I never move away from the start line. This is analysis paralysis: the inability to make a decision because you're overthinking the problem. It comes down to me never being able to commit to any ideas because I worry that it will block me from being able to explore other ideas that might be amazing and interesting and cool. But, obviously, if I never commit to anything, this game will never be finished. In fact, I'll never even start it!

17:52

I've got to find a way to fix this analysis paralysis. So at this point, I decided to get some help. So I've been doing this series called On The Level, where I talk to game designers while playing the levels that they've made. The last one I did, I talked to a guy called Oliver Granlund, who worked on It Takes Two's The Tree level. But as we were talking about it, I found out that he had also worked on the snow globe level, which has the main mechanic of… magnets! So if there was anyone I was going to talk to about my game design woes, it was going to be Oliver.

18:25

So I hit him up on Zoom and we chatted for a long time about all things magnetic, and I just dumped all my problems on him like a sort of impromptu therapy session. And in the end I just asked him, like, “dude what should I do?”. And here's what he said. OLIVER GRANLUND: “So you're you're both lucky, but also unlucky where you have infinite time. You're not doing it in a game jam. I would try to adapt the game jam mindset, because this happens in game jams too, right? Where you're like this mechanic… I could do so much with it! But if I had to make it in one week, what would I do? And I would set an arbitrary time limit (that you're probably gonna overshoot), but set a an arbitrary time limit of “I’m gonna try to finish this in one month”.

19:07

I'd look at like what are the core things you need to make this game that you're envisioning. Maybe it's just you carrying a magnet, you can drop it, and you can switch polarity. Maybe those are the only things. And then make, like, I don't know how many levels. Like make five levels that uses this mechanic in an interesting way. We usually talk about a an MVP, right? A minimum viable product. And I would recommend you to, like, focus on shipping this. If you want to continue, like, for example, for the sake of the series. Or because you're passionate about the game. Then I would do that from there. But then you made kind of like a small dent into the game to make it real. And you could ship that.

19:50

MARK BROWN: And you know what? I think that's pretty awesome advice. By setting myself a deadline and blocking myself from doing anything but the bare minimum that this game needs, I will force myself to start moving along that game development path. I will no longer be able to be indecisive about things because I've got this deadline to hit. Even if it is kind of made up and arbitrary. And so I don't know if Oliver was being 100% serious with those numbers, but I'm going to take them. 30 days to make five levels, using the basic mechanics for this game. Not 30 days in a row: I've got to take breaks, I've got to make other types of videos, there's Christmas coming up. But 30 days in total. How much game can I make in that time? Will I hit my target of five levels? What will Oliver think of my game? We'll find out… sometime in January.

20:39

Thanks for watching, and I'll see you then Hey, so before I go I wanted to give a quick shout out to GMTK Patron verysoftwares, who took on the challenge of actually making my Picross RPG from the last episode. The resulting game is ROWBYROW. In this one you have these spells which you can cast, as long as you can plot down the appropriate number of tiles on the Picross board. It's pretty clever and it does indeed make you think very tactically about how you're going to solve the puzzle, and asks you to change your strategy based on things like the number of enemies or your own dwindling health. It's a smart game made by a smart person. You can try the game for yourself over on itch.io and there's a link in the description.