Lessons of Gamemaker

So after nearly two years of commentating, criticizing, nostalgic picture, and occasional errant rant, we’ve decided to put some skin in the game and start trying to develop a game now and then.  We’re not pros (in case you couldn’t already guess) but we do sadly enjoy coding and considering the insane amount of hours we’ve dedicated towards games in our lives it only feels fitting that we pretend it was productive time spent for “research.”  Besides, if we make a game that someone plays that doesn’t include a sewer level or escort mission, then we’ve given something back to the larger game community already.

We’ve spent some time reviewing several different game engines and while we eventually think we’ll make the move over to Unity shortly, we do have to admit that Gamemaker is an incredible 2d heavy engine that’s both intuitive and fully capable (especially considering it was used for Hotline Miami or the recent Hyper Light Drifter).  Those that have had a chance to toy around with Gamemaker though will attest it’s not flawless.  Rendering text is a beast, the intuitive plug-and-play design based on events is easy to start but handicaps you from making more advanced games that require meticulous coding, the native debug functions are lacking, etc.

You may not make Hotline Miami your first go around, or your second, or fifth…

But as you start to conquer the various challenges that will arise and you see your game successfully run you do get a strong sense of accomplishment.  We’re having a blast making original material and look forward to showing it off here in the near future, but in the meantime we wanted to quickly highlight some lessons learned from way too many frustrated hours staring at the Gamemaker compiling screen and praying for it to work this time.

5. Most of development is successfully debugging the crap you wrote

Unless you’re some sort of development phenom, more than likely the bulk of your time running your game will be spent wondering why it’s not working exactly as you hoped – of course assuming your game runs instead of crashing upon load due to a missing semicolon or undeclared variable somewhere. Deciphering where exactly in the logic something isn’t right is a skill of its own, even if you’re staring at the code you wrote.

You’ll want to learn early the benefits of the Display GUI function.  With a few lines of code there you can draw variable values to the screen tracking in real time the underlying logic of your game.  Are variables getting passed the way you planned?  Did the Boolean check work as you hoped?  Just draw them to the GUI and watch them shift as you play.  You’ll start to see root causes instead of just the symptom and that will allow you to track back that poorly written code deep in the bowels of that object you forgot about.  You’ll need to get good at debugging your own code to get this to work at all.

4. Chase memory leaks

Related to the point above, chasing memory allocation is one of the best practices we picked on our own.  Gamemaker’s debug tools are fairly limited though they are great at showing you what’s running and how much memory it takes to keep that object running all the time. Even better, you can use this window to see if you have some uncontrolled code that’s going to cause catastrophic issues later.  For instance Gamemaker’s Draw functions are incredibly taxing on the CPU and the ubiquitous Step events, if poorly constructed, can be disastrous as they run every single cycle.  Opting for complex if statements instead of switch commands, instantiating objects nonstop through an unchecked Step event, or simply rendering too much at once through a Draw function instead of pursuing surfaces or sprites, it’s just too easy to write Gamemaker code that can kill even a top notch PC.   Tracking these concepts by watching memory allocation through the debug tools is about the best way to confirm your code is relatively well-tuned.

Plenty of good tutorials out there for Game Maker – no need to buy Angry Birds ever again

3. You will not plan out every function you need

We spent days perhaps weeks even mapping out storylines, gameplay elements, characters, inventory items, level progression, etc.  We basically had a complete game development spec ready to go before we created our controller object.  It wasn’t long though before we thought of an edge case though in a particular sequence for which we didn’t have a functional line of code to handle.

This is incredibly common.  You’ll start development but forget about an inventory system that has to pop up and pause the game, or mini-map you want to overlay on you view, or how a sequence can change by you holding a certain item or having performed some earlier action.  It’s ridiculous to assume you’ll know every minute function you’ll need before you start development and every addition will only be harder to implement the later you are into development without breaking the rest of the underlying code.  We recommend planning for a while the develop a proof of concept that will be used to identify what you’re forgetting.  After that, it’s almost better to start from the ground up again and develop against your new set of requirements.

2. Figure out your minimum viable product, not the bells and whistles

With that in mind we can’t overstate the importance of identifying and prioritizing the minimum viable product of your game.  The web series Extra Credits did a tremendous video on this idea last year you can find here, but in short the minimum viable product is the core mechanic of your game.  A platformer is about jumping and physics, an adventure game about solving a puzzle, a brawler about hit detection, etc.  Before story, graphics, music, a cool opening you’ve got in your head, before anything else find the MVP and deliver that first.  If that’s fun on its own, then you’ve got a mechanic you can build a game around.  It’s going to be a challenge to resist the urge though to spend time working on a parallax scrolling backgrounds or dynamic music generation as that stuff is exciting – refining the basic game over and over is not.  You’ve just got to do it.

1. It will take way longer and be way shittier than you expect

Silicon Valley’s Jared had an awesome quote this past season as they prepared to release the first launch of their Pied Piper distributed storage platform when he said, “if you’re not mortally embarrassed by the quality of your initial release, you released too late.”

You can do a helluva lot from this free game design engine

This is the real surprise.  Be prepared to lose hours, days, weeks of time and have very little to show for it.  This is a commitment and a sacrifice to make something that, more than likely, won’t get seen or possibly played at all.  At least not at first.  And what you do release will never live up to the expectations you had when you first started.

But you will have learned from your experiences.  You’ll know pitfalls to avoid next time you develop something.  You’ll have reusable game objects you can repurpose for future original projects.  You’ll hopefully have a feedback loop of a few people actually trying your game to know how to be better next time.  You, like your games, will get better in time if you just keep going.