ancient wisdom

To content | To menu | To search

Thursday 15 April 2010

Ancient Frog HD

I decided to take the plunge and release the iPad version of Ancient Frog on iPad launch day. It's a bit of a risk - I'm really not comfortable releasing something that I haven't seen running on the actual target hardware - but I thought it would be more likely to get noticed if it was in at the beginning. It also did me good to have a tight and immovable deadline to work towards. It's very hard to buckle down and finish a game, even one that's supposedly already finished, and the launch deadline forced me to finally decide what's in and what's out, and to polish off all the loose ends. To massacre a metaphor.

I did leave some stuff out. There's supposed to be interactive water, but I was worried about the performance, so that's waiting for my iPad to turn up. (It was a bit of a saga in itself, getting one shipped out to New Zealand, but it's finally FedExing its way across the Pacific.) As soon as I've plugged in all the missing stuff and buffed up the performance, I'll be releasing a lovely update.

I called the iPad version Ancient Frog HD. This may have been a mistake - the HD suffix has been applied to a lot of iPhone titles that have been lazily up-rezzed with no regard to the different form factor and demands of the iPad. I like to think that Ancient Frog HD is a significant upgrade to the original title (it certainly took a significant amount of time & effort), and I'm not sure that's the message that people are getting.

It had a little feature in 'what's hot' for the first week, which produced reasonable sales. However, the iPad app store is already crowded, and the user base is still much smaller than the iPhone, so I'm hoping for a nice steady slow burner.

If you're lucky enough to have an iPad, you can check it out on iTunes here.

Friday 29 January 2010

Ancient Frog on the iPad

You may have missed it - the news slipped out pretty quietly - but Apple has announced a new product line.

The iPad is essentially a scaled up iPod touch, so naturally I'm interested in what it means for Ancient Frog.

According to the announcement (and my experiments in the simulator), iPhone apps work on the iPad straight out of the box, with no changes needed. However, since the screen is higher resolution (1024x768 instead of 320x480), and a different aspect ratio (4x3 instead of 2x3), such apps won't look their best. Below are a couple of mockups of what you'd see if you had an iPad right now and ran Ancient Frog on it. (All of the pictures are shrunk down to fit on your screen - click on them to see them full res.)

The first mode just runs the iPhone app at its original resolution, giving you a little window in the middle of the screen:

It also gives you the option to run it "2x" - doubling the size of each pixel (in each direction), so the app uses more of the iPad's screen (640x960 of it). This makes it bigger, but either blurry or blocky depending on whether or not the device is going to filter the image when it scales up. I suspect they'll go for blocky, which is what I've simulated here.

Now, neither of these options is particularly elegant or attractive. With a bit of fiddling around though, I can make the current iPhone application recognise the iPad and behave more like a native application on that platform. What I've done here is run it at 768x1024, but allowing it to letterbox slightly to retain the original aspect ratio (luckily the ragged border gives me a neat way to bring the edges in a bit, as well as a bit of room to lose some pixels top and bottom). This already looks way better than the previous shot - lots of elements are still blurry, but things that appear at varying scales in the game are already at a higher resolution. This means the text, the daisy and the particle effects are all crisp, which makes the whole thing seem higher resolution.

So that's good - I can put a bit of work into the current app, and release a free update that makes it play nicely on the iPad. But it's still blurry - what would be involved in making it look great on the new hardware?

That's where it gets a bit tricky. The work involved suddenly goes up by an order of magnitude. Every level has to be reworked, and I have to handle the original aspect ratio, as well as two new ones for the iPad (for portrait and landscape). The download size also goes up - currently I fit just under the 10MB limit that allows people to download over their phone. With the background textures doubled up, I'm over 20MB and start to lose impulse buys (as well as bloating out the app for everyone, regardless of whether they have an iPad).

So my plan is to leave it at that - an incremental upgrade to make the experience worthwhile on the iPad - and offer a separate, HD, version for iPad only. This will use the reworked levels I've been beavering away at for the last few months, and make use of its groovy auto-aspect-ratio handling (the desktop version can be stretched to all sorts of whacky resolutions without breaking the effect).

And here's the result:

It's work in progress (the lighting has yet to be graded correctly, and the particles are missing), but you get the idea. The full screen is used, the frog is back down to a more appropriate size for human fingers to prod at, and there's some nice little environmental stuff going on for you to play with.

It would be nice if there were a way to offer a cheap upgrade path for people who already have the iPhone version, and I'm looking at whether there's a clever way to do that.

I can't wait to get my hands on the physical hardware. I think there's going to be some very interesting times for gaming in the next few years.

Wednesday 27 January 2010


Some good news for Ancient Frog this month.

It was honourably mentioned twice in the IGF Mobile awards - Best Mobile Game Design, and Achievement In Art. I only just missed the deadline for submitting last year, which is why it's appearing here so late. (Interestingly, Ancient Frog was out on the App Store shortly before Zen Bound, one of last year's winners. They clearly had a working build earlier than I did. I remember I was in a tearing hurry to get something out the door before Dylan was born, and pretty much released as soon as the levels were ready.)

