Designing a maze game – stealth, action and 30 year old classics

As somebody who has never really got along with Pac-Man I have to say that I’m developing a new found admiration for it. The games that I make much like the games that I typically enjoy are full on in-your-face affairs that generally involve shooting the bad guys, plenty of explosions and reasonable amounts of screen action.
Pac-Man, with its strong focus on avoidance, never really floated my boat.

With my new game being set in a maze with a strong emphasis on collecting objects and dodging monsters I should probably be quite daft not to have spent some time analysing the most famous of maze games.
Much like Namco’s 32 year old classic a lot of my game focuses on navigating your way through a maze, collecting gems and goodies whilst strategically dodging the guardians of the maze until such a time as you get the upper hand. The upper hand in the case of Pac-Man was of course the power pill. Once you have this you are no longer the hunted but the hunter and if you can catch them you can “eat” the ghosts. In my game this game changing item is not yet defined. Largely because I’m currently building a game of magic, wizadry and medieval castles but am becoming very tempted to set the whole thing in a Nazi castle a la Castle Wolfenstein.

 

Castle wolfenstein screenshot

Castle Wolfenstein

Castle Wolfenstein first appeared 30 years ago and was very much a game of stealth in which the player crept through a dark and dingy castle in search of secrets armed with a gun and the sole intention of escaping with the Nazi plans. Although I never actually played this game I know all about it thanks to id software’s 3D remake of the game 10 years later. This and Pac-Man are currently strong reference material.

Another game that I have played a lot and really enjoyed is Legend of Zelda: Ocarina of Time. There’s a sequence in there that sees the young Link stealthily sneaking his way past some castle guards. You can see it at this link on YouTube. Just skip to about 07:00 and you’ll see what I’m referring to.

zelda screenshot

Legend of Zelda: Ocarina of Time

I really like the way that Link is forced to creep around to avoid being seen. It was a fantastic feature of the game and something that has just the right amount of suspense and anticipation to be appealing as a challenge to casual gamers.

I’d very much like for my game to strike a balance between the stealth of the guard stage in Zelda, the arcade action of  Pac-Man and the overall challenge of Castle Wolfenstein.

So with my game (which I continue to call Castle Adventure) I am looking on playing with these game dynamics of stealth and occasional attack.
My character currently has the ability to take objects and will ultimately have the ability to use objects. I’m thinking along the lines of collecting a bomb, for example, (which then appears as a graphical button / icon that the player taps to active) and using it to defeat bad guys and unblock passageways.
I also want to add the classic find the key – open the door mechanic which is a useful way of having the player walk around the map without the “locked” item to find the key. In many cases the locked item may be a bomb or other object that hands the advantage to the player. Gun, ammunition, health… you get the picture.

The ultimate goal will be to leave the castle after completing a set number of (possibly randomly generated) levels in which the sub-goal if you like is to steal something or things. This is a direct link to Castle Wolfenstein and something that I think is an excellent motivation for the player.

I figure if I can appeal to the player in this way I’m probably getting something right.

More to follow.

Handling grid movement

I thought it might be worth briefly sharing my approach to handling grid movement. It’s by no means finalised but just now is giving some very satisfactory results.

In every game that I make I employ a fairly basic box based method for collision detection. In reasonably fast paced arcade games where the sprites are deliberately designed to fill the box this really isn’t a problem since gamers won’t notice a couple of pixels in error. Besides I always weight the collision routine in favour of the player where relevant.

With the maze game I’ve adopted a slightly different approach to handling whether or not the player sprite is about to collide with the maze walls. ( Visit this link to read an earlier blog post on the construction of the maze walls )

The game is laid out on a 10 x 15 grid of 32 x 32 pixel blocks. The blocks are actually sprites since I want to animate them (i.e. cycle through animation frames, move in to position on level load, resize and move during the game). But unlike all other sprites in the game I won’t be using the standard collision routines.
At any given moment in the game the player will be either a) sat at a precise location that can be converted in to a grid reference or b) in transit between two grid references. This is the key to my handling of wall collision.

sprite stopped

