I never thought collisions were also based on overlapping. I thought that if I'm hitting a wall it was because it detected a collision.There are only two (but important) differences between "on collision" and "is overlapping".

• "On collison" only triggers once, no matter how long the objects collide, while "is overlapping" is true as long as they overlap.

• Different picking behavior.

Thank you :)

I'll test again in August then. Now with at least some way to export to .exe, C2 gets more interesting to me. That's my motivation for asking and hoping it will work reliably. <img src="smileys/smiley9.gif" border="0" align="middle" />

Sorry for bumping Ashley, but I think it's worth to look at. I don't mind if it isn't meant to work on WinXP, I'd just like to know.

This plugin also doesn't help me with my idea. I hoped for a plugin that not only manages a deck, but several decks plus the stack. Also the card's type may be the same, but its strength may vary. For example, the card "mighty warlock" may exist with an attack of 10 or 12. Both cards would have the same ID, but a different tag. Giving every variant of "mighty warlock" a different ID would break the real existing number of cards.

Would it be possible to enhance the plugin in such a way?

I tried your cap and it doesn't run the collision event. It did trigger in my setup, so I thought about it and this is what I've come up with.

If an object has the solid attribute than the platform object will never collide with it but stop right before the collision.

That's why it worked with the mouse behavior, I simply moved the solid object across that invisible border and the collision took place.

I'm not sure, how exactly you want your platformer to behave, but if it is simply a matter of "solid if floor, destroyable if ceiling", you could, for example, use this event in your example cap:

+ Sprite2: overlaps Sprite : offset (0,-1)

-> Sprite: Destroy

This will destroy the sprite only if Sprite2 overlaps with 1 pixel offset above (1 pixel offset is exactly what is missing, when the platform behavior stops the sprite because of a "solid" obstacle)

EDIT: *sigh* why is ROJO always beating me to it <img src="smileys/smiley36.gif" border="0" align="middle" />

Have you tried this in a fresh cap? I made a new project, added 2 sprites and one panel, set all 3 to solid, gave sprite 1 the platform behavior, panel placed below to stop sprite 1 from falling, and gave sprite 2 the mouse behavior.

+ Sprite: On collision between Sprite and Sprite2

-> Sprite2: Destroy

Worked. So I guess there must be something else that interferes with that event.

The actual SDK is of version 0.99.3, compatible with R2, and you find it in the "Construct engineering" forum: http://www.scirra.com/forum/plugin-sdk-0993_topic37692.html

Neat video! I wish my eventing/whatevering would yield instant results :-P

But at least that's how music composition generally works for me.

That's interesting. It is exactly my experience too. Maybe because music composition already has that direct media connection? We instantly hear what we are playing, or how it affects the music if we change a note, a chord, an effect, etc.

Game design should feel the same.

I often read about complaints from non-programmers about the arrays in Construct. They said "I can't see them." And I didn't understand what they meant. Until I saw this video and its part about binary search. It's the same algoritm, that I use in "Verve!" for Construct's arrays. But all my comments in the events can't explain the functionality nearly as obvious than Bret's visual representation. This must have been what the people meant by "seeing the array".

But there's a downside. Making an editor with instant media connection would always be a solution to specific demands or else will be bloated with dozens of tools and functions you probably never need.

One side-note: I think, Bret's principle is exactly what people find so attractive about Spriter. It is following exactly this principle. You instantly see what you are doing and how changes affect it. I'm sure, there are other examples from fellow Scirrans out there.

I really mean the title. This evening a friend of mine send me a link in Skype. It was a short video on YouTube. At first I wasn't very impressed, but soon enough it got me. I started online searches and finally found the origin of the short video. It was a one hour talk of Bret Victor on "Inventing on Principles"

I know that not everyone will have the patience, but I really, really recommend to watch the whole thing. It is not just about programming or game design, but about being creative using the computer in a way that feels much more natural than current usage.

Those of you who don't want to watch the whole thing, watch at least the first 23 Minutes and from 29:20 to 34:00. I promise it will feel like seconds.

Now that you have watched it, let me tell you that it already influenced some game creators. For example,

.

I'm really excited, as you can tell.

Any thoughts?

I've been addicted to a special idea of a collectable card game, but never made progress. I just downloaded your plugin in the hope it might make a lot of things easier. <img src="smileys/smiley1.gif" border="0" align="middle" />

You don't need to excuse a question you had. That's what the help section is for. <img src="smileys/smiley1.gif" border="0" align="middle" />

Hmm, there are many ways to let something rotate. You should use the method that is most suitable. Most of them can (and should) be combined with TimeDelta to enable rotation over time. If you prefer rotation over ticks, that's possible as well.

First, let's have a look at your proposed RotateAngle(start, end, step). It will rotate the object to step'th-angle between start and end.

For example:

RotateAngle(10, 20, 5) will set the angle to 15

RotateAngle(30, 60, 12) will set the angle to 42

RotateAngle(90, 50, 8) will set the angle to 82

To let it rotate over time, combine it with a variable that you raise with TimeDelta on every tick.

+ Sprite: Angle Less than 90

-> System: Add 90 * TimeDelta to global variable 'myStep'

-> Sprite: Set angle to RotateAngle(0, 90, global('myStep'))

This event will let Sprite rotate from 0? to 90? within 1 second (90 * TimeDelta means 90 per second)

For Sprites, there are also specific expressions for rotation. Rotate clockwise and rotate counter-clockwise will start at the current angle and rotate by the amount given. If the sprite currently has an angle of 0?, then using

Sprite: Rotate 5 degrees clockwise

will set the angle to 5 (or rotates by 5 degrees per tick, when used in an always event, for example)

Mixed with a TimeDelta'd variable you can again rotate it over time:

+ Sprite: Angle Less than 90

-> Sprite: Rotate 45 * TimeDelta degrees clockwise

This will rotate within 2 seconds (45 * TimeDelta means 45 per second, a total of 90 is needed == 2 * 45 == 2 seconds)

You can also directly set the angle and when using lerp() you can get a smooth rotation too:

+ System: Is global variable 'myStep' Less than 1

-> System: Add 0.5 * TimeDelta to global variable 'myStep'

-> Sprite: Set angle to lerp(0, 90, global('myStep'))

With 0.5 * TimeDelta it takes two seconds to raise 'myStep' from 0 to 1 (used as t-value in lerp) and therefor 2 seconds two rotate from 0 to 90

When working with TimeDelta time has precedence over accuracy. That means, the ending angle might not be exactly 90, but e.g. 90.35762 If you need it to be exactly 90, just add an event:

+ Sprite: Angle Greater than 90

-> Sprite: Set angle to 90