Code Evolution

In the last post, Dan talked about the evolution of the concept and art of the game. He left the technical details to me, the evolution of the code of the game, from the prototype to the current build. How we’ve had to change the editor over and over again as we decided which technique was better to build the stages of the game.

First, the game was a little pixelart platformer, maybe something like the Orton and The Princess game by my friend Chman, but with different graphics and the special secret mechanics of Kodama.

The prototype was built using FlashPunk (as some clever readers may have noticed because of the flashPunk debug overlay), and it consisted of a simple tile-based platformer game, with the water you can see there. The water was a bit special, though, I made it dynamic with a celular-automata technique, but we decided to scrap this feature later.

The editor of this version was accessible by the simple press of the key. In the editor, you could place the tiles and objects like the player with the mouse, and press the key again to test the level instantly.

We had a talk later on about the graphics route of the game. At this point, Kodama was just a prototype name we gave to the game, so we could refer to it internally, but this same name was what made us decide to go with a japanese style on the game. We also decided to have the hand-crafted, high-res graphics to make gorgeous stages.

This was what Dan made, with a pixelarty style:

But Dan was not happy with his work. We decided we wanted something more. So he hired Chris…

So the next route we took, was that the artist would draw ALL the stage in a graphics edition program (he used photoshop). He drew some test stages we liked really much. For the collisions, I built a pixelmask system combined with the platformer, so Kodama could go up and down the slopes.

The editor was completely redone. Now, it asked for the images and pixelmask of the level. Then, you could also place water and other objects on the editor directly, in a tile-based fashion. We also placed a grid-system (with automatic pixelmask detection so we hadn’t to place EVERY solid place) for special systems of the game, like rays with mirror reflections.

But then, we decided that wasn’t what we wanted. This made completely impossible to tweak the level, as Chris would have had to redraw the whole stage. It was also hard to prototype levels and design new ideas. We had to draw the levels on paper and then give them to the artist so he could draw them. Then we had to import them to the game, build the level, and see if we liked. If we didn’t, we had to ask the artist for a complete redraw. What a waste of time. Moreover, it would have encouraged the laziness of not tweaking little bits to make the stage perfect, as a lot of work was required to move a platform 20 pixels.

So, after a bit of deliberation, we took another route. Have you seen Braid or Aquaria editor? How they work is, the person who’s designing the levels has got a huge collection of different stamps (little images), which can be placed, scaled, rotated and tinted. Thus, allowing to create gorgeous looking levels with a lot of possible layouts. We decided to go on the same route.

I spent a few days to get an editor ready which would allow us exactly that. It has layer management, stamps, objects, polygons for the collisions (more on that later), particles, can test the game with the click of a button, etc. Now it’s really cool and fun to design a level.

I also redid completely the engine of the game. I scrapped FlashPunk and got ND2D, which is a 2D engine which uses the new GPU features from FlashPlayer 11. I also incorpored Nape for the physics of the game, so the game featured real physics now, which allows us a lot more freedom on designing the puzzles of the stages. For the collision masks of the level, we use polygons now, that’s why the editor needed them.

We also got a level designer on our team, Javier, who’s doing all the stages. He plans the stages with some pictures, builds them with the editor… then we see if they work fine. After that, he works hand in hand with the artist so there’s special stamps crafted for that level to look even more pretty. Then it’s time for particles, eye-candy, etc. and the level is done. After that, we play the level over and over and over and over to make sure everything’s perfect, tweaking every little bit of it.

So that’s the whole evolution of Kodama code. I hope you liked it :D

Kodama – The SeeD that grew

Hey Guys

I’ve been meaning to write this post for a while, a little post on quite how Kodama got started.

The idea

For many years my girlfriend and I have owned a bamboo plant, she would often return to Poland for weeks at a time and leave me to look after this plant, and, well, me being me, I would constantly forget we ever owned such a plant, it seemed to be able to survive with no sun, and the same water for months at a time, in my opinion its probably invincible. This was the original seed for a game, a game where you would play as a plant, a plant in a plant put would of course be rather boring, so I instead went the anthropomorphized plant approach.

The idea was written down into my iPhone at around 1am whilst in bed, with Kodama originally being called OGMO (after Matt Thornsons editor), the next morning I sent the idea over to Abel Toy (whom I was already working on a much smaller and less ambitious title with) and he loved it, we discussed the idea in depth and it grew, soon becoming Kodama (after the Japanese tree spirit).

