The main problem with the collision even if you do stamp the collision info on the map is that the map only deals with whole tiles not part tiles, the way round this I suppose is to have them open fast enough so the odd glitch didn't matter too much?
If the door opened say 4 pixels at a time so it's pretty brisk and you just open up the collision after the square is clear it'll probably look alright.
I'll look into creating animated doors this evening, I don't think we need anything as clever as you've suggested Mark.
Thinking out loud:
Particle method:
Delete the door tile, then spawn a particle that is the door opening, after the particle dies it removes the collision block and check to see if there's a door nearby, if so run this again and so on until there are no more door to open.
The tricky bits:
Odd sized doors (3,5,7 etc) This would mean an additional particle that splits a door.
Finding the middle of the door before you begin.
The only other problem is that there would need to be a particle type for all the different coloured doors and both vertical and horizonal, it could be possible to generate these at run time, but I'm not sure it's worth the bother, after all, we've only got 4 or 5 door types?!
----------------------------------------------
Bigger bitmap method:
We have door types that are the edges of the door eg
=][= or ===] etc where ] and [ are the edges and = is door body (as it were).
This way we know where the edges are and which way the door needs to move.
Then we just generate a graphic of the whole door and move it in the correct direction and assume the map will take up the slack of the overdraw ie have the walls as block overlay so the door will just slide under it.
This might be a better way of doing it.
This would also look quite groovy for the smaller doors so they slide in one direction only rather than splitting in the middle the whole time?
Thoughts would be appreciated.
If the door opened say 4 pixels at a time so it's pretty brisk and you just open up the collision after the square is clear it'll probably look alright.
I'll look into creating animated doors this evening, I don't think we need anything as clever as you've suggested Mark.
Thinking out loud:
Particle method:
Delete the door tile, then spawn a particle that is the door opening, after the particle dies it removes the collision block and check to see if there's a door nearby, if so run this again and so on until there are no more door to open.
The tricky bits:
Odd sized doors (3,5,7 etc) This would mean an additional particle that splits a door.
Finding the middle of the door before you begin.
The only other problem is that there would need to be a particle type for all the different coloured doors and both vertical and horizonal, it could be possible to generate these at run time, but I'm not sure it's worth the bother, after all, we've only got 4 or 5 door types?!
----------------------------------------------
Bigger bitmap method:
We have door types that are the edges of the door eg
=][= or ===] etc where ] and [ are the edges and = is door body (as it were).
This way we know where the edges are and which way the door needs to move.
Then we just generate a graphic of the whole door and move it in the correct direction and assume the map will take up the slack of the overdraw ie have the walls as block overlay so the door will just slide under it.
This might be a better way of doing it.
This would also look quite groovy for the smaller doors so they slide in one direction only rather than splitting in the middle the whole time?
Thoughts would be appreciated.