Adding achievements to Distant Orbit

It struck me whilst developing Distant Orbit that the game was crying out for a more persistent challenge – for want of a better phrase.
I wanted people to be able to play the game for a little while and have progress saved after each phase. That’s a fairly standard thing and in a standalone sense using HTML5’s localStorage I can of course achieve this.
But I also wanted the player to have something to aim for that wasn’t directly part of the story within the game and that’s where achievements come in.

Distant Orbit screenshot

Distant Orbit

Achievements (or awards ) are a great way to give the gamer a reason to come back and have another go beyond actually completing the immediate task. In this case blasting the aliens to pieces and knocking out the tower.

I recently played Shuffle Party on the XBox Live Arcade on my Windows Phone. It’s a fun and very tidy little game that sees you spending most of your time trying to unlock content and gain achievements. I liked it so much I wanted to implement it.
So last night I spent a good couple of hours doing just that.
The results are certainly very rewarding and I think the overall appeal of the game has shot up 10 fold.

The plot of the game as stated is simple: destroy the enemy tower installations in each stage. That’s your primary goal. But within that, thanks to the introduction of achievements, you now have the added challenge of not losing your wingman, not taking any hits, completing the stage with full energy.. so on and so forth.

There are four planets to fly between each with 10 stages. Within each planet there are 6 awards to aim for with a special award handed out for destroying every tower on the planet. Currently (and most likely finally) moving between stages on each planet is sequential. Once the player has completed a set amount of stages and / or unlocked a set amount of achievements the next planet becomes available.

Each planet has its own name, tower range and of course its own look and feel. Again this gives the player something more to aim for. We are all naturally curious as to what the unlocked content actually looks like and how it plays !

I intend to create a little badge icon for each achievement. Furthermore I intend to structure the code such that the achievements can be portable and implement easily with a cloud service such as clay.io.

So far Distant Orbit has taken around 6 weeks. That’s 2 weeks longer than I’d anticipated. Thankfully the addition of the new features means that I get that in future titles and should hopefully rein the dev times back to a manageable month.

Distant Orbit – some new design ideas

Almost as if to underline my previous post about designing games around a loose brief I now find myself in the unusual position of having a far bigger game on my hands than originally intended.

The design for Distant Orbit was to be quite simple. As a super hero deep space star fighter you are dispatched to multiple planets to defeat the bad guys and destroy large monolithic towers. Once complete you leave the planet, pick a new destination and repeat. As the game progresses the structured levels become more complex and more challenging.

I’m at a stage with the game’s development where I’m spending as much time playing as I am coding. All graphics just now are placeholder.
What I love about this stage of development is just how rich the ideas can be thanks to the fact that you can actually play enough of the game to visualise such things.
Already things are changing.
For example; originally I had wanted to make the game as a simple shooter where the player adopts the role of an anonymous star pilot.
With each loss of a ‘life’ a new starship would become available and the game would continue.
But as I was playing the game it occurred to me that it would be so much cooler if actually the player adopts the role of a team of star pilots. So with life #1 the player is actually in the role of a young Cadet pilot named Aero. She has her own ship and that ship has its own laser style.
When Aero’s ship takes too much damage (there’s an on-screen energy bar indicator) she retreats and the next pilot slides in to view. I currently call him Fuzz :)
When Fuzz takes too much damage the final pilot in the party slides in to view.
So the characters in the game nevere actually ‘die’.

What’s great about this is that it allows me to do a few extra things with the game. First it allows me to create some cool character graphics for each pilot.
Second it allows me to weave a story and some interplay between the characters. The story is simple: the pilot buddies are from the Star Force Academy. As they fight the alien threat they grow in experience and ultimately will gain enough experience to graduate. So initially they fight as cadets but once the system is cleared the cadets will gain rank.
This drives a consistent theme throughout the game and keeps the player interested. It also allows me to script some suitably cool ‘buddy chat’ between the characters.
The presentation for such chat is as you would expect in that the characters portrait appears on the screen in a greyed strip with text alongside.
Note: for ease of localisation I use the Arial/Sans-Serif font family and save the text file in UTF-8.

Although I haven’t coded it yet I’m also considering a system of repairing and powering up each star ship. The reason for this is simple, it provides me with a means of locking content. Similarly I would like to lock pilots. So essentially the initial three pilots are the default. With enough experience the player can add to the party from a group of more experienced academy pilots.

I guess the point here is that I left enough flexibility in the design to allow it to happen. Better still since there’s enough flexibility in the code structure that I’ve created to make these games the transition from design idea to code was straight forward.

I look forward to being able to show a little more as the game nears completion.

Dungeon Adventure, lengthy developments and the future of making HTML5 games

Spending 2 months on a game is not what I had in mind when, in January, I started to plan for the next 12 months.
I have spent the last year refining my code base and HTML5 game framework to the point where I can sketch out an idea and have a prototype up and running in about an hour. This is pretty much the beauty of a) knowing and understanding your own code and b) having a clear idea for the game’s design from the outset.

With Dungeon Adventure I wandered off the beaten path in that I was taking my framework in a new direction with the control system and, if I am brutaly honest, didn’t have a clear design goal. I’m not very good at “winging it” with game design. The vision has to be clear for me and I have to believe in every aspect of the game’s mechanics in order to see it through.

Screenshot

Dungeon Adventure

I’ve learned a lot this last couple of months. Dungeon Adventure was to be my Gauntlet. In fact I’d written that word so many times of late I had convinced myself that I was honouring Atari’s 1985 arcade classic so much that gamers might well be forgiving of a few minor niggles. I was wrong.
Worse still the game is really NOT Gauntlet. Not even close.It’s much more of a maze game in the style of PacMan. Yes you play as a Wizard and yes you get to hurl magic at the ghosts but strictly speaking it’s a PacMan game.

I don’t want to bash it to death. Dungeon Adventure is a tight game with a lot of fun to be had. I think it will appeal to a lot of gamers but for me, as the designer, it took me in a direction that I’m not comfortable with. And that is my point. Wandering out of your comfort zone can not be taken lightly. The requirement for planning is vital if you want to stay on track. Especially if you have plans for new games to be completed in the time it’s taking you to complete just one game.

When you work closely on a game you get swept along by it. Your attachement to it is so strong and so intimate that you really have to work hard to see the wood for the trees sometimes.
Although I am extremely happy with the game’s appearance and challenges there are areas of it that I would love to revisit when I have more time.

For future developments I intend to spend more time ahead of the coding just figuring out the basics. I also intend to stick to the control systems that I know and where necessary expand on them. There’s no reason why I shouldn’t be able to create a perfectly attractive and challenging arcade game in just two weeks.
I’ve been in the business of software development for years. Too many years probably. But in terms of gaming (despite once working as an artist for Acclaim) I’m relatively new.

So now I’m in the process of getting back on track and am already working on a new game. A game where the controls are simple, the goals are clear and the challenges are plentiful and fun. I started this game just 3 days ago and will aim to finish it in less than 10. And then it’s on to the next game.

Suddenley the hobbiest element of developing browser games is colliding head on with the professional aspects of software development. The key for me will be in striking the right balance such that it all remains as fun today as it was when I first figured I could make sprites with DOM objects.

 

HTML5 gaming – what are we talking about?

The conversation about HTML5 gaming is changing all the time.

In just 12 short months we’ve gone from starting conversations with “hey, what’s this cool new tech / standard I can make games with ?” to “hey, I can make some money here,” and “hey, look at all these amazing tools I get to play with.”

But what were the conversations we were having inbetween and what are the conversations we could / should be having in the coming 12 months ?

It’s true that in the few years since the dev world adopted HTML5 as a standard fit for gaming requirements the vendor world has dragged its heels somewhat in trying to catch up and meet the requirements of the rapidly expanding community. Consistent support across the board is slowly emerging with the ever stubborn Internet Explorer finally adding some weight to the game.
Sluggish adoption is no more evident than in the iOS 5 upgrade pushed out by Apple towards the back end of last year. Finally developers could target Apple’s mobile devices and enjoy a practical amount of horse power for constructing good quality arcade games.
Better still the eyes of the world’s mobile gaming portal operators were opened and opened wide. Millions of people own iOS devices and millions of people playing games that are free from the trappings of App Store regulation means, in theory, greater margins.
Mobile web gaming took off and the conversations soon turned to that of monetisation and commercial interests.

