Some thoughts on player interaction with HTML5 mobile games

I currently have a number of small side projects which are for all intents and purposes simple design tests. My current focus is with establishing new, reliable and aesthetically satisfying ways to have the player interact with the game.

Basic control – Touch, slide and first-touch free movement

Initially with Wizard Wars I stuck to the basics and the game centered around tapping the screen to direct the wizard.

Subsequent games have seen simple slide left and right controls implemented to steer cars and star ships.

More recent games have seen me register the first touch and allow free movement in all directions. I like this approach and generally find it to be the most satisfying to play. Games like Crossfire (my homage to the C64’s shoot ’em up heyday) and Desert Rescue really benefit from this style.
So for the most part all of my games exclusively feature one of those three methods of controlling the on-screen character.

The only time I veered from this simplicity was with Dungeon Adventure. With hindsight I’d perhaps concede it didn’t work out so well and the control system took a lot out of what was a potentially enjoyable game.

Feedback and limitations

With mobile game development – HTML5 or otherwise – it’s vital that the game’s design is wrapped around the limitations of the touch screen control. I have never implemented on-screen buttons and don’t have any plans to. It just doesn’t work for me. The whole point of pressing buttons to affect the action is in the touch > tactile response > on-screen action dynamic.
For example the process of a ships laser firing in response to a button being pressed is empty without that central bit – the tactile response to the player.

Feedback in games is important to me, as is the management of player expectation. In many cases it makes a lot of sense to automate basic actions. e.g. your on-screen character automatically runs and you simply tap the screen to have him jump.

With Danger Ranger I desperately wanted a platform game experience. To achieve this I placed a jump pad at the base of the screen. As the player’s on-screen character walked in to the jump pad he was thrust high in to the air. The player’s only control was in sliding their finger left and right to control the character’s movement.

So there are several genres that can be achieved even with the limitations of a touch screen. We just need to consider these limitations and design the game around them.

Classically of course ports of great arcade games have failed to deliver since they were designed for different interfaces. Defender springs to mind. A proper spaghetti control system if ever there was one. Not a great game to try and play on a sheet of glass.

Fusing a couple of ideas together

So moving forward with some new design ideas I’d like to try and fuse some of these touch styles together.

Initially I considered Bomb Jack as a project.
I’d always loved the game in the arcades and figured it was colourful and lively enough to translate in to a good casual / mobile game. Better still it could quite easily be shoe-horned in to my Danger Ranger code base.
The issue of course was in the control of “Jack” (I assume that’s his name).

Bomb Jack arcade screenshot

Bomb Jack (Arcade version)

So what is Bomb Jack ?
Well essentially you play the game by directing Jack around the screen with the joystick. and hitting a button to have him jump in the air. He only jumps when he’s on solid ground be it the base of the screen or one of the floating platforms.

This makes things quite easy in that I will always know when he’s NOT flying or falling. So if the guy is on terra firma any tap above him on the screen could be an instruction to launch him skyward.

Of course whilst he’s in flight the side swiping controls still work to control him albeit at a slower rate.
For this to work there would have to be a threshold set around the character since the simple act of tapping the screen with the intention of moving him left or right is also going to fire touchStart().

Jump vs movement

   A         B  <-- Any touch here results in a jump
  ------------- <-- Slide control threshold
                <-- Any touch in this region moves Jack left and right
        J       <-- Jack's position
  ============= <-- Solid ground

Hopefully the crude illustration above makes some sense.
J is relative to Jack’s position and the dashed line above him marks the uppermost region for touch events that result in his walking left and right.

Tapping in the A or B region will send Jack skyward to the left or the right respectively. In reality I would aim Jack to the point that the touch was registered to give greater granularity of movement.

Whilst Jack is in flight the illustration isn’t relevant and any touch on the screen will drift him left or right until he finds solid ground.

Pure theory right now but so far I’m happy with it. In fact if it works I’d be happy to consider more complex platform games.

Bubble Bust and HTML5 mobile casual gaming thoughts

