2D Toolkit Forum
2D Toolkit => Support => Topic started by: unikronsoftware on March 10, 2012, 11:14:51 pm
-
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
-
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 ;))
-
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.
-
What about a little addition text wrap in TextMesh.
-
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!
-
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...
-
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.
-
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.
-
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)
-
- 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!
-
- 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.
-
- 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.
-
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 ?
-
@fsqdeq - that never got fixed, but it wasn't in my TODO - I must've missed it somehow. I've added that in now.
-
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 :-)
-
It would be possible to implement something like that, but should it REALLY be part of the sprite system? You can actually achieve the same thing by adding a second MonoBehaviour with a register function like you described into a pool somewhere. That way it wouldn't need to be tied in to anything in particular and would just work with any other scripts attached to it too.
What are your thoughts on this?
-
I agree with unikron. I would like if 2D Toolkit remained light as possible so I always know what's under the hub. It should not turn into game engine and force us to use certain software architecture.
-
It would be possible to implement something like that, but should it REALLY be part of the sprite system? You can actually achieve the same thing by adding a second MonoBehaviour with a register function like you described into a pool somewhere. That way it wouldn't need to be tied in to anything in particular and would just work with any other scripts attached to it too.
What are your thoughts on this?
Of course, it can be worked around, just like any other feature :)
But I thought that pooling was so inevitable that such a function could be baseline, instead of having to insert the same Register() functions in all 3 classes for every 2D Toolkit new build.
@nikolic : about the weight, I mentionned it as an option (set on false by default), so your memory overhead won't change at all unless you decide to tick that cache box. And about the 2DToolkit framework, I don't really think adding 6 or 7 lines of code (it is that much really, just an Add to a Dictionary + a bool checkbox in Inspector) would make it that much heavier. It doesn't force you to use any architecture at all, it just gives an optional memory database for easier handling.
So yes, I think such vital feature as caching should be in by default, therefore in for next builds (to stay on topic), but if you don't feel it like that, well nevermind, I'll just work around ;)
edit : this proposition is just a surface scratch of what should be a support for pooling. But I admit the whole idea could weigh far much more if it wasn't just dictionary caching. Anyway it's a start ^^
And as memory management is the core of mobile development, I guess it could be a real advantage over other 2D solutions to implement a really good pooling structure :)
-
What I was suggesting was keeping it out of tk2d altogether, and attaching a separate monobehaviour to the objects you intend to cache with. For instance:
public class SpritePooler : MonoBehaviour
{
static List<tk2dAnimatedSprite> animatedSprites = new List<tk2dAnimatedSprite>();
static List<tk2dSprite> sprites = new List<tk2dSprite>();
static List<tk2dTextMesh> textMeshes = new List<tk2dTextMesh>();
void Start()
{
tk2dAnimatedSprite animatedSprite = GetComponent<tk2dAnimatedSprite>();
if (animatedSprite) animatedSprites.Add(animatedSprite);
tk2dSprite sprite = GetComponent<tk2dSprite>();
if (sprite) sprites.Add(sprite);
tk2dTextMesh textMesh = GetComponent<tk2dTextMesh>();
if (textMesh) textMeshes.Add(textMesh);
}
}
There is no in game overhead to this (apart from the memory for the component) and it more or less does what you suggested, and doesn't really need to be part of the toolkit. With something like this you could obviously extend it to support non-2dtoolkit objects, for instance we have a PopupText script which pops up a message and disappears after a set time, we pool those objects rather than the textmeshes & sprites used to construct it (its a compound object with a 9-slice, a sprite and a textmesh)
Edit: By that I mean I have no problem having a properly written and tested script like this in the private support forum, just I still don't see any good reason to integrate this directly into the toolkit.
-
Actually the problem of a MonoBehaviour to attach manually kills the purpose of automation :)
Some nested sprite prefabs can contain a lot of different sprites, and can even be multiplied by the number of scenes. So for maintenance, it's overkill to attach it by hand and could take forever to prepare, as opposed to an automatic registration by code, whatever sprite is built on the scene. Hence the insertion in tk2dSprite/tK2dTextMesh/etc Awake functions (just after it's been built).
-
My argument is that something like that is very very specific, and would not work in say, the PopupText example I provided. I always want to spawn a PopupText instance, not one of the 3 instances of sprites / 9slice / etc. that make it. And I spawn a PopupText very frequently, eg. whenever an enemy gets killed and I want to show XP earned.
Actually in my case, what I do is I have a pooler class, which basically allocates a fixed number of each of these objects (a fixed number per prefab type), and I get these objects from the dispatcher (if none are available a new one is allocated and pushed into the stack). This works really really well and is almost as efficient as it can be.
Actually, I think I am beginning to understand what your requirements are - something else I have planned might be a much better solution simply pooling sprites, etc. Could you email me with more specific info on what you're trying to pool and spawn, and I will try to explain what I'm planning if it will be a suitable fit to what you're doing.
Cheers,
unikron
-
I've spent the last five years making tile-based games. I highly suggest looking at how the RPG Maker series manages tiles, especially autotiles. RPG Maker has a huge audience behind it, and I believe this is because tilemaps are extremely fun to make in the editor.
I've seen a lot of game creation kits try to implement tile-based editors, but they're all pretty cumbersome when put next to the one in RPG Maker.
The best thing to do is download the latest version of the editor and check it out.
http://www.rpgmakerweb.com/product/rpg-maker-vx-ace
If you need any tilesets for testing, I have dozens of them. Just let me know and I'll send them your way. Big note: system is based on 32x32 tiles (or 4x4). Not sure how much of a problem this would be.
-
Actually, I think I am beginning to understand what your requirements are - something else I have planned might be a much better solution simply pooling sprites, etc. Could you email me with more specific info on what you're trying to pool and spawn, and I will try to explain what I'm planning if it will be a suitable fit to what you're doing.
Cheers,
unikron
Hey thanks for your continued attention, really. I admit my actual need is not that unworkable on my part (I've already worked it in fact), I was just asking for a pooling solution to avoid having to update each TK2D framework component with each update, so if you're not so much interested in such a feature, I guess the thing doesn't deserve the burden of implementing it in TK2D. At least I would have tried ^^
So for the release of my game I will work with my custom solution, don't worry it's not that much a problem, but still I think I would be ultra interested if you brought an advanced builtin pooling solution in the future (that would also manage the need for pooling or not, as you mentionned earlier). For reference, this asset store product seemed to go deep into pooling concept : http://forum.unity3d.com/threads/104320-PoolManager-2-Released!-By-Path-o-logical-Games
(I insisted because I feel such a level of pooling management would be an awesome addition to TK2D)
-
I could do a pooling system, or even provide ours as an example in the private support area. I have no problems with that. I will think about integrating it into the toolkit in more detail later and make up my mind then. My immediate thoughts are it should be as separate as possible so it can be used in other scenarios too, which is why I'm trying to persuade you to do the other alternative. That pooling system you linked to is more like what we have for our own stuff, though we wrote ours ages ago before this was released.
My main target now is to get a beta of the tilemap editor released, was planning on today, but a few more features need to be done before its released - collider mesh generation needs to be optimized, layers interface is not there yet (a slider to select current layer isn't really cool) and prefab spawning. I will definitely release a snapshot this weekend - at least if I can get some early feedback for the ready bits, then that would be really good.
@amaranth - It is too late to integrate any new features to the first release, but I will certainly look at this autotile stuff with more detail. Currently the system lets you drag and draw 3 or 3x3 tiles to a rectangle of any dimensions, but can't handle the joins between islands, which you will have to fill out yourself. As I mentioned, I need to get it out first, and then worry about adding more features! Thanks for the suggestion - I was thinking of how to automate this, but now that there is a "standard" of sorts, perhaps I could use the same format of tiles.
-
Oh gosh, I didn't know you were that close. Awesome! :)
-
Just to add to the pooling discussion: on my humble opinion I agree with what Unikron is saying. Pooling is not always necessary for everything, and when not necessary it just adds a useless overhead (even if very light).
-
Definitely vote for:
+ Integrated multi platform support (different atlases for different platforms, automatically loaded in)
-
Actually the problem of a MonoBehaviour to attach manually kills the purpose of automation :)
Some nested sprite prefabs can contain a lot of different sprites, and can even be multiplied by the number of scenes. So for maintenance, it's overkill to attach it by hand and could take forever to prepare, as opposed to an automatic registration by code, whatever sprite is built on the scene. Hence the insertion in tk2dSprite/tK2dTextMesh/etc Awake functions (just after it's been built).
If you really want to, you could always create an extension script and wrap the "create -> tk2d -> Sprite" buttons with "create -> tk2de -> Sprite" that calls the "create a sprite" function and then automatically adds the component to it. Your workflow wouldn't have to change at all, and it wouldn't have to be part of the base project. For auto-adding to already created sprites, you could write a simple editor script that does so. I have one for one of my own components you can copy:
[MenuItem("KS/tk2d/Add tk2dTransformExtension (Selected Objects)")]
static void AddTransformExtensionSelected(){
GameObject[] gos = Selection.gameObjects;
foreach(GameObject go in gos){
if (go.GetComponent<tk2dTransformExtension>() == null){
go.AddComponent<tk2dTransformExtension>();
}
}
}
[MenuItem("KS/tk2d/Add tk2dTransformExtension (Scene Sprites)")]
static void AddTransformExtensionScene(){
Object[] gos = FindObjectsOfType(typeof(tk2dBaseSprite));
foreach(Object go in gos){
if (go is tk2dBaseSprite){
GameObject goo = (go as tk2dBaseSprite).gameObject;
if (goo.GetComponent<tk2dTransformExtension>() == false){
goo.AddComponent<tk2dTransformExtension>();
}
}
}
gos = FindObjectsOfType(typeof(tk2dTextMesh));
foreach(Object go in gos){
if (go is tk2dTextMesh){
GameObject goo = (go as tk2dTextMesh).gameObject;
if (goo.GetComponent<tk2dTransformExtension>() == false){
goo.AddComponent<tk2dTransformExtension>();
}
}
}
}
Just replace the "tk2dTransformExtension" with whatever your component ends up being named (and replace the menu list, as I don't imagine you want it under "KS").
-
Thanks a lot Kyle, that will come in handy for sure :-)
-
No problem... By the way, I must have been on my 18th our when I wrote that and totally spaced out with the "GetComponent<>() == false" lines. I would replace "== false" with "== null" for the sake of your own sanity.
(note: == false will work, but unlike null it's possible a script will return false when it is not, in fact, null. I highly doubt you're overwriting the == and =! logic of your components, but may as well do it the right way :D)
Must have spaced out and the lack of compiler error + it works fine won out for the night.
-
+ Integrated multi platform support (different atlases for different platforms, automatically loaded in)...
This would be HUGE
-
I think that will be my next big target after the dust from the 1.70 release settles. I have a few good ideas & prototypes on how to do this without being intrusive to the end user.
Its a bit of a toss up between this and a revamped animation editor, but I may end up doing that first as I think it won't take that much time to do.
-
You briefly mentioned these features in an email, but thought I'd make note of it here to see other peoples opinions:
Tilemap updates:
-Support for animated tiles natively
-Live streaming, so whole mesh doesn't need to be resident, gets reconstructed as you move around
I would die for these features, and would pay extra for them.
-
+ Integrated multi platform support (different atlases for different platforms, automatically loaded in)...
This would be HUGE
I must quote this feature meaning multiplatform also as multi iOS devices (retina, standard, iPad, iPad retina)
-
I must quote this feature meaning multiplatform also as multi iOS devices (retina, standard, iPad, iPad retina)
that would be very cool..
i also would like to see sprite clipping, a clipping area where everything behind gets clipped , that would be very useful
-
Sprite clipping is actually possible using multiple cameras right now & viewports. This will be much more efficient than any software clipping solution written in a managed language. The other option is using destination alpha as a target mask like Scaleform does, but this means having more control of the rendering pipeline.
-
hi,
very new to unity and tk2d but saw the "ex2D" plugin and some good features could be part of tk2d maybe on top of what you (unikron) suggested :)
-2D Skeleton Animation Editor
- the nice sprite animation editor
cheers,
-
A feature i would love to see to the sprite collection, would be to add colliders (mostly custom boxes and polygons) and enter the Collider view with a single hotkey, it takes up way too much time to switch between tabs when doing polygon meshes. That would improve my efficiency by about 250%, true story.
Yeah, I know I could hax this myself but, that wouldn't end up looking very nice :P
Awesome job so far Unikron! :)
-
I'll change the behaviour so as soon as you switch to box/polygon collider, the editor mode automatically switches to collider edit mode. Makes sense from a workflow point of view.
Also, I'll add shortcuts to the different edit modes there. Any suggestions?
-
I'll change the behaviour so as soon as you switch to box/polygon collider, the editor mode automatically switches to collider edit mode. Makes sense from a workflow point of view.
Also, I'll add shortcuts to the different edit modes there. Any suggestions?
ctrl + w and ctrl + e, easy to access, and not used by unity itself from what i noticed. They make no sense though but that's where i keep my fingers most of the time.
Cheers mate! :)
-
I'd definitely like to see some upgrades to the collision system in the future. The ability to create multiple polygon colliders per sprite, or even better, automatically generate them for concave vs concave collision.
There's a recent asset (not yet released) announced on the Unity forums called Uni2D which looks to make this stuff an absolute breeze - http://forum.unity3d.com/threads/142608-Uni2D-tool-A-new-amazing-way-to-create-2D-games-in-Unity!! (http://forum.unity3d.com/threads/142608-Uni2D-tool-A-new-amazing-way-to-create-2D-games-in-Unity!!)
Might be worth you having a look at the video Unikron and seeing what you make of it, I understand it's a lot of work but right now it's at the top of my request list as creating colliders by hand can be a pain for complicated sprites.
Keep up the great work, best ?50 I spent in a long time!
-
@AdamOwen...
I have multiple (composite) collider support in the pipeline and got very far along with the interface and such, and it would probably be fairly straightforward to complete it. The catch was (there's always a catch), I had to make it work with frame based animation, and that's why it isn't built in right now.
Uni2D does look really really awesome, and I can see getting it myself for some quick prototyping physics based games. I personally prefer explicit control when building on constrained platforms
About automatic polygon collider generation - I had convex shapes working at some point on a branch somewhere, but I don't think I'll complete/integrate it anytime soon - theres still a lot more to do, and Uni2D looks like it'll just do it automatically. The colliders will be directly compatible, so you should be able to mix and match :)
I'm really itching to get on integrating support for the Farseer Physics port... that could be really really awesome (imho). Box2D is so much more stable than Physx for 2D stuff. Maybe after 1.80, if there is any interest.
-
Thanks for the info!
Understood about the frame based animation issues, glad to see it's something you've been working on though and look forward to updates.
It's funny you mention prototyping as that was my main usage case too. I generally don't like anything automatically generated when it comes to final builds and depending on what the tools generate I'd more than likely end up creating my own colliders once the art has been finalized anyway. The early stages are a completely different story though and spending the time setting up such colliders just to find they don't play well is annoying to say the least.
I was considering generating colliders in Uni2D then moving them into 2DTK so it's not a game breaker.
Box2D support sounds great!
-
Good feature to implement: tiling (repeat) same texture in one sprite. I believe this can be done through special shader.
-
Tiling from within a shader is expensive and prone to precision errors, especially with low precision shaders and large tiling amounts, behaving differently further away from the origin of the tiling. It also won't work correctly with mipmaps turned on as the uv gradient will be very very large at the tile edge and at that point, it will mip down and you get seams. There are ways to fix all of this, but all require more work in the fragment shader.
I think its "better" and more suitable as a general solution to tile in software to the right size, clipping in software. Or, tile in software exceeding the limits, and then use a clip shader to shape it accurately. Anyway, I'll release something after I figure out a nice and clean way to interface the clip shader without requiring a ton of dependencies.
-
A paint tile tool like Tidy Tile Mapper where you can set various types of style for each block (Surrounded, Centre Alone, Centre Surrounded, left, right, top, etc)
-
For the love of god multiple box colliders per sprite/ animation frame.
-
+1 for Farseer (Box2D) integration. (http://flyclops.com/author/jake).