Issue: Moving TileMap Layers Cannot Collide With Anything

[Disease]

I don't know if this is a bug or intended behavior or even something that has been fixed recently (I'm using 2.5), but I have a pretty big issue with TileMap Layers.

I'm making a vertical scrolling shoot 'em up and if you know about the genre than you know that the 'scrolling' of the camera is little more than a contrivance. All the stuff in my game ignores the 'camera': player, enemies, all the different kinds of bullets, UI, powerups, info text, etc. The only exception is the background which I want to scroll down to give the effect of movement. Now my game is a little different in that sometimes there are obstructions in the playfield that that player has to dodge or jump over, and it seems to be it would make sense to create them with a TileMap. So I did that and since they are the only things that will be scrolling, I just move them manually so I don't have to mess with the camera or set 'fixedToCamera = true' on over a dozen different sprite types. 

Unfortunately this doesn't work. The TileMap layers that have to collide with the player as they move down will not do so because there seems to be a hidden restriction that moving TileMaps cannot collide with anything. I checked the documentation and read nothing of this limitation. I'm guessing this is intended but in my case, and other cases I can imagine, it means unnecessarily complicating the code to work around this limitation by bringing the camera into play and setting 'fixedToCamera = false' on pretty much every element in the game, perhaps with some silly inheritance. 

Am I missing an easy workaround here, or is this just a case of "them's the breaks"?

[symof]

6 hours ago, Disease said:

it seems to be it would make sense to create them with a TileMap.

It really doesn't. Just have them be generated as physics objects outside of the screen then add a velocity.y = 300 and the object will more downward, or add gravity just to that object instead of the game, and it will do the same.

6 hours ago, Disease said:

there seems to be a hidden restriction that moving TileMaps cannot collide with anything. 

I don't believe there is a hidden restriction.

 

https://gamedevacademy.org/how-to-make-an-infinitely-scrolling-game-with-phaser/

 

[Disease]

14 hours ago, symof said:

It really doesn't. Just have them be generated as physics objects outside of the screen then add a velocity.y = 300 and the object will more downward, or add gravity just to that object instead of the game, and it will do the same.

Wait, so you are saying that I basically have a giant map of the gameworld that contains hundreds of tile instances of over a dozen different tile types and that I SHOULDN'T make this a TileMap? Is there some better tool for laying out a stage than Tiled for Phaser that I have never heard of? 

[symof]

I have no example to give for your exact idea but this is as close as it gets.

http://codeincomplete.com/games/tower-platformer/

https://github.com/jakesgordon/javascript-tower-platformer

 

The above example uses a tilemap but not phaser built in tilemap.

 

Explaining what I mean would take much longer then a single post, but the main point would be, in phaser, to use a tilemap AND an event array that you can trigger based on the current "tile view" being displayed to create the object outsite of the tilemap.

 

I also don't understand your point regarding the camera. You can just have it follow the player and that would solve all your problems from the start. Then you would only have to use a tilemap set with proper collisions and a player. You would set the player.body.velocity.y = - 100; and that would make your player go UP for the entirety of the game, so as to do a "vertical scroll" kinda thing.

 

Kinda like this but with a tilemap background.

http://phaser.io/sandbox/edit/AQZrVkdI based off http://phaser.io/examples/v2/camera/basic-follow 

 

 

[Disease]

4 hours ago, symof said:

Explaining what I mean would take much longer then a single post, but the main point would be, in phaser, to use a tilemap AND an event array that you can trigger based on the current "tile view" being displayed to create the object outsite of the tilemap.

I also don't understand your point regarding the camera. You can just have it follow the player and that would solve all your problems from the start. Then you would only have to use a tilemap set with proper collisions and a player. You would set the player.body.velocity.y = - 100; and that would make your player go UP for the entirety of the game, so as to do a "vertical scroll" kinda thing.

 

Well the enemies are already being brought in by an event array, I do this because enemy formation, placement and movement is all more complex than just a simple tilemap. What I am trying to avoid here is unnecessary complexity. Going outside of the Phaser tilemap system to do something as simple as moving a tileMap that represents tile elements that can block player movement should not be necessary. 

I considered moving the camera like you suggested, but again it brings in unnecessary complexity. Now I have to manually set the speed of every, single, element of the game (player, enemies, powerups, text, all types of bullets) to -100 just to give the illusion of it not moving and THEN I have to add and subtract from that number to anything I want to move vertically AND have to remember to account for that base velocity anytime I want to work with something that moves. Yuck!

What I think I will end up doing is leaving the non-interactive tile elements (like patches of grass, rocks, roads, etc) as part of the moving tileMap. For tileMap elements that block the players progress I would like to load them as a tileMap layer and try to convert them to collidable, non-movable by the player sprite objects. Does anyone know if this is doable? I saw an example that turns tilemap elements into sprites so hopefully I can turn those sprites into things that scroll down and block the player movement. 

I'll be blunt here: not allowing moving tilemaps to be fully functional is a fault in the framework as it forces a user of the framework to conform to some arbitrary decision made by the developers of the framework. There is no intrinsic reason that moving tileMaps should not collide with sprites other than someone saying "because we said so". 

[symof]

You totally lost me. Are we even talking about the same game archetype? 

 

1. You have the tilemap as a background. Parts of the tilemap can collide.

2. You make the camera follow the player, and add some forward momentum to the player.

3. You make the enemies aim for the player.

This is a vertical scrolling shoot 'em up.

[Disease]

Like I said, I want an object that is motionless on the screen to have x and y velocities of 0 in order to keep things as simple as possible. Having to account for some arbitrary base velocity of -100 is going to complicate things when you want to make Cave-style bullet patterns. I guess my question was: can I maintain this level of simplicity while having moving, collidable TileMaps and the answer seems to be 'no'.