As you know, this particular game has been kicking my ass. It seemed like it was going to be rather simple, with me spending most of the time on AI/enhanced graphics, but just getting his movement down has proved a huge challenge. (*Note: when I say enhanced graphics, I mean only slightly better than the original - I'm no artist!). At any rate, a major problem for me has been keeping little Mr. Pac aligned on even boundaries so he stays within legal moving space and doesn't overlap onto the blue border pieces. I tried everything I could think of, tripled checked my math, and no matter what, as he moved, he began to drift a little bit. It wasn't bad at first, a pixel here, and a pixel there. The problem reared its ugly head in a major fashion though as you continued to move around because the drift was cumulative. In other words, the more you moved around, the further he drifted, and the more into the border pieces he got. It seemed really strange to me because I couldn't find a problem in the math, or the collision detection, which does work.

Then, last night, after working on the project again for a little bit, and having laid down to go to sleep, while reading a book, the answer hit me all at once. I've been looking for the problem in the wrong place all along. The problem isn't in how he moves, or the math (at least I think, we'll find out for sure a little later as I do more work), the problem is created because of when he is allowed to move.

One of the big play factors for the original game is that Mr. Pac McClone can turn before he actually hits the corner - the ghosts on the other hand, can not, they must travel all the way to the center of 'valid' space before they are allowed to make their cornering move. For a detailed explanation of this behavior, see: http://home.comcast.net/~jpittman2/pacman/pacmandossier.html

I've relied heavily on that particular game outline to keep things as close to the original as possible, and as you can see, Mr. Pac is allowed to make his cornering move anywhere within a 4 pixel range as he approaches, enters, and passes through the grid boundaries. My code mimics this behavior almost exactly, but I failed to take into account that he may not be grid aligned when he makes that cornering move. So if he corners 1 pixel early, it throws off the entire coordinate system and creates the cumulative effect so prominent in my versions so far.

Long story summarized.. my entire project has been off because I was looking in the wrong place for the problem. Anywho's I'm going to try and get some more work done today, and maybe I'll have an actual correctly working version up here soon!

And no, I haven't been getting much done recently. I'm trying to get some basic pathfinding or general AI intelligence working in my game, and when I stop procrastinating and actually try to program it, it chews me up and spits me out, haha!

At any rate, before the sickness hit I was able to get the new pac board up and rendered, and even some basic collision detection, so here's a screen shot from the latest version. I was able to use the slightly higher resolution graphics that I liked, so it doesn't look too horrible.

I'm not sure I'll be able to do the Bejeweled clone as I had planned to, but as RB said, it's better to have one completed project than two half working pieces. If my cognitive functions continue to work over the next couple days, I might be able to catch up and pull out a quickie Bejeweled in the last 7 days but for right now I'm going to focus on Pac.

It was real quite around the forum and chat this week/weekend, so I'm hoping you all made some decent progress on your respective projects. Anyways, hope to talk to you all soon, and have a great day!

After running into a couple little issues with the current collision detection, I was playing around and decided to try some pixel testing. Using pixel collision detection, you can get very fine results between objects, at the cost of speed. A lot of things can be done without it, but I wanted to take a shot any ways and see what could be done.

So, the first step in pixel CD is to determine the color of a pixel on the screen at a given coordinate. The idea is to check the screen in the direction of travel, and if you detect anything other than the transparent color (in Pacmans case, Black) then you know there's a collision, and you take the appropriate action.

This isn't a full implementation actually, just the first step, and the location that is examined is under the mouse cursor. In other words, this version checks the screen to see what color the pixel under the mouse cursor is. It's very simple, but like I said, it's the first step and implementing the rest wouldn't be too hard. If I'll actually do that, or just stick with the arrays I have now is yet to be seen, but I thought I'd throw up this version so you could play around and see how it detects the 'walls'. Note, that it only checks the texture used as the 'background' so it doesn't see the pellets or Mr. McClone. Anywho's, heres a new version which has a couple other added features - a score, and the board will actually reset if you clear all the pellets.

As always, with Googles funky drive stuff, to download the entire zip file in one shot, you can select 'File' at the top of the screen, then 'Download'. Enjoy, and let me know what you think!

https://drive.google.com/file/d/0B5moEgyck5X5SjNWUmNnTG83Z3M/edit?usp=sharing

-PiscesMike

Finally got to a point where I think it's time for a playable demo… mostly so you all can let me know if you run into any problems with the collision detection.

First off, here's the link:

https://drive.google.com/file/d/0B5moEgyck5X5VmdCdW9jbHVDeTA/edit?usp=sharing

There are a couple bugs/issues that I am aware of. Like, Mr. Pac doesn't change the direction he is facing when he moves up and down, or to the right. I'll get that added in at some point. The 'teleporters' on the edge of the screen don't work yet either. No ghosts, and no power ups. It's basic board, pellets, and pac at the moment. Still, there are some issues with him catching on corners, and, at least on my machine, he is waaaaay too fast.

Anywho's let me know if you see any major errors on the collision detection and I'll be working on the rest!

PS Google drive is a little funky with zip downloads, it always defaults to showing the contents of the zip file. To download the entire zip in one shot, select 'File' at the top, then 'Download'

There's still over 22 days left on the official clock and I feel like I'm already behind. That being said, I at least wanted to get up a video of what I've accomplished during the hectic week I've had.

The first of the games I'm tackling is a Pacman clone, and in doing so, I decided I wanted to keep it as original as possible. I wasn't able to find this font for XNA use, and I was too lazy to make my own, so I had to pull off some 'ugly' code to get this working.

Good job everyone, and happy coding!

Just thought I'd pop up my competition entry ideas. I had been putting off the final decision until today, and after talking with Swat and Marcus for a little bit decided I'm veering away from the tropes and suggested theme of Thrust. (Kind of similar to Asteroids, and that was such a pain I'm just not ready to face that task again! — even though it would be much much eaiser now, at least I think).

Anyways, I'm going to do a 'split' competition where I spent 2 weeks each on 2 different games. The first will be a classic Pacman ripoff, with the twist that you can play as one of the ghosts. The second is going to be a basic Bejeweled rip off.

I think I can pull those off in the time permitted, and if they come out cool they might even fit nicely on a windows phone screen, which I hadn't been paying attention to before. Be interesting to see how it turns out.

Ok, well those are my submissions, and since the clock has started ticking, I should get to work! Have a great day/evening, and happy coding!