I've also been nominated in the IMGA awards - under Excellence In Design.

It's nice getting this recognition - particularly the categories I'm falling into. I'm an old (old, old) school game programmer, and was always one for getting my teeth into every part of the creation of a game. Towards the end of my time in the mainstream games industry I'd been pushed further and further into a narrow niche, until I was just a middle-manager with a team of programmers to look after. Getting nominated for 'art' and 'design' awards helps take some of the bad taste of those times away.

Tuesday 5 January 2010


My thrashing around trying to pin down the details of project Blue Comb continues. I have decided on an art style, which is helping to frame the rest of it. Ancient Frog started with a very simple and clear premise, but this new project is just a collection of obsessions which I haven't yet managed to glue together. I suspect something will need to get cut before I'm able to finish it.

I just received an email from Jef Armstrong, whose game Mondrian was recently released. Jef emailed me last year, shortly after Ancient Frog was released, saying words to the effect that he liked my puzzle game, he was writing his own puzzle game, so let's talk about puzzle games. Flicking back through the emails, there's some blogworthy stuff about how I created the levels in Ancient Frog:

Creating the puzzles was one of the big challenges with Ancient Frog. I've been thinking about writing a blog article about it, because it's something I personally find fascinating. A large proportion of all the code written for Frog (possibly the majority - I should check) went into the tools for creating the puzzles. However, I'm a bit wary about talking too much about it in public because I suspect that some people would be disappointed to learn that it's not all lovingly hand crafted by some sort of puzzle making master craftsman.

Seems a bit silly now. Let's hear the details!

The most important part of the toolset is the solver. This has two levels - a quick pass to determine whether a particular layout has any solution at all, and a slow pass to exhaustively determine the optimum solution. (In this context, 'quick' means anything up to 15 seconds, and 'slow' can be up to 6 hours). There's nothing clever about the way it works. It uses brute force and a fast computer to walk down the tree of possible moves. There's some interesting optimisation, and stuff like exploiting symmetry, early-out, loop detection and so on, but essentially it uses the approach that computer scientists say is impossible. But that's because it's their job to come up with general solutions which work for the worst cases in the biggest data sets. I'm able to limit the problem space to something which is achievable by brute force, and just skip puzzles which are taking too long to check.

So the process for generating a puzzle goes like this:

