Create another condition to your event that checks whether the sound is currently not playing. Assuming you're tagging your sounds: Audio -> Is tag playing. Then, right-click on the condition and click Invert.

You've got loads of options to do this, and I'm kind of surprised that there isn't a tutorial to cover this.

The easiest way by far is just to have a series of sprites on which the user clicks/taps using the mouse and/or touch object. In that sense, any sprite can become a button, you just use the mouse -> [On object clicked] action instead of using an action from the sprite itself.

As for keyboard input, that's a little trickier, but here's a quick example for using the left/right cursor keys to navigate a selection screen. Press return to select the level. Example capx [r126]

In my example I'm assuming all levels are labelled "Level 1", "Level 2", etc. The text action is just an example of how to use the currently selected level, you'd usually use an action like [Go to layout] -> "Level "&Selection.Selected+1

I was going to mention that but I saw that he rounds it off, so I think he's aware of it.

Your event structure is way off. I strongly suggest that you read some beginner tutorials to become more familiar with the process of building events.

Basically, events have conditions and actions. If all of the conditions are met, then all of the actions will be performed. You're asking C2 to check if all of those conditions you've stipulated are true (start of layout, rd=1, rd=2, etc), and then, if they are true, excecute all of those actions you've specified.

You need to split up those events into a main event that sets the variable to a random number, and then individual sub-events that check that number to produce a result. Like this:

<img src="https://dl.dropboxusercontent.com/u/14522925/C2%20examples/sub-events.jpg" border="0" />

Damn man, very nice. Simplicity at its finest. Even though I'm still hoping to get something entered into the comp, this looks set to take the win.

It uses the collision polygon, as does the mouse object.

So I've been thinking about this and, even though it's kind of impractical, you could probably get away with using the free version of C2 to make your video, considering your financial restraints.

See, my thinking was that starting a Kickstarter without actually having made at least the core of all the components of your game that you're promising is kind of unethical, or at the very least asking for trouble. But if you take the time to make, say, a few different demos, each showing different components of the game - stringing them together into one "gameplay" video is a good balance between getting the core work done and showing people what they need to see to become backers.

That way you've actually made the bits that you're promising - you know that you can do it, and you're able to prove so - and when it comes to building your full game you would have the core/engine work done already. Moving events and objects between projects is cumbersome but doable, and while it'll ultimately make for more work for you, if you manage to get the funding you need then it'll work out in the end.

The only issue is releasing a playable demo, but you can get away with not having one if your gameplay video is compelling enough. If you can show that you can deliver, then most people will be satisfied.

With regards to your Kickstarter, I'd suggest definitely aim on the lowish side, but not so low that people don't take you seriously. Bear in mind that most "low-end" Kickstarters seldom go far into stretch goals, so don't budget for it. Something between the $1000-2000 mark should cover your basic software licences (not sure what image editing software you're using, but even something cheap like Graphics Gale will work for your project), outsourcing music and sound effects (although you can generate 8/16-bit SFX for free yourself), and maybe paying for any additional programming or artwork you may need.

When you do launch your campaign, don't forget to hit up every single gaming/indie site you can find. Any bit of coverage will go a long way - this is one of the biggest mistakes I've seen small groups make.

Phew, sorry for the lecture, but I like the look of your game and, if you can really pull off what you're aiming for, I think it could be successful.

It's your density. Setting it to zero basically makes it a physical anomaly, and the engine can't figure out what to do with it. Density should always be set to something.

The easiest way to increase overall speed is to increase the time scale (actions -> system -> set time scale), but without knowing a thing about your game it's difficult to say whether or not that's the best way to do it. So you could use a global variable that increases every time you finish a layout, and then depending on what that variable is, you'd set the time scale accordingly.

Then there's the design/ethics issue: is repeating the same levels at a greater speed actually going to make your game better? Is it the sort of game suited for this kind of "progression"? Would you perhaps be better off packing up this game and moving onto a new game, so you can practise other skills?

Another strange thing is what you said - you've completed a game, but you consider yourself a layman? Unless your game is ridiculously simple I can't see that as true. And if it is that simple, perhaps you'd be better off spending more time with it, refining it, adding meaningful features and, at the same time, adding skills to your repertoire.

Sorry for the philosophy lesson, just struck me as something worth discussing, but feel free to ignore everything after the first paragraph if it's none of my business :D

This is not an issue I've ever seen. Post your capx and we'll take a look.

Wall of feedback incoming:

• I like the main character. It's well animated and looks cool. Very Pokemon-like - possibly too much, but that's just a matter of taste.
• That little intro/story screen is perfect. I can tell right away what's going on from a single image.
• Those backgrounds animations in the first level make my eyes hurt. Ow. I struggle to focus on the game at all.
• Animated things in the HUD are very distracting.
• I feel that the gliding should stop when the player lets go of the up arrow, rather than requiring a separate button.
• The instructions that popped up for wall jumping didn't seem to ever go away. They also only popped up when I jumped and pressed spacebar on the (!) sign. I'd expect it to pop up automatically (and disappear shortly after). I had to refresh the page to get rid of it.
• Baxter gets stuck in the mid-run pose when walking against a wall.
• The gliding rotating thing looks funny. Does he need to tip and turn like that?
• I don't know if this is intentional or not, because it looks kind of funny, but if I hold a directional key while falling, Baxter makes his running animation instead of his falling one.
• There are loads of weird collisions and occurrences of the sprite and platforms not lining up properly.
• Why are there two kinds of things to collect?

To be perfectly honest, I think you should spend a bit of cash and buy the personal version to crank out a demo that's an accurate representation of the final product. There are so many games (and so many promises) on Kickstarter right now. Coming along as a "nobody" with little more than hopes and dreams won't pay the bills. You need to prove to the public that you're able to deliver on your promises, and nothing boosts confidence like a fully playable demo, or at least a gameplay video showing a solid playthrough of the main features.

As it stands, I'd say your demo is a touch on the short side, but workable, so I definitely wouldn't recommend cutting out anything. Kickstarters that haven't even reached the alpha phase (i.e.: a vertical slice of your game - at least a glimpse of every main feature) almost never reach funding.