I was joking too! Read my joke, it's a funny joke! I thought so anyway

You are correct. It does not resize the canvas. It appears to resize the contents of the canvas instead.

I don't think we should change the name to Builder. I did a google search for "Builder" and there was not one mention of Construct in the whole list!

Ah, your demo .exe works as advertised. Not bad, though the sword swinging seems a little slow to me. Don't know how you're going to translate that into sprites, either. Could be a bit tricky.

Anyway, it seems to be coming along so kudos

On a side note, deadeye, just for my clarification, when you said aSprite and bSprite, did you think I had the same sprite as two seperate objects? If so, that was my mistake of clarification. I have a single sprite object placed randomly on the screen, multiple times using a Loop proceedure.

Nah, that wasn't your fault. It was my fault for reading it wrong.

Happens a lot, I'm always answering the wrong questions

Timedelta is the number of seconds between ticks. It's a very low number. The number changes slightly from tick to tick because processing speed may vary.

Anyway, if your fps is 60 and you say "subtract 60*timedelta" to something, it will average out to subtracting 1 every second. So in that timer example I posted, you set the timer to 2, and subtract 60*timedelta, that means the timer will run out in two seconds.

If instead you told Construct to "Always -> subtract 1 from timer" then on very fast computers the timer would be shorter than two seconds, and on very slow computers it could be longer than two seconds. Timedelta makes sure it's the same on all computers.

But yes, mostly it's used for moving things around to make sure stuff runs at the same speed on all computers. All the built-in behaviors use timedelta automatically.

.cap file is blank

No it's not... try opening the Level1 layout

Anyway, the problem is you're trying to use physics collisions, but you're not telling the player to move using physics movement. You're telling the player to move using set pixel amounts. Physics doesn't work that way.

If you are using physics, you can only tell physics objects to move using force or acceleration in the physics tab of the actions for the object. You can only tell the physics object to rotate using torque or angular velocity.

You cannot tell a physics object to "rotate n degrees" or "move n pixels." You're doing it wrong.

Basically it works like this: The Physics behavior is a simulation. It runs all the collisions in the behavior itself. It's a totally separate thing from 8Direction or Platform interacting with solid objects. Physics doesn't care if an object is checked "Solid."

Physics objects only collide with other physics objects, period.

If you want physics objects to collide then you need the physics engine to do the work for you. If you tell the sprite to "move n pixels" then it totally skips the physics engine and move the pixels like you asked. But the physics engine doesn't know you just move the sprite. It doesn't know you just intersected with a solid. Moving those pixels is not part of it's simulation. The physics engine still thinks the sprite is sleeping away perfectly still where it started off.

Anyway, long story short: Physics and regular pixel movement (including other behaviors) don't mix. Physics only works with physics.

You know what I just remembered? The Bitmap Font object in MMF had a font creator built into the object. You could pick from the list of fonts installed on your system, change the color, size, add some simple effects like drop shadow or outline, italics, or whatever, and it would rasterize the font for you. (Or you could load one up from a sheet as well, I think.) For simple fonts that might be a way to go, yeah?

Or... I know David's unfinished Tile Map object let you load a tile sheet, and you could tell it what grid size the tiles were, and then place tiles in the layout by selecting them. Perhaps the spritefont object could use the same kind of sheet-loading system? And maybe there could be a standard for importing sheets, like all the letters, numbers, and symbols are in the same relative position, and you just have to plug in what the grid size is for your sheet. That way you could even include a template that people could resize to fit their font and they could place the letters on the grid and save the image in Photoshop or GiMP or whatever to import.

I dunno, just a thought. I'm sure it's already way to complicated without having to think about that kind of stuff . And I'm about to go to bed so I'm all groggy and I'm rambling, sorry...

Wellokayfine you have a good point about the counter object

Path movement should be a plugin or behavior, not necessarily just for sprites. It has been requested a few times. Would be nice to have.

Counters can be made with anything by adding and subtracting private variables. It is totally not necessary to have a separate counter object.

Gamepad support is a big thing. Currently there is none except for XBOX360 controllers. It's been requested a lot, and hopefully someone will make a plugin before 1.0.

Hiscore object? Why? What would it do that you can't already do with Construct? You could store your own high score info in a file with encryption if you wanted. You don't need a separate object for that either.

Okay then, I did misunderstand. I read over the OP three times and somehow still missed that he was colliding instances of the same object with each other.

Yes, the family trick will work just fine for this.

I don't think you would need bones, and I don't think that sprite is going to have too much effect on VRAM.

What is confusing is what it's doing. I have no idea how that thing is supposed to move or attack.

What you should do, if you know how it should move, is separate the frames into their own animations. That's the first step.

Second, create a timer to control when it switches from moving to attacking. Or for when it switches from attack 1 to attack 2, etc.

Third, when the enemy is activated (like, when it's on the screen) start the timer. When the timer counts down, switch modes.

When one mode is active (you can use a "mode" variable for this) then perform only the actions that it should be performing.

Something like so:

+ Scorpion is On Screen (or whatever)
+ Trigger Once
    -> Scorpion: Value('active') to 1
    -> Scorpion: Set Value(myTimer') to 2

+ For Each Scorpion
+ Scorpion.Value('active') = 1
    + Scorpion.Value('myTimer') > 0
        -> Subtract 60*timedelta from Scorpion.Value('myTimer')

        + Scorpion.Value('myTimer') <= 0
            -> Scorpion: Set Value ('mode') to random(3)
            -> Scorpion: Set Value ('myTimer') to 2

    + Scorpion.Value('mode') = 0
        -> Do movement actions

    + Scorpion.Value('mode') = 1
        -> Do attack 1 actions

    + Scorpion.Value('mode') = 2
        -> Do attack 2 actions
[/code:12mit8ay]

Obviously this is just the theory part of it, you will need to fill in the blanks.  But something like this will make it so that every 2 seconds the scorpion will pick a random "mode" and then you can use that mode variable to control what it's doing, whether it's moving, shooting a bullet, playing the proper animation, or whatever.

This single "mode" setting is what's known as a state machine.  You basically boil down everything that the enemy can do into separate chunks, and pick one state, or "mode," at a time to control which chunks are being processed at that moment.  This is a very simple version of a state machine, they can get rather complex, but they do make things a lot easier when doing things like AI and controls and animation.

Also, you don't necessarily have to use a timer, like I showed.  You can set the state based on whatever you like, such as an animation finishing.