Ah okay. That makes sense and I kind of thought it was something like that. So I guess the only way to avoid that is to make a "pop up window" that is built into the game itself?

It needs to be there. Even if it did have the wrap property, destroying it off layer will prevent it from wrapping. If off layout doesn't work for you, try is not visible and see how that does. There's a few options for destroying it. If all else fails, wrap your layout in sprites that exist outside of the viewable layout, and have it destroy when it collides with them.

I have a pretty simple argument that I'm trying to implement, but for some reason, the way I have it now requires the player to click an additional time before the game is responsive again.

So an example, player single clicks on the reset button. The browser pops the window explaining that clicking reset again will erase all local storage. If a player clicks on any other button (or really anywhere inside of the game), the game does not register that input. If the player then clicks a second time (let's say on the reset button again) then the action will take place. Is this a functionality of using a browser pop up to display something to the player, or is something running a second time in the background that I am unaware of?

I actually don't see any code that states the bullet is destroyed off screen. Just the line that says it will destroy if it hits Enemy01. Do you have it somewhere else not visible in this screenshot?

If you're talking about split screen for multiplayer, there's an official tutorial on that: construct.net/en/tutorials/split-screen-construct-addons-2252

For your background: I'm not sure I fully understand what you are trying to achieve. The way I moved my background is by adding in my background image as a tiled background (not a sprite or regular background), and in my case, my background is always scrolling, so I set it to "Set image X offset to Self.ImageOffsetX-120 * dt", which makes it move to the left on its own at a set speed. You can accomplish something similar by tying this logic instead to the inputs to move the player and only move it when the player moves, if that's what you're looking for.

As for the on-screen UI, you just have to give the things you want to stay locked on the layout the Anchor behavior, and they won't move no matter where you move.

I'm really new to Construct 3, so my answer may not be the right one here, but for what it sounds like you're trying to achieve, I think you need to use the angles functions in order to make this work. So if your player's angle of movement is greater than 340 but less than 10 degrees (north-ish), you'd show the sprite that shows him facing upwards. Or some variation of that. Repeat for each angle group until you have the sprite facing the direction the player is expected to be going.

This is assuming that angles starts with 0 at true north, which I THINK it does, but I don't remember.

Just circling back to update you all: I was still having a ton of trouble with saving and loading high scores until I realized it wasn't the code about saving and loading, it was my own dumb fault for setting the global variable to 0 each time the game loaded. So no matter what the backend saved the score as, the player always saw 0. Whoops.

That being said, the core functionality of my game is done, and I've got navigatable menus (even though they are empty). I commissioned a guy to provide me with a few more assets (he worked on the originals too), so I will continue to code the rest as I wait for those, but I'm ridiculously excited to see this come to life. It may be simple, but I have learned so much already off just this one project. I can't wait to do more.

Thanks to everyone here for the help!

Ah; my globals had been setting static by default, so I was missing that it wasn't checked off for local variables. That worked by the way. It's still not *quite* the result I am looking for with my spawns, but it's a start. I think the spawning is honestly going to take up the majority of my time in figuring out because it needs to start out simplistic at first, and progressively get harder, and I'm not quite sure how to achieve that yet.

As an update, I have now moved to the paid version, as after the core game (which could have probably made it within 50 events), the rest would not, so now I'm just hammering away adding in things that I want to see in this game. It's shaping up to be quite a starter project in C3, but I'm learning so much. The tree sprite trick was super slick though. You'd never know any other way that it wasn't eight separate sprites for the eight tree formations I have.

Weird that I cannot edit. Sorry for the double post, but I attempted to try the code and, well, I think we might have miscalculated here LOL. I'm going to play around a bit and see what I come up with, but thought I'd share what ended up happening because it made me laugh.

Thanks again!