a) Player sprite sat in "precise" grid location

sprite moving

b) Player sprite in transit between two grid locations

The graphics above should illustrate these points.
In illustration b) the player has swiped the screen to initiate movement. The game recognises the fact that the player sprite is currently not moving ( m.player.moving = false ) and is therefore cleared to attempt movement. But first we perform a test by translating the player sprite’s x,y co-ordinates in to a grid reference.

e.g. m.player.x = 128, m.player.y = 192 = the player sprite is sat at grid reference 4 , 6 (128/32, 192/32)

We can now determine which way the player wishes the sprite to travel and test the corresponding grid location to see whether a wall is sat in the way. We can perform this test against the leveldata array that stores our wall locations. You can see more on this in the blog post I linked to above.
So fairly basic so far. If a wall is in the way the move request is rejected – see below.

sprite blocked

c) Player sprite's path is blocked by a wall

Player sprite is sat at grid 4, 1. He wants to move to 5, 1. A quick lookup on the leveldata array shows us that for element 1 of the leveldata array there is an “+” sat in position 5. See below.

var leveldata = [];
leveldata[0] = [
        "+,+,+,+,+,+,+,+,+,+",
        "+, , , , ,+,+, , ,+",
        "+, , , , , , , , ,+",
        "+, ,+,+,+,+,+,+, ,+",
        "+, , , , , , , , ,+",
        "+,+,+, ,+,+, ,+,+,+",
        "+, , , , , , , , ,+",
        "+, , , , , , , , ,+",
        "+, , , , , , , , ,+",
        "+,+,+,+, , ,+,+,+,+",
        "+, , , , , , , , ,+",
        "+, , , , , , , , ,+",
        "+,+,+,+,+,+,+,+,+,+",
        "+,+,+,+,+,+,+,+,+,+",
        "+,+,+,+,+,+,+,+,+,+"
];

Where the fun begins is in the handling of new direction requests once the sprite is in motion.

A couple of things need to happen here.
First I need the player’s sprite to just keep going until a wall is hit.

In order to do this I let the sprite walk the grid only passing through the test function once its co-ordinates perfectly resolve to a grid reference. ( This my sound a bit hit and miss but I can, by initially setting the player sprite to an x and y that is divisible by 32, guarantee that this will always happen. )
My sprite walks at 8 pixel increments so moving from grid location A to grid location B takes 4 steps. This is a deliberately short timeframe between grid points. It is important for me that the player is able to register quite frequently by way of a swipe on the screen an intended next direction.

sprite new direction

d) Player sprite and indended next direction

 
This intended next direction is stored and when the player’s sprite falls perfectly in to position at the next grid reference I test this new direction instead of the actual direction. If the new direction fails the sprite just carries on on its prefered course until a) a new direction request is received or b) it hits a wall.

Of course at any point in transit the player has the freedom to “turn his sprite around”. There is nothing to stop this since the game is testing for precise locations the sprite will just fall back in to a previous grid location.

So finally a word on what happens with the other objects in the game.
Monsters will follow the same code path as the player sprite. When they hit a wall they will make a decision based on their definitions. In most cases I expect that the monsters will “hunt” for the player since this is where the challenge should be. But in some cases I will completely randomise things such that the monster will quite happily retread his footsteps. This should add enough of a mix to the game to keep the player guessing.

Other entities such as gems, powerups, bonuses, magic weapons etc will be initially placed by the leveldata[] definitions but will actually be tested for collision against the player using my standard collision routine. That way I am free to move the sprites around the maze if I wish.

So that’s it ! Nothing overly complicated at all. Of course this is all just theory written here. I’ve not posted code since the code isn’t finished. Once it is I’ll revisit some of this.
Thanks for reading.

Playing with new and old game concepts

I love messing around with new ideas.
Sometime last year I had the idea of trying to recreate a game that I adored as a youngster; Lucasfilm’s future sports classic Ballblazer.
It actually started to go very well in that I’d successfully managed to manipulate the “scanlines” such that they shifted left and right in proportion to the overall floor. The code for this isn’t complex and didn’t take long to implement. However, taking it to the next step – moving forward and backwards – highlighted a bit of a problem with my hasty coding.