Early tests

Here’s some screens from the Kodama early tests, we began using ChevyRays Flashpunk to prototype the idea, adding nice features like fluids and testing them out, heres a few screenshots from the very early days (WIP)

And a simple test of the fluid system Abel implimented


From here the idea started to grow quite rapidly, we removed several features that were nothing more then ‘fancy’ and ‘pretty’ wanting to keep the game down to the bare basics of the system and making sure this was enjoyable before adding to it.

A lot went on from here, I bought onboard a close friend and fantastic artist Chris .H and he began to paint things up, we’d already reached a good point and were confident in the idea, Chris’ art gave us even more ideas about the games visual style, the atmosphere and more, we started a little weak, not using the best methods of stage creation, causing poor Chris a few headaches when I or Abel requested changes, but we soon got on the right track thanks once again to the lovely folks at the Flashpunk Forums and began to use a fancy sticker system as you can see below. Abel will be posting something much more indepth about the editor process, so I won’t dive any deeper into this.

This made rapid prototyping dramatically easier, still not as easy on Chris as the graphics still take a while to paint up. but this speeds up the process and the memory footprint quite considerably, and enables us to make things like below within a few minutes as opposed to a few hours.

I know I know, there’s nothing new there, but it shows what the tile/stamp system is capable of.

I’m going to leave this post with a final image many people have been asking about, what does my most recent edit of Kodama himself look like?

The head is hollow, the mouth is gone, It’s becoming more creepy and typical of a Yokai creature, further edits will come, I’m not 100% sure where I want to take this, but I want to remove this slight ‘Pokemon/kawaii’ feel to it and create something that looks like nothing else before it. I’m pleased that its a far step from the Miyazaki Kodama in Princess Mononoke though, Daryl, the concept artist did a fantastic job here. He isn’t in the Team Page unfortunately, due to him having little free time, but in every Kodama image, there’s always something of his. Just as a small, final and yet rather unrelated note, I hope someone gets my reference in the way I’ve capitalized letters in the post name.

Clarifications about the game platform

Hello,

As the programmer, I would like to clarify a few things about the platform Kodama will run on, as well as some technical details for the interested.

First of all, we’re prototyping the whole game in an AS3 engine. It uses GPU accelerated graphics thanks to the new Stage3D API from FlashPlayer 11, so the game can handle the enormous stages and sprites it needs.

The problem is, we are not sure if flash will be able to handle the game AND all the fancy effects, eye-candy and all those things which make the game more pretty, but consume a lot of computer power. Therefore, if we see the game is too slow on normal computers, we will switch to another platform.

Let’s talk about what systems will the game run on now. We are firstly aiming for a computer release. PC + Mac + Linux is the ideal plan. Hopefully we can get to the three. Flash would allow us to do exactly that, but as I explained before, we’re not sure if flash is going to be enough. If it isn’t, we may use XNA or something else. XNA doesn’t allow mac nor linux, so we would have to investigate on ways to port it. Maybe we’ll even hire someone else to do it if I don’t feel capable.

EDIT: We’ve been informed by someone that we can also use HAXE and export to C++/OpenGL, so we could have multiplatform with that. Worth a look :D

So basically, we’re aiming for PC + Max + Linux, and the game is currently being prototyped in flash. If flash can handle the final version, great. If it can’t, we will port it, which is easier for me than coding it directly on a foreign platform, and we’ll try our best to make it available to the three platforms.

We will also try to do a possible web demo for marketing purposes, more or less like VVVVVV did, but we are not sure about that. Depends on the necessity. But that will definitely be in flash, so that we’re prototyping the game in flash will greatly help on that.

On top of that, as Dan said on the previous post, we will look into an iOs release (probably iPad only, as the game might be bad if it’s too small), and maybe also an Android tablet release but the first one is much more probable. We’re not sure if this will be on the release day or not, but hopefully some chinese hackers don’t steal our game for iOs if we do it later! :P

To sum up:

  • Game will be available for PC, Mac and Linux.
  • Currently being developed and prototyped in Flash. We will port if Flash isn’t powerful enough.
  • We MAY do a web demo for marketing purposes.
  • We MAY port the game to iOs (probably only iPad) – we could even port to Android tablets but that’s unlikely.

Hopefully this helped on clarificating the game platform.