Scratch

It's brilliant! 

I expect your version of Pacman to be the best. Keep working on it! 

That's spectacular! I'm a little bit curious as to how you plan on doing the AI, though...

coolstuff wrote:

That's spectacular! I'm a little bit curious as to how you plan on doing the AI, though...

The link in the first post is interesting, it outline the precise behavior of the ghosts. It was probably made by pacman pros to teach people how to manipulate the ghosts. If one copies the exact behaviors as outlined in that article, it should come out fine.

Thanks everyone and good call Archmage ("the Psychic"), I was up till 4:30 am last night/ this morning working on Blinky's Scatter script. (just uploaded new version btw) He finally ran into his corner and I crashed. I had already hit that "up too late - stupid phase" where you go back later and fix huge blocks by inverting a "greater than" into a "less than" lol.


I was programing each mode in a nested if/else block. Then each mode must be broken into another nested if/else block based on which of 4 directions the ghost is currently moving. That is ghost AI in a nutshell, you can get it working and then go back and tweak the logic to make it right. Most of the nfo is at the Pacman Dossier but naturally, the more you code the more you end up improvising. Like exactly which corner tile Blinky's target sprite goes to in Scatter, which way he turns when going down and left if in chase mode and the target tile is farther away on the X axis than the Y, etc, etc.
Of course the end result is a Scratch that is already lagging so badly while editing, I am having to pull blocks apart and even then it kinda sucks.

So now I'm faced with backtracking and (I guess) splitting the nests into separate, broadcast-called and variable switched on/off script blocks. At least then I could get back to editing without all the insane lag. Either that or just continue by copying sections, working on them unattached and then sticking them back in.

And now I see why Archmage's "order" post is so vital!! Sorry, I'm old and been doing this kinda stuff forever but I'm still a newbie around here compared to you guys, obviously. Plus I'm on dial-up so all my scripts so far have been small for my own uploading convenience.    Another problem with continuing in the "copy and nest" thing I'm doing now is I still have a ton of things to go back and add, from messages to fruit, dot "eating", costume changes, blah, blah.

So thanks so much everyone for the posts, information, and encouragement. Keep the suggestions coming please!! Lol, in the meantime, I'm gonna modem-crawl/search through old forum posts about 'optimizing' type strategies.

Last edited by Locomule (2010-07-11 13:06:36)

Had a moment so here are some thoughts...

Part of my problem is my effort to stick as closely as possible to the original, maybe that is something I need to get over? Another is my personal copncept of 'redundancy' in programing. I say that because I always considered code redundant if it was run in multiple, unnecessary repetitions during the same game cycle. So I was never really worried before about the overall size of my code, or that a bigger chunk of script alone would lag my interpreter/compiler/ etc until now. In fact, I have had a habit of getting crazy with the cheese wiz with complex subroutines, often having nested routines that contain exact copies of large chunks of an earlier routines, done just to save wasting a game cycle to get back. Right now the only compromise I can see is things like adding a specific routine to get the states (blocked or not) of all Pacs surrounding tiles to use that data for all the if/elses. It won't actually save me overhead per cycle I don't think but it will drastically reduce the size of my script block.

One of the things I envisioned was recreating the same sort of thinking in my code as in the original with a vision of a finished game where everything appeared to work just like the original. Your comments make me wonder if it wouldn't be better if not just flat out necessary to refine different routines instead of copying the original routines so closely.

I already have Pacman running nicely with apparently one minor bauble. You mentioned collision detection. The original, being a tile-based game, doesn't use collision detection per say. Pacman and a ghost only hit when they occupy the same tile. And none of the sprites check for collisions, they simply follow the programed paths of walk or don't walk according to the way the map data is programmed (in my TileData list)

In my opinion, the ghost AI will be the hardest thing to do correctly. I guess the benefit of my bloated but otherwise working current method is that it works basically just like the original. So naturally the AI scripts produce great results as far as copying original ghost behaviors.

From the limited Scatter mode coding I've done for Blinky here is why my ghost code is so redundant...

Ghosts must have 3 sets of AI, one for each mode 1. Chase 2. Scatter 3. Frightened
For each set, the ghost must have separate instructions depending on which direction the target tile/sprite is at that moment (that is 4 sets) and then each of those sets must include instructions for how to choose a new path at an intersection.
That is the only way I could figure out to 'program' the AI so to speak. So I guess I need to do the same thing here as in Pac's script.

Anyway, I will work on Pac and pull Blinky out of the mix for now, then start on the other stuff like you said. May have to do more backtracking than I'd like but oh well.

ps. thanks for that awesome link!! I used to play/map/run some tile-based online rpg stuff...

uh oh, can't resist an obscure shoutout...

Pain says Dragonspires and Delrith Online to win 4ever!!!

Last edited by Locomule (2010-07-11 20:05:36)