The reason that Fancy Pants game is so bouncy and hard to control is it's not using a traditional platformer engine... it's using physics.

It's the physics engine that's also allowing to get the normal for slopes, allowing for smooth rotation of the player when on a slope.

In my tutorials the slopes are rather limited, yes. But this is not meant to be the end of the road. It's simply a tutorial, not a finished, polished game. The method I (and Drasa) show for handling slopes is extensible... you could take this method and create other angles in the same manner. I'm just offering up the technique, it's up to you to take what you've learned and fill in the blanks.

As for loops and smooth curves... no, I won't be doing that. Shallow curves themselves are not terribly hard to do, but the platform behavior is simply not designed to handle real curves or loops. That would require a custom engine built from scratch with your own events.

Yes there will be level changing in a future lesson, but I'm sorry, no there won't be any of that other stuff. The lessons have all been planned out, and for my own sanity I've decided to keep things relatively simple. These are beginner tutorials, after all

For a beat-em-up like Golden Axe or Final Fight you'll probably want to use 8Direction movement on your player and your enemies, and the above-mentioned z-sorting could be done with all of the fighters in a Family using an event like so:

+For each fighterFamily ordered by fighterFamily.Y Ascending
  ->fighterFamily: Send to front
[/code:ypmjc1pv]

As Rich said, hit up some tutorials to get the general idea of how Construct works, and browse around the Uploads section for other ideas.  If you have trouble with anything in particular, feel free to post a help thread

what game is that it looks fun

I... can't... contain it... much longer...

Synapses firing... every fiber of my being dancing, burning like electrified plasma, reaching out... encompassing all... consuming... ALL

yyyyeeee

aaAA

AARRRR

GGGHHH

HH

HHH!!

<img src="http://www.b3tards.com/u/2951c544e5d930f23b20/thepower.gif">

I AM RISEN

What do you mean?

Are you from the future

No, probably not. You'd have to be fitting multiple boxes together like puzzle pieces to make buildings, unless you wanted perfectly square buildings. It could be done, though.

Hi.

I couldn't understand the cooper-bounce-overlap-timer part (lesson 8 )

Can you explain it?

Sure, no problem

First off, the reason:

We don't want the turtles to overlap each other. If they do start overlapping, they won't be able to pull apart, and you will have two (or more) turtles occupying the same space. This just looks awkward.

Second, the theory:

So... we need a way to get the turtles to bounce away from each other when they touch. Since we're manually moving the turtles by setting their speed and direction, it makes sense to set their speed and direction to something else when they collide. The easiest way to do this would be to make them reverse direction temporarily. This is where the timer comes in. We want them to only "bounce" away for a short period of time, and then return to normal movement. (If we simply tell the turtles to only move away when they're overlapping, then they will continuously try to push into the turtle in front of them. The timer gives them time to get clear.)

Third, the practical application:

In event 13 of the coopBox sheet, we have the overlap condition that starts the bouncing sequence. "coopBox overlaps coopBox." easy enough.

There is an additional condition that, out of those two turtles, the one that is farthest from the player is picked. This is the one the action gets performed on. The 'bounce' variable is set to 10.

Event 14 subtracts 1 from the 'bounce' variable every 10 milliseconds. 10 'bounce' multiplied by 10 milliseconds = 100 milliseconds, or one tenth of a second. This is the timer that defines the duration of the bounce, and it gives the turtle enough time to get clear of the one it's overlapping. When the 'bounce' reaches zero, we will return to normal movement.

BUT - notice that event 13 is always setting the 'bounce' back to 10 as long as the turtle is overlapping... this means that the timer doesn't effectively start counting until the turtle is no longer overlapping.

To get the turtle to stop overlapping we need to change it's direction. This is done in event 12. Event 11 sets the speed for the turtle when it's moving normally:

+ coopBox.Value 'bounce' Equal to 0
  -> coopBox: Set horizontal speed to coopBox.Value('xSpeed')
[/code:1vvt5pda]

But in event 12, we check to see if 'bounce' is greater than zero, and if so we reverse the speed:

[code:1vvt5pda]
+ coopBox.Value 'bounce' Greater than 0
  -> coopBox: Set horizontal speed to 0-(coopBox.Value('xSpeed'))
[/code:1vvt5pda]

The "zero minus value" equation is a way to toggle a positive number to a negative number, and vice versa.  0 minus 5 = -5, and 0 minus -5 = 5.

To summarize:
1. A turtle overlaps another turtle.  The 'bounce' timer is set.
2. The turtle timer begins to count down only when it is no longer overlapping another turtle.
3. As long as the 'bounce' timer is above 0, the turtle reverses his normal direction.

And that's about it.  Hope this helps

I think you should be able to add and remove atributes and effects in events.

It's been suggested, and iirc one of the developers said they would see what could be done about that.

As for adding or removing actual behaviors with events, I'm not sure I see the benefit to that.

However, please don't use this thread to suggest ideas .

Perhaps you should just lock the thread...?

Blasphemer! Outcast! Unclean!

No, that's fine, drawing comparisons to similar products is one way that features get refined. Of course the goal is not to "do it like they do" but to at least offer an equivalent solution.

I also heard about it through TDC, over a year ago. There was drama aplenty regarding the issue. Construct was being bashed in some thread or another and I thought "well, let's see what all the hubbub is."

Turns out that the Construct bashing was the most useful thing I'd ever read on TDC. I'd like to thank Liji for pointing me in the right direction

I read a gamasutra interview about Joakim Sandbergs Noitu Love...

I heard of it and thought it sounded promising on The Daily Click...

Um, hey Thomas... heh, never mind

Oh, that's cool then. Another thing I've discovered is animation angles right now have nothing but the most obscure of uses. They change automatically when you rotate a sprite, and unless I'm mistaken they can't be changed otherwise.

Well... yes they can. You can set a sprite to "No rotation" in the properties, or a few of the built-in behaviors have additional rotation settings. You can then set the angle to whatever you like with actions. If you set an angle of a sprite with no pre-defined animation angles, then it will simply turn the sprite. If there are any pre-defined angles then the sprite will adopt the animation angle closest to it's current angle.

I agree, angles should not have to do with animation angles. That should be seperate actions and conditions.

It's pretty much only a hindrance this way. The only way around it that I can see is to make seperate animations for each direction you want if you intend to have rotation. Say, if I have a picture of a fist turned right, I might want it to rotate full 360s to punch a face. But I would also like it to be able to do this in the other direction, and I add a mirrored frame to the 180 angle, but then I am screwed for the rotation to look good as the fist will constantly flip every 180 degrees no matter the inital direction.

In that case, don't use animation angles... have a separate animations for "Fist left" and "Fist right," with only one angle each.

Though I agree the whole animation angles thing might be a little confusing.