You can't click on Watch right there next to Inspect in the free version? Regardless, just make a text object that is updated to show fps and cpu utilization (both are system values) and skip the debugger all together. That will give you more realistic data. My game regularly uses 20+ layers, multiples of them with opacity/shaders/force own texture, all of the layers have a lot of images, and my performance is fine outside of the Inspect tab of the debugger (understandably so).

I thought I'd give it a test too just for more results.

With the layer: 60 fps, 11% cpu

Withou the layer: 60fps, 3% cpu

And adding more layers can slow it to a crawl.

The problem, however, is the actual debugger. Switch over to the "Watch" tab in the debugger instead of "Inspect". I can have 30 layers added onto your project and not exceed 1% CPU use. The Inspect tab keeps track of a lot of stuff. It's meant for really detailed display of everything going on under the hood, whereas Watch is a bit closer to an actual gameplay environment. I use Inspect to pick the variables and values I want to watch (with the eyeball) and then just check that stuff in Watch so not everything needs to be accounted for.

Fore reference, Core i7-4770 3.4 GHz, NVidia GT 640 4GB, 32 GB Ram. This was Chrome on Windows 10.

I don't know about one compute vs another, but don't worry--you're not the only one who must run their project with the cache unticked I can open it last I tried, but it will soon run into massive problems. The downside is the editor is slower without the cache, but that's still quicker than reloading regularly.

It's a little tough following what you're doing without at least a screenshot of your events, but I would give each music track a tag called object.animationframe. Then I believe you could use the inverse of is tag=object.animation frame to mute all of the others.

Unique just means individuals and excludes repeat visits.

R0J0hound Thank you so much for the update! It does everything I could have hoped for darn-near flawlessly! It was pretty easy to integrate into my game, though I had to change one thing to make it properly recognize objects with a negative width or height--just set boxWidth and boxHeight to abs(wall.width) and abs(wall.height). The new example with pushing stuff around looks amazing too! I wish that is what the built-in collision engine did!

Gearworkdragon I would store the X/Y position of the enemy in something like target variables. Then you can do attacks toward that position and not worry about picking. It's gonna take a lot of testing, debugging, and stepping through to make sure all of your logic flows correctly, but you should end up with a nice system at the end if you follow it through!

I guess I don't have the specific answer to your individual problems, but I think the problem lies in your system anyways. You need to look up a little bit of what a state machine is. I'd actually recommend pulling out some paper and a pencil and draw a flow chart for how your battle system should work. Take things like speed (attack order), secondary attacks, multi-turn attacks, and specials into account.

So it should start with if the battle is one or off, of course. Please don't use booleans for this, though. Use numbers to increase your flexibility (like if you want global changes later).

Battle = 1.

Then you need to decide whose turn is next. If you're using an ATB (active time battle) system then you would let players choose attacks once their bar is full (a state) then add them to a queue (probably an array) of attacks. If you're doing it true turn-based, then skip the ready bar and put everybody in an attack order/ready queue. If you're doing it speed-based, re-order the list by player speed every turn (in case you use abilities that increase or decrease speed). I don't know if you're doing all the good guys go and then all the enemies go or if it's more organic, but if you're doing it one side then then the other, use two lists and a state to switch between them.

Then, you can use the coordinates in your list to decide clearly mark who is attacking and who is not. You should have something like 'is attacking" for all of your players and turn that off at the end of a character's turn. When their turn is started (probably called with a function), turn their attacking condition on so you can do necessary UI changes and then each attack is a function. The parameters should be the target, damage, modifiers, etc. You should also include which character is performing the function/attack so you can use the same code for multiple characters.

It's really complex, but plan it all out on paper exactly how things will work, keeping functions, arrays, possibly the dictionary object all in mind. Then, it's much easier to wrap your head around how to set up your state machine so it can run itself based on your values in battles.

HZGaming

Ah, sorry. I didn't see any mention of control type--had no way to know you were talking about touch. Most games I've seen that require constant dual-analog use automate the rest. Like the character automatically fires their weapon, you just have to aim. So make firing automatic. As far as environmental interaction, I don't think that's so awful to have the player stop momentarily for that, depending on how often you do it. Or you could make everything trigger automatically in some elegant way.

For a dual-sick setup, typically the shoulder buttons are primarily used with the sticks. The face buttons would only be used in the instance of special functions that aren't always done.

I think the center of your viewport in the editor is the same as the center of your view on the game window, so that should help a LITTLE with lining things up. I dunno, perfect alignment hasn't been important for my game so far.