Spriter support on its way

[Trumgottist]

As you know, I've been looking into Spriter as a tool that might be useful for creating animations for SLUDGE games. I have now taken the first steps towards adding support for Spriter. If you don't know what Spriter is, I suggest that you head on over to their site and take a look. They now have alpha versions of the tool for both Mac, Windows and Linux. There will eventually be a pro version of the program (I've already paid for a copy through their Kickstarter drive), but the free version contains all the basics, so you won't be excluded if you don't want to buy Spriter.

So now that you know what Spriter is, you probably understand why I want to add support for it in SLUDGE. I consider it a good replacement for the Sprite Bank Editor in SLUDGE's dev kit. The Sprite Bank Editor will not be removed, and the DUC files will be supported in the future too, but Spriter does everything the Sprite Bank Editor does, and then some.

This is how a character currently is created in SLUDGE:

• Add all the images for the character to a sprite bank, and set their hotspots.
• Create a costume using the costume and anim functions. (This involves a bit of guessing to find out what looks good, and you will probably have to try a bunch of different numbers before you find something that looks right.)
• Add a character with that costume, and (optionally) perform additional animation with the animate function.

This seems like a better workflow:

• Add all the images to a Spriter project. Set their hotspots, and set up all the animations for the character visually instead of in the code. (Extra bonus: With Spriter, a character can be constructed from several different parts, animated separately.)
• Add a character in code, but instead of setting up the animations in code, simply refer to the SCML file, created in Spriter.

I like the possibilities that the extra functionality will bring, but I'm just as excited about how this could simplify the work process for the current functionality. But there remains a bit of work before that's possible. One thing I'd like your help with is figuring out what the interface should look like. Here are my thoughts (comments are welcome!):

Option 1: Allow addCharacter to be called with a SCML file instead of a costume. Done.

But if it's to be that simple, there will have to be a required naming scheme for animations so that SLUDGE can recognise them. A character has three basic modes: "walk", "talk" and "idle". Add to each name a number representing the direction the character is facing. This means that a character with all standard animations, able to turn in four directions should have animations called "walk0", "walk1", "walk2", "walk3", "talk0", "talk1", "talk2", "talk3", "idle0", "idle1", "idle2" and "idle3". Additional animations may exist in the file, and can be activated by the animate function (preferably by name).

Option 2: : Allow animations to be called whatever in the SCML file.

The downside with that approach is that we then still would have to construct a costume in our SLUDGE code, only that all anim calls would be replaced with animation names.

--

I think I prefer option 1, but there are probably things I haven't thought of yet, which is why I'm asking for feedback. (Once it's all implemented, it'll be more complicated to change how it works.)

That's it from me right now, but if you're interested in the Spriter support, please take the opportunity to think about how you'd like to use it.

[Erwin_Br]

Instinctively I'd go for option 1 because it's closer to the way SLUDGE works and doesn't create another exception/deviation that might confuse new users. It's probably also more versatile, because you can switch costumes. But I haven't looked at Spriter in detail, perhaps it's already possible to make variations in walk/talk animations that I'm currently using switchCostume for.

[Trumgottist]

You use switchCostume for variations in talk animations? I do that with animate+think (it's easier). But you're right that switchCostume is the only way to change a walk animation.

I guess you mean option 2, not 1? With option 1, you could change costume, but would have to change to another SCML file. Both SCML files could refer to the same sprites if you should want to (Spriter keeps the PNG files external to the SCML file), but you're right that with option 1 it wouldn't be possible to pick another animation from the same file.

Option 2 would lead to a lot more typing

addCharacter (myCharacter, 100, 120, costume ('myCharacter.scml', "idle0", "idle1", "idle2", "idle3", "walk0", "walk1", "walk2", "walk3", "talk0", "talk1", "talk2", "talk3"));

instead of

addCharacter (myCharacter, 100, 120, 'myCharacter.scml');

but it would be a bit more flexible than my other suggestion. Maybe there should be a new function instead of overloading costume with a new syntax?

I'm also thinking about how to refer to an animation. Using normal strings ("anim") seems intuitive, but then they'll be treated as all other strings by the compiler (which could work, but doesn't seem quite optimal) and show up in the translator (be careful not to translate them, or things will break). The alternative would be to invent a new kind of string for this. (@"anim" like in object C? §anim§?) From an implementation point of view, either could work, but I'm not sure about which I'd prefer when writing a game. (And that I'm planning to make another game is, of course, the reason I'm doing this). Do you have a preference, or maybe you have a completely different idea?

[Erwin_Br]

Yeah, I use switchCostume. Purely for semantics, though.

I don't mind a little more typing if it provides more flexibility and improves readability of the code, but that's personal.

I welcome the idea of referring to an animation name with @whatever. I'd rather not have these names appear in the translator/text output because it's easy to make a mistake and might be time consuming to filter them out every time you want to make an export for voice acting, translation or other reasons.

I'm also open to the idea of creating a new function instead of overloading. No ideas yet about how such a function could look like yet, though.

[Trumgottist]

No ideas yet about how such a function could look like yet, though.

If you get an idea, I'm ears, brains and various other body parts. (I.e. not all ears, but I'll certainly listen, and be thankful for any good ideas.)