-
Notifications
You must be signed in to change notification settings - Fork 258
Proposed token split into Avatar and GameData
This proposal is still being reviewed. Some details have yet to be decided and I'm sure others haven't even been considered. 🙄
The goal of this page is to describe how MapTool's existing "token" (circa v1.4.1) may be split into two pieces, one piece to hold the data model (called the GameData throughout this document) and the remaining piece to represent the GameData on the map (which is called the Avatar herein).
The big picture is that MapTool's current token contains all game data as well as information regarding the token's position and attributes on the map. Copying the token copies all of the game data, which means property changes on the new token will not be reflected in the original token. We propose factoring out the game data into an object that would be shared between both tokens. This wouldn't be correct in some circumstances (the GM may wish to copy and paste a combatant multiple times and each should have their own game data) but would be correct in others (copying PC tokens to a different map).
There was much discussion about backward compatibility for macros. However, this should be fairly clean as token properties would be stored on the GameData object, while map-related attributes would be stored on the Avatar.
Yes, I used those terms specifically. This document proposes calling values related to game data properties and values related to visual aspects attributes. Hit points, Armor Class, Ability Scores, and so forth, would be stored on the GameData and any macros that access properties would not change — the Java code would simply forward all requests for properties to the Avatar's GameData.
But macro functions that access visual aspects would be processed by the avatar. This means (x,y) coordinates, token facing, and similar.
There are questions around whether game data should be automatically exposed on the Avatar. For example, say the hit points change; clearly, if the avatar is showing the health bar, then the health bar should update. The same applies to various states, like dead, helpless, and so on.
But are there situations where that's not appropriate? Could the GM want two avatars to share the same game data, but be able to control those aspects separately for each avatar? Maybe the GM has a villain NPC with active spells that would normally be represented with states; they might not want those to appear when the NPC isn't known as a villain by the players yet. Or perhaps a PC gets bonuses in certain terrain. Since the avatar may appear on two maps at once, should the GameData represent those bonuses or not? There's no way for MapTool to know. (Or is it reasonable for MapTool to assume that the "current map" is the one whose terrain should apply? Is that the current map for the owner of the token? What if a token has multiple owners and they're on separate maps?)
If a player uses Meta-C and Meta-V to copy/paste, they should probably default to shared game data in most cases. Exceptions would include copying tokens that represent mounts that have just been purchased, or multiple creatures summoned via a spell. How do they distinguish between those use cases? Using Meta-C is commonly interpreted by most programs as copying data, so copying the game data makes sense. But how should they do copy/paste which results in shared game data?
Maybe the Meta-C stays the same, but using Shift-Meta-V does a "shared paste"? Or, the letter next to V on a U.S. keyboard is B and the Meta-B keystroke isn't currently used in MapTool, so maybe use that for shared paste?
Maybe there should be an option for a popup confirmation (like there is for new tokens dropped on the map) and it should default to on?
Maybe a transparent overlay on top of the newly pasted token with some kind of "copy" symbol vs. a "shared" symbol? It could remain for 2 seconds and then fade away. The user would have immediate feedback without requiring any additional action to clear. Perhaps an option leaves the symbol in place until the user mouses over the token, or until they click on the token the first time?
Clearly, these types of things will require some testing.
As you can clearly see, we haven't worked out all of the details. Our goal at this point is to lay out our concepts and try to identify the major issues. Over time, I'll try to distill our discussions into a form that can be presented here (we have dozens of pages of dialogues and examples), but that's likely to come in a trickle most times and then sudden deluges, as time becomes available.
(I'm working on making some design diagrams available, but I have to link to a URL from the wiki, which means they need to be checked into the repository. Which means I need to decide whether I'm going to link to a particular commit or to HEAD on the master branch or development branch, so that updates don't require me to come back here and edit the link.)