I appear to have completely left myself with no options for shifting the grid in all directions and as such left myself with a problem. I’m sure I could have persevered but to be honest I’d become preoccupied with the idea of presenting a shoot ’em up over the top of this shifting grid.

What I thought would be cool was to have aliens above dropping their bombs and aliens in the distance waiting to slide forward once the current wave of aliens had been exterminated.
I also quite liked the idea of the saucer being implemented some way off in the distance and firing its missiles down the grid toward the player.
So from a gaming perspective the player had to slide left and right to avoid bombs falling down the screen as well as avoiding missiles coming at him from way off in the distance.
As you can see I didn’t get too far down that line of thought but I’ll certainly pick it up again once I’ve got the current batch of arcade games off the shelf and in to the portfolio.

Touch control in a maze game ? Pac-Man has the answers.

I’ve been looking around the AppStore for games that implement the kind of touch control that I’m after for my maze game. There’s a thousand and one maze games on offer which is fantastic so I downloaded a few free trial versions to test them.

In many cases the controls felt OK but not great. The more I thought about it the more I liked the idea of a simple swipe gesture to change the direction of the player’s sprite.

Pac-Man has it all.
I really shouldn’t have been surprised. With the Pac-Man trial version you can set which style of control you prefer. So I picked swipe.

Pac-Man screen shot

The effect really is quite something. Your little Pac-Man chomps his way around the maze and you make your turns with elegant swipes. It just feels lovely. I really want this smooth feeling of control and am actually pretty much there.

I do have issues with the testdirection flag being unset after just one try but I will figure that out. Once I’m happy with the implementation I’ll write it up in a little more detail since I think it’s a useful thing to share to JavaScript game devs.

Talking of which here’s an interesting article called Analog thumb sticks for iOS using HTML5 from the creators of Onslaught! Arena which you may find interesting / useful.

Game Design Theory – Goals, Consistency and Controls

I love this article on Game Design Theory written several years ago for the book Atari Graphics and Arcade Game Design. Everything about it I find compelling and valuable in terms of considering the player and his requirements as a gamer. It goes in to detail about the benefits of well defined and above all fun challenges. It even touches on the player’s ego and its relevance to the broader game experience.

Naturally it was written at a time when arcades were king and home computing was still very much on the back foot. In fact the whole point of the article is how we as designers can capture the thrills of the arcade for the home gaming audience. It really is a perfect chapter for someone like me with a retro fascination in arcade gaming and a future that is very much about designing arcade thrills for mobile phones.

I’ve written about this several times before but I do believe there is a link between designing for the arcades of 25 – 30 years ago and designing for today’s casual mobile experience.
So let me pull just a couple of sections out of the article and try to make sense of them.

For a game to be considered challenging, it should have a goal where the outcome is uncertain. If the player is certain to reach the goal or certain not to reach it, the game is unlikely to present a challenge, and the player will lose interest. It is very easy to introduce randomness into the game either by hiding important information or by introducing random variables that draw the player toward disaster. Be careful not to overdo this, since a totally random game lacks a skill factor. Players quickly discover that they have no control over the outcome.

How many times have you played a game and quickly lost interest because you are just not challenged ? I see evidence of this quite a lot and have myself fallen foul of it. ( My Dragons game needs a better challenge, for example. It’s something that I aim to address at some point. )
The point about randomness is of course totally valid. As designers we probably rely on the randomisation of events a little too much.

A clear structure to your game with a well defined but out of reach goal is a great starting point for any design. Look at PacMan as an example. A maze full of dots and an animated mouth is a very clear instruction to the player of what she should achieve but is still quite clearly a) a big task and b) tricky.

 

pacman

Pac-Man

One of the more important design elements in any game is a logical set of rules. The rules can be extremely simple or utterly complex, but they must make sense. Since the game must follow its theme, any rules or variations should stem directly from that theme. It is pointless to throw in game elements that simply don’t belong just because you think that confusing the player would make the game more difficult. For instance, Donkey Kong, one of the best jumping, climbing arcade games, doesn’t require the player to shoot everything in sight, just avoid obstacles to reach the goal. Similarly, a tough, shoot-’em-up game like Galaxian keeps its fluid alien attack uncluttered by distracting game elements.

 

