Gem Hunt for iPhone now available on the AppStore

We are happy to announce that Gem Hunt has finally hit the appstore.

Gem Hunt for iPhone approved and available on December 14th

Good News Everyone!
Our new freemium color match game "Gem Hunt" is approved by Apple and will be available for iPhone and iPod touch next Tuesday, December 14th.

On December 15th (CET) Gem Hunt will be featured on DailyAppDream [1]

In Gem Hunt usually ads are shown which can be disabled via IAP. For everyone who downloads and runs Gem Hunt while being featured on DailyAppDream, ads will be disabled automatically.

PressKit

More Info about Gem Hunt as well as screenshots for press usage can be found in our new PressKit now available for download.

[1] For those of you who don't know DailyAppDream yet, it is a new program for free apps that allows free of charge promotion for developers. Their iphone app can be found here.

Going FREE while featured on the AppStore

Our game Into The Blue SD was surprisingly featured about two weeks ago. I couldn't believe my eyes when i opened up iTunes and saw the icon on the front page of the AppStore. A few hours later we decided to drop the price to $0.99 in order to get a maximum of sales and reach the highest rank possible.

One day before the feature in New and Noteworthy was about to run out, we decided to take a risk and make it FREE before the weekend.

Why oh why would you do that?

The game had been featured before. The last time our ranks and sales dropped to almost zero in a couple of weeks after the feature ran out. [We think this is due to the fact that Into The Blue is a quite "special" game that doesn't appeal to a wide range of users].

This time we didn't want to say goodbye to the upper ranks so easy. At least not without a fight. If the ranks/sales will drop soon anyway, why not getting the app more known and get some more buzz before going down?!

What we didn't know...

...was that after last Thursday we were still in the last slots of New and Noteworthy AND What's Hot. So the timing for going FREE was not that great after all.

The Positive Effects

• Going FREE while being featured last Thursday & Friday brought us around 30k free downloads and a way larger user base than we had before (~2k)
• Our customers who bought the former release could grab the new release for FREE (we want our customers to be happy)
• Media Buzz: lots of twitter messages, news posts, a review and few more covers and youtube videos
• Increased visibility due to reasonably high free app ranks (#58 free games, #6 free strategy games in U.S)

The Negative Effects

• Lost sales (since the game was still featured the next days)
• Ranks dropped quite a bit
• Bad ratings due to users who don't like the game/genre anyway

Lesson learned

it's hard to say what would have happened without going FREE. Most likely though we would have been able to keep our rank a bit longer and have a few more days with higher sales.

I conclude that going FREE either makes sense if the ranks are down anyway or if the app gets enough coverage (100k+) by being featured in one of the free-app programs. The latter would definitely increase the chance to get the ranks up again more easily after switching to paid.

But this is probably something that really depends on the game.

I looked up the ranks of about 10 games lately that were featured before by one of the major free app programs. The result was that only one of these games could increase sales/ranking after the free period. So it's probably more about getting a game known than getting more people to buy it.

Pricing

after reading the great post from Matt about pricing today i wanted to say a few words about our recent price changes as well.

Going on SALE for $0.99 definitely helped with the number of sales but i would estimate that it only increased by 15-20%. Making it $1.99 (the introduction price) would have been the more viable revenue option while being featured.

Going on SALE is possibly a question of going to the top or not. And by now we know that ITB is not a game that appeals to everyone - thus we probably could have stayed with the regular price tag ($2.99) and just enjoyed the ride while it lasts ;-)

In the last days we changed from $0.99 to $1.99 again and whilst we have about 25% less sales the revenue is higher.

Lite Version

we also released a lite version for Into The Blue SD a few days ago. Actually i'm not sure if having a LITE version out there does us any good. But more about this in a future post...

Suggested Reading

• Struct.ca - How to price your game
• Four Door Lemon - 99c problems
• Parade of Rain - Decoupling Ranking from Revenue
• Mundue - Pricing and Ranking, [part two]

Into The Blue (SD) FREE on Friday!

Now that Into The Blue is back in the AppStore and at the time of writing featured in "New and Noteworthy" we decided to make it FREE this Friday, Nov 12th.

Happy downloading everyone!

http://itunes.apple.com/us/app/into-the-blue-sd/id398897674?mt=8

Gem Hunt - our upcoming game for iPhone

I feel that it is finally time to introduce our upcoming game Gem Hunt to you. The idea to make this game came from a little free & casual marketing game called StuderusMatch we developed for a client of us this summer. StuderusMatch resulted in a fun little hiscore game and we really liked the mixture of physics and color matching. So we kept the idea in mind to make a similar game. One day...

The Palm Experience

A few weeks later we got word about the Palm PDK Hot Apps Contest. We decided to participate and chose to go back to the physics and color-match concept with the popular gem theme on top. So we went ahead and put together a playable version in about 2 weeks time. Unfortunately we started about 4 weeks late and the contest was already running. There were multiple prize sections depending on the number of sales. Since all slots in the paid section were taken we participated in the free section.

Being new to the platform and late in the contest we weren't able to win a big prize in the contest. But we still got rank #34 or so with about 15.000 free downloads.

It wasn't quite enough for the 10k$ prize but it showed us that the game had potential and that there are users who like it.

Since we like the game ourselves we thought that it might be great to have this game available for iOS too and started the work about 2 weeks ago. Now we are spinning to take the game further and polish it to make it even better.

The following image shows the game how it is right now. The graphics will probably change until release...

Gameplay

So what do you do in this game? It's quite simple. You have 60 seconds to beat the hiscore. In this time you direct gems in a billiard-like manner. Two gems of the same type match and disappear from the screen. If you match the same color a few times in a row, you are able to score more points. We'll also add more game features and possibly also alternative modes in the next weeks. Some of the features will be available in an IAP shop whilst others will be available to start with. I will write more about the game and features in the next blog posts.

Beta-Testing

Although we haven't really started beta testing, it would be great to get some feedback on the game early. If you like to give it a go let me know on twitter. Thanks!

Into The Blue (SD) Re-Released

After a few weeks of being offline, our game Into The Blue is now back in the AppStore!

We recently moved from a company to a common developer account. Unfortunately in this situation apple's system doesn't support moving applications across just yet. That's why we had to pull Into The Blue from the store and resubmit it using the new account.

SD vs. HD

Why is it named SD now? Simply because we weren't able to submit the game with the same name since the old version is appearently still in apple's system. Also chances are good that after we have finished working on our current project Gem Hunt (will blog about it soon) we'll find time for an HD version for Into The Blue.

While we had to resubmit anyway, we now added PlayHaven support to it and updated OpenFeint. We'll be also looking into releasing the LITE version soon with the new account.

Latest Proceedings: JSPortal.app, gh-unit and drilldown UIPickerView

Todays post is a about where i'm at with my current iPhone project and what i've been up to tech-wise.

My current project: JSPortal(.app)
I'm currently working on an iPhone App for a friend's WebApp called JSPortal.
I don't want to go into too much detail in this post but let me at least tell you that it is a quite cool time- and budget tracking software. It's also free of charge for up to 3 users. If you are looking for something to keep track of your development projects you should check it out.
Joost did a great job in providing a demo mode that let's you demo the WebApp right away. No signup, no email verification. Peace of mind.
The first version of the iPhone App is going to help JSPortal's users assigning work time to projects.
Since last week i made a lot of progress and hope i can finish it in time. This would be the 29th of October. Let's see if i can make it.


Unit Testing with gh-unit
Back in my Java days i wrote a lot of automated unit tests with JUnit. Since i started making my first iPhone game i've become a bit somewhat slack and didn't do much testing. Last week i finally started looking into testing again. At first i looked into OCUnit which i understand is shipped with XCode. It runs the tests during the build and you can see the results in the build view. I see that running them together with the build has its advantages. Such as having your build simply fail when there are tests not running. But here's the thing, i'm a very graphics oriented person and i only want to look into my tests when i'm running them. I want to see green and red bars. That's it. The gh-unit project runs its tests seperately from the build. The iPhone version of gh-unit runs the tests within an own iPhone AppDelegate which gives you also the opportunity to test aspects of your view as well. The only issue is that it also misses my beloved green and red bars. So i went a head and forked the gh-unit project and implemented them.
I feel that the table-view with these rather big bars and labels works well for a limited number of tests. For bigger projects smaller rows might be better. I can also see a custom view with lots of little squares for each test-method. That way you might not see which method in detail failed but you'll have a better overview over which suites/classes passed.


Drilldown UIPickerView Component
I still consider myself more of a freshman in the UIKit area but i also feel like my understanding is growing a bit every day i work with it. Today i was able to create a UIPickerView component that supports nested elements. It has some really hacky bits in it (the code, not the view) but it works well. It is also reusable because it gets its row items from a delegate. If someone is interested in the sourcecode, let me know.

Getting better at XCode

Yesterday i felt it was time to revisit the way i use XCode (3.2.4) and see if i can find some useful functionality that i can use more often. I also had a look at shortcuts and either created some that were missing or changed the ones that are hard to remember or simply hard to use for my taste.
Update: added sections Warnings, Split-Screen Editing, -(id) init {... and Recommended Reading [10/14/10]

File > Open Quickly... ⇧⌘D
This is probably the coolest feature i just haven't used yet. Instead of looking in the sidebar for your file and eventually clicking it, Open Quickly... opens up a little dialog window and shows matching files or methods as you type. I also realized that it captures your currently selected text.


Edit > Refactor... [1]






I used the Refactor > Rename functionality occasionally but always had the impression that i'm waiting longer for it to finish as i would need changing the names by hand. But if you uncheck the Snapshot option it's actually quite fast so there's no excuse not to use it. I'm also going to use at least the option Extract from now on to extract lines of code to a new method if it makes sense.
Note: Please uncheck the Snapshot option at your own risk.

Edit > Completion List [2]
I probably never used this function a lot because my fingers aren't used to use any shortcuts containing Escape. I always used Next Completion instead but sometimes you aren't even sure about the first letter the function you need starts with so that's where Completion List is for.

Edit > Format > Re-Indent [3]
I realized that i'm re-indenting a lot by hand by throwing tabs and spaces at lines. This is stupid. Re-Indent can be used on a selection or on the current line. It also seems that ^I triggers Indent-Line.

Build > Clean ⇧⌘K
I actually never used this before... ok just kidding - but i always used the mouse to do this. The shortcut isn't that hard so i'll try to use that from now on.

Build > Build and Analyze ⇧⌘A

This is a somewhat useful thing to check on your alloc-fu. The clang analyzer will go through your code and will notice for instance that you don't release that object you created without autorelease.
There's also a target setting called "Run Static Analyzer" to run analyze automatically. Although it's a great way to keep writing alloc-sane code it slows down build time which is why i turned it off again.
Note: as suggested here i had to add -D__IPHONE_OS_VERSION_MIN_REQUIRED=040100
to Other-C-Flags in my project settings so that the analyzer works with my current XCode settings. Might be a specific problem related to 3.2.4.


Help > Quickhelp [4]
Wow i really feel stupid not to have used this function before. For example if you select a method name and execute Quickhelp it will show you a little help window with some documentation if available.

iPhone Simulator Window Scale Shortcuts
To change the iPhone Simulator's window size it seems you have to do it with the mouse curson in the menubar since there's no shortcut for it. I had a look at the XCode shortcuts but didn't find any setting for this.

So my solution was to create a shortcut under System Preferences > Keyboard.
Simply add an Application Shortcut for 50% and 100% and you are done.

Warnings
in the past weeks i noticed that i tend to care more about warnings. If you want to always see your warnings (they usually hide after you run the build a second time) just switch to the tab "All Results" in the "Build Results" Window.

Split-Screen Editing
Today i found out in the article mentioned below how to edit multiple files in one window.
There are two little icons on the right edge of the window above the scrollbar to add another window vertically or horizontally.

- (id) init { ...
If you are as lazy as i am and you didn't put a default init macro in your obj-c template file you can also insert a full init statement manually by using Edit > Insert Text Macro > Objective-C > init Definition. Shortcuts can be added via XCode Preferences.

Recommended Reading:
14 Essential Xcode Tips, Tricks and Resources for iPhone Devs by Dan Grigsby

[1] I assigned the shortcut ^R to it since i'm not going to use whatever ^R is usually doing.
[2] I assigned ^SPACE to it since that is close to the shortcut i know from eclipse.
[3] I assigned ⌥⌘I for this.
[4] I didn't like the shortcut and now assigned ^H to it.

Using UITableViewController #1: Swipe to Delete

This article among other articles about iOS development can be found on my new blog.

this is just a quick tutorial for those like me who didn't implement this before. Luckily this is one of the nice UI features that can be implemented without much hassle.

You only have to do a few things to get this working.

1) Tell your UITableViewDelegate that your rows have a delete editing style:

- (UITableViewCellEditingStyle) tableView:(UITableView*)tableView editingStyleForRowAtIndexPath:(NSIndexPath*)indexPath {
return UITableViewCellEditingStyleDelete;
}

2) Implement commitEditingStyle: in your UITableViewDataSource. In order to get the delete button displayed it is enough to just have the function implemented without doing anything:

- (void)tableView:(UITableView*)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath*)indexPath {
// delete your data for this row from here
}

3) Now if you actually want to delete that row visually you have to add more to commitEditingStyle. And before you do that visual delete, you have to change your data beforehand so that
numberOfRowsInSection: returns less rows than before:

- (NSInteger)tableView:(UITableView*)aTableView numberOfRowsInSection:(NSInteger)section {
return numRows;
}

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath*)indexPath {
numRows--;
[self.tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
}

And that's it!

Simple but nice

Todays post tells a story that follows the lead of the last post on my path to more simplicity in the games i create.

The Story
Once a year or so i meet with a friend in the evening and do some painting. Everytime i paint, i try to paint something with a lot of detail. Usually the result is mediocre. The detail i want to achieve doesn't come out right or i don't have enough time/patience to finish it. In the end i'm just unhappy and have the feeling that i wasted my time. (It takes about a year to recover from this evening and try again.)

Yesterday i bought some ultra widescreen canvases with my girlfriend and instead of going for something detailed again i chose to just paint something simple but nice.

I love gradients so i chose to stick to that and imagined just horizontal stripes in black, a blue gradient, black again and red/orangy gradients.
Since i try to be a good indie citizen i started with a prototype.
I painted the gradients quickly on A5 format to see if i would actually like it. And i did. I asked myself if i should make another prototype which is even better but in the end of the evening i wanted to have a finished painting - not just prototypes. So i went ahead and painted the canvas and was finished by end of the evening. And here it is:






The Result

I must say i'm really pleased with the results. Probably because A) i'm not an artist and B) my former paintings were crap . What strikes me is that even though i worked fewer hours on it - and it doesn't have the complexity of my former paintings - it has much more to it. Let me stress that i'm not saying "this is an amazing painting" - i just say that i finished something in the time i had and i'm happy with the results and especially with the process of painting something i like in one evening.

Walter: “The beauty of this is its simplicity."

Conclusion

Painting is not game design. They are two different things and can't be compared that easily. But if i would draw the line to game design, i experienced a lot of the benefits i discussed in my earlier blog post. Due to the simplicity of the idea i could prototype it quickly and then execute it in the time i had. I even had plenty of time in the end to fix and polish a few things.
If my painting was an iPhone app, i probably would give it away for free since it is a bit too simplistic. But in the end i achieved something and feel that it is easier to build on top of that experience to make something slightly more complex next time.

To end this post i'd like to add a quote from an interview with Adam Saltsman i read a few days ago since i feel it fits well to this (and the last) post:

What do you contribute to your success as an independent game developer and what advice do you have for others who want to live the dream?
Make small games! Make little polished demos or prototypes and share them with everybody. This is not necessarily the route to financial success but in my experience it is the best and fastest way to learn how to design games. I’ve made maybe a dozen or so 1-week games and I’m just beginning to feel really comfortable with my design process.

Why developing smaller games is great

A few days ago I read about "Size Doesn’t Matter" in the #idevblogaday blog roll. Since i feel infected by the idea of small scope games at the moment i'd like to share my thoughts on why it can be a great catch for indie developers - especially newcomers like me. This is my first article on indie (iPhone) game development so please bear with me here ;-).




















We all know that developing small games usually takes less time than bigger ones and that there are plenty games out there that work great with just little scope. I asked myself what benefits there actually are to develop smaller games.
This is what i came up with:

1. Be more creative and have more fun creating games.
   If you have worked on a lengthy title before, you know what i mean, it just gets less fun the longer you work on it. With smaller games you still have to do your polish work but you'll be working on the next title or prototype sooner than later.
   
   
2. Release more.
   Releasing a new title brings that great feeling with it. You put it out there, people are playing it and you get some feedback for you work and feel that you accomplished something. Working on small titles willl give you that feeling more often because you'll just release more often.
   
   
3. Quicker Prototyping.
   This might not be true for every concept but usually if you have a smaller game you should be able to prototype it quicker because there are less questions that need be answered.
   
   
4. Good for your wallet.
   Since it takes less time to create that game you can keep the costs low. Less designer work, less sound work or purchases, less development, less testing, less concept work, less changes, less ...
   
   
5. Better Cross-Promotion.
   By having more but smaller titles you have more power to cross promote your own games
   and have one of your games free for a while. In my opinion NimbleBit shows this in perfection.
   
   
6. Faster Feedback.
   If you are a newcomer or new to a certain game genre it's good to get some feedback if you are on the right track. My first title took 5 months to release and all that happened was that i learned about 4 months too late what went right and what wrong. Although the game turned out well, the time i spent on the game didn't get into my pockets just yet. After all i rather would have created two or even three games in that time.
   
   
7. Day-Job Compatibility.
   Another reason for smaller games is that it works better with your dayjob. With a bigger project you might get into a state where you just feel it's dragging on and will probably never finish. And you might be right, you might just not have the time or patience to finish it. Think smaller.
   
   
8. Make it shiny.
   With less content that needs to be in the game you'll have more time (and patience) to polish your game and make it a better user experience as you would be able to working on a larger game.
   
   
9. Easier to grasp.
   By having a smaller game with less content you're likely to have less that needs explaining. The game will be easier to grasp and might not need any explanation at all.
   
   
10. Better for your nerves.
    Since you have a smaller scope, there's less to worry about and your game has should have less bugs. Also it might be easier to test. Less testing and bugfixing is not only time-saving, it also doesn't interfere as much with the work you actually wanted to get done and leaves you in a happier state of mind.
    
    

Despite all the advantages of smaller games i still don't think it's that easy to make a well working game with just little content. If the idea isn't good enough it won't stand all that cutting away of features. In the end it might just miss that extra mode or a bunch of levels to make it work.