gregh's blog

Marketing Post-Mortem, Operation: Eradicate

Following up on the Development Post-Mortem I wrote for our new iOS game, I wanted to give a quick look into how our marketing push was planned and how the first few weeks of sales went.

Though I am a coder first, I have many spare cycles in my brain to approach the business side of things, and I knew I didn't want to neglect the marketing and promotion side of the app. A failure to launch is many times cited as a source of frustration of independent developers and I wanted to give my new game a fair shot at success.

We finished up the game the first week of February, and it was submitted on Feb. 15th to Apple. We were hoping to launch the app before GDC since we didn't want to compete with GDC news and events. At this point, I was a bit worried that it would linger in the Apple review pipeline for too long, and I would have to postpone the launch until mid-March. Gladly, the game was approved on Feb 20 and we scheduled the launch for the next Sunday, Feb 26th.

Now that you have a basic timeline, I want to break down our efforts into two segments:
Pre-Approval, the time between App submission and approval.
Pre-Launch, the time between App approval and the release data.


During the Pre-Approval timeframe, which lasted only a week for us, we had two goals: prepare all the needed marketing material, and contact our high-target sites. During this week we created our promo trailer setup our website, started gathering emails for a LaunchRock promotion (more on that below), a few other presentation items.

Over the course of the last few months, I had gathered a large list of sites to contact, and from that list I selected 10 main sites that I wanted to write about us. I wrote a short 'new studio' type email, with links to the trailer, our website, and we offered a sneak peak through Testflight (since we couldn't give out promo codes yet).

One article was written by and a few others expressed interest. Really I was just hoping to set the table to the release announcement, so I wasn't discourage that we had only one hit at this point.


When Apple approved our app, we entered our Pre Launch phase, which was a bunch more work. Even though our release date was 6 days into the future, Promo codes still work once the game has been approved by Apple. So I templates and sent out at least 75 emails to game and app review sites offering promo codes for an early look at the game. I focused the email on the release data, included a few screen shots and links to the app on iTunes and to our trailer. I also offered to a few of the larger sites a sneak peak to our Press Release since the feel of an exclusive might get the wheel turning.

About 30 different sites or writers got back to me with interest, and I distributed 35 promo codes to writers leading up to and right after the launch.

This effort resulted in three decent sites,, and, writing Preview articles. All three would then write Release or Review articles in the days following the release of the game. In the 10 days after launch 6 more articles were written about the game, including and, and two from Board Game specific sites, which is the genre of the game (Board and Strategy categories in the App Store).

So as far as effort, 75 emails resulted in about 30 people asking for promo codes, and about 12 or more articles written about us. We issued over 35 promo codes to writers/sites, and only about 20 of them were ever used. Most of those codes were given to people who expressed direct interest in the game as opposed to the fill out this form and add a promo code type interactions. This effort alone probably totaled to over 2 full days of work on my part.

A word of warning: Don't get excited about 'interest' or even 'commitments' to write, only about actual articles. About half of 'enthusiastic' writers never wrote an article, and two higher profile sites wrote 8-10 days after launch, and one firm 'we will write about you' never happened.

Press Releases

The other main item of effort was the writing and posting of the press release. We posted the release in two different places ( and, scheduled it to go out at 3am EST the day of our release (Press Release text).

We felt the press release was part of our multi-pronged approach. They are a low cost way to spread the word to hundreds of sites and writers at one time and shouldn't be neglected.

Giveaways and Promotions

We ran two free game promotions, one for Twitter Followers and one for Facebook fans. Since this is our first game, we decided to only have studio accounts instead of game specific accounts. This way we can increase the followers and fans for the studio which hopefully will be leveraged for later games and updates.

We decided to give 5 free games to five random Twitter followers, and 5 free games to Facebook fans. For Facebook, all they had to do was Like our Skejo Studios Facebook page. We purchased a couple days worth of targeted ads on Facebook which gathered about 100 likes, and cost under $50.

Not sure exactly what the impact was from these giveaways besides increasing our Fans and Followers a bit, but for the cost of $20 worth of free games, and very little actual time, it felt worth it.

Quick Timeline:
2/15 Submitted app to Apple
2/17-2/19 Contact High Profile sites for Preview or Studio Spotlight
2/20 App Approved
2/21-2/25 Starting email campaign, announced Follower and Fan free giveaway, and posted trailers to Youtube
2/26 Issued Press Releases very early in the morning, then started checking the charts


But the true impact needs to be measured in sales and app position. We moved steadily up the iPad Board and Strategy rankings until on Monday morning we hit the #4 and #5 spots on those boards. Very satisfying. Of course we have since fallen to around 80 or 100 on those charts, but we are releasing a Retina graphics update for the new iPad and will probably do another promotional push after it is approved.
#4 iPad Strategy Game
#5 iPad Board Game

Here is a quick sales chart. The exact legend is removed, but for scale the tail is a shade under 50.

Quick Summaries

Here are some quick summaries of the efforts we pursued.

LaunchRock: Set up Launching Soon page in minutes. They allow you to setup an email capture form, that is nicely wrapped. Then they help those who have signed up to spread the world virally through email, twitter, Facebook and other social avenues. Works best if you can give early access or other tangible benefits to the people who are referring to your sign up.

Cost: FREE
Impact: 23 Signups, only 6 referrals, about half were people I knew and would have contacted anyway. A waste of time.
Avenues of improvement: Start the signup earlier. Find a more viral message, or a better award for the top referrers.

PRMac: Most of the multi purpose app review sites repost press releases. You will also get 10-20 emails from paid app review sites asking if you want to pay $50-$125 for 'featured reviews'. All of those were ignored.
Cost: $19
Impact: Was sent to 700+ contacts, and viewed 11000+ times according to PRMac. According to Google, over 30 sites have reposted the press release, including and other large general purpose iOS review sites. About five reviewers approached us for promo codes because of PRMac. I don't think any actually wrote. Press Release Service
The community site has a members only system that allows you to post one press release a month, along with member only forums.
Cost: Either $150 for full membership, or $15 a month for 12 months. One Press Release per month included.
Impact: Press Released uploaded to, which resulted in reposting by Not sure exactly beyond that.

Development Diaries: I posted about 12 development diaries along the 17 weeks of development. All were later cross posted to Gamasutra where a few of them were Featured.
Cost: Lots of time writing
Impact: Hard to know, if any. I pointed to the dev posts in the review solicitations, but don't know if that had any impact on reviews being written. At least provided some back history to both the project and the new studio.

Forums: No outreach was done at all in any forums. I did check some major sites after launch and replied to a few threads that popped up, but I it was only reactionary on my part.
Cost: Free
Impact: Hard to measure, gives the perception of engagement.

Other Tools

Promoter is a great service that scours over 1000 gaming websites for mentions and reviews of your game (load it with a few specific keywords to look for like your studio name or game title). An example, the public reviews for Operation: Eradicate.

Cost: Free for one app, 12 Euros a month, or 99 a year., used for tracking apps sales. Breaks down country sales.

This wraps up a wandering guide into our marketing efforts. After a few more weeks of sales and pricing adjustments, I will write about how 'successful' the game has been for us, both in regards to the raw sales numbers, and from the studio perspective of laying a foundation for future success. So far, it looks solidly in the middle of my expectations, have already passed the cash expenditures break even point, and is forecasted to probably hit the 'time and effort' break even point. If our first game out the gate breaks even, I will be happy, and we have plenty of new stuff brewing that I hope has much more potential.

Operation: Eradicate Post Mortem

For four or the five months, I have been working on Operation: Eradicate, an iOS turn based strategy game. With my graphics designer, we at Skejo Studios have revisited the last few months, and wanted to write about the highs and lows, and lessons learned for next time.

First I wanted to start with our initial hoped for timeline:

Initial Timeline

* Sept 2011 - Start
* Oct 2011 - Code fleshed out and Art assets started, first round done
* Nov 2011 - Dev and art near finish, start beta testing
* Dec 2011 - Wrap up loose ends, ship by Christmas

What really happened

* Oct 2011 - Started full-time on the first project with part time UI graphics guy, and contract artist
* Late Oct - Basic gameplay with dev art done, still hoping for Xmas release. Yeah right!
* Late Oct - First hard-drawn art assets issued
* Early Nov - Save/resume games implemented, iOS 5 turn based games (a selling point, to Apple more than anyone).
* Late Nov - Wife got a new job, moved new city little dev done. Art still slowly making progress.
* Early Dec - Final non-colorized artwork done. We were advised the game needed a full event driven tutorial to on-ramp players to game. Ugh! - Moved goal for launch to end of Jan.
* Late Dec - All game mechanics done, first beta test sent out to 5 players.
* Mid Jan - Many UI redesigns occur, plus tons of polishing adjustments.
* Late Jan - Finalized, full color artwork delivered. Pushed launch to Feb. Another round of play testing, polishing, tweaking.
* Early Feb more weeks of polishing.
* Submitted to Apple, Tuesday Feb 14.
* Approved by Apple, Mon Feb 20 (on my birthday)!!! Massive Marketing push ensues.
* Released set for Sunday Feb 26 (to get in front of GDC)

I will also be writing a Marketing Post Mortem to trace and dissect the good, bad and lessons learned from the launch.

The first lessons we learned is to be flexible with due dates, but still have them in place. As I was the only full time person, I was pushing hard because I could, but it is difficult to push part time contractors to speed up. I now will factor in slips in the timeline for artists. But even missed deadlines serve the function of putting a mark on the calendar and pushing for it. Motivation sometimes can be lacking, and that date keep things in focus. Just don't use missed deadlines as a source of depression, just learn to estimate better. Deadlines also help you look back and realize how much you did get done before that date passed.

Deadline Tip we learned

One way to help contractors (of any stripe, not just artists) create deadlines they will really try to hit, is to incentivize the deadline. Maybe add a 5% bonus for each delivery deadline hit, or maybe a lump bonus if 75% of delivery deadlines were hit. This will help them suggest dates they can hit, and gives them reason to hit them more accurately.

What Went Wrong

As already mentioned, this was my first time working so closely with artists directly, and a few false starts, and all deadlines missed made me realize I was working with people different that me (an analytical engineering type). We are all different minds, and that is all good. For me, I felt the artist delivered more than I asked for, but took longer than I wanted. But how do you direct them to do less to hit the deadline, when they are working on hand drawn artwork. Especially when the artist insists that he won't charge. Again, this is where the incentivized deadlines can come in handy

The other deadline item is setting realistic timelines for part time contributors. Rarely did their contributions come in smooth, predictable chucks. More likely they came in spurts, sometimes unpredictable. We will keep that in mind on our next projects, and as we develop updates for this game.

The last huge mistake is that we didn't add a zoom to the playing map for iPhones and iPod Touches. During one UI redesign, we took it out, and none of our play testers complained so we thought we were good. Except all of our play testers were experienced gamers, and had used the controls so much they didn't notice (or didn't report) issues with the map on smaller devices.

But we were nailed in the reviews w/ numerous 1 star reviews, and many emails asking for a zoom to be added. Thankfully we already had the code generally working, so it only took a couple hours to get an update to our testers, and wrapped up a submission to Apple in two days (numerous other typos, small fixes and enlargement of other buttons included).

Two things we learned from this issue is to specifically ask the impressions of a change you make if you are using the same testes. Them not reporting that the disliked a change, doesn't mean they liked it, just that they didn't report it. Second, use more new testers each time you have a test release. Otherwise they might be too familiar with the and attuned to the rough spot, thus not reporting them.

What we did right

We allowed enough time for UI rework. We didn't kid ourselves into thinking that we were going to get it all right the first time. I worked on a first pass developer UI just to get the game to a playable state. This I pushed to the UI designer while I worked on other behind the scene stuff like turn based games, Game Center integrations and other items. Then I implemented his design and we through it to some testers. Their feedback, and more time to imagine gave the designer more inspiration, which eventually lead to a good interface.

You can see the map and UI progressions here:

Some Quick Lessons Learned

* Send stuff to publishers. They may reject you, say mean things about your progress, but they might also give you hints on how to improve. They did for us.
* Fix bugs/broken stuff when you see it, don't add toa todo list. Fix it NOW!
* Biting off too much is very easy to do!

Don't Listen to these Fears

Fear 1: What will other people think of it? Maybe I will wait until I get more done.

No, the earlier you get feedback the better. Test users and honest feedback gets you off wrong paths and deadens, and spot glaring issues sooner. Polish added to a feature you remove later is a waste of time. Don't polish anything until you know you have nothing more to cut out.

Fear 2: We are done, but I don't want to send the game to reviewers because they might be critical.

If you think your game doesn't blow away the competition, or that the reviewers will hate it, then why did you make the game? If you aren't proud of it, send it back for more polish or rework. If you are proud of it, send it out, get as much talk about your game. Anything is better than silence. This last point is more for a marketing post-mortem, but it felt like it fit here.

Quick Facts

  • Web site:
  • Release date: February 26th, 2012 (iPad and iPhone/iPod touch)
  • Development time: 4 months
  • Team size: 1 full time, 1 part time, 1 contractor part time
  • Development cost: Cost of living for 4 months + about $2500 (art, marketing, resources)
  • Open source code: Cocos2d, Box2d
  • Primary tools: Xcode, git, SpriteHelper
  • Raw asset size: 391 MB
  • Total app size: 13.9 MB
  • Coffee Consumed: 500+ shots of espresso

Finally, we do have the first week's worth of sales data, and we must have done a few things right. We landed in the #4 iPad Strategy spot and the #5 iPad Board game spot at launch. We didn't write down targets for launch, but this would have exceed anything we would have written.


What is coming next for Skejo Studios?

Vertical Scrolling story telling platformer, to be official announced shortly.
With a side scrolling indirect platformer using same artwork/world/back story.
Very high concept resource management, mini-game, character advancement game.

Operation: Eradicate on iTunes.

Comment below, or with Twitter,


Eradicate Week 17: App Submission and Pre-Marketing

Short update as I prepare a much larger game dev post-mortem. But I am very glad to say that we have submitted our game binary into the Apple review pipeline. Now it is just a matter of waiting, and then we can schedule the release and marketing.

The other item that was created our teaser trailer for the game. Not even a demo, but it does highlight some of the artwork. Check it out.

Also, keep checking our Facebook Skejo Studios page, or follow us on Twitter.

Eradicate Week 16: Game Map/UI Progression

This update is more a gallery of snapshots than anything else. I think it is always instructive to our team, and other developers to see the progression of layout/design/game play. So without any further commentary, here is the progression of our main game surface from first prototype to near shipping screenshot. (one more will be added later, for the final shipped version).

Eradicate Week 15: Loadscreens and Beta Testing

We have been working hard at Skejo Studios pulling together all the loose ends as far as sounds effects, artwork, Game Center integration and QA/Beta testing our game, Operation: Eradicate.

I am super glad to announce that the load/menu screen is now completed by the artist and has been crafted into the game, as seen below.

Eradicate Week 13: The Art. Coming Together

This update is more to be seen than read. Half our main character assets have been fully colored, with the rest due next week.

Click to see the full versions, it is worth it.

Eradicate Week 12: New Menus and Messages

For this week's update on our Eradicate iPad game at Skejo Studios, I wanted show a bit of the direction we are head with the art assets.

First we have received an initial scan of a possible load screen. We might mess with it a bit, cropping or framing it, but it is done. The example below also shows the improved game setup screen where you can cycle through the commanders photos, instead of just their names. Colorized version of all assets will be delivered shortly.

Eradicate Week 11: Event Drive Tutorial

Seems I am more on a every two weeks update schedule, than even every Friday, but it will have to do. I am so excited for the direction of the game that I just keep working on it, instead of writing about it.

First, the main hand-drawn art work, by Anthony Moss at Magus Studio,, has been completed and scanned. He will start coloring them after Christmas.

But the main topic today is that Operation: Eradicate needs an event drive tutorial to help people get into the game faster. I was in a brief conversation with a gentleman at a larger mobile game publisher who noted that even if the game play is solid (which we are sure it is), and the art is improved (which we know about and are in the works to update), he advised that a video tutorial would not be enough to on-ramp players into the game.

The One Day Help System, in Cocos2d for iOS

Since we are developing a strategy game for the iPad/iPhone at Skejo Studios, we were in need of an in game help system to quickly tutor the player with the different controls and game options. We had been putting off this mechanism for a while, since it was figured it might take a while, but surprisingly it was rather easy in Cocos2d to accomplish.

Game Layer Code

I am assuming you know how to add the correct definitions and import class headers, so I am not showing that part. Placing the below code in your init method for the Cocos2d scene or layer setups up the layer to receive touches (though I assume almost any game is receiving touches already) and adds the help layer (blank for now).

-(id) init
	if( (self=[super init])) {

        //Setup delagate for processing touches
        [[CCTouchDispatcher sharedDispatcher] addTargetedDelegate:self priority:-1 swallowsTouches:YES];

    helpSystemOn = NO;
    helpLayer = [HelpLayer  node];   
    [helpLayer setGamePlayLayer: self]; //Only needed if you need to know something from your gaming layer.
    [playingLayer addChild:helpLayer z:10];


To accept the touches, you need at least the ccTouchBegan method (required for the CCTouchDispatch call):

#pragma mark Touch Processing

-(BOOL) ccTouchBegan:(UITouch*)touch withEvent:(UIEvent *)event
    CGPoint touchLocation = [self convertTouchToNodeSpace:touch];

    if (receivingTouches == YES) {
        [self selectSpriteForTouch:touchLocation];
        return YES;
    } else if (helpSystemOn == YES) {
        [self selectSpriteForHelp:touchLocation];
        return YES;

    } else {
        return NO;

- (BOOL)selectSpriteForHelp:(CGPoint)touchLocation {
    BOOL processedTouch = NO;
    processedTouch = [helpLayer processTouch: touchLocation];
    return processedTouch;


In our game, we don't always want to be receiving touches, so we have a receivingTouches flag that we check for. If so, then we forward the touch to the correct method. We now added the check for the Help System by checking for the helpSystemOn flag and forward to the selectSpriteForHelp method which simple passes the touch to the HelpClass instance.

NOTE: The 'processedTouch' return value is use if you have multiple TouchDispatchers going at once. They will be queried in order of priority until a dispatcher returns a TRUE value.

Before moving on to the HelpLayer class, we need to add the toggle switch for the help system. Normally such a toggle should be placed with other high level game controls like 'End Turn', 'Return to Menu' or 'Restart Turn' buttons. We added the showInfo menu button with the other buttons and assign it the showInfoPressed method when pressed.

- (void) addGameControls {
	...  //Other menu items.
	CCMenuItem *showInfo = [[CCMenuItemImage 
                              itemFromNormalImage:@"info.png" selectedImage:@"info_pressed.png" 
                              target:self selector:@selector(showInfoPressed:)];
    showInfo.position = ccp(60, 300);
    CCMenu *controlsMenu = [CCMenu menuWithItems:pauseGameItem, showManual, restartTurn, showInfo, endTurn, nil];
    //Place in upper left corner
    [controlsMenu alignItemsHorizontallyWithPadding:10.0];
    controlsMenu.position = ccp(10, 700);
    [self addChild:controlsMenu z:10];


-(void) showInfoPressed: (CCMenuItemFont*)itemPassedIn {
    if (helpSystemOn == YES) {
        //Turning Off
        helpSystemOn = NO;
        [self rebuildActions]; //Used to re-enable action menu    
	} else {
        //Turning On
        [self cancelMoves]; //Used to disable any current actions
        [self rebuildActionsWithBlanks]; //Used to disable the action menu
        helpSystemOn = YES;
    [helpLayer toggleHelp];

Any appropriate measures should be taken so that the game is essentially paused when the information system is on. We did this by disabling the action menu and canceling any in-progress moves.

So that is all the code that is needed inside the game play class, now we need to move to the HelpLayer class.

HelpLayer Class

//  HelpLayer.h
//  Created by Greg Holsclaw on 12/12/11.
//  Skejo Studios,

#import "cocos2d.h"
#import "GamePlayLayer.h"
#import "Constants.h"

@class GamePlayLayer;

@interface HelpLayer : CCLayer {
    CCLayer *infoLayer;
    GamePlayLayer *gameLayer;

@property (nonatomic, strong) CCLayer *infoLayer;

- (void) toggleHelp;
- (BOOL) processTouch: (CGPoint)touchLocation;
- (void) setGamePlayLayer: (GamePlayLayer*) gamePlay;

//  HelpLayer.m
//  Created by Greg Holsclaw on 12/12/11.
//  Skejo Studios,

#import "HelpLayer.h"

@implementation HelpLayer
@synthesize infoLayer;

- (id) init
    self = [super init];
    if (self != nil)
        infoLayer = [CCLayer node];
        CCSprite *helpBG = [CCSprite spriteWithFile:@"overlay-70.png"]; //A 1x1 pixel semi-transparent black overlay.
        [helpBG setScaleX:1024]; //Scale transparent background to appropriate size.
        [helpBG setScaleY:768];  //Scale transparent background to appropriate size.
        [self addChild:helpBG];
        [self setVisible:NO];    //Initially made invisible, only shown when info system turned on.
        CGSize screenSize = [CCDirector sharedDirector].winSize;
        self.position = ccp(screenSize.width/2, screenSize.height/2);
        [self addChild:infoLayer];
    return self;

-(void) setGamePlayLayer: (GamePlayLayer*) gamePlay {
    gameLayer = gamePlay;

- (void) toggleHelp {
    if (self.visible == YES) {
        //Remove Help system

        [infoLayer removeAllChildrenWithCleanup:YES];
        self.visible = NO;
    } else {
        //Add Help system

        self.visible = YES;        
        CCLabelTTF *helpLabel = [CCLabelTTF labelWithString:@"Info Mode On" fontName:kBaseFont fontSize:24];

        [helpLabel runAction:[CCSequence actions:[CCDelayTime actionWithDuration:2.2], [CCFadeOut actionWithDuration:1], nil]];
        [self addChild:helpLabel];

-(void) dealloc {
    gameLayer = nil;


When the toggleHelp method is called by the main game layer it makes visible the transparent overlay, and adds a disappearing message. Now we just need to implement the processTouch methods that was used when receiving touches.

Before diving into the code, I need to mention that a couple of design considerations went into this code. There are always at least two consideration in coding, ease of coding and maintainability. Usually the super easily coded solution isn't the best long term solution. We followed an easy to code method, which I admit *might* become a time sink later. But if the UI doesn't change much, then later will never come. We try not to let the perfect kill the good here.

If your game consists of items that are moving, and those items need to present information when pressed, then the code gets a bit more complicated, and the proposed solution won't work at all. See the 'Where to Go From Here section'.

For now, we simply wanted to add information for the control buttons, which are statically placed. Thus all we have to layout a set of coordinate boxes, and trigger the correct message if the touch is inside the boxes.

- (BOOL) processTouch: (CGPoint)touchLocation {
    BOOL processed = NO;
    BOOL found = NO;
    NSString *imageStr;
    NSString *text;
    CGRect boundBox;
    boundBox = CGRectMake(10, 230, 50, 50);  //Location of Move Button
    if (CGRectContainsPoint(boundBox, touchLocation)) {   
        found = YES;
        imageStr = @"help-move.png";
        text = @"HELPMOVE";

    boundBox = CGRectMake(10, 280, 150, 50);  //Location of Fight Button
    if (CGRectContainsPoint(boundBox, touchLocation)) {   
        found = YES;
        imageStr = @"help-fight.png";
        text = @"HELPFIGHT";

    boundBox = CGRectMake(60, 230, 50, 50);  //Location of Trade Button
    if (CGRectContainsPoint(boundBox, touchLocation)) {   
        found = YES;
        imageStr = @"help-trade.png";
        text = @"HELPTRADE";

    boundBox = CGRectMake(10, 180, 50, 50);  //Location of Cure Button
    if (CGRectContainsPoint(boundBox, touchLocation)) {   
        found = YES;
        imageStr = @"help-cure.png";
        text = @"HELPCURE";

	... //Other stuff if more needed. 

    [infoLayer removeAllChildrenWithCleanup:YES]; //Remove any prior message.

    if (found == YES) {
        processed = YES;
    	CCSprite *bg = [CCSprite spriteWithFile:@"bg_info_message.png"];
    	CCSprite *image = [CCSprite spriteWithFile:imageStr];
    	CCLabelTTF *label = [CCLabelTTF labelWithString: text fontName:@"Arial" fontSize:12];
    	label.position = ccp(0,100);
    	[infoLayer addChild:bg z:-1];
    	[infoLayer addChild:image z:1];
    	[infoLayer addChild:label z:2];
    return processed;

Finished product

Of course, the actual help text, images and backgrounds, and their positions need to be adjusted to your use, but this should be adequate to get you very near a tailored solution.

Our solution seen in a couple of images:

Where to go from here

If the help system needs to be used on sprites/objects that move on the game surface, then above solution will not work in the slightest. You will need to interact with your game play layer and reference all the actual sprites you want to give information about.

To do this, you must assign all the 'interesting' sprites to an array and go through the array of sprites checking for collisions between the touch and the sprite's bounding box.

In some init function add the sprites to a help array:

-(id) init {
	... //regular init code
	helpSprites = [NSMutableArray arrayWithCapacity:2];
	[helpSprites addObject:…….]; //Repeat for all objects that will need help information

Then in the 'processTouch' method for the HelpLayer class you would loop through the sprites looking for a collision:

	id foundSprite;
	for (id *sprite in gameLayer.helpSprites) {        
        //CGPoint boundOrigin = 
        CGPoint worldCoord = [sprite.infectionOverlay convertToWorldSpace: sprite.position];

        CGRect boundBox = CGRectMake(worldCoord.x, worldCoord.y, sprite.boundingBox.size.width, sprite.boundingBox.size.height);
        if (CGRectContainsPoint(boundBox, touchLocation)) {   
            foundSprite = sprite;
	//Determine which kind of sprite it is and display the appropriate help message.

A tailored mechanism like this will allow you to quickly add objects to the help system, and detect them anywhere on the game layer they might exist. Such code is much more maintainable because if you move any UI items later in the game design, the code isn't broken (unlike the original implementation which forces you to sync the boundBox to the location of items, which might be changed later). But this system is much more complex to setup.

Gladly, this entire process took less than a day to implement (minus cool help graphics to add), so no game should be w/o at least a rudimentary help system).

Comment below, or with Twitter,

Screenshot taken from our Eradicate project (view all posts here). Also visit Skejo Studios to see all we are doing there.

Eradicate Week 9 - Name Change and other updates

After a bit a break from blogging, I wanted to give another quick update regarding the state of this project. Skejo Studios,, is moving full steam ahead on our strategy game project, but it is taking longer than we anticipated. But hopefully, the longer the bread rises, the better it tastes.

First, the project name, 'Outbreak', has now been replaced by the game name, 'Operation: Eradicate'. Various internal discussions lead to this final name. I have updated many of the various links and names around the site to reflect the update.

We are now shooting for an end of January or mid February release to the app store.

Lastly, here are two uncolored pics of the commanders that will be used in the game and in marketing materials.

Syndicate content