Donkey Kong

Donkey Kong

I suppose this is straight forward.
Whatever you define as your challenge for the player to overcome it should make logical sense. You really cannot afford to switch the rules of controlling the game, for example, just to add complexity. It doesn’t do that at all it just confuses and irritates the player.I have myself learned this lesson the hard way.
That said a game’s design that I was always proud of was Wizard Wars. It was consistent in its execution and extremely simple to pick up. Just tap the screen to move the Wizard and collect the shiny things whilst avoiding the nasty things.

The ideal arcade game should foster the illusion of winnability at all levels of play. One important factor is a clean and simple game design. Too much detail or too many rules may intimidate the player. If a player believes that his failure was caused by a flaw in an overly complex game or by the controls, he will consider the game unfair and quit. On the other hand, if a player perceives failure to be attributed to correctable errors on his part, then he believes the game to be winnable and will play repeatedly to master the game. It’s as if the player teases himself to play one more time.

In modern gaming this is epitomised by the game Angry Birds. Love it or hate it it is an immediately accessible game and one that we all feel that we can conquer with just one more “go”.  I mean what could be more simple than pulling the elastic on a catapult and aiming your bird to arc its way in to a fragile structure.

 

Angry Birds screenshot

Angry Birds

I guess the point I’m trying to make is that the controls are so simple that the player won’t ever attribute his failure to a problem with complex controls he will always assume that his aim or power was incorrect. Ludicrously simple to learn and yet extremely difficult to master. At least in one sitting.

These are just three of the numerous things that jumped out at me from the chapter.
There is a lot to take in within the chapter and I implore anyone with an interest in arcade game design to study it.

So what have I learned ? Here is just a short summary.

  • Define your goals well and make sure they are clearly visible to the player. Consider Pac-Man and how visible and obvious its challenges and goals are.
  • Be consistent. Be logical. Again consider Pac-Man and its very obvious and visible rules and restrictions. There can be no confusion. Your avatar is a chomping mouth. The maze is littered with dots to eat. The ghosts are coming for you. Surely that’s not fair ? What do the flashing dots do … ?
  • Make your controls simple and fool proof such that the player won’t ever confuse them with his inability to conquer the challenge. Consider Angry Birds. Simplicity is key. I’m sure there is further scope for analysing the balance between minimal input from the player in return for maximum chaos on the screen. A truly masterful game experience.

I really don’t wish to sound like someone who is obsessed with a formulaic approach to something that should be really quite natural. But I do believe that as designers we do well to learn from the experiences of the masters of arcade game design. These guys had nothing compared to modern gaming environments. Sometimes having very little forces some great innovation.

Playing with sprites, walls and new game concepts

I’m always looking at new game designs and cool ways to implement them. I also have my own system for creating HTML5 games that has evolved over the last 12 months.
I don’t use frameworks or libraries or such, I just enjoy getting my hands dirty with my own code.
But if you’ve read this blog before you’ll know that.

I wanted to have a crack at building my own maze game.
I’ve created similar games in the past and enjoyed making them very much so the idea of bringing one to mobile web is quite exciting.

Initially I took the decision that I wasn’t going to build a level editor. I just don’t have the inclination right now. Perhaps that will change if this game works out pretty well.
For now I wanted to just hack around in JavaScript in such a way that I could visualise the level as I key in each element in to the level data array.

Something like this..

var leveldata = [];
leveldata[0] = [
		"+,+,+,+,+,+,+,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+, ,+,+,+,+,+,+, ,+",
		"+, , , , , , , , ,+",
		"+,+,+, ,+,+, ,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+,+,+,+, , ,+,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+,+,+,+,+,+,+,+,+,+",
		"+,+,+,+,+,+,+,+,+,+",
		"+,+,+,+,+,+,+,+,+,+"
];

