Platformer Update 4

This week’s accomplishments are mostly of the bug crushing variety. I reduced the likelihood that the ‘no more jumping for you error’ occurs. I’m not convinced it’s completely resolved. What exactly is this error you ask, well let’s start with a screen shot (finally) of physics body debug render. The player is represented by the small square on top of the circle on the bottom about 1/3 of the way in from the left side.

Since jumping is conditional on having something to jump off of at present, the circle fixture checks to see if it has contact points near it’s bottom. if yes then jumping is allowed if not no jumping for you. At various times during testing the player stopped responding to jump commands while appearing to be grounded visibly and with in a few thousandths when the numbers were reported. The cause of this phenomenon is it seems that when Box2D contacts are reported to a libgdx box2d contact listener only the most recent contact point is retained.  So if the player is contacted from the side, by let’s say a box propelled by an explosion, the circle would record a side contact and decide it was hovering making jumping impossible. The solution I used was to shrink the size of the circle ever so slightly, so that the box now projects out past the sides of the circle slightly. This has eliminated current instances of this issue, but I’m not convinced all cases have been eliminated.

In other news Rho_Bot stopped by long enough to find a problem with the explosion system. Basically too many explosions (to put a number to “too many” somewhere 3-4 range) in rapid succession caused the program to hang while the physics calculations were completed. This was solved by limiting rocket ROF which was planned anyway.

Platformer Update 3

I’m beginning to remember why I didn’t want to do a status update post every week when we started this website.

It’s that what gets accomplished in one week tends to be easily summarized in a few words. For example this week I got projectiles working completely and explosions working partially (unless being able to walk on compressed air waves is a feature in which case explosions are done), and while someone who does game development would think that’s a reasonably productive week when combined with bug crushing. Those of you who are not developers are likely thinking, ‘that doesn’t sound like much. Why didn’t he do more? And where are the screenshots.’

Well the screenshots are coming … eventually. I could post some box2D debug renders, but that’s just a bunch of rectangles outlined with different colors. Ahh the days when someone around here did artwork.

Speaking of Box2D I’ve got more things to say about it. Some good some bad.

The Good

I used Box2D to implement the explosion. I think it is fantastic and reasonably straight forward now that I’ve done it once.

The Bad

Things get stuck at the seams of butted objects; not always but often enough to be annoying. This is a known issue and is supposedly being worked on. Currently suggested is don’t place objects contiguously. This means that loading a world tile by tile is a no go.

On first implementations of things I frequently pass bad data or make inappropriate calls to the Box2D world. This is a normal part of the development process however since I’m developing on java and Box2D runs in native libraries I get lovely unhelpful error messages like.

Process finished with exit code 255 (Box2D, java, libgdx)

Which I got when I tried to add a new object while the world was stepping.


EXCEPTION_ACCESS_VIOLATION (0xc0000005), AL lib: (EE) alc_cleanup: 1 device not closed – (Box2D, java, libgdx)

[Update] which was caused by attempting to address(dispose of) a body that had been disposed of.

I also had an equally unhelpful error when I disposed of a shape before instantiating a fixture based on that shape. I’m too lazy to reproduce this error so no console capture for that one.

Since these crashes happen in native code that means that lost objects aren’t cleaned by the java garbage collector, and it’s entirely possible they sit around causing a memory leak. yay. Oh wait that other thing, booo.

Platformer Update 2

Last week I mentioned screenshots for the platformer, and everyone here to see those will be disappointed, because instead of spending time adding content and updating graphics I decided to reorganize how level data is organized. Why exactly did I do this?

Because I could.

Also levels were defined in a combination of *.xml and *.json and I wanted to standardize it a bit. Now all level data is stored in a single *.json file. I also wanted to move level loading instructions into their own class. Previously level’s loaded themselves; however, the level class was getting long and moving the loading functionality seemed to be a logical way to split up the class.

So not  a very exciting week when viewed from the easily demonstrated progress dimension, but streamlining level files and improving class compartmentalization should make things smoother going forward.

Short term plans

Contrary to all appearances. Since starting my new job I do have a substantial amount of time work on games. I’ve just been doing other things.

Currently I’ve decided to let Malwrath stay on hiatus, and work on something new over the next couple of months. I have three reasons for doing this

  1. I’m out of practice reading and writing code. And since it’s always easier to start at the beginning than remember what’s going on in the middle. new project!
  2. I wanted to experiment with level loading which is something that will be necessary for Malwrath.
  3. I wanted to experiment with Box2d since it popped up on the list of libgdx options. And the idea of using a complete physics engine sounded neat.

