First time using Phaser, misc questions and issues

[bburky]

Hello, I decided to port an existing HTML5 game I made (source) to use Phaser (source).

 

 

Phaser seems pretty good. I couldn't use a physics engine because my game isn't really physics based. So I did all the movement and collisions by hand. Is it really fine to use tweens for everything including player movement? Do they get decent performance? Do they run on the requestAnimationFrame clock or a setTimeout clock, can I depend on them to be fairly predictable?

 

Phaser bug: Start a player moving, then switch to a new window which pauses the game. Wait 5 seconds then refocus the window. The player will never stop moving and go off screen. I think the tween never finishes? outOfBounds will never be triggered either. I have also had the player go through a block. This is bug is somewhat unpredictable. I actually can't reproduce this at the moment, but I swear it has happened.

 

Could something like Phaser.Keyboard.ANY be added to detect any keypress? It would have to act differently internally of course, but it would be nice to detect if any key is pressed/isDown. I use game.input.keyboard.onUpCallback instead, but it is more difficult. I have to clean up the callback myself later too.

 

Is there a recommended way to restart for a new level and reinitialize everything? Right now I'm calling game.world.destroy() to kill all sprites/groups. Some other things seem to be removed, like listeners on game.input.onUp, but oddly not not game.input.keyboard.onUpCallback. Tweens don't get removed, so I do it by hand. (Example code)

 

Should I (ab)use tweens like this? It would be a nice feature to have properly in Phaser. I didn't pick an easing function yet, but I can. I wanted an easy to use tween but do something complex with the value. tween._object in onUpdateCallback works nicely, but is undocumented. Also, is there any nicer way to do the color things I'm doing there?

 

Is there any way to get an image's dimensions before placing it or position it from it's center instead? Currently I'm placing my background image at (0, 0) then centerOn() immediately after. I've seen the image jump on loading once or twice, so this isn't ideal.

 

Possible bug: if you set filters on a sprite while using the canvas renderer the whole game crashes. I manually check (game.renderType === Phaser.WEBGL) before setting it to avoid this. Could Phaser instead gracefully degrade by ignoring filters incompatible with the renderer? I was reading about pixi.js 1.5 and it actually has some canvas-only filters, so this may get worse in the future. But the canvas renderer is always supported so that may not be an issue as much.

 

I like Phaser a lot though, it seems pretty good and easy to use. I have even made a couple documentation fix pull requests and already had one merged. Work on 1.2 seems to be moving quickly too which is good. If ArcadePhysics is getting killed, I'd also vote for adding primitive AABB collisions. I was almost able to use something like that for this game, but I needed to predict the collisions before they happen.

[rich]

You can specific an Keyboard.onDownCallback which will be sent the original DOM event as the first parameter. From this the event.keyCode will tell you what was pressed, or if you don't care you can just use it as an 'any key' function.

 

You should be using States (and swapping states) to handle new levels, reinitialisation, etc. Have a look in the resources folder and Project Templates, you'll find a couple examples how to do this. game.world.destroy literally only clears the display list, swapping states clears pretty much everything and resets all the input handlers, etc.

 

You can abuse tweens like that if you wish, and if it works for you then why not? _object is a private var, hence left out of the doc generation, but this is JavaScript - anything goes really.

 

Before placing an image: game.cache.getImage(key).width (or store it in a local var and get the width/height from it).

 

The filter on canvas games is fixed in 1.2.

[bburky]

Thanks for answering my questions. I'll look into states, that's probably what I was looking for.

 

How exactly does preload() decide when it's done? I tired to use load.script then use its on loaded callback to load more assets that I found specified in the other script. (It's the list of levels in a separate file, each specifies a background image.) I think I was getting preload to finish before all the other images got loaded.

 

I'm curious about the usage of callbacks vs signals in Phaser. Are you going to be switching more of the callbacks into signals? It would probably be more consistent.

 

What's the recommended way to keep track of extra attributes associated with a sprite/entity. Should I tack extra random attributes on to the sprite object itself? Subclass Sprite? Or go ahead and make my own class that contains a sprite internally? I ask because on the web side of JS you can store data in the DOM and jQuery has a data() function. But adding random properties is asking for something to collide and break.

 

 

[rich]

preload decides it's done when its own queue is empty. If you define a bunch of new loads from a callback it won't have any understanding of those, so won't consider them part of its queue.

 

I use Signals where I can, which is in most places. But there are some cases where it's just not performant to do so - mostly in input event callbacks actually, so for example I'd never make mouseMove a Signal, it's just too intensive. Same goes for say a tween update callback. But pretty much everywhere else where I can, I use them.

 

I would suggest you sub-class, because as soon as you modify a known object class like Phaser.Sprite, most JS compilers will be unable to optimise it any more and force it down the slow-path. If you create your own class it can build an internal class structure from that (providing it doesn't dynamically change) and it should be fine.

[bburky]

Ok, thanks. I think that's all the questions I had.

 

I hadn't thought about JS performance as a reason to use subclasses. That's good reason to at least organize it somewhat better.

 

I'll continue to file issues and pull requests fixing any docs issues I find, hope that helps too.