Hello Guest

Author Topic: What next?  (Read 66261 times)

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Re: What next?
« Reply #15 on: March 16, 2012, 11:44:48 am »
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?

nikolic

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: What next?
« Reply #16 on: March 16, 2012, 12:08:06 pm »
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.

n0mad

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: What next?
« Reply #17 on: March 16, 2012, 02:21:49 pm »
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 :)
« Last Edit: March 16, 2012, 02:28:50 pm by n0mad »

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Re: What next?
« Reply #18 on: March 16, 2012, 02:40:14 pm »
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:

Code: [Select]
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.
« Last Edit: March 16, 2012, 02:44:00 pm by unikron »

n0mad

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: What next?
« Reply #19 on: March 16, 2012, 03:10:23 pm »
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).

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Re: What next?
« Reply #20 on: March 16, 2012, 03:51:34 pm »
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

amaranth

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 8
  • Amaranthians rule!!!
    • View Profile
    • Amaranth Games
Re: What next?
« Reply #21 on: March 16, 2012, 05:14:43 pm »
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.
« Last Edit: March 16, 2012, 05:26:21 pm by amaranth »

n0mad

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: What next?
« Reply #22 on: March 16, 2012, 05:56:14 pm »

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)

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Re: What next?
« Reply #23 on: March 16, 2012, 06:29:20 pm »
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.

amaranth

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 8
  • Amaranthians rule!!!
    • View Profile
    • Amaranth Games
Re: What next?
« Reply #24 on: March 16, 2012, 10:12:57 pm »
Oh gosh, I didn't know you were that close. Awesome! :)

Izitmee

  • 2D Toolkit
  • Jr. Member
  • *
  • Posts: 99
    • View Profile
    • Holoville Games
Re: What next?
« Reply #25 on: March 17, 2012, 07:07:23 pm »
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).

kemp40

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: What next?
« Reply #26 on: March 20, 2012, 09:07:13 pm »
Definitely vote for:
+ Integrated multi platform support (different atlases for different platforms, automatically loaded in)

KyleStaves

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: What next?
« Reply #27 on: March 21, 2012, 02:14:52 pm »
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:

Code: [Select]
[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").

n0mad

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: What next?
« Reply #28 on: March 21, 2012, 02:31:36 pm »
Thanks a lot Kyle, that will come in handy for sure :-)

KyleStaves

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: What next?
« Reply #29 on: March 21, 2012, 05:36:35 pm »
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.