You can change the layout scale over time.

Every tick->Set layoutscale to lerp(layoutscale, target, 5*DT)

Target is the layout scale you're shooting for.

Alternately, you could also add or subtract to it over time until a certain condition is meet.

If layoutscale >0.5 ---> set layoutscale to layoutscale-0.2*DT

Meaning it will subtract 0.2 gradually per second until it reaches about 0.5.

>

> I ran experiments with bouncing most of those terrain objects down to paster objects at the start of the layout. It turned out to be far less efficient than just multiple instances of the same objects (which are never checked for collision). It also takes a huge hit to the vram. A tilemap would either lack the diversity or require a significantly higher amount of work. If I put in the time to do all that, and it has that many possible outcomes, though, it actually seems as though it might be heading more intro the realm of huge vram consumption like the paster objects.

>

> So I fully understand it looks strange to use so many instances, but I don't see any better solution in C2 and it has an almost negligible impact on performance so long as I'm not targeting mobile (where fillrate would be the problem).

>

I like your method how you making the levels, but how big is the layout?

for example you can use a tilemap (without any collision, just for design) to make some graphics and reduce the instance of the level... it's hard to make the combination with a tilemap, but you can also make 2,3 or more tilemap with different texture and mix together

It would still be extremely limiting to try to make it work into the rest of the game. Even though there are more objects overall with my method, that cliff only took like one frame and then a circle to mask the edges. It only needs to be done for things that aren't straight anyways or to at times give variety to the ground. The level in the demonstration is I think 4,000x3,000 pixels, so I'm quite happy with the object count.

rexrainbow Thanks! I'm more looking at it as a less-limited way to use tiles, really. So most things are made of just big tiled background objects (walls, grass, dirt, etc), sometimes with some masking. I do have a few gigantic layouts that push the object count up quite a bit, but it's never really all on-screen at the same time and I have graphics settings in the menus of the game for users to disable (remove) things like swaying grass and to stop leaves and trees from swaying among other things. It really works surprisingly well, and any other method I've tested would either limit how it looks or crank the vram up considerably.

>

> > I added a new feature today about mapping! See some of my C2 workflow:

> > [saving space]

> >

> > How many objects in this layout demo at last?

> > ( I guess that it might more than 10,000. )

> >

>

> yes, I see a lot of instance placed for making the terrain... I would use tilemap for this kind of work, that would be difficult to make all combination for the tilemap, but the result could be almost the same...

>

rexrainbow and Ribis

Nothing of the sort. 1,287 objects on the layout after adding a little more after that video was recorded (and 40 MB vram).

Those reasons for not using a tilemap are precisely why I didn't. It would be a much higher workload with potentially inferior results and for a negligible performance increase. Sitting still, I'm at 14% cpu and 60 fps with all of the game systems running. Moving adds z-sorting, dust kick-up from the player, and a few other things so it does increase to about 19-20% cpu then.

I ran experiments with bouncing most of those terrain objects down to paster objects at the start of the layout. It turned out to be far less efficient than just multiple instances of the same objects (which are never checked for collision). It also takes a huge hit to the vram. A tilemap would either lack the diversity or require a significantly higher amount of work. If I put in the time to do all that, and it has that many possible outcomes, though, it actually seems as though it might be heading more intro the realm of huge vram consumption like the paster objects.

So I fully understand it looks strange to use so many instances, but I don't see any better solution in C2 and it has an almost negligible impact on performance so long as I'm not targeting mobile (where fillrate would be the problem).

This looks familiar? Not the idea of the Courier, but the game play mechanics of another C2 game. But I don't think that was ever released. Did you ever post prototype vids of another game you were working on? Anyway, nonetheless, it's lookin good!

Nope, I've never posted anything quite like this except for this game (which has been in development here a long time). I haven't really seen a whole ton of C2 games like this at all, actually. Arima used to have an RPG he was doing, and then I think wrangler has a pixel art top-down game. Those are the closest I'm aware of.

Great video series, some nice advanced tips for other devs to learn.

Thanks a bunch! One of the next ones I think is going to get into a bit more of the nitty gritty of how the systems with together. I just need to make sure it stays interesting for the non-devs too.

HR78 Thanks for the feedback! The character goes through lots of environments, so they're naturally going to look a little different relative to each environment. But make no mistake, it's all 2D hand-drawn stuff.

Here's a new video feature! This one's about the start of the game and the early story elements. You get to see a lot of in-depth segments that I haven't shown otherwise, so check it out!

I have a third video feature on Courier showing the start of the game and the beginning of the story!

I've got a new feature video out! This one you get to see an early (and in-development) look at how the game begins and the start of the story. This is probably one of the biggest looks at the game yet, so check it out!

I think you're misunderstanding what the solid behavior does. You don't need it on your sprite object to begin with--8 direction already interacts with solid objects. So you OTHER objects (think of boundaries) should have the solid behavior. These are what you use to define where the player can or can't move.

You haven't given us any details with which to work, but the most likely culprits are you have changed their size (stretched) them on the layout, you are scaling the game window (thus stretching it inadvertantly), or you aren't snapping to any sort of grid so the position might be on a subpixels (make sure the position of the object didn't have and decimals). Beyond those, there's no way to guess, so possibly provide a capx so we can quickly see what's up.

Check your drivers and check to make sure you don't have a TON of objects in your project (if so, go to Preferences and uncheck the item cache).

That was a ton of fun! I just had a video chat with and met one of my patrons from Patreon. It's a nice boost seeing somebody from across the world happy with what I'm making and asking questions because it's inspired them. Watching people play my game at public events, watching my son excitedly playing my game, and now talking face to face with a fan from another continent are definite highlights to the development process.

Aaaand just a heads up, I'll be releasing a new video this week showing off something else from Courier!

(link: Patreon)