{"action":"created","issue":{"url":"https://api.github.com/repos/HaxeFlixel/flixel/issues/1808","repository_url":"https://api.github.com/repos/HaxeFlixel/flixel","labels_url":"https://api.github.com/repos/HaxeFlixel/flixel/issues/1808/labels{/name}","comments_url":"https://api.github.com/repos/HaxeFlixel/flixel/issues/1808/comments","events_url":"https://api.github.com/repos/HaxeFlixel/flixel/issues/1808/events","html_url":"https://github.com/HaxeFlixel/flixel/issues/1808","id":147154127,"number":1808,"title":"Classic Physics: Slopes & Advanced Platforming","user":{"login":"nospoone","id":708588,"avatar_url":"https://avatars.githubusercontent.com/u/708588?v=3","gravatar_id":"","url":"https://api.github.com/users/nospoone","html_url":"https://github.com/nospoone","followers_url":"https://api.github.com/users/nospoone/followers","following_url":"https://api.github.com/users/nospoone/following{/other_user}","gists_url":"https://api.github.com/users/nospoone/gists{/gist_id}","starred_url":"https://api.github.com/users/nospoone/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nospoone/subscriptions","organizations_url":"https://api.github.com/users/nospoone/orgs","repos_url":"https://api.github.com/users/nospoone/repos","events_url":"https://api.github.com/users/nospoone/events{/privacy}","received_events_url":"https://api.github.com/users/nospoone/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":18,"created_at":"2016-04-09T19:05:43Z","updated_at":"2016-04-10T09:14:52Z","closed_at":null,"body":"I've been having this problem for a while, and I really think that having this built-in would benefit the community. @JoeCreates raised the issue in Slack, and I figured it was time to have a serious discussion about it.\r\n\r\n## The Problem\r\nFlixel's non-NAPE physics work well when you have simple level geometry, such as what `FlxTilemap` offers. Things however get hairy when you try to adding more \"advanced\" platformer level elements, such as slopes, one-way floors, or even one-way slopes. As we can see from the [FlxTilemapExt Demo](http://haxeflixel.com/demos/FlxTilemapExt/), it works but doesn't feel as good as it should. \r\n\r\n- When moving **up** a slope, the object seems to be going incredibly fast, as the distance you're travelling is greater than your horizontal speed.\r\n- When moving **down** a slope, the player should \"stick\" to the floor, and not float off it.\r\n- Hitting a **sloped ceiling** behaves weirdly: it shouldn't feel like you're going faster (related to the first point)\r\n\r\n## What's Expected\r\n@JoeCreates has (long ago, in FlashPunk) created a demo which displays how slopes are expected to behave. The red floating slope is a _one-way slope_ meaning that you can get in from the right side, but colliding properly on the left. Unrelated, but could also be implemented in `FlxTilemapExt`.\r\n\r\n- Going up the slope, the horizontal velocity should be **the same as walking on non-sloped terrain**;\r\n- This has to be implemented at the `FlxObject` level. _(e.g. not only for `FlxTilemapExt`)_;\r\n- Only convex, rectangular hitboxes have to be implemented, as classic Flixel physics don't support any other type of hitboxes (unless I'm mistaken);\r\n- Although I don't think this is required, rotated hitboxes would also collide properly;\r\n- All slope angles (from horizontal to vertical) should be supported.\r\n\r\n## Potential Solution(s)\r\nI am not qualified enough to dive into physics, but @larsiusprime and @Beeblerox have pointed out multiple resources that could potentially help:\r\n\r\n- N/N+/N++ tutorials: [Part A](http://www.metanetsoftware.com/technique/tutorialA.html) and [Part B](http://www.metanetsoftware.com/technique/tutorialB.html)\r\n- [Raigan](https://twitter.com/raiganburns) pointed out [Paul Firth's tutorials](http://www.wildbunny.co.uk/blog/category/platform-game/collision-detection-platform-game/)\r\n\r\n---\r\n#### Bounty\r\nI know this is a big issue and a lot to think about (and also that I probably don't understand the implications), but I am offering a small 100$ bounty for this issue to get implemented/fixed.\r\n\r\nThe bounty is payable upon verifying that the classic HaxeFlixel physics work properly with slopes (the What's Expected list works), and that I am satisfied with the results.\r\n\r\n---\r\n_(this is mostly a write up of a Slack conversation)_\r\ncc @JoeCreates @Beeblerox @larsiusprime \r\n\r\n<bountysource-plugin>\r\n---\r\nWant to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32782804-classic-physics-slopes-advanced-platforming?utm_campaign=plugin&utm_content=tracker%2F254189&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F254189&utm_medium=issues&utm_source=github).\r\n</bountysource-plugin>"},"comment":{"url":"https://api.github.com/repos/HaxeFlixel/flixel/issues/comments/207948810","html_url":"https://github.com/HaxeFlixel/flixel/issues/1808#issuecomment-207948810","issue_url":"https://api.github.com/repos/HaxeFlixel/flixel/issues/1808","id":207948810,"user":{"login":"Beeblerox","id":857406,"avatar_url":"https://avatars.githubusercontent.com/u/857406?v=3","gravatar_id":"","url":"https://api.github.com/users/Beeblerox","html_url":"https://github.com/Beeblerox","followers_url":"https://api.github.com/users/Beeblerox/followers","following_url":"https://api.github.com/users/Beeblerox/following{/other_user}","gists_url":"https://api.github.com/users/Beeblerox/gists{/gist_id}","starred_url":"https://api.github.com/users/Beeblerox/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Beeblerox/subscriptions","organizations_url":"https://api.github.com/users/Beeblerox/orgs","repos_url":"https://api.github.com/users/Beeblerox/repos","events_url":"https://api.github.com/users/Beeblerox/events{/privacy}","received_events_url":"https://api.github.com/users/Beeblerox/received_events","type":"User","site_admin":false},"created_at":"2016-04-10T09:14:52Z","updated_at":"2016-04-10T09:14:52Z","body":"@Gama11 i knew that you won't like it :)\r\ni know it's my fault that i've abandoned this project for a long time and hadn't made these changes before major 4.0 release.\r\nbut i just can't see another way to achieve that. i was thinking about project structure for a while (that's the only thing i could do in my free time) and there are two ways: \r\n1) we don't make major changes and engine will stay as we know it know, with known flaws (the main source of them is overusage of inheritance over composition). we still can fix minor flaws and bugs (for many of them i should be blamed, since i'm selftaught \"programmer\" and this was my way of learning things), but in the end it will stay the \"same\", with all of its childhood problems.\r\n2) we will make major reconstruction of it and it could become much \"better\" (imho) engine. \r\nWe can still maintain current architecture, like Phaser developers does. They maintain Phaser, but develop Lazer engine (which is the name of 3.0 version of the engine) at the same time, as they understand what things can be done with current codebase and what can't be done.\r\nThat's hard decision and it forced by my incompetence in programming area and lack of involvement in engine's development, but this is how i see it right now."}}