The Priority Approach

When I was in CS 101 as a college student, I had a marvelous teacher who introduced us to the process of making a computer program with a short, simple list. The purpose of the list was to prioritize the tasks that go into writing software in a high-level way.

I have forgotten the exact list he put on the white board,  but over the years I have behaved according to how my memory paraphrases it, and I have found endless benefits in doing so. Over time, I came up with my own version of the list, and it goes like so:

Make it,  Fix it,   Clean it,   Ship it,   Shift it.

Harder, Faster, Better, Stronger
Harder, Faster, Better, Stronger

1. MAKE IT do what you want. There are no rules. There are no programming standards. There are no comments. Make the thing.

2. FIX IT because it will surely have a ton of bugs.

3. CLEAN IT with comments, refactoring, and all the other stuff you ignored in #1.

4. SHIP IT unless you have extra time to…

5. SHIFT IT into higher gear with optimizations. Which you should spend time doing later anyway for future versions.


There are two reasons I have come to swear by this approach. First is the business aspect. At any workplace, you will have deadlines. So which would you rather show your boss if you run out of time: a fully functional program that is slow and poorly written, or a well written, optimized program… that doesn’t do anything? As long as you did step one, you have something to show.

The second reason is personal sanity. Many programmers will try to make their code neat and tidy and optimized as they’re coding. I was guilty of that for a while, myself. I’m not saying you shouldn’t be aware of good practices and doing them when it suits you,  but what happens if the very basic way your software works has to change halfway through? That means you have to scrap comments, code, functions, and optimization work because ‘whoops, I didn’t need to do that part’. By getting it done in step 1 ASAP, you see it functioning and can fully judge whether your solution is itself applicable to the problem. THEN it is safe to spend all that time cleaning up.

The Language Question

Recently I was amused to read an entry by Jason Bock, entitled “If Carpenters Were Hired Like Programmers.”  Here is my favorite excerpt:

Interviewer: Yes, I understand that, but can you give me an idea of how much experience you have with brown? Roughly.

Carpenter: Gosh, I really don’t know. Once they’re built I don’t care what color they get painted. Maybe six months?

Interviewer: Six months? Well, we were looking for someone with a lot more brown experience, but let me ask you some more questions.

Carpenter: Well, OK, but paint is paint, you know.

For those who do not follow the metaphor, it goes like this: there are many technologies in the world, from operating systems to programming languages. However, they all share the same fundamentals. It can take as little as a few hours for an experienced programmer to write something functional in a language they’ve never used in their lives, simply because they have Google and a good grasp on the ten thousand foot view of programming. As such, it can be very frustrating when an interviewer is critical that you haven’t used the -exact- technology they use, even when you’re confident that you’ll pick up an run with it immediately. (For non programmers: Imagine not getting a job because you use Firefox and they have Chrome installed on all their machines. That can be what it feels like. )

I definitely empathize with the frustration of it all. But I want to inject a little realism here, too. Unless you’re some sort of mega genius who can learn every paradigm just by looking at it, the metaphor is not a complete 1:1.

First, as a programmer, you cannot claim to be able to jump between languages unless you have an understanding of a range of language types. I divide them first into three categories: compiled, intermediate, and interpreted. On top of these, they can have dynamically typed or statically typed variables.  This creates a total of five different paradigms for programming, each with its own workflow, benefits, and nuisances.

Yes, OOP works the same, and so do loops, if statements, even variables on some level. All the design patterns are the same, too.  But languages aren’t simply ‘colors of paint’.  If you use C++ your whole life and try to pick up Ruby, there are a whole lot of things about managed, interpreted and dynamically-typed languages that will surprise you and slow you down at first. And the length of that learning stage concerns anybody writing your paychecks. I would recommend to any programmer who wants to be flexible, experience each of the types I mentioned: compiled, intermediate, interpreted, dynamically typed, and statically typed. At that point, yes, it’s not hard to jump between technologies…


Some languages are still, and will always be, a bit of a caveat. If you know Java, C# is not going to give you much trouble. If you know LUA, then Ruby or Python will probably come to you pretty quick. But if you get assigned to Assembly, Fortran, or (as I just found out) Javascript, you’ll find out that some things feel like you just entered a psychedelic dimension of madness. For example, if you’re used to an OOP language, go learn how you do polymorphism in Javascript. I could do a whole blog on that one.

Finally, the longer you use a language specifically, the more correctly and efficiently you code in that language. That one does not carry over from one language to the next (normally,) and employers are keen to this. You may be able to make software do something in good time, but did you do it according to standard, efficiently, expertly? Probably not. The other programmer who has 5 years of experience in said language is probably going to write what you did in half the lines with twice the readability.

I suppose I’m trying to tell fellow developers… or maybe myself… to be a little patient with these questions. Yes, there is a very good possibility of a company losing a real asset by denying somebody who has great experience in all the ‘wrong’ areas. But you have to be ready to work extra hard to adjust your skill set to that which is new. How you show them that you’re capable of this, well… when you find out, let me know :P

Game Jam 2015!

Lately I’ve been unwinding from a very long, difficult, and extremely fun time at the Nashville chapter of the Global Game Jam. The folks over at Black Gate Games led the charge, so here’s a very large shout out to them for organizing it. I’m sure their efforts will help establish them as a central part of Nashville game development industry, which is well deserved.

So first, confession time. When I was initially invited, I only planned to stop by at first. I am unemployed, so I figured it was a way to make some new contacts and perhaps impress some existing ones. Frankly, I would have not considered going otherwise; I’m one of those really flaky introverts that sort of talks his way out of going anywhere with anyone a lot of the time. But after I arrived, met people, and watched the awesome keynote, I felt inspired. Here were close to a hundred people, comprised of children with big dreams, adventurous mothers, students, and experienced game developers. The creativity borne of diversity was palpable.

As it turns out, I ended up participating all the way through, spending virtually every waking minute of my weekend working on a project and socializing with people like me. And you know what? I was never exhausted enough to really be glad it was over. But it wasn’t just the event itself. It was the realization that there is such thing as a game industry in my area, and I really do have a place in it.

Over the past few months, due to the perceived job market here in Nashville, I have been learning databases and web development so as to find work. Relocation is a difficult thing for me at this time, after all. But while I enjoy many different types of programming, I will always have a special passion for the special kind of creativity that goes into game development. A coworker once told me that it doesn’t matter what you are creating, programming is always the same. But that isn’t true. As you watch your output, the amount of pride you take in the fruits of your labor depend very much on your interest in it. At my last job, I was twice as productive when I came home and worked on my own things than I ever was at the office. I hate to admit that, but that’s how it is.

So in my first ever experience working with an awesome team on an actual game, I found myself buzzing with excitement. I want to do this for a living, and with this many developers right here in the Nashville area, I know it is possible. Even if some of us have to just get together and start on our own, the talent to get a ball rolling is right here. This changes everything.

So that’s what this year’s jam, my first ever, meant to me.  I think we made a rather interesting little game, if simple – but hey, it was done in two days.  Take a look if you’re interested:

Zow Gow: Super Jukebox Bot’s Find your Crate Adventure  


I have always had an odd relationship with mathematics. Even though I began programming when I was a young child, I had a difficult time in math. By the time I got to college I was so upset with the math requirements for computer science that I went the route of an English major. Not my best moment. It was a passive and somewhat naive decision, and in my junior year I started focusing on the CS major… but as soon as I finished the BA, boom, I landed a job, and it’s been over five years since formal education.

And how I railed about those math requirements. “Hey, a computer does math for you, why should we have to learn this stuff?” And likewise, I noted, math students in the computer science courses (a requirement at MTSU) had similar gripes. If I was blogging at that time, I would have probably had a whole bunch of arguments against any comparison of the two fields. And to be sure, they are different fields, at least unless you are specifically programming mathematical applications (and really a pro mathematician should be supplying the algorithms if that is the case).

I’m not a kid anymore but the thing about kids (I consider college me a kid) is they may have incorrect conclusions, but there is always something to what kids have to say. I was so challenged by math that once I broke down in tears in High School over geometry. But just today, I (warning, codespeak) used raycasting in the local opposite forward (z) direction and the global y direction to make an object automatically turn corners when leaning into them. Didn’t even break a sweat. So what happened between then and now besides just getting older? And why were those math students so stressed out in CS 101?

I have concluded over the years that there are two routes to problem solving. The step-wise refinement method, and the research method. In schools, we almost always learn the research method. We are asked to memorize formulas, and apply them to numerous situations repetitively.  I’m not saying mathematicians, like those in that class, are just regurgitators of past ideas. They work to both build upon and apply formulas to real world problems by expanding on the research, like scientists and other very important people. And it’s probably helpful for them to do some step-wise refinement. But I don’t think it’s how they normally approach a problem.

And as for me, well, I don’t exactly remember any math teachers telling me WHY numbers work, or WHY geometry functions like it does so that I could problem-solve it with logic or break it down into a procedure. If you want to see just how little the public understands numbers and how much they are taught merely to memorize things, try explaining counting in a different base than ten.  Even though the process is the same, because logic is always the same,  because math is always perfect… it is a curve ball.

I’m not offering any suggestions for the education system on how to fit more to everyone’s mold without losing people.  Maybe that kind of understanding is difficult for the general public, and memorization just gets the grades up for the usual ‘I hate math’ kid (i.e. 90% of them.) Or maybe there really is something wrong with the way it’s introduced. All I can say is that if you’re a young programmer, yes, math matters, but no, you don’t need to memorize every formula on earth. You have Google, you have innovation, you can do it. But please, wriggle through it in college… don’t cast your on-topic degree aside like that.

Tutorial: Runtime Variable Management in Unity

When designing a game, you will often have some runtime variables to be concerned with. Did you talk to that person? Did you unlock that door? What did you name your dog? These are just a few possibilities of what you might need. Not only should such things be easily managed, but they need to be serialized to and from game states so that the player can save and restore their game.

For the sake of self-education, I avoided the Unity asset store and decided to piece it together exactly as I like it. I liked the principal of RPG Maker’s flag tables, but I also love how one of Unity’s best features is being able to view and modify the game as it is running. I wanted all my variables to work the same way. What if I’m testing and I forgot to do something that is required to progress to what I’m interested in? I don’t want to have to restart, just let me set the correct flags and keep moving.

In order to achieve this, I needed a manager that could do the following things:

  • Edit and view my variables on the fly while play testing
  • Save and load the flags to a file stream, so I can easily add them to a save state.
  • Easily access them from the code anywhere I want

My solution: A singleton class holding a list of template objects, where each handles how it draws to the Unity Editor in a different way. This guide will show you how it works. See the link at the bottom for the full source code, free to use in your own project.


Extending The Unity Editor

Whenever you extend Unity with a script, you need to remember that during runtime, you will no longer be in the unity editor environment. That means that you will need to #ifdef your code to prevent errors:

using UnityEngine;

using UnityEditor;

using System.IO;
using System.Collections.Generic;
using System.Runtime.Serialization;

Any code using UnityEditor functionality, including GUILayout calls (which are used to create unity editor interfaces) must be encapsulated in this manner. The only alternative is to stick it in an ‘editor’ folder, but it won’t compile as part of your final game, which is less than desirable.

We will also need a small class which inherits from EditorWindow. Unity lets us add this window to the UI in all sorts of ways, but lets add it to the dropdown ‘Edit’ menu. Look how small this class is:

