search

RPTools / maptool

Virtual Tabletop for playing roleplaying games with remote players or face to face.
http://rptools.net
GNU Affero General Public License v3.0
766 stars 258 forks source link

Separate token data from its map representation #208

Open Azhrei opened 5 years ago

Azhrei commented 5 years ago

The idea here is that the visual aspect of the token that appears on any map is simply an avatar that acts as a front-end for the actual game data that the token represents. So, for example, the game data would include anything specific to the creature/object that the current "token" represents, such as hit points, armor class, or whatever game-specific data might be required. This means that what we now call a token becomes an avatar, so to speak — it's a visual representation of the game data on the map. Changing the hit points associated with such an avatar would change the hit points stored in the game data.

This has numerous issues related to it. Many have been hashed out in discussions amongst the main contributors, but we don't know that we have solved everything. It's likely that the first iteration of implementation will discovery additional pieces that are required. I have taken the time to create UML diagrams of (most of) the discussion and will put them somewhere her on GitHub for others to see and (perhaps) comment on. It will take some time to get these together, but perhaps I can get the first few uploaded soon so that other contributors can at least see what the plan is.

This will be a multi-stage implementation. Most macros that affect data stored on a token will continue to call the same functions and those functions will access the game data behind the avatar in a transparent manner. However, when an avatar is copied from one map to another, the game data isn't copied (that's the whole point of this change). This isn't always what the GM wants, though; consider the case of copy/pasting one goblin to become 15 goblins. Each should have their own game data. Because of this, new dialogs will be needed to configure how game data is copied, how copying avatars should work (link to the original, or copy of all data), and so forth. This means building Swing dialogs using Abeille, ane because we want to reduce our reliance on Abeille and phase out Swing entirely in the future, work done along this path is likely to be thrown away as the transition to JavaFX begins. That makes this a difficult and risky project to take on.

In any case, our discussions should be documented and preserved (for posterity, if nothing else!) so I'll get that started... "soon".

irisiflimsi commented 5 years ago

Can't comment on what has been hashed out. But this is an attempt at the heart of the data model. I wonder what Macro authors would say - do you think you can make this transparent to them?

Azhrei commented 5 years ago

Backward compatibility is the prime concern for this change, of course. If all macro functions that operate on Avatars simply forward the functionality to the GameData object behind them, macros should all work the same. In any case, a per-campaign setting of "Use new GameData/Avatar system" would mean old campaigns will still copy data just like they currently do, but new campaigns will default to turning that option on, thus gaining the benefits.

It might be that any macros which try to change maps (in order to select or search tokens on other maps) might need to trigger a warning or something similar so that framework authors know about it.

irisiflimsi commented 5 years ago

I was thinking about frameworks copying tokens around. Say, the macro "create army" creates 100 tokens from one template. Maybe we should have a config switch that says "use old copying". Maybe even default to the old style. The worst case is that the effects of such a change on macros/frameworks remains hidden for some time until the campaign is corrupted.

What will you return for token->getId? Tokens and Avatars both need Ids.

Azhrei commented 5 years ago

It'll always be the avatar id. There's no need for existing macro code to know anything about GameData objects. The wiki describes a checkbox (default: on) that causes copy/paste to work the way it does now (GameData will be copied) and macros won't need to be adjusted at all unless the user turns off that checkbox. Even turned off, macros should need little or no modification.

(I've started the wiki page, but what's there so far is concept stuff and some discussion of expected problem areas. I'll do something about design drawings when I decide how I want to handle them.)