CaddieOpen in CaddieDownload for Mac

The mistake every new game developer makes (Developing 2)

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

The bottom line

A new game should start with an ugly, quick prototype that tests whether the core gameplay is fun. Game design is the foundation for art, story and code, so a flawed idea sinks everything built on it.

Key takeaways

  • Game design is the foundation that art, story, music and code all sit on. 6:38
    • Carter's Curse used Picross puzzles to fight enemies. The enemy half of the screen was irrelevant, so the game was shallow and repetitive after months of sprites and cutscenes.
    • A noir adventure stalled on story research and a Snake remake stalled on movement code. Neither ever tested its core idea.
  • Developers fall into this trap by assuming an idea that feels fun in the head will be fun in play. 8:07
    • The second wrong assumption is that you can only learn if a game is fun after you build all of it.
    • Mark Brown learned otherwise by interviewing dozens of designers about how successful games start.
  • A prototype tests the idea cheaply, using only the bare minimum needed. 9:19
    • Prototypes use basic shapes or borrowed sprites, and they are often buggy. Their only job is to show whether the idea works.
    • For the magnet game, art came from Google Images, with no music, story or names, and the code could be broken.
  • Prototyping also produces ideas better than the original one. 13:16
    • Swapping the character for a magnet picture suggested a normal character who carries a separate magnet. That gave moments of full control and moments of less control.
    • Crypt of the Necrodancer began as a roguelike with a turn timer. Prototyping turned it into a game set to a song's beat.
  • Staying focused only on gameplay takes discipline. 18:20
    • Mark spent a week on particle effects, shaders and UI before he caught himself and scrapped that prototype.
    • The final prototype was fun to play and gave him a solid base to build story, music and art on.

The best game designers know that their brains are horrible smelly liars.

Mark Brown, Game Maker's Toolkit

Chapter summaries

0:00 Intro

Where a developer starts decides whether the game survives.

  • The first step in development can doom the whole project. 0:14
    • Last time, Unity was chosen as the engine.
    • This time the game idea is revealed.
    • The question is where to begin: if you take the wrong direction at the start, it can be disastrous.
    • The rest of the video shows a failed past attempt as proof.

0:45 The Idea

A magnetic character in a fast 2D platformer borrows a Zelda mechanic and gives it a better home.

  • The game is a platformer where the character repels from some platforms and attracts to others. 1:24
    • A button press changes polarity.
    • The idea comes from the magnetic glove in Zelda: Oracle of Seasons.
    • The glove also lifts big metal balls for puzzles and fights enemies, but the top-down view and Game Boy limit it.
    • The target is a game like Celeste or Super Meat Boy, built on speed, fluidity and precision.
  • A platformer is a sensible first project. 1:02
    • He loves the genre and it is far easier than an MMO.
    • His earlier videos on platformer level and character design should help.

2:44 My Game-Making Background

Years of unfinished games share one cause: starting in the wrong place.

  • Carter's Curse began with drawings and sprites instead of testing the game. 3:10
    • Howard Carter would fight zombies, mummies and Egyptian gods.
    • It was coded in Codea on an iPad, inspired by Bookworm Adventures.
    • The folder of notes came from his parents' house, with a Starcraft Ghost mouse mat.
    • Photoshop work included finishing moves, an intro cutscene and menus with big juicy buttons.

5:10 My Mistake

Game design is the foundation everything else sits on
Bugs and graphics can be fixed later, but a flawed core idea can sink everything built on top of it.

Treating every part of a game as equal hides that design is the part everything else rests on.

  • Picross gave the game no depth, so it was dull. 5:35
    • There was no tactics or strategy.
    • Play could not change with the enemy.
    • He was too far in and too demoralised to fix it, so he scrapped it.
  • Bugs and graphics can be fixed, but a flawed design can sink the project. 6:58
    • He built a house on really shaky foundations.
    • The noir game needed a procedural clue system he never designed.
    • The Snake remake died in bug fixing and movement code before he learned if it was fun.

9:00 The Importance of Prototypes

A prototype keeps only what tests the fun
ElementPrototypeFinished game
ArtGoogle Images, basic shapesOriginal sprites, animation
MusicNoneComposed soundtrack
Story & namesNoneWritten and named
CodeBuggy, borrowedPolished
PurposeTest if the idea is funShip to players
Mark Brown vowed no music, no story and no app icon until the magnet idea proved itself.

A prototype answers the one question that matters before anything else is built.

  • A prototype asks whether the idea is a strong foundation. 10:03
    • It must be fun or interesting and worth pursuing.
    • It is built as quickly as possible.
    • Designers often have loads of ideas, and all seem fun in their heads.
    • He vows to test only the game idea, with no app icon for an unbuilt game.

