Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/27/d312880249/htdocs/spacemonsters.co.uk/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 77

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/27/d312880249/htdocs/spacemonsters.co.uk/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 87
in-app purchasing – in search of Space Monsters

Great Boulder of Death and in app purchasing in HTML5 games

Every once in a while a new game emerges that I think is worthy of a closer look. Recently I downloaded Pik Pok’s Giant Boulder of Death (GBoD). As with one of their earlier titles, Flick Kick Football, the key to the game’s appeal is in that nagging “if I just have one more go I’ll improve…” dynamic. It really does work a treat.

Flick Kick Football is a tight game. You can launch and be playing within seconds, the controls are very basic and the challenge is enormous. A perfect game experience in every respect.

Giant Boulder of Death Giant Boulder of Death Giant Boulder of Death Giant Boulder of Death

GBoD is the same. Well almost. It takes just a little longer to start playing and the adverts and in-app purchasing breaks are a distraction. This aside though and the game is just too perfect to ignore.

Note: I initially titled this post Great Boulder of Death – a study and blueprint for making fun, challenging and market friendly games.

So what is this game?
Well essentially it’s a love story between two boulders. Man boulder sits high atop a mountain rock whilst woman boulder sits as an ornament in the village at the foot of the valley. A man with a chisel hacks the woman boulder in to tiny pieces and from afar man boulder seeks to exact his revenge by rolling at pace down the mountain destroying everything in its way.

This game is just loaded with tiny elements that go to making a wonderful challenge and overall experience.
As you hurtle down the mountain (itself an extremely satisfying experience) the town mayor orders some defences. Spiky walls, spike ball hurling contraptions, giant spiky robots… the more you unravel the game the more you will see.

To steer the boulder you tilt your device. I play on iPad Mini. It works a treat. To leap over stuff you tap the screen.

Initially your tilting effectiveness is pretty minor. As is your ability to jump. But the more in-game coins that you earn the greater your ability to “pay” for upgrades. As with all good games that use this model you don’t have to spend a single real-world penny. You can just play the game. The more you play the better you become and the more dib-dobs you earn. Spending your money wisely results in improved control, reduced adversaries and an overal greater chance of obtaining rewards.
The balance is perfect. No goals seem too distant. There’s always an upgrade within reaching distance.

My own experience developing Distant Orbit showed to me that achieving this balance is not the result of guess work. It takes a tremendous amount of testing to get the right balance of challenge to reward.

So the game is essentially an exercise in swerving around obstacles, destroying targets (sheep, ramblers, cars, horses, houses…) and accumulating enough coin to upgrade and make future games fractionally less challenging and therefore more fun. The carrot that is dangled by suggesting that a few more coins could increase the speed or height at which your boulder can slide or leap is enticing. The thought that you could reap even more destruction on the world by spending hard-earned game currency is a real thrill.
And that is also a key factor in the game. The process of actually playing the game and taking on the challenges is fun. Why? Because you are destroying stuff. Whatever could be more fun?

By combining speed with destruction and injecting a liberal amount of chaos the developers have, I’m sure, tapped in to what we as humans crave – total control and a little bit of madness :)

I should say right here that this game is not easy.
Dodging spike bombs is hard. In fact maddeningly so. You are left with a sense of frustration that it wasn’t actually humanly possible to avoid certain obstacles. In some scenarios the seemingly random nature of the object generation really does conspire against you. I’ve never encountered a dead end – let’s face it that would be a fairly neat way to hack someone off and never see them again. But I have encountered situations where an emerging pathway is suddenly blocked and only the mightiest of leaps would get you through.

But this is nit-picking.

Where GBoD succeeds is in its tying together of all of theses wonderful elements.
As a gamer I’m left with that holy grail of gamer emotions – just one more go.
I love games that focus on the score and on the importance of achieving as high a score as possible.
Some of the targets in the game focus on achieving high scores. This has to be the ultimate in “if I have one more go I’ll beat it”.

I’d really like to include as many elements from this game as I can in my current project. My current project is the start of a series. I’d like the gamer to feel that the first game in the series sets a precedent. I’d also like to leave the door open for in-app purchasing should any of my publishers require that feature.

In almost every conversation I have with clients these days in-app purchasing features.
I have code written to handle this but it’s my code. Integrating with 3rd party APIs will of course differ from solution to solution (assuming they’ve not gone the route of plugging in one of the off-the-shelf solutions).
I don’t like in-app purchasing models. They’re not a gamer’s solution. But I have to support them.

In-app purchasing is probably another post. For now I urge people to go and download Pik Pok’s impressive Great Boulder of Death.

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.

%d bloggers like this: