My MapTool Fork: Video Proofs of Concept 02-07-2013

[Lee]

Sorry for the delay. I had to re-upload as someone powercycled the #$@@#$!@# router!

[Bone White]

Thankyou for this Lee, we all know you're hard at work behind the scenes when you can, but a picture tells a thousand words and a video...

[Lee]

Thanks BW. I appreciate it

I don't have time right now to upload the 2nd video, as I'm leaving on a trip that will take me away from anything digital for the rest of the day.

I've added the database video to the OP, however, and I hope you guys like it

Edit: BTW, please read my description on Youtube about the newest video. It will explain a lot!

[jckrbbt]

Again, great job on the SQL implementation. I really wish this had been around from the beginning! Great choice of music on that video, too.

[aliasmask]

.

• ||| Lee adds SQL to MapTool |||

  

[wolph42]

Well that sure as hell makes my latest table addition to the bag of tricks obsolete

Cool stuff!

So when r u going for a release?

[Dracones]

I've added the database video to the OP, however, and I hope you guys like it

This is real nice. Is there any propogation of the actual on disk sqlite file or is it all handled via the sql statements pushing to all the clients?

[Lee]

@A.M. HAHAHA. I haven't seen Scanners since I was a kid. Good times.

@wolph Sorry about that. Did I mention that I have also completed manipulation functions for standard MapTool tables?

As for what you asked, very soon. I know I keep saying that, but if you saw everything on my end, most of the delays weren't completely mine. Right now, I have a green Launch button, but I'm waiting on other people so that we'll have the strongest possible package to survive the long haul.

This is real nice. Is there any propogation of the actual on disk sqlite file or is it all handled via the sql statements pushing to all the clients?

Right now, the structure is:

• The application has an embedded SQL engine. The user db is H2, by the way. After doing reviews on several, similar engines, this one fits the bill for now. The connection string is dynamic anyway, so we can always load up the next front-runner w/o needing to change the code.
• Since MT is a client-server mish-mash, designers can opt to either have all clients access one database through server mode, or let each client keep a copy of game data using embedded mode.
• Information is pushed as with any macro command, albeit, designers won't need to do any fancy macrolink/macrolinktext magic. We did that for you, in that execution is done client-side.

We're mulling the execution of the initial propagation of data. If we ever get to implement background updating, players can be fed the full array of updates off-session. But until then, we're thinking to push data to players on a "as-needed" basis (i.e. player's client checks if it has info. If it doesn't and the server has the info, it requests a pull.), or stream the whole thing during the session. It may come to a balance struck between these options, perhaps something hinging on the volume of data being sent.

We'll want to discuss the user structure for MT dbs in the future. We may have differing views but a good talk always spurs innovation

P.S. I'm too pooped to work on the 2nd video right now, and I'm about to hit the sack. I'll do it first thing when I get up.

[Full Bleed]

I've added the database video to the OP, however, and I hope you guys like it

Going to play the Devil's Advocate here...

I take it that this will allow us to create more powerful/useful tables and db's to access data?

To be honest, as someone who's never used SQL it looks like a very "programmatic" approach (i.e. lots of json syntax and populating/pulling data with long strings of code.)

I guess I don't see a more programmatic MT as being an entirely positive direction. Are there simpler/better SQL DB editors out there that can be incorporated?

[CoveredInFish]

I agree that MT shouldnt get a coders only tool.

(But) with a database in place I bet you could easily create some "dumbed down" functions to use its basic features - you shouldnt have to learn SQL to look up random treasure. But having it all accessible is awesome if you want to do more complex stuff.

[Lee]

I take it that this will allow us to create more powerful/useful tables and db's to access data?

To be honest, as someone who's never used SQL it looks like a very "programmatic" approach (i.e. lots of json syntax and populating/pulling data with long strings of code.)

I guess I don't see a more programmatic MT as being an entirely positive direction. Are there simpler/better SQL DB editors out there that can be incorporated?

Yes to the first part. The ideal is also to wean away from the current data storage (in-token) system, something we'll be chopping away at as we go. It'll not only be SQL, we're looking at others too.

We're gunning for:

