I’m realizing as I read through the feedback on my game that it isn’t exactly obvious that your character is actually moving, instead of just waiting for rats to run into his blade.  Notice how if you point your mouse away from the rats, the rats appear to slow down and move backwards relative to you?  And when your character turns the wrong way, that’s because of the way the vector addition works out– try moving the mouse further clockwise or counter-clockwise and see if that makes him do what you want.  And those big white things are walls.  My game simply fails to communicate a sense of movement because none of the terrain is textured.

If you couldn’t run my game, try downloading and running the following python file: http://peak.telecommunity.com/dist/ez_setup.py

I found out this file was a sub-dependency of PyOpenGL when I switched to a windows system to build a win32 executable.  I also found out that py2exe does not do whatever it’s supposed to do with pkg_resources, so my game will run before it’s packaged, but not after.

I finally settled on a name. Since this game is based on one of my past projects, a roguelike called “The Hunter”, I kept thinking of corny names like “Hunter 2D” for its contiguous 2d coordinate system, and “Hunter 360″ for 360 degrees of freedom. Yuck. Finally I came up with “Omnihunter” for an omni-directional version of The Hunter.

As for the polish I added since my last post, it was mostly a hour worth of minor bug fixes, and I replaced the alligator graphic with a rat because it matches the monsters’ movement pattern better. Here’s what it looks like:

It’s very… minimal. There’s a lot more I could have done with this game, like adding more types of monsters, give the player a choice of weaponry, make the monsters spawn out of things that the player can destroy, add walls and turn the environment into a labyrinth, add animations… even make the rats spontaneously combust. Overall, though, I’m pleased with how it turned out. It’s nice to see my entire development cycle outlined in my posts, and for my idea to have become a reality in about a day. Plus, I have fun playing my game, and I think other people will too.

According to my posts, it looks like I have spent around 9-10 hours of work on this project over the course of 26 hours. Somehow I think it should have taken me less time than that, seeing as it’s a very simple game, but I finished a project for once, and I have plenty of time to spare. Better that than not finishing in time.

Download the game here: http://www.mediafire.com/?xcmndkznj4n

EDIT: On second thought, there were still a few changes I wanted to make. I’m really cutting it close with only 17 minutes left. Download the updated version here: http://www.mediafire.com/?jdmmi1k5e7y

Dependencies:

• Python
• Pygame
• PyOpenGL
  • EDIT: PyOpenGL also requires you to run this file: http://peak.telecommunity.com/dist/ez_setup.py

Tools used:

• Ubuntu
• gedit
• terminal + command line python interpreter
• GIMP
• Audacity Sound Editor

I finally implemented the enhanced collision detection which determines who wins a fight when the player and a monster overlap. It took me a lot longer than expected– two hours– but now that that’s done, all I have left to do is polish off the game.

No screenshot in this post, because the only changes are visible in motion.

I realized that I could spend a lot of time optimizing the monster flocking behavior… or I could just remove it entirely to save CPU because the player hardly gets to observe it. Now the monsters just wander aimlessly and chase the player when they see him. It hardly impacts gameplay, except that it runs more smoothly.

As for the rest of the game, I drew bad pixel art and threw together some bad sounds for whenever the player collides with a monster or when a character bumps into the edge of the arena. Now, just as soon as I make the monsters actually kill the player, I’ll have a full game.

I woke up about an hour ago and added most of the AI to the monsters. The only thing they don’t do yet is avoid collisions with each other, but I hardly notice it when the green squares overlap. When I add images it may be another story, but I’ll cross that bridge when I get there.

Here is a zoomed-out view of the action. Note the clusters that form when monsters wander near each other. I think it looks great in motion, except that I can count the framerate on one hand when there are this many monsters in the arena.

I’m taking a break for dinner, and when I get back, I’ll work on optimizing the AI so it doesn’t take up my entire processor (and then some).

I finally have a screenshot, and it looks awful. Observe:

The red square is the player, the green squares are the monsters, and the white line is the arena boundary. The tearing at the top is there because my linux screenshot program doesn’t lock up the entire system the way it does on Windows.

So here’s my total progress:

• Player controls (complete)
• Render player (complete)
• Render monsters (complete)
• Render arena boundaries (complete)
• Player collides with arena boundaries
• Player image
  • Rotate player
• Monster image
  • Rotate monsters
• Monster AI
  • Approach player when in vision
  • Follow other monsters when player is not in vision
  • Wander aimlessly when nothing is in view
  • Avoid collision with other monsters
  • Avoid collision with arena boundaries
• Player kills monsters
  • dampen player’s velocity
• Monsters kill player

However, I am going to bed now because I have been awake for a very long time. Maybe I’ll know what to call the game when I wake up.

I took off an hour for breakfast and other things. Mostly I’m posting just to log the time I spent on this project, as the only progress I have made so far is setting up the general framework of the application. It runs, but hardly displays anything.

This took me a bit of thinking and discarding of lousy ideas, but I think I finally have a good idea.

I don’t know what to name the game yet, but the idea is that the player controls his character with the mouse and has to run down the monsters in order to kill them. The player character always accelerates towards the mouse cursor at a fixed rate. The monsters spawn at random locations, growing more numerous as the game goes on. The game ends when a monster hits the player from behind or from the side, and the player’s score is the number of seconds he lasted.