And without further ado, I announced that Project Claw v0.1 has been released and is now live on Google Play!
So, what is Project Claw? Well, here’s a description from Google Play
In Project Claw, you possess the ability to grapple to floating magic orbs and catapult yourself into the air. Fly high into the night sky by using these magical orbs, each with their own power and characteristic you have to master.
Have fun in this endless arcade game and try to fly as high as possible!
Project Claw is your usual endless arcade game where you need to fly as high as possible and try getting highscores. What’s different is the mechanism to get higher, in this game you have to touch these floating orbs to attach your character and release them to make him launches upward. You’re constantly moving up and down, so you need to have good reflexes to tap those orbs accurately. To prevent you from getting bored, there are several types of orb that you can use, each having their own special effect when used.
Here’s a video showing the detailed mechanism of the game:
Anyway, keen-eyed readers might have noticed that it’s Project Claw v0.1. Yep, it’s still version 0.1, in fact, it’s still pretty much a prototype, hence the version number. It really is something I put together over the week, most of the graphics is drawn over a single night, and the coding is one big mess with no architecture.
So, why did I release it? Funnily, it all begun when I was playing Mega Jump in the bathroom. I was frustrated with the inaccuracy of accelerometer-based control, and tried to think of how I would tackle the control for a similar game. A friend of mine tried to implement a left-and-right-side-touch scheme to control the character in his game, but while it’s accurate and simple, I felt that it’s not fun enough. Then an idea dawned on me: a control scheme based on grappling hook where the character moves upward by grabbing various objects using it.
I really liked the idea since it seems fun and it has a lot of possible additional mechanism to be incorporated. However, at that point, I had 2 other Android projects I was working on, and I didn’t like the idea of tackling more than 2 projects at a time, so I can’t really work on that idea. So I just write down the idea on a piece post-it note and stick it to the wall so I didn’t forget. Several moments later I had an idea that I should just create a prototype to test the concept and release it as it is. Since I can easily measure the market response, get a lot of feedbacks, and learn first-hand about releasing an application that way, I decided to go for it
The post-it notes grew along the project XD
So, a week later, after several iterations of testing and development, it was kinda done. I simply slapped a pause and gameover menu over the original gameplay and it was ready. I’m glad that this time the gameplay I imagined is truly fun, most of the testers easily get absorbed into playing the game and they didn’t really have a problem with retrying the game when they died.
Anyway, I originally planned to release the game by Monday, but it got delayed and I ended up releasing it on Wednesday (imagine, even a prototype can get delayed). One big reason for that delay is that I wanted to have a gameplay video so I could show it to people that doesn’t have an Android phone. Since my game wass too fast for emulator (yes, even for that new gpu-enabled emulator), I had to record a video of the game running on a real device. But controlling a fast-paced game in one hand and holding a phone for recording in another hand is really difficult, I ended up using some special equipments to stabilize the camera.
Behold my professional video recording equipment:
Yes, it’s a Galaxy Nexus on top of… some stuff
Anyway, since the game is now available, go download and play it!
Don’t forget to rate it on Google Play and hit the in-game feedback button =D
So, a little update on the competition: I lost, the game who wins has way better user experience than mine. I guess it’s to be expected, I didn’t plan anything upon developing this game, it’s really a spur of the moment thing. The good news is that I don’t have anymore time limit to improve the game, and I already have some idea on how to tweak it. That said, I guess I should start finishing up that postmortem!
Meanwhile, a little teaser:
Oh right, I did say I have something for you guys, well, may I present you…
The Kite Knight Wallpaper
The image was originally used for a promotional poster (which now I hung in my room), but when the artist showed me the final artwork, I realized that it could be used for a desktop wallpaper as well. In fact, I used it for my current desktop background, replacing my previous Diablo III wallpaper.
Obviously the wallpaper isn’t prepared for all resolution (like 1360 x 768 for example), so just take the closest ratio to your current resolution (for example, the 1920 x 1080 wallpaper would fit very nicely on a 1360 x 768 screen because they have similar ratio)
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 =)
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 XD 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 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.
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.
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.
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.
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.
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.
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 =)
Several days ago, I finally finished the development of Kite Knight, my latest game and also my entry for Nokia Asha Apps Challenge. As the competition name suggests, it is a game for Nokia device, but since it was a touch-based game, I planned to have an Android (and hopefully iOS) version of the game as well in the future.
In the middle of development, I felt like writing a blog post about how I turn a simple sketch into a real screenshot. However, I don’t have much time to write, so I decided to postpone it until I’m done and turn it into a full article chronicling the development of Kite Knight instead. For those wondering about the game, do check out the video I included at the end of this post =)
And without further ado, here we go with part 1! Note that this is my very first postmortem ever, so bear with me, okay? =)
Part 1: Inception
Birth
To be honest, I never intended to enter the competition in the first place, because I already have 2 other game projects going on (this will bite me in the ass later on). So, one night, I was discussing about the competition with a friend of mine who actually gonna participate in the competition, and I strongly disagreed with his game idea. Of course he didn’t listen to my rant, so I feel kinda bummed, thinking that I should just kick his ass in the competition instead. Problem is, I have no game idea!
Then I went into the bathroom and that’s when, out of nowhere, an idea hits me: controlling a kite with touch! Kites basically are controlled by dragging the kite around or releasing the thread so it went higher, and these can be translated to touch control. I don’t really know if it’s doable, but at least I’ve got something solid to build my game on now. I just need to register now.
Since the deadline is close, I don’t really have much time to think about the idea further, I just know that it’ll be about kite. But I would need a title to register the game, so I quickly looked up words that rhyme with Kite, and one of them is Knight, which seems very fitting for a game title. However, Kite and Knight doesn’t really mix, so I ended up registering both Kite Knight as well as Kite Might, since “Might” isn’t as limiting as “Knight”.
And thus, Kite Knight is born.
Brainstorm
Now that I have a vague idea of the core gameplay, I need to think about the bigger system, about how the game would feel. So I made some basic rules and limitations about the game:
The game should be endless and continuous.
Because a month (the competition duration) is definitely too short for balancing and designing levels.
The game should be simple yet addictive.
The game should prompt user to keep playing it, to have that “just one more time” moment.
Touch optimized
It’s a touch device, so I want it to be a pure touch experience, no friggin’ virtual button or gesture-based control.
I also need some reference, so I take a look at a game I’m recently addicted to, Temple Run, which as far as addictive go, it definitely has that “just one more time” characteristic.
Temple Run
With those in mind, my initial idea is:
A game where the player will control the kite to fly as high as possible. The player would need to manage when to control the kite and when to just follow the wind. To add difficulty, the player would also need to wiggle the kite when the wind power is weak. Other than highscore, there should be achievements so player has more stuff to do in the game. There will also be upgrades that can be purchased with money gained from playing the game so the player will keep trying to be better.
Note that despite my (kinda) lengthy explanation, the whole process takes very, very little time. It’s one of those traits of working alone.
Prototype
A bigger problem remains though, is the gameplay actually fun? It is fun when I imagined it, but that doesn’t mean it will be fun when I use it for real (and this is why I don’t believe in game design document). Well, lately I’ve been in love with prototyping to test out a gameplay idea ( and so far it has worked really well in determining whether a certain gameplay is fun or no), so why not test out my gameplay idea in a prototype as well?
My original plan is to use some tools to quickly create a working prototype. So I asked around and my friend recommends Contruct 2 or Stencyl for quick prototyping, and I choose Construct 2. I tried it for a while, but damn, I felt so constrained when using it. It feels like I have to go through a lot of steps just to implement a basic idea, so I ditched it and used my Android game framework instead.
First attempt
Surprisingly, prototyping with my framework (which serves as a wrapper for OpenGL ES functions) works quite well, in just one night I managed to create a simple prototype that includes the core gameplay. And ta-da! It wasn’t as fun as I thought it would be =(
The gameplay is definitely solid and simple enough, but just aiming for highscore is kinda boring. It’s like a Zelda game that takes place in an endless open field with no dungeon or town. So I decided to add more gameplay elements that would make the player have more stuff to do. I decided to add an energy bar that depletes over time so the player needs to collect some pickups to replenish the energy. I also add some powerups that would give the kite an upward boost when collected.
Prototype 2.0
Now the gameplay feels a lot better. With depleting energy and pickups scattered all over the place, the player now has a short term goal of collecting them to stay alive beside trying to break the highscore. And there’s definitely some sort of thrill when you manage to collect the powerup. I was actually surprised by how much difference those simple game elements could bring.
To top it off, having pickups also works great for creating storyline. At that point, I didn’t have any real background story about the game, but I could imagine a storyline where the pickups are accidentally spread all over the sky and now the player must collect all of them.
I’m not really satisfied at this point, so I try to add more stuff like dynamic thread and kite that moves a bit before scrolling the background to make the experience more fun. It didn’t work out though, I can’t implement it correctly and it’s just confusing, so I decided to remove that feature and go with the previous version instead.
Testing
Anyway, I built the whole prototype over the weekend, so when I got to attend class on monday, the prototype is already done. Another advantage of having a prototype is that you can quickly show it to other people (be it investor or family or friend) and observe their reaction to the idea behind your product. And that’s exactly what I do next.
Now I’m more confident with my gameplay idea, I decided to show the prototype to several people to know what they think about it. Well, they don’t comment much on the control (which is good, since it means the control works as they expected), but they often stumble on the fact that you need to wiggle the kite when the wind dies down. I kinda understand the problem, since that sudden change disrupts the flow of the game. At that point I just took note that I need to do something about this particular element, since I don’t have time to work on the prototype anymore.
And that’s it for part 1!
Stay tuned for part 2 where I start turning water into wine (if water means sketch and wine means mockup) =D
Video Time! Here’s a gameplay video for those wondering what is Kite Knight =)
You see, my latest two ideas came when I’m in the bathroom. The first one came to me when I’m not sure if I should enter a certain competition or not, since I don’t really have any idea of what should I make.Several hours before the registration deadline, I randomly decided to take a pee, and that’s when an idea hit me: controlling a kite using touch interface! So I decided to use it as my entry for the competition.
To be honest though, that idea still needs a lot of tweak, even now I’m not sure the gameplay is really fun XD
The second idea came to me just this morning. For a long time I haven’t got the slightest idea about how to adapt one of my games (Komodo Park) to touch interface, but just in a couple of minutes under the shower, I got an idea for a suitable gameplay. But seriously, it’s so random! I didn’t think about anything related to games before I took the shower, yet I suddenly stumbled into that idea.
So if bathroom is so effective in drawing out good ideas, should we start doing brainstorming in the bathroom? No, I don’t think so. Once we start having brainstorming sessions in the bathroom, it would become just like any other meeting rooms. I think it’s more about the activity rather than the purpose of the room. So thinking while taking a bath in the bathroom or in the meeting room have no difference whatsoever.
So, why? Why does the bathroom let us have good ideas? The first thing that I can think of is the state of our mind inside the bathroom. We’re relaxed when we go into the bathroom (so a public, crowded toilet won’t do). We all know that being relaxed helps up think clearly, that’s why it’s easier to have ideas under that condition.
The other thing would be freshness. Usually going into the bathroom lets us take a break and stop thinking about our current predicament. It’s like most of our problems are being stored outside and our minds are getting reset. With our mind reset, it’s easier to look at problems from different perspectives, resulting in brand new way of thinking that leads to a new solution.
One last factor that comes to my mind is that we don’t truly think inside the bathroom. It may sounds contradictory to my original argument, but it is true. We don’t really think when we’re in the bathroom, rather, we just let our minds wander off on their own. And much like the freshness point I mentioned before, letting our minds wander also means letting them tackle problems from different directions, leading to some new ideas that we never think of before.
I think its easy for our minds to wander off in the bathroom because most of the stuff we do there is already automated, leaving our minds idle. The privacy of bathrooms also helps, since now we don’t have anything to pay attention to.
So it all came down to being relaxed, being fresh, and having nothing immediate to think about. Could we recreate them outside the bathroom? It’s hard, but I think walking around with no destination is a close one, though it’s kinda dangerous if you don’t pay attention to your surrounding when you’re walking.
Ironically, most meeting rooms don’t encourage those three components XD
