I know this is an old topic but I ran into the same problem today – and found a way around! So I may as well post it here, for what it's worth.

Because I make my game on my work computer most of the time (during lunch-time hey ), I felt I should keep it private as much as possible. So I decided to configure Construct 2 so that it would run the preview builds using Firefox (default on my system) in private mode (not default)... But soon noticed that adding a command-line parameter in Construct 2's "Custom browser" setting wouldn't work!? I tried tricking it to work using double quotes, to no end... Then I found a way. ^^

If you create a shortcut to the browser with Windows, and add the command-line parameter(s) in it, Construct 2 will accept it in the "Custom browser" setting. You will have to type the whole path and shortcut name in that text field though, as picking the shortcut with the "Open file" dialog won't work! So just type or copy-paste the path and name of the shortcut, preferably with no spaces in the name of the shortcut, and don't forget to add the ".lnk" extension.

It should then work and you'll be able to use whatever special commands you mean to use while previewing a Construct 2 project. That's it!

Hey, just a lazy post to say I like this a lot! Nice graphics and atmosphere, I'm guessing you know very well the games you're paying tribute to.

Very nice work, keep it up!

I did try a few more options (Construct 2's Physics, or the latest iteration of your collisions with pushable objects) but they never were that much better, and sometimes were difficult to implement (your latest demo uses objects families but those can't be used in the Free version of Construct 2, which I use – oops! ^^).

But for now it's working perfectly for what I need, and I got around to add touch control as well! Thanks again for your help, here and in other topics.

Thanks for your reply, R0J0hound!

I had already found some of your helpful posts and .capx files here and there but wasn't sure they'd suit my project. Turns out they do!

However for now I've been testing another of your solutions for colliding/sliding, the one named event_motion2.capx (https://www.scirra.com/forum/event-based-movements-amp-collisions_p719471?#p719471). I've had a bit of a hard time getting it to work in my project exactly as in yours, but I found out why: my player's sprite was 16x16 pixels scaled up to 128x128 and somehow it made collisions tighter or less tolerant... Anyway – I've changed my sprite for an actual 128x128 image displayed 1:1 (thus the collision polygon is 8 times bigger, and maybe 8 times more accurate?) and that did it! Now it's working as intended. The player collides with the walls but can slide sidewards a bit if it hits the extremity of a corner, and you can slide flawlessly along a wall that's already blocking you.

I've looked at your latest .capx (the one you pointed to above) but I'm not sure I should use that one. Does it always handle the player's sprite as a circle when it collides? More importantly, can the size/position of the circle (relatively to the sprite's image) be tweaked? Oh and lastly, how do you think both of your methods compare in terms of processing power?

Hello,

I'm making a top-down game using the 8Direction behavior and I'd like to make collisions a bit more tolerant around the corners. Is it possible to tweak the 8Direction behavior so that collisions under a "soft" angle do not stop the sprite at once?

I know I could achieve this using Physics but I'm not sure I should, as the rest of the game controls are pretty straightforward (I'm thinking performance here). I tried "cutting" the corners of my sprite's collision polygon, by making them 45° slopes instead of 90° angles, but it didn't change a thing (same result when I tried cutting corners from the solid tiles as well).

My goal is to keep simple collisions while allowing the sprite to slide a bit when it collides on the very corner of a tile.

... Yeah, that did it!! ^^

When I read your answer I thought you misunderstood my question, like it couldn't be that simple... Well in fact, you were right!

What misled me is the way these instances of my tilemap are managed by Construct. I thought they would either be handled as two independant entities all the time, or share the same behaviors and variables all the time. Turns out it's a bit of both!? I added the "solid" behavior to one of them only, but it was added to the other one as well without notice; if I then remove the behavior from one of them, it's removed from the other one too. However if I disable that behavior in one of the instances, it can remain enabled in the other one... See, this is what confused me. I just didn't think it would work that way !

Anyway, thanks a lot SoldjahBoy. I can move on – until next time! ^^

Hi,

I'm making a top-down game much like The Legend of Zelda and I'm not sure how I should design collisions.

Here's what I've done so far:

– import an image containing all my tiles;

– add a tilemap object to my layout;

– add an instance of that tilemap on layer 0;

– add another instance of that tilemap on layer 1;

– fill the tilemap on layer 0 with tiles that don't collide;

– place the tiles that do collide on the layer 1 tilemap;

– add the player's sprite on layer 1;

– add "solid" behavior to the tilemap instance on layer 1;

– add "8-direction" behavior to the player's sprite.

Now what happens is that my sprite can't move at all... unless I delete layer 0. Then and only then, the "8-direction" behavior acts as intended, the sprite moves and collides with the tiles on layer 1.

How can I keep the tilemap instance on layer 0 while having my sprite ignore it when it comes to collisions? I didn't set a "solid" behavior on that tilemap instance. But my guess is that Construct checks for collisions with that tilemap anyway, because it's an instance of the same tilemap object to begin with – thus the sprite being unable to move, as it's on top of / inside some tiles which aren't meant to collide with it.

So what should I do? I'm thinking of having two different tilemap objects, one used on layer 0 only and the other used on layer 1 only. They should be allowed to use the same image file no matter what, so I guess I won't end up with twice the same image in my project... Is that correct or did I miss something?

Thanks for your help!

Indeed! Well that sums it up... I think I'll go for less tiles x several layers. After all, performance matters at runtime but so does the time required to make and handle my tiles' graphics! And method #2 certainly would become a more complex task towards the end.

Thanks for your answer(s)! I'll come back and post some WIP stuff as soon as I make significant progress.

Hi, and thank you for your answer.

I'm not especially trying to build the whole game in one layout (actually it would be much better NOT to do that xD ). I just don't know how much having several layers per layout is a good or bad idea, performance-wise.

But here's a picture I've assembled, in order to explain myself better! This should help.

So in the first example, I would be using several layers per layout to build my map but this would allow me to use fewer tiles. In the second example, I would be using only one layer per layout to build my map but this would require more tiles to begin with.

This picture makes it simple but you can imagine how quick the number of tiles could grow (of course there will be many more) if I was to use a third ground color besides green and brown... Yet everything would be on one layer, so I don't know?

*bump*

Anyone?

I... guess I wasn't clear enough, then... ( ; _ ; )

Looks nice! I'll follow your project closely, it may prove very useful. Keep up the good work!