Vicious Tactics Combat System: Discussion

[vespuleth]

This thread exists to discuss the VTCS. The scripts as they exist in the walkthrough can be found here and the walkthrough here. Please read both of these first as your question may already be answered. Also, please read through this thread before asking a question, as it may have been asked before.

[vespuleth]

This post is reserved to display frequently asked questions at the top of the page in easily accessible format.

/**FAQ**/

no questions asked

/**FAQ END**/

[doyleman]

Okay, I am slowly getting back into this whole ordeal.

What still puzzles me is how to remove tiles if objects obstruct your movement in certain areas. I'm beginning to think that with your 'Move' script, and grid layer tracker, it might be easier than what I'm making it, but I haven't a clue.

Basically, I think I can figure this out in a week, but that's only if I feel like getting frustrated for more than 3 hours.

[vespuleth]

your going to assign a number to each tile's event number; that number will eventually be a distance check against the character's move distance; anything that has an event number above that is removed. It'll make more sense when I get back to this. which i will. i swear.

[doyleman]

you're a genius. I think I got it now.

edit:
Well, I wrote ideas down on paper, and i've calculated everything, and this setup I have now seems like its working. I need to go over mult. senarios, however, to make sure. *is excited*

[vespuleth]

let me know if you need anything else.

[doyleman]

hm, there were 3 senarios where my idea didn't work (I can't quite explain them, but yeah).

I 'SERIOUSLY' think I'm getting there.

My question:
Did you do make each event for every possible obstacle? (maybe just naming it 'obstacle' + #, and changing the model in the enter battle script?)

I ask that because if you do a distance check against the obstacle when it ISNT there, the grid crashes.

Also: Deploy/undeploy your grid many times. If you don't eventually run into a bug where tiles start magically disappearing, something's wrong with my disc, or ps2, or something, cuz after I've deployed the grid 100+ times, it starts going haywire.

I'll get back to you if I ever actually figure out this problem (once I've had more time to experiment with the Event # concept that you stated).

edit: Yeah, that was a dumb move on my part. I was removing all the tiles except for the origin... Its cool

edit edit: I think I figured it out.

[vespuleth]

obstacles: yes and no. for things like trees and such, that's exactly what i do. it keeps my detailing in each map the same (as each map is the same) so everything is consistent and keeps my events manageable, while it also allows me to build a script that references each event's location so nothing is hard wired. for height obstacles, that is all programmed into the grid check, so they don't really need to be identified by the system so to speak.

you shouldn't be doing a distance check on obstacles. your tiles should be made to be capable of occupying an obstacle space (say, the same spot as a tree) and then check their coordinates against all of the obstacles (obstacle0-x or whatever) and see if it is in the same location as any of them, and if so, void the event number variable (that is, make it 99999999); that way, after all the distance checks are performed, all tiles greater than the member's move distance are temp removed and the ones located with obstacles are removed as well.

THEN (I know, lots of typing, sorry... I've replied to this twice and lost it both times) the grid really does nothing; all the path finding is engrained into the grid (each tile has its 'step number' as its event number) and when the player selects a location, the system checks 1) to see if a tile is there (if it's an obstacle or out of movement range, there shouldn't be a tile there) 2) if there is a tile there, what step number it is, and in what direction from the character it is 3) it finds the quickest route (combination of tiles that form a 1-x movement to the tile at distance x that has been selected) and moves the avatar of the party member along that route. 4) If a route cannot be found... you haven't implemented a rigorous/recursive enough distance checking formula. My system performs 3 different types of checks on each tile (actual distance w/o height modfier, actual distance w/ height modifier, relative distance based on neighboring tiles [this last one is the most important, but cannot be done before the other two; it does two things: a) it builds the necessary numbers for the pathfinding mechanism b) it insures that tiles that may seem like they are inside of the move distance but aren't, due to things like walking around obstacles (people or otherwise) are removed from the system; this brings up another point i will get to) and each of these checks is performed three times, shuffling the grid each time. that is, the first check is performed three times on each tile in the grid, the second check three times, and the third check three times. this means nine checks for every tile. it seems like a lot, but the grid still deploys in just under a second. this is because the first two checks eliminate the easy tiles, and the third check checks each neighboring tile (in other words, every tile is actually checking its four neighboring tiles for it's distance).

i mentioned earlier about the obstacles/people, and it reminds me of something that needs to be said: when you make your obstacle check (make it before the others; you want the grid to be as light as possible when that happens) check for battle participants that occupy those spaces as well, or else you will end up with two people in one square (it happens!). this should be easy, since you should already have a participant sorting script.

i want to go into the last check a little more, and then I am done. this is how it works: after all of the tiles are sorted by their actual distance, each tile is checked against it's neighbors. if one of it's neighbor's has lesser or equal distance than that tile (one of them will), then the tile will take their distance and add one. if they have a greater number, it will stay the same. each tile goes through this, then it all repeats. when you are done, all the paths are built, and you can safely eliminate any tile that is greater than the member's move distance.

I hope that doesn't confuse things.

[doyleman]

I got most of that made (the obj & height check) but the recursive (9 time) check with neighboring tiles was what was killing me.

I tried figuring out an easy way to check what tiles WERE neighboring the tile in question, without conditioning every possiblity. (1 tile has 4 neighbors, 84 tiles for a 6 layer grid, that's.... alot of checking), so I was seeing if I shouldn't just make a script for each tile, and directly call up each appropriate neighboring tiles (via event control change), load, do blah blah blah, etc. to see if it's going properly.

I actually had a simple method to figure out if a tile was working or not, but it worked ONLY on paper. Apparently, RPGM2 cant 'event info save' on a DIFFERENT event other than the event doing the saving (ie, even if you change control, it seems event info save saves the info on the current/parent event, not the changed controlled one...)

Your method does seem slightly confusing, but I think I understand the main core of how it should work (save for the 'neat' way of getting neighboring events), so I think I can get it done.

Thank you, though (after typing that up a 2nd time, I'd be annoyed if it didn't work after that, lol).

edit:

actually, why have each check 3x? and why 'shuffle' the grid (dont know what you mean when you say that...)

eh, i dunno....

[nate]

2 years later, i finally figured it out. i got it. cool.

[madcopper]

You do? Do you mind sharing it with me because I think his system is overly complicated. Also if you have a copy finished, can it handle changes in height for displaying tiles?

[vespuleth]

yes it can. maybe it seems overly complicated, but the complexity is necessary to allow for the feature implementation. in addition to height detection, it detects obstacles and adjusts the movement range, detects map edges and adjusts movement range and display, implements pathfinding optimization, displays varying sizes of grid for each character and can be adjusted on the fly, and demonstrates (relatively) rapid deployment.

edit: and to clarify dw's misstatement--we didn't finish not due to problems that we were having, but because vic and i both had some life issues come up. so i finished it alone, and that's why it carries his name. the only things i added after he parted with the project were the battle implementations (the grid was finished), such as ai (my ai is a heuristic combining different attributes to discern optimal behavior dependent on the given situation and the condition of the character. it took a long time to do because 1) i wanted it to be challenging 2) i didn't use standard stats so i had to program dependencies to the stats and 3) i wanted the computer not to make glitchy mistakes--i wanted it to demonstrate behaviors on par with the player (emulate learning, if not learning)). but rest assured, it was (is) finished. i have a hard drive with the full file on it, and a random battle generator (the test engine for comp ai). the thing i don't have is the chess game i made. sadness.

