[1GAM-Apr] Black Holes iOS Log

May be I should have gone with “Black Holes iLog” instead?
Black HolesWelcome to the progress log for my OneGameAMonth entry for April! As usual, it’s late, but at least it’s only late by 7 days.

You may have noticed that there’s no numbering in the post title, unlike the previous logs where I numbered my post with Log #1, Log #2, and so on. Don’t worry, that just means this log is going to cover everything I did in April, so there’s no need for a second or third log.

Wait, a single post for an entire month of work? How could that be?

Well, my entry for April is a bit unusual, you see. Instead of working on a brand new game, I simply ported one of my Android game, Black Holes, to the iOS platform. But that doesn’t mean I have it easy. In fact, I think this April entry is the one that requires the most work so far (not the most difficult work, mind you).

And since I’m just porting stuff, there isn’t a lot of design process happened. I don’t really like writing a lengthy, technical stuff either, so there isn’t really much I could write in the progress log. And with that in mind, I decided that a single log would be enough to cover the entire month.

To be honest, I’ve always wanted to have a game for Apple devices. Not because people said that’s where the money is, but because I want to know more about the iOS market, about the behavior of iOS users, about stuff that would affect my download count. And what would be a better way to learn about it other than to actually release a game on the App Store?

And since I did Black Holes purely using Android SDK, it is only fitting (or stupid?) to do Black Holes for iOS purely using iOS SDK and Objective-C as well.

Title screen on iPhone

So, how did the porting go?

Basically, I worked on it using a bottom-up approach. I started with porting a lot of the game base components, like images, file loading, and touches detection before moving to the more abstract stuff like game loop and resource management. Not surprisingly, the abstract stuff can be ported quite easily while the low-end stuff requires a bit more work (AKA googling).

Fortunately, despite the differences in both platform, I didn’t encounter anything too difficult. Two things surprise me though, one is the fact that iOS doesn’t seem to have a definite place to store game save data (whereas Android has SharedPreference). Another one is the fact that iOS has a really complete suite of audio processing. I mean, it has like 6 different classes just for handling audio.

Oh, and another thing that surprises me is the fact that file management on an Xcode project is a total nightmare. I keep having to create and recreate the project since moving stuff around often leads to things breaking down.

With all said and done, I finally managed to port the game and have it running on my iPod. I was fortunate since Black Holes is on the simple side and doesn’t utilize all the components my game framework has. Yeah, you guessed it, there are actually still tons of stuff not ported yet to iOS, most notably accelerometer input and scrollable item list.

Another major omission from the game’s (and framework’s) current state is the support for iPad. My game framework has been doing pretty well in handling multiple resolutions, but having two base resolutions is a whole different beast. And I’m not prepared for that.

Yet iOS developers have been dealing with that problem for years now. So yeah, I still need to research how other people are doing it before actually adding iPad support. Not to mention that I would need an actual iPad to test it, since the iPad simulator on Mac doesn’t seem to work for me.

Black Holes on iPhone

While I did say that the game has been successfully ported, it has not been released on the App Store yet.

As this post is written, I’m still struggling to finish up some administration stuff since I want to sell the game. I suppose I can just publish the game for free, but I kinda want to see how a paid game would fare and how the market would react when the game becomes free. After all, I did this for the sake of learning more about the market.

All in all, I’m quite satisfied with how the port turns out. Haven’t test it thoroughly yet, but so far I haven’t see any lag or memory leaks. That said, there are some rough edges since the size isn’t exactly optimized for iPhone’s resolution. But eh, I can live with that.

Oh, and speaking of which, my game and the framework it used is totally open sourced on GitHub (except for the music, that is). The plan is to have Black Holes as an example of how the framework can be used since its quite complex but still pretty simple. And since the game is also available on Android, it would easily shows how the framework can be used for multiple platforms. So yeah, feel free to check it out.

Phew, and with this, I’ve paid off all my progress log writing debt. We’re going back to our regular schedule, people!

