Limiting ammunition is done with variables. For example, you could create a local variable attached to the player called Ammo. Every time the player presses the button to fire their gun, first you check if Ammo > 0, then if it is, create an instance of the bullet along with the firing animations (or whatever else is needed) and subtract 1 from Ammo.

If your code is right with your health bar, then it's probably something silly like a layer or object set to invisible. If you can't come right on your own then you should post a link to your capx so we can take a look for you.

Select the project name in the project pane on the bottom right of the screen, then click on "First layout" on the properties pane on the top left of the screen to change the default layout.

No sweat. I've done this a few times myself so I knew the first obvious place to look :P

Yup, you'll have to edit the images to smaller size.

Read about image optimisation here.

You can see that file size is determined by a variety of factors. In your case, decreasing the dimensions of the images will greatly help in reducing file size. You seem to be using massive images but actually resizing them down greatly in-game. This still uses the original image, however (and additionally has to calculate resizing it, which also looks pretty ugly in C2), so you're effectively wasting space.

Example, your iodine bottle:

Original, actual image [703x1770px; 47KB]:

<img src="https://dl.dropbox.com/u/14522925/C2%20examples/bottle-actual-size.png" border="0">

How the image appears in-game [61x153px; still 47KB]:

<img src="https://dl.dropbox.com/u/14522925/C2%20examples/bottle-in-game.png" border="0">

Resized image to fit in-game [61x153px; 5KB]:

<img src="https://dl.dropbox.com/u/14522925/C2%20examples/bottle-resized.png" border="0">

In the properties pane on the left side of the screen, under behaviours, check that destroy isn't set to after fade out (it should be set to no, in this case).

Don't forget that objects off-screen or invisible can still be interacted with. You should use another condition like "is visible" or "is on screen" to check if the dialogue box should be interactive or not.

I was referring to the "on layout exit" action, but looking at your capx that's not the problem.

Still not sure what you mean by animations, unless that's what you mean by "games". Anyway, that's not an issue either.

Taking a look through your project, I'm pretty sure that the only issue is the size of your images - in terms of disk space. They're too big. 5MB for a simple project like this is huge. The images are simply taking too long to load (as it's their first time doing so when entering the layout) when changing layouts, which causes the delay. It's nothing in your code, you just need to optimise the images in an external image editing program like Photoshop or even GIMP.

I'm testing by compiling this project and even that is taking waaay longer than it should. My PC is churning away to make those sprite strips.

Your other option (which doesn't actually address the problem, it just side-steps it) is to include all or at least half of your images in your first layout, but just outside of the layout itself so they won't be visible. This forces the browser to load the artwork into memory in stages, instead of all at once. This won't reduce the overall lag, but it'll slice it into less noticeable chunks.

Oh, and you don't need to use both the mouse and touch object for input. Touch has a neat property called "use mouse input" which simulates the use of a mouse, meaning you can use the touch object exclusively but it'll accept both mouse and touch input.

The Map2 layout has no event sheet assigned to it.

Your method seems right, so there must be something else to take into consideration. Maybe you have a lot of stuff running on layout exit?

You refer to animations in an odd way, what do you mean by "this particular animation I'm working on"? Is it possible that an animation is still running, causing the delay?

Without much more info it's difficult to diagnose your issue without guessing. Posting a capx would enable us to help you easier.

Also, don't forget that you need to test if "Defender.Floating is not true" before assigning targets to the turrets. Otherwise they can fire before they're actually placed down.

Nope, sorry. I'd really like it if the sprite editor did have a basic text function. In the meantime, I'd suggest that you use a single static (as in - it doesn't need to change during the game) text object that you just clone and edit as necessary across your entire project.

I don't understand your second question :(

Just have a couple of minutes so I'll give you some real quick feedback of random thoughts in no particular order:

1) Is that Felix from Wreck-It Ralph? He looks awfully much like him...

2) Please replace the space key with the up arrow. I'm not sure what your thinking on this was but it feels weird to have to go between space and up when jumping and climbing ropes. Up should be up (in my book).

3) There's a weird, like, spongy feeling when colliding with the platforms. The player sticks to them and then falls through.

4) I was totally confused in the beginning, thinking that I couldn't walk through the centre beam, so I didn't even try it. It's because it's exactly the same as the outside beams (which are solid), so I'd recommend changing its look slightly to make it obviously not solid.

5) I like the cheeky death messages. They're to the point and make sense.

6) No death from falling too far? Is this a deliberate choice or did I just not fall far enough?

7) Just an odd thought: if he's going after his lunch, why is he not satisfied by all the fruit and croissants that I'm gathering on the way?

8) I really like the name, by the way. I don't usually spend much time in this sub-forum but I saw the thread title and immediately was interested. I didn't know what to expect. It's quirky, and it fits the gameplay pretty well.

9) If I die on the poison then the death animation drops me down twice.

10)It seems a bit unfair to not reset the timer upon death, considering that the player has to start all over from the bottom upon death.

11)Oh god, the music. Please make a longer sample, it's painfully repetetive :P

Great work so far. It needs some tweaking but it's set to be a nice little arcade-style game.