You must be thinking very highly of your coding skills if you think an engine you write all by yourself, even though it seems you hardly have any experience, is going to be more "stable" than well tested engines that many experienced people have been working on.
I'm not suggesting you should use one, but your reasoning for why you don't seems questionable. Especially, since the very thing you are afraid of happening with premade engines is already happening in yours (i.e. randomly falling through the floor etc).
Thanks @Derakon for adding his input, I agree. Somehow I got the impression that henke was trying to create a widely reusable, generic platforming engine. If you got the whole game planned out already, you can take many shortcuts. Although, I'd at least add comments inside the code that express the silent assumptions that it makes. (f.e. the player's speed can't exceed M, so maxSpeed must never be changed by anybody touching the code, and that walls can't be thinner than N)
As a project grows, even if you are the only coder, I think you'll come to find these kinds of comments helpful.
I still cringe at changing the player's coordinates before applying collision detection (I know you haven't been arguing against that). I think it's very bad practice. Since henke hasn't replied, I'll assume the worst case that he silently disagrees. Maybe this will make it more apparent why it's such a red flag to me. I read the code somewhat like this:
protected function xMovement():void {
horizontalControl();
//cap the speed
if(player.xSpeed>maxXSpeed) { player.xSpeed=maxXSpeed; }
else if(player.xSpeed< -maxXSpeed) { player.xSpeed= -maxXSpeed; }
if(autoMirror) {
if(player.xSpeed<0>0) {
player.char.scaleX=1;
}
}
player.x+=player.xSpeed;
//WARNING! Under no circumstances must any other method be called between these lines
//player.x may not actually be the player's x until applyCollisions returns!
player.applyCollisions(true,false);
}
....
playerInternal function applyCollisions(xDir:Boolean,yDir:Boolean):void {
//WARNING! Every method called by applyCollisions must not assume that player.x is actually the player's x or that player.y is actually the player's y
//It might be that they indicate the player is inside a wall even though he/she/it actually isn't
It just begs for it to eventually introduce bugs.
For example, you can't even call player.isUnderWater()* which returns true if player.x and player.y correspond to coordinates that are under water during applyCollisions, unless the wall he/she/it might be temporarily inside of knows it's an underwater wall. (An exception is if water can only be at sea level and there can be no individual pools of water above that, but I hope you get the point). Do yourself a favor and don't write code like this. If you do stuff like that in more than one place, chances are you're going to have a very hard time. I think that's all I'll have to say. Good luck.
*) Of course this method shouldn't really be part of the player object anyway. Just for the sake of illustration.