So, what’s coming up this May? Well, you’ll have to see for yourself in the May progress log, which hopefully doesn’t take too long to be posted. Suffice to say, it would be totally different from my previous OneGameAMonth entries. This time we’re going to focus our effort on a rather unusual aspect of a game.

Wait, did I just say “we”? Indeed, for my May entry I’ll be teaming up with a friend to help me finish this massive undertaking. And when I asked for help from other people, you know it’s going to be something exciting or something big, or may be even both!

Advertisements

[1GAM-Mar] Grid Chaser: Progress Log #3

Who would’ve guessed that just talking about some screens could get this long XD
One Game A Month
Before we go further, let me just tell you that Project Chaser (or Grid Chaser as the correct title) has finally been released on Google Play! Give it a try from here, and if you don’t have any Android device, feel free to check out the gameplay video here.

Wait, what is Project Chaser? Project Chaser is an Android game where you move around in a maze using swipe control while trying to chase down an enemy. Project Chaser is also my March entry for #OneGameAMonth, and you can read the first progress log here and the second log here. So what have I been doing with project Chaser so far?

Well, it’s the last week of March and all I’ve been working on so far is the gameplay mechanics (after all, that’s where most of the fun is). Problem is, there’s also a lot of stuff on a game other than the gameplay, like the title screen or the pause menu. So I fired up Photoshop and started exploring how those screens would look like.

Pause screen

Since pause menu is the simplest one, I started working on that one first. All a pause menu needs is a text telling that it’s paused and a button for resuming the game. This time I tried to do things a little bit different by having the player tapping anywhere on the screen to resume the game. After all, I feel that its implementation in Super Hexagon result screen is really nice and make navigating the game feels faster, so I wanna see how it does here.

I also added an extra button to return to the title screen in case the player doesn’t want to play anymore. The original look I’m going for is a simple flat button, however most part of the game has been pretty flat, so how should I make the button stands out more? Well, my answer to that is by actually making the button literally stand out, so I added a simple pseudo-3D effect on the button in hope that the player would realized that this particular rectangle can be pushed down.

I really like how the pseudo-3D effect looks that I decided to also makes the pause text has the same effect (previously its just a flat, simple text). I like this new look so much that I ended up changing the entire art direction of the game from a simple flat, retro look to a pseudo-3D one XD

Check out the title screen below for more pseudo-3D madness.
Title screenIt only shows static image here, but the little rectangles on the background is actually moving from the center to the edge of the screen. The idea is to have some sort of speeding-up-in-a-tunnel look without having to actually do it in a 3D scene. To be honest, I should have used a better speed calculation so it looks more realistic, but eh, it’s good enough this way.

This time I decided to also have the level selection menu right on the title screen to make things simple. To tell you the truth, originally I wanted to have the level selections slides horizontally when changed, unfortunately due to the limited amount of time that I had, I had to cut it from the feature list.

One of the reasons I didn’t have enough time is because I spent so much time working on the “Grid Chaser” title text. I tried to make the text a little bit more fancy by adding a more complicated 3D look which surprisingly took a lot of time to get right. I also iterated over several versions of the text since I just can’t seem to get the look that I want.

Here’s one of those alternate versions of the title text that didn’t make it to the game:
Alternate title textWhile this text looks okay on a plain black background, it doesn’t look really good on the actual title screen so I ended up scrapping it =/

So with the pause and title menu done, what’s coming next? Well, the tutorial is one thing I really need to do since it’s crucial to make players understand what the game is about. Other than tutorial, there are still tons of little stuff that need works such as a working level selection, progress saving, and even finding a suitable background music.

But don’t worry, I managed to do all those stuff in the end, so stay tuned for the final progress log of project Chaser!
(and check out the game here!)

[1GAM-Mar] Grid Chaser: Progress Log #1

Progress? More like “birth” actually.
One Game A MonthNote: This is the third week of March, but this log only consists of the first two weeks.

