Kite Knight Development Tale Part 2: Drafts

Story 2

This is the second part of my three-part series chronicling the development of my latest game, Kite Knight.

And as usual, you can check out the video at the end of this post if you want to see Kite Knight in action.


Let’s get started with this second part!
BTW, have I mention that any feedback is highly appreciated?
Do tell me what do you want to hear more =)

Kite Knight Title

Part 2: Drafts

Partner
Even though we have gone past the first part, at this point, there’s still no certainty if I will actually make the game at all. I will not do this half-heartedly, I’m either doing this and make a decent game, or not at all. Like I said before, I have other game projects, so I definitely will not be able to do this alone if I’m gonna make it in time. I need an artist.

I already have an idea of who I will ask to be the artist of this game, so basically, the fate of this project lies in whether he will help me out or no 😄 So yeah, I reached out to him and asked if he has the time to be the artist of my game. I also requested a meetup so I could tell him more.

He agreed to meet up,  so the next day I showed him the prototype (yet another advantage of having a prototype) so he would get an idea of what the game is about and how much stuff he would be working on. Fortunately, after I convinced him that there won’t be too much asset to work on, he agreed to help me out =D

It seems like my timing can’t be better, as I heard him rejecting a project on the very next day because he already has too much stuff to work on.

So we discussed what to work on right away and I told him to make the gameplay assets like the one he’s seen on the prototype such as the sky and the kite. And that night, we shared dropbox folder and started working on the game right away =D Below is the the first few assets he made.

First assets

First few assets of Kite Knight

One very interesting thing in having an artist to draw the asset (instead of yourself) is that you could see a totally different style than what you’re used to. If I am to draw the sky, I definitely won’t produce something like the sky image above, so it’s a really pleasant surprise.

And I still remember those magical last few hours where he pumped out the story images hourly. It was really awesome to see your ideas becoming reality in real-time. Especially when they become beautiful images.

Design
As of now, we only have the design of the core gameplay, we still don’t know how the game would flow or even how many screens the game would have. So I quickly sketched out a state diagram to flesh out the basic screen navigation.

State diagram

The state diagram

The diagram works quite well to show what big features the game will have. Besides, it also gives the team a unified vision of how the game would be. That way, all team members would know how far the game is from being completed.

Anyway, the competition requires us to submit a mockup of the game by February 14th to confirm our participation.

At that point, we already have some gameplay assets ready, like the sky, the clouds and the kite. But we’re still lacking the user interface, like the energy bar or the pause button. So I started sketching some layouts, that way the artist can draw the real interface right away.

Mockup 1

An interface layout

And I ended up with 2 kinda different layouts. While doing the first one, I got an idea of an alternative layout that may look better, so I sketched another one afterward. The artist agreed with me that the second layout looks better since the interface doesn’t take as much space as much as the first one.

There’s one thing I noticed from playing the prototype. When playing the game, most interface at the bottom of the screen will be obscured by the player’s hand. So the second interface is indeed better since it put all the important informations at the top of the screen.

Mockup 2

And another layout

It is really fun to see these sketches turn into a real screenshot of the game.

The artist produced three variants of the interface and I submitted the first one (the one with the bar on top) as our mockup. We ultimately ended up with a combination of these. We used the shape of the third interface as well as the color and the arrow of the first one.

Irony
Anyway, it’s funny how things unfold some times. In the first part I’ve said that I entered the competition to show a friend of mine that his idea sucks (I’m writing this beside him by the way XD). Apparently, he decided to drop out of the competition and develop his game straight for iOS instead.

A pretty ironic turn of event, huh? With no target anymore, I could have dropped out as well, but like I said before, I don’t want to do things half-heartedly. And so I decided to stick with this game.

Tradeoff
After submitting the mockup, I finally got a device for testing, so let’s get a bit technical =)

Nokia S40 devices are troublesome. While the devices themselves are quite capable of handling heavy graphics, a lot of them still don’t have 3G connection, which means downloading big-sized games is very difficult. I remember failing a lot when I tried to download my 500KB game to my Nokia C3 =/

Based on that experience, I know having as little file size as possible is a really important point for an S40 application. Thus, at one point during development, I need to make that very tradeoff between file size and quality.