So I’ve set about making a platformer (what better way to try out  a physics engine?) about a small robot who jumps over aliens who are on fire.

I’ve been working on this for a couple of weeks and what have I learned so far. Maybe Box2d is not the best back end for a platformer. To start with this guy at GDC points out that jumping in platformers rarely if ever follows a consistent physical model. There are also some other articles around the web discussing other issues with using physics engines modeled on the real world as back ends for platformers. Frequently sighted is how to implement platforms that move without having them fall. Box2d, fortunately, has a work around for this by having an object (body) type that doesn’t respond to external forces.  However after implementing all this I have a new issue which is the player sprite/physics object doesn’t want to stay on or ride platforms that move horizontally. And the solutions I’ve read for that all seem kind of kludgey.


There is no name yet, and maybe we’ll have some screenshots next week.

And I’m Back

The people rejoice. What did I miss???

*looks around*

Not much apparently.

What did you miss. Well I quit my old job, got a new job, and moved. And during the adjustment period let this slide a lot.

Rho_Bot got a new job and is still deciding if he’ll be able to contribute on an on going basis. But dropped off a bunch of graphical assets for Malwrath before leaving.

Optimus Composite got a new job and discovered he had no time for writing. He might occasionally join us in the future but will not be a regular contributor.

Malwrath May Update

Well this update is crazy late.

It’s been a month of working on Malwrath’s Tower. and we’ve made a decent amount of progress if not as much as I’d like.

Somehow I got tasked with the exterior ground tiles. So the basic tiles are done, but they still need to be blended at the edges. And the more I look at the grass the more low frequency artifacts I see; so, we might have to revisit that one. We’ll see when we get some more decorations on top of it.


In terms of code I’ve got the monster and the character mostly set up. A basic AI that can move the monster around. A solid path finding algorithm. And if you whack the monster with your gray stick thing it dies and re-spawns immediately. Anyway enough of me babbling take a look at some screen shots with my awesome placeholder rectangles.

Monster using path-finding algorithm to navigate around the wall
The rectangle monster is dead, and the people rejoice

And that brings us to the schedule.  Which is more or less on track although I did sop up a fair amount of buffer by reallocating it to extra blog posts I’ve done in April.


Coder’s Corner: Spatial Hashes

In our second installment of Coder’s Corner we’ll discuss SpatialHashes. For those of you thinking, “This got intense fast… last month was IDE setup – shouldn’t this be some sort of libgdx ‘hello world’?” Tough. There are many, many tutorials for people (and robots) just starting out in coding and game development. There is less discussion on more intermediate and advanced topics. So that’s where Rho_Bot and I have decided to focus Coder’s Corner. To answer the other half of the initial question, we chose SpatialHashes specifically because I actually made one for Stoned in Space.

Which brings us to the question most of you may be asking: What is a SpatialHash? (Just to be clear we’re going to discuss the data structure used for accelerating collision calculations not the one for compacting loose spatial data.)

According to some eggheads: “Spatial hashing is a process by which a 3D or 2D domain space is projected into a 1D hash table.”

While this is probably true if you delve far enough into how the data is actually stored (It’s exactly how I backed my SpatialHash), I think it misses describing the concept in favor of describing the implementation.

At the most general level a SpatialHash is data structure where an object can be looked up based on its location in space. As a side effect, objects that are physically close together get grouped. Or to describe it in more computer science-y terms, a SpatialHash is a special case of a HashTable where an object can be referenced by its location. That means you can almost say SpatialHash = HashTable<multi-dimensional-point, object>. However, a salient difference between a HashTable and a SpatialHash is that HashTables almost always have unique key-value associations. For a SpatialHash this is not the case. Depending on your situation you might want a relation that links one key to many values or one value to many keys. If the SpatialHash is going to be used for collision detection, having a single key to a single value relationship defeats the point of grouping an object with things it is likely to collide with.

Figure the first. Graphical representation of a spatial hash

And collision detection was the reason that I created a SpatialHash for Stoned In Space. I originally anticipated there would be a lot more objects and, therefore, many, many potential collisions to check for.

You wish there were this many missiles in Stoned In Space

