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

Ranguvar · 2009-05-28 06:09:56

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.

gnud · 2009-05-29 22:10:46

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.

Ranguvar · 2009-05-31 06:15:16

Heh, thanks very much for taking a look

1.) I don't really plan on doing much with this besides handing in the project. Well, since I don't really have any experience with Makefiles, I might write one for learning purposes. But we're approaching the time limit and since Eclipse will build it fine I don't want to get _too_ much into things like that. Over the summer I'll be digging into C and C++, which I generally enjoy more anyways so far Maybe sometime in the future I'll get back to it for kicks.
2.) Hmm. Bytes. I shall look into. I also want to take the maze out of being set in a class and into something loadable... might happen depending on how quick we can get basic Pac-Man working.
3.) Makes sense. Care to elaborate, especially on the mObject's image handling and on those that override it? If so, thanks Also might not be changed depending on time.
4.) Yeah, I feel more and more they're not worth the trouble xD
5.) True. One of the greatest traits a coder/hacker can have is laziness

Thanks again for your comments, they are much appreciated. Good luck on your plans as well
*goes back to mixed muttering and cursing trying figure out SWT's timing system*

Ranguvar · 2009-06-05 16:42:46

Threading is annoying me deeply... if anyone would take a look, it'd be _much_ appreciated Some things might be obviously broken besides threading, but threading is what I'm trying to get working right now. No code please, just if you could explain what I'm doing wrong?

Thanks very much

gnud · 2009-06-05 22:02:59

I'm not sure what you're working on - the GUI loads, but nothing is happening or moving, and no error message displays. What are you having trouble with?

Ranguvar · 2009-06-05 22:09:11

Click New Game and then try using the arrow keys to move about
Thanks!

Last edited by Ranguvar (2009-06-05 22:09:18)

gnud · 2009-06-06 11:02:57

Ok, I got the movement working without it leaving strange artifacts, or jumping.

I didn't change anything to do with the threads themselves, only to do with the communication between them.

What I did was:
In MobMaze i added a privateArrayList<LocationDepthless> dirtyLocations;
Then I added two synchronized methods: one for adding a location to the list of dirty locations, and one for creating a copy of the list, clearing the original dirty list, and returning the copy.

Then, in Player::move, I mark both the new location and the old location as dirty.
Then, in GUI::refresh(), I get the dirty locations from MobMaze, and loop through them, redrawing each one (I also removed the wait() call from GUI::refresh()).

With this approach, it's easier to add enemies and powerups (cherries) later, without having to rewrite GUI::refresh() every time.

Ranguvar · 2009-06-06 17:14:33

Hehe -- I just got it fixed myself, and was about to post and say so

Your approach is nice though, and perhaps better than mine. It means I can remove code in my refresh method (now the refreshActArea runnable) that is specific to refreshing the player and the space behind it, etc, and the whole mObject::getMoved() thing. And actually, I was going to make it so that (as in the original Pac-Man) if the player ran up against the wall, the Pac-Man would stop opening and closing his mouth and continue when the player started moving again. I could still do that by moving and then checking to see if dirtyLocations was empty (before I move the eventual Ghosts that will be added).

Thanks very much I'll try your approach now.

EDIT: Successfully implemented. Thanks again!

Last edited by Ranguvar (2009-06-06 21:21:03)

Ranguvar · 2009-06-10 08:29:56

Program's due tomorrow and there's a huge bug x.x

After a couple seconds of gameplay, everything goes really slow. Any ideas, anyone?

Thanks

EDIT: May have fixed it. Worried that I might not have hit the true problem. There can now be null mObjects, everything isn't an EmptyMob.
EDIT 2: Yup. The slowness is still hiding somewhere, it just takes longer to show up.
EDIT 3: May have fixed it now (not in CVS yet) The problem was, as the Sleak tool revealed (I now <3 Sleak), I was creating thousands of images on actArea.

Last edited by Ranguvar (2009-06-10 16:42:55)

Arch Linux

#1 2009-05-28 06:09:56

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

#2 2009-05-29 22:10:46

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

#3 2009-05-31 06:15:16

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

#4 2009-06-05 16:42:46

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

#5 2009-06-05 22:02:59

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

#6 2009-06-05 22:09:11

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

#7 2009-06-06 11:02:57

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

#8 2009-06-06 17:14:33

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

#9 2009-06-10 08:29:56

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

Board footer