Herein lies the first of hopefully many blog posts chronicling my attempts to learn how to make a game from scratch.  I am starting this blog post with three goals in mind: First, to provide a place to record my thought process, experience, milestones, and pitfalls on my way to making my first “shippable” game.  Second, to share my knowledge and experience so that other people like me who want to make games have a place to start.  Third, these posts should serve as a motivational tool to keep me moving forward towards my goals.  Please comment and share if you like what I have written ~Nathan

Games, amirite?

My gamer story is pretty typical; grew up on Nintendo, saved my money to buy a PlayStation, now that I am an adult, I buy more games than I can play.  You know the story.

I may have delved slightly deeper than the average gamer, occasionally picking up and reading a book on game design, narrative, or development the way a movie critic might read a book about cinematography; I used that knowledge to help me think more deeply about why a game was fun, or what went into making a game I liked.  I listen to podcasts that feature developers, read articles and interviews; keep up with the industry.  But that was about it.

And like probably everybody else who thinks the answer to “Are you a gamer?” is “It’s complicated,” I have ideas for games.  About a year ago I came up with an idea for a game that wouldn’t go away.  I would let it go, but it kept coming back, bigger, and more fully realized than before.  Finally, I decided to make it happen.

While this isn’t the beginning of my new hobby, I think it is the biggest step forward, and it definitely the most interesting step in my path to making a game so far.  So I will begin here.  This post covers the first time I put rubber to the road and actually make something that can played.

Or controlled, at least, on a screen.

And it’s not original.

But hey, you’ve got to start somewhere, right?  Since this is my first post, I will skip the many things leading up to this point, and simply say that last week I downloaded Game Maker Studio for Windows after hearing about their promotion from 8-4 Play’s Mark McDonald.  The standard edition (normally $49) was free for a short time; I splurged and upgraded to Professional which removes restrictions on things like the number of sprites you can use.  Not necessary, but since I have a specific goal in mind, it seemed appropriate to take advantage of the deal as presented.

A Word On Game Maker

Game Maker Studio is a 2D game engine.  It is an IDE (Integrated Development Environment), meaning when you start the program, it gives you everything you need to begin developing.  The IDE provides you with an integrated space where you can write code, combine the various aspects of games, and when you are ready, it will execute the code you’ve written and start the game or app you’ve written.  When you’re ready, the IDE also has tools to export or compile your project into an executable, an iOS app, an HTML5 program, and more.

I chose Game Maker because the games I’m interested in are 2D, retro style games.  Hotline Miami is probably the most prominent game to be created with Game Maker, but there are plenty of other examples, and with the user-friendly documentation and active community, Game Maker seemed like a good start.

The Code

GML feels a lot like PHP or Python or any other object-oriented language.  The code is very similar, there are IF…THENs, WHILEs, and variables are declared, using common scope protocols.  If you’ve spent any time dealing with those, you won’t run into anything too scary, at least at the beginning.  Bear in mind that I’ve spent exactly 60 minutes with the code, so this opinion will probably change, but if you are new like me, there is nothing to be worried about.  Yet.

As an object oriented language, everything that you see on the screen (aside from the background), and many things you don’t see, are objects, or more specifically instances of objects.  In your code, you write a function that describes what an object is (for example an enemy space ship), and all the things about that object (HP, movement speed, behavior).  When you run the game, you create an instance of that object, and that instance is its own version of the object you wrote.  In this way you can have a bunch of instances of the same object (ie a wave of space ships) on the screen that all use the same bunch of code you wrote, and they all keep track of their variables (HP, location, etc) independently.  This saves a lot of time and allows you to make complex designs quickly.

Persistence is another aspect of coding that is very important, because as an object oriented language, things like enemies or items are object instances that get created and destroyed constantly, along with all the data about those instances.  Your player is also an object, so if you want your player to keep its properties (like inventory or current health), you need to make it persistent.  Game Maker considers this a core aspect, so assigning persistence is easy.