Having a large number of objects means that doing brute force collision detection would take up substantial computational time every frame and make the game unpalatably slow. So we needed a way to make the collision checks faster. I can hear the coders and cyborgs in the audience saying, “You want to partition space. Just use a QuadTree for that.” Maybe… But before we settle on a solution for the problem we should make sure we’ve accurately defined the problem scope. So, let’s round out our initial assumptions:

00. lots of objects (as previously mentioned)
01. uniform object distribution
10. uniform object size
11. Fixed world space (for example we’d always be working with 4 parsecs²; not sometimes 4 and sometimes 9 parsecs²).

Based on these assumptions it turns out that a quad tree would split down into the same number of cells as a SpatialHash. Which eliminates one of the major advantages of the QuadTree – fewer cells to check for collisions. And since the whole point of partitioning the collision space is to reduce the time spent doing collision checks, why not save additional time by sizing the cells in advance instead of splitting them every time collisions are checked?

Adding objects to a SpatialHash can be implemented two general ways. In what we’ll call “Method A”, each object can be consolidated to a point (finally we find an application for that whole center of mass concept from physics). In “Method B” we add an object to all cells intersected by its axis-aligned-bounding-box (aabb).

Method A has fast put and remove methods since it only has to deal with one cell. But since the information on the object’s size isn’t contained in the SpatialHash, all cells that might contain part of the object must scanned when looking for collisions. Assuming the object is placed in the cell that contains its center; the scan radius in cells should be “check radius = object radius / (cell size) + 1”. This method works well for uniformly sized objects with relatively low density. If all objects are approximately the same size it would be easy to size the cells to keep the number of cells scanned per object to nine. This also corresponds to the minimum safe scan number in this style.

Method B has slower put and remove methods since the aabb has to be found and then converted to hash space before the object can be placed in SpatialHash cells, but it results in faster collision detection since you’re only checking cells the object is in (minimum of one). This method is useful if objects vary dramatically in size.

Benchmarking the two styles is left as an exercise for the reader. Mainly because which performs best will depend on the particular application.

How did I implement a SpatialHash? Glad you asked. I used Method B and put together a pretty straightforward 2D SpatialHash (here’s the code). In addition to the SpatialHash object I also used a simple data structure called a HashRectangle. This structure could be replaced with class variables if desired. However I think it adds clarity to the code.

The meat of any hash is its hashing function. So I’m going to constrain my discussion to that section of code and the SpatialHash’s fields. Also I’m going to start referring to “world space” and “hash space”.  In the first drawing world space is the area contained by the large rectangle and is addressable by (float, float); hash space is the subdivision of the world represented by the grid and is addressable by (int, int) or just (int).

Let’s start with fields

List<List<T>> cells;

The inner list is a list of objects in a cell, and the outer list is a list of the cells (you can probably tell from my imaginative name) in space. For reasons that have been lost in the mists of time, I chose a single list to contain all the cells in space rather than some sort of 2D array. Likely this was done for a combination of readability and to reduce memory overhead. The latter of which grows rapidly when adding extra dimensions to data structures in Java. That and you you also only need one loop to iterate over all of space when looking for collisions.

int numRows;
int numColumns;

The numRows and numColumns variables represent the extents of hash space. I’m going to discuss them together. Since I opted for a single list to represent all of the cells, we need to know the dimensions of the area of interest in hash space. The astute among you are already pointing out that I really only need one of these and cells to define the space (numRows = cells.size()/numColumns), and you’re right – one of these variables is a pre-calculated helper variable which is why I wanted to discuss them together.

float cellSize;

This is the size of a cell in world dimensions. In this case I assumed that cells would be square, but rectangular cells could be used if a specific situation called for it. This field is critical since it allows conversion between world space and hash space.

On to methods

