One very good way to learn how to track is to open up music modules in a tracker. This is how I learned many years ago. If you open up other people's songs and you will see how they are put together - it's a good way to see what the different tracker effects do as well, as to newcomers they can be very daunting - often they are programmed in with obscure hexadecimal values that won't make any sense at first - when you can see a track layed out visually though and isolate channels and instruments etc and generally just play around with it, it will start to make sense. There are thousands of tracker modules available online in places like http://www.modarchive.org - if you do a search for chiptune on there you will find a bunch of modules to download, then if you open those up with Milkytracker you will be able to see how the music is put together.

For chiptunes, trackers are pretty much the way to go. While you could write one on any modern DAW, but the tracker interface is really great for chiptunes. Milkytracker is great and will do whatever you need and more but will have a steep learning curve and you'll have to prepare and load your own chip samples into it. Haven't tried Pulseboy but it will probably also do what you need. If you want something out of the box you could try famitracker - which can be used to create tracks for the NES - if you want a pretty 'authentic' chiptune sound - your typical saw/triangle/noise - it's quite robust though and quite useful for sound design once you understand it.

I re-use a lot of my events in different projects and it is a huge timesaver. It really just comes down to planning to do this and always using the same naming conventions. Like Sol said, generic names work best as they're easy to remember and will be relevantly named between projects. Once you start to consciously plan to reuse events and name objects accordingly it becomes pretty painless.

Fantastic find! Thanks.

The detectors don't need to be solid - you can still check for a collision with the enemy and make it react on collision.

Hi, I'm not exactly sure what you mean. But your coin has a bullet behaviour applied to it, so when it spawns it starts moving to the right. So maybe remove that bullet behaviour and instead put a pin behaviour on the coin. Then you can spawn the coins and they will hang in the air - then test for a collision - if the coin is overlapping the platform pin it to the platform - it will then move up with the platform.

Hi, I've got a save/load system that uses Construct's default state save/load. This is nice and easy to implement and for the most part works really well. However, I'm thinking if I release the game, say on Steam and it needs an emergency patch, if I update the game and then redistribute it - what will happen to my customer's save games? Will they be useless? I've wanted to avoid having to use local storage/dumping a whole load of variables etc - I'll go down that route if I have to though.

You can set timescale on a per-object basis. So for example if you have set your main timescale to 0, you could then set certain objects timescales to 1 - so that they can still animate etc. If you look at the attached example the rotating box on the left represents the timescale of the project - when you left click it sets it to 0 but then it sets the box on the right timescale to 1 - so essentially the rest of the game is paused but some elements can be unpaused. https://www.dropbox.com/s/zex0f1wjvybz5pk/pause.capx?dl=0

I think it could work in exactly the same way as far as I can tell - there's a video tutorial here for a simon says game in construct, it should be fairly simple to modify that to shapes instead of colours

Check out Hitfilm 4 Express https://hitfilm.com/express - it's free and very powerful, seems to have a lot less restrictions than some of the other free offerings out there. The workflow is also very good.

There's probably a bunch of ways to do this - but here's one. Assuming you're using the standard platform behaviour. Set up a global variable called 'wind' which you can toggle on and off - when it's true set your characters max speed to a low speed and when it's false revert it back to the default. Here's a quick .capx to demonstrate - it can probably be done more efficiently, but it shows a system that works anyway. https://www.dropbox.com/s/oq6uujtldm87aqv/wind.capx?dl=0

Hard to tell without looking, but maybe you need to preload your sounds? If you don't do this there can be a delay while the sound is downloaded before playing.