Okay then. Here's how I did the timers in This Cursed Rock (I had a lot of cutscene events that were dependent on time).

Create a variable called "timerCount" either as a global or in one of your objects. Next, create a variable called "timerStart." Set both to default at 0.

Next, when you want your timer to start, set "timerStart" to 1. Then do this:

+Value('timerStart') equal to 1
+Every 1000 MS
   ->Add 1 to Value('timerCount')
[/code:1wjhlad9]

Then every second it will add 1 to timerCount.  Actually, the way "Every x MS" works is it will add 1 to timerCount immediately when it starts, rather than waiting 1 second, so at the end of 1 second your timerCount will be 2, at the end of 2 seconds your timerCount will be 3, and so on, so it'll always be one number ahead of the actual number of seconds passed.  If you need an exact count you can add an event that checks for another variable called "beginCounting" or something:

[code:1wjhlad9]
+Value('timerStart') equal to 1
+Every 1000 MS
   +Value('beginCounting') less than 2
      ->Add 1 to Value('beginCounting')
   +Value('beginCounting') greater than 1
      ->Add 1 to Value('timerCount')
[/code:1wjhlad9]

This is just how I did my timers though, I'm sure there are other, better ways to do it.  And if this doesn't do what you need then I suggest you get a little more detailed with your question, it'll be easier to help you that way.

What are you timing?

I agree, it's always best to make your own art, or find an artist to collaborate with. But if you're making a fangame, then it's a little more forgivable.

I'd also like to point out that the number of unfinished fangames outweighs the number of unfinished original games by several gazillion tons. I don't know why that is (well, I have a theory but I don't want to offend anyone). Hopefully that's not the case here, especially if this is for a class assignment.

Even so, you might consider making a smaller project for your first game. A smaller, tightly made, feature complete game would definitely get you a better grade than a mish-mashed, overly ambitious, buggy, unfinished one.

>

> You don't need to do this for every kind of game, but the way the platform object works you're just going to run into trouble.

>

It's generally good practice to create invisible hitboxes for most sprites anyway as oppose to pixel perfect collision I think. I think it's a fairly common practice but I usually draw my backgrounds seperately in photoshop and then after importing the image, build the platforms using hitboxes also, which makes the whole thing run a lot smoother.

True, but it's not exactly best for all games. Like a top-down space shooter for instance, where you don't really have walls or solid objects. Bullets hitting your ship would work better with Per Pixel in that case. Especially if your ship has an odd, angular shape (which most tend to do).

A better way to handle pause is to use the ELSE condition and a subevent. Eg:

+ On P pressed

----+ (conditions saying it's already paused)

----> Unpause

----+ Else

----> Pause

This way you don't need any flags or other events (and it's easier to make sense of too).

Ah, that is better. I remember someone posting an alternative to my method before but I couldn't recall what it was.

Awesome

We're in the process of completely rewriting the event sheet editor right now (every line must go) as it's in rather terrible shape.

Once that's done this is one of the first features on the list, along with many others we'll then be able to add as a result .

Will it be compatible with our current projects? Should we hold off on starting any big projects just to be safe?

You might be able to get away with an angle compare. Something like:

sprite.Angle is greater than sprite.Value('lastAngle')

You'd have to compensate for the 360/0 boundary though by adding in some more complex checks:

+round(sprite.Angle) is greater than sprite.Value('lastAngle')
+round(sprite.Angle) does not equal 360
   ->Set sprite.Value('rotDir') to "right"

+round(sprite.Angle) = 360
+sprite.Value('lastAngle') = 0
   ->Set sprite.Value('rotDir') to "left"

+round(sprite.Angle) is less than sprite.Value('lastAngle')
+round(sprite.Angle) does not equal 0
   ->Set sprite.Value('rotDir') to "left"

+round(sprite.Angle) = 360
+sprite.Value('lastAngle') = 0
   ->Set sprite.Value('rotDir') to "right"

+round(sprite.Angle) = sprite.Value('lastAngle')
   ->Set sprite.Value('rotDir') to "stopped"

+Always
   ->Set set sprite.Value('lastAngle') to round(sprite.Angle)[/code:2wgbui6z]

Then you could record the 'rotDir' states and use those for the playback.  I haven't tested it but with some tweaking it might do what you need.

Yeah, now that you know how to fix your button presses you should make the dialogue thing use just one mouse button. Or better yet, a key, preferably the Enter key or the main action key for the game (in this case, Shift). It's a good idea design-wise to make it so you don't have to touch the mouse unless there are actual mouse controls in-game.

You don't really need a container for your player because there's only going to be one player. Containers are for muliple multi-part objects. For instance, if you had several enemy sprites with several separate enemy hitboxes.

As for sub-animations, I really don't know. I've never even tried them out, I have no idea how they work. As far as I know, I've never had any need for them.

Also another tip is to use the tiled background object and set the width. That works well with a health bar that gets smaller (doesn't scale, just becomes less and less) or hearts where you have a tiled image of a 16x16 heart and each time u get hit you subtract 16

That's a clever trick

I finally got the game to play, for some reason it stalls at the dialogue scene and I thought it was just freezing or something.

Like I mentioned in your Help thread, the Per Pixel collision on your animated sprite causes problems. You can hang off the edge of a platform by his arm, for instance.

It will also cause problems at walls. Since your sprite is animated, it doesn't have a constant width. If you run into a wall on one frame, the next frame might intersect with the wall because it's wider than the previous frame. If it does that, your sprite will pop to the top of the wall due to the way the push-out function works on the platform behavior (it's designed to always push out of the ground if it's stuck).

Even if you changed the collision type to Bounding Box, you could still run into this problem. It's best for platforming objects to use a separate collision box sprite that has only one frame so it never changes size. Put the Platform behavior onto this box sprite, and take it off of your animated sprite. Then set the position of your animated sprite to the box every tick.

You don't need to worry about this so much with other kinds of games really, just platformers. If you're doing a top-down space shooter, for instance. But it's still a good idea to use this method whenever you have objects that need to come into contact with solid objects like walls or platforms.

As for the movement, Belmont is way too fast. You should slow him down a lot.

One thing... you have fifteen Start of Layout events in your test layout alone. You only need one. You should really learn to use sub events.

Edit:

In fact, I can see a lot of common mistakes in general in your .cap. You have your animated sprites as your Platform objects, and you have them set to Per Pixel collision. This is just going to cause problems for you. You should make a separate, invisible box and use that as your platforming object, and just position your sprites on top of it.

You don't need to do this for every kind of game, but the way the platform object works you're just going to run into trouble.

Plus, you would only need one platforming object, and you can use it to put your different character sprites on. If they have to have different speed or jump heights or whatever, you can change those at runtime depending on what character is selected.