* I choose a start point and an end point, and a set of pegs from which it can choose its route (this lets me put a particular move into a puzzle, but often I'll just leave it to choose from all pegs)

* I press the magic button

* It goes through a loop where it removes a random peg and tests whether a solution exists. If there is no solution, it replaces the peg and flags it as required. This process is repeated until no peg can be removed without creating an impossible puzzle.

* It checks the result against all the previously generated puzzles to ensure it's not a duplicate (taking into account simple translation, rotation and mirroring)

* If I like the look of the result, I press magic button #2 and generate the optimum solution for it

* I quickly step through the solution to see if I like the look of it. I tend to reject puzzles that require too much walking backwards, or that push the frog's head off the side of the screen or have the legs passing over the fly.

I like to generate a whole bunch in one sitting, then try to put them in order based on how difficult I think they look, and how difficult the solver reckoned they were (that's a bit of code that needs some work by the way - some of my rankings are quite a bit off). Then I leave them for a day or so while I get on with other stuff, so I can play them through without knowing how they're solved. In my playthrough, I log how long it takes me to solve, how many dead ends I go down, how many undos etc, all of which information also goes into the difficulty ranking. Each time I play through, I'll generally shuffle levels around a bit to improve the progression, but I also like having runs of very similar layouts with increasingly difficult solutions.

The tools also include stuff for applying backgrounds, frog species, fine-tuning of board position, rotation & translation of the whole puzzle and so on.

Interesting stuff!

Happy new year.

Friday 18 December 2009

Naming Your Project

I'm currently experiencing a problem that's so common among game developers, and so rarely talked about. My new game has the wrong name.

To be clear, this is a very early prototype I'm talking about, and it's just the name of the project - its directory on the disk and a handful of its files - that's wrong. I don't even know what title it's going to have when it's released. But once you've named your project, it's a lot of work to completely rename it. For one thing, the locations of all the files will change, which will cause you all sorts of problems if you're using version control software (and if you're not, there's all sorts of other problems waiting for you right there).

If you've chosen a name that's a perfect fit for your game, and your game changes, then every time you see it you find it a little bit jarring. It's not a big problem, but it's a constant niggle.

The brilliant solution I've come up with is to start using completely random names for my projects. I've taken a leaf out of the 1950s British military's book, and decided to use Rainbow Codes. A project is now named using a colour and a noun. And to make my life easier, I've created a web page to choose the colour and noun at random.

The problem I have now, of course, is that it's too convenient. I find myself repeatedly hitting refresh, looking for the 'random' combination that best suits what I have in mind. Does this game feel like Blue Boy, or is it more of a Violet Pencil? I'll just keep going until I find the perfect fit. And when I have a mid-project change of direction, well, it's not going to be such a good fit any more.

Thursday 10 December 2009

Number 1!

A couple of days ago I put Ancient Frog on sale ($1.99! Down from $4.99! This crazy offer cannot last!) The last time it went on sale was back in May (with rather disappointing results), and I thought it was worth trying again. The App Store is constantly evolving, after all.

I was impatient to see what effect the price drop was having, so I started stat mining. Previously, I've tended only to look at the bigger markets - originally the overwhelming majority of my sales came from the US and UK, later adding Germany, Canada and Australia. Over time, though, the distribution has started to flatten out more. The US is still the biggest of course, but it now accounts for under 50% of my sales, and Japan is up to nearly 10%. With that in mind, I decided to just grab everything - every ranking from every region - and see how I was doing.

One figure jumped out at me immediately: in one of the rows, Ancient Frog was ranked at #1. The number 1 paid app! Woohoo! Still got it, 10 months after release! Number 1... in the Family Games category... in Paraguay. But who cares about the details? That's got to be worth a screenshot:

In fact, digging further, I saw that in the Paraguay App Store I was not just the #1 paid app in Family Games, but the #2 Puzzle Game, #2 Game overall, and the #4 paid app in the entire region. I owned Paraguay! This is how fortunes are made, right?

Well, it turns out that to reach these dizzyingly high rankings, you only need to sell one copy. I had a trawl through my stats, and precisely one Paraguayan has bought Ancient Frog. (Thanks, whoever you are! If I'm ever in Paraguay I'll buy you a drink.)

Interesting, but probably not that surprising. But then I had a thought - just how much ranking does one purchase get you in all of the other regions? This price cut has led to a very broad but very shallow spread of new sales, and in a number of regions I've just made my first sale. In the following table, I've listed all of the regions where I've sold only one copy in at least the last two weeks. The purchase generally took place in the last couple of days, but I've listed some where I'm still ranked despite an interval of several weeks. The positions noted are the highest that I saw - these can drop off quite quickly (because we're necessarily dealing with regions with very granular figures).

So it's all a bit haphazard and imprecise, but I think it's interesting for all that.

App Store ranking achievable with a single sale:

Country        Family Puzzle Games Apps
Paraguay       1      2      2     4
Czech Republic 18     39
Slovakia (1)   20     36     50    94
Finland        28     71
Hong Kong      31     60
Poland         41     83
Portugal (2)   42     91
UAE            54     92
Luxembourg (3) 59
China          67
Austria        72 
Kuwait         75
Singapore      84
Turkey         90
Thailand       92
Switzerland    98

1 I saw it at #4 in Family in Slovakia, but when I took this set of figures a day later, it had dropped to #20
2 Copy sold on Nov 21
3 Copy sold on Nov 28

Now you might say that this isn't terribly useful or interesting information - obviously regions with low sales won't take much to break into their rankings. You might say that, but have you got the number 1 paid app in Paraguay (Games/Family subcategory)?

No you haven't.

I have.

Monday 26 October 2009

Quitting The Day Job

At about the time Ancient Frog came out, I started a new job for 4 days a week. I'd always assumed Frog would would be a slow burner if it burned at all, and the early app store gold rush hoopla had pretty much passed me by, so a bit of steady income seemed like a good idea. The job involved creating museum digital interactives, which I'd done before and enjoyed, and working for a guy I'd worked for before and liked.

As it turned out, Ancient Frog was featured by Apple and so made the majority of its sales in the first couple of months, and the museum job turned out to be a bit more workaday than I'd hoped. And the trouble with working for someone you like is that you can't just tell them to take their job and shove it when you decide it's not to your liking.

So what with one thing and another, I've been looking forward to the time when I'd be free of external obligations and able to jump back into the games. That time has finally arrived. I spent the day working on the core technology for my new game.

Spring has arrived in my adopted hemisphere, and I do enjoy a new beginning.

Saturday 3 October 2009

Nearly there...

Back from an extended visit to the UK. It was good catching up with all the people I haven't seen since I moved to NZ, and showing off the son and heir.

I'm rapidly approaching the end of some paying work, and when it's finished I'm planning to go full time on Ancient Workshop. It's been really annoying this year, watching opportunities drifting past for my own games while I work on somebody else's stuff. Definitely time to give it the attention it deserves.

Meanwhile, here's Ancient Frog on a list of "10 of the Most Beautiful iPhone & iPod Touch Apps" - makes my day.

Tuesday 25 August 2009

Level 80

By request...

Saturday 22 August 2009


I'm continuing to eke out Ancient Frog's tail with little incremental bumps. 1.10 adds another level. I'll probably keep going at this rate on it for a while yet, giving me some space to get the last of the museum work out of the way and finish up at least one other platform.

I'm champing at the bit to get going on something brand new and shiny, but while there's still life in the Frog, it makes sense to feed it.

Tuesday 11 August 2009

I was interviewed at - I have a bit of a grump about working in the games industry, but it's all better now.

Monday 27 July 2009


Removing the free version had no immediate effect. Sales trundled on unchanged for about a week, then started dropping - which they were probably due to do anyway. I put LE back on the store, and have released the 1.09 update.

1.09 contains a brand new level (albeit in an existing habitat), as well as the latest version of the Ancient Engine.

Thursday 16 July 2009

Fiddling with the App Store

Sales of Ancient Frog are at a stable level at the moment, with no new reviews or updates to perk them up (the 1.08 update was completely buried in the 4th of July glut). It seems like a good time to try removing the free edition (Ancient Frog LE) from the App Store, and seeing what effect that has. I've been unconvinced by its value as a sales tool - for a start, sales dropped when I first released it - so I'd like to do a little more investigation.

I wouldn't rule out putting the light edition back in the store if it seems justified, but I'd like to give it a while to let any latency work its way through the system.

Monday 6 July 2009


1.07 was so long in Apple QA that I'd finished a nice clutch of UI improvements by the time it came out. I decided to push it through immediately, to see what would happen if I got out an update while the boost in visibility was still in effect from the previous one - whether there'd be any advantage to it. As it turned out, it got buried in the mass of updates they got through while clearing the decks for the 4th of July (apparently some sort of cause for celebration in the US), so it didn't really do me any good.

1.08 fixes some nasty flickering that could happen when turning the page in the UI, improves performance (or at least battery life), and adds better feedback to the buttons. The buttons in the game started life on a mouse-based machine, and they didn't give terribly good feedback when deprived of a mouse hover condition. This meant you could be left wondering whether you'd actually pressed them or whether the game had hung or what. Now there's a glow effect that pops up the moment they activate, and stays there if the game has to lurch for a moment loading data. It's something that really should have been in from the start. Better late than never.

I haven't started on the next update, but there will be one. It seems to be the most successful way to keep the game visible. Downloads of Ancient Frog LE show a step up followed by mathematically perfect logarithmic decay after an update. (Downloads of Ancient Frog itself are low enough that the noise spoils the perfection of the curve.)

Monday 22 June 2009


1.07 - The Hints Version - has been languishing in Apple QA for a while now. I guess they're snowed under with 3.0 / 3GS business.

In the end I went for a system which offers hints via a question mark in the top left corner, but it only appears when you've taken significantly more than the par moves, or reset the puzzle. You can make it appear immediately from a button in the daisy menu. The idea is that if you're doing fine you won't be bothered by it. If you're struggling, you're offered some help.

There's a couple of levels where the frog's feet can get in the way of the hint button. I make the button disappear in these cases. It's not ideal, but I'm hoping that in actual use nobody will encounter this limitation. If I'd designed the button in from the start, I'd have just dropped the levels that clash, but I don't want to go removing content from installed games.

Pressing the hint button once gives you an intermediate goal position to aim for. Pressing it again gives the best move to take next. Pressing it a third time hides the hint.

Once you've reached the hint position, it disappears. If you still need help, you have to press the button again. I'll just have to see if this works in the wild - it may be that when people turn to the button for help, they want to be led through the entire solution. I'm assuming they only want a kick in the right direction.

If you've taken a hint during the game, you won't get a yellow flower in the garden, even if you come in with a perfect score.

I'm curious to see how this version fares. If you have any opinions on it, I'd love an email or blog comment about it. (Or just write an app store "* - why dose this app evan exist?" review.)

Meanwhile, 1.07 has been in QA so long that I'm nearly ready with 1.08. There's a bunch of niggly performance / feedback stuff that I've finally got round to fixing, which should make the buttons feel more responsive (and in some cases actually be more responsive).

Thursday 21 May 2009


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!

Saturday 16 May 2009

level 79

I had an email from a player who's solved every level at par, except for 79 which he couldn't do in under 26 moves.

Sorry Philip, it is possible.

An impressive achievement nonetheless! It's clearly time I made some new levels...

Wednesday 13 May 2009

Off Sale!

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.

Saturday 9 May 2009

On sale!

I had a bit of a jump in sales. It took me a couple of days to work out why (please, Apple, give me some stats!) - Ancient Frog has reappeared in 'What we're playing' on the App Store. So I thought I'd take advantage of that and the bump I expect to get from 1.06 coming out, and put it on sale. See if I can ride it up the charts a bit and make it stick for while.

I've dropped it to $2.99. Of course, I could just make 40% less income now.

I won't keep it on sale for long - and it'll be very short if it doesn't look like the volume is making up for the drop - because I don't see how such a low price can be justified in the long term. Still, the App Store has surprised me before - when I started work on Ancient Frog, I never imagined it going for $5, still less breaking even at that price.

Sunday 3 May 2009

The Demo

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: would do nicely.

- page 2 of 3 -