I’ve been thinking a lot about some casual game ideas just lately.

In my notebook under future reference / potential game ideas I have so many things jotted down. Games such as:

  • Beach Head
  • Ballblazer
  • Bomb Jack
  • Jet Set Willy
  • Joust
  • Encounter!
  • Zork

…the list is about 20 long !
Zork obviously stands out here since it is a pure text adventure game. I actually wrote quite a bit of a JavaScript adventure engine a few years back. With minimal tweaking I reckon I could craft it in to a fairly useful mobile web game.

Bubble Bust ! screenshotBubble Bust!

But the point here is that regardless of this list the games that I’ve been playing a heck of a lot just lately are bubble popping affairs. Games such as Bubble Bust ! (above)
I’ve always resisted these games. Figured they were just mundane and far too repetitive for my tastes.
I was wrong. The challenges are clear and tough enough to keep me coming back for more on a pretty regular basis.

I’m a huge fan of any game that contains a strong core theme and with clever design presents numerous ways to challenge you around it.

For example, in Galaxians we shoot aliens. We also have to shoot them as they dive. Galaga expands on this and forces us to time our shots when the captured fighter is being flown around.

Bubble Bust! plays with its core design beautifully. Essentially we are in the business of matching colours (3 or more in contact pops the bubbles) but of course it doesn’t end there. Different bubbles presented to the player have different abilities. Bombs destroy bubbles in a small area. Rainbow bubbles can be used as a generic colour. Steel balls tear through bubbles destroying everything in their path. So on and so forth.

At its heart Bubble Bust! is a race against the clock.
As the bubble pack descends you have less time to think about your next move. The game ends when you either fail to clear the bottom most bubble before it crosses the line or when you pop the “key” bubble.

The pace of the game is high and for a casual game it’s perfect.

I know there’s a glut of games in this genre but of the ones I’ve played this one captures the excitement best.

So now I’m thinking about the whole “lots of decisions in a short amount of time” scenario and trying to apply it to some ideas of my own. Soccer, Horse Racing, Bingo … those types of things.

What’s more I want to try and honour the idea that if you fail you’re left with a sense of “with one more go I can crack it”. To achieve that I need to make the process of actually playing the game equal parts fun and rewarding.

It’s a new direction for me. To date I’ve pretty much made shooters in some guise or another. With my next project I’ll most likely be stood outside of my comfort zone !

 

Initial thoughts on an HTML5 football (soccer) game

I’m looking at producing a football (soccer) game for my next project. Looking around at the world of football in computer games is a pretty interesting exercise.
Thanks to sites like YouTube it’s not so difficult to perform quick comparisons between games from a variety of different platforms.

See for yourself what I found over a coffee break earlier today.


World Cup 90 Sega Megadrive


Versus Net Soccer Konami Arcade


Cyberball Not sure which platform – cool portrait view


American Football game – cool portrait view


Beautifully presented N64 J-league game


Excellent execution. Non-fluid game.


Neo Geo. Say no more. Beautifully presented.

I included some of the non-Soccer games to highlight their presentation. I typically like to produce games in a portrait orientation so the Cyberball game was particularly interesting to me.

As a huge fan of football myself I can say that the thrills of the game are in the attacks. The faster and more precise the counter-attacks in a game the more thrilling it is for the spectator.
I want to build a game that captures the very best parts of a football match. To that end I may well ditch the standard approach for making such a game in favour of purely concentrating on the arcade thrills of attacking football.

Throw-ins, corner kicks, offside.. they’re all pretty dull to an arcade gamer.

One idea that I’ve had is to start each as a set piece where the player has to defend a free kick. If the attacking team scores then the set piece is reset and the player must defend again.
If the set piece breaks down and the ball goes out then the stage is reset and again the player must defend.
If however the set piece fails and the player obtains possession then the thrill of the counter attack ensues.

