Very nice. I'll take a look at it for certain. Given a rules-based approach, do you have any idea how it responds to randomness? The original PacMan had deterministic ghost movements and I believe there is information out there that shows it to be solvable if not solved. Ms. PacMan introduced a degree of randomness to ghost movements creating a less solvable or unsolvable scenario. My version has some randomness in ghost directional choices.

As for my version, there is yet another update available. Here's the detail on changes to v0.1.4:

v0.1.4 Updates
--------------

A few bugs were fixed. Specifically, some issues with whether PowerPellets and Ghosts were visible or not were addressed.

The ability to ignore walls or dots was added to the Windowed AI. In the parameters file the following keywords control this as follows:

DotWallSingleInput - If set to 1, the input will be -1 for a wall, 0 if empty, and 1 for a dot. If set to 0, there will be two sets of inputs - one for dots one for walls.

DotsWallsOnly - If set to 0, both dots and walls will be used for inputs. If set to -1, only the walls will be seen. If set to 1, only the dots will be seen.

I've been playing around with this for a few hours, and it occurs to me that part of the reason that PM gets stuck, is the fact that he is allowed to turn back on his previous direction. As far as I'm aware, the actual pack man games did not allow this. And it would also solve the issue of PM going into 'loops' where he simply walks back and forward within a corner. One other thing of note, is during the entire time I have been playing with this, I have never once seen PM move towards the left side of the screen, and tends to favour moving upward. Meaning that the vast majority of attempts have ended with PM stuck in the top right hand corner.

Anyway, that's just my two cents. Thanks for providing some interesting things to think on!

Thanks for your comments. I'm excited to see interest from the opposite side of the planeet!! 8^)

Regarding PacMan moving back on his own path, in the original game he can move in any direction he wants at any time. Given that the player controls his motion, there are no limitations on what direction he can go at what time. My intent was to allow the controlling neural net the same freedoms as a human player. Ghosts, on the other hand, are only rarely allowed to reverse their current direction in the original.

I had considered putting additional constraints into place and in my current version (not yet on SourceForge) I have an additional parameter called EnforceIntersctions which will only allow PacMan to choose a new direction at an intersection rather than at any time during the simulation. I have not enforced a limit on reversing direction, though.

I have also seen a preference for certain areas of the game board during multiple runs. I have often seen PacMan get stuck in all four corners, however. I'll do some investigation into the random number controls to make sure they are behaving as they should.

-Kirk

Well, I left the process running overnight, 37520 generations down and I finally see PM move left! Yay! :) (best fitness of 4100) By the way, what is the chance that you'll implement some sort of saving and loading feature? So that a: it becomes possible to stop and restart(continue) the training, and b: So that when I've had PM running around for a week, there's something to show for it :D

I figure some sort of serialization of the strongest NN from each species would be all that's needed.

Also, any chance you would consider threading this? The ability to run multiple tests at once would greatly increase the speed of improvement I believe.

By the way, I'm running PM with 4 ghosts, maximum stall of 10, and maximum score stall of 100. This greatly reduces the chance of PM stopping in corners, however there is still a tendency to run back and forward on his own track :/

Anyway, sorry if I'm being overly demanding >.< just trying to offer a few helpful suggestions.

Looking forward to more!
- Grey

You are certainly NOT being too demanding. I truly appreciate your comments.

Regarding your suggestions, serialization of the best neural nets in each generation is planned, I just haven't gotten to it yet. I hadn't thought about using that to halt training and then restart, but I like the idea. I'll put that on the agenda as well.

I hadn't considered threading primarily because the application is quite demanding of processor cycles as it is. If you ran multiple threads/instances simultaneously on the same machine each thread would have to share the processor and be slowed down. This would be improved on a duo core or quad core machine, though. One thought I had was to try to integrate PVN so that it could be distributed on a network. I have access to ~150 processors and PVN would let me run a huge number of simultaneous instances or have a VERY fast evaluation. Again, something I'd like to do if I have time.

Another thing I would like to get into place eventually is evolving ghost AI. The ability to run a competitive co-evolution - now that might be interesting.

All that being said, you should feel free to grab the code and make those very modifications. ;^)

-Kirk

Grab the code? I hadn't actually thought of that! :D The only downside being that I've got absolutely no experience with either serialization of data, -or- threading. (Yes I have several multi-core PCs, thus why I mentioned threading :) ) I'll definitely take a look at the source now however, and see what I can wrangle together. And if I make something that is "good enough" i'll make a copy available for you to rip apart :)

<edit> Is the zip on sourceforge the latest code? As it seems a little, broken. :| It may very well be a problem with me using VS 2k8 so i'll keep slowly fixing the errors (down to 8 from about 20) </edit>

[Edited by - TheGreyOne on February 27, 2008 11:02:48 PM]

The code on SourceForge is almost the latest. I have a 1 step newer version, but it is only a soft modification of what is there.

One difference is that I'm using Code::Blocks as my IDE, so transferring to VS may require some wrangling. Of course you can always get Code::Blocks and GCC for free. 8^)

-Kirk

While it's oh-so-tempting to get into a conversation on the relative merits of IDEs, I think I'll leave that for another place and time. ;)

I have given up trying to compile the code that is available to me. Mainly as I'm worried any attempts to 'fix' the seeming problems will only land me with more problems to fix (this time of my own creation.) As such, I will patiently look forward to your next release, hopefully with at least the save and load functions (*grin*) as that seems the most useful at this point in my opinion.

Anyway, I've nothing more useful to add at this stage, so i'll leave it at that! :)

- Grey

Sounds like a cop-out to me! 8^) Seriously, distribution of code can be tricky. I assure you, however, that the exact code you have compiles and runs nicely using GCC (MinGW) and Code::Blocks.

The next release I plan to put up will contain the Intersection Enforcement option I mentioned earlier - PacMan can only change direction at an intersection. I have also implemented a Vectorial Representation in which the inputs consist of angles and distances from PacMan to Ghosts, power pellets, and the centroid of the currently remaining dots. In this version I leave walls as a windowed representation. I also want to fix a couple of aesthetic bugs.

After that I plan to work on persistence of the nets, just as you've suggested here. Once that works, I can start thinking about evolving ghost AI simultaneously.

-Kirk