feature request: layer offset

My question isn't if these things should be done in a game, it's if they should be added to a game engine that's already bloated.

Truth is the user can already do these things as is.

Layers, just like groups, families, etc are a way to manage objects, albeit ways that do different things, rotation for example, isn't done with families, but it could be.

With that in mind, using a layer to move a group of objects around, at least to me, seems like it should set off some warning flags.

One of them saying "could this not be done another way?".

A behavior perhaps?

Also, I think there needs to be some discussion as to what parts of this are actually related to the camera, rather than the objects positions.

sqiddster - families in families is the same as simply adding both families to one object type, so I don't think there needs to be a new feature for that. I'm not sure families with different plugin types is even possible, because the whole point of families is so you can write your events once. If you go to add an action for a family with both the Sprite and AJAX plugins in it, which actions do you show? What if you run an AJAX action on a Sprite instance or vice versa? etc...

As for the other use cases, I think the complexity problems I outlined with layer offsets means that it would be better to find a different way of solving those problems, without having to offset layers.

If you go to add an action for a family with both the Sprite and AJAX plugins in it, which actions do you show? What if you run an AJAX action on a Sprite instance or vice versa? etc...

you only show the actions they have in common!

fldr - between something like AJAX and Sprite, I think that is pretty much no actions at all, making the family pretty useless!

^ The ajax plugin isn't even a 'world' type plugin...

this would be actually best done in a group functionality, if you see a group as positional nullobject

you could see it as a "layer" and offset however you want, it can be everywhere, can have multiple families in it

you can add and remove things from it, a group is a parent of all children that are in it works on sprites, you can destroy groups, ...

move and rotate would update the world position of all sprites in it

maybe you could add additional events to groups that can work on multiple families

https://www.google.com/#q=define:+gang

newt are you saying we should call it gang instead of groups ? then i agree, its indeed all thesame rapped into another name, but naming things is a big part of programming dont you know that

what can a gang do that a family can't, thinking on that one

Well you can be a member of several gangs.

I would say that can be a bit dangerous however.

i were still talking about construct, then you can be a member of multiple families too

maybe, two families are members of the west side "group/gang" and are moving both to eastside, while one family has guns and the other on has bats

or one is with cars and the other one on foot but both go in the same direction

Yeah, but once you're in a family you're always in.

Not so much with a gang, unless its the mob...

in the end you will realise that everthing in this world works as a parent - child relation, thats why we need an objectstructure, and this is simular as a family in family

sqiddster - families in families is the same as simply adding both families to one object type, so I don't think there needs to be a new feature for that. I'm not sure families with different plugin types is even possible, because the whole point of families is so you can write your events once. If you go to add an action for a family with both the Sprite and AJAX plugins in it, which actions do you show? What if you run an AJAX action on a Sprite instance or vice versa? etc...

As for the other use cases, I think the complexity problems I outlined with layer offsets means that it would be better to find a different way of solving those problems, without having to offset layers.

From a usability standpoint, allowing families in families is very different than saying one object can be in multiple families. Saying it's the same is like saying having families at all isn't needed because you can just copy and paste events for different objects. It makes maintenance so much easier.

As for your argument about Sprite and AJAX, obviously that would be totally useless. However when it comes to objects like Sprites, tiled backgrounds, text, etc, there are a LOT of common elements, and for something like a manual layer offset it would be very useful to be able to talk about all those objects at once. The sub-families feature also shows relevance too because I'm not going to want to manually add all the objects that could exist on that layer to this family manually.

fldr - between something like AJAX and Sprite, I think that is pretty much no actions at all, making the family pretty useless!

yeah, the Ajax object isnt the best matching candidate for what i descriped, but who knows what people want to build? i wouldnt worry and just let the users choose what they put into the family, if they put something in like the Ajax object it would be their own fault that they dont have many actions left to choose from, but personally i would love to mix sprites, tiledbackgrounds, 9-patch, spritefont etc. because what these things all have in common is x, y, visibility, width, height... and so on (and i think this is a more appropriate example then the Ajax object).

fldr - between something like AJAX and Sprite, I think that is pretty much no actions at all, making the family pretty useless!

Sprites vs Spritefonts vs Texts ...

X,Y, Scaling, Angle, Opacity

Use cases, sliding menus ...