A New Phone, A New Plan

The time had finally come. I had been waiting so long to get a new phone. Until recently, my sidekick had been the Sony Ericsson w810i, a utilitarian device that served me well since 2007. But as with all technology, it was time to upgrade. And since I stuck it out with my w810i for so long, I figured I now deserved the latest and greatest.

What I wanted

 

My main requirements were pretty simple: I wanted a smartphone with a basic phone+data plan and caller ID.  Since I've been mucking around with Android development, the smartphone would have to be an Android phone.  After much research, I settled on a sexy thing called the Sony Ericsson Xperia X10 (I'll work on a review of this phone shortly).  I didn't care much for the phone plan details because even the most basic phone plan would generally suffice as I don't call a whole lot of people nor do I care about long distance.  In Canada, it looks like the standard data plan is 500MB/month and I was ok with that too.  The only other thing I really needed was the caller ID for weeding people out. 

A little homework... 

Now that I had decided what I wanted, I started looking at plans.  My original plan was with Rogers and consisted of a very basic $20 plan, $8 for caller ID, and a deprecated $6.95 access fee for a grand total of $34.95 before taxes; not a great plan by any means.  The good thing was that my contract had ended back in 2009 so I was basically a free agent.  I had the power to switch plans or providers as I please without penalty.  I would use that to my advantage.

 

Since I was getting a smartphone, I wanted to add a data plan.  Rogers' cheapest voice+data plan was $50 plus a government regulatory recovery fee of $2.58 (varies by province).  Add in Caller ID ($8) and I was looking at $60.58/month.  To buy the X10 outright would cost me $500 but if I got on a 3 year plan I could get the phone for $150.  This would be my benchmark. 

 

Other worthy mentions were Wind Mobile's promotion ($150 credit for switching an existing phone number to them) and Bell's promotion ($10 off any voice+data plan for a 3 year contract and free Palm Pre phone).  Honestly though, none of the other providers were really in the mix as only Rogers carried the X10.  Wind didn't have a single Android phone in their lineup, and Bell's Android selection was weak.  But still, I could use these promotions as leverage in my negotiations. 

...goes a long way!

On a lazy Thursday afternoon, I decided to call Rogers to see what they were willing to offer me.  I immediately asked for their Customer Retentions department and was quickly greeted by a rep (one thing that has impressed me about Rogers in recent years is that I never have to wait on the phone for long).  I quickly explained my current plan and the new plan that I wanted.  Then I told him about the promotions that Wind and Bell were offering and how I thought that I didn't see anything from Rogers that was competitive with these promotions.  When I asked him if there was anything he could do about it, he politely declined.  I tried again and again from various angles (reminded him of all the services I had with Rogers, the number of years I had been with them, etc.) but this dude just wouldn't budge.  After a couple minutes of this I knew he was going to stonewall me so I gave up and ended the call.  From reading on forums, I knew that discounts were based on the rep's discretion, so I would have to try again.

 

The next day I called Rogers retention again.  This time, I told them I wanted to cancel because the guy from yesterday was not willing to give me any discounts.  I again explained what phone and plan I was interested in, informed the rep of the various promotions out there, and reminded her of the years and services I had with Rogers.  This rep was much more agreeable with me and asked me to hold on for a couple of minutes while she "worked something out".  When she got back to me, she gave me $10 off the $50 voice+data plan AND free caller ID!  On top of that, she said that I had built up credit for these past few years that I had been with Rogers and that entitled me to $50 off the phone.  After giving me a few extra bonuses - waiving of the activation fee and a few months of unlimited calling - I ended the call on a much happier note.  The end result?  I am looking at $100 for the X10 and $42.58 for voice+data (500MB data) and free caller ID with free unlimited messaging as part of the package!

Tips on how to negotiate with Rogers

So, what should you do when negotiating with Rogers? 

 

First off: do your homework!  Figure out your requirements and what Rogers plans and services satisfy them.  Then find out what other providers offer including promotions.  Figure out everything down to the nitty-gritty.  When I was talking with Rogers, I knew exactly all the fees involved including the old $6.95 access fee (no longer applied to new plans, but existed in my original plan), the government regulatory recovery fee, and the emergency access fee.  Also, you should be aware of your limits.  If you just started a contract, haven't been with Rogers for very long, or don't have other services with them then won't have much to negotiate with.  

 

Secondly: make a plan of action.  Before calling Rogers, I had written up a short plan of action.  In it, I put in some info on how I would approach the rep, what I would ask for, what I expected to get, and what to do if the plan doesn't work out.  You see, I'm quite bad at improvising.  If I didn't have a plan of action I'd most likely fumble and botch things up.  I think it's better to be prepared anyway. 

 

Third: be aware that discounts are based on the individual's discretion.  As you read above, my first call to Rogers ended in stalemate and I was prepared for that.  You just have to keep trying.  I have read stories of other people trying 4-5 different reps before they got one that gave them a deal. 

 

Fourth: Keep your cool.  Be patient.  Don't lose your temper as it gets you nowhere. 

 

Good luck getting that deal!

 

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!).
 

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. 

 

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 www.blogger.com), 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 docs.google.com, 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.

 

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...