Saturday, May 2, 2015

How to Make a Video Game from Scratch 2015 version

This month, we have decided to have a go at making a video game for ourselves, and relate our experiences. We’re starting with no prior experience in game development, and no clue what we’re going to make, so the chances of us creating the next Minecraft are unlikely. But the point isn’t to create a masterpiece. Rather, it’s to show that today’s game-making software, combined with an abundance of helpful instructions online, mean that anybody can have a try.

We’ll be relying on two crucial products. The first is GameMaker Studio, an accessible game engine and development kit designed for building simple 2D games. The other weapon in our developmental arsenal is an excellent series of YouTube tutorials created by Gunpoint developer Tom Francis. Initially, we’ll be following his instructions fairly closely. Both resources are freely available (although a more powerful version of GameMaker can be bought). If you want to have a go yourself, getting started takes all of half an hour.

Francis’ tutorial focuses on a topdown shooter in the vein of Hotline Miami (also a GameMaker game), although it’s much more simplistic. The initial video is simply about creating a playable game space, an object for the player to control and programming those controls directly using GameMaker’s scripting language. GameMaker’s playable spaces are known as ‘rooms,’ while raw objects take the form of invisible nodes placed in the game world. More often than not, objects are connected to a visible sprite, which then has actions applied to it, either through using lots of pre-designated visual icons and menus, such as ‘move’ or ‘shoot,’ or by coding those actions directly.

What becomes apparent within the first half-hour of game-making is that our caveman-like artistic abilities are going to limit the scope. It doesn’t help that GameMaker’s sprite editor is much more like MS Paint than Photoshop. You can’t separate your images into layers, which makes it hard for a novice to draw any picture more complicated than an amorphous blob.

At this stage, we’re more interested in learning basic coding than becoming the next da Vinci, though, so we proceed with the player as a blob, which is also how Francis proceeds in his example. We then program some WASD controls to make the blob move around. At this point, an idea arises that will go on to define our entire game. My fiancĂ©e is looking over my shoulder while I work, and suggests that, instead of a blob, we should draw a spider. Since a spider is basically a blob with legs, this job is possible even with our primitive doodling skills. We also give the spider eyes so we can see what direction it’s facing.

The spider theme will dictate many of the following design choices, and it’s at this point that our game stops being a carbon copy of Francis’ tutorial game, assuming an identity of its own.

For example, part two of Francis’ series covers shooting. It describes how to make the player’s direction follow the mouse cursor, bind a projectile to the mouse button (which initially turns the mouse into a paintbrush, enabling us to write the ‘hello’ in the left screenshot), and finally how to make that projectile ‘fire’ from the player’s sprite.

Since we’re playing as a spider, it’s logical that our spider would fire silk webs. However, a spider spins silk from its abdomen, so we tweaked Francis’ projectile tutorial code ‘MyProjectile.direction = image_ angle’ to read ‘MyProjectile.direction = image_angle - 180’, which makes the spider webs fire 180 degrees opposite from the angle the spider is facing. This tweak adds an interesting spin on the top-down shooter formula, as it means we can only shoot enemies while facing away from them.

However, before we can shoot any enemies, we first need an enemy to shoot. Again, the spider theme dictates the logical adversary – a fly. Therefore, we drew a fly sprite, which although still terrible, is a far better fly sprite than we imagined we could draw, and then followed Francis’ instructions to give it a rudimentary movement AI. This movement system tells the fly to bounce off the game’s window border, reversing its direction when it collides.

Francis’ next step covers projectile collision and destruction. In his game, the enemy displays damage by shrinking and then disappearing, and we experiment with this idea for learning purposes. At this point, we also encounter our first bug – the fly shrinks when damaged and then, when it reaches a size of zero, starts shrinking by minus numbers, meaning it grows into an absolutely enormous insect horror.

A shrinking fly doesn’t align with our spider theme anyway. It would be better if our spider could trap the fly with its web, then eat it. What we quickly learn about coding is that if you can program an object to do one action, it’s usually very easy to figure out the opposing command. Since we can tell the fly to move, we can command it to stop, and as we can program a sprite to disappear, we can code a sprite to appear.

Accordingly, we created a separate, larger web sprite, and programmed the fly to spawn it underneath itself when it gets hit by the spider’s projectile. At the same time, we also programmed the fly to stop moving when it’s struck by the spider’s projectile, which simulates the effect of the fly being trapped by the spider’s incoming web. We then instruct the fly to destroy itself when it’s touched by the spider, but only if it has stopped moving (another interesting point – enemies do a lot of work for your game). Ideally, we eventually want the fly to register the lack of movement and the existence of the web sprite, but the former on its own will do for now.

The final feature we want for our game right now is a sense of continuation and progression. Francis explains how to make an enemy randomly spawn another enemy when it’s destroyed, which will suffice for continuation. For progression, we took inspiration from the giant fly bug earlier, and made our spider grow slightly when it eats a fly (in more literal terms, we program the fly to grow the spider when the fly destroys itself. Again, the fly is doing a lot of work for us).

And there we have it, the basic foundation for a game, and it was all achieved in just two evenings! What’s most surprising about our experience so far is just how much variety can be created when you understand just a few basic commands. Simply following our theme to its logical conclusions has already resulted in some notable diversions from the tutorial, and we were able to figure out the right code for all of them. Even at this stage, we’d heartily recommend experimenting with GameMaker, and Francis’ tutorials offer the perfect way to get started.

But while our game might have an identity, it isn’t much fun to play yet. In the next part, we’ll focus on adding spectacle to our spidery shooter, and giving it a little more structure.


Previous Page Next Page Home

Related Posts: