CS-Man: Pac-Man (the game, not the package manager!) clone in Java/SWT

Question

Wasn't sure whether this would go here or Off Topic, but w/e.
I'm working on a Pac-Man clone for my AP Computer Science class, me and a friend. We're using Java and the SWT toolkit to write a suckish Pac-Man clone. We've been working on it for 2-3 weeks now, and have a few more weeks to go. Keep in mind, this is AP Comp Sci -- not very advanced, though are project is a bit above and beyond We're just beginners, although we're both pretty certainly heading into programming as careers.
You can check out the project, code, etc. at http://sourceforge.net/projects/cs-man . Bug reports and feature requests are very much welcome (not so much the latter actually, we have plans for more features than we'll ever get done already), but actual code is not -- it's BSD-licensed, but we need to do the project ourselves
The current code doesn't do much at all, but it's close to working player movement. There are some obvious gaffes, but it's 2am and I just wanted to commit the code and work more tomorrow, so those should be fixed soon. The structure resembles to a large degree the GridWorld case study.
The app works fine on Arch with GTK+ and on Windoze, and should on OS X as well (try SWT 3.5 development). Check out the code, add a user library called SWT with your SWT JAR and possibly source (Arch has these stored in /usr/share/eclipse/plugins/ or something like that), and try.
And yes, the images and such are (obviously) just for testing. They look like crap, and the psychedelic Pac-Man pics we have aren't even transparent.
Anyways, I'm off to bed.

Answer 1

I thought I could have a looksie, since I aspire to be a teaching assistant in an introductory java course this fall. Java is not really my forte, though - i don't know many API's, just enough for the university courses. I've never used SWT.
So, after fiddling a bit to get it working (I put SWT in my classpath, copied the image directory into src/ and started the app from there - could probably have buildt a jar or something too, but there was no makefile), here are some comments:
I'm not saying all suggestions I make are better, I'd just like to know your reasoning. Some of them are just better, though
1. Include a makefile/ant-makefile/cmake-file/scons-file/something. And a readme.
2. GUI::map - why shorts? Why not bytes?
3. Keeping references to all images in all classes makes for a lot of bookkeeping, and horrible constructor argument lists.  I'd create a helper class that serves up images (something like an ImageCollection -  images.getImage(ImageCollection::DOT)). Bonus: Themable application! Just implement a simple config file for the images at loading time
This funcitonality could also be contained in MobMaze, as asking the Maze how it looks seems reasonable enough, and it seems most classes already keep a reference to it.
Now, the next step is to decouple as much image handling as possible from the mObject derived classes. I'd make mObject hold a class variable that refers to the constant (or enum value) of the corresponding image - now MobMaze can use that value, and the mObject classes never have to touch a Image. Of course, the chomping logic for Player (and some state logic for having the trolls turn blue) must be implemented in overridden methods.
4. Using shorts everywhere is not likely to speed up your code on 32 bit machines.
5. In 'special' constructors, like Location::Location(int,int) - don't duplicate functionality from the general main worker constructor (Location::Location(int,int,int)). Call the main constructor with the default argument, instead. Keep the DRY principle in mind
But good work! This is a fair bit more ambitious than I was in my programs for class.
Anyway, I hope I made some sense. I'll see if I feel like having a more in-depth look.