Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complex objects from several primitive objects #572

Open
zilluss opened this issue Nov 30, 2013 · 7 comments
Open

Complex objects from several primitive objects #572

zilluss opened this issue Nov 30, 2013 · 7 comments
Labels
feature It's a feature, not a bug.

Comments

@zilluss
Copy link

zilluss commented Nov 30, 2013

It would be useful to select multiple objects and declare them as a group or complex object. A complex object can be copied as a whole.
For example if you have an enemy that consists of several body parts you can place the parts, select them all and group them together. Another example is a platform that is grouped with a polyline, which the platform is supposed to follow.

You can currently solve the problem with custom properties, but this is a tedious work, not only in the editor but also when you create and group the objects in your game.

@bjorn
Copy link
Member

bjorn commented Nov 30, 2013

Yeah. Actually, I think the map format should be hierarchical rather than being only 2 levels deep, and definitely moving around an entire sub-hierarchy should be possible. The trick is only in finding time to implement it...

@EdenIndustries
Copy link

I'm not sure if this request belongs here, or in a new feature request, but in the absense of (or in additon to) being able to create a complex object out of several other objects it would be useful to copy an entire Object Layer (or multiple layers ideally!) and paste it in a level (ideally supporting pasting it into a destination level that is different from the source level). This would sort of eliminate the need for a complex object, since you could build it as an Object Layer, though complex objects would also be cool!

@bjorn
Copy link
Member

bjorn commented Dec 4, 2015

@EdenIndustries You can press Ctrl+A to select all objects on the current layer and then copy/paste them onto an object layer of a different map. But I guess you mean copying the actual layer and adding that layer on paste. It's an interesting request, but maybe you should indeed open a new feature request for this.

@EdenIndustries
Copy link

@bjorn Gotcha, I'll open a new feature request, thanks!

@bjorn
Copy link
Member

bjorn commented Oct 18, 2017

Actually, I think the map format should be hierarchical rather than being only 2 levels deep, and definitely moving around an entire sub-hierarchy should be possible.

Since this came up in issue #1787, I have to take back what I said here. I'm no longer convinced we really need such a feature. For connecting a platform to a polyline, a better solution would be to allow connecting objects (#707). And for entities consisting of several parts, I think there are also better ways to represent them (like moving to an entity-component system, where multiple sprite components can be added to the same entity, or even defining the sprite in a different application like Spriter or Spine).

@bjorn bjorn added the feature It's a feature, not a bug. label Oct 18, 2017
@eXponenta
Copy link

eXponenta commented Feb 5, 2020

Yeah. Actually, I think the map format should be hierarchical rather than being only 2 levels deep, and definitely moving around an entire sub-hierarchy should be possible. The trick is only in finding time to implement it...

I was implement 'simple' hierarchy mechanism in pixi-tiled importer: i save parent layer/object name in property and reparent it when parsing.
It works but not very convenient in editor.
This way can be implemented without major changing of file format. Editor can add specific field same as parentId and export it as Flat array.

@bjorn
Copy link
Member

bjorn commented Feb 5, 2020

@eXponenta Right, and since recently you could use the "object" type for custom properties to refer to parent objects, and since yesterday those parent references will also render as arrows, making it clear which items belongs to which other item. Those features will be in Tiled 1.4.

Regarding the file format, when we would support grouping objects in the editor I would still prefer to nest children when saving. When implementing it as just a reference to another object, the question is what to do with the x/y coordinates and rotation. Since presumably the file format changes are kept minimal to avoid breaking compatibility, should the x/y/rotation properties be saved independently of the parent? And then on loading, these values would adjust to be within the parent transformation again? Personally I think I'd prefer for the loaders to be changed to support this explicitly.

Of course, it's another thing if you're arguing for parent reference instead of nesting because you think it's a better approach. A relational database for example stores each type in a huge list and relies on references to other objects to store any more complicated structure. In the end I think the nested approach is more readable to humans so am leaning towards that.

Regarding what I've written in 2017 about entities / components, that's a possibility but when an entity could have children I guess they should still inherit the transformation. If entities should be related but not inherit the transformation, it's a different kind of relationship that's now best expressed with a custom object property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature It's a feature, not a bug.
Projects
None yet
Development

No branches or pull requests

3 participants