Keep player in level

(Nate ) #21

This seems to have worked to an extent, the issue I am having now is… if the player is less than 10 or -10 away from the level the player still gets bumped outside of the level D: so it isn’t a cure all but it is partially working!

(azrafe7) #22

Glad to know there’s progress so far, but…

I get you’re having a bad time trying to solve it. And trust me when I say that is not easy for us to help you, given the few hints we’ve gathered so far. Please don’t take it bad, it’s only that shooting in the dark hoping to second-guess how to the exactly solve your issue is utopic. We need more information about how you laid out things, we need to look at your code to be helpful.

SWF + full code! Deal?

(PS: I’m aware that you can have concerns about giving away your code. It’s legit. But I imagine your game it’s still in its embryo stage, your finished product will be far more complex than where it is now. So don’t be too afraid to share it… or, if you still do, post a minimal example replicating the problem or PM someone of us)

Also… _sleeping over it can do wonders_™ :smile:

(Nate ) #23

I totally understand, yea nothing about this project is under lock and key. I partnered with someone who is focusing on story boarding as well as all graphical elements and I am developing his idea. I know we spoke of a non-disclosure agreement, but that would be more for the games concept and story, etc.

Yes, the game is still very much in the embryo stages, and right now I am just working on the core mechanics of the project. The issue I am having seems to be a fundamental one. The player is not supposed to EVER leave the level. The only code relevant to the issue I have posted here already, if I get permission to post the SWF (containing some of his artwork) then I will do so for a better understanding of the issue. If posting the SWF is an issue, I can code up a demo project with the same issue and post that SWF here.

Thanks again for the help azrafe! And everyone else who has partaken in this thread.

(azrafe7) #24

Yes, please post a little example (I mean a compilable project here) showing the issue (no need to include art assets, you can use placeholders for that. And by the way just setting the hitboxes to the same ones your game is using will do).

Let’s solve this! :smirk:

(Nate ) #25

Okay here is the problem in SWF form lol

A,D or left/right arrow keys to move, SPACE to jump and click to shoot!

The red blocks you can shoot to destroy, the purple block is a switch which can be interacted with by colliding with it and pressing E OR shooting it.

To the right of the wall of red blocks, place the character against the wall and let an enemy hit you, you will see the problem when you do this!

demo.swf (122.0 KB)

(Zachary Lewis) #26

It looks like you’re not properly handling your collision. If the player is ever in collision with something, resolve the collision fully and place him outside of it.

I’m sure I have an animated gif around here somewhere…

(Nate ) #27

This is really all I am doing for the player collision:

moveBy(xSpeed, ySpeed, ["level"]);

Which I realize now is not really collision code… but what exactly would be?

(Nate ) #28

Bump, Zach can you help me re-write my player collision?

Thank you!

(azrafe7) #29

From decompiling the swf you posted I can see you’re doing this in the player update():

...
if (collide("enemy", (x + 1), y))
{
	health = health - 7;
	this.moveBy(-20, 0, "level", true);
	this.moveBy(-20, 0, "destruct", true);
}
...

Which should probably be:

...
if (collide("enemy", (x + 1), y))
{
	health = health - 7;
	this.moveBy(-20, 0, ["level", "destruct"], true);
}
...

Not sure it’ll completely fix your issues, but should go in the right direction and that’s why I requested more code to start with. Can you please check with this small change and report back?

(Nate ) #30

Okay I changed that and it seems to have worked better. Why does putting them into one moveBy line make it work better?

(Jacob Albano) #31

Because calling moveBy() multiple times will move the entity multiple times. So what’s happening is that your guy is moved 20 pixels while avoiding collisions with “level”, and then 20 more while avoiding “destruct”.

The problem is that he ends up collided into “destruct” while avoiding “level”, or vice versa.

(azrafe7) #32

Using ["level", "destruct"] in one moveBy() instead of two, will check for collisions with those type at the same time. Having it on two separate calls will first try to move 20 pixels apart and halt if it hits a "level" and then try to move another 20 pixel halting on "destruct".

PS: I see you have another moveBy() at the end of update(), which could maybe cause problems.

PPS: I decompiled it to see how it worked internally, but couldn’t recompile it since I haven’t been able to recover the xml data you use for the level. If you can share full code+assets of that test project we can look into it further (if you still have issues).

(Nate ) #33

I see I see! Well the moveBy() at the end of my update function is how I was keeping the player inside of the level. Is there a better way to do that so I don’t have more than one moveBy?