Skip navigation

Category Archives: Uncategorized

I finally decided it’s time for my own site, so I coughed up the $200 for a domain, hosting, space, etc.  So I will be moving to my own site along with the blog.  I will not be posting much more here.  Instead you can find it all here at:

I will be moving over most of my interesting content to my main site will probably be dissolving this blog in favor of my own.  Hope to see you there.  BTW, I promise to post more often from here on out (for both of you who care).  So stay tuned and check out the new site!

Been WAY too long since I’ve done a review.  I feel a little out of it tonight, but here it is:

Left 4 Dead

Platform: 360   PC    Rating: M    Genre: FPS/Survival Horror

What it is:

Visceral, intense, and built for friends.  Zombie hordes, gripping visuals, believable characters, and forced teamwork push the Survivors to the brink to stay on their feet.  All too often a good game of L4D has the survivors limping into the safe-house with a Tank and the horde on their heals, down to just pistols and temporary health.  Not for the faint of heart at higher difficulties.  Online play with anonymous teammates is rarely as gripping as with a group of close friends striking out to complete the current campaign.  If you can, grab some of your pals and get a game rolling on Expert, just to see who would crack in the zombie apocalypse.

What it isn’t:

Sprawling, forgiving, or for sore losers.  There is a severely limited number of maps.  While the AI Director makes them less predictable, they pretty much turn out the same way every time.  A single fortunately-placed Special Infected and you are down for the count.  With this vulnerability, you have to get used to the idea that part of the game is death.  And if not death, then injury, low ammo, desperation and no hope.  For some less-mature players, this reality of Left 4 Dead is the hardest part of the game.


Gripping and tense, highly stylized, a great interactive story.  Still waiting for it to get boring, despite expectations.  Very fun online with friends and tolerable online with other people.  AI Director keeps the game tense and is a cool piece of tech.


Limited number of maps makes it easy to figure out good defensive positions.  The number of frivolous achievements easily offsets the number of truly interesting achievements, making progress in your achievements feel significantly less rewarding.


– Highly Recommended:

Splatter some zombies with your friends.  Solid, stylized horror.

It took an entire day to get In-App purchases to work.  TOTALLY unnecessary.  Apple’s docs on the subject are worthless, so I figure it’s time for another Coding Help Blog Post ™.

Alright, so getting a store in place is a bit involved, but I’ll do my best:

Include the StoreKit framework in your project and apply the appropriate #import.  In your main view controller, you will want to begin querying the App Store for product information as soon as possible so you can store the returned information before it’s needed to avoid network traffic slowing your user down.  You will also need to set up transaction observation in order to receive payment information.  To do this add the following lines to your main view controller:

NSSet* productIDs = [NSSet setWithObject:@”com.yourcompany.yourapplication.####”];
SKProductsRequest* productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers: productIDs];
[productsRequest setDelegate: self];
[productsRequest start];
[[SKPaymentQueue defaultQueue] addTransactionObserver: self];

This will ping the App Store for product information pertaining to the product IDs associated with the productIDs given in the set.  When the request receives a response, it will call your view controller’s -productsRequest:didReceiveResponse: method.  In this method, you will want to store the products array provided by the response object.  In this method, you should also check the invalidProductIdentifiers property of the response object to make sure that everything made it through and to respond otherwise.

You can use the information from the response array to populate your GUI and allow users to purchase.  Once the user has chosen a product to buy you will have to intercept their choice and send out for App Store information.  To do this, you create a payment object with the desired product ID and send that out to the App Store.  That will look something like this:

SKPayment* thePayment = [SKPayment paymentWithProduct: someProduct];
[[SKPaymentQueue defaultQueue] addPayment: thePayment];

This method will ping the server with a payment request or a test request if you are using the sandbox.  The request will return to your -paymentQueue:didUpdateTransaction: method.  In here you need to determine the state of the payment object that the update returned.  To do this, iterate over all of the transactions while switching on their transactionState property.  Upon SKPaymentTransactionStatePurchased, you will need to validate the receipt information, begin downloading, and close out the payment.

Most important of these is receipt validation.  To do this, create a string using the returned transaction’s receipt data and turn that into a string.  This string is actually a JSON object which can then be passed to your PHP server (or whatever) to be then forwarded to the App Store for receipt validation.  Your code will probably look something like this:

NSString* jsonObjectString = [YourClass encode: (uint8_t*)[[transaction transactionReceipt] bytes]  length: [[transaction transactionReceipt] length];

NSString* completeString = [NSString stringWithFormat: @””, jsonObjectString];

NSURL* urlForValidation = [NSURL urlWithString: completeString];

NSMutableURLRequest* validationRequest = [[NSMutableURLRequest alloc] initWithURL: urlForValidation];

[validationRequest setHTTPMethod: @”GET”];

NSData* responseData = [NSURLConnection sendRequest: validationRequest  returningResponse: nil  error: nil];

NSString* responseString = [[NSString alloc] initWithData: responseData encoding: NSUTF8StringEncoding];

int success = [responseString intValue];

You will have to add the following code to your project.  It’s recommended you put this code in as a category to NSString, but it can be place pretty much anywhere.  The following code can be found here: at the bottom.

+ (NSString*) encode:(const uint8_t*) input length:(NSInteger) length {
    static char table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";

    NSMutableData* data = [NSMutableData dataWithLength:((length + 2) / 3) * 4];
    uint8_t* output = (uint8_t*)data.mutableBytes;

    for (NSInteger i = 0; i < length; i += 3) {
        NSInteger value = 0;
        for (NSInteger j = i; j < (i + 3); j++) {
            value <<= 8;

            if (j < length) {
                value |= (0xFF & input[j]);

        NSInteger index = (i / 3) * 4;
        output[index + 0] =                    table[(value >> 18) & 0x3F];
        output[index + 1] =                    table[(value >> 12) & 0x3F];
        output[index + 2] = (i + 1) < length ? table[(value >> 6)  & 0x3F] : '=';
        output[index + 3] = (i + 2) < length ? table[(value >> 0)  & 0x3F] : '=';

    return [[[NSString alloc] initWithData:data
                                  encoding:NSASCIIStringEncoding] autorelease];

This will encode your JSON string to Base64, which can then be passed to your server and on to the App Store for validation.

The variable ‘success’ can be anything your server wants to return to indicate success, but the App Store returns a 0 on success.

Hope that helps.  It was certainly a pain in the ass for me and my co-workers.  Good luck!

I have been using a really cool little utility that I’d like to share with the 3 people who read my blog: The Clang Static Analyzer.  This little command-line utility is pretty damned slick.  What it does is it parses your code and identifies possible memory leaks and logic errors.  It’s a bit of a pain to get running, but once it’s in place, it’s VERY helpful.  I should mention that it works best for Objective-C and is built with Mac OS X and Xcode in mind.  Still, if you are working on a Mac or been having memory issues on the iPhone project, ClangSA is for you!  So let’s get started:

Go here Clang Static Analyzer Page and download the Latest Build, which should be near the top.  Once that has downloaded, unzip it and rename it to something like ClangSA or whatever you want.  I will be using ClangSA for the purposes of this tutorial.  Put the newly named folder wherever you like, I would recommend your Developer folder.

Alright, so now you have the Clang build on your desktop.  Where to from here?  Well, we could just use it as is, but this means you will have to cd into your Desktop and use the analyzer’s explicit path every time you want to use it.  Instead, we are going to write a shell script (*gasp* command line?!) to make the analyzer available to you from anywhere.  I use tcsh, but we will build a script for both tcsh and bash, just for fun.

Open your Terminal application.  From your ~ directory (Home) find your /bin folder.  If one does not exist, create one with: mkdir ~/bin.

Next: cd ~/bin.  Now that we are inside the bin folder, we are going to make a symbolic link to the analyzer.  To do this type: ln -s <Location of your ClanSA directory>/scan-build.  *WARNING* moving your ClangSA directory after making this link will break it.

We now have a link to the scan-build command for the analyzer.  This command is run on your code to execute the analysis.  For this next part you will need to check your shell.  Type: echo $SHELL.  If the result of that is tcsh, read on.  If it is bash, go down to the BASH section.


Navigate back home with: cd ~.  Next, type: emacs .cshrc.  If there is already contents in this file, add the following to the end of the file.  Type in the following:

set path = (~/bin $path)

Right.  This makes ~/bin part of the command-line’s search path for global commands.  This will allow us to invoke scan-build from anywhere, which is VERY handy.  Save the file with Ctrl-x Crtl-s.  Then exit emacs with Ctrl-x Ctrl-c.  After the bash section is more information, so skip down there and check it out.


Navigate to your home directory with: cd ~.  Then open up the editor with: emacs .profile.  If text already exists in this script, just put the following at the bottom.  Enter the following text into the script:

export PATH=~/bin:$PATH

That’s it!  Save the file with Ctrl-x Ctrl-s.  Then exit emacs with Ctrl-x Ctrl-c.  This allows us to invoke scan-build from anywhere, which is VERY handy.


If you haven’t read the Clang site yet, I’ll reiterate what it says here as well as explain how to use it.  Clang is best used on a project that has not been recently built.  So before using the ClangSA, open your Xcode project and do a Clean.  This will get rid of temp files and mark all of the source as unbuilt, which is necessary for the analyzer to work.  Once you have cleaned the project, open up the Terminal again.

Cd into your project folder.  If you do an ls, you should see all of your source files and the project file.  From inside this directory, type the following command:

scan-build -k -V xcodebuild -configuration Debug

This calls the scan-build command that we made global in the scripts above.  It should start spewing out a lot of information, but none of it is really what you are looking for.  When it’s done, it should open up a browser window with bug and memory information.  Oh, yeah, you always want to use the Debug configuration.  Apparently, Clang has a nasty habit of modifying and parsing build configurations, so it’s best to break Debug should that happen.

If you are building an iPhone project you will need to include your sdk.  To do this, type in the following line:

scan-build -k -V xcodebuild -configuration Debug -sdk iphonesimulator<SDK version, such as 3.0>

And that’s it!  The analyzer is not perfect, but DAMN is it ever helpful.  And it’s also pretty smart, so work with it to improve your code.  I really hope that Apple makes this an integral part of Xcode in the future (which is the current rumor).  Code away!

Today was a great day. You know, despite it being Monday, my project being rejected for minor issues, and my continued lack of personal computer time. I learned a LOT today, and that’s what’s important. The most signifcant thing I learned today is that my coding instincts have been more or less right on the money. I was introduced to the Factory design paradigm, the Strategy paradigm, and the Flyweight pattern. All of these can be found on the net if you are interested. Seriously, go read them, I’ll be here when you get back.

The point of introducing these concepts is to mention that I have been blindly applying these ideas in the practices without knowing about them until today, which fills me with confidence about my own methods. Now, before this ego boost gets out of control, some other things cropped up that helped to keep me in my place. For instance, the new level system.

Our manager gathered everyone into the large room and began handing out forms. He proceeded to explain the new peer evaluation system which centers around classes and rankings. That’s right we have classes and levels in our game studio. The example Mr. Oltyan used was Software Engineer III. In order to get a raise and increased benefits, one would have to demonstrate proficiency in certain skills to advance to the next level. Multi-classing is also allowed, allowing engineers to become artists and vice-versa. How fing COOL is that?! I’m infinitely curious to see how it works out.

This puts Sage and I at Production Intern III and Programming Intern III respectively. We have been informed that leveling as an intern requires signifcantly more experience than normal, so if we come back next year, it’s possible to become Intern IV, but it will be difficult to achieve that this year. Funny enough, I’m OK with it.

I had one of those moments today were I stopped in the middle of a line of code and said to myself “Holy crap. I’m in the games industry. I’m getting paid to make games. I had only dreamed of doing this a few years ago. I’m moving up, doing what I love, and having a blast.” A surreal and amazing moment indeed.

I found this informative article.  It’s really not that ground-breaking, but it’s a good read for any designer/developer or anyone who is interested in strengthening their story telling habits: A Simple View of Game Story

I’ve been putting off a new post for quite a while now since I feel that readers don’t care about how cool things have been around here.  Let me just say that ZG is pretty damned amazing.  The people are awesome, the work is engaging, and I couldn’t ask for a better introduction to the games industry.

As far as things I’ve learned though:

I learned about the “user story” planning model.  I had never heard of this before ZG, but it is apparently sweeping through the industry as the revolutionary new way to manage projects.  How this works is content is presented as a need from the user’s perspective.  Then tasks are assigned to the stories to separate the user story into a functional piece of the product.  For example, a user story might be: As a player, I want to be able to jump. This means that whatever is needed to make the final result of a jumping player is encompassed by this story: physics engine, character animations, noises, decals, whatever as long as the final results of the story is that the user perceives jumping.  After the stories are all compiled, the team then participates in “planning poker”.  A deck of cards with groups of Ace, 2, 3, 5, 8, Jack, Queen, and King are split up so that all members have one of each card.  A user story is selected and everyone places a card on the table estimating the difficulty of that story.  Ace is trivial, 2 is a day, 3 is slightly more than a day, a three is two to three days, etc., where Queen is a 25, meaning the task is large and hard to predict it’s time needs and King means 50 – a task that is daunting and will require many many man-hours to complete.  This technique seemed a little strange at first, but it has turned out be very powerful.  It really helps to figure out what concessions you need to make in order to deliver the expected results and packages each story into a single entity, generally independent of other parts of the project.

Next on the list of edumacatification is “Scrum Team Management”.  This is a part of the agile development philosophy, attempting to keep teams and projects lightweight and flexible.  The idea is that scrum meetings are held every day at the same time and last no longer than 15 minutes.  Period.  In these meetings everyone on the team explains what they did yesterday, what they plan to do today, and if they are waiting on anything (a blocker, as it’s called).  This puts everyone on the same page and encourages communication.  It seems to have worked pretty well so far.

Along with the Scrum methodology is the Sprint ideal.  Sprints are short periods of development where a specific set of user stories are focused on.  If a user story is not part of a sprint, it is ignored (unless there is a direct dependance, wherein both the blocking story and the depending story will most likely be involved in the same sprint).  These sprints are usually 2-4 weeks in length, but some longer and some go shorter.  For example, I have been working in 1 week sprints.  This is mostly because my project is smaller and we have very few people working on the project at this time, allowing for rapid development and easy communication.

My last piece of wisdom to pass down is simple, but profound.  I have been informed that it is NEVER a good idea to make more work for the people above you.  Take the time to do it right the first time.  Research, test, model, plan, do whatever you need to do.  Because if you do something stupid and someone who costs the company more money has to clean up after you, everyone is going to be angry and you will look dense and inconsiderate.  This doesn’t mean you shouldn’t ask for help.  This means that you should exhaust every resource you can before you go whining to more expensive people.

Things have been going really well down here.  Florida blows, but that’s really only because I’m used to dry, cooler weather.  Be sure to keep in touch and stay tuned in.  I should have more nuggets of wisdom some time down the line.

I arrived in Florida on Thursday after a 3 hour flight that went quite smoothly. Flying out left me without a car, so I begged an old high school friend to pick me up. So he picked me up from the airport and we started driving, quickly realizing that neither of us knew the address of my residence. So we spent a good hour or two driving around Orlando looking for a WiFi hotspot so I could look up the address and directions on my iPod Touch.

So I’m mostly moved in at this point, I will be posting pics as soon as I get my camera charger. I have a mattress on the ground, a table and chair from Walmart and my luggage in a corner and that’s it.

Anyway, on to content: I don’t start work officially until Monday but I decided to go in on Friday to meet everyone and to get paperwork out of the way.

Everyone was pretty awesome. Some of them were less sociable and receptive than others, but I wasn’t expecting hugs and a party anyway.

Shortly after my arrival and introduction we all went out to lunch and the hazing and initiation began. Dustin Clingman, my boss and co-owner of the company, tells me that I will consume a chip with a single drop of a special hot sauce. This hotsauce (the name of which escapes me at this time) registers at 1.5 million scouvilles — pretty hot.

So I ate it. It was pretty bad. Let’s leave it at that.

As for the people there are many people at the office, most of which I have not met to any functional capacity. Chris Oltyan and Dustin Clingman are the two head hanchos that I report to and they are both pretty awesome.

First piece of knowledge I learned at ZG was for iPhone programming: project names with spaces or other non-alphanumeric characters will fail using any calls to NSBundle. Instead, you need to go into your Target’s settings and change the Product Name field to something without spaces or weird characters. This will change the path that the os uses as well as any plist or setting that uses the Product tag. Of you still need the offending characters in your app’s name, go into the Info.plist file and change the “Bundle Indentifier Name” field. Enjoy!

Anyway, I’m a little unsure what I’ll be doing and will be bound by NDA but I will relay as much of my experiences as I can. Keep in there.

Paper Prototyping is a great article that I wish I had seen *before* I had done my iPhone game.  It has some very useful and interesting insights that I will be sure to use and reflect upon as I continue to develop, not only for the iPhone, but for all my games in the future.

Very useful article, I would recommend it to anyone who is looking into games, especially big budget games where mistakes cost lots of money.

Just got a reply from Zeigeist Games that said I got the internship for the summer!!!!!!!!!!!!  This means I’ll be flying out to Orlando, Florida for the summer and doing iPhone programming for these guys.  I can’t express how excited, elated, and anxious I am to be given this opportunity!  I’m “living the dream” as Max said this morning.  This will be a great learning and proving opportunity for me and I hope I make it worthwhile for both parties.  More on this later…