Looking for a physics developer for a few days paid work

[rich]

Hi all,

 

I need someone to help me sort out the physics system inside Phaser. I've spent too long messing with it and it needs a fresh pair of eyes and some sensible suggestions on how to resolve it.

 

I'll need you to be available on Skype for a text-based chat (maybe voice if it becomes too complex to discuss via text), and I'll need you to have a couple of days free to be able to implement the fixes needed. It's all coded in TypeScript, but honestly if you're familiar with AS3 or JavaScript it won't make any difference to you - everything is simply high level work with vectors and math.

 

In short I'm trying to implement AABB and Circle collision against both other moving entities (with SAT separation) and also against tiles including concave/convex/22deg/45deg/etc slopes. It's mostly all working, but I need to fire some questions at you and tidy up some of the things it does to improve usability.

 

Ideally you'll have Visual Studio installed, but it's not a requirement. I would recommend either that or WebStorm though so you can dive through the code faster.

 

Happy to pay whatever your going-rate is, as I don't expect this sort of assistance for free, even though you will be benefiting the larger open-source community in the process

 

Drop me a line: [email protected]

[PKrawczynski]

You definitely should contact deltaluca - creator of nape,

http://deltaluca.me.uk/

 

His vast and deep knowledge of physics is pretty amazing.

[rich]

Here are a lot more details explaining exactly what is required:

 

Essentials

 

1) A Sprite has a body property. The developer should be able to set either a Rect or a Circle shape within the Body. The size of the body should be independent of the rendered sprite size (so they can create larger/smaller hit boxes) and be able to be offset from the sprite origin. To keep things simple for now a Sprite body will only ever contain one single Shape. A Body can be either "disabled" (nothing moves it, it doesn't affect anything). "kinematic" (passes on, but doesn't receive impacts) and "dynamic" (both passes on and responds to collision).

 

2) They can influence the motion of the Body (and thus the Sprite) through simple functions, ala Flixel. I.e. player.body.velocity.x = 100 would move the sprite horizontally at 100px/sec (when not factoring in drag or gravity). They should be able to set either velocity or acceleration (and a corresponding min/max velocity) and angularVelocity/Acceleration.

 

3) The Body should have: drag, bounce and gravity properties used in the motion/separation calculations (and anything else you feel is essential)

 

4) Body to Body collision. I was originally using a QuadTree to select the objects, then a Bounds check and then finally a separation pass on x and y to move them apart, taking their velocity/bounce/body types into account. This worked ok for AABB but falls over if you want to handle rotated collision. Eitherway it's important that bodies can collide and separate cleanly, regardless of axis or rotation.

 

5) Intelligent collision grouping / determination. Sprites can be placed into Groups, you should be able to collide Group vs. Group or Sprite vs. Group. I.e. minimise doing a full pass through every single sprite, every single frame. Groups can also be nested. Ideally some kind of world grid / quadtree could be used to minimise what is checked to the bare minimum.

 

6) Tilemap collision. There is a full tilemap system built into the framework already, but it's important that Sprites can collide with the tilemap and re-act to it (i.e. bounce off, slide, etc). The "essential" requirement would be that every tile is just a rectangle and the body collides with it on that basis. Under "nice to have" you'll find sloped tiles There needs to be an intelligent way to select which tiles are to be checked for collision. Originally I was taking the area around the sprite, grabbing the Tile data just in that area and then checking against each tile - it worked fine (you can see it running here http://gametest.mobi/phaser/index.php?f=map%20draw.js&d=tilemap use the mouse to draw) but doesn't scale all that well. I suspect it might make more sense to be able to build-up some kind of "edge chain" of tiles you collide with (or just the interesting faces of them) when the game starts - however that doesn't work too well when you want to manipulate tiles (destroy them, add them).

 

Nice to have

 

7) "Interesting Tiles". Sloped tiles at varying degrees and concave and convex tiles. I've got this working based on a port of the Metanet N+ code, but it's a bit hacky and I'm not happy with the result.

 

8) The Rectangle Body Shapes can rotate to any angle, and the rotation is taken into account during collision.

 

9) Find if any given point is within a Shape.

 

10) Thoughts on a way to extend the system to support more than one shape per body and joints between them. I don't need this work quoted for (at least not yet but it would be great to at least have an API flexible enough to add this later on.

 

Because we're working in JavaScript and concentrating on the mobile browser, performance is absolutely key. You have to be quite careful not to just create thousands of new Vec2s every frame for example! It is utterly essential that the API is very simple for developers to use. I literally just want them to be able to set velocity on a sprite and that's it, it moves around, and call "collide" in the update and it collides. They shouldn't have to pass in direction vectors for movement, or work in arbitrary values (i.e. not pixels) or anything like this - those are all barriers that stop beginner developers from adopting your framework. I need to avoid this.

 

I don't mind how collision is resolved.. SAT, GJK, Minkowski Sum, etc. It just needs to be fast and not create lots of new objects every frame.

 

Please understand that a considerable amount of the framework is already finished, especially in terms of rendering, Vec2, math utils, tilemap handling, etc. Although you will still need to perhaps add to or tweak these a bit I'm not asking you to build the entire thing from scratch - but you ARE free to consider the "physics" API implementation as an entirely blank slate, to be best set-up how you'd like it.

[xerver]

Is it worth it to have this much work put into your own Physics engine? I would propose that having an easily plugable physics system would be more important, so that existing solutions can be used instead. Providing only the most simple collisions, and gravity are debatably all that you need built-in.

[rich]

Yes it's worth it. It's annoying as I've got a the fully working Flixel physics in there already, which is great. I could ship with this no problem. But I've also ported over the N+ library and that works really well too. They just don't work together Anyway I've had a few interesting leads so I'll see where it heads. I don't want Phaser to just be a "renderer" or something, I want it to take away the pain of complex stuff like this for you - not expect you to have to find a plugin for it. So it's worth my money I feel. Providing I find the right person at least.