Apple Doesn’t Care About Games

Tell us something that we didn’t already know.

In his (not so) recent article in The Guardian, I was an App Store games editor – that’s how I know Apple doesn’t care about games, a former App Store editor, Neil Long, confirms facts that we knew to be true, even obvious, through our experiences with game submissions.

The fundamental conclusion, that Apple doesn’t particularly care about games, is self-evident. Apple is not a game company, and they don’t value games as a way to sell hardware, or increase prestige, or whatever the hell Apple’s mission is these days. Oh, right… their primary mission is increasing shareholder value, so they have no immediate incentive (and very little foresight) to invest in nor properly support the mobile game ecosystem they created “by accident“.

The article confirms what we already surmised, from a “woefully understaffed team of app reviewers”, to comical submission failures, to generally making whatever changes seem to bring in the most profits, regardless of the effects on their customers, game publishers, or the long-term health of the entire system. They don’t see a reason to address the fact that the median income of an iOS game on the App Store is, literally, $0; as long as a few games make them loads of cash, they do not care.

This is, of course, why Apple did the calculus and determined that it was considerably less expensive to reduce commissions to 15% for most game publishers (which costs them absolutely nothing for the majority of games) than to lose their monopoly on iOS sales. (Honestly, I don’t actually know how many “publishers” have signed up for the App Store Small Business Program to get the commission reduction, since a seemingly large, and growing, number are non-professionals.)

I could speculate on the theoretical issues that will be an increasing problem for the App Store in the future, but instead I will mention the very real issues that are happening right now. First, the economics of mobile games (for both Apple and Android) are no longer generally viable without manipulation techniques. A handful of games are making millions of dollars per month (or even per day), but the vast majority do not earn enough in their lifetimes to cover the cost of development. There used to be developers advocating a “mobile first” design strategy, and now I hear nothing about this approach; I do hear about companies deciding that it is not worth the effort, and I know that is a very active discussion point for our future games.

On the other hand, despite the ostensibly strict submission and approval process, Apple is allowing the App Store to be inundated with multiple copies of essentially the same game, submitted by “different” publishers. In some categories I have explored, it is easy to download just a few games and find at least two that are obviously based on the same source code, with only minor graphical revisions (or else cloned so closely as to be counterproductive). I don’t know the actual business model (whether it is a larger company flooding the market, or somebody selling source code packages, or amateurs just submitting sample game applications from some tool or another), but the result is that the App Store experience is getting steadily worse. I love the fact that a 12-year-old with talent (as I was when I got started programming games long before any of this was possible) can gain valuable experience by publishing their own game on this platform, but when every game is either a first project, a clone, or a product with a 6-figure marketing budget, there is little value to be found.

Here are the questions that have to be asked by professional developers:

  • Why should we commit resources to developing a game for iOS (or Android) when the chances of profiting are very slim?
  • What incentives do we have to update and improve released products that have not recouped costs on this mobile platform?
  • Why should we develop for a platform where discoverability is such a problem, and getting worse all the time?
  • What incentives do we have to bother to remove a “zombie” product (i.e., one that earns nothing) from the App Store once published?
  • Why should we bother to support a platform whose owner so clearly does not care about us nor our support of their platform?

I do not have any tangible solutions to suggest (publicly) at this time, primarily because changes are up to Apple and they are unlikely to listen to me (based on every previous interaction). In general, though, as the article says, “Apple could have reinvested a greater fraction of the billions it has earned from mobile games“, and further, it could be seen to actually care about those of us who work hard to make a living developing games and, in the process, supporting their platform (and bottom line). You know, any reasonable change that does not make our lives more difficult or potentially cost us more money to compete would be a start.

Launch Screen Sizes for iOS 12

If you still use launch screens, these are the sizes you need.

As with mobile icons, the proliferation of new Apple mobile devices demands an ever increasing number of launch images.  This post lists the necessary artwork sizes to directly support all devices (and possible orientations) as of iOS 12.

Of course, Apple realizes that adding new launch screen sizes every time they introduce a new form factor will quickly become unsustainable.  (It is close to that now; otherwise, this post would be unnecessary. 😉 )  For that reason, they introduced launch storyboards, which allow a launch screen to be defined by a layout of controls and constraints, rather than by individually sized images.  The only problem is that, unlike normal storyboards, the launch storyboard is loaded before the application runs, so only automatic layout can occur; no code can be executed.  Therefore, customization is restricted, which prevents developers from accomplishing the same thing that is possible with launch images, namely, use of the entire screen on each individual device for displaying an image.

Apple takes the position that the launch screen should display an image reflective of the first screen of the application to give the impression that the app has launched that quickly.  This certainly is better for Apple, who is not known for missing branding opportunities, but using the launch images for branding, i.e., a splash screen, is expected in the game industry (and, arguably, for any software).  Also, games usually have custom background artwork, and if that is customized to screen sizes, there is no easy way to mimic that with a launch storyboard, at least at the moment.

To be fair, nowadays the launch screen is a somewhat rare occurrence, as it is only shown at first launch, or when the application has been unloaded, either closed by the user or removed from the background by the system to recover resources.  If you design your splash screen to be an image in a sea of solid color or a repeating texture, you can reproduce that with a launch storyboard.  The kind of splash screens that Rick Tumanis designed for Demolish! Pairs or Pretty Good Solitaire, however, do not lend themselves to this approach.  It is for that reason that we still use launch images in those games (and others).  In fact, Demolish! Pairs will reshow the splash screen if you shake the device from the menu.  (It is an ‘undo’ when done from within a game.)

So without further ado…

iPhone Launch Screen Sizes

Apple iPhones provide the bulk of the variety in device screen sizes, so you need to provide 11 (or 12) launch images for full coverage, as follows:

  • Portrait iOS 12+
    1. 1242 x 2688 (@3x) – iPhone XS Max
    2. 828 x 1792 (@2x) – iPhone XR
  • Landscape iOS 12+
    1. 2688 x 1242 (@3x) – iPhone XS Max
    2. 1792 x 828 (@2x) – iPhone XR
  • Portrait iOS 11+
    1. 1125 x 2436 (@3x) – iPhone X / iPhone XS
  • Landscape iOS 11+
    1. 2436 x 1125 (@3x) – iPhone X / iPhone XS
  • iPhone Portrait iOS 8+
    1. 1242 x 2208 (@3x) – Retina HD 5.5″ (iPhone 6 Plus / 6s Plus / 7 Plus / 8 Plus)
    2. 750 x 1334 (@2x) – Retina HD 4.7″ (iPhone 6 / 6s / 7 / 8)
  • iPhone Landscape iOS 8+
    1. 2208 x 1242 (@3x) – Retina HD 5.5″ (iPhone 6 Plus / 6s Plus / 7 Plus / 8 Plus)
  • iPhone Portrait iOS 7+
    1. 640 x 960 (@2x) – 2x (iPhone 4s)
    2. 640 x 1136 (@2x) – Retina 4 (iPhone 5 / 5s / SE)
  • iPhone Portrait iOS 5, 6 (legacy)
    1. 320 x 640 – 1x (optional – unused on iOS 8+)
    2. 640 x 960 (@2x) – 2x (same as #10)
    3. 640 x 1136 (@2x) – Retina 4 (same as #11)

Note that the lowest supported target system for Xcode 10.0 (latest version as of this writing) is iOS 8.0, and no devices at the original iPhone resolution (320 x 640) can run that version of iOS, so the final unique size (#12) is unused in modern apps.

iPad Launch Screen Sizes

There is good news and bad news when it comes to supporting iPad launch images.

Good News

The good news is that you only need 4 launch images for iPad support, as follows:

  • iPad Portrait iOS 7+
    1. 768 x 1024 – 1x (iPad 2)
    2. 1536 x 2048 (@2x) – 2x (iPad Retina / Air / Air 2 / 5th gen / 6th gen)
  • iPad Landscape iOS 7+
    1. 1024 x 768 – 1x (iPad 2)
    2. 2048 x 1536 (@2x) – 2x (iPad Retina / Air / Air 2 / 5th gen / 6th gen)

That is pretty straightforward, especially given that they are the same aspect ratio, so you can just create the double density size and directly reduce the image.  Further, if your target platform is iOS 10 or higher, the iPad 2 is no longer supported, so you only need the two larger images for all remaining iPads.

For completeness, here are the legacy sizes for iPads running iOS 5 or 6:

  • iPad Portrait Without Status Bar iOS 5, 6 (legacy)
    1. 768 x 1004 – 1x (optional – unused on iOS 8+)
    2. 536 x 2008 (@2x) – 2x (optional – unused on iOS 8+)
  • iPad Portrait iOS 5, 6 (legacy)
    1. 768 x 1024 – 1x (same as #1)
    2. 1536 x 2048 (@2x) – 2x (same as #2)
  • iPad Landscape Without Status Bar iOS 5, 6 (legacy)
    1. 1024 x 748 – 1x (optional – unused on iOS 8+)
    2. 2048 x 1496 (@2x) – 2x (optional – unused on iOS 8+)
  • iPad Landscape iOS 5, 6 (legacy)
    1. 1024 x 768 – 1x (same as #3)
    2. 2048 x 1536 (@2x) – 2x (same as #4)

The only (4) new sizes here are just the same launch screen sizes with an area for the status bar (20 or 40 pixels) removed.  These sizes are never used in modern apps.

Bad News

The bad news is that, as keen observers will have noticed, I did not list any of the iPad Pro models above; this is because an iPad Pro acts like an iPad Retina.  Without a launch storyboard, all iPad Pro devices show up as though they are only 2048 x 1536 resolution.

To be fair, the smallest iPad Pro, the 9.7″ model, is only 2048 x 1536, but the two larger models have higher resolution that is not used: 12.9″ is 2732 x 2048; 10.5″ is 2224 x 1668.

If you want to have the full resolution of iPad Pro devices, you must use a launch storyboard rather than launch images; you cannot use both, as (experimentation suggests that) the inclusion of a launch storyboard supersedes launch images.  Damn.

Conclusion

The release of iOS 12 added the need for 4 additional launch screens (to support both orientations for the iPhone XR and iPhone XS Max), so a “universal” app needs to provide a total of 15 launch images to support all iPhone and iPad devices.  However, if your game or app needs to take advantage of the full resolution of the iPad Pro, you will need to provide a launch storyboard instead, and adjust your launch screen appropriately.

All Apple needs to do to provide complete support is to provide constraints for individual form factors, allowing different images to be selected from the launch storyboard based on device model, OR use a provided launch image in preference to (or prior to) a launch storyboard.  Best of all, they could just remove the arbitrary and silly restriction that prevents access to full iPad Pro resolution unless we provide a launch storyboard, which restriction seems to be in place for the sole purpose of strong-arming developers into supporting launch storyboards (before they provide equivalent functionality).

In the meantime (which will likely be forever), it makes sense to start figuring out how to adjust your launch design and strategy to work with launch storyboards.  This is not unlike what is currently necessary for Android support, anyway.  For our next project, we are investigating a high resolution square-ish logo that can be the sole image in a field of white, scaled to largest size possible to fit the launch screen.

Abandoning this expected branding opportunity, though?  Not likely.

Modern Mobile Icon Sizes

Icon sizes you need to support iOS 12 and Android Oreo devices.

With the explosion of mobile devices, it keeps getting more difficult to keep track of the myriad icon sizes required for mobile apps.  This post simply lists the required sizes and uses for iOS and Android devices (as of now).

When creating an application icon, it is best to start with an image that is (at least) the size of the largest icon necessary, which is currently 1024 x 1024, and then reduce that image to the necessary sizes, reducing level of detail as/if necessary for smaller icons.

iOS App Icons

As of Xcode 10 (iOS 12), iOSApple iOS devices have application icons for the app on three different device types (iPhone, iPad, and iPad Pro), the store, spotlight (search), settings, and notifications, and these icons may need to be provided in single (unadorned), double (“@2x”), or triple (“@3x”) scale factors.

For a “universal” app, you need to provide icons in 13 resolutions (for 15/18/19 different uses, depending on how you count).  iPhone only apps need 8 resolutions; iPad only apps need 9 resolutions.

Here is a list of the iOS icon sizes, along with a color-coded list of the uses:

  • 1024 x 1024
    • App Store – all applications  (<title>.png)
  • 180 x 180
    • iPhone application @3x  (<title>_iphone@3x.png)
  • 167 x 167
    • iPad Pro application @2x  (<title>_pro@2x.png)
  • 152 x 152
    • iPad application @2x  (<title>_ipad@2x.png)
  • 120 x 120
    • iPhone application @2x  (<title>_iphone@2x.png)
    • iPhone spotlight @3x  (<title>_search@3x.png)
  • 87 x 87
    • iPhone settings @3x  (<title>_settings@3x.png)
  • 80 x 80
    • iPhone spotlight @2x  (<title>_search@2x.png)
    • iPad spotlight @2x  (<title>_search@2x.png)
  • 76 x 76
    • iPad application  (<title>_ipad.png)
  • 60 x 60
    • iPhone notification @3x  (<title>_notify@3x.png)
  • 58 x 58
    • iPhone settings @2x  (<title>_settings@2x.png)
    • iPad settings @2x  (<title>_settings@2x.png)
  • 40×40
    • iPad spotlight  (<title>_search.png)
    • iPhone notification @2x  (<title>_notify@2x.png)
    • iPad notification @2x  (<title>_notify@2x.png)
  • 29 x 29
    • iPad settings  (<title>_settings.png)
  • 20 x 20
    • iPad notification  (<title>_notify.png)

Android App Icons

AndroidAndroid icon requirements had remained fairly consistent, but as of Android 8.0 (Oreo, API 26), those application icons are now classified as “legacy”, though still required for support on earlier devices (i.e., 85.4% of the market); the latest devices can use “adaptive” icons.  All applications should have a store icon.

For most Android apps, you should provide application icons in 6-8 resolutions (none of which overlap with the iOS resolutions).

Store Icon

Android apps, if they are to be published, require a store icon:

  • 512 x 512 – Google Play

Legacy Icons

To support devices running Android 7.1 (Nougat, API 25) and earlier, which you absolutely should, provide legacy icons in resolutions supporting 5 (or 6) different screen densities:

  • 192 x 192 – xxxhdpi
  • 144 x 144 – xxhdpi
  • 96 x 96 – xhdpi
  • 72 x 72 – hdpi
  • 48 x 48 – mdpi
  • 36 x 36 – ldpi (optional)

Note that some legacy icons can (technically) be omitted, but those sizes will be generated by the Android system from other sizes, and not necessarily the best resolution (i.e., a larger icon may be generated from a lower resolution icon, which looks poor).  Therefore, only the low density (ldpi) icon is considered optional; no modern devices are low density, and if one was it would necessarily generate the icon from a larger source.

Adaptive Icons

Adaptive icons were introduced in Android Oreo to allow the system to perform visual effects with the shape and/or contents of an application icon.  In order for this to be supported, adaptive icons need to be separated into foreground and background layers; the foreground contains the important content of the icon, toward the center, and the background is an image or color that may provide branding but could be clipped.

These are the components:

  • foreground – 108 x 108 image with transparency, icon content in center 72 x 72
  • background – color or 108 x 108 image to be composited with foreground

The foreground and background may be moved or sized independently before being composited together, and the resulting image will likely be cropped into an arbitrary shape; Android reserves an 18 pixel border for these kind of visual effects.

For more information, see this page about supporting adaptive icons.

Conclusion

For a mobile app to support all recent iOS and Android phones and tablets, you will need to create about 20 icons, in the resolutions above, including separate foreground and background layers for adaptive icon support.  If possible, start by creating an App Store icon (1024 x 1024) from a separate foreground and background.  Use that as a source icon to generate the smaller Google Play, iOS, and Android legacy icons, adjusting detail as necessary.  Finally, resize the foreground and background layers appropriately to generate the components for the adaptive icons.  (Then, take a deep breath.)

Now you are ready to implement your application. 😉  Of course, if you want to support Android TV, Apple TV, Android Wear, Apple Watch, Android Auto, and/or Apple CarPlay…

Happy Birthday, Demolish!

Demolish! Pairs celebrates one year since its launch on iOS.

One year ago today, Digital Gamecraft launched the original iOS version of Demolish! PairsDemolish! Pairs 1.11 is a challenging puzzle/arcade game for iPad and iPhone.

Demolish! Pairs 1.11 for iOSDownload and play Demolish! Pairs now!

Here are the top 5 reasons that you should get Demolish! Pairs:

  1. It is fun to play for gamers of all ages.
  2. It exercises your brain to help keep you mentally sharp.
  3. It provides relaxation during less interesting activities (such as watching Nigeria versus Iran in the World Cup).
  4. The programmer just got hit in the forehead by a fallen tree and could use any sympathy and support that he can get. [*]
  5. It is FREE (for one day only)!

As promised, to celebrate this anniversary, Demolish! Pairs 1.11 is completely free for TODAY ONLY.  There are no strings attached, though when you do take advantage of this special offer, it would be nice if you would rate and review it on the App Store.

Also, for those who already have the free-to-play version, Demolish! Pairs FTP 1.0.1, all in-app purchases are free for today only as well.

For more information on the game, please visit DemolishPairs.com.

[*] Medical Update: The injury was not at all serious, causing no extra brain damage. 🙂

 

Please… Download and Enjoy!Demolish! Pairs on the iOS App Store

Demolish! Pairs 1.11 for iOS

Another update to our challenging puzzle game is released.

Digital Gamecraft has published Demolish! Pairs 1.11 on the App Store, where you can buy it for only $3.99 (US). This is, of course, a free upgrade for all existing customers, downloadable from the ‘Updates’ tab on the App Store.

Demolish! Pairs 1.11 for iOSDownload and play Demolish! Pairs now!

Demolish! Pairs 1.11 is an upgrade that simply lowers the minimum version of iOS to 5.1.1, making it (again) playable on the original iPad. For more information on the game, please visit DemolishPairs.com.

Please… Download and Enjoy!Demolish! Pairs on the iOS App Store

Demolish! Pairs 1.10 for iOS

An update to our premier arcade/puzzle game is available.

Digital Gamecraft has published Demolish! Pairs 1.10 on the App Store, where you can buy it for only $3.99 (US).  This is, of course, a free upgrade for all existing customers, downloadable from the ‘Updates’ tab on the App Store.

Demolish! Pairs 1.10 for iOSDownload and play Demolish! Pairs now!

Demolish! Pairs 1.10 is an upgrade that updates the program interface for iOS 7.x and adds 64-bit support.  For more information on the game, please visit DemolishPairs.com.

While supplies last, readers of this Gamecraft blog may receive a code for a free copy of the game simply by sending an email request to marketing@digitalgamecraft.com.

Please… Download and Enjoy!Demolish! Pairs on the iOS App Store

FTP: Early Results

In a word: Inauspicious. 🙁

On Wednesday, Demolish! Pairs FTP was released on the App Store.  Here are the initial results for this launch, keeping in mind that, so far, it has been fairly low key to remain in line with the initial launch of Demolish! Pairs to allow a comparison between “paid” and “free-to-play” editions.

Day 0: partial day

The app was first available on the (US) App Store shortly after 5:00pm EST, and it became searchable/discoverable about a hour later.  Therefore, the results, which are reported around 7:00am the next morning, represent only a partial day.  I am not sure when a “day” actually ends in Apple-land, but I assume it is around midnight in the Pacific time zone (3:00am here), so this data probably represents about a third of a full day.  Also, this also means that the release only hit part of the globe in prime app time.

That last part proved particularly true, as all downloads for the first (partial) day were from only two countries, the United States and Mexico.  Interestingly, and disappointingly, when compared to first day sales of the “paid” edition (at $1.99 each), free downloads only exceeded this figure by ONE.  This is, of course, an apple and oranges comparison, but I still would have expected more downloads.

One primary reason for the low download count was the huge number of “free” releases every day (even relative to paid submissions), so while Demolish! Pairs FTP was on the category front pages, it was beyond the “fold”, so users would have to scroll right to even see the icon.  I also discovered that, unfairly, the free releases are not put in chronological order, but alphabetical order, so beginning with D put us off the visible part of the main page, and the poor bastards whose apps start with I through Z never have them appear on the front page at all.  This meant that, while the “paid” version had a couple of days visible on the main category page, the FTP edition never had that at all, and partway through day 1, it was swept off the page entirely by the next group of freebees.

Day 1: first full day

As stated, day 1 (Thursday) was the first full day of downloads, and things looked a little bit better.  The first indication, via hourly iAd updates, was that the number of countries requesting ads went up significantly throughout the day.  When the final results came in, there were downloads from 24 countries, which exactly matched the iAd country count (though, oddly, iAd also had a few “unknown” requests).

In sheer numbers, downloads for the second (first full) day were up 544%, which was more than double the expectations if day 0 were 8 hours (and downloads were level), so the trend is positive.  Also positive (I guess 🙂 ) is that the number of day 1 downloads exceeded total (lifetime) purchases of the “paid” version, which means that our free-to-play edition is now in more hands than the original (and, as iAd shows us, almost all of them have been played, not merely downloaded).

Now the Bad News: I have not mentioned IAP sales because, thus far, they equal precisely $0.00, so our game is being played more, but nobody has paid us anything.  Of course, some of the incentives may take a while to work, so I am not jumping to conclusions yet.  Not at all unrelated (as a causal factor) is the fact that iAd has received thousands of ad requests yet has served exactly 0 ads.  None.  Nada.  Not one.  I have lots of strong words and strong feelings about this, but I will compose them (and myself) in my next post.

Conclusion

It is actually far too early for any conclusions (except that the iAd 0.00% fill rate is a major problem), but the data is enough to decide to delay the next marketing step for at least one more day, to see what kind of falloff we get for a full day with Demolish! Pairs FTP not on the front pages of each category.  After that, experimentation continues!

For the scientifically-minded of you, please do not worry about skewing our data, and just download Demolish! Pairs FTP from the App Store already. 🙂

Demolish! Pairs FTP 1.0.1 for iPad

Our first “Free-to-Play” game is now available in the App Store.

Demolish! Pairs FTP, the free-to-play iPad version of Demolish! Pairs, our hit arcade/puzzle game, has now been released on the App Store.  Price: FREE

Demolish! Pairs 1.0.1 for iPad

Download and play Demolish! Pairs FTP here (no charge).

This version is our initial (and, perhaps, terminal) entry into the mobile free-to-play marketplace.  We would truly like to see this fun game in the hands of as many players as possible, and if we can recoup something for our efforts (on a simple game that took more than a dozen years, during which time half of the development team died), that would be nice, too.  Seriously, it is important to us to get this product as widely spread as possible for the integrity of the data/results, which I intend to (mostly) share on this blog.

Download and Enjoy…  and then please Rate and Review it on the App Store!

Charitable Results

Our late October promotion flopped.

While we wait for Demolish! Pairs FTP to be reviewed (currently on Day 8), I figured that I would write about some results we got with our tiny promotion that ended almost a week ago, attempting to earn some money to donate to the Juvenile Diabetes Research Foundation.  The basic numbers are based on tracking provided by Facebook, so perhaps we should start there.

(Cheap) Advertising on Facebook

Back in late August, as an inexpensive experiment, we decided to dabble in Facebook advertising.  At the time, our Digital Gamecraft page had an embarrassingly low number of ‘Likes’, all from people who I knew personally.  In order to increase this number, I clicked on ‘Promote Page‘ to suggest this page to other people.  In conjunction with this, we created a short 75% off sale for Demolish! Pairs, to provide brand new content (and a deal) for the page.

The results of this “campaign” were fairly decent, increasing our ‘Like’ count to more than 50 (from fewer than 20) in just a few of days, and for around $15.  The real benefit, though, turned out to be the availability of Facebook Insights once we passed 30 likes; this puts a figure for the number of people “Reached” on each post, giving an immediate idea of how well propagated your message becomes.  That initial post reached fewer people than had liked the page, but it gave me data to consider.

The next step was making a new post, warning that the sale was going to end in 3 days, and then, rather than continuing the page promotion, I instead clicked on ‘Boost Post‘ to advertise the sale directly.  This appeared to be more successful in terms of sales, and also brought a smattering of new followers as well.  The reach of that post was 5862 people (a 27814% increase from the previous post).

The first campaign, to increase the number of page followers, was successful in its goal, with the added benefit of providing more marketing data, but did not increase sales much.  The second campaign was more successful with sales, but not quite enough to overcome the decrease in income from the sale.  Still, it was a good amount of experimental information received for only about $25 total, with costs offset by the minor sales bump.

With improved copy, a better plan, and perhaps a somewhat more profitable price point, Facebook advertising could prove worthwhile (or, at least, break even).

Game Promotion for Charity

Armed with little more than Facebook data and good intentions, I decided to make the offer to donate $1000 to JDRF if our game could sell 350 copies in the last week of October.  The target sales number was chosen to be feasible, if the promotion caught on, and would amount to a donation of all proceeds, plus a small additional contribution from us.  In truth, I would (and probably should) have gone further to authorize the donation of all profits from the sales to charity, but I wanted to see how a target number might work.

To “promote” this offer, I (only) posted it at the end of this blog post, on the Digital Gamecraft Facebook page, and on the Digital Gamecraft Google+ page.  From my personal accounts, I liked/+1’d and shared both posts, and then sat back to watch.  Though my friend (and indie game developer), Gianfranco Berardi of GBGames, shared the post on Google+, I am only using the Facebook numbers and total sales figures.  (You will understand in a moment why this does not affect the results.)

The results were notable.  The impact of an offer for charity seems to bring in views, as the reach of that post, without any paid promotion, increased 385% from the previous non-sales post (and 1724% from the first sale post).  That was promising…  until the sales figures came in.  Despite the significantly increased reach, not only did we not meet our target figure, but there was no discernible change in sales at all.

The Bottom Line

It is going to take a lot of community building and experimentation, and probably quite a bit of luck, before we start figuring out marketing and social media, but this is a start.

Free-to-Play Take 1: Rejected

The first submission of Demolish! Pairs FTP was rejected by Apple.

As I mentioned in my last post, I decided to embrace the free-to-play concept fully (if perhaps halfheartedly).  Unfortunately, my first attempt for iOS did not result in reciprocation, as Apple reviewers rejected the IAP (In-App Purchase) products submitted with the product, Demolish! Pairs FTP.  (Alas, it took the product 8 days to get a review, which then lasted only 15 minutes before the rejection notice.)

I had designed what I thought was a well-balanced menu of (4) IAP products, ranging from a “Golden Ticket” at $3.99 (the current price of the “paid” game) down to an inexpensive “Two Day Pass“.  This last item ran afoul of a guideline I had overlooked:

Content subscriptions using IAP must last a minimum of 7 days and be
available to the user from all of their iOS devices

The inclusion of that product was intended to mimic a standard overnight video rental, which is a clearly established mechanism for viewing movies, instead applied to a downloadable video game.  I felt that the inclusion of a $0.99 item (subscription, in this case) was important to anchor the bottom end and provide a quick, low resistance, purchase option for the customer.  The economics also basically require that a product priced in such a manner be something of a standalone, since the gap between pricing tiers is 1 dollar US, so this lowest (non-free) tier does adequately fill the space between any two other tiers; the short subscription would have met the need quite nicely.

I accepted the decision (since I had completely missed this restriction in my earlier review of submission guidelines), but not without registering my thoughts on the matter:

I realize that you do not have the authority to overrule the cited guideline, but I personally feel that it is misguided and stifles innovation.  In particular, overnight rentals have been well-established in the video rental industry, and our “Two Day Pass” option was intended to be analogous.  Now we have no method to test the acceptability of this approach (to customers) under iOS.

Indeed, I do intend to experiment with this option under Android, if possible (and I will read payment guidelines with this in mind), since one major goal of this whole procedure is to learn what does and does not work in this arena.

Preparing a second submission

Clearly, Apple was not going to allow me to experiment with this idea (as is), and I was convinced that extending the subscription to 7 days would unbalance the design, as would increasing the price of what was, very deliberately, the most inexpensive choice.  Besides, the “Two Day Pass” idea was already engraved in button artwork. 🙂

Rather than taking a bat to my IAP product design and hoping it remained stable, or delaying release long enough for a redesign to accommodate a different low end option, I decided to simply remove the “Two Day Pass” entirely, initially offering only 3 IAP products for sale.  Although the anchor I wanted is no longer there, this whole exercise is somewhat experimental and, certainly, incomplete data now is better than complete data delayed (and, hence, no data in the interim).

It pained me, due to the many hours of design, implementation, and testing, but it was far easier to remove the option than to add it in the first place; the second submission of Demolish! Pairs FTP was completed on the same day as the initial rejection.

Planning for the future

The design for the free-to-play version of Demolish! Pairs already envisions several updates to the IAP system that were not (fully) implemented for the initial release.  A replacement for the inexpensive subscription product was just added to the list of features to be added in future upgrades, and an idea is already in the works.

With the removal of the fourth product button from the store page, the “hole” in that page looks even larger than it did previously.  However, the view actually contains (hidden) controls for some of the upcoming options, including the fourth product button, so the store will look progressively better as we roll out these features.  Of course, all of that is premised on the free-to-play edition actually registering on the income needle.

So, now we wait (again)…