ancient wisdom

A 'hints' button is probably the most requested new feature for Ancient Frog. Time spent on free updates for Frog is time not spent working on the next game, but since each update gives me a little bump in sales, I'm going ahead and adding this feature. Having hints will also mean I can put some harder levels in the demo without (I hope) alienating people - I'm hoping this will make the demo a more effective sales tool.

It's an interesting problem to tackle, though. I'll start with the technical, and move on to the presentation.

The first thing that's needed is for the game to be able to work out what the best move to make is. This turns out to be really hard. A typical puzzle takes about 20 steps, and each pose can typically reach about 16 other poses, so that makes about 10^24 possible moves to search through. If it takes one microsecond to check a move, it would take about three times the age of the universe to find a solution.

Now, real puzzles don't allow the full range of movement at every step (they wouldn't be very interesting if they did), and there's a whole bunch of optimisations and shortcuts you can take to discard obviously wrong solutions. During development I wrote a tool to check the solutions to every level, and on a fast dual-core machine with 4GB of RAM, I have to leave it running overnight to verify all 100 levels. Some of them it can solve in under a minute, others take over an hour.

Clearly, this isn't going to work on the iPhone.

So what can I do? Well, I can store the solution that was calculated during the build process, and lead the player through that. But that only works if they're at the home position, and if they're looking for hints it's probably because they've tried a load of stuff and got stuck. I could make the game insist that they reset to the start before getting a hint, but that's not very elegant.

A better solution is to search backwards through the cached solution, looking for poses which are reachable in a couple of moves from the current pose. If we find one, we pick up the solution from there. That's great, but it only works if the player is on pretty much the right track. If they've gone off down a dead end, this system won't be able to find a pose in the solution that's close enough to their current position, and we're back to requiring a reset.

Luckily, we have another useful list of valid moves - the undo buffer. Because Ancient Frog stores every move to allow the player to step backwards, the hint system can use that. It just needs to search backwards through the undo buffer, and for each pose, search back through the solution to see if it can step from the one to the other. In the worst case, it would move back through the undo buffer right to the start, and then forward through the cached solution to the end. In practice it can usually get onto the solution after just a few steps back.

As a final refinement, it looks for shortcuts in the undo buffer (the player may have spent some time going in circles, or taking several moves to reach a pose right next to an earlier position), and trims them out.

That's the stage I've just finished. I can press a button, and the game will show me the best next move. It's pretty effective too - I've tried tying it up in knots, and in my testing I haven't been able to create a situation where it seems to be taking longer to get back on track than I'd expect. It won't always get the perfect solution from a pose several moves in the wrong direction, but it does a pretty good job of it. And if you start from the beginning, it will always lead you down the optimum path.

So that's that problem solved. But the aim of the exercise is not simply to find a solution and lead the player through it - it's to provide a hint. What I want is to provide an intermediate goal for the player to aim at, which will help them on their way. One of the criticisms levelled against the game in some of the App Store reviews was that playing it is a matter of trial and error rather than problem solving. That's not the experience I want people to come away with - clearly I haven't done a very good job through the level progression of teaching the tricks of the game. The hint system gives me another shot at it.

In each level there is usually one (or more, in harder levels) core move that holds the key to solving the puzzle. One that I use a lot is the sidestep across a gap:

The key to solving this type of puzzle involves getting into a position such that the hands can plant on either side of the gap, with enough room to swing out of it on the far side.

What I want my hint system to do, then, is identify these core moves, and show them as the intermediate goal. I don't want to manually tag the move for each of the 100 levels (and not just out of laziness - if the player is coming from a position off the cached solution, their core move may be in a different position). So how do I automatically identify it?

I'm currently experimenting with this, and it seems that the foot moving a particularly long distance in one go is a good measure of a core move. But there's work left to do in balancing how many moves ahead to limit the hint to, against how important the core move is. I'm also undecided about whether I should be showing the pose immediately before or immediately after the core move.

The remaining tasks required by this feature become easier to implement technically, and harder to design from a useability standpoint. For instance, I need to decide when to show the hint button - should it always be visible, or only appear if the player is struggling? How do I define struggling? Resetting the level is a good indicator, but some players don't even realise they can do that. When the button does appear, where should it go? only the Daisy corner is in clear space - anywhere else, and I'm in danger of covering up a peg. How do I mark puzzles that were solved with hints? I don't want people to feel they're being penalised for using a feature they were offered, but I've also had emails from people who've been solving the game the hard way and don't like the thought of other players just being handed the solution on a plate.

These are all surmountable problems, and I look forward to fiddling around finding the most elegant solution. But I thought it might be interesting to show what goes into satisfying a request as simple as 'add a hint button'.

Alongside this work, I'm also knocking the PC version into shape for a slightly unusual potential platform - more details on that when it's not a secret any more!

Results of the sale:

• Day 1 - sales sharply up, with the increase in volume more than making up for the decrease in price
• Day 2 - sales down, revenue back to where it was the day before the sale
• Day 3 - started losing money, stopped the sale.

So that was an interesting experiment. Even with Ancient Frog featured in 'What we're playing' with a big red 'SALE!' sticker across it, lowering the price lowered the revenue.

The logical thing to try next is raising the price. I think I'll have to couple it with some upgrades though - new features, and maybe a bunch of new levels.

