Adore - Animations

Started by Calin Leafshade, Wed 16/04/2014 13:07:21

Previous topic - Next topic

Calin Leafshade

Hey ladies/gents

I've been working on Adore (my adventure game engine) and I'm currently looking at how to arrange animations.

AGS kinda works like this:

Views have Loops which have Frames which are references to Sprites.

In adore it's slightly different.
It's more memory efficient to store an animation in memory as a texture atlas like this:



So in adore we have:

AnimationSets which have Animations which have a Texture Atlas (which is taken directly from a file on the filesystem like all sprites in adore) and a list of Frames which contain the delay info.

Now, I know that some consider the whole View system of AGS to be a little archaic and unintuitive so does anyone have any suggestions as to how they would prefer animations to be handled?
What do you think of the idea of having a named texture atlas for animations instead of individual numbered sprites like in AGS?

Gurok

#1
Views are actually fine by me. Views and Loops is same terminology that SCI uses.

It would be nice if each loop could have X frames that play at the start, Y frames that loop and Z frames that play when the animation is stopped. That would let people do better transitions from standing to walking.

One thing I would like to see is the ability to group sprites as flexible boxes. Basically, I'm talking about what we currently do for text windows but not associated with any particular GUI. I want to be able to define 9 sprites that act as the top, sides, bottom, corners and centre of a stretchable box. Then, I want to be able to use that box anywhere I could use a sprite, where specifying width and height will stretch the box accordingly.

Something that could be improved is the system for deciding which loop is shown when the player is walking in a particular direction. When I was developing a Node JS-based engine (long ago), I had a system where you would specify which direction *in degrees* that a particular loop was associated with. For instance, 90, 180, 270 and 0. This would give far greater flexibility. The engine would simply look at the current gradient of movement and do arctan2 (I think) to get the angle... then find the closest angle in the available loops for that view.

Don't know about a named texture atlas. If you're suggesting something like "Kylie's north facing frame where her leg is slightly lifted" and "Chest of drawers with open drawer", then I think that's preposterous. Optional naming if anything. Maybe if you just named groups, where "groups" would include any array of sprites you like, that might be a good solution. Still don't understand the intricacies of how it might work though. Maybe elaborate on what you mean by a named texture atlas.
[img]http://7d4iqnx.gif;rWRLUuw.gi

selmiak

#2
maybe split the animation atlases (atlanti?) into 2 categories and have some more tree options below like:

Animations
+-Characters
   +-Hero (Here is where you set the character specific stuff, like starting room, position, walkspeed, etc)
      +-Normal walking animation atlas (4 directions, click on a + button for 8 directions)
      +-other animations for this Character
      +-yet another animation for this Character
   +-Sidekick
      +-Normal walking
      +-other animations for this Character
+-Objects
   +-animated water
   +-animated water with splashes from rock thrown in
   +-burning candle

Did I miss something? Probably, but imho the cleans up some of the project tree nodes.
edit: and of course allow for grouping/foldering/bundeling of animations to have it cleaner by the user's standards.

Radiant

It strikes me that memory efficiency is something you can fix at load time, i.e. by combining several sprites into a larger sprite in-memory when needed.

The AGS method is view/loop/frame where frames refer to a sprite, and as I understand it your method is view/loop/atlas where atlases refer to coordinates within a bigger sprite. I get the impression that's less convenient and more error-prone for the programmer.

Calin Leafshade

I disagree.

When does it make sense to have multiple different images that are *not* part of a single animation?

Generally speaking each sprite is part of one animation and used nowhere else so doesn't it make more sense to contain the images in larger and less numerous files?

Scavenger

I personally do not like image maps for animations, so unless there's a way to, say, convert an image sequence or animated gif to an atlas, it would be incredibly inconvenient for me. Animators generally do not work in the same way the image is stored, so that might make importing images into Adore kind of a hassle compared to AGS (which can import image sequences and GIFs). If you can find a way to solve this problem, I would be totally okay with it.

In terms of things I'd like to see in the animation thing, yeah, an lead-in and lead-out setting for animations would be good.

And something I find very useful when animating (spoilered because long):
Spoiler

Animation layers, too, would be good - instead of doing the AGS workaround of putting one character over another, you could instead layer the animation "head" over the animation "body" with frame offsets and have a single view for the player character - so the head can bob while the body walks. That makes talking whilst walking, something that AGS has struggled with for years and years, into trivially triggering the head talk animation regardless of what the body animation is doing. Layers could also be used to make customisable clothing (for QfG style RPGs, or even something as trivial as a player character changing clothes between scenes). If the character is wearing, say, a cloak, you can layer the cloak's animation over the player's sprite without having to have another entire walk animation with the cloak. This would make the game smaller, and the animator's life easier - as the animation could simply be done all in one go and exported out in pieces. Layers could also be used to layer on lighting effects, edge lights, etc as needed.

Per-frame layer offsets, as mentioned, might also be expanded to be rotated or scaled or even tweened, making programmatic animation trivial - think of Rayman 1, where every character was made of tiny sprites that moved around their own canvas rather than fully animated sprites.

+-Characters
   +-Hero
      +- Walking animation atlas
        +-Base walking animation
        +-Cloak Layer
        +-Head Layer (can be swapped with another atlas at run-time, say Head-Talk or Head-Scared or Head-Angry or Head-ChewingGum, which will keep the same x,y offsets so the head doesn't fly off the body regardless of what it's doing)

[close]

Calin Leafshade

The concept of Layers is definitely something on my mind and it's something i'd like to add very soon.

I will reconsider the atlas thing if it's very unpopular.. I kinda thought it would be more convenient.

Radiant

Quote from: Calin Leafshade on Wed 16/04/2014 16:38:55When does it make sense to have multiple different images that are *not* part of a single animation?
When some of them are reused in multiple animations. That's actually pretty common in HQ.

QuoteGenerally speaking each sprite is part of one animation and used nowhere else so doesn't it make more sense to contain the images in larger and less numerous files?
Not particularly. Contemporary computers should have no problem with smaller and more numerous files, and using these is more convenient for the programmer.

selmiak

With what Scavenger said he convinced me already that the atlas thing is not that convenient. When animating you skip between frames forwards and backwards, once the animation is done you just render out the frames while an atlas would have to be created by moving each frame around on some imaginary grid or cut out and defined later in the program. This is a lot of extra work, at least in my workflow.

Quote from: Radiant on Wed 16/04/2014 17:03:12
Quote from: Calin Leafshade on Wed 16/04/2014 16:38:55When does it make sense to have multiple different images that are *not* part of a single animation?
When some of them are reused in multiple animations. That's actually pretty common in HQ.
This is true, it would be convenient to import sprites/frames right where you use them with a 'import frame(s)' button. And when you want to reuse some frames from one animation for another animation you should just be able to select them in the editor (ctrl/shift select for multiple frames) and copy paste them to a new animation set.
The whole sprite handling as it is in AGS atm could be left out. No more looking up spritenumbers when starting a new view, no more folders in the sprites node that only double work as you also group views and characters on top of that in AGS. Same for Gui Backgrounds and buttons, just make it possible to import each sprite/image right where you work on the gui. How you store these is in the hands of the enginecoder. And LUA understands something like Graphic.Character.Hero.Walking.Coatanimation.3 probably even better than AGS script... With autocomplete even on usernamed animations it is probably even fun coding this. And if Adore automatically searches for each occurence of the name of the animation (e.g. Coatanimation) in the scripts when you change the name of it in the editor and asks you if you want to replace it, it would be very convenient ;)

SMF spam blocked by CleanTalk