Bigger creatures

[Leeloo]

But in fact there's an even bigger problem that maybe you can help us solve, not related to cal3d: The creatures in the game only have ONE square that they take up, so for bigger creatures in the game(deer, bears, etc), half of their bodies go through each other if they fight, or fight with you, and also go through other objects. Would suck if you're riding a horse, and face off with another rider, both heads would be stuck inside each other.

Theoretically, the problem is not that hard, the animals would just have to take up more squares. The main problem is that this would add a lot more processing on the server, since it not only has to mark all those tiles as occupied, but also check if they are all free, before moving or even rotating.

 

And then there's some problems with how to rotate the group of tiles 45 degrees, if a horse takes two tiles 100,100 and 100,101 when facing north, which tiles would it take when facing north east? Remember the map editor manual here, we wouldn't want anyone to be able to walk diagonally through the horse

[mikeman]

And then there's some problems with how to rotate the group of tiles 45 degrees, if a horse takes two tiles 100,100 and 100,101 when facing north, which tiles would it take when facing north east? Remember the map editor manual here, we wouldn't want anyone to be able to walk diagonally through the horse

An easy solution for starters would be to use a bounding box aligned in both x and y axis. When the animal direction is diagonal, the box just gets bigger.

That is, the horse takes tiles (100,100) and (100,101) when facing north, and when it's facing north east to take the whole rectangle area(100,100)-(101,101). It's not perfect but it can work ok for many cases. The collision detection for two big animals would be just a bounds check between two rectangle tile areas, which is fairly easy.

[duran]

only problem then is navigation on maps, as that is happening serverside. and from what i recall its about 25-50% or so of the current server workload?

 

hmm, boundingboxes could allow for tileless detection, every house, tree and so on would need a bounding box tho. one would have to more or less dump the tile based map system of today to get to work. unless the tiles that are set as unwalkable acts as a kind of bounding box in their own right.

 

right now the use of tiles are to limit where people can walk and to control hight. if a area is set unwalkable it gets a bounding box like effect in the system so that if a boundingbox around a diffrent model ends up moveing into it the model in movement will have to stop and look for a diffrent path. the hightmap side can stay on as it have only a boundingbox effect for stuff that is more then one highscale below it.

 

if this will increase or decrease the workload for the server i dont know tho. but it would allow for the server to move every mobile item by rotation and forward/back rather then tiles. only when two or more boundingboxes comes ends up with the same coordinates there is a need to stop and rotate the direction of travel so that it removes the collision and move the objects towards the destination.

 

in fact this could allso allow for diffrent movement speeds...

[Wytter]

in fact this could allso allow for diffrent movement speeds...

A) It would increase the server load a little. Not entirely sure how noticable the increase would be however. Currently 25-50% of the server load is done in the pathfinding as you say (using Entropy's A*).

 

It would not allow different movement speeds - there are unfortunately some limitations in the server design that makes it very hard to implement. It might be possible in the future, but don't expect different movement speeds within the next year.

[duran]

reason i belived it to allow for diffrent movement speeds was that someone moves x amount forward pr second rather then moveing them 1 tile per second.

 

allso, if it will allow for any size monsters then is it not atleast worth looking into?

 

as everyone moves as the same time one will at any point in time know where a box is. therefor one can calculate of a colision will happen or now and either hold back on the movement for one of those boxes or just stop them before the colision happens, rotate to avoid and move again. i can understand that tiles help on the load as they allow for checking to see if a tile is occupied rather then haveing to trace every traveld path tho. but then it puts a limit on the shape and size of items. that is unless we cut down the size of the tiles but that just ups the number of tiles that needs to be checked (alltho would allow for interesting rotates. hmm, maybe if say you have atleast one cut down tile inside a normal tile then you fill the whole tile? gah, no matter how one turns it around there will be a increased workload

[mikeman]

A) It would increase the server load a little. Not entirely sure how noticable the increase would be however. Currently 25-50% of the server load is done in the pathfinding as you say (using Entropy's A*).

I really have no idea how the server works, but I don't think it would make such a dramatic difference. You can have both bounding boxes(only for moving characters) and tiles(for static environment and moving characters).

A bounding box would just flag "occupied" all the tiles it covers. Nothing complex here, it's just a rectangular area. Currently, it's just like having for all characters a bounding box of 1x1.

 

When pathfinding, instead of checking if a single tile is occupied, you just check if one of all the tiles that the bounding box "covers" is occupied. In fact, you don't even have to check all the tiles, say for a bounding box of 8x8 tiles, you can check only the tiles that belong to the "edges" of the box.

 

That would take care of collisions against both the environment(which stays tiled as is) and other big moving characters(because as I said their bounding boxes have the ability to flag "occupied" the tiles). I think it's pretty straightforward, but as I said I have no idea how the server works, so I could be wrong.

 

@Roja: I think both options are fine, since "sit down" is an action, not a cycle, but for convnience it would be better to have seperate animations for all. But as I said, I don't think it makes any big difference, so whatever you choose.

Edited January 25, 2005 by mikeman

[duran]

hmm, interesting...

 

edit:

hrmf, seems they pulled a even faster one then entropy did. their monsters are stationary. you can see them a mile away and dont worry about it rushing you. its like the fluffy would sit around and wait and as long as you stayed x distance away from it, it would never attack.

[Grum]

Now we're back on technical issues, I remember the thread, and think it's indeed possible to solve it the way Leeloo proposed it there. You'd have to keep track of the orientation of the monster (but you have to do that anyway), and it shouldn't be terribly inefficient. There's one thing to think about though: characters can only walk forward, so it should be made impossible for a monster to turn itself into a certain orientation, walk forward a tile, and then get stuck because it cannot turn back anymore. Gues that means you will always have to use the full square it cxan occupy

[Leeloo]

I wouldn't say a square, but a circle / eitght sided regular polygon (octagon? ). If a big square animal walked towards a wall untill it can go no further, it wouldn't be able to turn 45 degrees. The worst would be a H or U shaped animal (head upwards), which would need only a single tree to get stuck.

 

But, it depends on how actors turn (one thing I didn't check yet). If they turn 0-45-90-135-180 to make a U-turn, we need to be very carefull. If they do the shortcut 0-180, we have a lot more freedom, basically we just need to make sure that the tail is not longer than the head If he can turn 180 degrees, he should be able to go back the way he came.

 

As for the efficiency, that's just about the only thing I was worried about, especially in the path finding function. But I never studied good path-finding algorithms, and I don't even know how the one works the server uses, so I'm not sure how bad it would be.

 

But, all that will be for Mihaim or whoever he accepts for working on the server to worry about.

[Grum]

In the worst case you could make another pathfinding routine for multi-tile critters.

[Puntif]

Another possibility for multi-tile monsters is to limit them to outdoor maps and limit them to flying creatures so that most or all pathfinding can be skipped - they can just fly over obstacles and re-appear at or close to their intended destination.

[Leeloo]

It would have to fly high enough that it's over the trees and houses, so it doesn't fly through a tree. And how do you attack a flying dragon with your sword?

[Wytter]

You throw an iceball at it ;-)

[Soldus]

Or you read the book for the dragons war cry and when you click attack, you have a chance the warcry will make him come down and attack you...maybe based on perception...

[Roja]

They would have to be quite high..yes..and dragons are huge..will fill your hole screen hehehe but I will be working on some smaller flying creatures, like birds, to see how they will work(as a test), with our current system.