Vanilla Code Snips

Code snippets and development adventures!

Leave a comment

Bug tracking with Bug Purge

I’ve been working on a game along with my (very) small team and I needed each member to participate in the bug reporting process when running testing sessions. Of course, I also needed a comfy solution to track bugs myself. As the title suggests, what I stumbled upon and decided to use is Bug Purge. At the core and on the outside, Bug Purge is very simple and its quick workflow won me over. What follows is a quick overview of what Bug Purge allows you to do.

As a user, you’re able to get involved in multiple projects (either create one yourself, or receive invitations to existing ones). Projects have bugs, so that’s where you’ll be finding the things to purge.

As expected, one isn't limited to a single project.

As expected, one isn’t limited to a single project.

Submitting bugs is straightforward.  Each bug has a description, additional notes, a person assigned to fix it and a fixing priority. You also have the option to attach a screenshot to the submission (and add notes on it), to help whoever is in charge of fixing the bug reproduce it more easily or better understand what’s happened. Bug Purge allows you to paste it right in, so no need for extra clicks and browsing.

Project-wide overview in Bug Purge.

Project-wide overview in Bug Purge.

Bug Purge also keeps track of your past bugs, and thus, it acts nicely as a mean to view your project’s progress over time. As an extra, you are permitted to change your page’s color scheme and use your own logo to make it feel like home.

My experience with Bug Purge was pleasant from the start. No noticeable issues regarding its functionality, and the guys behind it were always easy to get in touch with and promptly replied to all of my messages.  That said, Bug Purge might be too simple (read: too limited) for some. It certainly won’t survive in a battle with the top dogs in the industry. But it doesn’t have to, really. It plays well in its own league, and for users like me, it’s the perfect tool for the job.

Be sure to give it a try at and share your experiences in the comments section below.


Leave a comment

Diagrams in game development

I like to think that everything around us can be represented, one way or another, through a diagram. At the most obvious level, we can define a linear diagram representing the state transitions suffered by a particular object throughout its lifetime.

Naturally, I use diagrams in game development. And I do so quite a lot. They’re not necessarily standardized, and some of my diagrams are at a very high level, feeling like mind maps.

As a first post here, I’ll present some of the diagrams I used so far. Click on each to enlarge.


This one is pretty obvious. It’s a fragment of a larger diagram, mapping objects in a game by property inheritance. It’s intended to guide the implementation of some particular interactive objects in a game, while being simpler than a full fledged UML. Interactive Object is the base class for its descendants and so on.
A similar format could be used to present the player with a map of related objects. Perhaps in the game’s manual?


The FSM (finite-state machine) is a great model to base certain objects in games. The above FSM diagram represents a spike trap. Spike traps look like this:


And in case you want to add one to your game, there’s a nice animated spike trap model right here (the picture was taken from that page too, but don’t tell anyone!).


This is a handbook diagram (named this way because it’s intended to be a come back to it often diagram) that I drew recently. It outlines the components of a game, and also helps with gathering the required assets, as you can see immediately what’s needed and what isn’t. I recommend these on small projects, as they get pretty huge on big ones. They can be broadened further though, so that may fix things.

When I go to a lower level, it’s usually because I need to plan the most intricate aspects of my architecture, and I usually deal with UML here. I never concentrate on outputting absolutely clean and complete UML though. I’ve adopted what I liked the most about the UML convention and the result is simple and does the job for me, but I wouldn’t go with it in an environment where actual UML is expected, for the obvious reasons.

I won’t be sharing any UML goodness, as I’m sure you can find plenty of it around the web. Mine is a subset of whatever you can find – we’ll leave it there.

Another situation when I have to go to a lower level is when I have to describe actual algorithms. I use what I call flow diagrams. It is a format inspired by the diagrams used in white box testing.

A sample for the spike trap would look like this:


This is normally the final layer between diagrams and actual algorithm implementations. If the need arises, I detail the flow diagrams further (with extra executed instructions), and deduce or estimate complexity, and build accurate test cases. I also prefer diagrams over pseudocode (when the latter does not outweigh the first in simplicity).

For those wondering, all of these diagrams have been drawn with the freely available, cross-platform yEd, that you can download here. Quite my favorite tool for such things. It’s perfectly smooth and user friendly.

Note: This article is meant to be updated regularly, with more diagrams added to it, as time goes by. The article went through 1 revisions so far.