Over the past few months, we have been diligently working on this game. Not nearly as much on the specifics of the game as on the graphical and logical programming required. Once we have all the components we need to make a fully working level, we’ll be working on the specifics of an actual game. For now, we have pictures of several stages of game development leading to what will soon be a playable demonstration of our work. We are hoping to complete this demonstration by our next Service Learning day, January 26.

progress on the game

December 20, 2010

While this image is only showing texturing, by this time, we had many features working in the back end:

  • fullscreen mode
  • almost completely object oriented (not entirely encapsulated at that point, for testing purposes)
  • using OpenGL ES 1.0
  • proper cartesian plane, with -y at the bottom
  • collision detection by Separating Axis Theorem(working on having them bounce back now)
  • movement/rotation/scaling with inerpolation (smooth motion instead of just appearing a far distance away)
  • textures (currently 1, and planning on splitting into tileset)
  • touch-based camera motion (it’s clamped right now, as in touching the very center of the screen returns camera to (0,0))
  • “Programmer art” tileset, complete with hand-drawn numbers
  • a hot pink background color. We entered random values for the RGB values, ended up being pink. We looked up what hot pink was, adjusted the values. I don’t know why we kept it.

December 21, 2010

Within a day from that screenshot, we managed to get a polygon to display only a small segment of the full texture. We also managed to streamline the process a bit and have the polygon display a specific tile based on a single number input. Not much was added between the last update and this, but some code was cleaned up and made to work better.

December 22, 2010

Again, this was a minor update. While this looks like a single polygon, it’s really 64 polygons aligned next to each other with randomly selected tiles. This introduced a slight change to the organization of the code, and allowed for layered rendering, where the tileset will always be rendered below entities.

December 25, 2010

This animated gif (click image to view animation) is showing a few things:

  • Multiple texture support
  • Transparency (some of the blank tiles in the back are actually showing the background and are not colored in)
  • Spriting abilities, from a tileset

Also note that the animated .gif format is limited in colors, which is why some of the smooth transitioning colors are represented by harsh changes in the image.

January 1, 2011

This is the last recording we were able to make because the Android emulator was starting to slow down quite a bit, and we wanted to try out actual speeds with a real phone, so we started debugging on an actual phone. Again, the gif format has inaccuracies in color, and recording it only slows down the emulator.

Anyways, this last animated gif shows a lot of things going on:

  • UI Layering. Instead of having the entire user interface move with the world every single frame, we simply render it onto a layer which never moves outside of the screen.
  • A progress bar. What’s special about THIS progress bar is that it doesn’t just take the red to green gradient and shrink the size of the polygon, it adjusts the color to make it seem as though the gradient were solid and the polygon were only showing a small segment of it.
  • A slightly improved spriting method which runs a lot more efficiently
  • Collision detection and reaction, the two sprites stop

In the last 4 days, we’ve switched to debugging on an actual phone, which is saving us a significant amount of time where we would wait for the emulator to boot up, and nothing worked as smoothly as it should have in the emulator, making us test it more than we do on the phone.

Since then, we’ve expanded the things the UI can do, such as adding buttons and a joypad to control camera and player movement, gradients that work not just right to left, but in every direction, and we’ve been filling out some of the details for some of the entities within the game. Throughout all these updates, we have constantly been cleaning up previously written code, refactoring variables with strange names, and trying to work out a good development process to increase our efficiency. Over this last week and a half, we moved from using subversion to git for handling code management. Both subversion and git are designed to help teams of programmers organize their code and merge changes with each other, but git does a far better job at it, letting us spend more time coding and less time figuring out what lines of code we need to keep or remove in order to merge successfully and without the loss of any new features.

We’ll be working hard for the next 3 weeks to turn a series of features into a cohesive level demonstration. We may make a few posts leading up to then, though.