But for me it is the conversations that typically started “where do I start” that have changed the most.
A quick look around Twitter and the open web development community in general will show you that there is now a tremendous focus on tools, engines and frameworks.

High profile software vendor Adobe changed things when it announced Adobe Edge. Although it’s not game specific it certainly provides a rich tool set for creating content for web presentation using the same open standards that we use to build games. If you’re in any doubt about the intimate relationship between HTML5 markup, JavaScript and CSS Adobe’s Edge will help you to muddle through.
This is good. It gives developers a way in and changes the conversation back to “how do I … ?”

ImpactJS, a well established and robust HTML5 game development engine launched in 2011 is a fantastic example of that blend of good design and perfect timing.
Around the time of Impact’s launch the conversations in the HTML5 gaming community were stuck at “where do I start ?”, “Why won’t it do this ? “, “I feel like I’m fighting this, ” and of course the biggest pain in everybody’s backside “what the hell is the score with HTML5 audio ?”

Such was the urgency for amateur developers and small studios to try and make some headway in this burgeoning world of HTML5 gaming  the conversations soon included “how can I get started quickly and reliably with HTML5 games ?”, “what is the path of least risk ( cost ) in creating HTML5 games ?”

Solid game engines like ImpactJS proved not only that there was a market for such tools but also that the market for HTML5 games was rich and growing. Conversations could be seen emerging on the web along the lines of “how many people are playing these HTML5 games ?”, “is there REALLY a market for HTML5 games ?” Perhaps the most important question of all “WHO is playing these games ?” was yet to be answered.

Facebook kept the wave from falling.
For what is arguably the most important web site out there to state that it would extend its social gaming to mobile devices was an enormous event. One that I feel really hasn’t been fully understood for its importance even now.
Any questions surrounding the size of the market for HTML5 games were answered in a heartbeat.
Facebook’s 350 million mobile users were all entering the arena.

Soon the high profile successes of companies like Dextrose (AVES engine) and RocketPack would be matched by similarly sized outfits looking to have their technologies adopted by comparable giants to Zynga and Disney.
The game development community couldn’t lose. Strategies shifted and large gaming portals started to follow Spil Games’ direction by embracing  HTML5 games as the future.
“We’re going to make HTML5 games. So what’s the best engine ? Who are the best developers ? Who can give us the games that we need right now to bolster our portfolio ?”

HTML5 game developers were right back at the centre of the discussion and game engine creators started to put 48 hour shifts in to get their own software up to production standards. Everybody wants this new wave of game creator to be on side and in bed with their brand.
There are so many engines and smaller frameworks available to developers now that the conversations have again switched back to “which is the best engine ?” and “which engine has produced the best games”.
“Which engine will give me the flexibility to produce the games that I / the market want to make / see ?”

Then in November 2011 the world of HTML5 gaming took another significant shot in the arm from an unexpected source when Adobe announced it was cancelling support for its mobile Flash platform.

Although it’s arguable just how much of an impact Flash has had on mobile devices over the years the importance of this announcement to the broader web gaming community cannot be overstated. Adobe, a huge player in the business of providing rich web experiences, had flung the doors wide open for HTML5 developers to stampede through with greater confidence.
Consequently the game changed.
Hardened Flash developers took notice and began to turn their attentions to the potential for this new kid on the block. Again as a direct consequence the bar was and still is being raised. Flash developers bring with them an enormous amount of experience and talent which, if HTML5 is to be taken seriously, is much needed.

Tools for HTML5 game creation are really starting to gain greater exposure. Just go and look at Scirra and GameMaker. Both of whom enjoy active and fertile communities. These companies are helping to turn the conversations back around to “hey, look what I can make” and “wow, I can do THIS !”