It’s already March, which means it’s time for another series of my OneGameAMonth progress logs! You can check out my previous game (and also the progress logs) for January here and for February here.

As I’ve said before, this time around I’ll be returning to my home turf, which is mobile games, so I created a bunch of prototypes on my phone to decide which game idea I want to pursue. One of the initial idea is a game about managing a factory where player have to choose the correct machine to create the desired object. And so I spent the first weekend of March building a prototype for it.

Factory sketch

The game turns out okay-ish. While it feels quite intense and requires a lot of concentration (like Super Hexagon), I feel that the game pacing is too flat. There’s no up and down, there’s no ramping up intensity. In the end I decided to abandon this idea and try another one.

At some point in the next week, a friend of mine mentioned a game idea about being a kidnapper who have to sneak around the neighbourhood and evade people. While the idea sounds kinda meh to me (because if I have to sneak around, I’d rather be Solid Snake), the control he suggested, which have the kidnapper keeps moving while the player control when to turn with swipe, piques my interest. Somehow I can imagine a game about a knight moving around in a dungeon avoiding monsters with that kind of control. And to be honest, Nimble Quest might have inspired me a bit.

On the weekend, as I started opening up Photoshop and Eclipse, suddenly it occurred to me that the game is kinda similar to Pac-Man where we have a guy running around in a maze evading ghosts. And so I decided to just go with the Pac-Man look for my game, which is black background and bright basic shapes. I went with green grid for the maze, light blue triangle for the main character and red circle for the enemy.

It’s kinda interesting that since I already have a visualisation of how the game would look (which is Pac-Man), I can just work on the assets without needing to sketch the whole game first.

Project Pacman

On sunday noon I’m done with the prototyping. While I quite liked how the control turns out, the basic game concept apparently isn’t so good. The game feels like a weird mix of action and strategy where player have to pay attention to both his movement as well as the enemy movement. I tried tweaking stuff like movement speed or the number of enemy, but it doesn’t make the game any better.

Since the control is so fast-paced, I decided to make the game more action-oriented. My initial idea is to make some sort of racing game where the player have to race other people through a series of checkpoints in the maze. I dismissed this idea since it doesn’t rely on the player’s reflex, which is the control’s strong suit.

To properly test a player’s reflex, the player must not know the path in advance and has to react in time. The best way to do this is by having the player chase something, so he has to react quickly according to the target movement. I decided to pursue this idea further, and thus Project Chaser is born.

I simply modified some stuff and by Sunday night I got the game working. I also added some “coin-picking” sound effect when chasing the target to make the chasing part more exciting. And yay, this time around the game feels so much better since it’s now totally action oriented.

Project Chaser prototype

That said, it’s not like the idea doesn’t have any problem. The biggest problem is scalability, how do I make a full game from this chasing concept? I don’t think an endless version of this game is easily doable since it’s pretty boring if the enemy simply got faster and faster. Not to mention that I can’t figure out a good death condition for the game.

So that leaves level-based system, which is also annoying. Not just creating more maze is a pain in the ass, having a simply bigger and more complicated maze is also boring. What’s really needed is variety in the form of environmental obstacles, and while they’re doable, actually creating them will take quite a while.

We’ll see what I can come up with to overcome this problem.

Oh, and by the way, I think I have decided on the name of the game, which is Grid Chaser. The name actually comes from the racing game idea, which supposedly will be named Grid Racer (since it sounds similar to Ridge Racer). But since the game is now about chasing, I simply changed “racer” to “chaser”.

Well, that’s it for now, stay tuned for the third week progress on the next log (which hopefully will come out tomorrow)!

Project Mirror Progress Log #1 [1GAM-Feb]

It’s that time again for another progress log!
One Game A Month(oooh, I really like how this header image turns out =3)

Well, as some of you may have known, I’m participating in OneGameAMonth, a movement that encourages people to release a game every month. You can check out my game for January here, but since it’s now February, let’s talk about my new game!

