Skip navigation

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!


Has time flown.  I can’t believe it’s already the end of the summer.  It’s been a blur, but looking back I realize I’ve done, learned, and screwed up a lot of stuff over the last 10 weeks.  Most importantly, I have learned a huge enormous gigantic ton of stuff that I would have been otherwise hard-pressed to find on Google.  I’d like to list and optionally briefly explain some of the things I have learned this summer:

  • How to build mesh data (for drawing) from vector data (from the simulation).
  • To draw as much as possible in a single draw call: all particles in an emitter and all objects that are related to one another by building one big-ass master mesh.
  • How to use interleaved data for fast drawing (didn’t actually use this, but I think I have the theory behind it down well enough to use it).
  • The power of good OOP architecture.
  • The crippling effect of poor OOP architecture.
  • The terminology of Factories in a CS context, what a Facade is in CS context, and a slew of other CS architecture paradigms.
  • Any kind of I/O sucks.
  • The worst form of I/O is networking.  Need to check for all cases including network failure, bad data, dropped data, incomplete data, yadda yadda yadda.
  • I enjoy building systems and I really like building tools to manipulate those systems.
  • How a particle engine is built and how a particle engine is built properly.
  • Verlet integration and the power behind a Verlet particle system.
  • That there are 3 ways to do everything: the wrong way, the right way, and the best way.  In software engineering, we shoot for the last and end up with the middle one most of the time.  The first is rarely engineered, but can be the result of failure at any point during the code base’s inception: communication of ideas, engineering, coding, QA, etc.
  • The Scrum process and the Agile Development paradigm.  These would have been fantastic to know and be used to before this internship, but that wasn’t really an option.
  • I suck at projecting the amount of time required to complete a task.  This is core to Scrum and Agile Development, which is why being familiar with that format would probably have benefitted me.
  • I don’t like C++.  While it has benefits, it’s structure is easily broken and it feels very hackish.  Admittedly, I am not aware of a lot it’s ins and outs, but what I have seen has made me very glad that I was introduced to programming through C and Java.
  • Complete Separating Axis Theorem!
  • There is nothing like a solid group of competent teammates on a programming project.  Things that seeming daunting to the individual can be conquered easily with the right team.

I have learned a huge amount and I want to thank everyone at ZG for giving me this wonderful opportunity and for putting up with me for a full 3 months!  I had a great time and I would highly recommend the experience to anyone looking to for an internship out there.  Yeah, that means you!

Anyway, even with all of this new-found knowledge I realize I still know next to nothing.  I feel my iPhone and Obj-C skills are pretty solid now, but there is much I still have to learn.  It’s unknown how much longer it will be until I graduate, but I feel confident that I will have something to contribute once I do.  I’m still debating whether I want to stay in state or move somewhere in specific, but one things for damned sure: it ain’t gonna be Florida again…

That’s it for me.  I’ll probably wrap up my internship thoughts sometime next week, but I’ll be sending my computer back home soon, so it will probably be short.  Keep on keeping on and I hope to have another post sometime soon.  Peace.

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!

I’ve been getting back into my game engine again.  Shawn Kendall, one of the owners of ZG, has been kind enough to provide me with some tips and pointers for engine design.  Shawn is an incredibly learned man in this subject and used to teach game engine design at Full Sail U here in Florida.  Naturally, this has been an amazing opportunity which I plan to continue to leverage as much as possible.  In any case, the basics of the engine are pretty much planned out by now and I will probably be uploading the images of that sometime soon.  It’s been a lot of work and slow going, but it will be pretty awesome to have an engine of my own to dork around with and gain experience from.

On to the title of this post: the people at the ZG office **LOVE** Magic: The Gathering.  They play pretty much every Friday night, sparsely during the week, and sometimes even during breaks.  They are constantly talking about the new sets that are coming out, the recent deck they built to best so-and-so, and how broken certain cards are.  Me?  I like Magic, but I probably won’t ever get to the level of devotion that these guys have.

However, I have found that MTG is a very solid, well built, and fascinating game.  Since my time this summer has been almost exclusively *coding* games, I figure flexing my design and balancing skills is just as important.  I think Magic is a great place to start with that, so I have come up with a few card concepts that I would love to have feedback about.  I will hopefully be churning out more card concepts over the summer, but we’ll start with these:

Spiteful Visions:  2 Black                                      – Common


Target player discards 2 cards and draws a card.


“Forgetting is as much of a blessing as a curse.” -Iithes

Slash and Burn:  3 Red, 2 Colorless                   – Uncommon


Destroy target green permanent or target basic land unless it’s controller pays 3 Life.

“Take a life to save a life?  Sounds like a fair trade.”

Thriving Sapsire:  5 Green                                    – Rare

Creature – Saproling Ancient


Put a -1/-1 counter on Thriving Sapsire: put two 1/1 Saproling tokens onto the battlefield.

When Thriving Sapsire is placed in a graveyard, put two 1/1 Saproling token onto the battlefield.

Creatures of the forest never die, they simply get smaller.

Inspired Flight:  2 Blue, 2 White                        – Common


Enchant Creature

Enchanted Creature gains +2/+3 and has flying.  Place a -1/-1 counter on enchanted creature.  When enchanted creature is put into a graveyard it’s controller gains Life equal to the number of -1/-1 counters on enchanted creature.

“The best things in life might just kill you.” -Tarr’agun

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.

Had to present the delivery I made last week to the rest of the office today.  While I strongly support the deliverable, our presentation left a lot to be desired.  However, I feel that passing on the key points of the presentation are a good idea.

What went right: we tore up the user stories.  We hit pretty much every milestone with room to spare and didn’t really have to scramble to get our sprints finished on time.  Despite all of the interruptions that cropped up during development, we still delivered on time with some bits of fluff and padding to spare.

What went wrong: I consistently doubted the abilities and habits of the engineer who had worked on the project before me.  This meant that I frequently had to ask him stupid questions that were resolved with a single line of code, taking away valuable time from him.  Also, other projects kept getting in the way of our sprint.  Although we were able to still deliver with these interruptions, the other projects certainly didn’t help our development cycle and tended to distract our team.

Lessons learned: use the tools at hand to their greatest extent before bugging other people.  Use Command-F, use the debugger, use the internet.  Exhaust your resources before you call in other people to help mitigate your issues.

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.