// Allows menu based editing. Don't need to do anything, just go to Edit/Flags
public class FlagManagerEditor : EditorWindow {
 public void OnGUI() {
  this.Repaint(); // For some reason this is needed to initially draw the thing.
 [MenuItem ("Edit/Flags")]
 public static void ShowFlagEditor() {

The ShowFlagEditor function triggers when you click Edit/Flags now, opening this window – fully dockable, too! Of course, this by itself will give you an error since it wants to use a singleton called FlagManager in the OnGUI() function. Well, let’s make that now.


The Main Class

I’m going to call the variable management utility FlagManager since it’s good and short. Yes, it holds variable types, not just booleans, so sue me.

FlagManager follows the singleton pattern, but it doesn’t have to be a scriptable object or anything like that. It doesn’t even have to attach to a game object. It is a permanently existing component to the game.

public class FlagManager {
 private List<FlagRecord> records = new List<FlagRecord>(); // The records

 // Singleton pattern 
 static private FlagManager instance = null;
 static public FlagManager Instance {
  get {
   if(instance == null)
    instance = new FlagManager(); 
   return instance;
 private FlagManager() {}

There, a very simple singleton. I introduced another class, FlagRecord, which we’ll get to later.

Now for it’s OnGUI call, which uses Unity GUI commands to draw to things your interface. Remember: this only ever gets called and only can be used in the editor, not for a standalone executable. Another #ifdef fixes that:

 public void OnGUI() {
  foreach (var record in records) {

Each FlagRecord in our records list will handle its own drawing, because after all, how do we know what kind of input to allow? A number slider is different than a checkbox or a text entry box.

Nevertheless, we can add ‘new’ buttons directly after the foreach statement. They will go at the bottom of all the flags that way:

 if(GUILayout.Button("New Boolean"))
   records.Add(CreateRecord("__TEMPBOOL__", typeof(bool)));

And thus we need a CreateRecord function:

public FlagRecord CreateRecord(string key, System.Type type) {
 if(type == typeof(bool))
  return new FlagRecordBoolean(key);

 return null;

Notice that in the last two functions I put ‘if’ statements. This is because you can extend both OnGUI and CreateRecord to handle new types in the very same manner. The full source code at the bottom of this tutorial supplies strings, integers, and floats. But for now, let’s focus on booleans.


The Flag Records

Now we need a typeless FlagRecord class. You can’t directly use them, so it’s going to be declared abstract.

public abstract class FlagRecord {
 public string Key; // Name of this record
 public FlagRecord(string keyName) { key = keyName; }

  public abstract void OnGUI();
 public abstract void SaveToStream(Stream stream, IFormatter formatter);
 public abstract void LoadFromStream(Stream stream, IFormatter formatter);
 public abstract System.Type GetValueType();

It has a key, but no value. Not yet. But now the main class can aggregate our records. Next, we need a template subclass:

public abstract class TemplatedFlagRecord<T> : FlagRecord {
 public T Value;
 protected bool shown; // So that we can collapse and hide flags

 public TemplatedFlagRecord(string key) : base(key) {
   Value = default(T);
 public override void OnGUI() {
  shown = EditorGUILayout.Foldout(shown, Key);
  if(shown) {
   // Now create the editor for the value based on type
 protected abstract void createValueEditor();

 public override void SaveToStream(Stream stream, IFormatter formatter) {
   formatter.Serialize(stream, Key);
   formatter.Serialize(stream, Value);
 public override void LoadFromStream(Stream stream, IFormatter formatter) {
   key = (string)formatter.Deserialize(stream);
   Value = (T)formatter.Deserialize(stream);

 // Retrieves the type of value held within this flag record. Do not override.
 public override System.Type GetValueType() { return typeof(T); } 

NOW we have a value… of any type we may need, too. And thanks to C#’s great type system, we can even initialize it to a default value.

If you’re not familiar with GUI functions, the ‘Foldout’ will display the key name next to an arrow that can be expanded or collapsed. You’re also DONE when it comes to serializing any of these flag records, as long as their type knows how to serialize. For basic types, this is always automatic.

So, finally, here’s the boolean flag class:

public class FlagRecordBoolean : TemplatedFlagRecord<bool> {
 public FlagRecordBoolean(string key) : base(key) {}
 protected override void createValueEditor() {
  Value = EditorGUILayout.Toggle("Value", Value);

That’s all there is to it.

Taking it Further

I did not include the functionality to actually set or fetch variables, rename them, preserve uniqueness in the names, delete them, save all flags to a stream at once… etc. I wanted the tutorial aspect to quickly show how a list of variably typed fields can be managed and displayed in the Unity Editor in real time.

The complete, functioning code is available here.


A Letter To Myself (aka new Unity3D users)


Dear me about a year ago,

There’s no mistaking how much easier it is to use an existing engine for game development. Even something like Ogre3D, while greatly simplifying the rendering part, is bare-bones. Unity, Unreal, and other systems give you rendering, controls, and most importantly, scene editors. But there’s two major gotchas you need to know about before going into an existing game engine. I can only verify that they are true in the case of Unity, but I would always go to the table with them in mind.

#1 – You are stepping out of the loop

When I first started my project in Unity, I went in with a few needs. One of those needs was that any two scenes in the game could be loaded at the same time, invisible to one another. All I can say to anyone who is going to attempt that is, you might want to contact me about it. Additively loaded levels always load in at their local geometric space, and moving them with a translation affects cloth. Let me tell you, it was pretty awesome watching all my cloth tear itself free and fly off into space. And using layers had its own list of problems. I solved this, but it took a ton of work – whereas I was able to prototype the two-scene concept in 2D with ruby and Gosu in, oh, about four hours. Wow.

To summarize, by using Unity, you are stepping out of the main loop. By using an SDK, you are sacrificing your god powers as a programmer and relying on the engine to make a consideration for your specific need. This isn’t true with an engine like Ogre3D. With libraries, you are offloading work onto existing code. You still own the program. Before you give up that authority, make absolutely sure the engine you’re using will support your specific needs, particularly if they are unusual.

Why did you think companies still make proprietary engines internally? To burn money?

#2 – Everything you know is wrong

My biggest handicap as a programmer is perfectionism. I took a lot of the ‘proper’ programming practices to heart when I was in college, and I strive to follow them. I could write a whole blog entry on this topic, because I have come to think trying to program great code ends up adding unnecessary length to the process. They’re important guidelines, but sometimes you have to remember that the goal is a functional, maintainable application. Not to perfectly and pedantically compartmentalize everything.

And then you have Unity.

I could never have guessed how different it was to program in a component-based manner. In Unity, you attach scripts to gameobjects. You do not have scripts that are always executing no matter what scene you launch from – you have to get sneaky with singletons to pull that off. All script execution starts and updates from those gameobjects, and in an arbitrary order by default. And forget cutting off access to any of those game objects; you can look up and access the public members of anyone from anywhere.

I discovered that it was much easier to maintain my code by breaking most of the guidelines I cut my teeth on. I gave classes multiple jobs divided into different files using the c# partial keyword. I created singletons. I publicly exposed member variables. It’s just easier.

I think if I had been aware of all this going in, I would have saved some time. So I send this letter out hoping it helps prepare someone going in. Using Unity is NOT a normal workflow if you are trained in programming directly, even if you use an interpreted language. Though it isn’t without its benefits. If you can work within the limitations of the engine, being a part of the program instead of its core developer is much less work. If it starts to feel like more, you’re doing it wrong.

Literally yours,


Genetic Algorithms!!

In programming we’re often told not to reinvent the wheel (i.e. if someone’s done it, don’t do it.) But I have always felt that a little reinvention was the best way to truly understand something. The way I see it, if you can discover the big picture from a basic concept, you will be more intimate with the process and therefore prone to do something innovative.

With that in mind, I started a side project with genetic algorithms… and I decided to approach it by not researching the subject one bit. Now, I already knew that it the idea is to mimic evolution, and that it involves generations, mutation and calculated fitness values. So with that in mind, I basically ended up with a design that was pretty close to the standard, albeit my naming convention came out different. What most such algorithms call a genome or chromosome, I referred to as a gene. I refer to my organisms (a solution of genes) as cells, and the world they exist in as my petri dish.

I’ve learned that there are different approaches to the process of the genetic algorithm, but I took a Darwinian approach because I’m familiar with his theory. I don’t know the others (Lamarckian / Baldwinian) but I will do more research sooner or later. Anyway, my cells mate in randomized pairs and pass a mixture of their genes on to offspring with a chance of mutation or newly spawned genes. At each cycle, I kill off all cells that have below or equal to the average fitness value, which is up to 50% of the population. Then I replace those with offspring and start over. Eventually, sure enough, my fitness values end up quite high, especially as more generations die and mate. I refer to my best fitness cell as the ‘hero’ of the  current set.

I break numerous rules of nature, such as having a fixed population for all generations and having no mating rules whatsoever. There are also no catastrophes, lifespans or gestation periods because I don’t see these as valuable to trying to reach a solution. Perhaps I am wrong.

Anyway, I’m really having a blast and considering a GUI-based G.A. library of sorts that could aid me with my experiments. I hope this doesn’t cut in to my game design time too much. :)

Window of Opportunity

As an adventure gamer I’ve heard a lot about the resurrection of the genre through the existence of tablet computing. There are two features that make this possible:

1. Lower standard of graphics means that traditional 2D sells just fine, and that seems to function better than 3D in the genre.

2. The touch screen is ideal for inventory puzzles and other forms of problem solving.

Okay, so the second one is going to always be a thing. But with a heavy heart, I have to say that I lack faith in the staying power of point #1. Tablets are about to get increasingly powerful. Even Google’s cheap-o Nexus 7 has four cores in it. And Microsoft wants them to basically be full computers that just happen to fold up nicely with a touch screen.

While you need other peripherals to really enjoy a third person shooter or massive RPG, I think there is a very small window of opportunity here. Many adventure game legends, through kickstarter, have wisely jumped aboard this ship but I think for many upstarts like myself, it’s going to have sailed before anything can be pulled together. I fear that this does not provide lasting hope to the genre, unless it improves graphically and makes the absolute tightest use of touch-screen interaction. This has yet to be seen.

As It Begins

I have begun the frightening business of designing my own game, so this blog will largely chronicle my process for a while.

This is a big and potentially risky thing to do, so I am beginning small with what I am tentatively calling my Game Pitch Document. This will essentially be a short GDD (Game Design Document) meant to interest those I pitch it to. Another consideration I have made is to rapidly prototype the actual gameplay. For this I will probably use unity since it is getting to be good to know how to use it. This approach also helps show that I am capable of developing as well as designing.

The delightful Lori Cole, a huge inspiration of mine, let me know that there is a book called “Art of the Start” which I will be getting. I have also found numerous internet resources that have been immeasurably helpful. My only concern is what I have learned about the compensation game designers get – another reason to make sure and get an actual salary job programming for the thing. From my understanding, getting 5000$ is considered ‘good’. I would rather kickstart the game myself and at least be in control of an IP that means immeasurably more to me than such a pittance. But we shall just see.