As you can see I have defined an array to contain all the level data in and then populated each element with another array. It is this second array that will store the level specific data.
What you see above is a representation of tiles. Each tile on screen is 32 x 32. So a level array with 14 elements equates to 14 rows of 32 pixel height = 448 pixels. This in turn equates to a total tile height of 480pixels. Perfect for my prefered game resolution of 320 x 480.
You can also see that I’ve left the last few rows full of tiles. This is due to the iPhone leaving its status bars in place by default and therefore chewing up far too many screen pixels.

In my code I iterate through each element in the array and parse the string for the comma “,”.
You can see this below.

function setWalls()
{
	try
	{
		var l = leveldata[g.level];
		for (var y=0;y < l.length;y++)
		{
			var s = new String(l[y]);
			var a = s.split(",");
			for (var x=0;x < a.length;x++)
			{
				switch (a[x])
				{
					case "+":
						spawnWall(x*32,y*32,0);
					break;
				}
			}
		}
		g.mode = "pregame";
		g.resetting = 50;
	}
	catch (e)
	{
		write("Set walls: " + e.message);
	}
};

g is my global namespace. Quite a lot goes in there that is game specific as opposed to player or sprite specific.
spawnWall() is my function for pulling a wall sprite out of the sprite collection and assigning it a set of co-ordinates.
Something like this..

function spawnWall(x,y,row)
{
	try
	{
		for (var a=0;a < NUM.WALLS;a++)
		{
			var o = m.walls[a];
			if (!o.visible)
			{
				o.visible = true;
				o.targetx = x;
				o.targety = y;
				o.x = x;
				o.y = g.canvasheight + y;
				o.row = row;
				break;
			}
		}
	}
	catch (e)
	{
		write("Spawn wall: " + e.message);
	}
};

I am positioning the wall tiles below the canvas height. This is deliberate since I want them to scroll in to view in between levels. In my move() function I have code to shift a sprite from its x co-ordinate to its targetx co-ordinate. Same for the y.

So back to the leveldata array and where you see a white space no tile will be drawn.
Where you currently see a “+” a wall tile will be drawn.
Eventually the + will be replaced by single characters that represent the type of wall tile I want to display.
For now it simply translates to my default wall tile.

wall graphic
You can see that this wall tile is 64 x 32 in size and contains 2 frames of 32×32. I am going to animate my wall tiles.

When I run the game in test mode I see the following screen layout.

castle screenshot

I have deliberately defined the wall tiles as sprites.
This gives me a tremendous amount of flexibility since the sprite class and methods allow for a lot of animation and movement. It also makes life a lot easier when I come to consider collision. Rather than “overlaying” a collision map I simply test for position based on a ton of sprites.
It also gives me the freedom to move walls should my design require it.

So just now I’m playing with ideas but ultimately I’d like to plant entity starting points in to the leveldata array.
Perhaps try a PacMan approach to a game where the whitespaces are taken up with “o” which will be translated by the game in to small coins that the player must collect.
I don’t know. It’s early days.
The most important thing is that my codebase allowed me to create this proof of concept in around 15 minutes.
Exciting times.

A couple more thoughts on designing games for mobile phones

I’ve blogged some thoughts on designing arcade games in the past but I just wanted to offer a few thoughts on just a couple of aspects of designing games for mobile phones. These thoughts came to me whilst relaxing with a coffee over lunch so please forgive the hasty nature of this post :)

There must be some good practices that as game designers we should employ when considering an audience of gamers that are “on the go”.
And let’s start right there shall we with that oh so popular misconception – mobile gamers are actually mobile !
Not all mobile phone gamers are going to play whilst in transit – bus, train, walking – in fact most I’m sure will play during a period of down time between classes or on a lunch break. Immediately I ditch the notion that mobile gamers are unable to offer anything less than 100% of their attention.
This is vital. I firmly believe that the mobile phone gamer is looking not for something to fill the gap between two geographical locations but an experience and a challenge that their mobile phone can offer them exclusively.

