I see two easy ways you could do this.

The first would be to make a new object (let's call it "cameraObject"), and place it in the center of the screen. Make it invisible, and make the camera/view focus on it. Then, implement the code: "every frame > cameraObject.y = cameraObject.y - 1". This way, the camera will go upwards, but it will never come back down or go side-to-side. If you use this method, make sure that the camera isn't bound to the edges of the game world - otherwise, it will stop when cameraObject.y reaches zero.

The second way would be to not use a camera at all. Simply move the blocks downwards when the player reaches a new height. "Every frame > for each block > block.y = block.y + 1". This method might be a little less intuitive to implement, but it can be more efficient, and is the "standard" way of making endless jumping/running games.

Ultimately, go with the method that feels right to you. It would be silly to say that one method is "better" than the other.

There are a lot of ways that you could do this. You would be best off implementing whatever method/formula is most intuitive to you, or whatever fits in easiest with your program. But here's how I would do it:

1. Apply the reel variables to a 5x3 array

2. Make a recursive function that takes the variable present at [x,y], and checks whether the same variable is present at [x+1,y] (i.e. the reel square directly to the right). If y>0, then check whether the variable is present at [x+1,y-1] (the reel to the above-right). If y<2, then check whether the variable is present at [x+1,y+1] (the reel to the below-right). If the variable is present in any of these position, then call the same function for that position. If x+1 == 5, then congratulations - you've got a line - do whatever it is that you need and don't call the function again.

3. Call the function for [0,0], [0,1], and [0,2].

If you hate the idea of using recursive functions, then I suppose you can do a similar implementation with one or two for/while loops.

You can add blank sub-events. Just right-click > Add > Blank Sub-event. You can't add blank actions as far as I'm aware, but you can just right-click > Add > comment, which is normally a sufficient place-holder.

For anyone wondering about the effects of screencanvas rendering in the latest update: I've noticed an all-round boost in frame rate on iOS via CocoonJS. In my game, there's a significant increase during cut scenes (essentially 3-5 large sprites being panned slowly) - the scenes have gone from ~30FPS to ~42FPS. However, the increase is negligible during gameplay (10-15 sprites, basic physics, GUI overlay) - the scene has gone from ~28FPS to ~30FPS.

This means that the change probably won't make a previously unplayable game playable, but it might help make for a smoother experience.

I've found CocoonJS to be great for iOS. Aside from memory issues, my Construct game seems to work exactly as expected, and I can maintain a frame rate of around 30-40FPS. From what I hear, Android performance varies. One developer on the Ludei forums mentioned seeing a huge frame rate increase when he removed a tiled background - I suppose Cocoon is still in the "some features are more reliable than others" stage of development.

I wouldn't mind seeing a performance comparison between AppMobi and CocoonJS. It would be useful to see if certain assets are handled differently, and whether this significantly impacts the frame rate. On a related note, does anybody know whether AppMobi loads all the assets (except music) up-front like Cocoon does?

Apply the Toon Shader, then apply the Color Replacement filter with a source of 0,0,0, a replacement of 255,255,255, and a tolerance of 1.

Oh, awesome. You guys are adding features as fast as I need them! I'll make a post on the CocoonJS forum.

I'm currently making an iOS game through CocoonJS. It's going very well; I am 70% through development, and am consistently getting a framerate of 30FPS on an iPhone4. However, a little issue has been bugging me.

I notice that the application front-loads all of its graphics (at least, it appears to). This causes a memory warning, and results in the application being automatically closed if I attempt to load another app. Although not game-breaking, this is undesirable.

I figure the possible solutions would be to either load and deallocate the assets dynamically / manually, or find a way of allocating a large chunk of memory that the OS can leave alone.

Does anybody know if either of these solutions are feasible or even possible through Construct2 and CocoonJS?

Sure, I'll send a message later. Thanks for the reply.

That's disappointing, but there must be some way of gathering the "now playing" position, even if it's in the form of a crude method like counting the number of bits streamed so far.

First, I would like to say that Construct2 is an amazing piece of kit. It is, without a doubt, the most intuitive and fun-to-use games engine that I've come across. I love it.

I'm currently working on a rhythm game, similar to DDR or Guitar Hero. Normally the visuals and the music synch together perfectly, but if the player leaves the tab, or if the application stutters for whatever reason, the music gets a little bit ahead and the synchronization is ruined.

I did a little searching and found this topic from a few months ago, but it appears that no solution was available at the time.

I imagine that one solution would be to check the music time elapsed against the number of ticks passed, and if there is a discrepancy, then the music can be rewound accordingly. I don't see a way of checking "music time elapsed" or "go to this time" with the standard Construct2 commands, so are there any plug-ins that would allow me to do this? If not, is there another route that I can take?