feature request: layer offset

Nobody has provided any actual use case so I'm not persuaded at all yet. What kind of actual games or features would this make possible that you can't already easily do?

This kind of feature can have significant code complexity implications and possibly significant performance implications too: the collision cells and render cells optimisations are strongly dependent on the predictability of the positions of objects. Layer parallax forces the collision cells optimisation to be disabled since cells no longer line up correctly. I think a layer offset feature would have the same effect. Usually parallax is just for decorative purposes so it's not important if collision cells get disabled. However with layer offsets I can imagine that you simply offset your main layer by 1px for some reason or other, and then it completely tanks the collision performance because collision cells no longer line up and it reverts to brute forcing collisions.

So I'd need a pretty darn compelling reason to implement this feature which exceeds the complexity and performance implications, and so far it's just a thread of "+1 sounds interesting". So right now I'm thinking "no way this is worth it".

Ashley: From reading the first page, I have a feeling what people actually want is an offset (X/Y position) of the parallax layer instead of a percentile value set in the layer's properties. The parallax percentile value can already be modified "on the fly" at runtime, possibly ppl want to set exactly a pixel amount of offset.

That's my understanding of posts in the first page though.

I could imagine quite some use cases with isometric related games and height differences.

Ashley , the first think that came to my mind when I saw this post was earthquakes! Moving all Sprites on a layer together interdependently from Sprites that live on other layers can have great potential I think. Also, linking layer positions to sine behaviors could create very interesting movements. What Kyatric wrote is also true, the way parallax works now is weird, it doesn't allow for accurate control, everything "shifts" from to 0,0 coordinates and many times I find my self wishing for the offset to happen from the actual scrollx, scrolly positions (relative post here).

It is a suggestion that has nothing more or nothing less that what I said, potential.

What we really need is a more robust Families system so that this can be done trivially in events.

lennaert - can you actually describe in detail what they are and how they work? I still don't know any valid reason that the feature is necessary.

eli0s - doesn't normal scrolling cover that, like the Scroll To behavior's 'Shake' action?

sqiddster - what needs to be more robust about the Families system precisely?

Ashley , the "Shake" action, or anything that moves the scrollx,y position, will affect all layers in the same way (taking into account any parallax offset). On the other hand, moving layers individually would allow for example one layer( and all of its Sprites) to move in one direction and an other layer (again with all of its Sprites) to move in an other direction. This will create a very "earthquaky" shake, especially when parallax offset exist between foreground and background layers. And that's only one example. I think that having control over the layer's position (as we can do already with it's angle) can provide some cool opportunities, however, I don't think it's something essential or that it will elevate C2's (or C3's) workflow to a new level.

I would much rather see a proper masking system, or a 2.5d camera/world positioning system, that will make a difference to me!

I agree with eli0s - this would be a nice to have but it's not worth postponing many other features and updates for. Uses: any moving background like the sea, clouds etc.

lennaert - can you actually describe in detail what they are and how they work? I still don't know any valid reason that the feature is necessary.

When you take the isometric concepts into consideration, there generally is an "offset" differing the height in terrain level pieces.

This same concept is used with the playerbase object / animation object.

Using these together will make (semi) isometric game creation simpler.

Instead of having to do various calculations to determine the offset, you could simply move/lerp the players/playerbase 'off set' toward the offset of the layer the player moves to.

But there are far more 'nice' usages for this ...

Just imagine having 2 layers, big ring at the bottom layer, small ring at the top layer. You can see the big ring through the little rings inside.

Then play with the offset at run time and it could 'fake' a 3d feeling as the off set moves the entire top layer in a circular motion over the bottom layer.

You could have plane shifts, parts of the level move-able.

Or imagine a inner space level, with various layers determining certain 'height' in the galaxy, and as you move your ships, the levels above and below shift gradually.

Or imagine being in an elevator, and the floors below and above gradually pass you by using the offset.

Atm, there are other approaches in which you can all reach the similar results, but it would require more calculations and more events to address everything. In contrast where you could manipulate just one layer.

Some of the above suggestions would assume there is an expression to get the current layer off set.

I

Ashley -

My use case would be as follows: There would be a group of layers that the main game, bg etc are on. Then there would be a group of layers controlled via offsets. Nothing in either groups interact via collisions. As a matter of fact, they each run their own collisions. It's like two different worlds, where one can be seen behind the other, but they have little actual interaction most of the time. I actually run my own collision algorithms at this point... The current system is very... how to put it... single minded? The testing of the overlaps is great and all, but as there are no filters it really only works in a one world sort of way... and the solid attribute is worthless in a context where more than one thing is solid, but only to some things, but in different ways, all simultaneously ... Anyway, I made my own.

Long story short, the world behind the world is like the inside of a ball, as you move about on one side, the other side moves in the opposite direction, but I also need it to move independently. Also, I don't see why the layer couldn't simply have its collisions detected as is, regardless of offset. If the objects in a layer group only interacted with each other, the group needn't brute force the collision detections. I feel like there should be an option to move a layer around and keep collision detection normal to the layer. That way I can have a background layer with objects interacting within the layer and yet still be visually independent of of the main game layer. I don't know if this all makes sense or not.

Ashley the main issues holding back Families at the moment are 1. No families in families, and 2. no families of multiple plugin types. I assume either of these would require fairly hefty architectural changes so it's definitely a C3 feature but for large games it really would be a game changer.

The biggest issue with plain layer offsets is parallax won't work with them.

It may have to be parallax, or offset for all layers, not both, and probably not alternating either.

The biggest issue with plain layer offsets is parallax won't work with them.

It may have to be parallax, or offset for all layers, not both, and probably not alternating either.

That's not true, they can work together. Imagine that the offset is an independent parameter that maps to the amount that the layer offsets from the scroll position, like: "layerPosition = layerScrollPosition + layerOffset". One can then have the layers move with scroll plus control the layer offset, or can alternatively set the scroll rate to 0 and move only with the offset without being affected by scroll.

The only thing is that the offsets need to be taken into consideration for the collision cells like Ashley mentioned. Apart from that it seems quite trivial to implement.

I felt the need for this feature sometimes in the past. Although it's not something I'm really in need for C2 right now, I really wish to see this in C3 as it would be very handy.

A layer with an offset as well as a percent offset seems like it would be a bit much to keep track of what with the expectation of expressions for those offsets to use with other layers.

Then layer rotations would further complicate things.

newt - complexity isn't a bad thing. It's the game makers job to manage complexity in an organized and efficient manner in order to mitigate the risks of making mistakes, getting confused etc... Complexity is often a necessity in doing something innovative in games, as there are now prior guidelines for how something should be done. Collision detection is a topic to fill hundreds of books and consume the waking hours of many professional programers. It can be simple or it can be 50,000+ lines of advanced code, both in the computer science sense and the mathematical sense.

None the less, in construct we have access to several forms of collision detection and two forms of collision resolution. All can implemented with a few clicks. But each of those clicks has a mind boggling amount of complexity behind it.

One offset with another percent offset isn't really that complex (A+B). Also, I'm glad you brought up rotation... you know that layers can be rotated independently, so why can't layers be moved independent of each other? Being able to rotate a layer but not move it is like having a car that has a clutch and gas but no steering wheel.