How do I constantly scroll?

0 favourites
From the Asset Store
All popular touch mechanics - scrolling, zooming, swiping
  • Hi everyone,

    I guess this is more of a 'what's the best way' rather than 'How Do I' but here goes:

    I have a platformer style set-up except my character constantly moves forward (like flappy birds for example).

    Whats the best way to keep the character in the centre of the screen? I'm currently using 'Scroll to' on the player object - but it seems to produce some stuttery effects as the screen moves (not lag - everything else is smooth). Is this really the best way?

    Thanks!

  • I would keep the player in the middle and move the entire background / objects to the left.

    This way you don't need ScrollTo.

  • I would keep the player in the middle and move the entire background / objects to the left.

    This way you don't need ScrollTo.

    Hi Rezagamertag,

    Interesting! Why would you take that route - I must be wrong in thinking moving many objects is more CPU intensive than just moving one?

    Thanks for your input!

  • It saves time creating very large maps, especially when it's an easy game like Flappy Bird where repeated objects appear constantly.

    The pipes appear at a random position on the right side and the background is a repeating pattern.

    All you have to do is move the bird up and down and you've got yourself an award winning game.

  • 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.

  • 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

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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?

  • infinite runner not example but it's template here it is

  • infinite runner not example but it's template here it is

    Apologies, you're quite right its a template.

    TMAJA ,

    My tutorial on ways of extending the above infinite runner template is here : https://www.scirra.com/tutorials/1019/bite-sized-game-development-adding-complexity-to-infinite-runners

    There is a good idea behind your method, usually in an infinite runner you either generate the objects after a certain time and at a certain position, sometimes randomly, but you're building the entire level right at the start and not generating it on the fly so I'm going to assume you want your objects to be always fixed in the same place every time the level is played.

    The bigger issue for me is if you have a pretty large level, there are going to be a lot of objects in the layout, that aren't visible on screen, but will still be impacting performance.

    I need to head out for an hour but this little discussion interests me so I'll come back and expand on it further, even if you don't require any more help.

  • 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

  • TMAJA that was not tutorial but, to guide you and inform you that it was not EXAMPLE but template. Scroll to you can use it but, it has it's own drawback. I would rather scroll the background and so on. For you my friend depend entirely up to your choice

  • 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!

  • 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!

  • 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!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)