There’s something exciting and enduring about the appeal of a handheld device that is essentially you in a tiny box. It carries everything that you need to survive whether that’s an address book, a phone directory, a means to text or of course a voice to your countless social networks. The games that you install are for you and you alone.
If you’ve downloaded and installed Bejewelled Blitz it’s because that is a game that you will enjoy playing. Not your mother or your wife or your best friend.

Be personal

So the first keyword I thought of when considering this new look at designing for mobile gamers is personal.
Everything about playing your game should feel as if it is personalised to you the gamer.

You don’t really have to break your back as a developer to offer this. It could be something as simple as offering a Continue from a previously saved point right there on the game’s title screen. Instantly the gamer thinks “hey, it remembered ! It knows who I am and where I’m up to !”

Better still it breaks down that hurdle of “shall I play that game again ?” since the player knows that he will be able to pick up from where he left off. This is great since it opens up broader game experiences such as adventures or sporting tournaments.

Naturally the more complex games might remember your personal preferences as well as your progress. Music, controls, screen size, avatar settings. All of these things add up to an extremely welcome personalised experience.

Set the stage

Perhaps more of a regular concern to the game designer is the actual style of the game. The genre or the “look and feel”. My own preference for games sees me harking back to a time of pixelled cartoon-like space monsters and all things explosions and lasers. It’s an age thing ;)
Also, and quite importantly, these shooting games aren’t all that tricky to code.
But there are so many styles of game that as HTML5 game designers we can approach for our next game.

With my very small portfolio of games I’ve discovered that it’s really not so much the style as the stage on which you present your game.  And by stage I mean what exactly the player sees and experiences within a single “go”.
i.e. when I have a “go” of your game will it take place across multiple screens and levels, a scrolling landscape or in a multitude of different rooms / locations. This is the stage on which you present your game and challenges.

For example, in Wizard Wars I provide a single arena. Each of the goals ( defeat Zoltar, collect stars, avoid monsters ) is the same no matter which level I am on and each level is identical in appearance.
Furthermore the game is set within an arena that is the size of the playing area. There’s no scrolling to be had and no jumping between locales.

The same can be said for the shooters Galactians and HyperGunner although with HyperGunner the style of alien attack varies and there is of course the hyperspace element.

I am fairly convinced that there is a lot to be said for staging your mobile phone game within a single arena regardless of the overall length of the game.
Even if your game is 10 hours of play try to think of it in terms of how long a “go” on the game might be.

For this I’m thinking of classics such as Frogger and PacMan.
Take a look sideways at games like Bejewelled and again you see a single static arena within which you are to play.
Each of these games feels right in your hand and in many cases is probably controllable with just the hand that you are using to hold the phone.

I also think that this is quite calming for the player. To know that they can launch the game and be presented with a challenge that must be played out within a very visibly defined area is very attractive.

This is by no means a hard and fast rule for designing for mobile phones and there are exceptions to the rule. But I think it’s probably a pretty good starting point to try and design your game with such a visual restriction.
Try and think about what might take place in that arena and how best you can throw your challenges toward the player.

Remember the old Atari rule – “easy to learn, difficult to master.”

Even in your epic 30 hour mobile adventure The Quest for the Dragon’s Treasure there is an argument for good staging and providing a complete experience for the player with every “go”.

 

 

Developing a new HTML5 game with a few lessons from Doom

I’m currently working on a simple corridor shooter with a mutant / zombie theme. It’s called Area51 ( at the moment ) and as the title suggests I want it to feel like a cross between a 50’s B movie and an episode of X-Files.
The perspective of the game is fixed to behind the gun. So a little bit like Doom in that sense but none of the scenery moves.

Area 51 - HTML5 arcade shooter

The goal of the game is not yet defined although I keep coming back to the idea of simply escaping from an over-run laboratory complex. It’s just that when I put it like that it sounds horribly cliched and a bit dull. So I’m still trying to figure that out.
The point of this post though is not the game’s story as such more the thinking behind the design and the order of events if you like that I typically go through in arriving at a “final” game. More importantly I’m challenging the way I’ve always designed my games.

