Please login to submit a screenshot

Title James Pond 2 Robocod
Game Type Platform
Players 1
Compatibility All
Submission Andy Thomas (andy@adamantium.demon.co.uk)

Review
Having played the demo of the first game, I really wasn't sure if the
sequel was going to be of interest to me. However, when it got the AGA
treatment and became cheap, and having seen it being played at the local
computer club, I decided to give it a bash.
I'm not a big platform fanatic but from what I know of the genre, this
guy would give Mario a good run for his money. Certainly this was a very
beautiful game, beyond what the consoles of the day seemed to be doing.
Chalk that up to the AGA chipset. But beyond that, the extendy body of Mr
Pond was novel, and he even had vehicles that he could drive.
The cyborg nature of this incarnation of Mr Pond was quite amusing.
It allowed him to do a very good impression of Reed Richards out of
the Fantastic Four - you remember, the elastic bloke. Thusly Mr Pond
could reach up to grab ledges other aquatic agents just couldn't get
to. He also did a good impression of VINCENT and BOB out of the
Black Hole, by tucking his head down into his metallic body and
shielding himself from harm. Along with other power ups this made
for platform gameplay beyond the simple jumping and climbing ladders
routine.
I think this was also one of the first games to be linked in to a
brandname, in this case a certain chocolate bar linked to birds from a
cold climate. Zool was the next example I came across. I didn't complete
Robocod, but it was one of those games you came back to from time to time
when you just fancied bouncing around pretty screens for pure relaxation
value, and I'm sure that for platform addicts it was great.

"The names Pond, James Pond... Licensed to krill"

