Separating sprite update logic from state update logic while ensuring execution order

[Jmaharman]

I'm doing a bit of experimenting with Phaser and working out how best to layout larger projects in a way that I would for other JavaScript projects. For me this means using browserify and creating CommonJS modules. So, I'm working through Space Invaders and trying to do this, however I have a question about the life cycle of state and objects within Phaser.

 

I've converted the example into being a separate State, so that I can load it from a root menu. On top of that I have created a Ship class that inherits from Phaser.Sprite and contains all logic for moving the ship. This means I've moved the the logic that controls the ship's movement out of the state's update function and into the Ship's update function. However the code testing for collisions is still within the State's update method.

 

Based on my initial tests the following is true:

1. State update function called ( which runs collision detection )
2. Ship update function called ( Moves the ship X amount left, which may overlap with a bullet )
3. Render occurs and the player may actually overlap the bullet because the update method on Ship is called after the State update function

If this is the case, what is best practice when trying to separate out functionality and logic into separate modules like this, while still ensuring the order that the update functions are called are logical in relation to the game.

 

The only way I can think of ensuring the order of execution of the functions is to rename the update function on the ship, and call that from the State's update function.

 

A slight alternative to the above would be to move the collision detection into the Ship itself, which then means I need to pass in a reference to the bullets group, which I don't like the idea of.

 

However I can't help but think there are some best practices for managing things like Sprite movement (AI or user controlled) and Collisions so that they are executed in the same order, especially for larger code bases where code is separated out into different files, rather than being in one large mega file with global variables (which is great for simplicity for demonstration purposes but not so great for maintainability).

 

Thanks

 

John

[InsaneHero]

Which type of collisions are you running?

If you use Arcade (or I think any other) Physics, the collisions only run when you call the "collide" function on them - which could be in your ship update.  Unfortunately that does mean that you need a reference to your bullets to be available.

 

I've only just started JS games writing, but I've released a bunch of Flash games (www.insanehero.com) and the pattern that worked best for my short one-man projects was using Static classes.  So the bullet manager would be Bullets, the enemy manager would be Enemies, etc.

What's nice about this pattern is you can then access the bullet manager from anywhere using Bullets.checkCollisions(this.sprite); and it can return a list of the bullets which have hit your ship.

Many of the conventional arguments against using static globals like this don't apply in one-man 3 month projects, and the few that are still relevant should just become warning points for your coding style (eg. don't abuse the pattern, it's fragile!)

 

In the longer run a lot of your design choices come down to one basic decision:

"quick or clean"?

 

Despite many claims for different patterns, I've yet to see anything that does both... and as I need to churn the games out to keep the mortgage payments going, I chose quick - but with a whole bunch of self-imposed limits to prevent spaghetti code or obscure dependency chains.