Ordinarily I like to take an idea and play with it until it feels so natural and fun that it quite clearly belongs at the centre of my game.
I did this with every game so far and perhaps most notably with Galactians 2 in that I was determined to have the alien bugs “splat” on collision. This is my centrepiece. A core to the game if you like. Everything else in the game will be built around the simple concept of shoot & splat.
I played with this idea for days before it actually became a game.

As with all my shooting games I like there to be an intense feeling about the combat. I like lots of bullets and a fair sprinkling of bombs and bad guys to aim at.

So here I am with Area51 and I’m trying to find a direction based around my “core” concept.
The core concept in this case is quite simple – spray bullets down the corridor at the advancing bad guys and watch them squirm and spray blood until eventually they splat.
Fill the room with such monsters and essentially repeat the above until all monsters are defeated.
I was hopelessly in to Doom almost 20 years ago and it is this cartoon splatterthon style that I aim to replicate. But there is a subtle difference between the 2 experiences ( not including the obvious visual differences ) and that is in how the game is controlled.

Doom

Doom

In Doom you had to point the marine in the right direction then pull the trigger. In my game you simply aim a crosshair at the bad guy and the rest is done for you.
Actually swinging the viewpoint of the marine around in Doom is quite a skill and therefore something to be learned before the game can be successfully beaten.
Simply moving a crosshair across a static scene is not so hard. So although Doom and my game have a similar core concept – shoot the hell out of bad guys – they are in reality a million miles apart in terms of the experience.

What I need to do is find a balance between the thrill of shooting stuff to hell and applying some kind of a challenge and skill curve.

As the father of modern video gaming Nolan Bushnell put it all those years ago, games should be easy to learn and difficult to master.
So far my game is simple to learn and simple to master. Watching monsters explode in a sea of bullets will only hold our interest for so long if there’s no challenge.

So I added another dynamic – ammo.
Rather than just spraying endless rounds down the corridor I wanted the player to have the concept of ammo protection. To aid this I started hurling supplies in wooden crates down the corridor. When shot the player could tap health or one of the two ammo types to collect.
My game suddenly became as much of an exercise in ammo conservation as it did a shooter. Much like Doom. I was happy.
But still the game was a little too easy. So I looked again at Doom in more detail.

The weapons in Doom ranged from pea shooter to a rid-the-room-of-everything gun.
The action was staged such that you didn’t get the Big F* Gun until later in the game. In between that and the poxy pea shooter you had such things as a shotgun ( never bettered ), chain gun, rocket launcher and plasma rifle. Progressively more deadly and intense and progressively more thirsty for your precious ammo. Better still if you let fly with a rocket within 10 feet of a wall or monster it tended to smart a little.
Looking at Area51 I realised that I needed a similar constraint on weapon usage.

Although I’ve yet to implement the changes I suspect that the two weapons that I have that use Plasma might be benefit from being a little volatile at close range. Quite possibly useless against a certain monster as well. Not sure yet.

Finally, the bad guys in Doom shot back. From fireballs, to magic to just plain bullets you had to duck for cover around every corner. I need to find a way to force the player to protect himself against attacks. Perhaps using a shield or some such physical barrier. Clearly I can’t display the viewpoint changing to be behind a wall or ducking for cover so I need to be a little creative.

So the point of this rather hasty blog post is that it’s not always such a great idea to use a “fun” mechanic as the centrepiece of your game. At least not without giving it some serious consideration.
The game’s design, i.e. the challenge that you ultimately want the player to overcome, should always be your main focus. Otherwise you wind up trying to squeeze a game in to something that you become quite unhealthily precious about.

Although I will keep the concept of blasting monsters in a cramped space I will adapt the game to be much more of a challenge. Hopefully without taking away any of the skills required to complete it.
And that’s the point. Unless your game has skills to be learned in order to overcome your challenges your game is going to be pretty flat.

 

 

Coffee break thoughts on the use of colour in attracting potential gamers

I’ve always loved to see colour in games.
Back in the hazy days of the video game arcades it was always the colourful cabinets that drew me and for the most part the colourful games that took my last coin.
I think this is the key to much of the success in casual gaming.

