Feature: The Development Process of Go! Go! Kokopolo

NL: Where does the name "Kokopolo" come from, and why the subtitle of "Harmonious Forest Revenge"?

KW: I can't actually remember where the name Kokopolo came from, but it is very possible it was inspired by the name Kokopelli, which is a mythological native American deity... but I originally came up with the name years ago, so I can't be sure. Around the time that I was thinking about the original concept – sometime around '96 or '97 – there was a Sega Saturn game called In The Hunt, which was published by a team called Kokopelli Studios, and I probably saw it in a Sega Saturn magazine, so it's possible I liked the sound of that and tweaked it. In fact, I think that makes sense... and I later made the connection. I also liked that the name fits in with the "Go! Go!" sound to add a sense of rhythm to the title.

"Harmonious Forest Revenge" was just purely made up from nothing. I wanted a subtitle that sounded like it might have been mistranslated from Japanese, and fitted the wacky premise. It's basically laying out the foundation of the (very simple) plot, in that all is peaceful until the concept of revenge is introduced... but to be honest, I just thought it sounded nice.

NL: One thing that we find especially draws us to the game is the character design. A lot of work clearly went into this aspect – scrolling through the website reminds us of those old-style instruction manuals wherein each enemy had its own backstory. Can you elaborate on how you went about it and what you were going for?

KW: I really like the Mario style of enemies, in that they are all cute and cheerful characters, and very simple in their design. In fact, I recall when I was a kid, around the time of the SNES era, I got a Super Mario World birthday cake for my birthday one year. I didn't have a SNES at that time, so I didn't know much about Mario, but on the back of this cake box, they had images and artwork of all the enemies in the game. I was fascinated by this, and that style kinda stuck with me from that, similar to how they were all represented in the manuals.

As I mentioned before, because one of the original springboards for the game design came from the fact that the enemies needed to be eaten, they were originally based on fruits and vegetables. Some of the later enemies encountered don't follow this pattern, as it was a little too tricky to fit it in with what the specific attack pattern of that enemy was going to be.

One of them is actually based on an old Japanese ghost-type legend, I believe, called a Kasa-obake, which is an umbrella that comes to life after 100 years. I remember seeing loads of old games – Pocky and Rocky, Mario Land 2 – which featured these creatures, and was always confused where the inspiration came from. Once I found out, I decided to put one in my games, so there is an enemy like that in the game that snatches you and drags you through spikes. He is, however, also based on a flying squirrel-thing too.

NL: Can you tell us a bit about turning those designs into sprites and animating them? There's definitely something appealing about watching a carrot become infuriated.

KW: Whilst I was creating the sprites, I really wished that the game was just a simple 2D sidescroller! The reason why I say that is that I realised I needed to do three versions of animations for each character due to the different angles of front, back and side. All the attack patterns needed to be done in this way too, and it took ages! If it was a sidescroller, then I'd only need to do one angle and flip it! But I persevered and got them all done in the end!

The other thing is, when I am drawing characters in the concept stage, I tend to put black outlines around everything to keep it looking neat. With a lot of old sprites, because of the restrictions of space, pixel artists tend not to draw these lines, and simply use a really clever use of colour to make it appear that they have outlines when in fact they don't. I'm probably not good enough at sprite art yet to do that, so I had to include the outlines to get all the expressions and animations across, but this meant that valuable pixel space was being used. Thankfully, because the sprites were a little bigger than most games, this was possible to do without too many problems.

My eyes were certainly relieved when all the sprites were done though, as it is quite painstaking looking at a screen so close for hours on end!

NL: What was your reasoning for including the scratch card collectibles?

KW: The original idea was simply to have character and enemy bios unlockable in the game... these were originally just going to be simple character cards. But then inspiration struck, and it made sense to have them as “Scratch Cards” in keeping with both the theme of the game – scratching – and the touch screen aspect of the DSi / 3DS lower screen. It was one of those things that came together really well, as it utilised an aspect of the hardware, and made sense for the game in general, so they stuck.

