I'll avoid using these in my project for now, but there's clearly something weird going on beyond just brute-forcing the collisions. In the example capX there is only one sprite object and around 100 tiles, but it's running over 600 checks per tic.

So either the tiles in the tilemap are checking against themselves, or they're checking against the single sprite object six times. Either way, something is off?

I'll avoid using these in my project for now, but it still doesn't seem like the current behavior is working quite right.

Link to .capx file (required! If link is blocked remove the http and www parts):

dl.dropboxusercontent.com/u/23075162/TileCollisionExample.capx

Steps to reproduce:

1. Make a tilemap with the solid behavior, and a single square object with platform behavior.

2. Create some tiles as terrain, and give the tile you are using a custom collision poly (I used a smaller rectangle.)

3. Run the game in debug mode.

Observed result:

The collision count in the debugger gets extremely high, over 50,000 collisions per second while moving, and ~8000 while still. It is registering over 600 collision tests per tic, when there is only one object for the tilemap to test against. The tilemap may be trying to collide with itself?

Expected result:

The collision count should be much lower - when not using a custom poly for the tile, it sits at around 67/tic.

Browsers affected:

Chrome: yes

Firefox: yes

Operating system & service pack:

Windows 7 64-bit

Construct 2 version:

R160.2

This is mostly an issue with the Solid behavior, rather than collisions in general. Each Solid should keep a list of objects it can act on, with every object on the list by default. That feature would be a huge boon for some tasks.

Just a note, I have a grid of 32x32 sized tiles and if I edit the collision polys to 1 pixel smaller than the actual tiles themselves them seem to register collisions with each other and cause a massive spike collision checking.

Hope it helps :)

I haven't had a chance to send the fixed CapX, but my tiles are set up exactly the same way. Their collision boxes are all rectangles, but smaller than the tile size itself.

Make a "CreateGUI" function and call it at the start of each layout where you'll want to use the GUI. Have it create (non-global) instances of the GUI buttons and position them as needed. Only create the buttons with this function.

Much easier than messing with global objects, in my experience.

lucid, regarding the importing you may also want to check for cases where the .scml or .scon file has its name changed before being reimported, or the spriter object in C2 has its name changed. I found some very odd behavior around that: I would have expected it to either recognize the name change and update accordingly, or see itself as a new spriter object and import fresh instead of updating. Instead it seemed to get confused and ended up deleting a bunch of my events.

I understand you are busy with the program itself, just something to look at when you get time.

You'll want to use a few variables for this. One that shows what your last attack was, and a couple to act as timers. When you press the button to attack, check the state of the attack variables and do the logic accordingly.

So if you press the button with all the variables at 0, it will do the first attack and increment the variable that tracks what your last attack was, then start running down a short timer variable. If they attack while the last attack variable is 1 and before the timer is up, play the second attack and reset the timer. Then do the same for the third. This will let you combo attacks together, while reverting you back to the first attack if you don't attack for too long.

It can be a bit complicated, so if you aren't used to using variables you may want to read up on them a bit, and try to keep it simple at first. Maybe start by just implementing a single variable that increases by one with each attack, and plays a different attack animation based on its state.

For making only a certain part of the attack hit the enemy, you'll want to spawn a separate "hitbox" object, an invisible rectangle that overlaps with the sword but not with the rest of the enemy. Give the hitbox a lifespan variable so it doesn't stay around after the animation, or just remove it when the animation ends. You can even change the size and positioning of the hitbox to match the sword in different animation frames, though that gets more complicated.

If your animations aren't centered well, you want to change the hotspot, which is in the animation editor. It decides what point the animation is "centered" around, so you'll generally want it to be in a consistent place on the character.

— lucid

Can you guys make a tutorial on how to "refresh" or "update" the scml and scon files in C2 THE PROPER WAY?

Do I have to delete all related obsolete scml,scon and the sprites everytime I want to update my scml/scon files? Because this is what I have been doing for quite sometime and it's getting on my nerve... <img src="smileys/smiley7.gif" border="0" align="middle" />

I always got into a mess whenever I updated my scml files. Anybody got a better way of doing it?

Not sure if it is just me or everybody else don't update scml files as frequent as I am...

Please help TQ

For changes that don't involve adding/changing the sprite images themselves, you can just remove the .scon and .scml files from the C2 project and reimport the latest versions. Much faster.

So my game has about 40K-80K collisions per second, according to the debugger. Almost all of that comes directly from the tilemaps used to build my levels: if I remove the tilemaps, that number goes down to 300 or so. My tiles are 32x32, and my level is 5120x3072, with lots of terrain.

Since I'd like to be able to make larger levels in the future, are there any ways to optimize tilemaps? Disabling collisions for tilemaps that are a certain distance from the player seems like the most basic approach, but the Tilemap object doesn't actually seem to include any way to disable collisions.

I have implemented every one of these elements in C2 Projects. You may need to spend some time getting used to the event-based language, but it's quite powerful once you know what you're doing.

Comparing it to GM, I've found some things to be easier, and some to be harder. A lot of it probably comes down to preference in the end, but C2 is capable of making complex games if that's what you want to do.

Having a separate red sprite is okay, but if your ships are too big and complex it's going to be a lot of extra video memory, since each ship would represent a separate set of textures.

I would probably try to do this with effects. A Tint effect that starts at 100,100,100 but lowers its green and blue parameter each time the ship is damaged seems like it would do something like what you want?

As for your current method, it will be easier if you use containers and a pin behavior. Put the red ship into a container with the regular ship (this will cause both objects to be created/destroyed/picked whenever one of them is.) You can read about containers here if you haven't used them.

Give the red ship a pin behavior. Then do events similar to this:

On Ship Created -> RedShip Pin To Object: Ship.

On Ship Damaged -> RedShip set opacity as needed

Disabling collisions for the background object when it isn't in use should do basically what you want. If you have events that don't trigger on collisions, you'll need to disable those too.