Scale Behavior

You might want to have a tick for use current height/ width, or use original height/ width.

Like it or not when you scale up things will get blurry at some point. You can deal with this by making the original a few sizes to big, and then scaling it down in the editor.

Perhaps a Loop setting, for pulsing things.

But the sine behavior already does this really well?

You might want to have a tick for use current height/ width, or use original height/ width.

I'd say that's starting to look like feature luggage (as a user you already set the size so you probably want it at that size and then scaled in proportion to that size) - it'd be nice to have it real clean and tight, just like the Fade behavior (yeah, I like it ). But then again it's all up to linkman right now. And any version would be great anyway.

> Perhaps a Loop setting, for pulsing things.

>

But the sine behavior already does this really well?

Yes sine works quite well, in fact you can use it to do all you've suggested by just comparing a dimension.

You might want to have a tick for use current height/ width, or use original height/ width.

I'd say that's starting to look like feature luggage (as a user you already set the size so you probably want it at that size and then scaled in proportion to that size) - it'd be nice to have it real clean and tight, just like the Fade behavior (yeah, I like it ). But then again it's all up to linkman right now. And any version would be great anyway.

Why would you want a behavior, that cant do what events can with just a few lines?

Why would you want a behavior, that cant do what events can with just a few lines?

Few lines PER OBJECT... When you have dozens of unique objects you might want to use this with that adds up. When you want to change the scale speed - that adds up again. Want to try something different - more work.

The idea behind construct is to make people do LESS coding, so why not like this? Simple, quick, easy. Want to do more - you can. Don't want to - don't have to.

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

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 (http://dl.dropbox.com/u/1328856/DT.zip) 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.

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.

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 (http://dl.dropbox.com/u/1328856/DT.zip) 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.

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?"

> Perhaps a Loop setting, for pulsing things.

>

But the sine behavior already does this really well?

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.

look what exactly are you trying to do here thats so difficult that you need a behaviour?

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>

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?"

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>

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

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

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.

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.

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.

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.

it just seems like your overcomplicated things to far here.

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.

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.

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.

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.

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?

(...)What I don't get is this strong opposition.

Developer time 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?

Developer time I'd rather have them focus on 1.0

It's not like I'm helping develop Construct.

I've made some headway on this today. If all goes well, I should be able to release a beta tonight, tomorrow at the latest.