I like simple controls so initially my thoughts are to tap left, centre or right on the screen to direct the goalkeeper when in defensive mode.
In counter-attack mode the AI for the advancing players will be handled by the code such that the player simply taps the screen to pass the ball. The theory is that the player taps ANYWHERE on the screen and the code will select the nearest team mate to pass to.
Once the team player with the ball moves beyond the overlaid 20 – 25 yard line he automatically shoots.

This is very much a dumbed down approach but it currently works for me to think like this.
I’m a huge fan of simple controls and simple execution.

 

Crossfire progress update

My current project, the C64 shooter inspired Crossfire, is nearing completion.

All features are in place and the code is pretty stable just now.  I’m hoping to finish testing in the next two days and spend the following couple of days creating all the marketing materials.

I play through my games a heck of a lot. Last night I was blasting away when it occurred to me that the game needs just something extra. A stage that gives the player a break from the normal trench blasting and avoiding objects. So I created a Challenge Stage.

The challenge stage runs the trench at 4x its normal speed.
It’s automatically hellishly difficult to perform the usual blast and collect but is by no means impossible.
I set the challenge stage to appear every couple of waves and right now it looks and feels amazing.

Very excited to be finishing this soon and will of course be presenting it on playstar.mobi once its done.

Crossfire – an HTML5 vertical shoot ’em up – development update

Just a quick update as work on Crossfire (previously Stargun) is moving at pace just now.

I’m very keen to use the project as an exercise in broadening the featureset of my game framework.
Currently I’m focusing on creating the kind of vertical shoot ’em up that was popular around the late 80’s and early 90’s. The sort of game that you might have played on an Atari ST or Commodore Amiga. I didn’t personally own either machine as this was a period in my life when I didn’t do much with computers – parties, playing in a rock band and girls were far more important :) – so this is very much an exercise in researching the games of the day via YouTube & VGMuseum, buying a few old magazines and firing up emulators.

It’s a huge amount of fun and the results are proving to be very exciting.
I’m still using a 2 pixel brush as a hang over from the previous game. I rather like the pixellated style of the artwork that is produced and may continue the theme through a few more games. Drawing with a bigger brush in Photoshop is a lot of fun !
I guess the irony is that the artists of the day were probably desperate to work with greater palettes and increased resolutions. They would probably look in horror at how I adoringly craft these retro-inspired spaceships and effects :)

Crossfire fighter graphic

So the features of the game are pretty established.
The in-game level editor / structure allows me to define a JSON map of the level and then iterate through based on a pre-defined delay. As the code ticks through the level row by row a new set of obstacles / bonuses / enemies / power-ups is spawned just off the top of the screen and moves slowly in to view and off down the screen.
Based on the sprite’s type and class it will then animate, glide, blink on and off, shift left and right, rotate, be destroyable or simply shoot at the player.  The combinations available to the level’s designer are huge !

I also took the decision to have the player’s fighter move instantly with the touch.
In River Raider I implemented a kind of drag effect. As you slid your finger across the screen the plane drifted in to position. A kind of drag effect. I think it worked for that game and gave you a little more to think about. But in Crossfire I wanted the movement to be instant.
It’s a mobile game so to enable this functionality and still be able to see the fighter sprite I register the first touch on the screen and move the fighter relative to subsequent touch co-ordinates. This really is the correct way to control your on-screen fighter / character. Too many times we see a virtual joypad and it really doesn’t work.

So currently I’m designing the enemy and toying with the idea of using a pre-rendered scrolling backdrop rather than just the trenchlines that I detailed in an earlier post. The game has a distinct feel and character which I think (hope) the retro shooter enthusiasts will enjoy.
It also has some cool sound effects courtesy of the Buzz JS Audio Library. Getting this to work across the board on mobile is flaky so ultimately I think the audio will be a desktop feature. But big things in mobile audio are on the horizon so watch this space.

Hoping to complete the game within a couple of weeks and push it to PlayStar (mobile only) shortly after. As always the game will be available for licencing on a non-exclusive basis.

Introducing Hellspawn – an HTML5 take on the frenzy of Robotron and Gridrunner

