Messages

1

Support / REQUEST: "Material overrides" for sprites (kinda technical)

« on: April 10, 2017, 01:46:59 am »

Hi! I've been using 2D toolkit for quite a while with my game Blast Brawl 2 (Steam link: http://store.steampowered.com/app/447980). 2D Toolkit is GREAT, much better than current standard 2D support in unity, but I have a few requests for tweaks/additions that would be extremely useful in certain situations.

This is (I think) my last suggestion, and it's by far my most niche/technical. (I totally understand if it's rejected lol)

Anyway: when adding more complicated mechanics to my game, I implemented a system to "override" the material of a sprite.

Examples:

• a character is frozen in ice, so I stop their current animation and give them a version of their normal material that adds an "ice filter" effect.
• Or, a character gets set on fire, so they are overriden with a "charred" filter.
• Space ship covered by a pulse shield? Filter.
• Stealth mode? Filter.
• etc etc

Other 2D toolkit developers may appreciate the feature, so I figured I would suggest it here. Also, the code to do this it is actually surprisingly easy to do! (I can provide it if it would make this more likely to be implemented.)

So:

REQUEST: Please allow dynamic material overriding in a generic way.
In short, it would be nice to be able to add code in tk2dBaseSprite (thus adding the feature to all other sprite types) that allows developers to set a material that is null by default.

If the material is NOT null, the sprite's mesh material is set to that material instead of the one defined on the sprite. (Setting the material back to null reverts the material to the sprite's default obviously.)

Honestly, the largest change I would suggest making is adding a material field in the sprite editor to allow developers to control this material from the inspector. Since this is a fairly programmatic-centric change tho that's not even necessary.

Also: In my implementation, I do a little bit extra. When setting the override sprite, developers can specify if they want the final material set to match the primary texture on the default sprite material. I have some small code that manages a static list of materials/clones and cleans up them to handle textures. This is potentially outside of the intended scope of 2d toolkit, but it allows much more generic materials to be used across a wide variety of sprites at basically no performance impact.


That's basically it! Honestly this feature has proven way more useful in practice than I expected it to, since it gives you a really efficient/direct method to do certain effects. Again, this totally makes sense as an out-of-scope feature, but it's actually not that much code in my implementation so I thought it might be worth it to suggest.

Cheers!

2

Support / REQUEST: More controls on AttachPoints (Z-depth, complex data, callback events)

« on: April 10, 2017, 01:14:47 am »

Hi! I've been using 2D toolkit for quite a while with my game Blast Brawl 2 (Steam link: http://store.steampowered.com/app/447980). 2D Toolkit is GREAT, much better than current standard 2D support in unity, but I have a few requests for tweaks/additions that would be extremely useful in certain situations.

I heavily use Attach points to make game effects line up with sprites on a per-frame basis. The support that IS there is very nice, but there are a few additional features that could prove extremely useful!

1: MOST IMPORTANTLY: Pleeeease add controlled Z-depth onto the attach points.
Currently there is no good out-of-the-box way to have an AttachPoint reliably positioned above/below a sprite other than to just set the Z-depth on the transform.

There is particularly no good out-of-the-box way to have the transform move dynamically in front of and behind a sprite on a per-frame basis (e.g., as part of a sword slash animation, with the sword starting in front of the body, slashing in front of the character, and ending on the far side of the sprite).

This seems extremely simple (though I know that's always dangerous to say about someone else's codebase) but more importantly, it seems like a particularly useful and straightforward addition.

2: Add complex data to each attach point
This is more of a "nice to have," but it seems potentially quite useful to have arbitrary data associated with each AttachPoint for each sprite in a collection. A good example is how there are "events" with data in animations, but I'd suggest having more fields/flexibility (e.g., add an array of strings so that users can have tons of data/parse out anything they want at runtime).

In addition theoretical "gameplay" use cases, this is potentially useful in a pure rendering context. Consider that it allows much more information for how an attached sprite should be displayed (e.g., display the mounted "head" sprite looking to the front instead of to the right on this frame). Coupled with the Z-depth addition above, this would help solve many issues for "body part" sprites I've run into without excessive external code.

I'd also suggest adding similar data fields onto each individual Sprite Definition in general, as it has similar potential uses (particularly on Tilemaps).

2b: Add callback events to process data in "2"
Just an additional request: if the data above is added, it would be extremely helpful if callbacks were added to make processing attach point changes easier.

If I could suggest a format, adding both a general callback and mapping a callback specifically to an attach point name (i.e., only receive calls for the attach point "head" is active) would probably be useful. Also, adding callbacks for when an attach point becomes active as well as inactive would be potentially nice. (There's a theoretical use case for developers who want to manually handle "disabling" an attach point while still leaving the relevant game objects active in the scene.)


In summary: AttachPoints are extremely useful! But what is there is slightly bare-bones. These are (imo) simple, general-purpose enhancements that allow developers to leverage them in much more technical ways.

3

Support / REQUEST: Easy cloning/reskinning of sprite collections and animations

« on: April 09, 2017, 09:55:03 pm »

Hi! I've been using 2D toolkit for quite a while with my game Blast Brawl 2 (Steam link:http://store.steampowered.com/app/447980). 2D Toolkit is GREAT, much better than current standard 2D support in unity, but I have a few requests for tweaks/additions that would be extremely useful in certain situations.

A very common use case I have run into is wanting to leverage already created 2D toolkit data (sprite collections, animation libraries) to make it faster to create similar data. A perfect example would be player "skins," where you can create another version of the player sprites and have all of the animations, attach points, collision, dicing, etc be the same but with different actual image data. Ideally the process to create this similar sprite should be easy, since I've already done all the work of setting up the base sprite.

Several generic options make this surprisingly easy, I'd like to request they - or something equivalent - be added to the plugin.

NOTE: I have actually implemented this (though in an older version of tk2d than is currently live) and can provide code if it would help make this a reality in the actual plugin!

1: DUPLICATING/IMPORTING SPRITE COLLECTION DATA
First off, it seems very difficult in general to safely duplicate sprite collections - I don't think this is currently supported? Duplicating a collection via Unity seems to require a rebuild (which makes sense) and unless things have changed in a more recent version I don't think there's an option in the tk2d editors.

Regardless, it would be quite helpful if you could make total copies of sprite collections, with the intent of tweaking the cloned data. The solution I implemented added an "Import" button into the menu bar of the sprite collection editor. Clicking it detects the active selected object, and if it is a sprite collection it will create sprites with identical names/images/data/etc to the ones in the selected collection (obviously IDs are not guaranteed to be the same, and my implementation didn't create copied sprites if something with the same name existed in the collection already).


2: "REBASING" SPRITES IN A COLLECTION TO POINT TO DIFFERENT SOURCE IMAGES
Likewise, it's nice to be able to do a large-scale edit of what sprites in a collection look like, without needing to update textures by hand per-sprite, and while leaving the original image files intact.

Sprite sheets seem like the obvious place to implement this, as there's a logical flow of:

• Make Sprite Collection
• Add Sprite sheet, set up sprites
• Duplicate sprite collection to make similar sprite
• Switch out for a new sprite sheet image
• Sprites now look different

but it should not be the only way to rebase images.

In my case, I stored all images for a sprite collection in a specific folder close by, so I implemented this the following way: I added another button on the menu bar of the sprite collection editor, called "Rebase Images." Clicking it detected the selected image or all images below a selected folder in the unity editor. For every selected image, it tried to find all matching sprites in the collection that were based on an image with the same name, updating their referenced image when it did.

It's possible there's a more generic solution that allows for more arbitrary file system setups, such as possibly requiring the user to specifically select the images to choose from. Idk! It's very useful though.


3: DUPLICATING/IMPORTING ANIMATION LIBRARY DATA
Similarly, it's nice to duplicate animations! I added a similar button in the animation editor that detected a selected animation library and copied all the animations in it into the currently edited animation library.


4: "REBASING" ANIMATION LIBRARY DATA TO DIFFERENT SPRITE COLLECTIONS
ALSO similarly, it's extremely useful to rebase copied animation data onto a new sprite collection(s). My implementation was pretty similar to the stuff above, and just changed referenced sprites based on matching sprite names.


That's pretty much it! Does this sound like something that might be added to base 2d toolkit? It's a bit more technical but very useful for large-scale projects!