Pulling down the house of cards
This week I had the decidedly unglamorous task of moving the Phaser web site from one server to another. The new server is sufficiently more powerful, and capable of dealing with the increased daily traffic we now get. There were a few teething issues, and I'm aware of a couple of old legacy redirects that need putting in place, however on the whole it went well. I'm now using DeployBot, so pushes to the Phaser site, or Phaser Examples git repos, are atomically deployed to the server.
Pew Pew
I've also been working through the Phaser Issues, merging in Pull Requests, closing Issues, and enhancing existing classes. This week the Weapon Plugin got a nice boost, allowing you to blast out whole patterns of bullets in a single call.
The House of Cards
I've also been looking at the Animation system within Phaser, and figuring out how best to support animations that span multiple textures. This is sadly more complex than you'd expect, due to legacy reasons. A recurring problem that I keep hitting my head against as I work inside of Phaser. Just last night I was ranting at poor Felipe on the Slack channel, bemoaning the way things are strung together, and wanting to nuke the whole lot from orbit. Thankfully I slept on it, and am being more rational today :)
Even so, the problem still remains: Phaser is a house of cards, and if you're not careful when working inside a part of it, it's easy for it to all come tumbling down. The crux of the issue is that several years ago, when I first built Phaser on-top of Pixi, I didn't want to mess with it in any way. I extended Pixi classes, never changing them, constantly keeping Pixi updated with their releases (and helping that process along).
This has lead to nested inheritance chains everywhere though. For example, returning to my original issue of wanting to enhance animation support, I've got to fight my way through a coupling of: BaseTexture -> Texture -> Frame -> FrameData -> Animation -> AnimationManager -> Game Object. Suddenly, what seemed like an innocuous change, risks tampering with 7 different classes at a minimum.
As we work through issues, and merging the renderer updates back into v3, part of me is screaming out that things like this need changing (there are many other examples.) They're not broken as such, the system does actually work, it just needn't be so massively chained any more. Maybe it's time to remove a whole stack of cards, and replace them with more solid ones.
This week I had the decidedly unglamorous task of moving the Phaser web site from one server to another. The new server is sufficiently more powerful, and capable of dealing with the increased daily traffic we now get. There were a few teething issues, and I'm aware of a couple of old legacy redirects that need putting in place, however on the whole it went well. I'm now using DeployBot, so pushes to the Phaser site, or Phaser Examples git repos, are atomically deployed to the server.
Pew Pew
I've also been working through the Phaser Issues, merging in Pull Requests, closing Issues, and enhancing existing classes. This week the Weapon Plugin got a nice boost, allowing you to blast out whole patterns of bullets in a single call.
The House of Cards
I've also been looking at the Animation system within Phaser, and figuring out how best to support animations that span multiple textures. This is sadly more complex than you'd expect, due to legacy reasons. A recurring problem that I keep hitting my head against as I work inside of Phaser. Just last night I was ranting at poor Felipe on the Slack channel, bemoaning the way things are strung together, and wanting to nuke the whole lot from orbit. Thankfully I slept on it, and am being more rational today :)
Even so, the problem still remains: Phaser is a house of cards, and if you're not careful when working inside a part of it, it's easy for it to all come tumbling down. The crux of the issue is that several years ago, when I first built Phaser on-top of Pixi, I didn't want to mess with it in any way. I extended Pixi classes, never changing them, constantly keeping Pixi updated with their releases (and helping that process along).
This has lead to nested inheritance chains everywhere though. For example, returning to my original issue of wanting to enhance animation support, I've got to fight my way through a coupling of: BaseTexture -> Texture -> Frame -> FrameData -> Animation -> AnimationManager -> Game Object. Suddenly, what seemed like an innocuous change, risks tampering with 7 different classes at a minimum.
As we work through issues, and merging the renderer updates back into v3, part of me is screaming out that things like this need changing (there are many other examples.) They're not broken as such, the system does actually work, it just needn't be so massively chained any more. Maybe it's time to remove a whole stack of cards, and replace them with more solid ones.