Questions about Alternative Versions of Card Art

[luckylavs]

Hi,

I just have a couple questions about having different versions of Card Art in Manalink.

My first question is this: How many different versions of card art can I include for a single magic card?
For example, if I wanted to, could I create 10,000 different types of art for "White Knight" -- which would all be in the CartArtManalink Folder... White Knight.jpg, White Knight (1).jpg, White Knight (2).jpg...White Knight (9999).jpg? Or is there some hard-coded limit to how many I can have?

My second question is related-- I remember reading on another post that certain card art will appear in the game way more frequently than others. More specifically, the first couple of cards (e.g., White Knight.jpg and White Knight (1).jpg) you will see almost all the time in the game, meanwhile card art variations that are much later in the sequence (e.g., White Knight (16).jpg, if it existed) will rarely be seen in the game at all.

I'm wondering if this is possible to change -- why we can't just have each possible card art variation appear about as frequently as every other variation. i.e., can we just select a card art variation randomly from a pool of all possible choices, rather than having the game weight the first couple of card art variations more heavily?

Secondly, does the selection process get progressively less frequent the farther down the list you go (for example, would pulling White Knight (30).jpg be a lot less common than pulling White Knight (8).jpg, which itself is less common that White Knight (1).jpg? Or is it really more of a two step thing -- like you have White Knight.jpg and White Knight (1).jpg -- which are the special cases -- then any other possibility is is about as common as any other possibility.

Hope my questions make sense.

[Aswan jaguar]

If I remember correctly 25 pictures is the limit for a card.At lest for lands that I tested I couldn't get more to show.

[Korath]

Well, currently the function that picks which art version to show looks like:

Code: Select all

int
get_card_image_number(int csvid, int player, int card)
{ // 0x468160
  if (csvid == -1 || player == -1 || card == -1)
    return 0;
  else
    {
      int num = cards_ptr[csvid]->num_pics;
      if (num > 1)
        return (card + player) % num;
      else
        return 0;
    }
}

cards_ptr[csvid]->num_pics is the number in the "Num Pics" column in manalink.csv, which is why you couldn't get more than 25 to show for the basic lands. Neither cardartlib nor drawcardlib nor the exe have a built-in limit of 25.

player will be 0 for the human player, 1 for the AI. card is assigned sequentially for a given player's cards (both real ones and the orange effect cards) as they're created and put into his player's hand/onto the stack/onto the battlefield; this is why lower-numbered art versions are seen more frequently.

Replacing get_card_image_number() is easy. But it's going to get the same parameters, and it has to always give the same result when given the same parameters, at least on a given run of the game. If we accept that you'll get different art versions on all your cards if you reload a game, and someone's willing to put together all 938 or whatever versions of basic swamp, I can replace the function with something less biased.

[luckylavs]

Hi Korath,

Yes, I would be in favor of an alternative solution, if it is possible, and if it isn't too much of a pain to implement.

More specifically -- Rather than relying on "card" and "player" to select a particular card art variation, is it instead possible to return a randomly chosen number from 1 to num? (And I am assuming here that returning 1 will mean that the first card in the sequence is selected, e.g., White Knight.jpg, while returning num will mean that the last card in the sequence is selected, e.g., White Knight (num-1).jpg.

Because to me, it seems strange that the variable "card" (how many cards are currently in play/on the stack?) and the variable "player" (whether the given player is AI or human?) have any type of bearing on what particular card art variation should be selected.

Because if the card stack never grows to be a particular size in the current game, I take it you just never will see card art variations with indices that are greater than the the current "card" stack size.

Meanwhile, as I have also gathered -- the initially dealt cards (on game start) are always going to be assigned card art with indices of lower values, because I imagine these cards are placed on the stack early in the game.

I don't know how easy it is to change the current solution to a random one, as you have said:

"But it's going to get the same parameters... on a given run of the game."

Does that mean you can't change the parameters of this function? If so, I suppose one idea is continue to pass "card" and "player" -- just don't use them in the card art selection function.

Then maybe you can call a function from within this function to return a random number in the relevant range?

You have also said:
"But... it has to always give the same result when given the same parameters, at least on a given run of the game."

Will a randomly chosen return value defeat this condition?

[Korath]

The logic behind the way it's currently done is that this function isn't run once and the result remembered; it's recomputed every time the card is redisplayed. (Dragged around, clicked on, becomes activateable or unactivateable or tapped, gains/loses abilities, you name it.) Picking a random number each time would make it constantly flicker between different card arts. player/card are about the only things that remain constant for a given card.

[luckylavs]

My preferred solution would have been-- for each card in a given round of magic, randomly choose a card art index upon initialization of that card and persistently store the chosen index. Then, you wouldn't have to tie its card art index value to the size of the "card" stack. You also wouldn't have to constantly recalculate its card art index value. To me, recalculating an answer that has already been calculated a hundred times over seems inefficient. Although I'm not an expert in these things.

But it sounds like the above solution would be a major pain to implement. Like you would need some kind of major overhaul in how the underlying core mechanics of the game worked.

So how about the below solution in the alternative?

What if... at the beginning of each Magic round, we randomly select just one integer (for example, in the range of 0 to 1 million). We make this integer a global variable, so we can access it in get_card_image_number without having to pass it over. Thus, the parameter list for that function can remain intact.

My proposed solution is something to this effect:

if (num>1)
return (randomint +(card + player)) % num;
else
return 0;

It's basically the same process that was occurring before, but it is shifted forward by a random amount each Magic round.

I'm thinking this satisfies the second constraint as well, since all calculations are using a constant value of randomint for the duration of the round. You will therefore always get the same output when given the same input.

What do you think?

---

Oh, and just an aside -- it may be related to this problem, or it may be a separate problem entirely. Earlier you mentioned that it looks kind of strange when card art constantly changes during the course of the game. Well -- when I have a card in play which has a card art index greater than the first card in the sequence -- for example, let's say I have White Knight (1).jpg on the board -- well, as soon as that card goes to the graveyard, the card art changes back to the first card in the sequence -- White Knight.jpg. So the card art changes. Not that this is the biggest deal in the world -- It doesn't affect actual gameplay. Still, it looks kind of funky.

Wonder what is causing this.

[gmzombie]

the one thing i could see with that is most cards do have multiples and would probably slow down the engine a lot due to how many cards come out.

[Korath]

There isn't going to be a measurable performance hit on modern hardware no matter what we do here; but if we're talking efficiency anyway, it's hundreds of times faster to recompute this value than to store and fetch the previous value from main memory.

The way it's currently done made perfect sense when this was first released; of the cards MicroProse made, only the basic lands, Mishra's Factory, and Strip Mine had more than one art version, and each of those only had four. (Fallen Empires and Ice Age had been released, but weren't in the game.)

As it stands now, no card has more than 11 versions in the standard art directory except for basic lands, so it still makes sense. Remember that the card index increases continuously; it's a very unusual game where you draw fewer than 11 total cards. Even at 25, the bias is small enough that it's hard to notice if you weren't already aware of it.

Cards that aren't in a hand, on the stack, or in play have no information stored about them at all except for an id saying which card type it is, which is why they always use the first artwork version. It's not remotely practical to change that; we'd have to rewrite large swathes of the exe that haven't been reverse-engineered yet, and large swathes of code in C as well (much more of which touches the deck[][], graveyard[][], and rfg[][] arrays directly than has any right to).

Anyway, again, if someone's willing to put together the zillion different swamp/island/etc. images, I'll fix the function so that they can all get displayed in roughly equal frequency.

[luckylavs]

Well... I don't know how much my own vote counts for anything -- But I for one, would appreciate if this function was fixed so that the images were displayed in roughly equal frequency. That is, if it is an easy fix, i.e., not too much trouble from your end.

Because I would like to add a ton of variations to cards already in the game. Also--Aswan Jaguar (above) said he was trying to get lands to appear past 25 and he experienced some difficulty with that (although admittedly, the reason for this may actually be what you said above--he didn't update the numpics in the csv file, rather than what we are discussing here).

Without having any hard data, I'm guessing there are other art designer-type people out there, who are not voiced here, that would feel similarly.

And as for the card art reverting back to its first version when it goes to the graveyard... Sounds like it's too much of a hassle to change... we're just going to have to live with it.

But this other thing sounds fixable -- so if you ever get around to fixing it, I would greatly appreciate it. I can't speak for other people in the Manalink community--but I'm guessing they would appreciate it as well.

[stassy]

And all these made entirely mod-able through some editable config file would be nice