Ryzom

That wouldn't be jumping, and people would instantly complain about it.
It would just allow them to hop around the world like rabbits, exactly the idiotic behaviour that we love to not have.

Making that impossible while allowing people to jump over (LOW) fences and small obstructions is what would be the only thing worth having.

(I know this post is old, sorry)
I do not like "bunny jumping" neither, and I understand that maybe could be difficult to do technically, but the reason of not implementing it just because we/someone don't like the attitude of those "bunny jumpers" is ridiculous (don't want to be rude), that is ugly and just not freedom neither in concept. I mean, society ingame is mature enough to handle with those exploting the "bunny jumping" thing, altough stamina/sp cost for jumping seems fair (but not optimal) to me.

But, more important than jumping, i think is the ability to explore the underwater world. dive skill would be definitly more awesome (and maybe more complex) than jumping.

anyway, ryzom is the first mmorpg i will decide to pay and i will keep doing it because is free software and represents more than my favourite game genre to me. I hope ryzom and Nel will evolve a lot this 2011

PD: happy "gnu" year everyone.

danto,

The "bunny hopping" justification isn't a reason for keeping it out of the engine. On the contrary if someone supplied us with a functional patch it would be accepted. The "bunny hopping" justification is why projects which are using Ryzom Core have no interest in implementing jumping. It's me, from the Werewolf project, saying the reward of hopping in contrast to the work involved adds very little to my game. Just for example. Likewise I would assume that's Winch Gate's stance as well. They'll get more benefit from improving gameplay, adding content and missions than they will from adding "jumping" to the game.

I know that the underwater areas were early plans at Nevrax for Ryzom. There's evidence of this in the asset database, including diving animations and underwater creatures. If someone had the time to implement this I'm sure we could get a member or two from the community to help with implementation details.

I'm glad to hear that you are enjoying Ryzom. Look forward to seeing you around.

Thanks,
sfb
/s

Jumping needs:

- Collision meshes for all IG (currently ground collision meshes and pacs primitives specified in 3d editing software)
- Collision meshes for all trees (currently pacs primitives specified in plant sheets or something)
- Collision meshes for all creatures (currently pacs primitives specified in creature sheets or something)
Cannot do collision meshes directly on a per shape basis because it would be too heavy since creatures are animated and consist of multiple shapes.

- Common code to build collision mesh from zone (on the fly, pre-built may be prohibitively large and pointless)
- A bit on the network that flags which entities the client needs to display using physics instead of pacs (flagged on player entities)
- Optionally a service which randomly selects zones to verify player client physics for a while to detect cheaters
- Client code to interpolate and match local physics of other players' physics characters with server provided values
- Update client animation code to animate characters based on their movement provided by physics to include jumping animation (also requires a method to know if a character is on the ground or not)
And some more stuff too

Jumping animations required:
- Idle_To_Jump
- Jump_To_Idle
- Marche_To_Jump
- Jump_To_Marche
- Course_To_Jump
- Jump_To_Course
- Marche_Arriere_To_Jump
- Jump_To_Marche_Arriere
- Jump (loop)
- Jump_To_Swim_Idle
- Jump_To_Swim_Front
- Jump_To_Swim_Front_Speed
- Jump_To_Swim_Back
- Jump_To_Fall
- Fall (loop) (exists already)
- Fall_To_Idle
- Fall_To_Swim_Idle (exists already)
- Fall_Death
- Jump_To_JumpDeath (when killed mid-air)
- JumpDeath_Loop (falling distance unknown)
- JumpDeath_End (hit ground)
All animations need to take all kinds of equipment into account.

And then a whole bunch of diving animations if you like that too.

is there any info about, what fileformat is needed for animations, how does the engine handle them(key frame split, separate files etc.)?
if devs really are aiming at adding jumping to ryzom i could handle the character animation part of it.

velogfx wrote:

is there any info about, what fileformat is needed for animations, how does the engine handle them(key frame split, separate files etc.)?
if devs really are aiming at adding jumping to ryzom i could handle the character animation part of it.

Someone more knowledgable in the process could probably answer, such as Kaetemi, but my experience with animations is that in NeL they're all separate .anim files. The build_gamedata pipeline goes through specified directories (e.g. w:\database\stuff\fyros\agents\actors\male\animation) and exports the animations.

You can see in Kaetemi's reply there are a handful of missing animation types. The names for the animation files (including these non-implemented ones) are detailed in his wiki page on Animation_Name_Structure. If you look at w:\database\stuff\fyros\agents\actors\male\animation\anims\FY_HOM_A_marche.max you can see this naming structure at work. So the Fyros male armored idle to jumping animation would be called FY_HOM_A_idle_to_jump.max. In that folder you'll see other animations that match the structure in the wiki article.

