In Which I Figure Out Where To Move Pandas

As feared expected, getting our game done in time for the January 23rd deadline took precedence over writing about all the problems I ran into while making it. However, I will still record the experience here because keeping a record of my journey of discovery will help and inspire future generations of would-be game creators who already know how to program.

When I last left off, I had a cursor on screen, and a pandacat at a fixed location. My next step was to get the pandas to move. Since we knew a central part of gameplay was going to be coaxing animals around obstacles to a specific destination, Josh suggested I look into A* search. I vaguely recalled having studied A* in college and wound up following the excellent article A* Pathfinding for Beginners. The first hurdle I had to cross was deciding the level of detail for my A* grid: our game targets 720p and 1080p TV resolutions,1 but since this game has to run on a decent-but-not-amazing Android device which I have no way of testing with, I figured trying to search pixel-by-pixel was going to use more memory than we had available (not to mention time). I decided to pick an arbitrary reasonable size and landed on 160×90: I figured 10x the aspect ratio of 16:9 would probably give us enough detail.

So, uh, how do I keep track of where the animals can walk and where they can’t?

The LibGDX sample apps came to the rescue again: the Cuboc demo does something very clever to build its level map: it loads a PNG and builds its in-memory level information based on the color values of the pixels in the image. This is probably common practice for a lot of game-dev folks, but this was a new approach to me and struck me as very clever. So I copied it. I made a simple black-and-white image, 160×90 pixels, which showed roughly where the barriers were in our temporary game level. Then I just loaded it into a giant boolean array of arrays in memory (14,400 booleans doesn’t actually take up much memory, thankfully).

A 2x version of the collision map I drew for our basic testing map.

A 2x version of the collision map I drew for our basic testing map.

LibGDX by default counts Y values as increasing from the bottom, so (0, 0) is the bottom left corner, whereas in my image (0, 0) is the upper left, hence the weird Y subtraction.

Now that I knew which grid points where invalid, I could skip them when doing A* searching. Once I fixed a few2 bugs in my A* implementation, I could miraculously draw paths out of grid squares from an animal to an arbitrary location on screen, avoiding obstacles:

The green path is where I want the Panda to go. I just haven't figured out how to get it there yet.

The green path is where I want the Panda to go. I just haven’t figured out how to get it there yet.

Now, I just had to figure out how to tell the animals to move along the path. This turned out to be quite a bit harder than expected, because as I soon learned, I couldn’t remember anything at all about geometry. Next time: VECTOR MATH.


  1. That would be 1280×720 and 1920×1080 respectively. 

  2. okay, a lot 

OUYA Game Jam: The Start

I’ve always been a gaming fan and kept an eye on the games industry, but the one and only game I’ve written was a silly two player pong game for a just-for-fun class senior year of college (taught by the excellent Joe McKay). So, when my friend Lily asked if I wanted to apply my Android experience to coding a game for the OUYA/Kill Screen CREATE Game Jam, I decided to take a chance on learning a bit more about this whole game programming thing.

Lily already had a vague gameplay idea, working title Noah’s Art, where the player would switch color filters which would effect how they could interact with differently colored objects in a top-down world. Her friend Josh joined in to help with gameplay design. I started by researching different game engines for Android. Of the simple open source Android libraries, LibGDX seemed the best maintained, had the most community support, and good 2d support. Then there’s Unity, a very popular commercial library that supports every platform under the sun, is a sponsor of the jam, and looks like it does a lot of work for you if you can figure out how to use it. In the end the deciding factor wound up being the wifi at the coffee shop I was working at on Monday: the 1GB+ Unity download kept getting cut off. I was also concerned about the hefty price tag on Unity, while LibGDX let me avoid those concerns.

Game Day 2: Things on screen

Noah’s Art Day 2: Things on screen

I started with LibGDX by working through Tamas Jano’s excellent “Getting Started in Android Game Development with libgdx”. After a morning spent kicking the tires on LibGDX I started a new game project with a 720p screen targeting OpenGL 2.0 to match the OUYA’s specifications. Now that I remembered how game loops worked, which LibGDX handles for you by repeatedly calling the render() function on your GameScreen class, it was time to get to work. I easily ripped off the Invaders sample code to draw a temporary background image and rendered a temporary sprite at a fixed coordinate as a stand-in for a game object.

The first task was getting a cursor to display on screen, as the player will manipulate wandering animals with a cursor controlled with one of the OUYA controller thumbsticks. I added support for the OUYA controller using LibGDX’s new controller support (I also added mouse controls for LibGDX’s desktop mode for development testing). It turns out getting controller state in LibGDX is pretty easy: on every game loop just check where the stick is and set the cursor’s velocity accordingly, then update its location based on that velocity:

After that it’s a simple matter of drawing the cursor at its new location:

VoilĂ ! You’ve got a cursor you can move with the thumbstick. Now, about that fixed temporary game object … tomorrow: things that move!