Marketing Refresh including video

This week Kent and Joshua focused on marketing and did a great job!  When I first built the site, my main focus was making it an extension of the game, so that logging in on the site you were able to see all the same data as on the phone.  Kent and Joshua looked at other web sites for mobile games and found that they were really more about marketing.  They also pointed out that there wasn't much need to do things on the site that you could do on the phone already.  So we shifted in the marketing direction.

The site looks great.  Below are some before and after shots of the home page.  And most notably, Joshua made a hilarious promotional / instructional video which is highlighted on the new home page.


 (As a funny aside on the video, we first tried posting it on YouTube on an account that was connected to my Lanitek Google Apps account.  Maybe it was something related to Google Apps, but we could not figure out how to make a channel or upload the video on that account.  So Kent and Joshua made a Vimeo account.  Well, turns out the Google Play store will only let you specify a promo video if it is hosted on YouTube.  I've come to expect that kind of thing from Apple, but it surprised me that Google did that.  So we made a totally new GMail / YouTube account for MonsterCache, and then we were able to upload the video there.  And its still on Vimeo too).

BEFORE:

AFTER:

iOS 6 caching Ajax data

Wow, it's been a crazy 24 hours for MonsterCache development.  Kent and Joshua had found a few bugs once they got their iOS versions of the app.  Sunday morning I got a chance to work on them and fixed most of them!  So I sent Kent a new version with:

• sound for caught monster fixed in iOS
• restyled popup windows
• splash screens
• badge images now showing up
• "Recenter Map" button

I was very excited about the progress!  But there was one issue I couldn't figure out.  He said that each time he logged in, it was resetting his nets and coins back to their original values, even after he had used some nets and coins.  This was a new account for him, so every time he logged in, it just said 100 coins and 5 nets.  I asked him to make sure he did a Force Quit and try once more and he said it does same thing after many Force Quits.  So then I was depressed because this sounded like a major problem.

All that data is stored in window.sessionstorage, so I thought something was wrong with that, and that the values wouldn't overwrite. I've never heard of an issue like that. I just kept searching and couldn't find anything. I *thought* I had not seen this in the ios simulator in XCode.  But I think I didn't see it before because I occasionally have to do a "Reset content and settings" which must clear the cache. Or I just didn't notice.  Luckily I tried one more time to duplicate in the simulator before sending a version with some little storage tests to Kent and I was able to duplicate it.  I bought a net, logged out, logged in, and it showed the old numbers.

From there, I just had to put in a couple of alert() boxes to discover that the data coming back from the Ajax login call was incorrect.  The storage wasn't the problem, the data coming back from the login call was cached data! iOS was caching those results, which is terrible because the result changes all the time.

Turns out over 630 people had the same frustration, as evidenced on stackoverflow:

http://stackoverflow.com/questions/12506897/is-safari-on-ios-6-caching-ajax-results

Now I'm back to excited!  I think I introduced a small bug yesterday with the "Show Found / Hide Found" monsters, and I still have some JavaScript confirm() boxes to restyle, so I need to make a few more fixes.

In the meantime, Kathleen spent a couple hours MonsterCaching yesterday and has blown by Reed on the leader board.  She now has 33!

Pricing

Started a conversation about pricing for our In App Purchasing today.  All of our In App Purchasing products will be bundles of coins.  The question is how much to sell each bundle of coins for.  Here were my thoughts on it today:

We definitely want to offer better value for higher amounts.  My first idea was:

$3.99 - 100 coins

$5.99 - 300 coins

$7.99 - 500 coins

But now I think that is too high.  With 100 coins, you can currently buy 13 nets (10 nets for 70 coins and then 3 single nets at 10 each).  So that means $4/13 nets = 30 cents / net.  That seems like quite a bit to charge.  Especially since people have been easily getting 13 in a week or two at the start.  So I'm thinking either 2.99 or 1.99 for 100.  I like $1.99 because its little enough that I think people will do it. Maybe

$1.99 - 100 coins = 2c / coin = 15c / net

$3.99 - 300 coins = 1.3c / coin = 10c / net (or less with bigger net packages)

$5.99 - 600 coins = 1c / coin

$8.99 - 1000 coins = .9c/coin

If we also have bulk buying options of nets for coins, then someone could probably buy about 200 nets for 1000 coins / $8.99.  I like the idea that if you're willing to spend $8.99, you can play *almost* indefinitely   Matt has gone WELL over 200 nets with his GOD account though, so the real dedicated users may still have to pay more.

----------------------

Kent agreed that $1.99 is a good starting point.  He indirectly brought up the issue of consumables vs. non-consumables.  Since our Silver and Mirror items do not diminish, we could sell them as non-consumables in the app store.  But I kinda like keeping it consistent with just selling coins.  We'll see.

iOS for Kent! After Provisioning Profile confusion

Good day for MonsterCache.  Kent had an intern, Joshua, helping him today and they were asking me some MonsterCache questions.  That gave me the extra little motivation I needed to try getting an iOS version to them.  Even though I was able to get the iOS version running on my parents' phones already, that was much easier because I could hook their phones to my computer.  That's called Developer Provisioning (I think).

Kent and Josh are in Colorado and I'm in Kansas, so to get the app to them, I had to email it along with a provisioning profile.  That's called Distribution Provisioning (I think).  It's all quite confusing.  You have to make these special Provisioning Profiles for each case.  Besides the Developer Profile and Distribution (also called Ad Hoc) profile, XCode makes a Team Profile for you. That may be the same as the Developer one. I don't know.

Anyway, the first time I built and signed the archive file for the app and sent to Kent, he tried installing and it failed.  So I read a bit and figured I'd used the wrong profile.  So I downloaded all the profiles from my Developer account to XCode and tried again.  Turns out I hadn't downloaded the Ad Hoc profile the first time, so I hadn't signed with it either.  Once I had it and signed it with the Ad Hoc, then I sent to Kent and it worked!  Since I was happy to have figured that out, I posted an answer about it on StackOverflow.

Oh, and I got the iOS In-App Purchasing working last weekend, so now things are VERY CLOSE!  Just need to do a few more styling things.  And its great that Kent and Joshua have the app now, and Matt's coworker, Reed, is beta testing on Android.  Very exciting.

Phonegap In App Billing plugin for Android - v2 API

Yesterday I got motivated to make my first PhoneGap contribution.  I planned to add some calls to a couple of API functions that weren't implemented in the plugin.  I don't know Java, but I hoped that I could just copy some parts that were making other API calls and just make the changes for the calls that I needed.

As I started looking at the Java code in the plugin, I noticed that there was basically just one API call being made with a different command message being sent as a parameter.  That wasn't what I was expecting to see.  So I started looking back at the Android API documentation and found that the calls being used in the plugin were from the version 2 (v2) API.  The v3 API is the latest, but just came out in last month or so.  But its quite a bit different.  So essentially the plugin would need a major upgrade to support the v2 API.  Not knowing Java, that seemed to be too much for me, so I had to give up on helping with the plugin :-(

And MonsterCache will just have to get by with the v2 API features for now.  The two v3 features I was trying to implement were:

• Getting the list of available products and prices from the store.  I can store those myself, but getting them from the Play store may send you a converted currency in other countries, I'm not sure.
• Consuming items.  In v3 all items in the store are "Managed", meaning Google keeps track of whether a user has bought them so that they don't have to be bought again.  But if your item should able to be bought again -- like in-game currency -- then you have to "consume" the item so that the user can buy it again.  In v2 though, they have "Unmanaged" items, and you can still make those in the Play store, so v2 still works

So once I coded for v2, it looks like Android In App Purchasing is working.  I'll have to have my test user (my wife) run a test tomorrow to be sure.  Google doesn't let you buy your own product.

I also got a JQuery popup dialog working today.  That was very good because I have lots of basic ugly alert() boxes that I could replace now with something that would look better.

Tomorrow I'm going to take a shot at the iOS In App Billing plugin.