The "right" way of doing backgrounds in C2?

0 favourites
From the Asset Store
Find pleasure in juggling balls with this basic HTML5 template
  • Hello all,

    I reached the point where I seriously need to start considering non-interactive backgrounds in my current project and I was wondering what would be the "right" way of doing nice looking multi-layered backgrounds in C2.

    Now, I've read quite a good deal of posts in the forums and from that I take away the following points:

    1) having huge images saved as backgrounds is not advisable, as this takes considerable computing resources (specially in mobile)...and it's really a brute-forcey way to go around.

    2) Full tilemap implementation is not available (it is implemented through sprites in 3rd party plugins though). The official tiled background object in C2 just allows you to define 1 tile and repeat it according to the size of the object.

    3) People usually point towards the way Rayman Origin builds its backgrounds. That is, repeating a lot of 'prop' sprites like trees and rocks and using size, color and other transformations to introduce variety

    So 3 seems the best way to go. Is there anyone who successfully implemented this method? If so I would like to ask him the following questions:

    a) Performance-wise, how heavy is it on PC and mobiles? Any disadvantage

    b) What special advantages does this method have? For example, if they are all sprites, can you animate some of them for added impact?

    c) Tips and Tricks for doing it right, limitations from C2, etc.

    Also, if anyone can also post their own success stories with this or other background methods (for example 3rd party or dynamically generated maybe) it would be extra nice :)

    Cheers and thanks in advance

  • Hi Alcemon,

    3 is the option to go with.

    Check this blog from Tom, (Scirra Developer) Don't Waste Memory

    It is good read and excellent information..

  • For Mortar Melon I learnt a few things along the way.

    One of the biggest things I found is that when you employ depth of field, out-of-focus imagery can be upscaled at no real visible loss of quality. This can save a lot of video memory and improve performance, but it leaves you in a difficult position as to whether use tiled backgrounds or upscaled sprites (as tiled backgrounds can't be scaled).

    I found that the more out of focus an image was, the more it made sense to not use a tiled background. However, when I got closer to the in-focus layers, then tiled backgrounds were more effective resource-wise.

    Hopefully this breakdown should illustrate my point.

    This is the complete layout for one of my desert levels:

    <img src="" border="0" />

    Here is my foreground layer. Whilst these sprites are some of the biggest on the screen, they're also the most out of focus and hence upscaled from smaller sprites without much deterioration in quality. The trunks that frame the image are tiled backgrounds because they extend dynamically to fit either very long or tall levels.

    <img src="" border="0" />

    This layer has one of the biggest sprites and because it's fully in-focus I couldn't scale up without a loss of quality, so it made sense to make it a tiled background. Normally I'd bake the pot into the tiled sprite but as it sometimes overlapped things awkwardly, I made it a separate sprite.

    <img src="" border="0" />

    Whilst the playground layer is typically made up of individual sprites, I created a separate wood tiled background so that I wasn't using hundreds of individual sprites to construct complex scaffolding. After implementing this optimisation I was often able to half my onscreen sprite count. This only works with non-physics objects (you can see the physics wood has a red tint).

    <img src="" border="0" />

    This layer uses a simple tiled background for the sand, and as the tree is out of focus it's scaled up.

    <img src="" border="0" />

    This is quite a large tiled image, but a lot of it becomes exposed on taller levels so was necessary. This would probably be better off as an upscaled sprite in hind-sight.

    <img src="" border="0" />

    As the parallax decreases over distance it made sense to upscale this as a sprite rather than use a tiled background. It's a seamless sprite so you can still paste it next to itself and it will tile for longer levels.

    <img src="" border="0" />

    Normally you could get away with a single upscaled sprite for the background here, but as I'm using my own scaling solution, the area above could become visible on narrow resolutions. I solved the problem by fading the background sprite into a dynamically sized tiled background.

    <img src="" border="0" />

    Final ingame shot:

    <img src="" border="0" />

  • thehen - wow, thanks for explaining your technique and showing those informative screenshots.

  • thehen : very interesting, and nice to share.

    I've done quite the same thing for my game, i would have just use 2 tiles sometimes instead of one, to have smaller ones, but it creates more objects, so i'm not sure what is better, i think it depends of the game or the device we target.

  • thehen

    It's probably worth copying and pasting everything you've just said and illustrated into a tutorial so it doesn't get lost, as that's some very clear and helpful advice.

  • more like a blog post "Making of The Mortar Melon"... nice post by the way.

  • I agree with Dave. A sticky would be nice for the great tips!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks everyone for the responses, this indeed will become a great reference.

    thehen About performance, how slow/fast is this setup for PC (and mobile if you have also tried)? Finally, how big in diskspace did your background resources end up being?

    Seems that this the way to go to achieve very polished medium to small levels. Maybe for larger levels (which is not my case for now) a tilemap based solution would be needed.

    Thanks again for the replies

  • Alcemon My whole game is 7mb, though I could probably get that down to 5mb if I fixed a few plugins so I could minify the script. Performance is great across the board - physics bottlenecks way before sprite count.

    I'll write my post up as a tutorial next week :)

  • Thanks a lot

  • thehen thanks for the explanation - very interesting

  • thehen Your graphics really are beautiful and your up-scaling of sprites to make them out of focus really is a revelation.

    The thing I don't understand is (and I read Tom's blog) that while using lots of small images saves a great deal of memory, doesn't it cause massive overdraw issues? How well does this method work on mobile, where it's best to keep to a 3-draw limit?

    If a background layer is overdrawn but stays static, is it redrawn every tick or held in memory as 1 image? Maybe Arima will be able to help answer this. Thanks

  • thehen,

    Really helpful explanation, with an upcoming tutorial to follow! Where the heck do you find the time to do it all? :)

    Nice work!

  • Nice info! Tutorial is a good idea.

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