I love the fact that amateur coders, such as myself, can still play a huge part in the world of game development by sitting in their bedroom dreaming up great games and then turn to their computer and, well,  just make it happen. This is vital in keeping the conversation focused around “WOW !” and not “How ?”

We really need to be seeing more games.
Games that are good, bad and ugly. It really doesn’t matter.
If somebody creates a game that they’ve enjoyed making such that they’re in love with the process of making games then that’s great for everybody. Quality comes with experience and confidence.
You can’t very well teach somebody that the real crunch in making a great game comes in that final 10% of its development. They just have to see it for themselves and understand what was missing or not required.

The more people writing their own engines /frameworks and the more people using off the shelf tools and engines the better. Everybody has their part to play.

So in short, although the standards have been around for a little while now it’s really only in the last 12 months that we’ve seen significant changes in the way that we discuss HTML5 games. Moving from a sense of intrigue and exploration to a more practical sense of efficient development and commercial positioning.
My only fear is that the amateur “bedroom” coder / game designer becomes intimidated and struggles to find a foothold in a rapidly developing world of tools, engines and commercialisation. As exciting and indeed necessary as all of those things are they can very well provide a psychological barrier to entry at the most amateur level.

I hope I’m wrong and the conversation amongst the developer community continues to centre around “Look at the cool games that I’m making / can make with this technology !”
If you are an HTML5 game developer then the future is yours. If you become good at it you will be worth money. Never lose sight of your passion for games. There are plenty of tools emerging to make your life easier. Always ask yourself “how can I make this ?” or “wouldn’t it be cool if…”

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 screen and player movement

Today I have spent a hopeless amount of time playing with the touch screen interface for a new game.
The game is a maze game, similar in many respects to Pac-Man in the way that it executes, but quite different in its content.

When I started to assemble the code for the player’s sprite behaviour I knew I was going to be faced with a tough decision regarding movement control.
In previous games this has never really been much of an issue since I’m generally dealing with movement in a fairly basic way. Galactians for example was a simple slide left and slide right affair. Wizard Wars was a touch-to-go-here game and Danger Ranger was a case of sliding your thumb or finger to turn the ranger to walk left or right. Everything else in that game was about jumping. In any case I’d taken the movement code from Dragons and not added much more to it.

But with this maze game it’s important to me that the whole thing feels natural. I really didn’t want the player to be concerned with where he has to put his finger in order to move. I really do loath the idea of semi-transparent virtual d-pads. It’s just that the touch screen interface can be used to great effect without them.

But, I had to explore all options.

Before I prattle on about the theory of implementing player movement let me show you how I set up and manage the touch code.

function initTouch()
{
	if(checkForTouch()) {
		if (document.body.addEventListener)
		{
			document.body.addEventListener('touchmove', touchMove, false);
			document.body.addEventListener('touchstart', touchStart, false);
			document.body.addEventListener('touchend', touchEnd, false);
		} else {
			window.addEventListener('touchmove', touchMove, false);
			window.addEventListener('touchstart', touchStart, false);
			window.addEventListener('touchend', touchEnd, false);
		}
	} else {
		window.addEventListener('mousedown', mouseDown, false);
		window.addEventListener('mousemove', mouseMove, false);
		window.addEventListener('mouseup', mouseUp, false);
		write("No touch capability.");
	}
};

function checkForTouch() {		
	var d = document.createElement("div");
	d.setAttribute("ontouchmove", "return;");
	return typeof d.ontouchmove == "function" ? true : false;
};

As you can see I perform a fairly basic test to see whether touch is supported as a function and if not fall back to mouse control. If you were to play any of my games on the desktop with diags switched on you’d see the line “No touch capability.” every time.
The point here is the level of control that we have over touch start, move and end. It’s pretty powerful and gives us a ton of options for controlling our games.

So how do we do anything with touch ?
It’s quite simple. Every time a touch event fires I store the co-ords in the touch object. Something like this..

var touch = {};
function touchStart(event)
{
	var xy = getXY(event.touches[0]);
	touch.startx = xy.x;
	touch.starty = xy.y;
};

function getXY(event)
{
	try
	{
		var xy = {};
		xy.x = (event.pageX - (g.canvas.offsetParent ? g.canvas.parentNode.offsetLeft : 0));
		xy.y = (event.pageY - (g.canvas.offsetParent ? g.canvas.parentNode.offsetTop : 0));
		return xy;
	}
	catch (e)
	{
		write("getXY: " + e.message);
	}
};

I generally wrap most functions in try / catch. Just pretend I did that with the touchStart() function ;-)
So again it’s all fairly straight forward. Returning an object with just the x and y parameters I get some control over how to handle my player movement. Notice that I use the offsets to determine the true position since I’m positioning my game canvas in the centre of the document with margin: 0px auto and a width of 320px; On the desktop this is an issue. Generally on mobile it isn’t since I’m handling the display with the viewport.

So now I’ve got some co-ordinates and I can start to explore options for controlling the player.

The game itself is a maze crawling affair. I want my character to walk the maze avoid monsters and collecting goodies. There will be a little more to it than that but essentially this gives me something to go on when considering the player’s control of his character.

Option 1 is all about a virtual overlaid d-pad. You will have seen them. God awful things that just don’t feel natural at all. They’re generally plonked in the lower corner of the screen and you are forced to control your game in a small space.
I created a simple d-pad graphic and placed it in the lower right corner.
I then wrote some code to track which edge of the d-pad had been pressed, uploaded the game and hit the refresh on the phone.
( Note: my X/Y detection code is primitive. I’m checking the screen to see if the touch event was recorded at the same location as the location of the d-pad graphic. )
To cut a long story short I must have spent 50% of my time looking at the blessed d-pad and not even enjoying watching my character march around the maze.
I ditched this idea swiftly.

Option 2 saw me drawing thin arrow graphics at the top, right, bottom and left most edges of the game screen.
The theory was sound. I’d just let the player touch some fairly large areas of the screen in order to move the player up, right, down or left.
Again I uploaded and refreshed on the phone.
Initially it felt OK. I was able to smoothly move the character around and it felt pretty good having more than a couple of cm flexibility in the movement.
But I soon tired of having my hand obscuring the lower corners of the screen when the player character was down there and I was in need of some finer movement.
I ditched the idea.

Option 3 was actually fairly similar to option 1 but with greater scope.
I switched the phone off and just touched the screen. I played the imaginary game and tried to feel for what was right.
As I moved my thumb around I realised that the kind of control I was after was in fact quite similar to option 1. But I wanted the d-pad to be positioned based upon where I first tapped the screen. A kind of user-definable d-pad location.
So I set about creating a sequence that went something like:
touchStart: record the centre of the d-pad co-ordinates
touchMove: throw the event at a d-pad handler and update touch x and y

With the centre of the d-pad recorded as my origin I then needed to figure out how the co-ordinates of touchMove translated in to a new direction for the player.
Something like..

if (touch.newx > touch.startx) moveright; 

There are some complications here.
Imagine that the finger is swiping to the right from an origin of say 128,128.
As the touchMove event continues to fire the x is incrementing through 129, 130, 131 and this is great. I’m clearly looking to move to the right.
But then my thumb flicks up or down the slightest amount.
My y value is also incrementing 128,129,130,131…
So which is true ?
Does the player want to move right or down ?

I’m actually still working this bit out and will blog about it once I’ve got it working.

Overall the movement is fairly smooth just now and I’m working hard to make it as smooth as possible.
User feedback and a logical touch interface is vital in these games. If you mess this bit up you kill the entire game and your player will just go looking for something else to play.

Other things that I’m curious about are walking DOWN a corridor, effectively “hugging” the wall to turn RIGHT or LEFT at the next available exit.
To this end I’ve played Pac-Man quite a bit just lately and learned some valuable design lessons.
I’m also mucking about setting touch.testx and touch.testy in an attempt to sniff the wall for available exits.
Actually this code works pretty good right now.

When there is more to see I will return to this subject.
Thanks for listening to me waffle ;)
Please feel free to share your own thoughts, ideas words of wisdom on the subject.

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.

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”.

 

 

%d bloggers like this: