View Single Post
  #1  
Old 03-22-2002, 01:58 AM
ScotchTape
Fire Beetle
 
Join Date: Mar 2002
Posts: 12
Default Some thoughts on setting up zone movement points

Entre development thoughts on movement.

When I think of pathing points, I think of a collection of points in a zone that mobs follow giving the illusion of movement. Perhaps this could at some later point even be scripted, such that

SPAWN 0
AT TIME T
MOVE TO X1, Y1, Z1
AT TIME T+10
MOVE TO X2,Y2,Z2

but scripting is a later thing.

Right now, unless the active build has it, I don't see any movement code of this nature built in yet. So I'm going to put out some thoughts on it, as I haven't had a chance to sit down and do it.

I was thinking that a zone needs to have a collection of path points, and that within a zone there are two kinds of movement: spawngroup based movement (e.g., a group of goblin peons in RE that walk about) or spawn based movement (e.g., mooto in misty). I was thinking that there need be only a few points setup for the mob, and that the pathfind algorithm will move the mob from point a to point b at time interval (movement_timer, which is already defined in the code, but is more concerned with attack). Therefore, there needs to be a way to determine what the next movement point needs to be (which might be helpful later for triggers), along with coordinate information, and a relation to the spawn2 table. With all the above in mind, I have the following mysql SQL (not all SQL is the same ;o) table:

Code:
CREATE TABLE path_points(
  id int(11) NOT NULL auto_increment,
  spawnID int(11) NOT NULL default '0',
  zone varchar(16) NOT NULL default '',
  x float NOT NULL default '0',
  y float NOT NULL default '0',
  z float NOT NULL default '0',
  step int NOT NULL default '0',
  primary key (id)
 );

This table will then have all the necessary data. The next step, I'm thinking, would be to put in the necessary code to buffer the table contents when the zone loads. But we also need a structure to contain all the data from the table.

struct PathPoint {
float x; // x location to move to
float y; // y location to move to
float z; // z location to move to
int step; // step (a) in linear sequence of (a)
int spawnid; // id of the spawn
};

Now the entity object will need to be aware of what the last step it took was, so a quick property of Get/Set LastStep would be necessary.

Now the pathpoints need to be loaded. I'm thinking a linked list that has at least the following signature:

Public:
PathPoint* MovementPoints(float x, float y, float z, int step, int spawnid);

And then the linked list should be stuck into the zone class, such that the zone can do the movement checks every so often, which might be best defined by one of the existing timers or perhaps a new one, so that people might be able to control how often this occurs (for slower machines) or -1 to turn it off completely.

Next, the actual check comes up.

An iteration loop of the zone movementpoints with and another nested loop of the npcs, or maybe any entity? But I'm pretty sure only one of the derived classes has the x,y SendTo() method (which will need to be changed to an overload version x,y,z). I'm going to dip into some pseudo code now :)

Code:
if (timer-says-do-movement-for-zone)
while (!at-zone-movementpoints-iteration-end)
	while (!at-npclist-end)
		if (zone->movementpoints-contains-spawnid)
			{
			pathpoint pp = checkstep(spawnid,spawnstep);
 //return the struct with the coordinates to move to based on the spawns spawnid and current step
			spawn->SendTo(pp.x,pp.y,pp.z);
			}
//end whiles
freeupusedmemory()
That, I think and in theory, would cover much of the core issues surrounding zone movement.
Reply With Quote