  journal posting | 
Posted - 8/29/2005 1:03:05 AM | taking a glance at the more recent entries, i realize that posting that stuff is pretty pointless. noone's getting anything out of it. i should be sticking to summaries unless i feel i need to explain some algorithm or structure or something - all that time-entry stuff thats coming from my local journal isn't really very useful. live and learn i guess.
| |
| draw night | 
Posted - 8/29/2005 12:59:30 AM | yeah we had a draw night tonight. the theme was 'werewolf', thanks to phoe. i got this much:
as always, there are a number of things that are just plain fucked up, but overall its probably one of my better peices. i used Paint.NET for it and man i really like that program. i'm going to be able to color it rather easily with the same, as well. i might make some comics in the near future now that i can draw AND color with relative ease.
| |
| Saturday, August 13, 2005 |
| pacman journal entries for 2005-08-13 | 
Posted - 8/13/2005 8:02:05 PM | 8:09pm [[ ghost house ]]
i put a bit of thought into the ghost house, and i think i have all aspects of it cleared up. for one thing, at the start of the level or on new life reset, three ghosts are put into the house and blinky is put outside the front door. the ghosts will wait a period of time before one comes out of the house, and when they get out, they go right into scatter mode. blinky's going to start in scatter mode too.
when the ghosts return to the house after they've been eaten (eyes mode), the ghost will immediately exit in normal chase mode, but will be set to scatter as at the start of a new level. when the ghosts have to return to the house, they set their target to the front of the house and enter the house immediately upon reaching the target. they get to ingnore the wall when they go in, as well as when they leave. this is the only time this is allowed.
all thats left now from what i see is the level/new life startup and gameover.
| |
| pacman journal entries for 2005-08-12 | |
Posted - 8/12/2005 7:57:36 PM | 12:11am
yet again i found myself fighting against thinking about the data arrangement in code. i managed to realize i was doing it, and stopped. this is going to be an uphill battle.
1:16am [[ pathfinding ]]
appendage to:
pacman eats a power-pill.
result: sound is played. it should be only one sound that will play for as long as a ghost would stay in scared state. perhaps it should be used as the time length definition.
time to look at pathfinding. i heard someone mention something about graphs or something and i have no idea what thats all about. so instead, i'll make another method. for one thing, ghosts cannot go back to the tile they were on last. that means the only decisions they have to make are at intersections of 3 or 4 directions. let's look at how each ghost will decide which direction to take at an intersection.
i'm going to reference http://www.everything2.com/index.pl?node_id=499157 again for this.
the orange ghost, clyde, is random. when he hits an intersection he picks a direction randomly (but not the one he came from). this guy's easy.
the red ghost, blinky, is the shortest-route ghost. we need to figure out a way for him to find the shortest route from an intersection to pacman. [researching pathfinding algos] i'm only finding stuff on A* here. i don't really want to learn A*. instead, i just thought up a simpler way to do it. lets first imagine a vector from blinky going towards pacman. we know which directions along the x and y the vector will travel. these will be the set of directions we'll choose from to start. if either of the two directions is where we came from, we pick the other one. if the remaining route isn't available, we have to pick another route at random. if both routes are available, we pick randomly from them. that should work pretty well.
the blue ghost, inky, is a combination of clyde and blinky. if the distance to pacman is short, he'll act like blinky; otherwise he'll just move about randomly like blinky.
the pink ghost, pinky, is the oddball to me. he's supposed to act like blinky, but he's supposed to make 'opposite' turns.. well, that would make him move away from pacman with the algo presented above. [thinking] how about every other intersection, he'll act like blinky. every intersection in between he'll do things in the opposite direction. that might do the job. [thinking] perhaps another method could involve blinky's location relative to pac. if both directions are available to move in (as in blinky's method) and blinky falls along one, then the other is picked? that seems like it would be more likely to do pincer attacks that way. also, no reverse directioning crap. i like that better.
it looks like i need to explain blinky a bit more. i need to explain how we choose the direction he'll take. we need to first assume that an intersection has to have 3 or 4 exits. one of those exits will not be considered, as it is where we came from, reducing us to 2 or 3 choices. pacman can be chased directly in 1 or 2 of those directions. if the 1 or 2 direct chase routes are all unavailable, we have to pick from what's left.
this problem needs to be reduced in its complexity somehow. i want to make an ordered collection of possible routes and remove routes that we can't use. the top ranking routes are the one or two that would move us directly towards pacman. in the case where there's two, we randomly choose which of the two is ranked at #1. the other is then #2. all other directions are added in random order after. now we discard the route that we came from, and then the routes which are walled off. now we pick whichever is the most top-ranked.
blinky tries to find the "best" route to pacman:
method: is pacman above or below? yes: randomly add this direction to top-ranking collection, and randomly add the other direction to the non-ranked collection. no: add both directions randomly to the non-ranked collection. do the same for left/right. append non-ranked collection to top-ranking collection. step through entire collection and remove illegal directions. pick the first one remaining.
we might wind up taking a completely random direction to get to him, but it'll do its best at every intersection. pinky is going to have to be a bit more specialized, as his algo relies on blinky as well. we're going to go all the way through blinky's algo, and add a step just before we pick the first one remaining. if any of the directions remaining in the collection is the same as the one blinky's currently travelling in, throw it out if there are any others in the collection. then pick the first one remaining.
in alot of cases, this will cause the pincer effect i want. in some cases it'll make pinky look retarded. i don't really like that solution.
i think i need a third collection, containing the directions to go toward blinky. whichever distance along each axis is longer is the direction we want to use. no, this doesn't look right either. damn you pinky!
... how about if any of the directions remaining before we choose is in the direction pinky would head in to get to blinky, we throw them out unless there are no other directions to choose from. nope..
lets look at blinky again. we're choosing to randomly order the top-ranking choices, but what if we did it ordered? then pinky could just order in reverse and we'd have a solution. thats all we really want. ok, so how will we order? whichever axis has the shorter distance to pacman is ranked higher for blinky, and lower for pinky? whichever way we choose it shouldn't really make a difference i don't think. so that works out. lets redo blinky.
blinky tries to find the "best" route to pacman:
method: is pacman above or below? yes: add this direction to top-ranking collection ordering by distance to pacman along this axis, and randomly add the other direction to the non-ranked collection. no: add both directions randomly to the non-ranked collection. do the same for left/right. append non-ranked collection to top-ranking collection. step through entire collection and remove illegal directions. pick the first one remaining.
pinky tries to find the "best" route to pacman:
method: is pacman above or below? yes: add this direction to top-ranking collection INVERSELY ordering by distance to pacman along this axis, and randomly add the other direction to the non-ranked collection. no: add both directions randomly to the non-ranked collection. do the same for left/right. append non-ranked collection to top-ranking collection. step through entire collection and remove illegal directions. pick the first one remaining.
eesh. that was a pain.
4:43am [[ extra rules ]]
apparently blinky is supposed to speed up when there's a certain number of pellets left. torn right from the site i'm using, here is a table showing when blinky speeds up:
Level Pellets left
1 20
2 30
3-5 40
6-8 50
9+ 60
the other ghosts don't change speed at all (except for when they're in scare mode).
something else i wasn't aware of, but is part of the rules, is that every once in a while, the ghosts will enter 'scatter' mode and will beeline for their corner before going back to their normal chase ai. again taken from the site:
"The ghost will enter scatter mode four times for each life on each level. As they exit the ghost house, you can easily see they begin play in scatter mode. Blinky heads for the top right corner, Pinky for the top left, Inky for the bottom right, and Clyde for the bottom left. When the ghosts enter scatter mode is determined by a timer. Generally the first two scatters are the longest in duration, and the third and fourth are about 2/3 as long. Beware Blinky: he can still pursue Pac-Man in scatter mode."
it might be a good idea to generalize the blinky direct-route method for use for scattering and returning to the ghost house.
there's still alot to go over, like the pacman/ghost interaction, the bonus fruit, the tunnel, and ghost house stuff.
5:15am
i had forgotten to mention yesterday that when the ghost is in its scare state, it moves at a slower speed - 1/2 or 2/3 or something.
well, lets go over the pacman-ghost collision situations. when a ghost collides with pacman during hunt mode, pacman dies. whe a ghost collides with pacman during scare mode, the ghost changes to eye mode and immediately sets a direct path to the ghost house. the ghost regains its speed for the return trip - i beleive eye mode is even faster than normal speed. for every successful ghost-eat, you gain 200, 400, 800 and finally 1600 points. when you eat a power pill, the ghost-score multiplier is reset back to 1.
when pacman dies, the ghosts are reset to their positions at the start of the level, as is pacman. if it hasn't yet been eaten, the fruit is removed from the board and its timer begins again.
the tunnel is pretty simple. if you go completely off the screen, you're wrapped around to the other side, off-screen, and continue back onto the map. the ghosts won't likely be using it; on a rare occasion the two dumb ghosts will.
it looks like we only have the bonus fruit and ghost house stuff left. i need to find out how much the pellets and power pill are worth, as well as how many points you need to get a new life. i'm not sure if there's anything else to worry about after that. we should probably go over the scatter mode in more detail as well.
7:37pm [[ bonus fruits ]]
gotta remember to talk about game/level startup and gameover.
lets get the bonus fruit done and out of the way. from a new level start or new life restart, a timer begins. after the timer runs out, the bonus fruit appears just under the ghost house. the timer begins and runs for the same length, after which the fruit will disappear. this loops forever. however, if pacman eats the fruit, it will not appear again until the next level begins. torn right from http://www.everything2.com/index.pl?node_id=499157, here is a table of the fruits that appear each level, and their point value:
Level Prize Point Value
1 Cherry 100
2 Strawberry 300
3-4 Orange 500
5-6 Apple 700
7-8 Grenade 1000
9-10 Spaceship 2000
11-12 Bell 3000
13+ Key 5000
pacman eats the bonus fruit.
test: bonus fruit collision rect touches pacman ghost-collision rect, and bonus fruit in show state.
result: fruit not available until next level. score increased by point value of fruit. sound played.
| |
| Thursday, August 11, 2005 |
| pacman journal entries for 2005-08-11 | |
Posted - 8/11/2005 10:40:10 PM | 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.
10:04pm
[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.
| |
| pacman journal entries for 2005-08-10 | |
Posted - 8/11/2005 10:38:49 PM | 4:51pm [[ lots of stuff ]]
so yeah. i was thinking a bunch about this and didn't get to put it in here yet. lots of stuff getting in the way of this project. anyways.
so i figure the best way to do this project (as opposed to how i've gone about things in the past) is to leave the drawing until last. i know that i won't be able to debug the program if i don't have a way to see it, so i'll append "won't do any serious drawing" until the end. i want to leave the game open to add different methods of drawing, so i can easily add in a dx or ogl interface if i want to.
that being said, every tile in the map is going to have dimensions 1.0 x 1.0. i should probably explain the tiles themselves. as far as i can understand it, each wall tile has its line running through the middle of the tile. this allows the pacman and ghosts to take up 2x the space than they actually use. each corridor is only 1 tile in width, which means it would be easiest to make the pacman and ghosts' tile-clipping rectangle only 1 tile in size as well.
when the pacman's clip rect lines up with a dot tile (or passes over the line-up state of a dot), he eats it. moving the pac around isn't hard, when you line up or pass a tile, you stop at that tile and see if you can continue in that direction from that tile. if you can't, you're stopped on that tile. if you've pressed a direction (whether released or not) and you align to a tile, you check if you can go in that direction and go that way if you can. if you choose the opposite direction, you immediately turn around.
ghosts follow the same rules, sans opposite direction. the ai should generally check to see if its at an intersection before deciding on a new direction. each of the four ghosts has a different way to decide on a new direction. each also has a speed slightly greater than or less than the pacman. pacman and ghost collision should tested with a different rectangle than their map clipping rect. these rects are probably 3/4 the size of the pac and ghost sprites, which would be 1.5x the size of a tile.
when the pacman clip rect lines up with a power pill, the ghosts turn blue (scare state) and immediately do a pathfind to get away from pac. at every intersection, they'll do it again. this will last for a period of maybe 10seconds. when the power pill effect is over, they return to their original colors and resume their regular pathfinding.
during the powerpill effect, if the pac touches a ghost during scare state, the ghost is 'eaten' and changes to eyes. the ghost will return to the spawn box and will be returned to normal state for the duration of the powerpill effect. near the end of the powerpill effect, any ghosts still in scare state will blink until the effect is over.
i need to find out how they do the ai for each of the ghosts. i'm sure one of the ghosts is completely random, and one of them finds the shortest route to pac.. [researching] http://www.everything2.com/index.pl?node_id=499157 is the answer. [reading] oh crap. this thing is going to be more complicated than i originally thought. thats ok, i'll nail it.
order of programming:
- maze
- pacman on maze
- pellets on maze
- ghosts on maze
- power pellets
| |
| pacman journal entries for 2005-08-07 | |
Posted - 8/11/2005 10:36:50 PM | 7:30AM [[ intro ]]
so yeah i'm not going to do anything more than introduce this project at this time. dustin and i agreed to compete at something - make our own version of pacman. we're going to stick to the rules of the original, and we're going to have until the end of august to have something working and (hopefully) bug-free. we're both going to use c# and winforms to pull the thing off.
i'm using this project as a lesson in discipline for myself. it could be that the single biggest reason i haven't completed anything i've attempted, is that i wasn't concentrating on what i should have been concentrating on through most of my attempts at development. i've also had a problem with not wanting to have to redo anything; and i know i'm going to have to redo things, likely several times over. i need to force myself to deal with that fact in my own projects.
the last thing i'll make a note of right now is the somewhat different format of this section of the journal. i'm timestamping so that when i come back and go over my progress, i can see when i start to get bogged down and how badly it slows me. lets hope i can learn something from this. i'm also keeping the work i do on this seperate from the rest of the journal, as i want to see if its a better idea to do the journal by project instead of having a single day journal entry with miscellaneous postings. there isn't a need to jump around looking for each bit of a similar topic this way.
we'll see if i can't get something done after i get up from my after-work nap.
| |
| update! | 
Posted - 8/11/2005 10:35:36 PM | wow! an update. blame visage for this. i'm working on a pacman clone at the moment. a longtime buddy of mine challenged me to complete a c#/gdi+ pacman game by the end of august. i haven't made pacman yet, so i took him up on it. i've decided to post "what i've got" in here for no reason in particular.
in other news, i've received my programming c# book by jesse liberty. i started reading up on it a bit, but i won't bother with it until i'm ready to tackle the actual code for pacman. i have half an idea of how to use it, so for now i'll just hold off until i don't know how to do something in particular - and then look it up and learn it.
i read much of my winform prog in c# by chris sells, and it turns out to be more of a reference book to me than anything else -- and thats great. the one thing thats in there that i didn't get around to reading yet is the part on threading. i'm not sure how much threading will help me out, if its anything like interrupt programming, then it won't give me much help.
time to post my pacman journal entries.
[edit: oh, and i can get microsoft visual* through staples. for the price i listed in my purchase list. woot]
| |
|
| S | M | T | W | T | F | S | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | | | | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | | | 30 | 31 | | | |
OPTIONS
Track this Journal
ARCHIVES
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
June, 2006
May, 2006
March, 2006
October, 2005
September, 2005
August, 2005
July, 2005
June, 2005
May, 2005
January, 2005
December, 2004
September, 2004
|
