Developer Plans

[Agetian]

@ friarsol: Yes, I noticed the ante not displaying correctly in the match UI a very, very long time ago (I think it's been like that for over a year, at the very least, and I'm not sure if it was ever right, at least since I started helping out with the project). Sadly, I wasn't able to figure out a way to fix it back in the day since I was never much into UI coding, hopefully someone will be able to fix it. Good news about the upcoming cards, by the way!

- Agetian

[friarsol]

@ friarsol: Yes, I noticed the ante not displaying correctly in the match UI a very, very long time ago (I think it's been like that for over a year, at the very least, and I'm not sure if it was ever right, at least since I started helping out with the project). Sadly, I wasn't able to figure out a way to fix it back in the day since I was never much into UI coding, hopefully someone will be able to fix it. Good news about the upcoming cards, by the way!

It's kinda gone back and forth between kinda working and not working at all. At one point it printed all the cards in it, but didn't actually clear out as you moved forward in the match, so it would show all cards anted in all games played.

[swordshine]

I'll try to convert Old Man of the Sea. Lots of codes are related to this single card in forge.game.StaticEffects. I hope Rootwater Matriarch might be scriptable after the convertion.

[Agetian]

My immediate dev targets are:
- Finishing the support for multiple card art (almost done, in the process of some final tweaking and will then try to do something about choosing the particular set for random cards instead of always the latest set);
- Continuing to work on foils (will add routines for generating foils in boosters and quest card pools, will possibly also add match/quest-based preferences for whether the player wants to play with foils or without them; I won't enable any of this by default until the deck editor is updated to visualize the foils and add foils to deck separately from non-foils though).
- Continuing to work on AI personalities (the project has been stagnant for a while; as soon as I finish my long-planned card-related work it's likely to be all AI work for me).

- Agetian

[Marek14]

My immediate dev targets are:
- Finishing the support for multiple card art (almost done, in the process of some final tweaking and will then try to do something about choosing the particular set for random cards instead of always the latest set);

One slightly off thing that would be nice would be if, in case of Zendikar basic lands, you could also choose "random, but full pictures only" and "random, but normal pictures only".

[Agetian]

@ Marek14: Hmm, sounds like an interesting option, but I'm not sure where exactly it'll fit in. On the one hand, if you have a handful of Zendikar lands in a quest or sealed/draft, you can deliberately choose to put/not to put certain ones into your deck, ditto the Constructed mode where you can compose your deck with any art in mind that you'd like. It sounds like a nice option for random color Constructed decks, but I'm not sure if it can become a global option with the current module split in mind (it might require some calls to Singletons that are currently deprecated elsewhere outside GUI and will become impossible after the module split is complete). Anyhow, I'll think about how this can be best implemented and I'll do something if possible.

- Agetian

[Marek14]

@ Marek14: Hmm, sounds like an interesting option, but I'm not sure where exactly it'll fit in. On the one hand, if you have a handful of Zendikar lands in a quest or sealed/draft, you can deliberately choose to put/not to put certain ones into your deck, ditto the Constructed mode where you can compose your deck with any art in mind that you'd like. It sounds like a nice option for random color Constructed decks, but I'm not sure if it can become a global option with the current module split in mind (it might require some calls to Singletons that are currently deprecated elsewhere outside GUI and will become impossible after the module split is complete). Anyhow, I'll think about how this can be best implemented and I'll do something if possible.

- Agetian

One option would be to make the syntax accept two numbers.

ZEN would be unlimited from Zendikar.
ZEN|1 would be a specific picture.
ZEN|1|4 would be random picture from range 1-4.

[Agetian]

@ Marek14: Hmm, to be honest that sounds like too much overcomplication for the deck format - in addition to one more numeric parameter for a card, it'll introduce the unwanted ambiguousness of the first numeric parameter (it will then either mean a specific art or the beginning of a random art range). Don't worry, I'll think about it and try to come up with something acceptable if I can

- Agetian

[friarsol]

Not particularly a feature, but I plan on going through as many of the keywords I can and adding reminder text. I know for me the keywords that released in the mid 00s I can never quite rememember what they do, and I'm sure we have plenty of people using forge who has no idea what some of them do.

After I get done with that, if Max's trigger changes still don't seem to be having issues (which I haven't noticed since the last fix, thanks Max). I'll add in the Phasing triggers and Teferi's Imp since it contains both triggers for examples for other scripters.

[Max mtg]

Not particularly a feature, but I plan on going through as many of the keywords I can and adding reminder text. I know for me the keywords that released in the mid 00s I can never quite rememember what they do, and I'm sure we have plenty of people using forge who has no idea what some of them do.

You can go even further and gather all keywords into a dedicated enum with their descriptions and possible parameter type [none (many common keywords), magnitude (k:suspend), cost (k:equip), creature type (k:offering), land type(k:~landtype~walk)]

[drdev]

Not particularly a feature, but I plan on going through as many of the keywords I can and adding reminder text. I know for me the keywords that released in the mid 00s I can never quite rememember what they do, and I'm sure we have plenty of people using forge who has no idea what some of them do.

You can go even further and gather all keywords into a dedicated enum with their descriptions and possible parameter type [none (many common keywords), magnitude (k:suspend), cost (k:equip), creature type (k:offering), land type(k:~landtype~walk)]

I second this idea. When I was working on supporting mana symbols in details, prompt, and abilities, I found keywords to be very tricky to work with in their current organization. There also is room to optimize things given how many String comparisons that are currently involved.

[Max mtg]

My challenges of the month:
1. Untie AI from game (module separation, lots of refactoring)
2. Background images loading. (You just start the download and it continues in its own thread, the interface is no longer blocked and you don't have to wait till it's finished). As an extra mile there could be implemented download by request (prioritize images of cards you are currenly playing with or building in deck editor).

[Hellfish]

Keyword changes

How would you guys feel about changing keywords in a pretty major way and make them more inline with abilities, giving them named parameters among other things? So CantBeBlockedBy or equip would become

Code: Select all

K:Type$ CantBeBlockedBy | Valid$ Creature.PowerGE3 | Description$ CARDNAME can't be blocked by creatures with power 3 or greater.
K:Type$ Equip | Cost$ 2 | Description$ Equip COST (COST: Attach to target creature you control. Equip only as a sorcery.)


Turning keywords into proper objects would allow them to take advantage of extending CardTraitBase and make it generally easier to implement proper text replacement.

[Max mtg]

Keyword changes

How would you guys feel about changing keywords in a pretty major way and make them more inline with abilities, giving them named parameters among other things? So CantBeBlockedBy or equip would become

Code: Select all

K:Type$ CantBeBlockedBy | Valid$ Creature.PowerGE3 | Description$ CARDNAME can't be blocked by creatures with power 3 or greater.
K:Type$ Equip | Cost$ 2 | Description$ Equip COST (COST: Attach to target creature you control. Equip only as a sorcery.)


Turning keywords into proper objects would allow them to take advantage of extending CardTraitBase and make it generally easier to implement proper text replacement.

That's the worst idea that can bloat cards with tons of useless data.
Keywords don't need decsriptions in scripts or explaination of what the parameter is - because that data is part of keyword's definition and should not be repeated on each card

Turning kw instances from string into objects is good idea, but do not use map<String,String> ever again. A keyword instance is to contain KeywordType enum member, and keyword's parameter (kw instance can use parameter type as generic) - looks like there's nothing else that is unique for each kw instance.

[Hellfish]

That's fine, it was just one idea.

The main thing I was after was letting the keyword itself track wether it's intrinsic or not, like SpellAbility,Trigger,ReplacementEffect and StaticAbility do now. Tracking wether it is "HIDDEN" or not also seems like a good idea.