new engine and a hope..

[MalaTempora]

sorry if i open a new thread to just yell my only and unique hope "to see soon"
the "solidity" of the players..
I hope to see this game put off the "ethereal" feeling that so many mmorpg have, this will give a lot (IMVHO) of bonuses to this game:
- the zergs will suffer becoming nearly impossible to attack a little group with all the total number.. (with solidity none can stand where i stand.. so i can really
be a block to be destroyed before heading mage or archers)
- there will be no more ppl passing over you ... maybe also mob solidity?
-tactics in fights will be much more deep
-zerg (yea again) will suffer also on movin... think on holdin the bridge with
a little strong and able number versus a lot of ppl zergin on.. :-D fantastic?

just my thoughts..

Mala Tempora (Hunter Ignis)
Massenzio Treesimo (Knight Ignis)

[UmarilsStillHere]

As much as solidity would help the game it has be spoken about before and the most we could deal with might be a knight spell to create a sort of "wall" stopping people from passing him untill he dies.

To have everyone 'solid' is to much load on the server.

[Pizdzius]

That's true, collision detection would really slow down the game and increase lag ;S

[Froste]

Not to mention we wouldn't be able to enter forts due to all the dead corpses (if anyone remembers)

[DemonMonger]

perhaps if we could pass through dead bodies but not living

[UmarilsStillHere]

Originally Posted by DemonMonger

perhaps if we could pass through dead bodies but not living

Because having to make solid entire zergs and run constant hit tests off moving targets wont increase server load?

It would be great if it could be done, but for now the servers just arnt good enough.

[Erikose]

Originally Posted by Pizdzius

That's true, collision detection would really slow down the game and increase lag ;S

Metin2 has collision detection which works fine. It's the numpties that play it that let that particular grindfest down.

[Pizdzius]

Originally Posted by Erikose

Metin2 has collision detection which works fine. It's the numpties that play it that let that particular grindfest down.

Tibia does too, but Metin still sucks like Tibia even if it's 3d ;P

[Erikose]

Originally Posted by Pizdzius

Tibia does too, but Metin still sucks like Tibia even if it's 3d ;P

Lol

True

[ArcticWolf]

Originally Posted by Pizdzius

That's true, collision detection would really slow down the game and increase lag ;S

Exactly.

I can't tell you how painful it is to design a reliable, fast and accurate collision & boundary detection algorithm without being too technical, but I'll do my best:

First, you have to check if you can move to a certain position, so you have to query the objects along the path (i.e.: if you want to move from A to B and you have a wall in the middle, you shouldn't be able to move, unless you're Chuck Norris or Surak). But that requires you to first calculate the path and then query the objects. With static boundaries it's easy because you can load the map in memory (you don't have to re-calculate them, so why not cache the data?), and pathfinding isn't difficult. The problem is, well, you do this for each movement message the client sends. And that's awful.

Now, suppose you have a super-efficient algorithm, but it doesn't do any checking on speed. That's right, you got speedhacks! How can we avoid that? We can calculate the distance over time. Sounds simple, and in fact it is simple, but that adds to your previously super-efficient algorithm, which is now a little less efficient. And you end up having roughly twice the memory footprint than your previous version, because now you have to "remember" your previous position.

And add status effects, such as paralysis or slow-down spells. That requires you to do some extra checking.

Ok, no problem, we can live with that. Now it comes the really awful part: checking against mobile objects. Now you have to tell your now-a-little-less-efficient-pathfinding-and-collision-detection-algorithm that it has to ask for all the objects along the path, check if there are any of those objects, check if you can move to that physical spot, check your speed, check if you can move and then move. That requires more memory.

Well, we could make use of parallel computing and multithreading! Not so fast, buddy. Two objects can't be at the same place, at the same time (unless you make characters non-collisional), so now you have to make your entire movement system thread-safe or process-safe. And that adds more overhead to your now-not-so-efficient algorithm. Split the map, and make boundaries non-safe environments, or maybe define groups based on density and topology and then assign a thread to it.

Or just throw your idea away and keep it simple.




PS: And remember that you have to flush changes to a database, and that movement functions are called quite a lot per user (and that you may have a lot of users online).

PPS: And, just in case, assembler won't do the trick for you this time. It's not worth it.

PPPS: You don't have to do all this for each message the client sends, because you should make an equipotential system: that is, ignore repeated or similar messages within a period of time.

That period of time may be variable, depending on the ratio of total incoming messages and total repeated incoming messages over time.