Currently the animation editor just saves the rotation offset and position offset of jointed limbs, in the future it would be cool if we could see the animation editor save the part’s:
Size
BrickColor
Material
Transparency
Child changes (Support children would be any of the Light objects and any of the particle objects)
Use cases would be amazing, it would make animating with cool effects a lot easier because we could see, change and modify those effects in real time while we’re animating so we can make adjustments when we need to and not have to sit and watch the animation and make edits a thousand times in playsolo to get the perfect animation. Yes this would mean more data to download (guys, get over it. Games are almost becoming 1GB+ as a standard now.) but it wouldn’t really be that much more (unless your limbs have hundreds of instances parented to them) then requesting for custom colored terrain.
Just something to think about for the future.
EDIT: Just for clarifying, games as in non-roblox ones.
No, but when we do allow game downloading (thats going to happen one day, mark my words) it won’t be much of an effect. It’ll be like playing any game on steam, one massive filesize download then smaller ones as the developer updates the place.
Animations for those would look pretty dumb considering those properties can’t be interpolated. You’d just get ugly popping animations.
That’s a pretty messy way of doing it. Instead, those particles/lights should just been hooked into the animation and have their properties (emission rate, color, brightness, etc) interpolated over an interval like a part’s offset in an animation. Ideally you’d be able to hook in any instance into animations and interpolate any appropriately typed property (size, color, brightness, etc).
Actually it wouldn’t really affect animation file sizes at all. Animations are currently set up where every keyframe that isn’t empty has a hierarchy of the names of the objects that need to be animated and the CFrame value for that keyframe. All that’s saved is the object name and the CFrame value it should be at during that keyframe – other properties / objects that aren’t animated aren’t stored. The only change in terms of animation structure would be an additional StringValue per object to denote which property that value is, and that wouldn’t make the animation file sizes much larger.