R15 animations interfere with gameplay

When R15 animation packs were announced, I was definitely excited. I mentioned that I even couldn’t like the announcement enough. The animation packs were supposed to breathe life into R15 and encourage more users to adopt it, but so far it seems it’s caused the exact opposite.

As a game developer, why would I want to support R15 when its custom animation packs can break how my game was meant to be played? For instance, if I don’t have crouching in my game, players can equip the Ninja package to crouch their character, gaining an edge over other players. Or, they can use it to fit into areas that they’re not supposed to fit into. Players can also use packages to distort the way their avatars use tools, as seen in the last image.


As developers, we can make a copy of the current Animate script, force default animations in there, and then override the default Animate, but we lose out on updates to the Animate script at that point. We could provide an option similar to the avatar scale changes which allows only the default animations, but there are non-default animations which don’t cause issues e.g:

Blocking those, we’d run into the same issue that gear has, where these assets are effectively useless since little to no games allow them. It’d be great if animations could be categorized as potentially game-breaking or not and allow R15 games to disable game-breaking animations. Competitive-based games like an FPS could disable these animations, while roleplay games could leave them enabled.

With that, we would also need to see a change in what kinds of animation packs are produced. The current packs have no diversity whatsoever, with their primary use being trolling. We have no “normal” animation packs, which is why I suspect we have so many game-breaking packages. If this doesn’t change, a switch to disable game-breaking packages wouldn’t be as useful because there won’t be any animations to equip in these games.

16 Likes

You can force a new animation script, or you can put down like 10 lines of code (when super uncompressed) to just replace the animations that can cause trouble. I do it on my game so the animations fit more with the gameplay, forcing consistency on mechanics and such too.

Here’s the code I use, it’s extra long because it waits for everything to load in (and I’m not good at compressing code sometimes). Belongs in a localscript.

local plr = game.Players.LocalPlayer
local char = plr:CharacterAdded:wait() or plr.Character
local hum = char:WaitForChild("Humanoid")
local anim = char:WaitForChild("Animate")
BaseID = "http://www.roblox.com/asset/?id="
local FallID = 230778860
anim:WaitForChild("fall"):WaitForChild("FallAnim")
anim.fall.FallAnim.AnimationId = (BaseID..""..FallID)

But yeah, I totally agree. The first time I saw the animation packs I immediately thought “man that’ll cause a lot of problems.” The ninja-crouch one is a perfect example.

EDIT: This code is written for R6 though; I’m not sure if the animation script for R15 is formatted differently or not, lol.

Hi Masteralan – thanks for the response. I appreciate the code you’ve provided, but some of the concerns I mentioned in the OP addressed downsides to a number of those:


[quote=“Masteralan, post:2, topic:40219”]
you can put down like 10 lines of code (when super uncompressed) to just replace the animations that can cause trouble
[/quote]


Ultimately this thread is also requesting a solution at the core of animation packs that solves a problem more fundamental to the animation packs themselves than the games that use them. Addressing these problems in individual places only patches the damage in certain areas.

Yeah, I replied with the downsides in mind, such as how forcing the script prevents updates, hence the simply “change the animations” solution. I’m not good at voicing my thoughts, sorry about that.

But yes, it is a problem that needs to addressed, but I was thinking you (or anyone else reading this) could use this as a temporary solution if it is actually affecting your(/their) game.

I think part of it is the likelihood of it giving advantages/disadvantages to players in many games is very low, and well-scripted games either replace the animations, the character, or have mechanics not affected by it at all. But again, you’re correct, it still needs to be addressed, or at least considered, so cosmetics don’t end up ruining the point of the platform.
But I don’t know, just my thoughts on it.

We’re currently looking at ways to change how core player and character scripts work, to address these issues. One of the things we’d like to improve is the separation of logic from data and parameters, so that developers don’t need to copy (and thus fork) a core script just to change one parameter, or add a special case. It’s essential that it is still possible to do this, when the developer actually wants to hand merge updates, but it should be flexible enough that people wanting only minor changes to default behavior don’t need to edit code.

It will need to be even more flexible than this, as animations that are game breaking in one game might be fine in another, it unfortunately won’t be as easy as marking them game breaking or not. It may even vary within different parts of the same game (e.g. a lobby or social area vs mini-game). Everything should be moving in the direction of developer control, IMO. For now, I like @Masteralan’s approach of blacklisting only animations you know are a problem in your game.

2 Likes

This becomes maintenance problem. If you don’t notice a new animation pack has come out, players could be using game-breaking animations for a week or longer.

Also, to reiterate, another step we can take is to start diversifying animations released so a number are more normal instead of for trolling, since toned down animations likely won’t cause issues with games.

If you’re afraid of future animation packs being a problem too, then you can just replace all of the animations. I don’t find it that hard to animate, but if you don’t want to do that, just replace everything with the default IDs every time. Or use custom characters (still R15, just dummy rigs though) then LoadCharacterAppearance on them to avoid the animations being loaded in.

Replacing all animations is not an option I am considering because I want players to be able to use non-game-breaking animation packs that they paid to be able to use.

Manually whitelisting them as they come out is a maintenance problem.

All of these issues are elaborated on in the OP. There is no action I can take as an individual developer that satisfies the needs enumerated in the OP.

Curate a list of game-breaking animations and replace those with default animations. Seems pretty straightforward.

1 Like

If there were a good solution I could implement as a developer, I wouldn’t be posting here.

So you want us to curate animations that we think could break your game? I think what I’ve suggested is a good solution. You could alternatively curate a whitelist, meaning that new animation packs won’t break your game when they come out. You’d have to let it in.

EDIT: it being “a maintenance problem” does not make it a bad solution. It means slightly more work, sometimes.

No. I don’t care about animation packs that break just my game. The concern is animation packs that cause problems in a significant amount of places. Animation packs, while cool, were created to grow the usage of R15. They become moot if developers, again, in significant amount, just start turning them completely off in their games.

It also means players won’t be able to wear the package they just spent $10 on for a week or so in my game.

1 Like

Yeah, but that’s not Roblox’s problem. As soon as a package comes out, test it, whitelist it, done. Like 15 minutes of work. A day when playing your game when I can’t use the animations I bought is not a big deal.

@Osyris enlightened me as to some actually critical problems, such as Ninja being able to jump through walls. Your problem with the animations, however, is incredibly game-specific. Throwing out phrases like “significant number of places” doesn’t mean anything. How many is a significant number? What does it mean for one animation to break one game and not another? If they’re using the same labels, how would you know the difference?

Because these animations are meant for general use, there’s no way that Roblox could label them in any meaningful way to everyone that uses them. Probably not even a “significant” number.