Obviously one of the other reasons was to add a slight exploration edge to the game as well, but most scratch cards are out in the open, so not too difficult to locate…however, three of them in general will confuse some players on how to reach them... but let’s say, when you work it out, you’ll be either lol-ing or kicking yourself.

NL: We understand that you had a unique set-up with Room 4 Games, rarely meeting face-to-face and mostly working remotely. What was that like?

KW: Right, well here's the thing... there were two programmers at Room 4 Games who worked on the game. One engine programmer, Szilard Peteri, and one gameplay programmer, Gergo Kiss. Both were based in Hungary, and I was based in the UK.

I've only met Szilard, once, for a total of half an hour, about a year before we started the project, as he was based in the UK at the time. I showed him my original design for Kokopolo, and we talked over the possibility of developing it together, but the timing wasn't quite right at that time. About a year later, when I had some free time, I dropped him an e-mail. He had just set up a small company back in Hungary, and had approval from Nintendo to be a DSiWare developer, so after a few emails and contracts back and forth, we began the process, and the rest is history! But in total, I have only met him for half an hour max!

"In short, it is crazy, pure arcade mayhem, wrapped up with beautiful pixel artwork and fantastic stylised graphics!"

However, the main gameplay programmer, who did a vast majority of the coding work on a day to day basis was Gergo, and he and I have never actually met! We were working extremely close together on the project, but basically only communicating through emails, and bug lists... and managed to collaborate together somehow and get the whole thing done! I know Super Meat Boy was done by a team of two also, but I think those two guys at least have met once... the two main people who worked on Kokopolo have never actually met, or spoken to each other outside of emails! Pretty weird, huh?

But it worked great, and I think that is partly to do with the fact that the design was so well pinned down and documented before we began, but I think also because we both had an intuitive idea for how games work at a gameplay level, and so a lot of things that would usually be issues simply didn't come up... as we both understood what the game should be.

NL: What was the play-testing process like?

KW: It was fun! Aside from the tweaking of certain stages, and placement of enemies which I'd mentioned before, it was basically a case of making sure it was fun. I have probably played through the game more than I have any other, and strangely enough, I still find it fresh. I had worked on games before, where you get sick of play-testing as it becomes very monotonous... but I didn't get that with Kokopolo.

I think, possibly because I've played it so much, I probably know all the stages and layouts in my head, and could play it in my sleep. or with my eyes closed... but from what I've heard, that might be too much of a challenge, even for me!

NL: Kokopolo certainly is a challenging game. Can you elaborate on tweaking the difficulty?

KW: We experimented with the two different dash speeds to try and get the perfect balance, and in the end decided that both a slower and a faster one worked to give different players a different experience.

There is an Easy Mode included in the game, which has a kinder, gentler pace to it, to allow players to get a hang of the basics and explore the stages at a slower pace. But after a while, that all gets a little slow, so you’d really want to try out the Normal Mode for the more frantic, heart-pounding action!

The way the game is laid out also means the player is directed to explore all the areas of stages, as opposed to Sonic style games where you just run straight through, before working out the best strategy to complete each level. Thankfully we made sure the save system automatically saves your progress after each stage, so you are never penalised too much if you lose a life.

If players want to excel at the time attack mode, they can get to know stage layouts intimately, and they are laid out so perfect route is possible for each level. I got used to all the stages, as I was playtesting the levels a lot, and when you know the layouts off by heart, you can chain together some epic chases, and that leads to really different style of play when attempting to perfect a stage, and it’s really rewarding when you see a completed time attack screen with all levels cleared!

It wasn’t actually my aim to push players to the limits, but it was more designed to allow players to take their time with the game, and savour every moment, as opposed to simply rushing through. On hindsight though, after the comments about the level of challenge, it was a good job we didn’t include an Expert Mode in the game, haha… or did we? (He winks.)