It's looking good, — keep it up!

Here are two shots from Courier, which is now Greenlit! A hallway and dorm in the Academy:

Yeah, that looks pretty similar. Here's a screenshot of the event sheet: (relatively large image). I simplified things somewhat from how you had it, particularly the start of layout event and the "every tick" one at the bottom. I also changed the values applied by the buttons just for ease of testing.

So in case Anon's response wasn't clear for how to do that, you should set the bar's width to (current health/max health)*maximum length. You can also get fancy and use lerp or some other operation to make it smoothly change there. So, for instance,

Set width to lerp(self.width, (current health/max health)*maximum length, 5*dt) where 5 would generally change how quickly it gets there.

I've attached a quick example of how to do it. I changed the green bar to a Tiled Background object so that it won't get the blurred edges you get from stretching out a sprite.

[attachment=0:3hxpbx18][/attachment:3hxpbx18]

Here's one way of doing it. It's a capx of basically what I explained in my last post. It doesn't look layer-y to me, though I did use a few layers just to enhance things a little. I don't see any performance issues with it, either. The movement is based on a global asteroid speed and is inversely relative to the camera movement.

[attachment=0:1f5dbnol][/attachment:1f5dbnol]

I hope that helps.

I haven't tested this, it's just off the top of my head. I love parallax layers, but what you're trying to do doesn't seem suited to them (maybe a few only). I think you should have a private variable ("multiplier") for your asteroids that defaults to 1. At runtime, spawn them off-screen and assign each "multiplier" variable with a random value between 0.5 and 2. Then, based on movement of the camera, move them in the opposite direction and multiply it by that the "multiplier" variable. It would likely need some tweaks, but essentially this would give them a range of movement of half through double their base speed. So assigning them to three or four parallax layers + doing the movement multiplication may work nicely.

I thought I'd go ahead and mention that Courier has been greenlit!

Reshay

That looks fantastic! I hope you have some smooth animations to go with that killer art style!

Tons of great games here Can´t wait to try C-7 s, it looks absolutely huge!

Hey, thanks! It is getting quite large...

Oh, why not? Here's part of a town I'm building for Courier. I don't have the NPC's in yet and I don't have all of the street objects placed, but the rest is built!

And, for fun, a zoomed out version without clouds and light rays:

> blah blah

>

This seems like exactly what I need! Though how does the player.X>enemy.X+threshold work in event sheet? (Sorry if I am being tedious I am just trying to learn new things in construct 2 which could hopefully help me later.)

The bullet behavior example would certainly work. Here's the same thing done with 8 direction (I limited it to 45 degree movement intervals, but you can do what you want, of course).

[attachment=0:30flhqrd][/attachment:30flhqrd]

I actually do something similar for touch controls using 8 direction. Same principle.

Pick a threshold (it will be an imaginary bounding box) for how close the enemies can get to the player. Say, if they get within 40 pixels of the player, they stop progressing. Otherwise, they keep moving.

This is simple to set up. In this case, we decided threshold = 40.

If player.X>enemy.X+threshold, simulate control "move right" for enemy.

If player.X< enemy.X-threshold, simulate control "move left" for enemy.

If player.Y>enemy.Y+threshold, simulate control "move down" for enemy.

If player.Y<enemy.Y-threshold, simulate control "move up" for enemy.

It will then move up, down, left, right, and any combination of those directions until it is within your threshold (40 pixels here). That way, they won't bunch up and overlap the player. You can have whatever offset you want.

As far as I'm aware, the issue is more with the editor limiting how many icons can be viewed due to windows. Every object has 3 icons (small, med, large) for use in the IDE. So multiple frames within the same object should not be a problem at all. But around 3,000 unique objects and you may start running into problems. So it isn't frames, but images that the editor must display. Disabling the icon cache under Misc. should fix it, though.