Scale Behavior

New releases and general discussions.

Post » Sun Feb 21, 2010 7:16 pm

Have you used families yet?
True Construct can do things quite well from an object oriented point of view, but it can be even easier from an event orientation.

>family.value = 5
>--family set height to lerp(family.height, 200, 1-0.5^timedelta)
>--family set widthto lerp(family.width, 200, 1-0.5^timedelta)

>family.height = 200
>--family destroy
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Sun Feb 21, 2010 7:22 pm

Yes I have, but let's have an example - in my little shmup a scale effect might be used for the following things - impact sparks, powerups, damaged enemy ships, active enemy ships, explosion parts, background items and something more I quite possibly haven't thought up yet. Each of those may have several sub categories which require different scaling, etc.

So how many families was that already?

It's not that I don't know how to use it - the little example showed that it can work just fine ([url:1qy77a8w]http://dl.dropbox.com/u/1328856/DT.zip[/url:1qy77a8w]) with events alone, but it's NOT easy and straightforward. Which is always a plus :)

Following the same logic - why are there a Rotate or Fade behaviors - easy to do with events as well. But so much faster to just throw them in.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Sun Feb 21, 2010 8:21 pm

look what exactly are you trying to do here thats so difficult that you need a behaviour?
you can just do .width+1 or some arbitrary variable like .width+.width/10 or something.

i dont understand the need for it besides cosine interpolating things for a smooth ease in and out, which is a pretty rare case anyways, but youre making this way too complicated.
B
52
S
7
G
6
Posts: 1,945
Reputation: 7,610

Post » Sun Feb 21, 2010 8:36 pm

[quote="Somebody":1yo2a07i]Yes I have, but let's have an example - in my little shmup a scale effect might be used for the following things - impact sparks, powerups, damaged enemy ships, active enemy ships, explosion parts, background items and something more I quite possibly haven't thought up yet. Each of those may have several sub categories which require different scaling, etc.

So how many families was that already?

It's not that I don't know how to use it - the little example showed that it can work just fine ([url:1yo2a07i]http://dl.dropbox.com/u/1328856/DT.zip[/url:1yo2a07i]) with events alone, but it's NOT easy and straightforward. Which is always a plus :)

Following the same logic - why are there a Rotate or Fade behaviors - easy to do with events as well. But so much faster to just throw them in.[/quote:1yo2a07i]

You really dont need bunch of families, you can give each object as many private variables as you need.

Also alot of users wont use rotate, or fade because they are so limited.
plus fade, is.. well not that intuitive... "do I start the fade, or do I set it activated?"
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Sun Feb 21, 2010 9:31 pm

[quote="Somebody":31ghvu5j][quote="deadeye":31ghvu5j]Perhaps a Loop setting, for pulsing things.[/quote:31ghvu5j]

But the sine behavior already does this really well?[/quote:31ghvu5j]

So? It's a scaley type scale thing, so why not? It would save having to add a Sine behavior.

Oh, and different loop types would be nice. Like ping-pong, ramp up, ramp down.

And also a linear scaling vs ease in/out option. I mean, if you're going to make a plugin for scaling you might as well go hog wild with features so that it's actually useful to a wider number of people.

[quote="QuaziGNRLnose":31ghvu5j]look what exactly are you trying to do here thats so difficult that you need a behaviour?[/quote:31ghvu5j]

We're past that now. It's going to be made so you may as well embrace it. At this point it's about finding functionality that would justify it's existence.

<rant>

[quote="newt":31ghvu5j]Also alot of users wont use rotate, or fade because they are so limited. plus fade, is.. well not that intuitive... "do I start the fade, or do I set it activated?"[/quote:31ghvu5j]

Ugh, tell me about it. I made some fading objects in my tut recently with just one line of code for opacity. Took me about ten seconds and it worked the first time, but it used TimeDelta... which means I have to write a whole long description of TimeDelta for my tuts. So Ash says "why not just use behaviors and avoid TimeDelta?" So I tried the Fade behavior. I'd never used it before. It took me like an hour to figure out what that thing was doing. It seriously needs a revamp.

</rant>
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Mon Feb 22, 2010 7:22 am

[quote="deadeye":6lu1jeeh]Oh, and different loop types would be nice. Like ping-pong, ramp up, ramp down.[/quote:6lu1jeeh]

Ah, now this actually sounds different from Sine and pretty decent. Could have some nice effects with that.

[quote="deadeye":6lu1jeeh]We're past that now. It's going to be made so you may as well embrace it. At this point it's about finding functionality that would justify it's existence.[/quote:6lu1jeeh]

Yeah, this is kinda weird - saying over and over how it can be done with events, private variables, etc. Maybe I'm lazy or maybe I just want to, you know, design stuff, but adding variables to everything, adding extra events, changing that stuff to check minor details - doesn't sound all that fun.

If someone doesn't like the idea of a behavior - well, don't use it - use events and everyone's happy.

Never had any problems with Fade, though and it's used A LOT here.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Mon Feb 22, 2010 11:12 pm

im not against the creation of a behaviour but it just seems like your overcomplicated things to far here. the thing is you dont need any variables, or behaviors or anything like that. its just as much work setting it up as it is finding ADD behavior in sprite properties.

all your doing here is set width to ".width+10" set height to "(.originalheight)*(.width)/(.originalwidth)" the brackets aren't even needed, and the .height part could just be set height to ".width" if you have a square graphic, which is pretty easy to do for an explosion or something like that.

that would take me all but 2 seconds to set up, and it took me 2 seconds to figure out aswell. Im not against making things easy but i absolutely cant stand it when people use that as an excuse for not thinking for themselves in really easy places. you don't want people to constantly be helping you with things, and be pinned down by the behaviors that construct supplies you with. your just cookiecutterizing things for yourself. and in this case a behavior isn't as useful as your making it out to be anyways, linear scaling is sooo easy to do, it takes 2 actions.
B
52
S
7
G
6
Posts: 1,945
Reputation: 7,610

Post » Mon Feb 22, 2010 11:39 pm

I don't think it's too bad an idea. It's more about convenience and simplicity. Sure the events are dead easy, but in many cases it's just convenient, especially if you're already several subevents deep and need to trigger a scale - having some extra calculations there, or setting some kind of flag to start off a scale, would harm readability. The Fade behavior is a good example - it's trivial to set up in events, but if you use a lot of fades, having the behavior is handy. You can set it up from the layout editor/object properties, it triggers events for you like On Fade Finished, and takes care of timedelta for you too.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Tue Feb 23, 2010 7:10 am

[quote="QuaziGNRLnose":1rcavhs4]it just seems like your overcomplicated things to far here.[/quote:1rcavhs4]
My overcomplicated things to far? *puzzled expression*

Ok, grammar naziing aside - the idea is to simplify things. At least for people who don't feel like using events for EVERYTHING just because they can.

[quote="QuaziGNRLnose":1rcavhs4]that would take me all but 2 seconds to set up, and it took me 2 seconds to figure out aswell. Im not against making things easy but i absolutely cant stand it when people use that as an excuse for not thinking for themselves in really easy places. you don't want people to constantly be helping you with things, and be pinned down by the behaviors that construct supplies you with. your just cookiecutterizing things for yourself. and in this case a behavior isn't as useful as your making it out to be anyways, linear scaling is sooo easy to do, it takes 2 actions.[/quote:1rcavhs4]

I believe if you had taken a look at the example I posted earlier - which was made using only events with timedelta, etc. - you'd understand that I CAN *surprise* figure it out just fine, it just gets in the way when it's a small part of something bigger.

Perhaps to you an explosion is just a single or a couple of sprites being scaled up. And you make it, adjust that value 2 or 3 times and are happy with it. Me, I'm an explosion freak, for example - they have several elements, working together to produce the desired effect. I'd prefer not to jump into events every time there's a need to tweak something. Use a behavior, set the size, test, adjust, done.

I mean if coding was the focus here might as well go straight for a programming language - there's plenty to go around, even for games, these days.

[quote="Ashley":1rcavhs4]I don't think it's too bad an idea. It's more about convenience and simplicity. Sure the events are dead easy, but in many cases it's just convenient, especially if you're already several subevents deep and need to trigger a scale - having some extra calculations there, or setting some kind of flag to start off a scale, would harm readability. The Fade behavior is a good example - it's trivial to set up in events, but if you use a lot of fades, having the behavior is handy. You can set it up from the layout editor/object properties, it triggers events for you like On Fade Finished, and takes care of timedelta for you too.[/quote:1rcavhs4]

Exactly! The boss has spoken.

What I don't get is this strong opposition. There's basic events for most things in Construct except for scale so far: Fade, Rotation, Bullet Movement - all very simple as well - will someone want to throw them out next?
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Tue Feb 23, 2010 6:38 pm

[quote="Somebody":2ahq2brg](...)What I don't get is this strong opposition.[/quote:2ahq2brg]

Developer time :P I'd rather have them focus on 1.0

That said, I guess this could be useful as fade is (when it's not getting weird).
So, BRIEFLY (sans wall-of-text), what would this behavior do?
Resize over time, I'm guessing, but... forever? oscillating?
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 4 guests