codevinsky

# curve-fever 2.0 proposal ## Proposed Tech Stacks * Backend * * Node 7.5.0 * * Express 4 * * Socket.io * * Mongoose or other mongodb ORM * Front End * * Phaser LTS (which ever version that is right now * * Socket.io * * React for the UI * * MobX for state management ## Scenarios: In order from least time intensive to most time intensive ### A: Translation Assuming you have all of the game logic already implemented and merely want it translated from current implementation to the new implementation, (both back end and front end), then that's "minimal" work (as compared to Scenario B and almost no work as compared to Scenario C. In that case, most of the work will go towards the ui. ### B: Re-implementation This involves not just translating, but optimizations where they can be found... So, whatever length of time A would take, this takes that long, plus time to refactor and test ### C: New Implementation Basically, start over from scratch and implement the game, server, and full techstack from the ground up. This has the possibility of being the quickest (depending on which developer you get... and how familiar she is with Curve Fever. But it also has the ore real likely hood of being the slowest. However, this one also has the highest chance of producing a better product (again, depending on the developer). So out of those three scenarios, which would you prefer the most?

So, one -huge- problem I've encountered thus far: I've got an angular application wrapping my game layer. As such, phaser-inspector -dies- immediately and doesn't start up.

I'm ridiculously excited about this.

Here's a request: Let's say we've got and endless runner game with three states: MenuPlayGame OverIn menu, we have a scene that has a parallaxing background with floating buttons. When we click the "Play" button, we move to the play state... but without wiping the scene of current game objects. The player character enters from the left, running at a constant speed with the background is still parallaxing properly. On player death, we switch to the gameover state, the background stops parallaxing, and a "stats" display flies in with a "try again" button. When this button is pressed, the background seems to "rewind" all the back to the beginning, and we switch back over to the "play" state. The Request: Be able to switch states without having to wipe all of the game objects that are still on screen and retain references to those objects.

Make the change to group/layer.. release it alongside 2.5 It's ok to have API breaking changes at milestones like that. Lord knows Angular did it.

1) Do you ever create PIXI.DisplayObjects directly in your games? Not as such, no. However, I do -often- use the inherited abilities of DO's and DOC's to add child sprites to sprites. 2) Do you use PIXI globals anywhere in your code? 3) Do you always use AUTO render type, or do you target a specific type? Most of the work -I- do is web work using Phaser as an animation layer. As such, I -always- use AUTO as we have to support a lot of different browsers and platforms. However, I'm not opposed to having to include modules. That being said: I am ALL about being able to use webpack and correct es6 module and class structure for my projects. Right now, it's a mish-mash of what can and can't be done. So, whatever it takes to be able to have Phaser be correctly modularized... I'm for it.

Is this a physical 'zine' or e-pub only?

"Pool" seems like it would automatically implement recycling, as that's generally where I've heard the term. If it doesn't then maybe something else. How about these suggestions: * Assembly * Bag * Cartel * Lot * Store * Batch * Cluster * Crowd * Stack * Heap * Pile * Kit I, personally, like "Stack", as it has a double meaning referencing an actual layered memory stack (which is, by definition, not a display element) as well as describing the exact function (stacking) that you're trying to implement.

The phaser documentation site is down right now. While that's being worked on, you still have access to the documentation. It's in the github repo under "docs", or if you've grabbed it via bower, you'll have it locally as well, though it's the classic style (which i prefer) and not the new style. JUST FYI

Basically, all revenue that comes from my Phaser related tutorials and ad sales go -right- back into the community now.

Very nice!

I've canceled a number of other non-essential subscription services so that I can become a patron. I'm -extremely- excited to see this happening, as the community surrounding this framework is -ridiculously- active, and we can -always- use more support.

I'm going to end up going with this solution: https://stackedit.io/viewer#!provider=gist&gistId=0ec84c8264e96f210f3a&filename=animation-architecture.md

I've got a project I'm working on right now that has a complicated series of transitions between game "states" as well as some complicated real-time Inverse Kinematic animations. I've got a number of people working on the project, most notably myself as the architect and an animator who's very familiar with phaser's tweening engine. However, I need to be able to separate app logic from animation code and sandbox him so that his code doesn't touch the app logic code. What's a good design pattern to follow that will give him full access to event based tweening while still keeping him from having to touch logic code?

If there are fixes that need to be made, the code now lives in the Phaser Plugins repo: https://github.com/photonstorm/phaser-plugins