Jump to content
  • Advertisement
Sign in to follow this  
jwopitz

Unity Avatar Movement Approach

This topic is 3475 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there. This is probably one of my first posts here. I am currently working on the as3isolib (ActionScript 3 Isometric Library). You can read more about it here: http://code.google.com/p/as3isolib/ I am curious about how games like Dofus/Wakfu handle their avatar/NPC movements. Initially I had thought that the used something akin to the Filmation sorting algorithms (http://bannalia.blogspot.com/2008/02/filmation-math.html) but that seems rather inadequate for huge maps of many moving characters at many different elevation heights. So I put this question to the community to get some feedback: Do you think Dofus is using a) Fimlation sorting algorithms or do you think that it is using b) something more akin to how the Openspace Engine handles avatar/NPC movement*? *The OpenSpace Engine handles avatar movement based on tile sorting algorithms. At its heart it works something like so: - OpenSpace builds map iterating through 3D array to pre-position elements based on their 3D position in isometric space. - Avatars/NPCs are placed in the TILE sprites and then passed betw. the neighboring tiles sprites based on movement and direction. This means that an Avatar/NPC sprite is a child object of a tile/terrain object rather than a sibling. So basically you needn't have a scene render pass to resort the depths of objects because their intended depths are already set based on which tile OWNS them. In theory it sounds good but OpenSpace's execution of this is poor.* Now looking at the complexity of a Dofus/Wakfu map, I am starting to think they use the OpenSpace method simply because the variable elevations of the map might necessitate it. Looking forward to your input. Thanks, Justin

Share this post


Link to post
Share on other sites
Advertisement
Thought I might post some more links so as to clarify the variable terrain maps in Dofus/Wakfu:

http://staticns.ankama.com/ankama-games/www/img/screens/screenshot_big_game3_03.jpg
http://staticns.ankama.com/ankama-games/www/img/screens/screenshot_big_game3_06.jpg

Share this post


Link to post
Share on other sites
I don't really see the problem...
if you draw from back to front, you only have to worry about "objects" that colide by occupying both 2 squares or more and at the same time, overlappying each other.
The fastest way I can think of to solve this, is to have a ruleset on those objects:
- obj A, occupies a 3x3 square. So just define a function "drawFirst", that receives a square with coordinates local to the above object, and tells you what is the draw order.

so ObjA is at (x=10,y=10,z=2), size (x=3,y=2,z=2). You want to draw ObjB, that is at (x=11,y=11,z=1), size (x=1,y=2,z=1). You call ObjA->DrawFirst(ObjB) and that returns true or false.

Maybe I'm neglecting something, but it seems to cover everything :=)

Share this post


Link to post
Share on other sites
Unfortunately that is an over-simplification of the problem and I have been down that route before (I have tried so many approaches before I found the Filmation mathematics).

So it sounds like, based on your suggestion, that using a pre-sort of terrain tiles and still having the avatars/NPCs sprites as siblings to the terrain tiles is what you favor. So is that option a) that you choose?

Has anyone any experience with option b)? Anyone have any inside knowledge of how the Dofus/Wakfu engine works in this regards?

Share this post


Link to post
Share on other sites
Quote:
Original post by jwopitz
Unfortunately that is an over-simplification of the problem and I have been down that route before (I have tried so many approaches before I found the Filmation mathematics).

So it sounds like, based on your suggestion, that using a pre-sort of terrain tiles and still having the avatars/NPCs sprites as siblings to the terrain tiles is what you favor. So is that option a) that you choose?



I would split each avatar/npc/object into basic blocks (tiles).
You wont' need to pre-sort terrain, cause its a 2d grid. So starting from back to front, draw each tile and everything on top of it.

This solves the filmation algoritm problem too.
Can you pinpoint a example where this might fail? (I'm not saying that it doesn't, just that I haven't found anything that I can't fit in this algoritm).

Share this post


Link to post
Share on other sites
if you treat the Avatar/NPC sprites as siblings of the terrain sprites then you start running into the typical overlap issues especially considering the variable terrain height sprites are not only (in a 3D space sense) below, but also to the 4 sides of the avatar/NPC sprites. I meant to say the idea is sound, but the actual logic was over-simplified.

The only successful method I found for your approach was using the Filmation math. But again I feel that would be poorly suited to the whole Dofus-complexity issue. So let me rephrase this question specifically for you:

Assuming a different (non-Filmation) approach, what are your thoughts about treating the avatar/NPC sprites as child sprites of the terrain sprites that they are currently on? This would also assume that the child sprites would be nested above the terrain graphical assets to ensure that they indeed appear above. In order to move the avatar/NPC, movement would have to be handled by the terrain sprites "handing off" the avatar sprite to it the neighboring terrain (to be calculated based on direction of movement and other factors).

BTW this is targeting the Flash player so we must assume the techniques necessary for the Flash API's display list.

Share this post


Link to post
Share on other sites
Better yet and simpler to answer: How do YOU think the Dofus/Wakfu engine works with regards to those numerous variable heights in the terrain?

Share this post


Link to post
Share on other sites
Ok, I see a problema now :)

Avatar moving from tile A to Tile B.

if A.height>B.height
draw Avatar while rendering A until avatar is full on B
if A.height<B.eight
draw avatar in B.

any flaws?

Share this post


Link to post
Share on other sites
Quote:
Original post by jwopitz
Better yet and simpler to answer: How do YOU think the Dofus/Wakfu engine works with regards to those numerous variable heights in the terrain?


don't take it so serious :)
I haven't ever made a isometric game or though about it. And never player Dofus/Wakfu.

Was just trying to help, mate!!

edit: Looking through the screenshots I don't see a "problem" with "my" approach

Share this post


Link to post
Share on other sites
Maybe the text came across the wrong way. I apologize if you sensed any impatience or hostility. Not my intent. I was just saying, for the purposes of clarity, that that particular question might be easier to answer since I tend to be wordy sometimes.

I will look into your approach further to see if I can address this issue. For strictly tile-based elements where both terrain, bldgs, characters and such are restrained to single tile dimensions that might work fine (though I haven't been able to implement) but for elements that extend beyond a single tile's dimension (e.g. obj.w = 2 * obj.l) that might fail. Referring back to the Filmation math, that is where it solved issues, but then again not truly designed to address huge maps of variable terrain.

Thanks for your thoughts and ideas. Discussion produces the best solutions.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!