This business stuff is quite interesting, but I'm definitely happier (and better at) making games than selling them.

I never did write a follow up post about the result of releasing the demo.

The reason is that I'm not really sure what effect it had after all. It certainly didn't reignite sales of the full version - shortly after the demo came out, sales dropped right down to a trickle. On the other hand, I'm not convinced that the demo is to blame - downloads of the free version are also pretty dismal, so I don't think people are getting that instead of the full version.

Sales were heading down anyway when I put the demo out (that's partly why I did it), and I think that as it dropped out of the charts, that accelerated its decline.

It's all just conjecture - I have no traffic stats from the App Store, so I'm just left guessing at what causes the effects I see.

I'm pretty happy with how the game did overall - featuring on the front page did it a world of good - but it would be good if I can stretch its tail out a bit longer.

A few more articles like this: http://www.msnbc.msn.com/id/30508084 would do nicely.

By popular request (well, by one request), here's the solution to puzzle 62 - the Corroboree level from Ancient Frog LE.

I think I made a mistake in using the perfect solution as the par value. The game would be less frustrating (and a bit richer) if the par value reflected a really good but not necessarily perfect solution, and if it were then possible to come in under par. Players wouldn't be banging their heads against the wall on the really nasty levels, and there'd be a feeling of having beaten the game if they got a better score.

There's a fair bit of smoothing out of the progression and difficulty in general that I'd like to do now that I've seen it played by a much broader base of people, but I don't like to change a puzzle that someone is in the middle of at the time the update goes out.

Meanwhile, 1.06 is getting ready to release. The trouble with optimising is that there's no absolute end to it, and once I've started I find it hard to stop.

Version 1.04 is up, and my iPhone has arrived, so I was able to check that the silent switch now works. (It does!)

The Light Edition, Ancient Frog LE, is also live on the app store! It will be interesting to see what effect a free demo has on sales. Some people swear by them, some say they cannibalise your sales. The next few days' stats will be interesting to see.

Apple finally sent out the financial reports for February. Still no actual money, but at least an indication that there will be some.

My iPhone game has made enough that I can afford to buy... looks around sheepishly... an iPhone. I've ordered a 16GB one in white.

I used an iPod touch during development, because it was the cheapest way to bootstrap myself into iPhone programming, but it meant that I have been unable to test the phone-only features such as the 'silent' switch. And so, not unexpectedly, Ancient Frog wasn't honouring it correctly. And so, also not unexpectedly, people were (quite understandably) complaining.

My reward for this sloppy quality control is a shiny new toy. Hurray!

Time for some SATIRE!

Most of the Ancient Frog reviews have been lovely, literate and positive. And emails to support@ancient-workshop.com have been even nicer - I think I've hit a genre that attracts frankly nicer people than did any of my previous games. But those 1-star blurts are what stand out on the sell page.

Well, Ancient Frog is out there and starting to earn its keep. It's patched to a respectable level, although I'll probably have another bash at the pesky undo gesture, and I'm tempted to give the menu screen a makeover. There's also a 'light' edition to consider, much though I'm wary of that (it's very hard to decide which levels to leave in - if I throw in a couple of tough ones, people might think all of the paid ones will be too hard. If I don't, they'll think there's no depth to it).

But that aside, for the first time in far too long I'm able to start considering new projects without getting pangs of 'unfinished business' guilt. It's a bit of a mental luxury, indulging myself in thoughts of all the neat little ideas that have been piling up during Frog's development. It's tempered slightly by the thought that, once I start on one of them, the others have to go back in the cupboard until I'm done.

My intention this time is to bang out something really quickly, using the tools and experience I've built up, and focusing on the tightest, most cut-down game mechanic I can manage. The fact that that has been my intention for every game I've worked on for at least ten years, and they've always ballooned in features and overrun in time, makes no dent in my optimism.

I've just uploaded Ancient Frog 1.03 to the app store. It'll probably spend about a week in Apple QA before going live.

The big bug fix is the stutter in the ambient sound loop. It's been gnawing at my conscience since I released the game - I knew it was annoying, but I released anyway in my mad rush to clear the decks before the son and heir turned up. I had a few hours of peace and quiet today and was able to have another look at the problem. In the end I admitted defeat on my original approach, and switched to a less highly compressed audio format. This puts the package size up by about a megabyte, but I think it's worth it for seamless looping.

The other addition is to tell people in the tutorial that the daisy is a button. Lots of people weren't stumbling upon this (and it's not that obvious really). The solution is a bit clunky (nobody reads text in games), but it's better than completely throwing people in at the deep end. It also makes the end of the tutorial a bit less abrupt, so win.

I had an email from an Ancient Frog player, frustrated that he couldn't reach par on the 'easy' puzzle 15.

Difficulty ratings are an inexact science in Ancient Frog - in many cases, a puzzle will switch from frustratingly hard to really trivial just by changing one move. I try to rate them so that puzzles requiring twisty turny routes are marked harder than ones which are mostly solved in a straight line. Overall, the difficulty levels average out to about right, but sometimes they just don't reflect what a particular player is experiencing,

Anyway, I sent him the solution, at least in part to show that the par rating was achievable. It was a bit of a faff describing the route (using ascii art), so I decided to write a little tool to generate solution slideshows.

Here's the output for puzzle 15. (look away if you don't want to know the results!)