Seven Years Later April 2, 2013 10:17pm
I just realized how much my coding has changed over the past seven years. I was writing some code for a new app, when I remembered I'd done pretty much the exact same thing for an old project back in 2006. I dug up the old code, but since I'm lazy I only copied the core functionality, not the fifty or sixty lines of support code that was also required. Earning the gold medal for laziness, I refused to dig up that old code again and just rewrote it. This time around it only took me three lines. To do the exact, same thing.
The Job June 26, 2012 5:58am
First off let me just say that I get a lot of interview requests every day, so I want to apologize to anyone I am unable to get back to. I realize the trend these days is to be "agile," but every time I see a posting with the terms "agile development" and "extreme programming" I tend to have a giggle and move on. For the uninitiated, in the really real world agile development and extreme programming mean they don't have specs, project managers, a realistic roadmap, comprehension of time, sense of direction, they have super short release cycles, a perpetually high burn rate, or all the above. This would all be fine, if only the company in question at least adhered to a process like Scrum. Unfortunately, most tend to adopt only the parts of Agile they like, while leaving out the checks and balances.

When I was with Nokia I was a scrum master and strictly enforced the complete Agile process. We got a lot of work done in a fairly short amount of time, but as the changes piled on work constantly came to a halt. As with every other agile company I've been with, that was when they broke the process. We kept the weekly releases, the stand-ups, the high pace, and the fluid spec, but we were no longer sprinting. We stopped freezing and resetting sprints when the changes rolled in. Instead we were still expected to meet the weekly releases, which of course was impossible.

It was then that some of us decided to switch to Waterfall. We sat with the product managers and business and defined a clear spec. We said goodbye to the meaningless incremental releases and instead set a fairly short two month deadline. In just under two months we were code complete and ready to ship version 1.0 of our product. Then along came the pm's with a laundry list of changes. As you may have noticed, I said I "was" with Nokia.
Let's Goto! December 14, 2011 6:09am
I've written code for a lot of companies. At last count it was well over thirty. Believe it or not, only a few of those companies used and enforced formal coding standards and best practices. Of those, all are now defunct. The point? A standard does not make a good product.

The curious thing is that at every single one of these companies there was at least one developer, usually some young buck fresh out of college, with genuine nerd rage over the code base or some other developer's code. All the seasoned devs - and that doesn't mean old so much as very experienced - would joke around about it, but weren't all that concerned. That's because a good coder is more interested in the content than the appearance. If the code works, and works well, I couldn't care less if all the equal signs line up. Readability is all well and good, but I'd much rather a developer was thinking about the algorithm than where to put a curly brace. Subjectivity has no place in code. Which brings me to the best practices portion of the phrase.

Let's analyze the term for a second: best practices. By definition, a "best" practice is subjective. In programming there's usually more than ten ways to do something. Which one is "best" depends on the context, therefore there can be no true best practice. To rule in advance that a particular way of handling a given problem is the only acceptable method can severely hinder future solutions.

Let's use my favorite example, our friend the goto statement. Easily the most hated artifact in the programming world. But why? Many will tell you because it causes spaghetti code. I would argue that it is the developer who cooked those noodles. Besides, millions of lines of spaghetti code is written on a daily basis using seemingly best practices of object oriented programming. Goto, like OOP, has its purpose, and also like OOP, can be easily abused. To blacklist any given statement, function, or design pattern in coding is akin to stripping a carpenter of his hammer for fear he might break something.
Programming Is Easy December 2, 2011 3:38pm
People are always telling me I must be really smart when they hear I'm a coder. I always tell them, "Not really. Any idiot can be a programmer." And it's true. All it takes is basic problem solving skills and memorizing some syntax. I was coding when I was seven years old, and I was smart for my age, but definitely not smarter than my non-coding parents.

So yes, programming is easy. Programming well, on the other hand, not so much. I know a lot of coders, but I can count the good ones on one hand. No joke. The joke is that some of the worst coders I know are the most educated ones. The ones who have a bachelor's or master's degree in computer science, yet somehow tank the entire codebase with a single check-in (often with some pompous commit message explaining how they fixed someone else's poorly designed code).

To be fair, the highest percentage of bad coders I've known were street coders. You know, that guy who read a book on PHP (cover to cover) and now he thinks he's a programmer. Or that nimrod who scored a copy of Dreamweaver on a warez disc and made his first "kick ass" website so he must be a programmer. Sorry to bust your bubble, but no matter what wikipedia told you, you're not a programmer until you ship your first app. Until you can look at some code you wrote five minutes ago and know exactly why it's crap. Until the amount of programming knowledge your wife has acquired through osmosis qualifies her as a junior developer. Until you've had to go back to the toilet to finish wiping because you got an epiphany on the commode but forgot to take the laptop with you. Oh what, like that never happened to you?
It's Not That Hard After All November 9, 2011 3:31pm
That's what she said? Ahem, right, so I'm back to work on porting Show & Spell via S3D plugin and things are going pretty smoothly. I've got most of the utility functionality working and just need to add the core behavior and state logic. After that I can add all the resources to the project and tie it all together with the Lua triggers and we're good to go. I was dreading this for a while, but somehow it's not too bad. Maybe it's just the simplicity of the project or maybe I suck a little less this year, who knows. Either way, I'll take it. I've got at least three more games on the drawing board, and if I don't know my stuff I do know they'll be the death of me.

I was thinking about doing a quick app with the C4 engine, but I highly doubt that's going to happen any time soon. At this point I don't have time to experiment on mere hobby apps. If I'm sitting in front of a keyboard instead of changing diapers or feeding kids I need to have a good reason. Somehow, "I'm learning a new framework," doesn't seem like something that's going to keep the Mrs. from putting a fist in my face.
Smart Is The New Stupid October 22, 2011 10:31pm
At 2:04 this morning I found out how smart I am. Then at 2:08 I found out how stupid I am.

I'm currently in the process of porting another one of my iOS apps to Shiva, only this time I've decided to write the whole thing as a C++ plugin rather than scripted in Lua. The app I'm porting is Show & Spell because, once again, it's simple. The idea is to show a random spelling card when you tap the screen. In the original version the card selection is totally random, which allows for annoying non-bugs like showing the same card several times in a short time frame, and even in a row. I decided that while I'm porting it I should fix this bug. Shouldn't be too hard, right? Right! That is, unless you suck at C++.

The approach I took was to shuffle the list of cards, then just pull them out one at a time in the new randomized order. I just needed to come up with a method to do the shuffling. No problem. First I wrote a while() loop to randomly get cards and stuff them into a new list. Then I added a function to check whether or not the given card exists in the new list. Bam, done. A total of eight lines of code got me a perfectly shuffled list every time. I == genius. Of course, being a true genius I looked at that for() loop staring at me from inside that while() loop and knew how inefficient it was. I did a quick search for better ways to do this and, of course, found:

    void random_shuffle (
        RandomAccessIterator first,
        RandomAccessIterator last,
        RandomNumberGenerator& rand

Yay! A built in function that does exactly what I just spent thirty minutes coding up. Great. "Well," I thought, "it cant be THAT much better can it?" Of course I was going to refactor my code, but I just had to make sure I wasn't a complete idiot. I spent a few minutes dropping in some timing code to see just how fast each method was. My code took an average of about 45 ticks, with a low of 32 and a high of 59. Cool, man, 45 ticks isn't so bad, right? So I run it again, this time using random_shuffle(). 5 ticks. Dammit. Never mind.
The Rockstar Moment October 19, 2011 4:04am
One of my favorite things about being a coder is what I like to call The Rockstar Moment™. That's the 1-5 seconds after you write some bad ass piece of code or solve some heinous problem. That brief period where you are a golden god and all the little humans are like the buzzing of flies to you. Don't even lie, man, you know exactly what I'm talking about.

I just had a Rockstar Moment™ about fifteen minutes ago. I was piddling around with my new favorite game dev tool (S3D aka Shiva) trying my luck at building a plugin in C++. Previously I had a few misgivings about the tool in general. The engine itself (the S3D part of the package) is a thing of beauty. It's fast, stable, pretty, and extremely well documented. The integrated editing system, however, has its flaws. Not to mention the gimped version of Lua it uses for its scripting engine. My hope was that I could use plugins to sidestep all the issues and hack away at C++ in Visual Studio which, let's face it, is only the greatest IDE of all time. As it turns out, my hope == done deal.

In roughly five minutes I was able to -at run time- grab input from the engine, act on those inputs, and spit out some data. Everything just plain worked as it should. I know that's expected behavior, but it's just not often the case these days. I officially have zero reasons to not use S3D. Oh yeah, and I == Rockstar.
It's Confirmed. I Am Stupid. October 14, 2011 3:02am
I'm sitting here looking at a project I built in 2005. It's a multi-threaded email server with a regex-based spam filtering system. It's basically a performance oriented port of an original I made in C# back in 2003. So I'm staring at my screen thinking, "What. The. Hell?" I seriously hope coding is like riding a bike, because I don't remember any of this.
Am I Stupid Or Is C++ Raping My Mind? October 13, 2011 2:30pm
I suck at C++. There I said it. My first exposure to programming was way back in 1983 on an Apple IIe with Logo. Pretty soon I picked up BASIC and was writing text-based games on a TRS-80, and an address book on my Casio FX-802P. A few years later I was puttering around doing very basic stuff in C. So one day I went down to Egghead Software and picked up Visual C++ (1.0) for $99. Yes, I'm that old. Anyway, let's just say C++ aggravated me enough that I got back into design for a few years.

After realizing the Universe wants me to be a coder I decided to make a career out it. That was twelve years ago, and in that time I've worked with Perl, Java, PHP, C#, Lua, and a few others I can't remember at the moment. I kept revisiting The Demon over the years, at one point talking my employer at the time into buying me VS 2008. For some reason, however, I could never get my head around the complexity, perceived or real.

So here we are at the end of 2011. I've now been coding for just under thirty years -twelve years professionally- and it's once again time for me to take a shot at The Demon. This time is a little bit different because it's not just academic. I finally have some real projects that require me to use C++, so I've been catching up on what I'd forgotten and re-learning what was giving me so much trouble in the past. And after all this time I finally figured out what my problem was: other coders.

Don't get me wrong, I'm not saying everyone else is crap. It's just that most of the code I was looking at before wasn't ideal to learn from. The basics of any language are easy. It's making the code work -well- that's hard. Most of what I'd been looking at was high performance real-time code. Game engines, physics, ai, stuff like that. I sometimes have trouble figuring out what my own hi-perf code is doing so I don't know why it never occurred to me to look at simpler work. Actually I do know why: I'm stupid. So to all you hard core C++ programmers out there, from one coder to another, I hate you. You guys amaze the hell out of me, but I still hate you. My brain hurts and it's all your fault.
Hello Shiva == Goodbye Unity September 30, 2011 6:01am
Last week "the team" decided to Just Say No to Unity. After over two years developing iOS games on the system we'd finally had enough of the never-ending cycle of performance issues and workarounds. The straw that eventually did me in was a massive frame rate hit doing a ridiculously simple walk animation. And I mean painfully simple. Just a hip joint and two leg bones with three key frames cut the frame rate by almost 20%. I was forced to implement a cute little mesh morph system that, while we instantly fell in love with, just didn't cut it for our other projects.

We were planning on a slow shift to Shiva after being blown away by the results of the Bubble Time port. The idea was to finish the current iOS project, spin off a desktop version, and do the other episodes in the series all in Unity. After all, I'd already built out over 80% of the code. The ai, path finding, state machine, scoring, weapons, networking, damn near everything was already done. All that was left to do was plug in the assets, fill in the blanks, and add some polish.

That's when we got "the call." An old colleague, who has a Unity source license, called and ranted for almost an hour about the buckets of joy he's been having rewriting the core engine for his current project. I'm not going to go into all the gory details because I'm not sure if his team is under any kind of NDA, but I will say the root of the problems seems to be that the core objects (GameObject, Time, etc.) aren't threaded and are managed in some bass ackwards way. Apparently making a call to one of these objects locks them all until the process is finished. In other words, if you were to do GameObject.FindWithTag(), you have to wait until that's done before you can get Time.deltaTime. There was also some mention of the animation code being a massive bottleneck but I won't get into that for reasons already mentioned.

Which brings us to Shiva. I have to say, I'm still not a fan of their editor. At a minimum resolution of 1650x1200 on a 27" monitor it's fine. Anything less and it's almost claustrophobic. I've mostly got my head around all the quirks though, and Lua is proving to be a lot easier to get used that I expected. I'm a firm believer that any programming language without braces is a child's play thing, but whatever. Lua works, the editor sucks, and the engine is amazing. It's pretty, it's fast, and it's lightweight. Did I mention setting up a nav mesh took me less than minute and didn't require a community-built plugin that has massive memory leaks and core dumps like Windows ME?
Porting From Unity to Shiva: The Outcome September 16, 2011 10:55pm
Well it's been a while. Shortly after I picked up Shiva my wife and I had a couple more kids and my free time turned to nothing. As a result my game dev hobby was put on hold. Now they're more autonomous so I finally got around to porting an app from Unity to Shiva.

Anyway, I just wanted to post the results of my porting experience and ask a question or two while I'm at it. I've only done my top-seller so far, but plan to do the rest as time permits. The app in question (for context, not promotion) is Bubble Time. The reasons I picked Bubble Time are:
  • It's the simplest app I've made so figured it wouldn't take too long to complete.
  • It recently started selling 400 units/day so I wanted to update it to keep up the momentum as well as make it a better app.
1. Development Time:
This is the total time of development only. This includes setting up the project in the respective tool, importing the assets, scene setup, prefab/model setup, attribute setup, and actual coding. To be a fair comparison, this does not include conceptual design, logic design, or asset creation.
  • Unity: 9 hours
  • Shiva: 4 hours
2. Performance:
This is the real world performance of the app as tested on an iPhone 1G and iPod Touch 2G.
  • Unity: Animation of the bubble is smooth overall, but can stall from time to time causing them to appear to jump suddenly. Tap popping works fine, but is not perfect. Trying to pop several bubble quickly will always leads to missed taps and more jitters in animation. Often times you must "lead your target" by tapping above the bubble as there is a noticeable lag from tap even to raycast. As can be seen in the screenshots on the AppStore the image quality is suspect. The outer edges of the bubbles are noticeably ragged and somewhat blurry. The inner area of the bubbles is also cloudy and dark.
  • Shiva: Animation is very, very smooth. I have witnessed no slowdown whatsoever with the animation. In fact I have increased the limit on maximum bubbles and still haven't had any issues. The tapping is amazing to say the least. This is what shocked me the most. I can literally roll my fingers (successive tapping with many fingers in sequence) on the screen as fast as I can to pop the bubbles. Not a single missed click and no need to "lead the target." The image quality was the second most shocking thing. The bubbles are super crisp, clear, and bright. Definitely as good as viewing the actual image file on my computer.
3. Build Size:
This is the size of the .app file, uncompressed, then with "the formula" to simulate final size on the app store. For those who are not aware, "the formula" is uncompressed executable from inside the .app package + remaining package compressed + 100k. This usually yields a result within a meg of actual in-store size.
  • Unity: Uncompressed .app file is 16.2MB, while the formula yields 13.5MB. Final size on the store is 12.8MB
  • Shiva: Uncompressed .app file is 9.5MB, while the formula yields 8.2MB.
So yeah, I'm still kinda in awe over the whole thing. I really didn't expect it to go so fast, especially since I hadn't even opened the Shiva editor in about a year before getting back into game dev a few months ago. More so, I didn't expect the performance. I figured the app would be smaller in Shiva, but I honestly expected it to run like ass on the device. As a realist I'm not expecting such a huge contrast with my other ports, but I'll definitely expect good things from now on.

Now, I did notice something strange during this whole thing. Building the .app file straight from the UAT resulted in a 18.1MB file which only shrunk to 17.8MB after the formula. The great build size I finally got resulted from building a Xcode project in the UAT and compiling from there. I didn't change any settings in Xcode either, just pointed to the right Provisioning Profile and hit Build & Run. Is the huge size difference normal? If so, why?

Anyway, there it is. Overall I'm obviously very pleased with the outcome. So much so that I plan to leave a "Powered By Shiva" blurb and logo at the bottom of my own splash screen.

UPDATE: So the update for Bubble Time was finally approved. Final download size came out to 7.2MB.
Unity + Dynamic Batching = Broken August 13, 2011 7:47pm
Last night I decided to experiment with dynamic batching in hopes of getting some extra performance out of Belt Runner. Rather than risk breaking my game and pushing back the deadline I dusted off an old one: Bubble Time. After converting the project to Unity 3.3 I saw that the bubbles were already getting batched. I thought, "This is supposed to be impossible," seeing as how each one was a different scale. I went back to Belt Runner and puttered around with my asteroids, then plain cubes, and even the same bubble prefabs for hours without success until it hit me: The bubbles were not 100% uniform!

Since Bubble Time is essentially 2D the bubble prefabs were only being scaled in the x and y axes. Each time I manually scaled the z axis to match the x and y, however, that instance was removed from the batch and placed into a new draw call. I played with the numbers a little more until I finally found the tolerance level. I then applied the same theory to Belt Runner and it worked. I am now averaging 15 draw calls with batching instead of 24 draw calls without, which gained me an average of about 5fps on the iPhone 1G.

So why does it work? A better question, perhaps, is why doesn't anyone else seem to know about it? This topic has been bouncing around the Unity community for the past two years. Two years! Common knowledge has been that an object must be of uniform scale to qualify for dynamic batching. In fact, Unity Tech's own developers and qa people have publicly stated this. Why does a guy writing apps in his free time know more about a product than the company who makes it?
Unity + Object Oriented Programming = Broken (wtf?!) August 8, 2011 2:40pm
My 6th full game went gold yesterday, and I was just going to write up the tilt controls for the mobile version when I was hit with an unexpected setback: EXC_BAD_ACCESS. It took me several hours of debugging and experimenting with workarounds once I'd figured out the problem, so I figure I may as well gripe about it.

I have a Main controller class that handles states and contains some common methods that get used a lot by other classes. One of these methods is a scene loader/state setter. In one of the scenes I had a Menu class and a few UI element classes. The UI element has a reference to the Menu class which has a reference to the Main class. I got the segfault when doing:


In other words, I was calling the method UI.Start() which did a few local things then called Menu.StartGame() which did some other local things then called Main.setScene(). I think it was crashing out because UI didn't have an explicit reference to Main, only a connection to it through Menu. The reason I came to that conclusion is when I copied the scene loading and state setting functions from Main into Menu.StartGame() the problem went away.

Now keep in mind this all worked 100% on the desktop. It was only when I built to iOS that it was getting a segfault. This process isn't happening on Start or Awake, but as an explicit function call. So anyway it seems Unity's C#/Mono implementation for iOS is broken. No word from Unity Tech on a fix, or if they're even aware of this issue.
Using SVN With Unity -or- No, You Don't Need Unity Pro March 19, 2010 2:48am
I started thinking about a svn solution yesterday and am happy to say it works in the Indy/Free version. I've tested it with my teammate and with porting PC projects to iPhone and it definitely works. The only caveat is you must close the Unity editor before performing svn operations that will affect the Library.

Assume you have a project named prj-1. The directory structure might look like this:


All directories and contents can be committed to svn EXCEPT for \library. You can either set \library to be ignored or just never commit it from the beginning. With the UT editor closed, zip up the \library directory and commit the zip file to svn. After doing any svn updates, unzip the library.zip and overwrite the existing library folder (i actually delete \library before unzipping). The first time you (or another team member) check-out the project you will need to manually open the scene file.

Now that you've got the structure set up you can either a) work from the source controlled directories within the UT editor, or b) svn export the project to a separate directory for editing within UT. With option B you can do frequent commits and updates without the need to close the UT editor provided you haven't made changes that will affect the Library (modifying assets, and most script changes are safe).