Other than the gameplay, my January game is pretty much a familiar territory. It’s for a familiar target platform and made with a familiar tool. So February is time to try out a new tool (which is Unity3D), a new dimension (which is the third dimension), a new approach, and a new challenge. Basically, I’m trying to get out of my comfort zone.

So what will my February game be? Well, the original idea is from a twitter conversation some time ago (sorry, too lazy to dig through my tweets) and this is the light version of that idea:

The player is stuck on a temporal dimension that keeps changing. To survive, the player must keep moving, jumping from one platform to the next as quickly as possible to avoid getting swallowed. The game is viewed from a first person perspective.

Think of the game as an endless Mirror’s Edge but with randomly generated level. And so, since I haven’t got a proper name for the game, I’ll call it Project Mirror for now (even though the game has no mirror at all).

Mirror's Edge

Mirror’s Edge.

That said, the inspiration actually came from playing Assassin’s Creed III. Running and jumping around on that game feels really, really fun, so I wondered if having that kind of experience on first person view would be even more awesome. Oh, and the radio tower puzzle on Far Cry 3 is also another inspiration since it’s rare to see such a well-executed platforming puzzle on an FPS game.

Usually I would start developing a game by sketching how the game would look. However, this a 3D game with a first person camera, I don’t think sketching how the game looks from the camera would help visualize the game. So this time around, I decided to just poke around inside Unity3D engine and tried to get a feel of the game. Like I said, I tried a new approach for this game.

Well, I played around with Unity3D for a bit and this is what I’ve got so far:

Note that the platforms will be totally randomly generated, so there shouldn’t be any big jumping section like that in the early part. I just put it over there to have fun with Unity3D level editor =D

As can be seen from the video, I haven’t got really far with the game since I’m still learning the rope with Unity3D. I managed to generate a series of disappearing platforms that player have to jump across, but that’s it. As expected, generating an exciting platforms that’s fully random is hard since people will get bored if it’s just jumping and jumping, it have to be more varied.

That said, variety can be improved by increasing player’s skill set. Right now it’s only running and jumping, but simply adding something like a wall run or ladder climbing would improve the kind of platforms that can be used. I haven’t decided any additional ability to add yet though, I would have to find the formula for generating fun platforms first.

This time around I’ll try to stick with horizontal platforming. The original idea that I tweeted before is actually a Prince of Persia-like game with first person view where the player has to climb an endless version of the tower of Babel (even I got the title already: “Babel”). Who knows, may be that will be my March game?

As for the graphics, since the game takes place in some sort of inter-dimensional realm, I can stick with those white cubes for the platforms. The visual I’m trying to achieve here is similar to Assassin’s Creed loading scene where it’s just white stuff all over the place. That said, it won’t be only cubes though, I’m hoping to have more complicated forms like a stair, an L shaped platform, and other stuff.

Another thing I’m hoping to have is some sort of cool effect when a platform appears. I really like the scattering polygon effects on Assassin’s Creed III loading scene, so I’ll try to emulate that. I It seems a bit to complicated though, so I may have to simplify the effect into something like multiple tiny cubes gathering together to form a bigger platform block.

Assassin's Creed III

Assassin’s Creed III loading scene.

It’s interesting to see that this game development can be separated into several big challenges. The two biggest challenges that I can see are how to generate a fun platforming section and how to implement various movement abilities like sliding or wall running. I feel like if I can get those two problems solved, I would have a nice game at my hand. Oh, and implementing that “scattering polygons” effect like in Assassin’s Creed would be tough too, but it’s low priority for now.

That said, there are only 2 weekends left in February, I don’t know how much I could do with them =/

Trivia: some of my friends claimed their dream game is an RPG. Me? I guess my dream game is a really immersive FPS game =)

[1GAM-Jan] Black Holes: Final Log

Yes, we’ve finally come to this final log =)
One Game A Month
Right, before the actual report, let me tell you the good news. Black Holes, my OneGameAMonth entry for January, is now live on Google Play! You can go grab the game right from here! Or if you don’t have an Android device, you can watch the gameplay footage at the end of this post. Black Holes is a game about using black holes to pull away enemy bullets from your spaceship, sounds cool, right? =D

Oh, and link to the previous logs: #1 #2

So, on to the progress log. It’s the last weekend of January and I finally learnt the negative side of “working every weekends”.

Like I said in my previous post, there’s only a couple of stuff left to do and I’m quite confident it could be done in a day or two. However, come Saturday and I was still focused on working on my main game, Project Claw. I was working on a new mechanic and I wanted it to be done quickly so I could send it to my tester before Saturday night. Oh, and I also needed to send a mockup to another developer for a collaboration I’ve been proposing. Yeah, tons of work that day and in the end I didn’t touch Black Holes at all.

But there’s still Sunday! Sure, I started by working on the title screen logo, and once I’m satisfied with it, I moved on to laying out the rest of the title screen. But after that I suddenly lost my mood to work on the game. Apparently my mind is still on my other game, and I can’t force it to change its focus. In the end I didn’t do anything other than the title screen that weekend.

And that’s the problem with working only on weekends. On the previous week my mind is totally on “how to improve the game experience” and I’m able to work really effectively. However, once I achieved the level of experience I wanted, my mind moved on to the another stuff. And thus I found myself working on stuff that I didn’t really want to work on. Apparently it’s hard to maintain the same level of focus if you’re not working on the stuff regularly.

Title Screen

Well, despite not really focused on Black Holes, I know I need to get my shit done. The end of January is approaching fast after all. And even though I’m not really into the coding at that point, I still pretty much enjoyed working on the artistic part (like the icon). Fortunately, by Tuesday afternoon I already got it all working, both art-wise as well as feature-wise.

It’s not without its problems though. For example, apparently Android can’t play music track continuously without any gap 0.o So I ended up scrapping the plan to have an intro music for each round and just put the intro music on the title screen. Another problematic one is the tutorial. Well, I didn’t exactly have any problem with it, it’s just I hate working on tutorials. Not to mention that the tutorials are really crucial in making players quickly understand what they are supposed to do in this game, so they must be handled with care.

Someone seriously need to write a great tutorial about building tutorials =/

Tutorial screen

Later on that night I uploaded the game to Google Play (also came up with a description for the game) and with it, the Black Holes development saga has finally come to close. So, what’s my takeaway?

There are several things that I got from OneGameAMonth, first off is how awesome the indie people are. Seriously, the community is unbelievably helpful and supportive, and they’re also making cool games! Another thing is that I got someone to provide music for my game, which is super awesome. For me there’s always something magical about strangers working on something together.

What about the game itself? Well, I have achieved my goal of testing out the black hole mechanic, and I’m glad it turned out to be quite good. That said, I still feel that the game format can be better. Most games that utilize physics have tightly designed environment like Cut the Rope, Bad Piggies, Where’s My Water, etc, so may be puzzle game is more fitting for Black Holes?

One more stunning thing for me is how simple value-tweaking can drastically alter a game experience. Seriously, when I lowered the bullet speed from 250 to 150, it improved the game a lot, and when I changed “distance” to “distance squared”, it made the game even much better. Another thing I learned that I shouldn’t give up quickly when the early implementation isn’t good enough, I need to find the underlying problem and keep iterating to solve that problem.

I also learned that honesty is really, really important. Early on I found myself hoping that other people will find my game fun, even though I actually didn’t think it’s fun. Only by being honest with myself, accepting that my game sucks, I can start improving the game. Anyway, those are my opinions about the game, what about other people?

So far the early response to the game is pretty good, most people (like, almost all of them) are praising the idea, saying that it’s a good gameplay concept. And I even got a friend who kept nagging me with new ideas for the game XD It’s interesting to note that people are praising the concept, not the gameplay itself, which is kinda what I actually feel about the game. That said, there’s a few people who mentioned that the bullet is acting a bit weird, so may be I need to actually implement real physics engine after all.

