feature request: layer offset

Discussion and feedback on Construct 2

Post » Fri May 29, 2015 1:32 pm

@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?
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,454

Post » Fri May 29, 2015 2:00 pm

@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! ;)
composer - multimedia artist
www.eli0s.com/en/
B
68
S
26
G
4
Posts: 1,146
Reputation: 9,649

Post » Fri May 29, 2015 3:23 pm

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.
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
73
S
19
G
66
Posts: 2,198
Reputation: 42,193

Post » Fri May 29, 2015 4:51 pm

@Ashley wrote: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
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,562

Post » Fri May 29, 2015 5:37 pm

@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.
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Sat May 30, 2015 3:14 am

@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.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,679

Post » Sat May 30, 2015 3:50 am

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.
Image ImageImage
B
168
S
50
G
164
Posts: 8,236
Reputation: 105,591

Post » Sat May 30, 2015 10:17 pm

newt wrote: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.
Scirra Employee
B
149
S
53
G
17
Posts: 711
Reputation: 17,725

Post » Sat May 30, 2015 10:25 pm

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.
Image ImageImage
B
168
S
50
G
164
Posts: 8,236
Reputation: 105,591

Post » Sun May 31, 2015 12:10 am

@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.
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests