You can also try rex's Push Out of Solid behavior in combination with Solid behavior to make sure units don't overlap, although you'll have to make sure pathfinding is set to custom instead of solids.

The first example shouldn't be happening if the sprite object is on a layer below the UI layout. I would guess it's somehow getting moved, or created, on the same layer as the UI.

For the second example I would try to include a condition for the camera scrolling function that doesn't trigger it if the mouse is overlapping/dragging the window. I.e. "if click and drag + not dragging window -> move camera", This should stop the camera from scrolling if the window is being moved.

For the third example I'd try something similar to the second. "If button clicked + mouse not clicking window -> destroy window". This way if the button is obscured by the window, clicking in that area shouldn't push the button.

Well, I don't think it's precisely what you're after but you can try the Scroll effect by Somebody (towards the bottom of the first post). Though if this project is something for mobile it may not work.

You can try putting Destroy Outside Layout behavior for all the objects and simply have them start outside the layout on start. That way they will be immediately destroyed when you run the layout.

Not sure what you're asking in the second part though?

Are you changing the bullet speed through events? It stands to reason that if older monsters aren't affected by those events (e.g. if events only run for when a new monster is spawned) then they'll remain unchanged. Can't really say for certain without seeing how the events are set up, though.

Well, short of looking at your .capx to try and find it, I'd suggest plugging "speed" into the event sheet search box so it'll isolate any events to do with speed.

It sounds like the game might be treating the speed increase as a one-off event instead of continuous, so it'll increase the speed of one object, but as another one spawns it sets speed back to its original. Only guessing though.

If I'm understanding the situation correctly you can simply try using a variable or something to check which weapon is currently equipped, so if shoot+variable=1 -> shoot weapon type 1; if shoot+variable=2 -> shoot weapon type 2, etc.

An ambitious project indeed

1. I guess you'd have to ask every single C2 developer ever and see what their map sizes are! More realistically, just play around with the layout to see what works best for your project. I've had maps spanning ~20,000 pixels, which may have been overkill for my project. Also, unless you're shooting for one big continuous map, remember you can always have several layouts for different parts of the map to make the game world larger.

2. You can try using Pathfinder behavior to make zombies chase players around obstacles, and Line of Sight behavior to make it possible for the player to hide behind things.

3. Don't know unfortunately. You can try looking through http://opengameart.org/, see what they have.

Disabling rotation in the turret's setting shouldn't disable any of its other parameters, so it should still be tracking targets and counting down its shoot timer, etc. If I had to guess I'd say something else must be interfering with the behavior.

You can probably just recreate the Example: Lighting file but with your screen.

Basically, try setting the screen's blend mode to Destination Out, then make the layer the screen is on opaque and turn on Force Own Textures for it.

Am I understanding currently that the ball merges with the hill when it tries to go back up? Can rex's Push Out of Solid behavior possibly be used as a quick fix in this situation, if you were to designate the hill as solid?

You can try using Pin behavior to make the sprites trail each other, then turning on their own locomotor when the sprite they were pinned to is destroyed.