See the game yourself on this full gameplay footage:

Now we’ve reached the end this post, let’s take a look at the future. What will become of Black Holes? Well, I never have any plan to develop it any further than this. I felt Black Holes has served it purposes, that is to prove that a game concept I had is quite fun, and thus I have no need to develop it anymore. If anything, I may use it for further learning, like learning to send a press release with it or use it to test out things such as an online leader board (hey, I love reinventing wheels!)

A little bit of confession, while writing this I just thought of another cool addition to the game. A cool addition that will never be implemented on the game, sigh.

And what of my February entry for OneGameAMonth? Well, I actually already have a really rough vision of what I want to do for February, but the main point is that I want to do it with Unity3D. I really think that it’s nigh time for me to finally learn some new tools. Oh, and it’s also gonna be in 3D. I really need to refresh my 3D calculation repertoire, been playing on the 2D space for too long.

Anyway don’t forget to give the game a try from here!

[1GAM-Jan] Black Holes: Progress Log #2

Ugh, super late progress report >.<
(it’s One Game a Month after all, not One Report a Week)

One Game A Month

So, in case you don’t know, right now I’m participating in OneGameAMonth and currently building a game called Black Holes. Black Holes is a mobile game (Android, specifically) where you must pull away enemy bullets from your spaceship by placing black holes. This is the second progress report, you can read the first one here.

Okay, with that out of the way, let’s proceed to the confession: I cheated.

Cheated? Well, yes, the original plan is to work on the game every weekend, but I ended up also working on it in the middle of the third week. It’s not without reasons, earlier I got a suggestion to slow down the bullets and I thought that’s an interesting idea. So I tried to implement it since I thought it would be quick (it’s just some value-tweaking). It is indeed quick, but the resulting game is so much better that I started to tweak other values, changed the interface, and all those incremental improvements since I finally felt like the game is moving on the right direction.

I also ended up adding a pause screen and a result screen. After all, there’s a game developer meetup in the middle of that week, and I wanted to make sure I have a functional game that I can give to people at the meetup. My ultimate test in finding out a game’s level of fun is by giving it to people and see if they’re retrying the game or not. And that’s where the result screen comes in, since I needed a place for the retry button.

So, how did it go? Well, poorly. While people seems to be interested in the mechanic, they’re not interested enough to keep playing it. It’s quite different compared to when I tested out my previous game, Project Claw. When people tried Project Claw, they keep hitting the retry button when they died (which made me quite confident that people will like the game), but not on this game. From the beginning I already had doubt about this game, and seeing this kind of reactions actually confirmed it.

New interface

The new, simpler interface

So, what should I do? From what I see during the meetup, people seemed lost and confused while playing the game, not really sure of what to do in it. It looked like the game is too passive, since the players don’t have any immediate goal to accomplish.

To remedy this passiveness, I thought of adding enemies. Having enemies would give player a much clearer goal since they can quickly associate enemy = bad = needs to be destroyed. So now instead of bullets coming from the sides of the screen, the game would have enemy ships firing at our spaceship. On the weekend I quickly implemented the idea and came out disappointed. Apparently it’s so easy to counter enemy ships, all a player need to do it just put a black hole near the enemy and the bullet will randomly hit it.

With that plan unsuccessful, I shifted my focus to the gameplay. I remembered feeling pretty fun at one point in the game, when there are tons of bullets and I hectically tried to catch all of them. That led me to think of a new gameplay where players would try to catch the bullets instead of bending them with black holes. But then I figured that it would totally beat my purpose of doing OneGameAMonth, which is to test out new mechanics. So I scrapped the idea and stick with the current one.

Enemy ship

Enemy ship

