But as far as this specific suggestion goes, the "see inside but not beyond" thing still very much has my +1. A separate layering system that is orthogonal to the current one, or a more intelligent grouping tool would both be options here. Being able to define sections of the map that group everything - map objects, DL paths, tokens - and which can then be hidden or revealed as a unit would give GMs tools to do progressive reveals manually for immersion and atmosphere without overly complicating the toolset or its implementation. At the moment, one of the big limitations is that you can't easily introduce new parts to a scene with corresponding dynamic lighting paths. With that in mind, I think the elevation problems could better be handled by providing some more sophisticated tools for the GM to reveal/hide things. I don't think that we should be asking the dynamic lighting system precisely to represent tactical LOS during combat. If you really want to introduce new tokens by surprise at this stage, there's always the Bump script and the GM layer. But once you get into a tactical situation, I feel like it's better to remember the tabletop roots of the game we're playing - in some ways it's just easier to make everything visible at that point, and rely on the players and the GM to communicate about who can see what. It allows players to "discover" the map bit by bit, and feel, to some extent, the claustrophobia of a dark dungeon. The value of Dynamic Lighting (to me, at any rate) is to provide a more or less immersive experience during the exploration part of a game. At this point I think we need to remind ourselves that this is supposed to be a virtual Table Top, not a FPS computer game. The only real solution to this is to build a genuinely 3D tool, and quite apart from the practical infeasibility of Roll20 rebuilding their whole platform, it would introduce significant additional complexity for the GM in setting up the maps in the first place. A top-down view relies on being able to "see" more than you should really be able to see precisely in order to compensate for not being able to see vertical surfaces - which is why the "see inside" use case comes about in the first place. Even if you gave every object on the canvas a height property and calculated all the sight lines in 3D, it is liable to be immensely confusing in practice without a 3D visualisation. Attempting to deal with elevation effectively in what is fundamentally a 2D application is extremely challenging and I'm not sure there's really a good way of doing it. This isn't going to fix the elevation problem, however, since a token placed "inside" the boundaries of a vision-blocking obstacle (because they're actually on top of it) won't be able to to see anything outside at all - the opposite of what was intended. One-sided DL lines would obviously be the easiest way to make this happen - you can see from the "outside" to the inside but not vice-versa. įor me the fundamental thing here is the ability to see "inside" an object without being able to see "beyond" it - like the tree trunk example. Useful for creatures who do not rely on sight, like Tremorsense, or flying creatures when using an Elevation Border Line, which I suppose could be a new type of Dynamic Border type. Can see through both sides of the dynamic light. Anyone on the right side can see towards the left, but not the other way. <-| In this ascii example, the line segment has a normal "To the left". The orientation of a particular line segment would determine the Normal and thus direction of sight. Can see through one side of the DL border, but not the other. A token cannot see through either side of a DL border. This is the default and how it works now. Cannot see through double sided DL border. So a DL View Number that represents what a token can see or not see. BUT if the token is flying, and at least as high as the top of the cliff, they'd see through the one way DL border like usual. A token at the bottom of the cliff can't see up, but the token on top of the cliff can see down. So one token can see through the DL border, and another cannot. This would reduce the lag since not all draw calls would be to be applied to all tokens. Can Dynamic Lighting (DL) be used on a per token basis? By that I mean some tokens can see the light source and some cannot.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |