Two things I can say - you sure you want the tank to move at all angles? If it was limited like the player to basically 90 degree increments it would be easier to make a simple movement solution (Hit wall - turn 90 degrees - hit again - turn -90 degrees, hit again - turn 90 degrees, etc And each 5 or so iterations turn 90, 90 just so it doesn't get stuck too much). Then it could have a simple automated patrol route and just set the direction to closest 90 degrees to the player.

Well, something like that. It'd also be oldschool

Also - there's a nice command for distance between two points in Construct so you don't need the big white sprite as a detector.

I really like how everything's nicely separated into Event Sheets, though.

When that window comes up there's a link to options and in there there's an option to turn them off.

I'd give more exact instructions, but on Windows 7 here, it's not an issue.

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?

Nice, .83 doesn't crash every time on exit like the previous ones did.

However - there's a pretty weird bug where when you select an action in the event list a whole other event will randomly get selected and that action will be unavailable. Looks like it's pretty random - just clicked 3 times and then it happened and then 16 more and it happened again.

Seems to happen when there are groups under groups, will see if a plain buggy cap can be made.

You have plenty of frames of animation for that shield effect - you might just make it a separate animation call it "impact" or something and then set your collision event to start that animation. Then add another event for Animation over and set it back to the normal one. Hopefully that made some sense

so why cant construct?

You know, probably because it uses DirectX and has hardware accelerated graphics? On a basic level it's just not too likely and would be pretty limited even if they would manage to (waste A LOT of time) and code such an export thing.

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.

Yup, pure white screen here as well. I had that once when a canvas object was acting weird or a layer has some FX and needs to have "Force own texture" enabled.

Heh, quite the game indeed

(Also can someone point me to a tutorial on how to get soundfiles actually embedded in the .exe? Because I've seen it done and this 'separate folder for sounds' -stuff is a bit cumbersome.)

Go to Project tab and add the sounds to the Files folder - they will be stored inside your project just like the graphics. Then use Play Resource.

There are also Music and Sounds folders there, but those apparently don't work yet.

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.

Besides 3D games already have several high-end engines, the development resources required for a decent modern result are massive and I suspect there's less people with the necessary skillset in the user base of such a "Friendly" tool like construct.

I think it's great that Construct is focusing on an awesome development platform for 2D while employing hardware acceleration and shaders. There's still plenty to improve as well, apart from adding 3D stuff.

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.