Closed IkonOne closed 8 years ago
NOTE TO SELF: There are typos in the commit, back it out and fix.
One class per file is something I'll always strictly adhere to, regardless of how small one class is, but yeah I'd be fine with this. I was going to implement it myself eventually.
This object was something I quickly hashed together so I could control some features myself easily, but I certainly intended on formalising it as a class, including the tiny SAT member that stores the SAT.js response of each collision.
I just created PR #15 that adds these fixes and a couple of more to the typedefs. I'm going to close this since it doesn't actually cause any issues on the typescript nor javascript ends as far as I can see.
The solution I used in the typescript definitions is to simply declare these anonymous objects as interfaces so that they are valid types in typescript but cannot be directly instantiated with new
.
The slopes variable added to the Body class is a dynamic object. These are unusable in typescript as they will throw errors when trying to access their member variables(unless you use ['array'] access). This commit I created some classes in the typescript definition so that the variables are properly accessible: https://github.com/IkonOne/phaser-arcade-slopes/commit/df06dc62b7410b554d647214e4f363d42a1a042f
The added classes are
BodySlopes
andBodySlopesSat
. I think that an approach like this is ok for now. If you agree with this approach, I can convert the objects in the JS code to classes as well as you mentioned the possibility of here: https://github.com/hexus/phaser-arcade-slopes/blob/master/src/ArcadeSlopes/Facade.js#L87The two classes needed could possibly go in a new file called BodyMods.js or something.
Also, since the
sat
variable is only used to store the responses, maybe simply having acollision
orresponse
variable might be a better fit.