Pre-Prototype Cards Teaser

[ornate vortex]

This looks pretty good. But, I've got a niche use case that might not fit in the current data model.

Some table top war games use what are called "Chits", which for all intents and purposes act like a card. They are square pieces of cardboard with a front and a back and are generally either placed in a stack or drawn from a cup during play. So far, so good. Now, in a particular game that I play, chits are placed in four separate cups, and drawn when determining naval ships that you are facing during a battle (it's a WWII simulation of the US submarine campaign in the pacific, in case you're wondering). The front of each chit represents either a Japanese merchant ship or a warship, but the back can have either a Standard Japanese flag 🇯🇵 or a Japanese battle flag which has the red ball but has what look like rays of light radiating from it. Most merchant ships have the standard flag, but some have the other. And most warships have the other flag, but some have the standard flag. This is done to introduce a kind of "fog of war" effect that you can never be sure what you're gonna face.

All that being said, my point is that there are valid cases where it might be preferable for each individual card to have a separate image for it's back. The current model doesn't seem to support this.

[proper ferry]

Based on prior discussions during the community feedback gathering phase, I believe that the card fronts/backs like you want will be enabled through the Faces array described in 5731, which isn't described in much detail so far.

Edit: looks like it is described and I read too fast, see LordZeel's response below #878330933021917274 message

[ornate vortex]

that might work, then

[proper ferry]

preliminary thoughts: looks super cool. Love the system implementation described in 5755.

[pastel crest]

Re 5755, I take it the answer for implementing a complex card game as a module would still be "flags and determination"?

Will it, by default, be possible for a module to define cards which leave the system data fields blank - e.g. having a system-independent module for playing Gwont which will work even in the a system which implements Mages The Gardening with game system data?

[distant gust]

Loving the ideas so far. Something that is pointedly absent though seems to be descriptions on what a Cards object will be capable of in terms of drawing, peeking etc. I guess that's on purpose?

[tall current]

class CardFaceData extends DocumentData {
  static defineSchema() {
    return {
      name: fields.BLANK_STRING,
      text: fields.BLANK_STRING,
      img: fields.VIDEO_FIELD
    }
  }
}

Looks like each face has a name, text, and image.

[tall current]

I think this is just the data schema.

[distant gust]

also, the naming of Card and Cards may lead to confusion. Naming it Card and Deck or Stack seems to be a less ambigous way to go

[distant gust]

good point

[tall current]

This is one of my questions as well.

It's all well and good for a system to define a schema, but some card games are very "simple" and make better mini-games. And some systems could hypothetically support many card games. Not to mention cards as premium content.

This may be a case where modules need to be first-class citizens when it comes to data.

Example: In 5e there is the Deck of Many Things, plus there are some non-SRD card deck magical items that could exists as a premium module, and any tavern worth its salt surely has some people playing some fantastical card game that the players could enjoy.

Implementing those outside of the system would be troublesome without the ability to define the data schema.

[pastel crest]

A module can do whatever it wants in data.flags, though this ends up with slight fewer sanity checks than working in data.data where the system data is. But it's somewhat important for being able to do database validation on the server to have that system/module split here, AIUI.

My main thing is that I don't want to end up with system-specific card game modules where avoidable. For Actors and Items, there are few use cases for non-system specific instances (a generic bandit would still need to understand how the system does monsters, for example), but modules need to be able to define a self-contained card game and clearly note this as "this is a card for my game, and not one of the card types for the system".

[tall current]

Yeah.

[desert ibex]

hey folks, thanks for the feedback!

it sounds like for the most part this is heading in the right direction for you all

I definitely am sympathetic about the issue that, with system data being possible to add, card-based systems become more powerful and easier to work with than card-based modules

I don't think there is a better approach here though, at least not now.

I think system data for cards is a good idea, even though it isn't an option that modules have

[proper ferry]

In the spirit of "it's maybe easier to have additional attributes now than add them later," I had two thoughts for new attributes to consider adding to CardsData:

1) Counters
Your Magus the Gardening example got me thinking about this one, but "putting small physical objects on top of cards to indicate a count" is a common enough universally applicable mechanic that adding an (integer?) "counters" attribute might make sense. Core wouldn't have to do anything with this attribute, but it would be a nice feature for the document model I think.

2) Marked
A surprisingly popular feature of Card Support Unofficial is the ability to designate a card in hand as "marked" which the UI applies a tint to. I had implemented this originally for Torg folks to indicate that a card was in their Pool as opposed to not. A card that was "marked" in their hand showed up as red, and this was a boolean value- it was either marked or not.

Now, there are better ways of accomplishing Pool in this new document model, but the ability to generically "mark" a card, wherever it is, could be useful to accomplish the zillions of weird things people will use cards for, like perhaps visually highlighting a card for yourself or others while discussing a trade, to replicate physically pointing at a real card maybe, or... whatever.

Generially speaking, adding an attribute named "marked" to the core document model that took an integer? value might allow systems and modders to do interesting things. Again, core wouldn't have to do anything with this attribute, I don't think.

[distant gust]

Counters only really apply to TCG-type cards, at least as far as I can tell, so I feel that this feature should be left for the system

in this case less is more, since cards are so universal. If we sat enough and thought long enough we could come up with a dozen more things that could be added to the core definition but which ultimately are mostly situational based on what game uses the card

[proper ferry]

The logic is that people are free to just not use the attribute it it's not useful to them, it doesn't cost much. Certainly it will not be useful for SWADE... Unless you wanted to create a pretty card with an appropriate image to represent a Dramatic Task, and put counters on it to indicate progress.

It's exactly this sort of low cost flexibility that can be added for creative people that could be cool.

But yeah, this is obviously just a suggestion. It's better to discard an idea once considered, I think.

[tall current]

I'm unconvinced that "less is more" here though. In most cases we're talking about a few bytes of data here and there. Making data more accessible and universal is, imo, the right play.

If counters make sense in multiple systems, and having that property won't negatively impact other systems... I don't see a strong argument not to include it.

No, the schema probably shouldn't have 100 properties. But a handful of common ones? Why not.

[distant gust]

by that logic all cards should also come with a suit and a face value since poker cards are used by many systems too

[tall current]

I do think all cards should have value but I think suit is a type?

[distant gust]

after all we're only talking about a few bytes and if the data doesn't negatively impact other systems I don't see a strong reason not to inclide it :P

[uneven token]

I agree on the "marked" attribute. It could be really helpful in my system.

[tall current]

Actually maybe faces should have a value?

[distant gust]

then you start getting really wonky once you start getting into systems that have more than one type of card (poker card vs tarrot card for example)

[tall current]

I think some "value" of a card/face is fairly common, even outside of a poker deck.

[tall current]

Suit was mentioned in the schema for type

[proper ferry]

I like the idea of faces having a value. Having a "type" and "value" generically available would be pretty awesome I think.

[tall current]

Though if it works like Actor types... Idk if that the correct way to use it.

[distant gust]

I'm really not liking the idea of suit = type when considering actor and item types as a comparison

[tall current]

Yeah, I agree. What's a better generic word for what we mean?

suit is too specific. type means something in Foundry already.

[distant gust]

category maybe

[tall current]

Maybe, seems too broad, but maybe.