10:56 Building My Prototype

Three quick rebuilds turned the magnet into a fun mechanic
Making the magnet a separate object gave the player moments of full control, which the original idea lacked.

A rough prototype built from borrowed code and built-in tools can test the magnet idea quickly.

  • The first version used the simplest possible code and already felt good, but it was hard to control. 10:56
    • The character moved left and right and jumped by applying forces to a rigidbody.
    • The magnet pull came from Googled code that finds the direction to the magnet and pushes that way, speeding up as the character gets closer.
    • Turning the magnet off kept the velocity, so the character flew through the air onto a platform.
    • He made sure he understood the borrowed code before using it.
    • Things got out of hand easily, so the code was not perfect.
  • A built-in engine component made the second version easier to build and tweak. 12:20
    • Unity's point effector is a magnetic field. A collider plus an attract strength pulls rigidbodies toward its center.
    • The game felt more grounded, and putting the attract points on the magnet's poles looked good.
    • A layer mask system limits which objects the field attracts.
    • He had missed it for a while, though its icon is literally a magnet.
  • A magnet picture for the character led to a better idea: a normal character who carries a separate magnet. 13:16
    • Unity's joint system ties the character to the magnet. Letting go in mid-air still launches the character to higher platforms.
    • The character has moments of full control, and moments of less control while holding the magnet.
    • Two magnets, or more, become possible. A magnet can lure an enemy that is then crushed when the magnetism turns off.
    • Ideas for a magnetic character had run thin. With two separate entities they flowed.
    • The character is nimble without the magnet and slow with it, like Mario Odyssey with and without the hat.

15:47 Making Discoveries

Fast level tools, borrowed movement code and a few mechanics showed the idea is original, flexible and fun.

  • Shortcuts kept the work on gameplay. 15:55
    • Sprite shapes, normally used for organic levels like Ori's, let him drag handles to snap together a blank-colored level.
    • A downloaded character controller handled movement, so he skipped coding jumps.
    • He can tweak or remake the controller later.
  • New mechanics and puzzles showed the magnet has range. 16:50
    • Throwing the magnet and recalling it, like Thor's hammer, gave free game feel when it bumps the character on the catch.
    • Scenarios included throwing it at a wall to make a platform and switching polarity to jump between conveyor belts.
    • A piston can be connected to the magnet and released at the right time to send it flying.
    • A weighted platform can launch the player when the polarity changes.
  • The prototype passed the test: original, flexible and fun to play. 17:35
    • He has seen many magnet games but none like this one. It supports both platforming and puzzles.
    • Picking up a controller in the Unity scene was already enjoyable.
    • Earlier games were made with blind hope. This one rests on a solid foundation.

In the growth library

Mark Brown, creator of Game Maker's Toolkit, making his first game. Game design is the foundation every other part of a game sits on, so a new developer should build a scrappy prototype to test whether the idea is fun before making art, story or music. Mark's failed Picross game Carter's Curse set against the magnet prototype that turned into a better idea shows why.

Lessons that draw on this:

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

Transcript220 lines
Intro 0:00
0:00

Last time on developing, I picked my game engine - Unity - and I started to learn how to use it. But now it's time to reveal the idea for my game and, well, get started with making it. But where does one begin when developing a game? And I think this is a vitally important question because, as you are about to see, if you take the wrong direction when you start developing a game it can be disastrous for the project. Let me explain.

The Idea 0:45
0:44

Okay so let me start with the idea for the game. I am going to make, and brace yourself because this is crazy, a 2D, side-scrolling, platform game. Yes, I know, every indie developer starts by making a side-scrolling platformer. But I think I have some good reasons. I love the genre. Platformers are relatively easy to make in the grand scheme of things - it’s not a MMO at least. And I've made loads of videos about platformer level design and character design which should prove helpful.

1:17

Now this is also going to be a, brace yourself again, platformer with a unique twist. The idea is that the character in my platformer is magnetic which means they will repel away from some platforms and attract to others. And you can change your polarity with a button press. The idea actually came from this game: The Legend of Zelda: Oracle of Seasons. In this game you have a magnetic glove power-up which allows Link to repel from some surfaces and attract towards others. You can also use it to pick up large metal balls for puzzle solving and use it to fight enemies. It's a really cool mechanic but it does feel somewhat limited by the genre, the top down camera perspective, and of course the limited technology of the Game Boy.

2:06

