Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

pacman journal entries for 2005-08-11

Sign in to follow this  


5:05am [[ not ready to code yet! ]]

so i was thinking about starting with code last night. i don't think thats a great idea yet. see, the last thought i had code-wise was that if i was to have the maze object own everything else, there wouldn't be a way for the objects to get at the maze object when they needed to interact with it. there's no default owner member and creating and maintaining one seems like more work than should be needed. so instead, declaring implicit ownership seems best - we're not going to have any more than one maze. we might want to have the map own the pellet and power pill objects, as they're tied right into the tilemap portion, but that will require more forethought.

no, before we can start coding, we need to define the relationships between all objects; pacman eats pellets, ghosts kill pacman, etc.

5:48am [[ relationships ]]

pacman eats pellets.
test: when pacman's maze clip rect lines up with or passes over a pellet tile. (note - if pacman never moves any more than 1.0 units, then there shouldn't be any worry about the passing over condition)
result: pellet tile removes itself from the maze. score is increased by pellet worth. sound is played.

3:53pm [[ maze navigation ]]

i was thinking about movement in the maze again. pacman and ghosts can get away with only doing their ai and logic updates when their maze-clip rects line up with the tiles in the maze. this means we don't have to do ai and logic updates every single frame, speeding things up for us. but if we're going to do this, we have to have a way to find out when an object is lined up (or just passed lined-up state).

4:54pm [[ maze nav ct'd ]]

A) one way i came up with would be to check which tile you were 'almost' lined up with and check that against the last frame. if they're different, we can say we're lined up with a new tile and do an ai/logic update.

B) another thing we could do would be to force the game into a 30fps framelock situation - lamothe style. this way objects move at a constant rate and we can assure that they'd always land on a lineup state for every tile they head toward. unfortunately, if you're not careful, you could still have to do the step above for anything that moves at a rate that won't line up on every tile. then there's floating point error to deal with too. i don't like this answer.

C) the solution i like best that i came up with is as follows: we can assume that every object tends to be between two tiles at any given time. when we change which tiles we're between, we must have slid over a tile line-up state. whichever tile is common between last frame and this frame is the tile we would have lined up with. from that tile we can do coldet and logic, and even move the object along the new path however far it was supposed to have gone originally.

another issue i looked at was about slower computers. for any computer that's slow enough to have the pacman jump over several tiles in one frame, we'd need to deal with it. compensating for that couldn't be too hard, but is it an issue we need to deal with? that'll be something to deal with when it comes up. i had put a little thought into lag for solution C of the maze navigation problem: you could iterate over the tiles one by one using the solution rather easily. but again, we'll deal with it when it becomes an issue during development.

on my ride to work i was thinking about whether or not it would be wise to make a generic object class and have the ghosts and pacman be derived from that. on one hand, there are alot of things that are likely to be done alike between the ghosts and pacman. on the other, we don't know what those things are yet. until we can say that they share important common elements (and can back it up), then theres no reason to add more complexity to the solution.

i'm still debating whether or not to post these "informative texts" to my gamedev.net journal. if i do, i might feel i'd have to update more regularly and whatnot. if i didn't, i could wait until i was finished the project and put these texts all together to help anyone that might try to learn something from my work. at the same time, dustin isn't going to get any help from this until the end, and that isn't helping anyone. i lean heavily towards not posting, but i'll have to consult him on the matter.


[current mood: excited ^_^]
[listening to: Guilty Gear XX Soundtrack - Burly Heart (Potemkin)]
[... damned livejournal tags]

let's take the first line, of the above section, a step further. any sort of logic at all (aside from pacman/ghost interaction) will be performed only at tile line-ups. this means: direction changes (besides reverse-direction), maze collision testing, pellet and power-pill eating, and pathfinding.

what's left is to assess the power-pill stage, pathfinding, and pacman/ghost interaction.

pacman eats a power-pill.
test: pacman maze-clip lines up with a power-pill tile
result: power-pill tile removed from board. all ghosts in chase state or scared state are reset to starting scared state.

ghost is reset to starting scared state.
result: ghost immediately uses ai routine to find path away from pacman. standard move rules apply. change graphic set to 'scared' set. scared timeout reset to max.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!