(but for sure, if type is the same concept as "character" and "npc" that isn't suitable for suits)

[proper ferry]

In general, the idea is to support physical things that a card can do, I think. "put stuff on them" is one of those things, as is "mark" them (aka point at them, move them slightly to set them aside), etc.

You are completely correct in that poker cards are super important so making sure that support for them is solid is definitely a high priority, in whatever form it comes. Ideally I'd personally like to make sure that it would be possible to add poker-type cards to your game without necessitating system-level support... I think a lot of tables could benefit from a random card minigame here and there, regardless of setting and what the suits/ranks are called or reflavored to.

Exactly what makes the cut and what doesn't is a judgement call on the Foundry side, which I'm more than happy with. shoves Card Support Unofficial under the rug and hits it a few times with a shovel.

[distant gust]

poker cards are just an example that comes to mind due to personal bias, so I don't really want to openly agree, because of my stake in #swade.
That's exactly why I personally think that less is more in this case since the usecases are so incredibly diverse. You will not be able to please everyone by packing more stuff into the core data model, so I wouldn't even try. I'm well aware that the downside of that approach will be a lot of duplicate implementations

in my mind a good analogy would be (for Items) the state of whether the item is equiped or not. It's such a universal concept and yet it's not in core, since it's not needed all the time nor wished for. The same goes, as far as I can see, for things like whether a card is marked or how many counters are on it

[proper ferry]

That's fair

[tall current]

I would argue that the base Item should have an equipped property then.

However, Items and Actors are very system-specific. They always have a system schema, and they aren't portable.

Cards on the other hand easily could be portable, and in many cases a system-level schema won't make a lot of sense. So supporting more at the core level reduces the "bag of flags" effect.

(ex: poker deck in 5e. Why would the system add that schema? The game doesn't use it. But a DM might want to use one for a homebrew rule)

[distant gust]

the issue I can see with the inclusion of such properties is that you will shoehorn people into a certain way of using the data. if marked is a boolean then you'll force people whose cards have a range of markings (say symbols represented by strings) into using the flags anyway. Counters as well. Should a counter be an array? should be a number? The usecases are too diverse to cement that into the document structure

[tall current]

I would say this, as someone who doesn't play a system that uses one...

The core data model should be able to support a poker deck with no extension.

[proper ferry]

Yeah, I had that thought about counters ideally being an array of objects myself. Maybe with"just" a name description and count (the integer). But it's a fair point... Is this a useful baseline to add to core, or is this a job for flags?

I'd just like to interject that we should keep in mind how useful our debating here is. I think we've covered both sides pretty well.

[distant gust]

I want to agree so hard, but I am deeply involved with a system that would benefit extremely from that and it feels a bit self-servingxD

[proper ferry]

The SWADE community is a big part of the "cards" push and use case in Foundry so I think that's more than allowed

[distant gust]

I agree, but this is a very cool opportunity and i want to stay as neutral as possible so nobody gets any inherent benefits

or rather, everybody gets the same inherent benefits

[tall current]

Here's how I would approach data inclusion:

Pick the top 10 card-based games that don't use the same card decks.

Determine the data needed for each of those games.

Merge those schemas together, de-duplicating liberally.

Use a degree of common sense to evaluate which entries in the data model are just too specific to make sense (mana? Eh, prolly not generic enough).

Now you have a data model that can support most games with little extension. And the extensions will nessesarily be very specific.

[distant gust]

how would you determine the top 10 card-based games? Would you include purely card based games like TCG's? What about board games?

[tall current]

It's the most common type of card deck and can be used to play hundreds of games. The designers of SWADE decided to use it because it's ubiquitous.

[distant gust]

fair point

[tall current]

That's an exercise for the reader 😜

The main point is: Make an ugly super schema, then de-duplicate, then cut.

Rather than adding one property at a time. Start with too much and remove things that make no sense until you're left with something justifiable.

And if 5/10 games had a face value... Maybe cards should have face values.

If only one had counters, maybe they don't make sense.

If 8 of them have some concept of "suit" that seems like a winner.

(in MTG I feel like that's color? But then I think cards can have multiple colors so that gets weird)

Imagine this case:

Artists making card decks. Seems like something that will happen.

If someone makes an awesome set of poker cards with special artwork, can they distribute it as a content module? Can it be a compendium that can be used in any game system?

Or will they need to package it into 7 different modules to support different systems?

Or will it just be a zip file of images, and the GM needs to put in the work to create a deck from then because it's just too much work for the creator to maintain multiple packages?

Scenes are pretty system agnostic. Actors and Items are not. I would really love to see Cards fall in the first category rather than the later.

[desert ibex]

The discussion is interesting, but it's not clear what you are actually proposing @tall current - from a nuts and bolts perspective?

[distant gust]

scenes are system agnostic because they don't let systems define anything about their data, only fill in existing values. I think the main issue here isn't actually related to cards at all. Foundry is from the ground built for the system to define the majority of the goings on. Modules then work with the existing data, or add their own as flags, as needed.
Now we've come to a situation where the reverse seems to be most beneficial, but the technical groundwork for that simply doesn't exist.

[tall current]

Assuming that module-defined schemas are out of the question, I think my proposal boils down to "support the data for as many hypothetical games as possible out of the box" with a minimum of common card deck types like poker, tarot, and others my limited knowledge can't call to mind.

[distant gust]

(which is why I'm suggesting less is more. Why reinvent the wheel? The flag approach has worked pretty well so far.)

[tall current]

Specifically, if there is a kind of card (example: poker cards) that many systems might use, it would be great if they didn't all have a slightly different implementation.

[distant gust]

That way you'll end up with schemas where 80% goes unused and 10% needs to be reimplemented as flags because it doesn't exactly fit the needs of the person working with it >_<

[tall current]

No solution is going to be perfect.

[distant gust]

agreed ^^

[desert ibex]

module-defined data schema is impossible for this update

[tall current]

Yeah, that.

[desert ibex]

my perspective is that if the game system itself is a card-based system, giving it the extra power is certainly helpful

[tall current]

I don't think systems shouldn't have the ability.

[desert ibex]

if we're talking about an add-on card game tacked onto an existing (non-card) system

they will just have to make do with schema-less flags

the module can always implement its own data schema for the flag object it uses

[distant gust]

module level schema definitions seems like a can of worms that needs its own entire update cycle

[desert ibex]

As for things like a standard poker deck, it certainly makes sense that there should be a built-in option for that - the best way to do that is something I am not sure about yet

[tall current]

Could Core define a card "type" and schema?

So a small number of card types are universal?

[distant gust]

you mean a generic card?

[desert ibex]

yes, there is a universal "base" card type

that doesn't require a system definition

it doesn't have any special schema (nor does it really need to?)

[distant gust]

will this generic card be able to be created via the API/UI?

like Card.create({type: "base"})

[tall current]

I mean for the case of poker cards, can core include the schema for that type of card on top of base without actually adding to the base card definitions?

I.e., exactly how a system does.

But available to all systems

[desert ibex]

maybe

I'll think about that

I'm trying to think what the value is that isn't captured by the base data schema

I guess really it's just the suit

[proper ferry]

man I have to run to go canoeing but good talk, I'll check back later.

[tall current]

And value

[desert ibex]

I've gone back and forth on whether suit belongs in the base card schema

[distant gust]

what type should value be?

and suit for that matter

[tall current]

Value, for a poker card, would be a number.

For a generic base? Probably string, or Number || String

[distant gust]

I'm actually not sure if the document schema model can do that

[tall current]

Then String

Though that makes little sense, it's the most flexible type.

But if poker cards are not supported by base but rather a core-defined subtype, then the value could be a number instead.

[distant gust]

see, we already run into an issue. I swade both of these properties (suit and value) are numbers xD

[tall current]

Suit is technically an enum

So a number is valid

[distant gust]

fair, though JS doesn't support enums

could be a constant

but that's neither here nor there

too much in the detail

[tall current]

Ultimately only the computer cares what the suit is as the user will always be presented with an image or a translated string.

[desert ibex]

If suit is added back to the data model it will be a string

[tall current]

Which works just as well in JS land.

[desert ibex]

with regards to the "value" of the card, I think that's a pretty ugly variable name because it's so generic, I had considered perhaps rank (number) as an alternative field name

[tall current]

Value is more broadly applicable I feel? Rank isn't a term I would use for, say, Uno.

But I don't disagree that value is problematic as a variable name...

[distant gust]

I would suggest face but that's already a thing

[tall current]

Which calls back a question from earlier: if a card has some value/rank is that a property of the card... Or the card face?

[distant gust]

I'm starting to see why MTG is considered turing-complete

[pastel crest]

Re: the system/module split, I think there's a few use cases that need to be possible:

1. I am playing in a system that defines a card schema. I can install and use any system independent module that uses cards without conflicts (assuming the system Dev has implemented things sensibly).

2. I have two modules that each define a card type (say, poker and Uno). These card types can be kept appropriately separate by standard API means, so that module developers can ensure they only interact with their own cards.

[red pawn]

Regarding the system data structure vs module data structure thing---

I will point out that just like every other document type, Flags exists in the data model if a module wants to construct its own data.

[uneven token]

Instead of (or in addition to) "marked", I would love to see an interface that lets players create a publicly viewable "tableau" (called a "pool" in my system, but tableau is probably the more common term in board gaming/RPG). But I know that is a lot more interface work and maybe not realistic.

As a system element, it would probably include true/false as to whether it is present in the tableaux and then have some coordinates within the tableau interface?

But I'm not nearly as experienced with development as the rest of those in the conversation.

"Marked" (aka how it works in UCS) is the next best option.

[red pawn]

i think this would be handled by generating a separate Cards Document of a 'stack' type.

[uneven token]

That makes sense. I guess the difference would be that there is a public-facing interface that goes with that stack. Similar to the way you would place a land or creature card in MTG out onto the table.

[red pawn]

Yeah, development hasn't fully kicked off on the UI side yet, so it remains to be seen- but i'm foreseeing the data objects making it reasonable to construct, if nothing else, Applications to handle things like this.

[uneven token]

If nothing else, I suspect you can just dedicate a scene for player pools/tableaus and let them switch between the map and the tableau whenever they need to. (Probably, building a custom interface like that is going to be beyond my capabilities...😆 )