I’ve spent the last two days wrapped up in game development and it’s produced some fantastic results.
I set out initially to further refine my code base for making arcade games. What fell out of that process was quite eye-opening in that I realised I could tie quite a few operations together within the code and produce some nice effects.
Assembling the framework for the game takes just minutes these days so now being able to quickly define the basic presentation of the game in little more than half an hour is a real boost and means that I can concentrate on the specifics of the game itself.

The game (which I’m currently calling Hellspawn since endless waves of creatures spawn in to the scene to be blasted in to tiny pixels) is essentially my take on Jeff Minter‘s stunning Gridrunner from 3 decades ago. Like Jeff I love colour in my games but for me this has been a bit of a departure since the style is very much of the very early days of the video game arcades.
I’m generally most comfortable when I can use a broad palette and have several pixels to play with. For Hellspawn I’m going for the pixelated look and setting a 2px brush in Photoshop. I’m also using fairly vibrant “web safe” colours as they really stand out against the dark grid that scrolls behind the action. I’m not sure this will be the most screenshot friendly game I’ve made but I’m aiming for a game that is possibly the most frenetic.

Hellspawn screenshot

So the challenge is in presenting a playable game to the end user. Like all my games this is designed with mobile in mind and specifically iOS. I test on iPhone 4 and iPad. The game scales to fill the screen on whatever device is is played on so the gamer gets the full screen to play with.

My initial focus was on filling the screen with aliens. I’d wanted to re-create Robotron. The challenge there is of course converting the two joystick approach to a touchscreen. Something had to be sacrificed.
I took a long look at Robotron and play it for some time. I also played Gridrunner and newer Gridrunner++ from 10 years ago. The thrill of these games is common – blasting things to pieces. I had to have a game where the focus was on reducing sprites to an explosion of dots and colour.

I’ve always liked Gridrunner’s presentation. The sight of squares filling the screen is quite pleasing for me. Especially when juxtaposed against the circles, dots and random shapes that fly around above them.
I wanted to make a big deal out of this. I really wanted to fill the screen with chaos. Almost Bangai-O style chaos.

So I set out to create some simple pixel graphics and threw them around randomly.
For the player I decided to have a starship that runs along a rail. Initially I just slid it left and right effectively bouncing between end points. The ship autofires a stream of laser shots. Roughly 10 on screen at any one time.
I then implemented an icon that the player controls. As I was drawing it I liked the look of a spinning orb with some kind of a magical glow that span around it so I stuck with it.
As with Rebel Rescue I ensured that the player could touch any place on the screen to initiate full multi-directional movement. This is of huge importance. The alternative would see the player’s finger masking the orb. Definitely not a good idea.
The orb acts liked a magnet for the starship’s lasers. As you direct the orb  it can be quite mesmerising watching the laser shots as they arc around the screen blasting sprites to pieces.

I’m thrilled by the effect.
The added bonus of unifying my code base also means that I have some neat routines at my disposal for presenting special effects. This is a game that really needs special effects.

I later re-worked the player’s path code so that I could define multiple paths. The player is now presented with a rail that wraps the screen in some circumstances. As the ship moves along the rail between waypoints it spins to face the right direction for the action.

I’m absolutely thrilled by what’s come out of the last 48 hours of development and look forward to launching the game on Mozilla’s Marketplace and our own PlayStar.mobi once its complete.

 

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.

Designing an HTML5 arcade game the crude way

I’ve tried so many different ways to create what you might call a templated approach to designing arcade games. In some cases it’s worked. In others it simply hasn’t.
To a certain degree I play safe with established game mechanics. River Raider, Dungeon Adventure and Galactians all follow a tried and tested model that was employed successfully to games that are 30 years old.

I always create a design document of sorts and dump it in the root of my game project. It’s extremely crude and carries the file name _devnotes.txt

Here’s an example using my current project Distant Orbit:

Game file: DISTANT ORBIT

