Wednesday, March 24, 2010

Progress Report: March 24, 2010

This is my first progress report!  But before I go into the report, let's talk quickly about my the game idea.  My game will be based off of another game (what game ISN'T based off something else nowadays?!) called Canabalt, created by Adam Saltsman.  It's a fun, fast, and furious little game that Adam created within a span of 5 days (wow!).  If you don't know about it, you can click the link and try out the flash version of the game; an Iphone version is also available for purchase.  However, he hasn't made an Android version yet, so I'm hoping to fill in that niche market!  Basic premise of the game is that you are running and jumping from one rooftop to another, avoiding obstacles and trying not to smack into walls or fall between buildings.  The only control you have is JUMP, so the running and acceleration is automatic.  When you die, the game is over.  The only important statistic is how far you ran before your demise.  It's a pretty simple concept, but it seems to work so well, especially for a smartphone game. 
So I am trying to make a game just like Canabalt.  If you're asking: "Why don't you use some creativity and try something new?", see this post.  What have I done so far?
  1. Coded a simple engine that is based on a constant framerate (currently set to 25fps), making use of Android's SurfaceView class.  My physics update function for the player is time-based (as opposed to frame-based).  This means that his movements - horizontal and vertical - are calculated based on real time, not frames. However, the sprite animations are frame-based.  But since the engine is running at a constant framerate, this shouldn't be an issue.  I'll have to revisit this later on should I decide to change the engine to allow for a variable framerate.
  2. Created an environment that is composed of buildings and gaps between the buildings.  Currently, I have three types of buildings: tall, medium, and short. 
  3. Created a player that can run and fall off buildings in the environment, taking into account horizontal and vertical velocities and accelerations. 
  4. Used existing sprite sheet from one of my favourite Naruto characters, Rock Lee!  I found his sprite sheet here.  Don't worry!  I'm only testing with these sprite sheets.  Eventually, I'll make my own original sprites!  So far, I've got animation of him running (6 frames looping), standing (1 frame), and falling (1 frame). 
  5. I've been working on the pseudo-code for implementing the jump functionality.  I think I am pretty much ready to code it.
  6. Throughout all this work, I've been documenting all my stuff: pseudo-code, design, state diagrams, acceleration/velocity/distance algorithms, etc..  I'll try to share some of that in future posts.
In terms of coding, I think I'm close to finishing.  After implementing the jump functionality, I need to code how to handle when the player gets into the "game over" state, and an algorithm that randomly generates the environments.  After that, I'm pretty much done coding, unless I want to go back and do some code optimizations.  But I think I'll leave the optimization work to the very end (...because it's not as exciting as creating!).

Tuesday, March 23, 2010

Why are you doing this?

Often when I reach a point of frustration during a project, I ask myself "why am I doing this?"  And often times, I am unable to really answer that.  By then, I have either lost sight of what I wanted to do or never really knew to begin with.  When this happens, you lose your mojo, get lackadaisical, and this project becomes yet another unaccomplished half-assed job.  That's why it's important when you set out on a journey to know what you plan to accomplish.  It helps you keep your focus especially during the rough roads ahead (and the roads WILL get rough!).  Here are some of mine:

Goal 1: Finish a game. 

How?  Here are guidelines I've set for myself to help me reach this goal:
  1. Quick turnaround.  I want this first game to be completed within half a year.
  2. Simple and easy.  Keep the game 2D because 2D is easier than 3D.  Don't bother using OpenGL ES for now; Android's SurfaceView will work fine with a small number of sprites.
  3. Don't over-engineer, over-think, over-analyze.  Don't focus on pixel perfect collision detection algorithms.  Use simple, albeit inaccurate, algorithms because they can be revisited later on. 
  4. Mimic an existing game.  Basically, I want to walk a path that has already been traveled.  I'll think about originality for my next project!
  5. Keep motivated.  How?  By focusing more on results you can see.  Work on graphics before gameplay mechanics.  Work on implementing functionality before working on code optimization.

Goal 2: Make some money!  

Let's face it.  I'm doing this mainly to get some additional revenue aside from my regular work.  The plan is to eventually put this game up on the Android market for mass consumption. 

Goal 3: Make the game fast-paced.   

