PixelHero here!

I'm a professional developer (C# and WPF, though I end up supporting legacy C++ applications a lot where I am), and a hobbyist game developer.

As a kid, I always though making a game would be fun, but I never really looked at the games industry as I got older. Waaay back I used DarkBasic (back before they had Pro), although that never really amounted to anything. Then I dabbled in XNA, and finished the only game I've ever really made: a clone of Arcomage from Might and Magic VII and VIII, though it used the original art assets, so I was never able to release it. But It was actually a complete game, including an AI opponent with fairly complex rules as to how it would play. It even won sometimes.   <img src="smileys/smiley7.gif" border="0" align="middle" />

Then I dabbled in Unity (before they had a built in 2d toolkit), which is a natural fit for me since I really enjoy working in C#, and I have a fairly large bag of tricks there. But it just... never really worked with 2D for me. I tried a couple of 2D toolkits, and they help with the atlasses, but I just found it difficult to make 2D games with it.

So even though I know programming, and it at times is difficult for me to set aside my OOP training, I find myself having fun in Construct2 and actually continuing to develop my ideas. Which is a novel concept for me. :-)

Oh, and I STINK at art and assets.   I can do 3D sculptures (I use sculptris) though, so maybe I should make some digital boardgames....   hmmm

Sorry, I have yet another idea I need to write down...

The common use of Lerp actually hides what the math is doing. LERP is a linear interpolation between two values, where a decimal number between 0 and 1 describes how far along the scale the value lies.

So, for example,

if you scale is 0-100, a value of .3 indicates that the value should be 30. Percentages! But of course, we can use other scales, so a scale of 654 - 1782 with a interpolation value of .3 is 992.4.

It works out to:

(high - low)* interpolation + low.

Now, the common use in Construct 2 is to achieve a smooth curve approach to a value, such as a camera target. That way the camera smooths into the value, rather than having an abrupt end. If we look at the math:

Say we had our 0-100 example, with the .3 interpolation value.

First loop:

0-100, .3 gives 30. So we set position of the camera to 30.

Next loop:

30-100, .3 gives 51. So we set position of the camera to 51

51-100, .3 gives 65.7.   So we set position of the camera to 65.7.

Etc...

Now, what ends up happening is that eventually the camera is moving by very small steps per step of the logic. But we are feeding the result of the previous step back in as into the logic to get the next step. Eventually, the camera starts moving by less than an integer per frame, which means that if you floor that value, it stops moving entirely, because every time the floor is causing it to reset the value to what it was. (going from 941, to 941.87, which gets floored back to 941, in your case, for example)

Now, it is a good idea to have an end condition for the move, to prevent small minute "drifts" of the camera. This can be achieved by having a condition to check if the distance between the camera and the target is less than some critical distance. If it is, snap it to the end value. Too much and you'll see the snap, too little and you'll get minute pixel shifts of some of your sprites, particularly if they have non-integer positions.

Hope that helps!

That probably is happening because your event sheet isn't picking a door instance. If you don't have a specific instance picked by an event, then the action happens to ALL instances.

So for instance, something like:

* System | On start of layout

   local variable newDoorID = 0

   * System | For Each [] Door

        Door[] | Set doorID to newDoorID

        System | Add 1 to newDoorID

This will cause each door to get a unique ID at the start of the layout. If you want globally unique door IDs, then just make newDoorID a global, rather than an instance of the on start layout. You can also do a for-each ordered if there is another criteria that you want to use to determine the IDs (such as position along the x axis, or something)

If you want, you can also save the level to load in a text instance variable on the door, and then use common code like the following (you'll have to add in the stat saving and all, sorry)

* Keyboard | On [use your key here] key pressed

   * Player | is overlapping [] Door

   * Door | X Is Locked                           //Just an example

      * System | Go to layout Door.levelToLoad

For an example. Of course you can spruce it up, but at least then you don't have to do any custom mapping of doors to levels.