Another key component are sprites.  Again Game Maker makes this easy, by allowing you to import your sprite images (or create them with the built in image editor), then quickly assign a sprite to your object code via the GUI, so that when you create an instance of an object, the sprite will appear with the instance.  Collision is built in as well, so there are functions that will allow you to easily detect when a bullet hits your ship, or your hero touches lava, or whatever.

I’ll get into the functions later; this more or less covers the basics.

The Graphics

GameMaker uses “rooms” as the space in which your game takes place.  On the most basic level, you can think of a room as the TV screen.  The main screen in Pac Man would be one room.  The title screen for Pac Man would be another room.  If you looked at Ms. Pac Man, each new maze would be a different room. Pretty straightforward.  You can expand your room size beyond the edges of the viewable area though, and build a larger level inside one room.  Think of NES games like Ninja Gaiden, where there screen scrolls with you for a bit until you reach a door, then start in a new area that scrolls with you until the next door.  Rooms have lots of properties that you can assign, like a static, tiled, or scrolling background, and persistence.

Sprites (and objects) are moved around and manipulated via an X Y coordinate system, with X(0) and Y(0) being the upper left corner of the room.  If your room size is the same as your screen size, then it would be in the upper left corner of the screen.  You can move things around relative to each other, or as an absolute.  Relative is helpful in cases where you want to shoot a bullet from your character’s gun; Absolute is helpful when you’re placing things like the health bar.

Where To Begin

The real change began when I discovered Game Maker tutorials on YouTube.  After Mark MacDonald’s tweet, I decided to look into Game Maker, and it turned out to incredibly accessible and very well documented, with a large, helpful community.  As part of this search, I stumbled onto Shaun Spalding’s YouTube Channel, featuring several tutorials on using Game Maker and GML.  Shaun is an Indie Developer who worked at Ubisoft, and has several released games under his belt.

Shaun’s Basic Platformer takes players from 0 to Game in under 30 minutes, using plain language, and explanations along the way that cover the whys of all the code he is presenting.  It’s very impressive, and incredibly helpful, and you can follow right along and get something up and running in about 20 minutes, although it took me about an hour.

What I came up with looks a LOT like what you see in the video, so i will skip posting pictures of it.  What I will share are my thoughts on the process.

My Thoughts On The Process

I do have programming experience.  I’ve done probably a dozen websites; some (like the old Seattle Retro Gaming Expo website, Pink Gorilla’s website back when they were Pink Godzilla, both no longer online, and my old Kind Stranger site) from scratch, some (like this site) from existing CMS solutions like Movable Type and WordPress.  I’ve worked at companies that require a decent knowledge of SQL and MySQL, so I’ve spent a lot of time teaching myself MySQL, and can run queries, create views, INSERT, UPDATE, and whatnot.  I am pretty comfortable with IF..THEN, WHILE statements, and variables.  BUT, I’ve taken no classes, do not know established protocols beyond the basics like camel case, and I usually work by looking up new functions or examples as I go; I don’t have an extensive knowledge base in my head, so sometimes little, simple problems can halt my progress for days while I wait for someone to answer my stupid question on the internet.  That’s about where I am coming into this.

GML seems perfect for a guy like me.  It is robust, similar to other coding languages, and takes a lot of the foundational stuff like collisions, health, image manipulation, movement, and bakes it right in, so you can begin building the parts you care about right away.

Shaun’s tutorial was incredibly helpful, mainly because he was very good about describing why he would choose one method over another; I suspect that I will spend a lot of time in the next few month writing spaghetti code that will prove overwrought or slow.

For this reason I’ve decided to make a bunch of small, single-mechanic games.  I will probably follow Shaun’s tutorials to build as far as he has some of the examples in his videos, then strike out on my own, making simple games that employ various mechanics from my main game.  In this way I hope to end up with a game that, while still my “first” game, will be the culmination of lots of practice and experience.

Stick around!