Implementing a new animation means using the same base skeleton for the race which is essentially just a biped figure and then animating it. Each animation type is, thus, a separate MAX file that is processed and exported by build_gamedata. When you open an existing animation you will see the biped figure as well as the mesh for the character - this mesh is merged into the animation file as a reference only and is completely ignored by the export process.

Thanks and hope this helps!

sfb
/s

One of the more challenging bits on the animation part, is that, in a way, the character is pretty much jumping blindly, and the animation system tends to not know for how long you'll be jumping, and you'll just be told 'you're now on the ground', and you have to handle the animation accordingly, have the animation in such way that the character always lands on the same foot, and that it works for both jumping up and down a cliff, and into the water, etc; although you can make the implementation in such way that the physics predict in advance where you'll land, disallowing any movement during jumping, but that probably wouldn't make it that much easier, perhaps even more complicated.
If you do decide to create animations, you will have to work closely with whoever implements jumping; follow the technical guidelines, create the necessary animations in a way that their transitions work in every imaginable case, and rework animations that get changed technical requirements after testing, etc.

Oh and you may want to take into account, that there are separate running animations per race, so you'll also need a transition for every race run loop to jump loop; and perhaps even just separate jumping loops per race.

ok i'll get a look on it

The best way to start is to start sketching on paper all the different cases, and splitting them up in reusable loops and transitions; so character running on flat land, jumping, and switching to walk while jumping, and continuing to walk after landing, or a character jumping off a bridge into the water, or a character running off a bridge into the water without actually jumping, or similarly a character running off a small cliff without actually manually jumping, or a character jumping up a cliff while walking and stopping to move when he lands, and all that and more for walking, running, backwards, landing in water, maybe even have it implemented for strafing left and right too, etcetera.

IMO before starting to work on the graphics and animation sequences, a thorough analysis as to the impact and cost (in time, resources, performance) of what needs to be done in the Ryzom Core codebase is essential.
General idea at the moment seems to be that the addition of a true third dimension (jumping/diving/climbing, whatever would be included) would effectively mean a complete rewrite of the physics engine and recoding of the world data (all the maps would need to be remade to include that third dimension, altitude data, different gravitation and air pressure between areas maybe?, etc. etc.).

Compared to that, the generation of the animation sequences involved is probably child's play in terms of investment of resources required.

My plan would be to add physics for player characters only, AI has no practical use for it and would be too heavy anyways. The largest amount of work is in fact getting collision meshes for all content, animations, and polishing up the character animation code. It does not require a complete rewrite of pacs, the physics system would run side-by-side with the existing pacs. You'd be surprised how much work goes into the character animation code. Implementing some physics is child's play compared to that.

That, and, an animator has no need to wait for a thorough analysis of the codebase. The animations need to be made eventually either ways.

kaetemi wrote:

My plan would be to add physics for player characters only, AI has no practical use for it and would be too heavy anyways. The largest amount of work is in fact getting collision meshes for all content, animations, and polishing up the character animation code. It does not require a complete rewrite of pacs, the physics system would run side-by-side with the existing pacs. You'd be surprised how much work goes into the character animation code. Implementing some physics is child's play compared to that.

That would still leave recoding the map data and database (plus all the code using it) to include what can be jumped over, onto, off of, how high a roof is (else you'd maybe jump through it), things like that.

I don't know the Ryzom animation format, but I do know that semi-automagic tooling exists for other engines where you put in some of the steps and the tooling generates all the steps in between.

kaetemi wrote:

That, and, an animator has no need to wait for a thorough analysis of the codebase. The animations need to be made eventually either ways.

true. But if analysis of the codebase shows it's not going to happen (too much effort for the expected return) the animator might want to do something else instead.

jwenting wrote:

That would still leave recoding the map data and database (plus all the code using it) to include what can be jumped over, onto, off of, how high a roof is (else you'd maybe jump through it), things like that.

Those ARE the collision meshes. And did you read my first long post?

jwenting wrote:

I don't know the Ryzom animation format, but I do know that semi-automagic tooling exists for other engines where you put in some of the steps and the tooling generates all the steps in between.

Even after doing your pose by pose, and interpolating the tweening, you still have to manually adjust the curves to get correct sharp/smooth movement where necessary, and add additional human imperfections into the inbetweens. It doesn't work automagically.

is there anything worth looking into (codewise) as far as the /alert emote is concerned, since it has a jump animation??

Ryzom core lack a true third dimension.
Ryzom (the game) doesn't really need to have jump or diving, it doesn't worth the time passed to develop it.
BUT it's different for actual developpers in search of a good MMO engine to start a new MMO. The lack of third dimension in RC is a very bad point. Every new MMO on the market have 3 dimensions and offer some sort of flying and/or diving.

Adding the third dimension should certainly boost the choice of RC for new projects and will enlarge the dev community.

Consider "hop" to start.