So I thought… what if I were to borrow that game idea and put it in a different genre: a fast-paced, 2D platformer. Something akin to Celeste or Super Meat Boy. A game where you have to master the magnetism for speed and fluidity and precision. So that is the idea. And the question now is: where do I begin with it? Do I just jump into Unity and start coding? Do I jump into Photoshop and start making some artwork for it?

2:37

Do I start thinking about the storyline or the characters? Where do I begin?

My Game-Making Background 2:44
2:43

I'm going to level with you: this is not the first game I've ever tried to make. Ever since I was a little kid I've come up with ideas for games, and at various points in my life I have tried to make those games in different tools and whatnot. But I almost never finish those games and I think the reason is the same, every single time: I start in the wrong manner. Let me show you. So I got this folder from my parents house and it is full of notes and sketches and ideas for a game I was going to make a few years before I started Game Maker’s Toolkit.

3:24

That is actually just a mouse mat for Starcraft Ghost. That game never came out, did it? That might be worth something actually, put that in the eBay pile. So this game was going to be called Carter's Curse. It was about famed archaeologist Howard Carter, the dude who discovered Tutankhamen's tomb. And, in my game at least, he would also awaken an ancient Egyptian curse meaning he'd have to fight zombies and mummies and ancient Egyptian gods. I remember spending hours and hours drawing all of this stuff. I mean… what a nerd!

3:58

Anyway. So how would you go about fighting these enemies? The answer: playing Picross puzzles. Picross is this logic-based, grid-based, puzzle game… a bit like Sudoku. Nintendo's made loads of Picross games. I was really inspired by games like Bookworm Adventures where you have a puzzle at the bottom of the screen, and completing the puzzle does damage to enemies in a little fight scene at the top of the screen. And so my idea was kind of the same: you'd have a Picross grid at the bottom of the screen and Howard Carter would be fighting monsters at the top of the screen.

4:30

So I jumped into development. I was making the game in an app for iPad called Codea which lets you make iOS games on your iPad. I'd actually previously used it for a very standard Picross app for iOS so I knew I could probably code it, but I wanted the graphics to be amazing so I jumped into Photoshop and just started making loads of sprites and animation frames. I actually have a Dropbox folder that is full of sprites and animations. I made loads of different characters, I made finishing moves for Howard Carter, I made an introductory cutscene, I made menus with big juicy buttons to press. I really got into it.

My Mistake 5:10
5:10

But then I realised something. Something quite important. Something quite detrimental to the project. The game wasn't any good! It was really bad, it wasn't fun at all. And the more I coded it and the more I developed it the more I realised what the problem was: Picross just doesn't have enough depth for this type of game. You can't really have tactics or strategy, you can't change what you're doing depending on which enemy you're fighting, and ultimately it was immaterial that you were fighting enemies. You could ignore that entire top part of the game and the game would still work because all you're doing is just playing Picross puzzles. So it meant that I didn't have the ability to make the game more difficult or more interesting depending on which enemy you were fighting and it meant the player was just doing the same thing over and over again.

6:05

I had made a game that was shallow and repetitive and dull. And maybe I could have fixed it but I was so far gone at that point and so demoralised that I just kind of scrapped the whole thing. So what was my mistake? Well, with many, many years of hindsight… it's been almost a decade now… it's pretty obvious to me what happened. And it's this: when you're making a game there's a bunch of different things you have to create. The main ones being the music, the art, the game design, the story, and the code. And now it's easy to think of them as being equal… but they're not. In a lot of cases, the game design is not equal but instead it is the foundation upon which all the other parts sit. And so if you get that bit wrong the whole thing falls apart.

6:58

I mean you can fix the bugs and you can redraw the graphics, but if the gameplay is fundamentally flawed well the whole project can sometimes be unsalvageable. And this is pretty much what happened to me. I spent so much time on the art and animation that by the time I finally got around to the gameplay, I realised that the whole thing was flawed. I had basically built a house on really shaky foundations and then I was surprised and upset when my toilet fell through the floor.

7:26

Embarrassingly this is not the only time this has happened to me. I wanted to make a film noir point-and-click adventure game with a unique procedural generation clue system - but I spent so much time on the story and researching the time period that I never got around to actually designing that system. And I wanted to make a fast-paced modern twist on the mobile game Snake but I got bogged down in bug fixing and trying to get the movement code perfect that I never found out if that game was any fun before I got bored and burnt out.

7:57

So every time I've tried to design my own game I've put other elements like story and graphics ahead of the gameplay. Why? Well I think it comes down to making two very wrong assumptions. Assumption one is that the game always felt kind of cool in my head, so I just kind of assumed that the game would be fun when I made it. Obviously that was wrong. And assumption two is that I'm not able to find out if the game is fun until I've built the game. I have to just kind of keep making the game and at some point I'll realise if it's any good… right? No, wrong again.

8:40

And this is all very cringe-worthy to say because now the answers are so obvious. But they weren't obvious then - it's only since doing Game Maker’s Toolkit, since researching game development, since interviewing dozens and dozens of game designers that I now know how most successful games start.

The Importance of Prototypes 9:00
9:00

You see game designers have loads of ideas all the time and I'm sure they all seem amazingly fun in their heads. But the best game designers know that their brains are horrible smelly liars. The only way to know if a game idea is good is to build it, to test it. But instead of having to build the entire game, designers just have to build a… prototype. A prototype is just this small scrappy test bed for an idea, just designed to see if the idea is fun or not. These prototypes are usually incredibly ugly with just unfinished art or basic shapes or sprites stolen from other games. They're often buggy and broken and they have nothing in them but the bare minimum features needed to test that mechanic. They are a just functional enough version of the game idea, built as quickly as possible, with the only purpose being to see if that game idea works. Is it fun or interesting? Is it worth pursuing? Is it a strong foundation upon which to build the rest of the game?

10:09

And so that's what I'm gonna do. This time I'm gonna get it right. I’m gonna focus exclusively on making the prototype and I am going to be extremely disciplined and not do anything other than just test this game idea. So in terms of art, I'm just going to pull stuff off Google Images. There's going to be no music, there's no story, I'm not going to think about the name of the game or the name of the characters. I'm not gonna start designing an app icon for a game that hasn't even been built yet, Mark, you idiot. The code will definitely be buggy and broken because I'm still just learning Unity, but it should be good enough to see if this idea works. Just a sandbox to test out game mechanics and see what's fun.

10:52

So let's get started, and open up Unity.

Building My Prototype 10:56
10:56

The first thing I needed to do was to have a character who can just move left and right and jump, so I just have it apply forces to the rigidbody when I hit the right keys. This already had some problems, which wasn't a great start, but I got there in the end. Then I put a magnet in the scene and needed to make it so the character would attract towards the magnet. Now to get this working I had to become an expert programmer, I had to use my galaxy brain coding skills, so I limbered up my fingers and typed in the following line of code… how do I move a rigidbody towards another object. Okay, yes, I Googled it, found some code, and slapped it in my project. But I did make sure I understood how it works - it basically finds the direction between the character and the magnet and applies forces to the rigidbody in that direction. I also tweaked the code so that it would speed up as you get closer to the magnet.

11:50

Then I made it so you could turn off the magnet with a button press which had the intended effect of keeping the character's velocity going, sending them flying through the air. So if I slap a platform up here I can attract the character towards the magnet then let go and jump up here. Which does feel pretty good… but it's a little hard to control things. This code maybe isn't perfect, things get out of hand pretty easily.

12:15

But as I was researching this stuff, I stumbled upon something really useful in Unity. It's a built-in component called the point effector, and it's basically… a magnetic field. I don't know how I missed this, the icon for it is literally just a magnet. Here's how it works: you give a GameObject a collider and a point effector, and then set an attract strength. And now when a rigidbody is in the collider, it's attracted towards the center of the field.

12:42

You can also use Unity's layer mask system to make it so it only attracts certain objects. So this would certainly make the game a lot easier to make, so I decided to remake the prototype. And, yes, the game feels more grounded. It's easier for me to tweak things and I can do cool stuff like if I put the attract point on the poles of the magnet, this happens - which looks pretty sweet. But when I made this second prototype, for some reason… not quite sure why, I decided to not use Mario this time, but replace him with a picture of a magnet for the main character. And this kind of gave me an idea: what if the character is not magnetic, but there is a magnet in the game world. And the character can walk over and pick up the magnet.

13:29

To achieve this I used Unity's built-in joint system, it's another component. This allows you to connect two rigidbodies together using different types of joints like hinges and springs. So now the character is essentially holding the magnet and if the magnet is attracted to a piece of metal, the character goes with it. Until you let go of the magnet, and now you can walk around again. And that gameplay I wanted before, with using the trajectory of the magnet to send your character up to a higher platform, that can still be achieved by just letting go of the magnet in mid-air.

14:01

