sqiddster, I'd argue that video playback is a very important feature for modern games.

Just yesterday I was watching Myst's co-creator Robyn Miller do a post-mortem on Myst from GDC, and he said that when Quicktime was released about halfway through the development of the game, it changed their project significantly for the better.

Bit of an arbitrary example, but my point is that some developers might find video playback to be critical to their game, or it might open up new possibilities, and it's certainly the kind of feature that wouldn't hurt to have, especially for those of us looking more towards desktop than browser-based as launch platforms.

And, yes, I'm aware of the plugin - this post is purely in support of an integrated solution and in favour of this thread.

Add another condition to event 1: If TimeCount > 0.

Set event 2 to just be: If TimeCount = 0, end layout.

onion, you definitely don't want to add your UI elements per layout. That is going to be an issue as your project grows.

Your options are to use global objects and just hide/show them as necessary, or, yes, use events to build them as necessary. I chose the the latter and it works well enough for me.

There sure is: zeropad(number, digits).

If that's the totality of your turret's events, then you need to add targets for the turrets to acquire. Turrets need to know what to shoot before they'll do anything useful.

Have a read through page four of my tutorial for an overview of the behaviour in action, and don't neglect the manual entry.

Why has this come up so often in the last week?

Answer is here: scirra.com/forum/status-on-screen_topic66010_post405143.html

Download R124 and check out my example. It's dead simple - a single event. You should generally stay up-to-date anyway.

Have a look at this example.

Just for example's sake, I've assigned the PlayerBox the platform behaviour so you can see how it moves, but in your game you'd obviously have some sort of custom AI movement set up for your mobs.

The way you should set up your colliders should be the same, though. Notice that the actual box is the object that's controlled - the sprite is simple pinned to it. The box would be invisible in a proper game, though.

Also worth noting is that when I pick the sprite (On Created) - it automatically picks the correct collision box in the pin action; this is the beauty of containers.

The simplest way I can think to address this "problem" (technically it's a feature more than anything) is to hide the UI elements when you don't need them.

Since you're still using the free version of C2 you won't have access to families, but you can create an event in your menu event sheet that, on the start of the layout, sets each UI element to invisible (families would let you do this as a single action). Then just make sure that you do the opposite in each actual level's event sheet.

If these are UI elements that are interactive, then add a condition to their interaction events that checks if they're visible before performing the action.

Use containers: this will ensure that each mob gets a collision box when it's created, and when one dies, so will the other.

The simple method to pin a container is with the pin behaviour. So do something like this: when the mob is created, position the collision box to it, and then pin the box to it (two separate actions, same condition). With containers, the box is automatically created when the mob is created, and the correct instance of the box is automatically picked when you pick the mob.

Pinning and assigning position every tick are identical in terms of functionality and resource usage.

dragoonblade a lot of people think that. Not sure if it's a language barrier, people not reading carefully or (more likely), newcomers who don't understand the terminology when they first read about the limits, and end up thinking they actually read the other word.

Because I thought this was all rather interesting, I created a small test to determine how much of a performance hit is taken generating objects on-screen as opposed to off-screen.

This test has two options; both use identical events to generate one of each of three sprites every tick and displays the time, frame rate and sprite count. One test only creates the sprites on-screen, and the other uses the entire layout. The tests will give you the exact count of sprites at which the frame rate reaches 30.

You can try it yourself here. I don't know how scientific this test really is, and I'd be interested to get some feedback on its accuracy as I think it could have an effect on how layouts are designed for games that depend on a smooth frame-rate.

For reference, on my machine, test 1 takes 8310 sprites to get to 30fps. Test 2 takes 11043 to get to 30fps