There has been a long tradition of game heroes drawn from the animal kingdom over the years. Crash is a Bandicoot, Sonic is a Hedgehog, Gex is a Gecko and Jim is an Earthworm [a pedant writes: technically an earthworm is not an animal it's an Annelid]. Anyway, one of videogaming great ''lost'' animal heroes is James Pond the super spy fish. This small orange cod starred in a well received if rather uninspired platform game; James Pond at the end of the 1980's [another pedant writes: fish aren't animals either and cod are about six foot long and white, not small and orange]. However the sequel James Pond 2: Robocod which debuted on the Commodore Amiga in 1990 and subsequently on the Sega Master System, proved that the concept of a running, jumping fish was one that had legs and its always been a big surprise to me that the game and character has faded into obscurity [a pedant writes again: fish don't actually have legs, they have fins and…SNIIIIP!!!!!].

The story of the game is quite simple. After his exploits in James Pond 1 where he saved the world from the sinister Dr. Maybe, our James has been provided with a robotic suit (by scientist ''Phil'') which lets him survive out of water and stretch to enormous lengths. He is chilling out with his penguin friends up in the Antarctic, skating, fishing, what have you when disaster strikes. The evil Dr. Maybe turns them all into chocolate biscuits!!! Which isn't quite as odd as it sounds; a chocolate biscuit manufacturer who makes a brand of biscuits called ''Penguin'' sponsored the game. The game features Penguin biscuits throughout.

Anyway, after losing his penguin friends in this heinous manner, James is informed that Dr. Maybe has infiltrated all of Santa's toy factories and has planted penguin bombs. James must get into the factories and defuse the bombs before they explode and ruin everyone's Christmas.

James is also informed that the wings and armour that was supposed to be added to his Robo-suit has been stolen by Dr. Maybe and so he must hunt down these extras to help him in his mission as well as finding the penguin bombs. He then goes to Dr. Maybe's castle which functions as a central level hub, here he can warp to all the factories, tackling them in any order he pleases.

So one of the more ludicrous plots in videogame history then. But one which perfectly introduces you to the bizarre and psychedelic world of James Pond, the worlds first robotically enhanced super-fish. The game plays out in a more straightforward manner. Each level is made up of platforms, pits and obstructions to be negotiated by jumping, bouncing, stretching and flying (with the requisite bonus item). Enemies are killed by being bounced on, secrets are found by smashing blocks. Various powerups are scattered around the levels, including invincibility, little wings to fly with, extra lives, energy powerups and even a flying bathtub to cruise around in at one point!

You must search each level for all the penguin bombs; once they are discovered you can leave the level via the flashing barbers pole exits. Occasionally these will lead to secret levels and bonus games. All levels can be revisited once completed meaning you can stock up with lives on earlier levels if the later ones are proving to difficult. At the end of each set of themed levels you face a Boss monster which must be defeated by studying its attack patterns and striking at the moment of weakness. There are nine ''missions'' or sets of levels in all, plus the final showdown with Dr. Maybe at the end.

From the description above the game sounds like little more than a Mario rip-off. It's true it does have all the hallmarks of a stereotypical Mario clone. Yet its rises above this simply by the sheer silliness of the in game experience. The graphics are amazing. The sheer colours and vibrancy of the design really blew me away at the time, and even revisiting it ten or so years later I am very impressed with how well the cartoon designs have aged. The designers really went to town exploiting every inch of the Amiga's graphical processing power. The result is every level is a riot of bright oranges, reds, pinks and purples. Every platform, every brick is beautifully shaded.

Enemies are chunky and humorous looking. As the theme is Christmas, all the enemies are psychotic children's toys come to life and out to kill you. So on one level you have to avoid birds made out of pencils with playing cards from wings, on another toy cars whose bumpers split into huge toothy mouths try to bite you and run you over. The first boss showdown sees you attempting to bounce on the head of a huge cuddly teddy bear that is intent on squishing you into whitebait. Further levels see you assaulted by ping-pong bats, mutant caterpillars, flowers, chess pieces and cherry pies (!)

With plenty of secrets tucked away on each of the enormous levels, there's much fun to be had exploring every inch of the game, especially when you never know what kind of ridiculous enemy might come at you next. The central hub level also has nooks and crannies that can be searched around as you unlock access to later levels and allows you to experiment with your Robo suit and practice your moves without danger of death. The controls and collision detection are excellent and the fact that James can be hit quite a few times before losing a life takes the edge of what can be quite a tricky game in places.

Overall, James Pond 2 is a riot to play. The gameplay maybe unoriginal but the inspired surrealness of the concept and design makes it a deeply enjoyable experience. Towards the end like many 2D platform games it can get very demanding on your reactions and memory and cheap deaths can be unavoidable. But the sheer charm of James himself, grooving backwards and forwards constantly in his stylish, stretchy suit always brings you back for more.

If you don't have access to the original Amiga version, then a very good conversion appeared on the Sega Master System. It suffers from less detail and a slightly less responsive control system (and also omits the Penguin biscuit sponsorship!), but its well worth tracking down if you are a fan of the platform genre. For myself I was excited to hear that Nintendo are considering releasing Robocod on the GameBoy Advance. I would love this to be the case as a whole new generation can experience the joys of James Pond and his battles with Dr. Maybe. Well thank you for herring me out about this great game, hope I didn't give you a haddock going on about it. Now if you'll excuse me I have no fish to keep you any longer, I'll see myself trout.




Reviewer's Score: 9/10 | Originally Posted: 03/06/02, Updated 03/06/02

Robocod is 50 frames per second of all colourful goodness! Was it difficult to keep the game running in a frame? Does the game slow down and drop a frame when too much is happening?

Running at 50/60 fps made a huge difference for scrolling games so it was a major goal. In Robocod's case, yes it was difficult because there was quite a bit going on and no real constraints on how things could be mapped (it would have been hard to optimize in specific ways without limiting the game and generally I much prefer to create open, generalized systems). So yes, it was very difficult to keep it in a frame, and frankly... I failed! Which is why I did something that I suspect was fairly unusual at the time: the game-play logic actually ran at 50fps via a timer interrupt while the main game loop received buffered render requests which it would fulfill as quickly as it could. I think this is the next best thing to a totally solid frame-rate - at least the game response doesn't drop into slow motion as things get busy. (Of course these days, frame-rate independence is a simple matter of scaling all movement by a time delta, but that isn't so viable when you're not working in floating point).

The screen setup seems to be the same as James Pond - 16 colours repeated twice so bitplane 5 is the real parallax layer (snowflakes on the main screen, and the colourful backgrounds everywhere else). I had a look at the code and bitplane 5 always seems to be at the same address (every 2 frames since it's double buffered) - this implies to me that you are redrawing that entire bitplane each frame update! Is that correct?

Yes, it's the same bit-plane usage, but definitely taken a lot further this time around. As you say, the 5th bitplane is fixed in memory and gets totally redrawn after every 16 pixels of smooth scroll. That gave me the freedom to do a lot more with it, including the option to force per-frame redraw to achieve animation as with the cogs background.

Originally I suspected the parallax layer was carefully constructed so that it had 16 repetitions of itself each an additional pixel offset from the last so that no matter what the scroll value was you would have an offset you could set the 5th bitplane pointer to and it would be correct. Did you ever think about using a trick like that or did you want the backgrounds to be far more flexible?

Yeah, I wanted to make a flexible system, because as you'll have seen there's quite a lot of usage variety across the game. I don't recall any stats, but I guess that a single plane full-redraw can't have been too expensive...

I'm surprised that the Amiga can update the entire screen (plotting new tiles in the sides, erasing the background where software-sprites were, redrawing all baddies and drawing bitplane 5 in it's entirety) and keep it at 50fps!

It certainly wasn't feasible to have all bit-planes being fully refreshed every frame. So the first four planes certainly used the hardware-scroll/strip redraw approach. Perhaps the plane 5 redraw contributed to the frame-rate stutters more than I can recall!

Can you explain how you setup the actual screen (copper-wrap etc) so it can scroll 8 directions and huge maps?

Well... If I remember correctly, it used the copper-wrap technique to allow for vertical scrolling. To also support horizontal motion, the bit-plane memory was carefully laid out to reserve an extra 16 pixels of screen height, then, as the side strip redraws occurred the base pointers just stepped forward/back by a word. It meant there was a limit to how wide a play-area could be (16 screens) which always bugged me slightly, but otherwise made for a pretty flexible system. I believe there were games after Robocod that eliminated the need for (and limit of) this buffer space but I never got to explore that technique.

If you disable sprites, many of the enemies flash or disappear for a while so they are sometimes drawn with the sprite hardware, and sometimes blitted. The score is drawn using sprites so that eliminates any available at the top, and James Pond is drawn down the bottom also with sprites so that disables any from the lower part.

I was very underwhelmed with what Amiga sprites offered, and being a fan of generalized systems, I decided to try and use them within my general object handling framework for JP2. This meant that the system would consider all the objects wanting to display each frame, and would pick some of them to display using sprites. The screen had four bands: the top and bottom 32 pixels used fixed sprites to show the score and 'lives' display, and the space in the centre was divided into two bands where any object of 32 pixels or less in height that wasn't straddling the line between the bands, would be blitted into a reserved area of sprite memory for quicker display (i.e. no put-pack or clipping). Perhaps this wasn't the absolute most efficient use I could have made of them, but I liked it because it meant I wasn't having to treat them as a special case; they would improve performance under a wide range of game scenarios.

Were the hardware sprites in the band multiplexed so you could re-use the 8 you had multiple times or they were only used once? (Presumably you had only 4 since they're surely all attached 16-colour sprites).

Multiplexed only in the sense of there being the two bands described above. They were always rendered using the 16 colour mode since all backgrounds and characters derived from the same 16 colour palette which again made things very flexible.

If you have a 320 wide screen when the Amiga hardware scrolls at the pixel level, it doesn't have enough DMA time to fetch the sprite data for all 8 sprites. Was this the reason the screen has a 16 pixel black area on both sides, to keep from losing the last sprite and then to even it up on the right?

Most likely. I must confess I don't remember those details :)

How did you come up with the idea for Robocod to stretch vertically a huge distance up the screen? Expanding Robocod would have been easy using a sprite for his middle section, but he seems to be always blitted! What was the reason for that?

It was just an idea that popped into my head one day when I was trying to think of some special power I could give to him! Up to that point, the best I'd come up with was a large Donkey Kong style mallet so I'm very glad to have had that flash of inspiration! I didn't use a sprite for this because the stretching section would have crossed over between the two bands of sprite re-use and besides this was an element of play that you only used occasionally and only when the action tended to be a bit slower anyhow.

Was the map editor a custom one you wrote for especially for the game? Did it have positions for the baddies in it or were they all done externally from the map?

Yes, the editor was built right into the game. It was a little crude (saving a level meant grabbing a chunk of memory using the debugger), but very good in terms of providing a very quick edit/play turnaround.

Maps were a simple tile grid, but were nicely unified in that all enemy placement and another special information was present in the same place.

One of the Hall of Light team members whilst ripping level maps from the game noticed that some tiles appear to be drawn upside down. Was that some kind of bitfield set on the tile? How did you store that information and were there any other special flags like that?

That's right, tiles could be flagged as inverted (to get extra value-for-memory). They could also be flagged as solid or not, damaging, bouncy, affecting character inertia or enemy-stopping (for invisible platform ends to stop enemies from walking off). These were all high-bit flags where the lower bits were the tile index.

How did you create the demonstration mode?

The principle here is very simple: there's a 'record' mode that allows you to record player input, then in demo mode you're replacing the 'live' player input with the data previously recorded. In Robocod's case we also had simple (run-length) compression on the input data to keep size down. In practice these demo modes are usually pretty horrible to get working reliably since they rely on the entire game-state being *completely* deterministic. The tiniest mis-placed 'bit' of difference, or out-by-one-frame in timing can mean an ill-positioned enemy or 'wrong-turn' by the player character and your slick-looking demo can look real stupid real quick! Having implemented this in a few games, I don't recall Robocod's being especially painful - we were lucky. I've known of shipped games that appeared to have a perfectly working demo mode only to end up being seen in shop windows screwing up majestically!

Was the development system upgraded by this time or were you still using Devpac and an Action Replay cartridge?

After JP1 we upgraded from our old 1040 STs to PCs - the first PC I ever used! We got set up with an early version of Snasm from SN Systems and the MS-DOS based 'Brief' text editor. By comparison with what we had been using before, it was *awesome* - finally proper debugging facilities!

Was the Amiga game still the lead version?

It was a little odd in that we started with Amiga as lead version - and the platform I was working on, then EA signed up for a Megadrive version but needed it to be ready about two months *before* the Amiga version was scheduled to complete. We hired in a new programmer (Simeon Pashley) who was tasked with getting the Megadrive framework up and running, and then porting across what I was doing on the Amiga. Because he needed to finish first, my focus was very much on writing the *game* and trying to defer the Amiga specifics until the back-end. Consequently most of the copper and parallax effects weren't worked on until the last two months at which point we knew we already had a decent game behind us. That's a pretty nice way to do things as it turns out.

This might be a stupid question for those living in the UK (if the answer is something to do with Penguin biscuits) but in the intro it has the following text:
Something fishy is afoot in the Arctic...
Alvin... Dr Maybe has captured the toys!
Murray... And he has kidnapped our friends.
...Only RoboCod can help us now...
He must rescue the penguins... And defeat Dr Maybe!

Who (or what) is the Alvin and Murray that are referred to?

I think that was the script (and names) that the Penguin people gave to us - I have a hazy recollection of Penguin TV ads where the penguins spoke and referred to each other by those names (or I might be dreaming).

At what stage of development was the Penguin biscuit sponsorship worked out and put into the game? If late, did it cause problems? (Presumably you had to add the intro featuring the biscuits - did you get to design the intro?)

Very late. That was a seriously unpopular demand when it first came through! (Although in hindsight I think it actually adds to the character of the game). The whole sequence was created by Simeon Pashley who was the programmer primarily responsible for the Megadrive conversion. He's a super professional coder, so it all went in very smoothly. I added the Penguin graphics to the chocolate-and-candy level set and tacked on the simple 'rescue the penguin' mechanic. I always like the wry addition that Simeon made to the game-over screen as a group of penguins drag Pond's body offscreen: 'smoked kipper for tea!'.

Nothing to do with RoboCod, but have you seen the clever use of sprites in Risky Woods?

Definitely a very clever technique! I think for Robocod though - had that approach even occurred to me - I might have still gone with the 5th bit-plane/copper-bars look because I was a big fan of the sheer eye-popping degree of colour it brought to the screen. I think that was one of Robocod's biggest hallmarks and why - for me - the Amiga version is actually far nicer to look at than the Megadrive version despite the fact that version had 'full colour' parallax. I like to think thematically and visually Robocod was the start of an Amiga trend (e.g. Trolls and especially Zool seemed to be take very direct inspiration!)