Critical Analysis: How to Tell if Your Game is Shit

Follow by Email

So a lot has changed since I last updated this blog, and Project GhostLight has received a massive overhaul, and there’s one good reason for this; It was shit.

I think it’s very important to be able to be critical of your own work, to be able to look objectively at it and ask yourself, is this fun, is this deep, is there a lot of room for me to expand on these mechanics. Those three words that I bolded are very important for this discussion, as it’s when thinking about those three tests that I realized, my vision for GhostLight failed all three (take note of them for later).

And so this article is going to be about Critical Analysis of your own work, why it’s useful in a hobby and real-world scenario, and then a brief discussion of my critical analysis of my own game, what my original plan for it was, and then what has changed.

So, making a game is a HUGE project, especially for a one-man team, there’s a lot of design elements you have to consider; art style, level design, mechanics, characters, plot, genre, controls, game-play, etc. And the difficult thing is that to make a great game, all of these have to work together. Each element of the game has to complement the rest. Take Shovel Knight for example, and the reason I’m choosing this game is I’ve been analyzing it a lot myself lately as it’s inspired a lot of what the new GhostLight is, but we’ll get to that later.

Shovel Knight sells itself as a modern NES game, and everything about it lends credence to that claim. The Graphics are all reminiscent of the NES era, with a modern twist! The developers have talked about how they stuck quite rigorously to the graphical limitations of the NES system, however through the addition of little improvements they managed to make the game look modern and beautiful, without losing this retro feel. The colour palette for Shovel Knight is mostly the NES colour palette, however the developers noted that:

“The problem for us mainly came in trying to display a gradient in most hues. For example, there isn’t a very useful yellow, the darker spectrum of color is very underrepresented, and there aren’t many shades that work for displaying a character with a darker skin tone.”

(This quote was found at a great article on Gamasutra discussing what NES rules Shovel Knight broke), and so in adding a few transitional colours, and a few colours for darker skin tones, the developers of Shovel Knight managed to add that much needed modernization to the game.

Another graphical example would be the Widescreen display and Parallax backgrounds (a topic I am planning to cover), Widescreen display is an obvious choice as it helps make the game more accessible and in-line with modern standards, however this doesn’t alter the old format much, Shovel Knight still keeps the same number of vertical ’tiles’ (suually a 16×16 pixel block) as any old NES game, but increases the number of horizontal tiles in order to allow more breathing room for the player, and creativity in regard to puzzles.

I could go on and on about the NES properties of Shovel Knight, as well as the NES properties it breaks, if you’re interested, give the article above a read, it’s actually written by one of the developers and goes into a lot more detail on the brief things I’ve mentioned here.

Now we know that a game needs to be complimentary to itself, each facet has to be designed with the overall product in mind, even if it’s just a hobby project that will probably be released for free or a small amount (like GhostLight), thats no excuse not to put as much effort as you can into making it ‘good’.

But why ? Why should you bother making sure your Tetris clone has a music track that compliments it’s special effects ? If you’re making a game for practice, just for yourself to practice coding or pixel art, then maybe it is less important. But if you’re trying to develop Game Design skills, if you’re trying to market a product, even if you’re using the product to market yourself as a portfolio piece, then Critical Analysis is so important.

Lets make up a little scenario and see how it plays out, you are the head of a small Indie game group, looking to make some money with a mobile game, maybe it’s not even about money, maybe you want to make it big, make the next Angry Birds or Flappy Bird, so you start on your bird-related adventure into the world of games. Your graphics guy makes some nice retro 8-bit bird sprites, your music guy gives you this awesome funky Dubstep track that gets stuck in your head, your team of programmers work expertly to create a bug-free game involving your bird flying through space.

Excited by your new product, the culmination of all these different areas that, on their own, were brilliant, you eagerly release Dubstep Pixel Aviation Simulator 2015 onto the app store and…
Nothing happens.
Which is to be expected, games don’t explode overnight right ? Look! You’ve already got some people downloading it and playing it! OH LOOK! Your first Review! 3 Stars ? Oh…well what was wrong with it ? The review reads jsut one sentence

“It’s ok, Got boring pretty fast though.”

At this point, you as a Game designer have failed. Each piece of your game, from the art to the music was made independently of each other, with no reviews, no collaboration, no management from you. The music may be great, but it doesn’t really compliment the pixel art in the game, and the blocky pixel art doesn’t really fit well with the smooth flying controls. It’s a disjointed mess, not designed with the final product in mind.

It’s not even the overall feel of the game that you’ve got to consider, it’s the platform it’s going to be on as well. Especially with mobile games, this is so important, and if you don’t analyse your game early on and catch things like this, if you’re too stubborn clinging to your design mistakes you thought were gospel and the center of your masterpiece, then at the end of it all you’ll have an alright product and a big waste of time and money.

Whew! That got a bit intense, so lets take the heat off of this imaginary indie developer and put it on me, let’s turn the light to face GhostLight in this interrogation. What was wrong with it? Well, a lot!

My original design document for GhostLight (Speaking of which, design documents are important to have, even if it’s just a brief paragraph explaining how you want your game to feel and look) described a 2D platformer, following the adventure of a dead flashlight, his only attack would be to shine a beam of light out, this would be used to solve puzzles, to weaken enemies, light lanterns to open doors, etc. Wait…hold on a second, do you see that ‘etc’ I had at the end of that list of 3 things ? That just meant I’d ran out of ideas. Well not really, I had some other ideas like refracting light, different colored filters, shining light through a mirror to burn rope, but as I developed these ideas more I began to realize – I couldn’t do them. Now not in the sense that it’s impossible, but the way I’d designed and created the light-beam of the flash light wouldn’t work with this, it could be reflected and trigger a light source, that was about it.

And it was around this time that I began to understand the issue behind my game. And I’m going to link this back to those 3 words I bolded at the beginning (Told you they were important!):
The game lacked depth, I couldn’t expand on the player’s experience because the player could only do a few things, walk around, jump, double jump, and shoot a torch. That was it. Any puzzles created would be trivial in the sense that if you just stood in a certain location then it’d be solved, and player’s tendencies to shoot at a lot of things when they have unlimited ‘ammo’ means a lot of them may be solved without realizing it.

Other design decisions lended to this too, due to the size of what was allowed on screen, and the free-moving camera, I as a designer, could never be sure what the player would be looking at at any given time, and so puzzles based around bouncing light beams around didn’t really work out very well, as the player either couldnt see all the puzzle, or the puzzle was so cramped that it was trivial. This is not fun.

Even the character design was limiting, it didn’t really have any charm beyond it’s novelty and was restricted to either shooting only horizontally, or it’s legs being bent weirdly out of shape as the body rotated.

And so I looked at my work, realized it just wasn’t going to work, and I scrapped it. Not all of it, mind you, a lot of the art assets and some of the character’s control code is ok to keep, but the character, level design, and game design have to start back from square 1. And so that’s what I did.

So what’s the new GhostLight like ? To be honest it’s heavily inspired by Shovel Knight in terms of gameplay, I’ve incorporated a room-based camera system, similar to the original megaman games, this was for two reasons, one: it means as a designer I can always be aware of what the player will be able to see at any given time, making it MUCH easier to plan levels, and to teach the player the mechanics of the game. I’ll be releasing more about the character soon, but he’s able to attack in at least 3 directions so far! More of the games development will be shown through this blog as time goes on 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *