A Game Design Tip a Day #5 – [Design] The First Few Minutes of Your Game

The tips I’ve shared until this point have all been centred around scripting with Unity and using the Unity editor. This tip is going to be a more general discussion of the first few minutes or levels of your game. First impressions are extremely important, so you’ll want to grab your audience’s attention without completely overwhelming them.

Don’t overwhelm the player

In the first few levels of your game, it’s easy to just throw all the game mechanics at them in one fell swoop in the tutorial. Generally speaking, unless you have only one or two mechanics, this is bad because it’s simply too much for the player to handle. The best way to ensure the player gets a good grip on the core mechanics is to introduce them one at a time; show the player a brand-new mechanic and provide a safe area (one preferably without any deadly obstacles or risks) for them to test out the new mechanic, then put them in a relatively simple level that requires its use to proceed while allowing access to the safe area in case they need more practice. Making sure the player knows how to use a mechanic and has successfully completed a task using it will ensure that more complex later levels won’t present too many issues for them.

It’s also important to unveil your game’s signature mechanic early on, as this will be the focus of the game and keeping it behind a curtain for hours may make the start of the game feel like pointless warm-up. Portal 2 does an especially good job of drip-feeding new mechanics to the player and does all of the above very well – it even splits the Portal Gun tutorial into a single-portal device to smoothly introduce the concept of portals, weighted cubes and buttons, then proceeds to hand the player the dual-portal mechanic once they’ve mastered single portal placement. The backdrop of the first few levels of Portal 2 is also the familiar, yet now overgrown, scene of Portal 1’s introductory levels, which is a good technique to help the player feel ‘safe’ if you’re making a sequel.


Portal 2 lets you play with the single-portal device in a familiar level with no threats

A short story introduction or cutscene goes a long way

If your game is built around any kind of story (and unless it’s completely abstract, then usually it should have some story), then it’s best if you give the player some kind of story to invite their curiosity and make them want to finish levels in order to get the next piece of the story. A short cutscene (we don’t need any Metal Gear Solid levels of stuff here) should suffice. You can also use cutscenes and story plot points in quieter sections of the game (such as in-between levels) to break up the game into more manageable chunks; alternating between interesting action and quieter plot exposition can lengthen the game experience while keeping the player interested. Quiet sections also provide valuable exit points in your game – places the player can safely decide whether to keep going or stop playing without risking losing progress.

The start of the story is also where you ought to introduce most, if not all, of the main characters, as they’ll be driving most of the plot forward. It’s best to take the same approach here as with game mechanics; don’t throw a whole cast on the player at once, because a) that would be painful – people are heavy – and b) having to remember all these new characters will make the plot feel more complicated than it really is. This is where I personally think a game like Pokémon X and Y fell flat, especially if you were a newcomer to the series at this point – within the first 10 minutes you were introduced to Professor Sycamore, then Calem/Serena, then Shauna, Trevor and Tierno all at once, as well as the Pokémon you’ll likely be travelling with the whole game. I mean, I have far more gripes with the fact that the whole cast may as well be made of cardboard, but the main problem is that a lot of characters with distinct, ahem, ‘personalities’ are introduced at once. It’s a lot to take in.


Your friends would’ve been great in smaller doses. Or if they were actually, y’know, developed at all.

In summary, you want the first half an hour or so of your game to entice players with the first parts of a plot. Then, you want your main game mechanic, the one you advertise and put on the box art, to steal the show. After that, most of you game will be alternating plot points and gameplay (occasionally with new gameplay mechanics). The one thing you don’t want to do is scare away your player too early by shoving every mechanic you’ve got at them. It’s kind of like fishing, except you don’t want to shoot yourself.

Ludum Dare #31: My First 48-hour Competition!

I’ve finally gotten round to actually writing about this, despite it taking place way back in December! For those who aren’t that familiar with Ludum Dare, the basic concept is that people from across the world spend 48 hours making a game to a theme that gets voted on by participants beforehand, and people taking part must make all assets and write all code during the 48 hours. There’s also a more lax Jam version, in which participants get an additional 24 hours, can work in teams and can use assets from anywhere. Because I’m an idiot, I chose the competition, not the jam. The theme was ‘Entire Game On One Screen‘, and since I was a little stuck for things to do with this theme (well, technical limitation, not theme), I ripped myself off. A lot. Some of the basics of the art and concept was taken from one of my up-until-now-unseen 2-week challenge games – this game to be precise:


This is why I don’t write stories for two-week challenges.

Wow, you’re not dead. What have you been doing since your last post, 58 days ago?

Thanks for asking! Now, cast your mind back to the end of November. Yeah, that’s how useless I’ve been with this blog. The final 2-week challenge for the Warwick Game Design Society was ‘Micro’, which I actually won! That’s possibly because everyone had a lot of work due towards the end of term, but I’m still really glad I came first. The game I made was rather short, and involved a byte called Sam moving around through a (very abstract) computer, collecting powerups that shrink and grow him, and flip gravity. You can take a look at it here. I’ve only included a Windows build for now, but if you’d like me to build it for Mac or Linux, I’d be more than happy to.

Why the heck is this relevant?

Because the theme is so terrible, I was really stuck for ideas. I just needed to put something on the screen to play with, and my Sam sprite made this easy – I could re-draw it in about 10 seconds. Then I started screwing about with gravity, using my gravity pickups from Sam’s Micro World. Then I got portals working on the edges of the screen. Then I added coins, screen shake, sounds and many other cool little things, and it came together in the end – I got my very first Ludum Dare game put together within the time limit, in a surprisingly polished state. Give it a go in its competition state!

ld31-04Forever Falling, one of the most complete games I’ve ever made.

The most helpful thing about having a large platform to deliver this game to is that I got tons of feedback. There were a lot of positives; mainly, people loved the slow-motion level transitions, and the general gravity-bending mechanics. A few people also liked the tension when the timer was nearly zero just as they were at the end of the level. However, pretty much every comment on the game’s page said one thing that I overlooked for the entire competition: “it’d be nice to not restart the game from the beginning when I die“. I’m actually an idiot. If anything, it’s shown me how much I overlook in my own games – since I was playtesting each level individually, I didn’t realise that it was a problem. I didn’t do badly by any means though – I came 266th overall out of about 1300-or-so entries, even on my first try, so I’m very pleased with how I did.


Ahhh, why didn’t I make the player respawn at the start of levels!

It was still a thoroughly enjoyable experience, so much so that I’ll hopefully be doing the next one in April. I managed to get portals working in 2D – something I really wish I could do in 3D, but I have no idea how – and on top of that, the portals redirect gravity according to the direction they’re facing. You can also flip gravity at any point, which leads to pretty awesome, weird platforming. A lot of people liked smashing into walls, as it had a satisfying screen shake and sound effect, plus it gives you points, actively encouraging you to smash into everything at high velocity. I did a bit of work on it after the competition, and got a bit of a leaderboard working, plus a very important feature: you restart each level when you die, rather than the entire game. The first level will probably (definitely) be formatted badly, since it was a quick job with the Unity UI stuff, but give it a go if you’d like.

ld31-03Have another image, free of charge.

A bit sooner in the future, later this month, I’ll hopefully be doing Global Game Jam too. I’m super-psyched for it, hopefully it’ll be a bit more relaxed than LD31 due to it being a jam rather than a competition. I’ll be trying to not neglect this blog like I did at the end of last year (I’m a terrible person, I know), so expect to see a bit more activity over the next 11 and a half months. Oh, and happy late 2015 everyone!

05/05/13 Update

Today I’ve been working on a few things, wrapping up a few loose ends and things I’ve been a bit behind on finishing. The first thing I’ve done is (finally) add amethysts. I tried before and for some reason the mesh didn’t look right when I imported from Blender to Unity, but I’ve played around with a few settings and it’s fixed now.

unity_platformer_16They look more transparent than the other 5 types of gem, but that’s by no means a bad thing. The colour of these amethysts is pretty darn cool, and they sparkle well. I’ve now added sparkles to every gem, too.

The main thing I’ve been working on in this update are the portals. I’ve added a proper portal frame and a few decorations to go with it.

unity_platformer_13The frame is basic, but it’s a damn sight better than the red cube I had before. The particles move both up and down, giving an awesome portal-y effect. The lights and the particles only become active when the player has enough gems to use the portal, which took quite a bit of programming for a newbie like me. It works really well, and I’ve included some really small details like the lights gradually brightening rather than becoming live instantaneously. You can see the difference between the on-state and off-state portals in this picture:

unity_platformer_15I started to add bits of scenery in the game today too. It isn’t much, but I added huge versions of the gems on a hillside.

unity_platformer_14You can jump on these gems and climb over them without them being picked up. You can see some of the smaller details on the gems much better like this. I also worked on trees today, but with limited textures, I didn’t get far before realising the need to find more varied textures, or make my own. I will try to find more textures so I can create a more varied forest of trees, as I want that kind of variety in my game.

I worked on a little cube that emits gems today too. The script for this picks two random numbers between 0 and 1, and depending on the results, spits out a random gem (or doesn’t, depending on the number chosen). This is the basis for the crates I will add, which will be breakable and will release gems upon destruction. The cube I have added will only spit them out at random and is not yet destructible, however.


I will tone down the rate of emission for the playable download, as too many gems could potentially crash your computer. I had a few thousand rolling about, and my FPS decreased quite a lot, so it’s best, for testing purposes, to limit this. If you want to try it out, you can download it from my Dropbox, and if you want to see my video on this update, just go to my YouTube channel. Thanks for reading, and I hope you have fun playing!