• A slimmed down token model. No more data riding on it that doesn't pertain to it's relation to a map, or any information that has references to the token (e.g. macros).
• Relations allow the actual information to be stored elsewhere and will exist on the token only as links/references.
• One instance of a token's model with a data map tracking where images of it is at on all maps/scenes.
• Updates to the token will then mean all token images will have reference to the newest information.
• etc.

I don't think MT will become more programmatic than what it already is. The API to the db is still accessedby macro script; only people in the know will feel the need to use the direct SQL functions I provided (i.e. sql.query, sql.insert). The rest provides an abstraction to SQL; it's just like putting all those headache inducing jsons together to save on a library token. Same process here

Lastly, I predict several grand community projects spearheaded by the technically savvy to make definitive databases of their game system's data (e.g. spells, weapons, powers characters), and SQL will provide a standard (dare I say "universal"?) means of access to these. No more rewriting macros from scratch to access self-made data structures hosted on tokens. Yay.

I agree that MT shouldnt get a coders only tool.

I understand. I'm just keeping it real to the project's design ideal of "empowering designers, who in turn create great experiences for players."

[wolph42]

even if its quite 'cody' in its basis, users (like me) upto now always managed to create a more UI friendly interface. E.g. the new tables I created has an interface that is easily created and used (the processing was the real pain, but that's now taken care off). So I wouldn't worry too much about that.

I'm curious though. Your talking about moving the data from the tokens to a database and have user access that db instead of the token for info. So stuff like
- properties
- stored vision data
- location
right?

currently (IRC) when one thing on the token is changed (e.g. moved) the updated token is send to the server and the server sends the updated token to the remaining clients, right?
in your case? is the data again send to the server and then again distributed to the remaining clients (but now to local databases instead of tokens)? Or is the data is send to a central db, but how do the clients then'know' the changed location of the token?

Overal I gather that the big advantage is is that when e.g. the 'wounds' property of a tokens is changed, you no longer need to send the entire token with all its data over all clients, but just that piece of information?

Basically all of the above are questions/assumptions. Care to elaborate on them?

[Lee]

@wolph Something similar, quite close. I will elaborate, but later. I got to run out for some personal stuff.

In the meantime, I've uploaded the play on the map system

[wolph42]

@wolph Something similar, quite close. I will elaborta, but later. I got to run out for some personal stuff.

In the meantime, I've uploaded the play on the map system

awesome!! i notice that you have the same issue i had when i started making vids: no voiceover. Get over it and add them!!

one question, the (forgot the name..isotropic??) not top view, is that something you can set or will this be default?i ask cause i still prefer the top down view. Also the fading fog, also cewl, but it might get annoying, so again, is this a setting or default?

[Lee]

awesome!! i notice that you have the same issue i had when i started making vids: no voiceover. Get over it and add them!!

one question, the (forgot the name..isotropic??) not top view, is that something you can set or will this be default?i ask cause i still prefer the top down view. Also the fading fog, also cewl, but it might get annoying, so again, is this a setting or default?

Oh the things I can accomplish if I had more time...We're thinking of redoing our videos as it the last one turned out so well with the right settings on Bandicam. I admit it's a character flaw, but I'm so much of a perfectionist at times that I keep scrapping stuff over the smallest of errors, and find out belatedly that I wasted the whole day over some thing as short as 2 minutes I'll try; that's about the best I can promise right now.

As for your questions, it's a map generation option. I mentioned working with finite maps (but we're mulling putting an infinite map option in), so the work process will be:

• Choose map type (top down, isometric, etc) or import
• set dimensions (where applicable)
• tweak settings
• design

The fading effect is just play for now. It's a combination of 2 things: layers and the animation api. For fog, we just hooked the fill property to a transition loop and set the duration for the whole cycle. The implementation of what's involved in the video and which parts of it is open to users, is still being discussed. What we wanted to show is, it's possible to do stuff like this for immersion on the moment, like when you're pressuring players to make up their minds fast since the clock is ticking and it's almost sundown, and it's time for the tide to come in...stuff like that

I'm curious though. Your talking about moving the data from the tokens to a database and have user access that db instead of the token for info.

Not exactly, it's not a forceful move. The new data options are just that, options. Users can opt to keep everything on the token base if they choose to do so. Trust me, it'll be clear once it is made.

So stuff like
- properties
- stored vision data
- location
right?

Properties will exist on the token model BUT we're moving toward (very loosely) defining what a property should actually be, especially seen in the light of relevance to the object/token. For example, we are used to storing gobs of info on tokens that are not necessarily lib:tokens. Actually, the existence of library tokens itself is (no offense meant), what I think, a product of well-meaning design that got convoluted due to MT's organic growth; in other words, an anomaly. I mean, we have an image asset to represent a data store on the map, but no actual interface to view the data? Wouldn't it make things easier for people if data is separate from the token system, and designers can just create the references that they need?

Under the hood, another question, you need to traipse map information to locate a library token, so that you can then perform operations on it? Why aren't all tokens referable no matter where they are? Why do you have to be on their map to do so? Some of the answer to that is because there was a hard association made between a map, and what was on it. It makes sense sometimes, and creates problems in other situations. Everyone here knows more or less what I mean.

Stored vision data will not persist on the token. I'm guessing that when this was conceptualized, thing were viewed from the actor's perspective; like what an entity perceives, it "knows", so the logic then is to store the knowledge there. I haven't sat down to implement this but I'm going to test shifting things to the Player's perspective, and it starts with storing vision on the map itself, as opposed to the token. (To me) it makes more sense that way.

Being in-character aside, a player with ownership over a certain token "sees" or "knows" what the token does, if we apply the same logic to all his/her tokens, then all their vision data should be an amalgamation both in (stored) and on (visualized) the map. If we take vision data out of a token, passing it along the network would be a lot lighter. The ideal is to "flatten" the consolidated views and forget the vision data on the individual/character level, but I'm guessing people would still want to make some sort of persistent references to a character's vision data (i.e. Character: Vision info), so that's still on the table, though, I think, that defeats the purpose a little; though one good scenario for keeping references is when there is transfer of ownership to another player, so that player's map needs to be updated, while the former owner needs his map to "forget" what the character saw. In order to the impact of maintaining these references lighter, I think we'll need to take it out of memory and store it on media at certain intervals or force storage script-wise, and call it up when it is requested for, e.g. a transfer of ownership.

Storing on the map itself takes care of several things like multiple characters (e.g. summoned creatures), and the trickiness of the current Individual FoW. Instead of IFoW being an option, it can be made a standard. We'll essentially have our cake and eat it too. The only person who won't benefit much from this would be the GM, as he maintains and "knows" all the views. Since they're built to suffer for their players, it'll be nothing new to them

Location info is definitely a token property, so it stays on the model.

currently (IRC) when one thing on the token is changed (e.g. moved) the updated token is send to the server and the server sends the updated token to the remaining clients, right?
in your case? is the data again send to the server and then again distributed to the remaining clients (but now to local databases instead of tokens)? Or is the data is send to a central db, but how do the clients then'know' the changed location of the token?

I think I've answered most of the first paragraph. When a token is moved on the map, we'll only be moving its image. Location information will be updated when it gets dropped on the map, and that's about it. There will only be one model per token, hence one data model as well. When information pertaining to it is manipulated or modified, it behaves as it always has: all client's get updated in session time, but everything becomes permanent only if the host saves things post-session. We'll just make thing smarter by updating only the parts that got changed, instead of passing the whole token around each time.

The reason (I think, and only on anecdotal evidence) things are what they are right now is, MT started out only to move images around on a map, and it was great and all that connected clients can see a token move in real-time. When data was added to the model, and macro script introduced, everything just rode on how the token movement mechanism works, regardless on whatever it brought along with it. It's just about as close as MT can get to having a "god-object". Again, purely guess work on my part.

Overal I gather that the big advantage is is that when e.g. the 'wounds' property of a tokens is changed, you no longer need to send the entire token with all its data over all clients, but just that piece of information?

Yes, and that all instances of the same token on different maps are just images referencing the master token model.

Phew. I need to take a break. We're prepping for launch, so I'll be very busy over the next 5 days, but I still hope people will drop by and continue the discussion. Thanks!