Hey all,

I have run into problems with one small feature of Construct 2 on a number of occasions now: When you are resizing a sprite and you accidentally right click on another, it makes the sprite you are resizing the same size as the clicked sprite.

Now I may be the only person in the world with lazy middle finger syndrome, but the number of times I have drastically resized sprites I only wanted to change a little is getting ridiculous. To compound matters the action cant be undone!

Is there a way of disabling/rebinding this feature?

If not developers, please PLEASE consider adding one.

ArgH!

Hey,

Does anyone have any advice on the best way to create a complex infinite runner?

I ideally would like to spawn 'stages' of a set width with various sprites in each stage.

As with other infinite runners I would then spawn the next stage as the player reaches the half way point of the previous stage.

I do currently have a system in place but it is pretty long winded.

What is the best way of going about creating a system like this?

Thanks.

Not that stable, not compatible with c2 memory management, not fully compatible wit some of c2 basic features, conflicts between scirra and ludei that finally lead to have the community itself take care of the plugin since ludei did not enough work from their side, better exporter for android, phonegap that will take the lead at the end for both iOS and Android, the surprising popularity of cocoonjs despite the fact it is kind of unstable, that updates of cocoonjs tended to be plain broken, and that scirra had to endure the support to their user since they were proposing it.

Now scirra will not have to take responsability if it is broken once again for a long time period.

I think that sums up it partially.

Ahh I understand. I've heard of phonegap before but never really looked into it. I just had a quick glance now and a) it seems to be a paid service, and b) appears to not come with advert integration build in.

Is it really that much better than Cocoon?

Ahh brilliant thank you. Do you know why it was depreciated?

So in the latest update, the CocoonJS exporter has been depreciated.

What do I do if I still want to use CocoonJS?

I can confirm that after testing banner AND full screen ads do not show as often in the new compilers as 1.4.7. So annoying!

Damn, I noticed this problem a couple of months ago when I tried to swap to the 2.0.2 compiler. I was really hoping it would have been sorted by the time they forced us onto 2.0...

Who is at fault here. Is this CocoonJS or Mopub that are screwing up?

No worries, honestly I love working through these little problems, and its been interesting to test out different things!

I cant be sure on wether the behaviour is frame rate independent, but considering 'simulate control' effectively runs every tick, you would imagine it might be affected by frame rate changes. Try experimenting between that and the bullet behaviour for best results is my best guess. As is so often the case, wherever possible playtesting should give you the answer!

Glad to be of help!

Hi SeriouslyCrunchy,

You've been a huge help - this topic has been very interesting! One last question though:

Would I be right in thinking: System| Every tick - Player Object| Set Platform vector X to Self.X+250*dt

Is regulating the X movement of the player object by dt therefore making it frame rate independent?

This doesn't really seem ideal though...

As far as I could tell after some quick prototyping the platform and bullet behaviours aren't actually frame rate independent (unless someone knows otherwise). This is obviously a problem for me so I need a way of making the movement robust to changes in frame rate!

Any suggestions?

Even after a few years programming I'm still yet to realise it's never, ever simple!

TMAJA

Yes, this is getting interesting. We have two ways of doing this, and I honestly think both are viable. If you were to follow the infinite runner template example, you would have to hard code in what 'time' each object would need to spawn at, with its corresponding X and Y co-ordinates, which honestly is a bit of a pain, but would clear up any performance issues.

However, I'm convinced you can still use scrollto quite happily! So I've spent a few moments editing the infinite runner template and using your approach instead. I think now the best way for you to try this is to edit the way your player character moves forward. You could either give the player character the Bullet behaviour, or if you're already using the platform behaviour, have it so every tick you simulate control of the player character in the direction you need them to go.

Heres the quick capx I cooked up using the bullet method, if you want to try the simulate control on every tick method, remove the bullet behaviour from the player character and enable the event in the event sheet : https://dl.dropboxusercontent.com/u/245 ... ollTo.capx

The only way I can see this not working so well is if you need more control then that over your player character.

Hope this helps!

Hi SeriouslyCrunchy,

Sorry it took me so long to reply on here! Your capx was incredibly interesting to inspect, and I have actually changed my characters movement to the simulate control method! Thank you very very much for your informative answer and taking the time to provide some example code; amazing!

I have come across another related question though - as I am now using the platform behaviour and simulate control to constantly move the player object forwards, is this behaviour frame rate independent? Obviously frame rate can be pretty changeable on mobile devices and my previous method was robust to those changes. I had a look in the manual and it actually doesn't say (unless I have missed something)!

Thanks!

Lordshiva1948

Thank you!

SeriouslyCrunchy

Yes your spot on - the difficulty curve is quite specific so at the moment objects need to be in a fixed location.

Again your exactly right - having a lot of objects does cause some pretty huge headaches performance wise, especially on lower-end devices. The strangest thing is though, even on high end devices (where the frame rate sits happily at 60) the screen still seems to 'vibrate' as the player is moving. That's why I was originally wondering if ScrollTo was actually the best way!

I will honestly look forward to your reply, I'd greatly appreciate your continued input - It's a pretty interesting topic!

(Also while your tutorial isn't 100% relevant to my question right now, it is a well written guide which I will definitely be using in the future!

Thanks

Your game sounds less 'flappy bird' and more 'infinite runner', although flappy bird is of course an infinite runner in itself in a way, so some of the same principles hold true. Have you had a look at the infinite runner example in C2? I also wrote a small tutorial about infinite runners, but I don't think this covers what we're discussing right now.

I'd like to see a .capx if possible of your attempt with ScrollTo. In my experience, the issue with using ScrollTo for infinite runners is that it in my opinion it gives you less control over certain aspects of the game. Object instance generation and termination are much easier to handle, for example.

Hi SeriouslyCrunchy,

I have to admit, I haven't actually looked at the infinite runner example - although I just had a look for it now in the example projects and couldn't find it at all? Do you know what it's called?

Would you link me to your tutorial? Any and all opportunities to learn are always welcome even if it is not 100% applicable here!

Unfortunately I cant upload my capx - but I can describe to you EXACTLY how my ScrollTo works.

My ScrollTo behaviour is implemented on my player object (by just adding the behaviour from the behaviour panel).

My player object then moves forwards like so:

PlayerObject| Set X to Self.X + 240 *dt.

My levels are pretty long (14,000 px horizontal) but not infinite and have a variety of different objects within them!

Am I doing this the best way?

Is there any other reason other than CPU use for you to use ScrollTo? Are there some special events that need this?

I have to agree with rezagamertag above. As you rightly say moving many objects is more CPU intensive than just moving one, but I'd say in most cases doing it this way will save a lot of headaches in the long run over using the 'ScrollTo' action. Just don't forget to terminate objects that fly off the side of the screen.

Hi SeriouslyCrunchy,

Nope, I was using 'ScrollTo' because I thought it was the 'best' was of doing things. It just keeps the camera focused on the player object as it travels through the levels, that all.

By best I generally mean best for performance; as the game is on mobile devices performance can be an issue!

Although I did make flappy bird comparisons only the movement is really the same - things get much more complicated after that - levels are certainly much more diverse.

I'm guessing there is a tipping point somewhere; where the size/complexity of the level eventually makes it so the 'ScrollTo' behaviour is the best way forwards?

Thanks