Plus it allows for all sorts of other things, like you can have two magnets, or more. And you could maybe, like, place the magnet up here, then get an enemy to chase, you turn off the magnetism, and splat! Oh this is kind of cool, actually. Maybe this could work. Suddenly the game felt way more interesting than my original idea, which I have to admit I was starting to get a little bit worried about. When your character is magnetic and being attracted and repelled it's very easy to feel a bit out of control, but having the magnet be a separate object means you get times where you are completely in control as the character, and a bit more out of control when holding the magnet.

14:41

Plus, I was a bit worried just how many ideas I could come up with for a game where the character is magnetic. But as soon as I had it as two separate entities, the ideas just started flowing. Plus I really like games where you move back and forth between two distinct types of gameplay, like, think how Mario Odyssey changes when you do and don't have the hat. So in my game, the character is nimble and can jump really high without the magnet, and slow and leaden when holding the magnet - but, of course, that magnet allows for all sorts of amazing possibilities.

15:14

Now I shouldn't be surprised that an even better idea emerged during the prototyping process. As we saw in the GMTK episode The Games That Designed Themselves, it's pretty common for new ideas to emerge during prototyping. Take a look at the game Crypt of the Necrodancer: when that game was originally designed, it was just supposed to be a roguelike with a tight time limit in between your turns. But as the designers made it, they realised that it would be even more interesting if, instead of it being on a timer, it was set to the beat of a song.

Making Discoveries 15:47
15:46

So prototypes aren't just a way to test and prove the validity of an idea: they are a way to generate new and even better ideas. Now during this whole stage I made another interesting discovery in Unity: this one is called sprite shapes. And it's generally used to make really cool organic level design, like you might see in the Ori games, but for my purposes I just put on a blank colour and this allowed me to make level design really, really fast. I could just snap together a prototype area by dragging handles around like doing something in Photoshop. So I built the prototype again and this time I wanted the character to be a little bit better to control, something closer to a real video game character.

16:28

Now I don't want to get bogged down in coding movement and jumps, so I downloaded a character control script off the internet. It works really good, I can focus on tweaking it or remaking it or whatever in the future: right now I don't want to put time into that. Also in this prototype I started looking at some more mechanics like being able to throw the magnet and then being able to recall it back to you like Thor and his hammer. And because the magnet rigidbody bumps into the character's rigidbody, it gives you this little bit of feedback when you catch the magnet. It's like free game feel, it's amazing.

17:04

And then I came up with various scenarios that you could use the magnet in, like throwing it at a wall to create a platform. Maybe connecting it to a piston and then disconnecting it at the right time to send it flying. Maybe switching its polarity to jump between two conveyor belts. Or how about you weigh down this platform, stand on the top of it, and then change the magnet's polarity to shoot you up in the air? Whoa this is actually pretty cool, right? This is looking like a video game. This is pretty fun!

17:35

And this really was the point where I felt like this game idea certainly has some potential. It's original: I've seen a bunch of magnet-based games but nothing quite like this. It allows for both platforming and puzzle based gameplay. It feels like ideas for this game just flow really easily so I can build loads of different levels. And, best of all, it's just really fun to play. I can just jump into this scene in Unity and pick up a controller and it's quite enjoyable. That is surely a very good sign.

18:06

And so this is the power of prototypes: you can use them to test if a game idea is actually any good. And, if you're really lucky, you might find that new ideas emerge during that prototyping phase. Now I think you do have to have a certain level of discipline here, you really do have to say ‘I’m not going to focus on anything extraneous right now, just the gameplay’. And, I mean, it is hard. Like, in this video I didn't show you the entire week I spent looking at particle effects and shaders and UI elements and things like that - I'd gone right back to that old behaviour of getting distracted and carried away by stuff that just doesn't matter right now. But luckily I caught it in time and scrapped that prototype, before getting back to the stuff that is important.

18:54

And ultimately I think it worked out: I ended up building something that I think is pretty fun, that does have potential, and that I am excited to work on. My previous games which I tried to make when I was much younger were built with a sort of blind hope that the game would be fun, which isn't the most confidence-inducing way to make a game. But now it feels like I'm building on a really strong foundation and so all those other aspects - the story, the music, the artwork - that can be built with faith that the underlying foundation is solid.

19:29

And so I feel like this is the way to start making games: building a prototype. The only question is: what the hell do I do next? I guess we'll find out next time, in the next episode of Developing. Thank you so much for watching and I hope you'll join me on the next episode of this journey. Goodbye.

20:14

The idea actually came from this game, The Legend of Zelda: Oracle of Seasons. Damn it. From this game. Oops. From this game. It came from this game. This game. This game. This game: The Legend of Zelda: Oracle of Seasons. The idea actually came from this game: The Legend of Zelda: Oracle of Seasons. That was pretty good.