Stack-Ranked Lists and You

March 24, 2014 at 9:25 am (Computer Science, Game Development, Programming, Rant, Teaching) (, , , , , )

If you are a professional software developer, you may be familiar with development methodologies. You may have encountered such beasts as “Agile”, “Waterfall”, or if you own a time machine, “Extreme Programming”. These are all just different ways of organizing your work. They let you decide on what to build and give you an idea of when to build it. They’re handy things to utilize and if done right, they’ll make you look younger*.

      *May not actually make you look younger.

So why am I writing this? Well, it isn’t to evangelize the way you should change your life and use what I suggest. It’s more to talk about one specific technique that’s pretty low cost and can help your cluttered development life, even for small side projects. Furthermore, I’ve found that it can help with motivation issues and help you force yourself to finish what you start. You’ve always finished your side projects haven’t you??

What I use now for my projects is a stack-ranked list. This is a list of all of the individual features that I want to implement in my software put in order of importance. Again, if you are a professional developer, you will probably begin to smell the Agile backlog here, but this is just a small slice that can offer a lot of value. First I will talk about the list itself and what that should look like and then I will discuss the idea of importance.

The feature list should be kept fairly granular in order to be things that you can achieve in a relatively short period of work time. You definitely shouldn’t go into such details as “change while-loops to for-loops”, but you should also try to break up tasks as big as “write rendering engine from scratch”. The idea here is that you can track what you need to do in an orderly fashion, but also when you’ve completed them, you get to check them off your list! Don’t sneer at this concept. Having something tangible (I mean, other than working code) that says you’ve completed something is a big deal. It’s a way to trick your brain into thinking it’s being rewarded. I go as far as to not even delete the task from my list, but I mark it in a different colour.

Lets switch gears and talk about importance. It isn’t a difficult subject, but it is ambiguous enough that it should be defined a bit better for this situation. To clear things up, “importance” is whatever you want it to be. I mean it. I choose importance to be not just how important the feature is to my final project, but what order it should be done so that other tasks can be completed. If you give each tasks a proper importance value (or “stack-rank”), then you can even do such exciting things as picking milestones to release demos for.

Now, how do we do this all? What does it actually look like? I use a Google Docs spreadsheet for my feature list. It has auto-save and it is accessible on any computer. I typically use different computers, sometimes in different places, so it makes sense to me to have access and not have to worry that my version is the most up to date one. In my spreadsheet, I have the following columns: Stack Rank, Task Name, Task Status, and Additional Notes.

For the stack rank, I’ve made it be just a number. 1 Is the most urgent, and 50 is the least. The range doesn’t actually matter; it’s just a way to sequence your features. The task name is a short description of what the feature is. Easy. The task status is a column that I’ve written conditional formatting for. When a task is complete, I write in the text “Completed” and the cell turns green to show how awesome I am. If I want to keep track of what I’m currently working on, I write “In-Progress” and it turns orange. I sometimes use a “Bug” status that turns red if I’ve broken something and I want to specify that it’s a regression to previous code, but that’s getting a bit too in-depth. Lastly, I have an “Additional Notes” column for quick ideas on how to complete my task.

Here’s some examples. I’ve been working on a game as a side project. It’s a zombie shooter/puzzle/adventure/overly complicated concept game. Here are some of the tasks I have had in my list:

2, Shootable Urn,  Player can shoot them and they shatter
6, Title screen,  Landing page and player goes here when they die
14, water dripping effect,  Use particle system
25, Melee attack,  Necessary for the game but not to get other things done

These are my tasks. Notice that melee attack seems like a pretty importance feature, but it’s at the bottom. Sometimes my importance value is more based on how fast I can get a feature completed. The idea is to make a complete game, and some features can end up using an open-ended amount of time. The melee feature was an open-ended one in this case. I had to do new character art, I had to add in the game mechanic, I had to playtest it and make sure it made sense, I had to balance the damage, I had to find SFX for it, etc. Shooting an urn ended up being super easy. I subclassed a Billboard Game Object class I already had and whipped up some art for an urn and a broken urn.

To close this lengthy article, what we all want is to work on interesting things and see them in a completed state. It’s fun to make them and if your idea was good enough, it’s probably fun to play with it. Stack-ranked lists could be something that could help you. Keep in mind it’s an open concept, so make this technique yours. Customize it to work better with your workflow. Say you have a small team, perhaps you’d want a column to say what Type of task it is: “Art”, “Programming”, “Music”, etc. Maybe it’s better to just write a developer’s name next to the task for a group project. Whatever. If you struggle with getting things completed and staying motivated, at least give it a try.


Permalink Leave a Comment

Quick and Accessible Inversion of Control

March 14, 2014 at 1:37 pm (Computer Science, Games, Graphics, Java, Processing, Programming, Rant, Teaching, Video games) (, , , , , )

So by now you’ve probably at least heard of the magical beast known as “Inversion of Control”. You may even understand what it is. If you’re in this boat, why aren’t you using it more often?? (if you are, you can read the rest of this article with your head held high).

There are tons of places on the interwebs where you can learn all about Inversion of Control (or IOC), so it doesn’t make sense to write up a detail explanation and then have people correct me on it. The short version of it is that it lets you defer your problems to someone else (future you for example). You allow the implementation to be abstracted in such a way that you can conveniently inject it in such a way that would make your college programming professor proud and/or confused.