You see, image with transparency (which used a lot in games) can only be created as PNG image. There are 2 kinds of PNG format though. One is the lossless PNG where each pixel is saved as an ARGB value. Saving as this type of PNG usually results in file with a big size, but it can handle semi-transparency so curves will look smooth.

The other type is indexed PNG where each pixel would have a specific predefined color. In this type, several colors (up to 256) is defined in the image and each pixel would refer to one of this color. This type doesn’t provide semi-transparency, even though image with this format can be saved with very little file size. However, with no semi-transparency, most edges will look very jagggy, especially curved ones.

Indexed VS Lossless

Lossless vs Indexed, 10KB vs 3KB

So, which should I use for the game?

Both. I decided that static objects that will get the most attention will use that lossless PNG format while the rest will use indexed format.

For example, I used the best quality images for that bar on the left corner, the kite, as well as the pause button. You may notice that all other circular buttons are pixelated, since users won’t see them as much as the pause button. And even though users will see the stars a lot, the stars are moving and kinda small, so it’s okay to use indexed PNG for them.

Game comparison

In-game comparison, lossless (left) vs indexed (right)

One thing I regretted is that I used indexed PNG for the clouds. They look okay on bright background, but once you went higher and the sky gets darker, the jaggy-ness of the clouds will be very visible since it clashes with the background.

Development
Finally the development side of things. Let’s see where’s our standing right now.

It’s February 15th, I just submitted the mockup and all I’ve actually done is mostly state navigation and some basic class like Image and Sprite class (I created a wrapper to J2ME Image class so it behaves just like the Image class on my Android framework). The deadline is March 1st. So basically I’ve got around 2 weeks to do everything.

While we’re at it, let’s delve a bit into how I work on stuff. I like to work on stuff by fixing it. It sounds weird, so let met elaborate on it.

I usually start by creating a very basic version of the whole application, that way I can immediately start scanning which area I need to fix. Once I found it, I’ll work on that area until the experience feels right. It’s a really quick cycle of testing and coding, ensuring quality while having the project ready to ship any time.

So, for games I always start with getting most of the state navigation done, even if that means some states would only have an empty screen.

I really like this approach, because even that early in development I can show the game to users and they would understand, “oh, this is where I will play”, “oh, this is pausing the game”, etc. It makes the whole project feels “ready to ship”. And we all know that shipping is really, really important.

Using that approach and a lot of copy-paste from my previous project, in a day or two I managed to get the splash, title, and credit screen ready. I didn’t have any interface asset ready back then, so I resorted to my trusty programmer art.

Programmer art

My trusty programmer art

With those screens out of my mind, I turned my focus into the actual gameplay. You know, the meat of the game. I started working on the background, namely the sky and the cloud, to get the scrolling feels right. The wind comes next, but it is simple enough that I can just copy the code from my prototype. Then I moved on to the Kite, implementing stuff like energy bar and altitude, then I finally worked on the pickups.

At one point, the artist asked if I want the kite to be animated. Well, an animated kite would draw the attention of the player, so it’s a good thing. Not to mention that animated kite would make players quickly recognize that the kite is the object they’re controlling, so of course I decided to go for it.

After implementing it, I realized that it would be cool to have the kite animation speed vary depending on the wind power. After all, as the wind got more powerful, the kite should get a lot shakier as well. Too bad in the end we don’t really have any time to implement it =/

By weekend, February 19th (so, around 5 days after I submitted the mockup), I’ve got the basic gameplay going. I haven’t put any control, so the kite would just fly upward, but the whole scrolling background and pickups is already working. Like I said, I like to keep stuff “ready to ship”, so I did show the game to several friends. I couldn’t get much feedback at that point though, after all, the player can’t control the kite yet.

So, 10 days left and we already got the basic gameplay done? Sounds great, right? Unfortunately, I suddenly got news that the publisher for my other project wants to take a look at our progress (of that other project) and requested a meetup on Wednesday (February 22nd).

So I decided to postpone Kite Knight until Wednesday and started working on the other project. Besides, I would have all the time to work on Kite Knight after that day. Or so I thought…


We finally reached the end of part 2!
Watch out for the final part where all hell is unleashed =0


Video Time!
Here’s a gameplay video for those wondering what is Kite Knight =)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s