Okay, another try. What if the gameplay is actually fun, but didn’t feel intuitive enough because it didn’t behave correctly? After all, I just used my own hacky calculation to add gravity accelerations to the bullets. And so I opened up Wikipedia to learn how to properly calculate gravity acceleration. Apparently the real formula used distance squared, while I only used distance in my calculation. So I quickly changed it and…

…HOLY CRAP IT WORKS MUCH BETTER!

Seriously, once I used the correct formula, the whole experience feels way better. It is so much better now that a lot of nice additional mechanic kept popping out from my head. One of them is “near miss” mechanic where player would gain bonus score if they managed to make the bullet barely reached the ship. It’s a true risk VS reward mechanic. I also changed the scoring system so players would gain score when they managed to deflect a bullet out of the screen.

Both of this scoring mechanism made the game feels much more active. The players are now being directly rewarded when they do certain things so they understand what they should do in the game. And I really like how the floating text notification (it shows up when the player gains score) turns out =D

And so, at the end of the third weekend, this is what I came up with:

It is really close to the finish line now. I got most of the experience nailed and all that’s left are minor things like the title logo, highscore, game icon, etc. Stay tuned for the final progress log!

And oh, one last thing. I managed to get a great guy to help me with the music! You can listen to it and check out his other works here! =D

[1GAM-Jan] Black Holes: Progress Log #1

Let’s take a break and talk about other game once in a while =D

One Game A Month

As some of you may have known, I’m participating in OneGameAMonth (check out the website to find out more). In short, it’s a community that encourage people to build and release a game each month. Me? Well, I saw this as a perfect opportunity to flesh out various gameplay ideas that I have and also to try out new platform and tools.

For January I want to keep things simple, so I used a tool that I’m already familiar with, my own game framework for Android. As for the game itself, I want to try out an idea that I toyed around months ago:

Player must defend a spaceship by placing black holes on the map to pull away enemy bullets. The longer the ship survive, the higher the score will be.

The project is codenamed Holes for now (black holes, got it?). And the plan is to work on it every weekend or so during this January. And since I’m only aiming for a fun and playable prototype, 4 weekends should hopefully be enough time =D

Black Holes Sketch

In the first weekend I only fiddled around with the game concept, sketching out a quick mockup of the game, and drawing the game assets. I kinda liked the style of my sketch, so I tried to experiment with the art style and came up with a nice black-and-white sprites. To be honest though, I think I spent too much time polishing those sprites. But then again, drawing spaceship is really fun XD

Last weekend (second weekend of January) I started to code the game. I managed to implement the basic game mechanism and made the whole thing playable. I was doing it much slower than I had hoped though. I suppose it’s hard to suddenly change my mindset after working for a while on my main game which requires polish and planning.

Anyway, here’s what I have so far:

Note that the black hole (white shuriken stuff) is created on player’s tap.

As can be seen on the video, the “pulling bullets away with black hole” mechanic is already working even though it’s still very rough. And, truth to be told, I don’t think the game is as fun as I imagined it would be. This could be caused by a lot of things, but one of my suspicion is because the mechanic feels very “loose”.

What is “loose”? Well, a loose mechanism is a mechanism where a slight difference in input could have a totally different result. For example, Angry Birds is a “loose” game while Temple Run is a “tight” game. So a game with a loose mechanism will have a smaller margin for error.

Looking at these black holes, we can see how loose they are. When a player drops a black hole, the player doesn’t know how it will change the bullets. The hole might just change the bullet’s course slightly, or just made the bullet revolve around it, or it might even be too far away to change the course at all! I feel it made the game not fun because a lot of times the bullet will hit the ship just because of a stupid mistake. It’s too punishing.

Hopefully I can come up with something to make the game much tighter =)

Speaking of which, the original plan is to have a “black hole” that pulls in objects and a “white hole” that pushes objects away. Well, after playing with my current prototype, I feel that a simple black hole has made stuff complicated enough. Adding a “white hole” is just too much so I decided to remove it, at least for now.

Tune in next week for another progress report, I’ll hopefully also have something for you to listen to =D