For this example, I am going to use PicoContainer and Processing. PicoContainer is an IoC library for Java, although you could implement what it provides yourself through a variety of techniques I won’t tell you about here. The idea is just to show you a brief intro to what it can look like. In my example, I have a Graph object. It is the “M” of our MVC, and we want to separate the “V” from it. This means that the bit of code that draws the graph on the screen is going to be extracted. The kicker is that the way we abstract it will allow us to re-skin the graph in whatever way we want, whenever we want. We just inject a new view without changing the model layer and we’re good to go.

  This is our interface for abstracting the View from the model
public interface GraphView {
  public void draw(PGraphics g, Graph graph); 

  This is our Model: The object we want to abstract the view from.
public class Graph {
  private MutablePicoContainer graphConfig = null;

  public Graph() {
     graphConfig = new DefaultPicoContainer();

  public MutablePicoContainer getGraphConfig() {
      return graphConfig; 

  public void draw(PGraphics g) {
     // I'd recommend caching the view ahead of time to remove overhead
     GraphView graphView = (GraphView)graphConfig.getComponent(GraphView.class);
     graphView.draw(g, this);

Now here is the part that makes it all work. I’ve written this in Processing code, but it is essentially simplified Java anyway. In this snippet of code (although it is a working program if you include the previous snippets), I instantiate our Graph object and then inject a View. In this example I’m just showing the power of IoC by including an anonymous implementation of a View object. In the “real world”, you would have written it as a standard Java object.

import org.picocontainer.*;

Graph graph = null;
void setup() {
  graph = new Graph();
  graph.getGraphConfig().addComponent(new GraphView(){
      public void draw(PGraphics g, Graph graph) {
        g.ellipse(25, 25, 10, 10);
void draw() {

Now to summarize, we have accomplished our goal of abstracting the view of the graph from the data represented by the graph object itself. This means that we could completely re-skin the visual representation of our graph without touching any of our previously written code. If we wanted to draw the draw in 3D, we could just inject a new implementation. If we want it to be rendered using only ASCII characters, we got this. In the case that you still don’t see the value of this, consider a game you’re probably writing right now in your spare time:

You have a general “GameCharacter” class that both the PlayerCharacter and AiCharacter classes inherit from (Because you’re object-savy and generally good-looking). Both of these allow you to draw the characters differently. What happens when you decide to add new AiCharacters that act exactly the same, but look different? Well, you could throw in an IF statement and just check a state variable…. OR you could abstract the view, just like in our example! When you construct the AiCharacter objects, you inject a View object that will do all the drawing. As an object-oriented purist, you feel content, and as a game developer you feel pleased that you were able to trim off an “IF” statement from your render loop. You high five yourself.

Permalink Leave a Comment

Automated testing in game coding

March 10, 2014 at 9:38 am (Computer Science, Games, Programming, Rant, Video games) (, , , , , )

So my musings so far today have circled around the idea of automated testing in game engines. Automated tests are a series of unit or integration tests that can automagically verify whether or not you broke your code.Here is a quick explanation of both types of automated tests:

Unit tests are tests that isolate specific areas of your code and rigorously test individual parts. They typically pretend that the rest of your code doesn’t exist (usually accomplished via Mocking frameworks) and when you think about it, isn’t that how you’d debug a problem anyway? An example would be “Does this function in the class return the values I’m expecting when I give it input?”

Integration tests on the other hand function to test your code “as it is” for lack of a better phrase. It tests how the classes and modules of your code work together and whether or not your “business logic” is correct. An example would be “When 3 players connect to the server, does the database correctly log their actions?”.

Now, in game coding the typical idea is to get the game done ASAP and cut corners wherever possible since time is money. By this, I don’t just mean what big companies such as EA, etc. do to pump out new games every five minutes. It functions for all game development to a degree; if your game takes 10 years to be built, you’re probably going to have an out of date game and you’ll have to re-code at least some of it.

Do automated tests truly add value though? If you are a one-man shop, your argument is probably that you know the code intimately and that you stick to your coding guidelines (Thanks to Ruben for the argument). What happens though if you need to modify a really complicated system 6 months after writing it (while not forsaking the codebase in your day job)? Is booting up the game 40 times to do trial and error worth it more than a 30 second run of your automated test suite?

It most likely depends on your perceived usefulness of the tests. If you are just writing unit tests to verify that setPosition(1,1) actually sets your X and Y positions, then there probably isn’t any advantage. You’re likely to waste time building up a nice collection of tests to verify what you know. If however, you are concerned that your A* algorithm is a bit fragile and you’re worried that the AI would try to do something questionable on the game board, perhaps it might be a good idea while you’re working on the code to have some tests.

Keep in mind though, that the idea is to be able to verify without a doubt that the pieces of your code work 100%. If you don’t write your tests correctly or if you don’t even run them, then you’re only fooling yourself. Perhaps you have a good reason for fooling yourself though; perhaps at parties you impress people by telling them you have automated tests in your game engine code…



Permalink 2 Comments

Reservoir Dogs & Marvel: A Conspiracy Theory

March 5, 2014 at 11:33 am (Rant) (, , , , )

So I watched Reservoir Dogs last night for the first time. Among many other things, I couldn’t help but notice the connection with Marvel in that movie. An argument could even be made that this film has impacted more than one Marvel film.

The first film is a somewhat obvious one: Fantastic Four. In RD, Mr. Orange describes Joe as being like “The Thing” from the Fantastic Four. Now, let’s fast forward to the unfortunate FF movie from 2005. Do you see any similarities between The Thing and Joe? Thought so.

My next film is still a theory at this point, but the trailer for Guardians of the Galaxy certainly has the same cover of “Hooked on a Feelin'” in it as the scene in RD where Eddie is driving Pink, White, and Orange. There is also some speculation that James Gunn could be a fan of Quentin Tarantino, but we’ll see how that plays out when the movie is released.

Permalink Leave a Comment