In high school, I made a turn based game which was lots of fun to make.  But ultimately, it was not a fun game as it was just too static.  This time, I want to make something that requires reflexes!

Goal 4: Learn about game design. 

I don't need to learn everything about it.  I just need to get something out of it.  Now that I think of it, this one is pretty much a given. 
My plan is to revisit this post during my development and use it to keep me from losing sight of things.  What are your goals on your own journey into game development? 
Side Note: I've been skimming through this guy's blog about his journey as a game developer and came across this interesting article.  It talks about keeping motivated during development.  JW: You don't know me, but thanks for the article!  Hopefully it will help me maintain my focus on my own journey. 

Thursday, March 4, 2010

How to Put Drawings in Your Blog

This post is not at all related to anything mobile, gaming, or programming.  But it's a great beginner tip for bloggers, myself included!

Say you work with Google Documents a lot and enjoy the rich set features that it offers, such as multi-level lists and the ability to insert custom drawings.  I love the drawings feature (ie: charts, graphs, diagrams, illustrations, etc.) of Google docs because I love visual aids.  I love to include some sort of visual to "show" what I am trying to explain. 

Say you also have a blog (say, from, but you find the blog site's default post editor somewhat lacking in features.  For instance, you may want to give your blog post some... visual aids!  Sadly, Blogger's current post editor does not have this capability and I am not aware of any other blog sites that do offer it.  You would need to find some software to create your drawing, save it as an image file, then insert it into your blog post.  TEDIOUS!  Wouldn't it be great to use Google Documents as your post editor?

Well unfortunately, you can't change the post editor, but here's the next best thing.  You can write your blog post as a Google Document, and then publish it straight to your blog!  This method allows you to include those drawings in your blog post!  Another bonus is that you can use multi-level lists (like numbered lists or bullets) because Google docs does it while the  Blogger post editor only handles single level lists.  Mind you, I have only tried this with Blogger, but I don't see why it wouldn't work with most other blog sites out there.

How to do it: Start off by creating a new Google Document and use this to write your blog post, drawings included.  When you're ready to publish, click on the Share button at the top-right corner.  In the menu that pops up, select Publish as web page.  Now you should see an option to Post to blog.  If this is your first time, you will need to set your blog site settings, such as which blog site you use and what user ID and password you use to access it.  Once set up, click on Post to blog.  Now, your Google doc has been published to your blog!

Check your blog.  If your drawings don't appear (they may appear as missing links), here is the reason why and how you fix it: When you publish to your blog, the drawing gets converted into a picture (PNG format) that Google stores internally.  Your blog will automatically link to this picture.  However, blog readers will not be able to see these pictures because the PNG file is only readable by you.  This is because by default, only you can access the Google doc.  To fix this, go back to, select the check box for the Google doc that contains your blog post, and click on Share -> Get the link to share.  In the dialog that appears, select the check box for Allow anyone with the link to view (no sign-in required).  Make sure to NOT select the Allow them to edit check box for obvious reasons.  Click on Save & Close and you're done.  Check your blog post again and the PNG files should appear. 

This is great for those of you that do technical articles because of the ability to insert your own diagrams or illustrations to spruce up your blog posts.  It is also easy to change: just change the drawing in the Google doc and republish to your blog.  Very geeky, but very powerful.  Happy blogging!

2D Collision Detection: Part 1

Last night, I completed my simple 2D collision detection function and tested it.  It works!  Before I divulge the details of my algorithm, I'll show you my process.  When I was researching algorithms, I came across some common ones people were using:
  1. Bounding Box algorithm: put each object into a bounding box and then determine if two boxes intersect each other  

  2. Bounding Circle algorithm: put each object into a bounding circle and then determine if two circles intersect each other (offhand, this one seems quicker and possibly more accurate for more organic shapes than the bounding box algorithm)  

  3. SAT using convex polygons: This one is more complex than the other two and requires significant work beforehand.  Basically, you need to create a convex polygon for all objects (likely a manual task), and then you can use SAT (Separating Axis Theorem) to determine if two polygons intersect each other.  My thought is that using SAT will be the most accurate algorithm, but I got scared off by the thought of having to calculate normals for each edge and the shear number of projections involved.  Also having to manually set up polygons for each object seemed like just too much work.

I figured that I would start simple, so it would have to be either bounding box or bounding circle.  The basic algorithm would be:

Given box A and B and vector V that represents the movement from A to A':
  1. move box A to A'. 
  2. if A' intersects B, then reverse A' to the point where it no longer intersects B.
The problem here is: what if B is between A and A' and V is large enough such that A' passes B? 


In such a case, A would simply move right through B.  I looked online for solutions on this and the only solution I found was: keep vector V relatively small (ie: Don't move A so fast!).  I could understand that in most cases, this would not be an issue.  But what if B was skinny? 

In such a case, it would not take V to be very large before this problem occurred.  I was determined to find an algorithm that would not only account for the starting and ending position of A, but also the path of A to A' (the darker red area below).
 Next time I will look into the strategy of how to implement this.


Tuesday, March 2, 2010

Introductions are in order...

Who am I?  If you're reading this, you probably have some interest in game development.  My interest in game development started back in the days of the original Nintendo system (the 8-bit version!).  I remember playing Super Mario for hours on end.  The first game I bought was probably Batman for NES, back in 1989.  Good times.

It was around that time that my dad bought me my first PC, an XT with 640Kb of memory and a 20Mb hard drive.  I still remember the monitor: a CGA screen capable of 4 colours!  I would play King's Quest, Police Quest and Space Quest in glorious cyan, red, green, and yellow.  And as for sound, we were taken to aural ecstasy through a PC speaker that only output beeps.

My uncle was the one who introduced me to programming.  He taught me how to program my first "Hello World" on Turbo Pascal 5.x.  I was hooked.  The first app I wrote by myself was a calculator that could add, subtract, multiply, and divide.  I had turned my $2000 PC into an oversized $1 gadget.  Wow.

In high school, I was introduced to Street Fighter 2 and it caught me hook, line, and sinker.  My buddies and I would go anywhere that had a SF2 arcade machine and play for hours on end.  I spent way too much time dreaming about making my own fighting game.

In my high school computer class, the programming language of choice was Turing and I learned it inside out.  After spending way too many hours in the computer lab, I completed my first game: SpartanX.  It was a two player turn-based game played on a grid map.  The goal was to use your ship to destroy the opponent's ship.  The interface was completely graphical with a 320x200 resolution and 256 colours.  I even programmed my own graphics file format and graphics editor (with a "fill" algorithm!).  When you got bored killing each other, I had a map editor where you could make your own battle grounds complete with walls and water hazards.

In 1995, I went to university.  That's where I seem to have lost my passion.  I stopped programming and spent too much time hanging out with friends and doing "university things".  The funny thing was, I was in a computer science program in university and I was working at Electronics Boutique (they sell video games!). I had so much influence and inspiration all around me.  But it was this period of my life that I lost the interest in it.  One thing led to another, and now I find myself as a happily married father of two wonderful girls, working as a database administrator for a large Canadian bank.

What happened?  Why am I not working for Capcom or EA?  I don't know, but it's been a long, long time and I am starting to feel an itch again.

When cell phones began coming out with colour screens and little time-waster games I had a feeling that it wouldn't be long until technology caught up and we'd start seeing more advanced games on more advanced cell phone devices.  I thought that it would be good if I could catch that wave.  Then in 2007, Apple came out with the iPhone.  The games on the iPhone were great: fast, fun, and not too advanced or complex.  This was a market that independent game developers could prosper from.  But alas, there were too many roadblocks.  Development for iPhone was only available on a Mac, and I was a PC user.  We were expecting a second child, so free time was to be drastically reduced.  Also, I heard that the process for getting your app approved and put up on the App Store was tedious and troublesome.  Time went on, and I started feeling like I was missing the wave. 

In 2009, I began hearing about Android, Google's operating system for smartphone devices.  It was said to be a strong competitor to the iPhone.  It was new.  It was Google!  This could be my opportunity.  A few months ago, I took the plunge and installed the SDK and tinkered a bit.  A few weeks ago, I decided to start working on a small game.  Nothing big or complex.  Just a simple time-waster of a game.  Maybe even put it up on the android market for free.  Last week, I started working on some of my game engine components and decided to blog about it.  Here goes...