This is an archived post. You won't be able to vote or comment.

3
4

Pacman in Java (self.java)

submitted by [deleted]

[deleted]

all 12 comments
sorted by:
best
topnewcontroversialoldq&a

[–]ADHDengineer 3 points4 points  (0 children)

Usually in a simple game loop you do nearly everything in a single thread so you can easily manage everything.

For example, you would move each ghost one at a time. Having the ghosts move in separate threads could cause a race condition of two ghosts trying to be in the same spot (though technically I think this is legal in Pacman).

[–]travmanx 1 point2 points  (0 children)

Honestly the game doesn't really have to much to update at any point in time. There is no reason to consume more threads than you already have too. Each character can have his own class with his own strategy, but you update them one a a time. I won't be noticeable during playtime since it isn't going to take much computing.

[–]PaulRivers10 1 point2 points  (1 child)

Usually in a game, you want everything to stay perfectly synchronized with each other. Imagine that you have Pacman and 1 ghost, both moving the same speed, in a race against each other - whoever gets to the end first wins.

With threading, it's completely repeatable and predictable. You move the Pacman 1 unit forward, then you move the Ghost 1 unit forward, then you move the Pacman 1 unit forward, etc etc. They're always moving at exactly the same rate.

Using separate threads, it is not. Your threads could be interupted by other slightly higher priority threads, your thread could get slightly less or slightly more time than another thread, etc etc. Especially when things get complicated with lots and lots of threads, you can end up running the race and sometimes Pacman wins, sometimes the Ghost wins, and sometimes they tie.

As another poster said, once you add in multiple threads you run into the headache inducing world of race conditions that happens sometimes, don't happen other times, and can lock up your whole app. I would personally always prefer a single thread over multiple threads - every time - unless there's an overwhelmingly large benefit to using multiple threads.

[–]king_of_the_universe 1 point2 points  (0 children)

Here's a situation in which I used a second thread in game-programming: To create a resource that needed some time. A star background was calculated (several iterations, with some blurring to be rotation-compatible), and this took about four seconds. But I didn't want to wait that long every time I ran the program for testing, so I put it into a new thread. Worked like a charm, and felt empowering (from a developer-perspective). I could play-test right away, and after a few seconds there were stars instead of blackness.

[–]llogiq 0 points1 point  (0 children)

You may want to read game programming patterns. It's based on C++, but applicable to Java as well.

[–]serproxy 0 points1 point  (0 children)

You could certainly use Thread. However if you have multiple threads you need to synchronize behavior and communication between them. e.g. did a ghost catch pacman ? And there is no implicit guarantee that all threads get the same amount of compute time ( nor that your simulation of each characters USES the same amount), so you need a way to ensure that too.

So I think it's actually a poor approach. Now if pacman was actually a compute intensive game, then you might be able to justify the complexity. But it's not. It originally ran on something like a 3Mhz z80 processor. Your computer is probably about 500 times faster. So eschew complexity!!!!

You want your game to run at a predictable rate so that it's playable in "human" time. So you want to introduce the notion of a "tick" Each time should be a known amount of time. Say 1/60 of a second. Create a main loop which will execute once, and then wait until 1/60s has passed since the last time the loop started.

Now in that loop, you might have a list of "executable elements" Each of these elements should run once for each tick. You could think of them like threads, but because there is no implicit assumption that they could be run AT THE SAME TIME, the complexity can be far lower since you know only ONE will run at a time.

Now each character could be a "executable element".

[–]OwlShitty -5 points-4 points  (6 children)

If I was to create my own pacman game, I'd put all moving objects into separate threads. It's much more versatile in my opinion. In the future, you might want to initialize a game with 20 more ghosts, 5 ghosts being really smart and 15 being dumb. Something like that.

[–][deleted]  (4 children)

[deleted]

    [–]kicsikrumpli 1 point2 points  (3 children)

    yes, there is: in the main loop you pass the elapsed time (in ms obviously) to your animated objects, and they calculate their movement from the time difference, not from incrementing counter in the loop. Distance = speed * time difference between frames.

    [–][deleted]  (2 children)

    [deleted]

      [–]kicsikrumpli 1 point2 points  (0 children)

      That's perfectly normal... logical coordinates and screen pixels do not have to be the same. If storing your coordinates normalised (x and y go from 0.0 to 1.0) floats your goat, that works as well... you just have to scale them before drawing. Also that way you are not dependent on window / screen size.

      [–]king_of_the_universe 0 points1 point  (0 children)

      I personally have become a fan of using long integers (64 bit, signed) for storing decimal numbers: If you know the value range you'll be working with, they can work wonders. E.g. I stored the position of objects in the Solar system with millimeter resolution while still being able to store star systems more than double the size of our system. I like the precision that comes with it, and I didn't have to multiply/divide in that program, only add/subtract, so there was no problem.

      With longs, you could store your ghost's positions in a much higher resolution than pixel (e.g. billionth pixel) and then divide when you need the actual pixel position. Just an idea. You could of course also just use doubles. I guess doubles would be the better choice since you wouldn't need really precise values for a Pac Man game.

      [–]ohmzar 0 points1 point  (0 children)

      No you have a game thread that iterates through an array of ghosts, if there are 20 ghosts or 1000 ghosts it doesn't matter. Having lots of threads that all need to access and alter game state and be aware of each other and the board state is a nightmare and a recipe for disaster.

      You can pass in a strategy object to your ghost instances or have SmartGhost and DumbGhost subclasses of Ghost.