[vespuleth]

I'm double posting on purpose, to keep things organized.

To be clear, my AI took so long because I wrote it all together (I scripted a full behavior) and then I broke it into modules so that the different behaviors could be combined 'ad hoc.' then i wrote profiles for characters so that their ad hoc combinations fall in line with their character traits.

This meant that in addition to party affinities, they had personal affinities. and this also meant that class wizard didn't necessarily follow a certain behavior--such as cast magic. It depended on the actual friends and foes present. To reiterate, the hardest part of this was making the scripts modular (doan and vic both practiced this publicly, so it's not only my idea) to allow for the greatest number of possible behaviors, while maintaining functional behaviors no matter the combination determined. And my ai didn't choose which behavior to do based on probability alone (what can be done); they behaved on an ethos pathos logos algorithm (what can be done, what should be done, what they wanted to do) that each player had their own vars for that determined which behaviors won, creating it's own sort of unique behavior.

Hahah, thats the one thing about Vespuleth, he doesn't just "give" his knowledge, you have to understand and be able to interpret what he's saying. And trust me Doyleman can even vouch for this, Vespuleth has a way of explaining things that sometimes make your head implode. Just my two cents =P

Sorry Drew. And he's right.

[nate]

Sorry Drew? For what...?

And who's right?

Is there a post I didnt read? this isnt making much sense.

[madcopper]

Jan 15, 2009 21:45:35 GMT -5 vespuleth said:

yes it can. maybe it seems overly complicated, but the complexity is necessary to allow for the feature implementation. in addition to height detection, it detects obstacles and adjusts the movement range, detects map edges and adjusts movement range and display, implements pathfinding optimization, displays varying sizes of grid for each character and can be adjusted on the fly, and demonstrates (relatively) rapid deployment.

Good to hear. I made a grid today that does all of the above features, with the exception of pathfinding optimization, not sure where you are going with that. Took a few hours but I'm satisfied at the moment with my product.

Jan 16, 2009 16:50:20 GMT -5 vespuleth said:

This meant that in addition to party affinities, they had personal affinities. and this also meant that class wizard didn't necessarily follow a certain behavior--such as cast magic. It depended on the actual friends and foes present. To reiterate, the hardest part of this was making the scripts modular (doan and vic both practiced this publicly, so it's not only my idea) to allow for the greatest number of possible behaviors, while maintaining functional behaviors no matter the combination determined. And my ai didn't choose which behavior to do based on probability alone (what can be done); they behaved on an ethos pathos logos algorithm (what can be done, what should be done, what they wanted to do) that each player had their own vars for that determined which behaviors won, creating it's own sort of unique behavior.

This sounds very interesting, I will have to do some research into this. Give me a week and I'll let you know what I come up with.

[Drew]

Oh, no worry Ves. I actually think how you explain things is fascinating, you don't leave out any detail which is good. And I really hope someone can replicate the VTBS one day, it would be nice to just play it, even if it wasn't open source.