What next?

[unikronsoftware]

Hi folks,

The new tilemap editor is nearing completion and I am happy to say it will be a free upgrade to everyone. A beta will be posted in the near future in the private support forum.

What other features would you like to see after that? I have had a few suggestions, and some areas clearly need improvement. I have only one constraint - any feature added would have to either co-exist, or be compatible with the other features in the toolkit. I try very hard to keep backwards compatibility with older versions, and unfortunately this means some features which aren't very nice will have to stay or in some way kept compatible.

So, what would you like to see in a future update? I have listed some of the suggestions we have had so far...

• Sprite collection interface update (multi select and change parameters on multiple sprites simultaneously, etc. We have had some gorgeous mockups of this)
  
• Integrated multi platform support (different atlases for different platforms, automatically loaded in)
  
• Animation editor upgrade (this is long overdue in my opinion, but generally, our workflow fits quite well with the way it is right now)
  
• More GUI elements and improvements (2D Toolkit isn't really meant to be a large-scale GUI solution, but no harm in having more GUI elements)
  

Please feel free to comment and/or suggest any other improvements.

Cheers,
unikron

[Izitmee]

I'd definitely vote for Integrated multi platform support.
Also, being able to undo (at least simple things like sprite color changes) would be great (http://www.unifycommunity.com/wiki/index.php?title=EditorUndoManager )

[Izitmee]

By the way: another great addition would be sphere colliders. As of now, each time I use a ball (which my game is almost completely made of), I have to add that outside of 2D Toolkit.

[gerlonx]

What about a little addition text wrap in TextMesh.

[KyleStaves]

The two things I would really love to see (in addition to that list; editing the parameters for multiple sprites at the same time is going to be epic).

1: In-string color formatting for text meshes (so you can say something like textMesh.text = "[#000000]This is black and [#FFFFFF] white [#000000] text."
2: A "clipping area" that automatically clips any meshes underneath it (so that only parts of them within the area are displayed. This would make it much easier for us to roll our own GUI elements (like scroll lists/areas and what have you).

Whatever you decide, keep up the awesome work!

[unikronsoftware]

KyleStaves - you can actually get something similar to the tinting of the textMeshes, using a texture gradient (but have solid color swatches in there), and using ^1..^xx in there. Some kind of markup for color would be pretty useful, and I have added it to the TODO.

The clipping area is also a very useful, and I do have a few ideas on how to implement it without adding significant overhead.

Izitmee - About the sphere colliders, the reason it isn't in there by default is that the only animatable collider object is the box collider, and adding a sphere collider as an option means that if someone animates a sprite where one frame is a box collider and another is a sphere collider, it would have to be deleted and recreated, freeing and allocating memory in the process. If everyone is happy to introduce the possibilty of doing this, I can easily add it...

[Izitmee]

Oh, now I understand about Sphere Colliders - I still never used animated sprites. Actually, I withdraw what I said about it, and now I prefer for that feature not to be there. I think it's better to have to add some things manually, than to have them automatically, with the risk to forget they might have less-than-top performance compared to the rest.

[nikolic]

I vote for:

• Integrated multi platform support (different atlases for different platforms, automatically loaded in)
  
• More GUI elements and improvements (2D Toolkit isn't really meant to be a large-scale GUI solution, but no harm in having more GUI elements)
  

At the moment 2D Toolkit has everything I need to finish my game. I'd be happy to see what is listed above in next few months when I go iOS path.

[n0mad]

Same as Nikolic, current 2Dtoolkit has everything I need to finish my game (and it's a lot), but more GUI solutions would be welcomed :-)

Plus :
- a fully supported sprite clipping
- and an enhanced version of the current animation system (don't know how planned enhancement is looking like, though)

[Dgizusse]

• Integrated multi platform support (different atlases for different platforms, automatically loaded in)
  
• Animation editor upgrade (this is long overdue in my opinion, but generally, our workflow fits quite well with the way it is right now)
  

A nice, artist friendly, animation editor would be awesome!

[storm33229]

• Integrated multi platform support (different atlases for different platforms, automatically loaded in)
  
• Animation editor upgrade (this is long overdue in my opinion, but generally, our workflow fits quite well with the way it is right now)
  

A nice, artist friendly, animation editor would be awesome!

Seconded. Even as a programmer, the guess-and-check numeric index system is not ideal. I have a recommendation as to how it may look too: http://docs.garagegames.com/tgb/official/content/documentation/Tutorials/Feature/images/AnimatedSpritesFigure8.jpg

That is a picture of GarageGame's Animation Builder inside of Torque2D. I've used this before and it was really easy to construct the animations.

[dead1ock]

• Integrated multi platform support (different atlases for different platforms, automatically loaded in)
  
• Animation editor upgrade (this is long overdue in my opinion, but generally, our workflow fits quite well with the way it is right now)
  

A nice, artist friendly, animation editor would be awesome!

These 2 are definitely the most important to me. Having a better way to determine which animation is playing by name instead of clipId would be very nice.

[fsadeq]

Was the Raycast/tk2dButton issue ever addressed? This is when if the timescale was set to 0, then the button events never get fired. I think you suggested using some proxy class for setting the scale, but I believe the problem was with the Raycast itself ?

[unikronsoftware]

@fsqdeq - that never got fixed, but it wasn't in my TODO - I must've missed it somehow. I've added that in now.

[n0mad]

Addendum :

A very much needed feature, for pooling purposes (which I think all devs are using to an extent), would be to give an option per Sprite Collection/TextMesh to store each created instance in a static Dictionary on Awake().

Actually we have to hunt down sprites manually for pooling, with transform.Find(spriteInstanceName), which can be very slow on complex intricated prefabs.
With a static Dictionary, we would just have to call the said instance by its name (ex : tk2dSpriteCollection.pool["enemy1"]) to use it. This would be undoubtedly way faster for load times than transform.Find().

I'm using a hack for now in the Awake() functions of tk2dSprite, tk2dTextMesh and tk2dAnimatedSprite, using a Dictionary.Add(sprite.gameObject.name, sprite), but it's not optimal.

Would it be possible to implement such a thing ? It would really not be long, but would help a ton :-)