Best practices for building levels

0 favourites
  • 14 posts
From the Asset Store
Buildings - Isometric view - PNG transparent - multi styles, multi fonctions buildings
  • I'm getting ready to build my first real level, so I thought it would be a good idea to figure out some do's and don'ts.

    I've searched for this info on the forum, but most posts were of older versions, so I don't know what's changed. I also thought some answers were a bit vague, so I want to make sure I get things cleared up.

    Let's assume that we are making a fairly large level, and we need to fill it up. Maybe we'll target a standard resolution of maybe 720p, but our layout needs to be big enough to provide a worthwhile level for a platformer, so at least maybe 3000 to 4000 px or more.

    Now, we want the level to look as good as we can, but at the same time not need a supercomputer to run well. We might even want to put it on mobile platforms as well.

    Here is a chart showing some ways to fill the level. The numbers are just placeholders for example purposes.

    A: we could fill the entire level with a sky, maybe just use a single color and using a tiled background.

    B: we could fill areas with single color tiled backgrounds that are a bit smaller

    C: we could fill large to medium sized areas with fancy tiled background for areas we want detail

    D: we could make a bunch of individual sprites to fill the areas

    E: we could make a bunch of sprites but each one would use an animation frame (like the platformer tutorial I read on here).

    F: we could use background tiles that are various sizes broken down into chunks and then placed side by side

    G: we could use sprites that are various sizes broken down into chunks and then placed side by side

    H: we could use moderate sized tiled backgrounds like 500px by 500px

    I: we could use moderate sized sprites like 500px by 500px

    So, I mean we have a lot of choices for what we use to fill out the level. On one hand, we can end up with a lot of objects if we use smaller sprites. On the other hand, we can have fewer objects but larger images to work with.

    I figure we will use a combination of sizes. I just need to find out what the limitations are so I know what will break the game and make it run poorly.

    I've read warnings about using too many objects and warnings about using too large objects. I'm trying to figure out where the best comprise is before I start working hard on detailed artwork.

  • Depending on how much detail you want a small tile for the blue (or tall thin tile if you want your sky to have a gradient for sunset, etc..) then add other sprites on top of it for clouds, etc... nothing too large that would fill up the whole layout. You put enough layers of objects to fill up the screen about 3 times over and you blow out the memory on most mobile devices...

  • the small one would be a tiled background of course

  • my platformer/runner levels are usually 20,000 or more in width and about 1300 or so in height..

  • It all really depends on what you want to do. Usually, breaking things up into smaller parts is a bad idea, unless your image is larger than 2048x2048.

    If you want to go with the detailed image, just put the whole thing into a tiled background and leave it as-is (unless it's larger than 2048x2048 pixels, but to save VRAM it should be much smaller anyway).

    If not, then just go with the simple one.

  • Okay, so it seems that larger (but not too large) images are the way to go.

    I am going to have multiple layers so I can get some parallax effects.

    I wouldn't really need anything to fill the entire layout since there will be some variation.

    Can we go by the numbers that Construct gives us? Like if it says it is using x amount of memory, can we know if we are safe or not?

    I can make a game look nice, my main concern is just making sure it will run. I'm just trying to plan ahead a little bit.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Unity3D extension is called 2D toolkit is capable to cut the big image into pieces of dice (128x128) by one click

  • DrewMelton

    "We're working on a brand new tilemap editor for Construct 2, with support for importing TMX maps. Keep an eye out for the next beta coming soon!" -Scirra on facebook

    i think you should wait a little bit to see how this tile map editor works and suit your needs

    but on the go, what you have to keep in mind(i think) is to plan your game objects first:

    -colision objects

    -background

    -platforms

    -animated stuff

    -characters

    my first game test cant run on mobile devices, because i made it with a lot of isolated sprites and it crash as soon you run it

    i dont know what kind of game you are making or the platform you looking for, but if your game need big places, try to break it in sections, levels, screens...

    i dont know if it helps because this is a very simple proj and it cant be use to measure how it will impact a full game, but this is how i did with a jam game a time ago:

    <img src="http://fc07.deviantart.net/fs71/f/2013/304/3/2/screen_by_valdarko-d6sh7fp.png" border="0" />

  • You really shouldn't use the tiled background object for filling the screen with a single color.

    You should either of the following:

    use the background parameter (in layer properties) to fill the screen with the color you want

    create a layer that doesn't scroll (don't remember how exactly, might have something to do with parallax settings (0?)), have a 1x1 pixel image of the color you want added to it, then stretch it to your screen size (point sampling might give you better results)

    And contrary to the beliefs of the guys here, i'd say that you should go with slicing up your image into smaller parts, here's why:

    i read on one of the threads you can find here that the objects that are off-screen are not drawn, therefore don't take up some of the time needed for rendering a frame (however the images are still in memory, so there's that), which means that if only a certain part of your whole level will be visible at a time, the images that are off-screen won't take up the systems' resources and you should, in theory, have better performance than if you just used a single huge image. Or something... /speculation

    Using a plain color background would still be faster than using a sprite... :/

    If you'd like to know more about the performance optimization, i made a thread recently, where i asked for feedback from others on my views, but it appears that it's gotten buried now.

    Here it is: scirra.com/forum/optimizing-a-game-for-mobile-platforms-your-tips_topic78778.html

  • Thanks, I'm going to do some experiments tonight and see what I can figure out. I'll report back soon.

    The game will be similar to Castlevania. It will be combat focused and somewhat difficult, so I don't need huge levels. I just want to make them look good, and not find out that it won't run at all on cell phones. I mean, I guess releasing on Steam only or whatnot would be fine, but I'd like to have options.

    I'm also looking into a program called Spriter to see if that would help optimize animations for characters.

  • FYI. In the Project properties. You can set it to NOT DRAW background. If your going to fill the entire scene with your own images. Then don't bother filling the background with a draw call.

    It hurts mobile performance to waste the render since most mobile for C2 is render by pixel amount. As a suggest think of the situation like this. if you can draw 3 times the screen resolution. Then rendering a coloured background is 1/3 of your render allocation. Not only that it's 1/3 you never see since then you cover it with images.

    Also for rendering large sprites for backgrounds. make sure your images are not larger than the render speed. As someone pointed out that 2024x2024. however make sure your mobile targeted device supports that. You might find it's only 1024x1024 and then your hurting for rendering images too large still.

    However for whatever you target on your mobile device will just burn through on a desktop. So while rendering 1024x1024 is your target for mobeil(don't qoute me that as truth. This is just theory) is great. The desktop will just eat that up and no effective loss of performance. As performance is so much more anyways.

    TEST ON MOBILE. Every notable change. TEST ON MOBILe.

  • I need to get my pc set up to allow me to test on my cell phone. I may have to uninstall Zonealarm firewall. It may have been causing problems.

    My main thing for now though is just at least making sure it runs on pc's pretty well. But to be safe, I'd like to at least test a little on mobile.

    My phone is a Nokia Lumia 920.

    I just got Spriter. It's hard to decide what to focus on when everyone keeps announcing updates.

    I think I will go ahead and do my main character. I had planned to spend the rest of the month doing the rest of the characters in the game, and then next month doing the levels.

    jayderyu, as far as not filling the background I have it set to "clear background: no" I don't know if that's what you meant or not.

  • After doing some experimenting, here are a couple things I've noticed (possibly).

    1. Image size is more important than sprite size. In other words, a small 100px image enlarged to 500px in C2 is better than a simply using a 500px image.

    2. Copying and pasting a sprite does not seem to add to memory use, but does add to object count. So, we should still be careful how many objects we use even if they are the same sprite copied and pasted.

    Does this seem correct?

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