I'll take your word that the video doesn't fairly portray the game. It's looking good so far, and I admire your patience in placing every single one of those dots! How's the deadline looking for you in terms of being realistic?

I already have most of the core features implemented, I just need to add enemy movement, a bullet system, sound effects, and a points system to create a basic, playable game. I don't think that should take too long. After that, I'll make a cool title screen and possibly animations for when you die, kill an enemy, etc.

So, today I added code to display the enemies and an array to hold the enemies' data, but they aren't able to move around yet. Hopefully, I'll be able to make them move and follow the player this week.

*bump*
I've been working on enemy movement, and it somewhat works, but my code is really unoptimized and bloated so I'm completely rewriting it.

*nudge*

Enemy movement works well enough now that I can move on to other aspects of the game, but there are still a few glitches with the collision detection.

The first thing I noticed though was the rough outlines on the ghosts -- maybe just my OCD, but they'd look more in place with the borders removed IMO. Other than that, superb!

Yeah, the rough outlines were just the result of my laziness and inability to make good sprites; I'll remove them later. Right now, I have to focus on making a playable and complete game.

So in the end you didn't need to use any sort of tricks like frame-skipping? I'm confused why or how XNA is breaking that, by the way.

Kerm, maybe I am misunderstanding what you said, but if you mean "Why is XNA making the borders rough", it's not XNA's fault. That'd be Souvik's fault when he found the PacMan sprites and cut them out to give them a clear background.

Souvik, nice! Are you still doing the same sort of enemy AI as PacMan? (where the various ghosts aim 4 blocks above, to the left of, to the right of, and below your character)

Nope, it's not at all like the Pacman enemy AI; it's completely original. It's smart enough to follow the player around, but it sometimes does stupid stuff like forgetting to turn at intersections.

Souvik was moving the sprites by two pixels each frame of the game for speed needs. He was having collision-detection problems. I suggested on IRC that he perform frame-skipping, where you calculate frames of the game but not display them. For example, Invalid Tangram only displays every (fourth?) frame, and Obliterate does 8x frame-dropping, which means it only displays one out of every eight frames it calculates. In both cases, you get accurate physics and collisions without losing speed due to slow rendering. Souvik said that when he tried it, XNA was clearing the screen each time through the main loop anyway, so he had to redraw on every frame.

You should not be trying to trick the Game class by manually implementing hacks like frame skip; assuming the default settings (i.e. IsFixedTimeStep is true) your Update() method will be called sixty times per second. If your code is too slow to make this then IsRunningSlowly is set to true and XNA skips Draw calls, dropping frames on your behalf. Work with the library, don't try to subvert it.

I got player shooting to work. I don't really like the bullet sprite too much, though.

*bump*

Enemy shooting is now fully functional.

I'm almost done with my game. There are still a few quirks with the enemy movement, though, and I don't think I'll have enough time to fix them. I'm currently working on the level system and high scores, which I hope to complete today. Should I include the XNA dlls along with the executable when I submit it? I know it's against the EULA, but this is so the judges don't have to install the XNA framework.