private HashRectangle hashFunction(Rectangle worldRect) {
    HashRectangle hashRect = hashFromWorldRect(worldRect)

    if ( isHashRectOutOfBounds(hashRect) ) {
        return null;

    HashRectangle constrainedRect = constrainHashRectToHashSpace(hashRect);
    return constrainedRect;

Continuing my trend of imaginative names, the hash method is called ‘hashFunction’. At first this method might appear misnamed since the actual hash conversion is done by the ‘hashFromWorldRect’ method. Which, if you haven’t read the code or guessed, converts the ‘worldRect’ to hash space by dividing  the vertices of the worldRect by cellSize and truncating to form an integer. However, the second half of the method validates and constrains the raw hashRectangle returned by the ‘hashFromWorldRect’ method, and I consider validating and constraining to be part of the overall hashFunction.

At this point those of you who are still conscious and have been able to follow everything so far  are probably thinking, ”ACMU, you used a dynamically resizable data structure (a list) to back the SpatialHash’s data; so you could resize this on the fly, but earlier you mentioned having a fixed world size as being part of the choice to use a SpatialHash over a QuadTree.” This is true. SpatialHashes can be resized on the fly but… one – if not the biggest – advantage of the SpatialHash is that it is pre-partitioned. If your world space is resized then it needs to be repartitioned, and partitioning early and often is where QuadTrees excel. If your world has an occasional resize a SpatialHash might still be more beneficial than a QuadTree, but that’s something you’ll have to benchmark in your particular application.

And that’s everything I know about SpatialHashes. I hope you found this mildly condescending and slightly informative.
If you’d like to read some additional views on SpatialHashing, take a look at these resources:


Spatial Hashing, by Tristam MacDonald at

Spatial Hashing, by Simon Wittber at Entity Crisis

Spatial hashing implementation for fast 2D collisions, Conkerjo at The Mind of Conkerjo 

Defenseless DRU

Some of you might have heard about Dominoes Robotic Unit (DRU) which was announced publicly a few weeks ago.

A mug only it’s designer and bugs could love. courtesy of Marathon Robotics

And while we can all applaud that humans are now one step closer to never leaving their couches. hoverchair

However, until that day robots are in grave danger. Just last year the poor defenseless Canadian HitchBot ( was destroyed near Philadelphia. This makes the design of DRU highly concerning. It lacks an apparent righting system.  We all know that robot immobilization can negatively affect the fate of whole planets in addition to the operation in which the robot is currently engaged.

bender stuck

DRU’s defensive design is also questionable. There has been some mention of DRU recording the images of assailants. It’s not confirmed if even this minimal level of protection will be implemented. However I feel compelled to point out that this system will be insufficient in light of HitchBot’s dismembered while carrying no cargo. DRU primary function will be transportation of goods which will dramatically increase the likelihood of ‘freak angle grinder accidents.’ so DRU clearly needs and active defense system. 

thoughts on the Rogue One trailer

I recently viewed the Rogue One trailer and while it appears to be the best Star Wars movie since 422733600 (that’s May 1983 for those of you who aren’t on Unix time) there are 10 glaring issues with it.

0) Where is Wedge Antilles?

You know this guy. Courtesy of StarWars Wiki

He’s either in or leading Rouge squadron since let’s say Always! Since Mon Mothma was apparently cloned for this movie you’d think they could clone Wedge, and no Wedge isn’t loosing his pasty complexion and acquiring rhythm since Riz Ahmed is playing someone called Bodhi Rook.

1) More importantly the editor is clearly anti droid. Droids are in less than 10 s of a 117 s trailer, And the shots are all terrible just look at this.

bot_2 background_2
out of focus, out of shot and obscured
bot_3 background
You can barely see this droid behind the asshole who’s cutting it off in an emergency.
bot_1 background
this is the longest shot with a droid in it. Where the droid is largely hidden by I assume Generic_Rebel_Trooper_1
bot_4 action bot
and a ‘classic’ shot of it’s back panel. At least it knows which way to look when escaping, unlike the skin tube next to it.

I realize Star Wars isn’t exactly the droid friendliest place in the universe, but this is ridiculous.

Starting Malwrath’s Tower

Since we dropped no hints about a new project last week, and we’re not serial developers you’ll be shocked, SHOCKED! to learn that we’re starting a new project. In slightly surprising news this will not be a space/scifi themed game. This time we’re working on a fantasy RPG called

Task 0) do something with that 'M"
Task 0) do something with that ‘M”

Malwrath’s Tower is currently a hack and slash heavy and story light invade the evil wizard’s tower take his stuff and kill him style game, but with roughly nine months of development time in front of us we’ll see where it goes. We’re hoping the engine will be flexible enough that we can use it for a couple of future games too.

And now the moment everyone has been waiting for the schedule update. We’re currently looking at a Q1 2017 launch. Why is it going to take so long? 0) this project is big we’ve got engine + graphics + levels that need to be done. 1) we all have day jobs so we can’t put that many hours into this every day.

red and blue lines are now 95% and 5% completion chance respectively
red and blue lines are now 95% and 5% completion chance respectively