Programming Game Logic 101

[NASH7777]

I found this site to be very helpful. Check it out

www-cs-students.stanford.edu/~amitp/gameprog.html#ai

[vespuleth]

excellent resource.

[NASH7777]

Indeed, I'm learning all sorts of things from it.

theory.stanford.edu/~amitp/GameProgramming/AStarComparison.html
I especially like that page for AI movement.



^The red line is the way I do it :-( lol

[vespuleth]

haha! i do it the blue way.

[NASH7777]

Well I've found some scripting ways to optimize the red way to be a lot more like the blue way. I call it the yellow way. Pretty much it goes straight up until right before the "C" enclose then takes a right then goes up and around to the point, so it's close enough to the blue way....
:-{

Ooh it's on the page actually


Pretty much i do it the first red way then analyze it to rid of extraneous moves, then retest the new movement, if it works, then I use it, if not I go the long route.

[doyleman]

I haven't a clue how I'd go about that....

[Deleted]

If it were an RPG I'd explore every square inch of the place.

And yes, I'm an idiot!

Man, I checked that link you posted Nash and I don't even know where to start. That's crazy man. Oh well, rpgs don't need good AI.

[doyleman]

who put the quarter in Will?


AI difficulty's depend on game type and (in rpgm2) focuses mainly on battles (AI can also reflect upon villagers moving, etc...).

In Turn Based battles, it's easy in that no distance checking is really needed, but to make sure that they do appropriate things based off of their status, that could be some challenge (actually, sounds more like alot of conditioning....).

In Action battles, it's trickier in that their are objects to obstruct AI (stupid Event: Move could ruin your whole ideal, however, I found a way to kinda fix this....). For my Zelda game, my custom AI was fitted in FIXED rooms (where I knew the dimensions, the object placements, etc), so there was 0 chance of them messing up (unless it rested in RPGM2's system).

And yeah... that's bout it.

[Doan the Nado]

I actually developed a form of collision detection, but it relies on Event Save/Load, so if you have more than one event doing this, you will have to wrap them in spin locks, and with too many of these, you will end up with a slow system or an event breaking through a lock anyways. The cool thing is that you don't have to physically enter all of the information about the environment... it will take care of itself.

If anyone is interested, I'll post what I did.

[realitybites]

Hmm, sounds interesting Doan, I would like to hear how you accomplished this feat. As ive tried a collision detection, but failed.

[NASH7777]

I can do it with a duplication and removal trick, not sure if doan has a better method...

[Doan the Nado]

Yeah, I pretty much did what Nash did. It involved saving the current coordinates, then duplicating a new event right on top of the moving one. That event's action script tries to move it forward one step right away and then load event info. Meanwhile, the original event waits like 1F then checks the Event: X and Event: Y variables to see if the duplicated event was successful in moving. If it was, that means there were no obstacles in the way. Otherwise, it would get stuck when trying to move forward and not load event info. Either way, you remove the duplicated event after the movement test.

So anyways, you can use that to see if it's possible to move in a certain direction. I use this info to set a flag (such as "Move West"). You can repeat this process for the other three directions in order to get information on where it's possible to move to. Once you have that info, you can decide how your event can, and should, move. Of course, you can cut corners a bit: if you want to always move forward if it's possible, you could simply move forward right away if the forward-moving test is successful.

In practice, I tried to use this for the movements of the ghosts in a Pac-Man game. It worked great for one ghost, but as soon as I added the others, there were immediately problems, but I kind of expected that. I did not use any locking mechanism to ensure that event loads didn't overlap, so it probably could have been made to work for 4 events. Get too many events doing that, though, and the game would lag a lot and eventually end up getting inconsistent and screwing up. (This is because the locking mechanism that we use is not 100% foolproof... there is a small chance of either deadlock or of an event getting through the lock when it's not supposed to.)

So yeah, that's what I did. It's probably the same thing Nash was talking about, but hopefully that gives you enough info to do it yourself if you want to.

[NASH7777]

Yes that's what I was talking about Doan, but for your ghost case there's an easier way. Instead of attempting to move the invisible event a direction and see if it fails, make it work(bypass objects) and do an elevation check. This way that event doesn't become 'stuck' and you don't have to remove him. Also then you don't have to worry about locking events because each ghost in your case can have it's own checking event; this would also be easier as you can just change in each ghost script one line, the one on which event control takes it over, also you don't have to check x and y, this way you only check z. Also there's a problem with duplicating events... after you do it so many times the game doesn't recycle it's data for events you've removed so the game locks up, in other words freezes.

[The Final Rune]

[white]This makes me think a rat in a maze. It'd be cool to test it out in an actual maze to see if the AI could make its way out. Although waiting for the system to make the calculations to figure out which way to go would be mind numbing, especially if you don't program for it to actually remember where the dead ends were. I can just see it hitting a dead end in a long hall. Then turning back around and getting stuck in the other end. Repeating over and over. I guess it would need four directional checks every step and flag markers to tell it where side paths were located. All very complicated.

This reminds me why my game is made to run of situational events. I can't handle the work involved in scripting really complex AI programs. Although the challenge of it is appealing.[/white]

[realitybites]

admin said:

Yeah, I pretty much did what Nash did. It involved saving the current coordinates, then duplicating a new event right on top of the moving one. That event's action script tries to move it forward one step right away and then load event info. Meanwhile, the original event waits like 1F then checks the Event: X and Event: Y variables to see if the duplicated event was successful in moving. If it was, that means there were no obstacles in the way. Otherwise, it would get stuck when trying to move forward and not load event info. Either way, you remove the duplicated event after the movement test.

So anyways, you can use that to see if it's possible to move in a certain direction. I use this info to set a flag (such as "Move West"). You can repeat this process for the other three directions in order to get information on where it's possible to move to. Once you have that info, you can decide how your event can, and should, move. Of course, you can cut corners a bit: if you want to always move forward if it's possible, you could simply move forward right away if the forward-moving test is successful.

In practice, I tried to use this for the movements of the ghosts in a Pac-Man game. It worked great for one ghost, but as soon as I added the others, there were immediately problems, but I kind of expected that. I did not use any locking mechanism to ensure that event loads didn't overlap, so it probably could have been made to work for 4 events. Get too many events doing that, though, and the game would lag a lot and eventually end up getting inconsistent and screwing up. (This is because the locking mechanism that we use is not 100% foolproof... there is a small chance of either deadlock or of an event getting through the lock when it's not supposed to.)

So yeah, that's what I did. It's probably the same thing Nash was talking about, but hopefully that gives you enough info to do it yourself if you want to.

Interesting.....have you tried TTC's variable locker? It might help with the events movement, thats how I made my custom to character AI movement, but then there is the whole if they can't get to me and run into a wall, the event is canceled out. No Idea why, just does. But yeah, with the lock, I could have the same movement script going for all my enemies, without lag and many interruptions.