Destroy, avoid and collect across a sprawling, scrolling landscape with the ultimate goal of destroying the alien communication tower.
Player must protect his Energy Bar (Shields) as his starfighter comes under attack from alien craft.
Comm towers are protected by energy generators that must be destroyed. These are the same as obstacle sprites but have a special type of "ENERGY" for the collision detection.
A visual indicator shows the number of energy towers that remain.

Aliens     - avoid and destroy
Bonus aliens - avoid and destroy for released bonus, e.g. laser enhancement, fast-lasers, replenish energy
Alien laser bombs    - launched from alien surface craft ( avoid )
Energy pool - on the floor ( fly over to gain energy )
Dark matter - on the floor ( avoid or lose energy )
Environment obstacles    - on the floor ( avoid )
Energy tower - glowing obstacle ( destroy )
Alien saucer - hovers over terrain in the near distance and launches energy bombs toward the player
- not sure how to destroy this yet - if at all !
Gems and powercells    - on the floor ( collect )

There will be heavy emphasis on the avoid / collect dynamic. A skillful starfighter pilot will be able to shift between obstacles and collect valuable items whilst gunning down advancing aliens.

Tower becomes vulnerable when all energy towers are destroyed ( icon lights go out as each tower goes down )
Level ends when tower is destroyed. Cut sequence showing the starfighter leaving the planet.
Show analysis of the spoils from the planet and award bonus points and achievements,
i.e. All planet aliens destroyed, mothership destroyed, collected 100 powercells
Cut sequence showing the starmap and selection of next planet.
Possibly inject a running storyline.

It occurs to me that this is actually how I work. I’m not one for tremendous amounts of planning upfront. I’d much rather get my hands dirty with code and some basic “placeholder” artwork and try to mould a game from what I have. A kind of organic approach if you like.
With some games it’s easy to do this since you know the basics of the game’s design based on the “classic” game that it borrows from. But with other games, such as Distant Orbit, it’s a little more tricky.

Distant Orbit screenshot

In development - Distant Orbit

When I am faced with actually having to balance the game’s design aspects myself I tend to start with what the player has and see it in terms of what he is trying to protect.
So in the current case I naturally consider the starfighter and how I must protect it. What is the worst case, what could possibly go wrong and what would I need to do / obtain to prevent these things from happening. ( Something of a CBT approach to game design !? )

This naturally leads me to thinking about an appropriate adversary and presents some questions that need to be answered and understood.

  • How do I control the player sprite ?
  • How do I attack / avoid ?
  • What is my short term goal ?

Once I’ve understood these things I can identify how best to challenge the player.
With a game like Dungeon Adventure ( which was essentially Pac-Man with magic ) it was simple. There is little room to move, the player had to think a few steps ahead so place required objects where the monster will tread.

I like to inject a few ideas in to the game and play them before approving / eliminating them. Again very organic. If I like it, it supports the ultmate goal of the game and it “feels” OK to play then it stays.

With mobile gaming you always have to think of the device and its limitations. I only ever target touch screen control so a few things must be assumed.
I loath and detest on-screen buttons and joysticks. It’s lazy and un-necessary. So to get the best out of the game it makes sense to have a few things happen automatically. Laser firing, item collection, trigger points for certain actions such as opening doors. Again, if it works it stays.

Whilst there is harmony in the process I am happy that the game is going in the right direction. As Jackson Pollock said “it’s only when I lose contact with the painting that the result is a mess.”
I strongly believe this. When it’s going well and the design elements are slotting in to place such that the end product is fun and rewarding great things can happen. Good ideas follow good ideas. Having confidence and belief in your work sends you on a journey of design and development that you ultimately return to in future work since you “got it right”.

The rub here is of course that you end of with a shelf loaded with game projects at varying stages of development. I currently have as many games on the shelf as I do completed. There’s some damned good stuff on that shelf and when I find the right amount of inspiration I will complete them all. Sometimes it’s just the way it goes.

If I lose touch with the work I move on.

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.

 

%d bloggers like this: