Tech Project Survival Guide

Right now I'm working out of River City Labs and meeting a lot of folks who are in start-up mode.  Full of entrepreneurial spirit, in some cases backed by other peoples cash, and all finding themselves with varying levels of skill in managing a technical project.

To try to do a an ultra-dense, nutshell presentation that compresses the top few tips I have learned about getting a tech project to success, I decided to try out PowToon.  It needs some work, but have a look and see what you think.  I may yet replace the music with a voice over.

My talking points about what I wanted to say are summarised below.  At present the video does not have voice, just the music that came with the PowToon software.

• Tech projects involve 
• project owners who have an idea they want realized
• and technical experts who think in terms of what artifacts are needed
• there is a natural tension that can result in bad outcomes
• if you are the project owner YOU must work to fix this
• YOU must make sure communication channels are working
• good tech experts have lots of work to do without doing your job for you
• As a project owner its tempting to think of your idea like a plan for a house
• it can simply be built like other houses
• you don't need to specify everything
• we'll come back when its all done
• but technical projects are not like that
• a technical project is more like a journey 
• project owners and tech experts must travel together
• your spec not a house plan, is a chart into unknown territory 
• and it will have to handle change
• When your project is on course, completed code is piling up
• maybe you have an in-progress app or a website 
• that means NOTHING without the code
• the code is what makes your screens & web pages actually work
• without it you have nothing - what if your developer leaves?
• no more changes can be made - the whole site/app will need to be rebuilt
• project owners MUST track the code that is being written for them
• NOT OPTIONAL - you MUST do this, techie or not
• successful tech projects put their code & other artifacts in source control
• if you already know source control, then good: 
• if not learn:
• what is a source control "repo"?
• how do I log in to mine and see the commits?
• who has access?
• NOT OPTIONAL - you MUST do this
• Join the crew, be part of the technical team.  
• Check your project plan - its your map of the planned project course
• But reality is not the plan.  The plan is an idea.  It may need to change.
• As a project owner you are expert in the goals of the project, and 
• your technical crew are expert in the tech needed for the implementation.  
• the cleverness/coolness of implementation comes AFTER meeting the spec
• work to get your features the best way within the technological constraints
• Don't treat them like "resources", and 
• stay on board with them.  
• Earn their respect
• just paying on time is not enough to achieve this.
• If you have your head in the project plan and don't talk with your team 
• you will blow off course and your results will show it
• Iterate with your team.  Daily.  Weekly.  Watch the artifacts pile up.
• Check your implementation against your spec.  Look for gaps.
• Keep your charts up to date, and map your current location.
• Know where you are every day.  Avoid surprises.
• If for some reason you can't be at the helm
• find a trusted project manager
• with no-one at the helm you'll go off course & the project will founder

In summary - if you are a project owner, don't just give your technical project team a brief and tell them to go for it.  Your idea is mostly in your head, and your technical team is not psychic - if you want the project to fulfil your vision you have to work with your team throughout the duration of the project.  Creating ever more detailed project spec's is one answer, but its no substitute for communicating with your team, checking in every day, and making sure you're on track.

This allows you to work with them to make the implementation fulfil your goals.  Your plan will likely need to change - maybe there are cheaper, easier ways to get something done technically that achieves the same goal business-wise.  You'll never know if you are not on-board with your team, working with them.  Course corrections can be made before you drift too far off track.

And.  Use source control.  Even if you're non-technical, learn what it is, why its used by every successful project; and how to access at least the web-console for your source control "repo".

CocosBuilder Revolution

A couple of months ago now I threw away all my code and started again.

Was that a bad thing?  Well, it was bad in the sense that I wish I had known back before I started writing all that code that there was a better way to do it, a way that was going to be so much more productive that even throwing away months of work was going to be sort of OK.

So what is that better way?  Using CocosBuilder.

Cocos2D is a powerful API for building your games on iOS, but it is just code, and when I started out on my game I quickly found it impossible to organise all the resources I needed and to size and position all the elements on the game screen.  As I mention in the video I had seen CocosBuilder last year but it seemed flakey and not up to doing enough of what I needed.

But the new 3.0 version is much improved and there are a number of tricks with CocosBuilder that allow you to do a lot more with it than appears at first blush.  It turns out to be well-suited to creating an adventure game like mine, if you can figure out how to game it to your ends.

To try to help anyone who is contemplating going down the path I went down, or anyone who needs a powerful game interface creation tool but is too afraid to ask, here is a video tutorial I put together looking at how to get started with CocosBuilder for iOS.  The tutorial also includes a bit of my thinking around the game editor journey for me.

The tutorial comes in 4 parts, each of around 10 minutes (due to YouTube constraints) and I have tried to make the divisions not too arbitrary.  I'd encourage watching the whole thing, but if you just want to dip into the bits you need I hope the text below will help choose the right parts to watch.

As well as watching my tutorial please also check out two other great tutorials (not videos but very good nonetheless) which I used myself during my CocosBuilder learning process:
http://code.zynga.com/2012/10/creating-a-game-with-cocosbuilder/
http://www.raywenderlich.com/23996/introduction-to-cocosbuilder

Here are download links to the software I used:

• cocos2d-iphone-2.1-rc1.tar.gz
• Download CocosBuilder Application

Part 1 - Installation and Setup of a Tutorial project for Cocos2D-iOS & CocosBuilder

Part 2 - CocosBuilder resources and first Run of content

Part 3 - Creating a HUD layer CCB

Part 4 - Animating the HUD & making the buttons work

Things I had to leave out

The tutorial was already up to 40 minutes so I had to leave some things out.  Maybe I need to learn how to talk faster.  :-)

Using the UI elements: I imported some UI elements in a plist file in part 1, but never got time to use them.  But if you experiment you should have no trouble in seeing how to use these.  It's pretty much a case of drag and drop.  In some cases you need to use the "Sprite frame" selector in the properties panel on the right-hand-side of CocosBuilder.

Making a layer use the targeted touch handler: I recorded some footage on this, but had to remove it to get the tut down to a reasonable size.  The trick here is that most tutorials and references tell you to implement registerWithTouchHandler in your CCLayer subclass in order to get the kCCTouchesOneAtATime behaviour.

With that behaviour you can use

- (BOOL)ccTouchBegan:(UITouch *)touch withEvent:(UIEvent *)event
{
    CCLOG(@"%@::%@ - %@", NSStringFromClass([self class]), NSStringFromSelector(_cmd), touch);
    CGPoint location = [touch locationInView: [touch view]];
    location = [[CCDirector sharedDirector] convertToGL:location];
    
    BOOL isHandled = NO;
    if (CGRectContainsPoint([self boundingBox], location))
    {
        isHandled = YES;
        // do stuff
    }
    return isHandled;
}

Now it turns out that you can get that by setting the following in CocosBuilder for your CCLayer subclass:

...and since these are set in didLoadFromCCB before the onEnter handler sets up the registration, this will cause the CCLayer's implementation of registerWithTouchHandler to set up your instance for one-at-a-time touches.  Now you can implement your touch handler (as above) and off you go.

Thanks for watching videos - I hope they're useful.  Please - if you spot any mistakes let me know so I can address them.

Happy Cocos building!