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. 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. 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. 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? Do I start thinking about the storyline
or the characters? Where do I begin? 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. 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! 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. 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. 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. 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. 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. 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. 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. 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. 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? 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. So let's get started, and open up Unity. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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! 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. 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. 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. 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. 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.
The series has been really enjoyable so far. Definitely is shaping up to be good, and definitely for the sort of person who has watched his stuff before and wants to take the next step - probably something they should watch first.
Had I seen this before I had started developing - it would definitely have helped me get on the right track and honestly just do it at all. Often tutorials are kind of . . . Boring - and they're quite direct, addressing just one particular issue or whatever. Which is fine, but it's great to have content like this too - really tells a story and lays out a rough pathway in a way less on the nose than, say, "Follow my 10-part series on [making a basic game]." It's very complementary to the more technical aspects of learning and speaks to the creative process a bit more than most things do.
Today, Just started a new project.
Was working in Unity and Multiplayer and learning how to code game lobbies using Photon.
Got a good gist and started getting some initial framework for the gameplay down, assigning player controls and spawning.
While I was following a youtube video on some things I was missing, this video appeared in the side bar.
Then when I took a food break, this reddit post showed up for me as well.
Boy did I need it.
I totally forgot to test the game idea I had and got wrapped up in the coding aspect.
This is an episode in GMTK's new series that is all about him actually getting into making a game himself after all these years of making videos about game design. Thoroughly recommend watching the other episodes in this series (Personal opinion ofc, as I enjoyed them a lot). But all of the videos are standalone so it's not a requirement to understand what he's talking about.
EDIT: It also seems like the videos title got changed as I were watching it. The post title is the old original title of the video, and "The mistake every new game developer makes" is the new current one. IMO the new one is a lot less informative and "clickbaity-ish". But adding this just so there's no confusion about the post title :)
Good episode, totally agree. Don't underestimate the value in prototyping. I've started assuming every idea I have is terrible until it's playable in some form, because it usually is, and I need that prototype to tell me why and what would be better.
After Brackeys went offline, now it's gmtk time to do the job!
I really like GMTK but I'm pretty surprised at the idea he's chosen. Magnet platformer is a pretty day 1 Game Jam thing, I'd bet dozens of games with the same premise have been submitted to the GMTK jams alone. It's far from a bad idea but I guess I expected something a little more creative / out of the box from the game design guru, though it is his first game so understandable to go with simple. Regardless I'm excited to see how the rest of the series pans out -- there's plenty of design left to excel in, can't wait to see the levels and such he designs.
I was sligthly worried when he started the serie but he is actually apprehending everything the right way. It has a lot of great advices and useful insights, backing it up with lessons learned from his mistakes in an entertaining format. This is shaping up to be a must-watch for anyone trying to get started in gamedev.
that background track tho...
This video help me to decide what to do first. Love to see how he express big thing in amazing and small speech.