When we make games we really need to consider the potential audience. What do they want to see to give our games a chance ?
With an increasing number of portal sites for HTML5 games and more games emerging from the community we need to ensure that our games stand out in the crowd.

I remember as a 14 year old reading Jeff Minter‘s view on the subject in the popular British magazine Computer and Video Games. In it he basically argued that gamers love colour. They respond to colour far more enthusiastically than they do any other form of presentation. You just have to look at some of Jeff’s games to see that he means what he says.

colourful screens

Comparing colour to black & white courtesy of www.html5games.com

Introducing colour in to your games doesn’t necessarily mean that you need to be a wizz with graphics. If your graphic skills are limited then just rethink how you wish to apply the style and objects to your game. By default it seems a programmer thinks in terms of black and white. if your graphic skills extend to using primitive shapes then draw them in yellow against a complimentary background – purple or dark blue, for example. Instead of dropping white shapes on to the screen spawn multiple coloured shapes. If your game involves explosions don’t just assume a yellow circle will suffice, figure out how to throw a few multi-coloured circles around.

Colourful games are fun to watch. If in food we argue that we eat with our eyes before we eat with our mouths then I would suggest that in games we play with our eyes before we so much as commit to playing.
A game that involves a small white object against a sea of black might have worked when arcade capabilities were severely limited but they won’t kick the player in to taking on your game quite so much in 2011.

Finally, I’ve always believed that the best games are “screenshotable”. That is you can be at any point in the game and capturing the screen to the clipboard would give you something to share amongst your mates and be proud of. Better still it would give you something to hand over to a web site that says “this is an accurate representation of my game.”

( You can play the game Cirplosion here: www.html5games.com/2011/12/cirplosion-3/ )

Good use of screen composition and rich colours helps to paint a picture to the player. It helps him to conjur up a view of the game before he’s dropped his coin in to the slot. That’s the target in my opinion. We have to assume that our audience has just one coin in their pocket and you are basically answering the question “why should I spend my last coin on your game ?”

As designers we must think not just of the game and its challenges but of the player and his difficult decision on which game to commit to with his last coin.

Looking for inspiration again with old fantasy games

The last couple of times I’ve tried to create an original game I’ve ended up taking the seeds of a game off the shelf and completing it. I’m determined this time to actually explore something new.

I’ve been digging around the web ( well, YouTube mainly ) for some of the games that I enjoyed playing on friends home computers back in the day. There are some classics ranging from Elite ( still an astonishingly complex game ) to Knight Lore to Boulderdash to countless platform games to… well just about everything.
Something that struck me was the way that games were named back then. There was a certain romance about the title and the image that it conjured in your mind. Even if the actual game didn’t quite live up to the dramatic title.
It wasn’t uncommon to be buying games called “The Castle of Terror” or “Haunted Citadel”. Proper fantasy titles with action that centered around the exploration of dungeons and the hurling of magic and such.
I loved those games and have done my best to honour them with my earlier games. e.g. Castle Adventure.

 

Atari Gauntlet

Gauntlet

I’m quite intrigued by the notion of “buddy” games. Golden Axe, Gauntlet and other such titles. It’d be pretty cool to pick a character to control from a selection of, say, four characters. Then once you’re in the game the CPU controls the other three.
I’ve blogged about my love for Gauntlet before in some detail.
I like the idea of ridding randomly generated dungeons of all manner of hell beings and then counting up the gold at the end. Possibly with a shop or something to power your team up.

 

Atari Gauntlet

Atari's Gauntlet - screenshot

I’ll enjoy opening up Photoshop and doodling some character designs. Just to get a feel for what such a dungeon game might look like.

I’d also like to research putting the game on to Facebook and getting a multiplayer angle to it.

I can see the benefits of it. Imagine the following scenario.

You’re on Facebook and 3 of your friends are also online. You send them a quick message “Hey, let’s go play Dungeon Adventures” ( or some such title ). The game populates with 4 players and away you go !

Better still you could form a party that the game saves based on your Facebook login so next time it’s even easier.

All just ideas right now and quite exciting.

%d bloggers like this: