It is currently 25 May 2020, 15:23
Text Size

Need advice: keep hacking at Snowfall?

Moderators: TheElk801, BetaSteward, LevelX, North, noxx, JayDi, jeffwadsworth, CCGHQ Admins

Need advice: keep hacking at Snowfall?

Postby catsmdogs » 25 Nov 2018, 23:28

Snowfall is my first attempt at implementing a card. I know it's on the tricky side.

I have successfully gotten my environment up and I can run units tests and manual server test mode, so I'm in a good spot that way.

I've written some basic cumulative upkeep tests and Snowfall specific tests. I think these are worth keeping even if my actual card implementation is a mess.

Finally, Snowfall itself. The codebase is REALLY nice so I think eventually I could get a working version.

The thing is, I see several different ways of organizing the ability/effect and there are layers of abstraction (like ManaEffect and related) where it looks like not only for making it easier to implement cards, but the type is key for implementing the rules of the game. So I'm lost when there are quite a few paths starting from other cards to follow.

The "whenever a player taps an island for mana" is very similar to Vernal Bloom which leads me towards TapForManaAllTriggeredManaAbility and AddManaToManaPoolTargetControllerEffect.

The "only spend this to pay cumulative upkeep costs" seems pretty straightforward to hack from Thran Turbine's pieces.

The fact that it's a "may" ability I think could be relevant given cards like Damping Sphere, although when I set up a test with Gruul Turf and a Snowfall+Island, without having implemented the ability as a "may" yet, Damping Sphere damped Gruul Turf but not the Island. So maybe if the extra mana comes from some other source's ability then Damping Sphere doesn't actually matter under the rules? In any case, I really have no line on how to make sure an implementation of the may ability gets applied at the correct scope (like do you choose as part of activating the ability, or as part of resolving the effect?!). I ripped some code from Blood Crypt that is my best guess at an appropriate "may" shell.

Then there's the snow-covered vs regular island bit. One effect that alters amount based on resolve-time info? Or implement two different effects, one for snow-covered or not, but at what scope do you dispatch them? This still seems like the way to go, because the for example conditional mana classes kinda want the mana specified up front to make the mana builder and whatever. And perhaps I don't need a builder... if it can't be used to cast spells??

So what I have is a lot of soup ingredients but no soup. I figure I ought to work out exactly how the "may" part should work, see what architecture choices get fixed by that, then use my piece parts to build out from there.

SO. Actual question: advice? Is this card just better left to someone who's built up more experience with the codebase? And if so, would maybe the tests I wrote be worth making available without obviously submitting them? Or has someone looked into this, already knows a gameplan? If you gave me a target like "the ability should extend this, the effect should extend that" I'm pretty sure I can carry it from there.

Oh, and I don't use git/github/intellij except for this so I haven't even figured out how to check my diff or do a pull request when the time comes. So this question is also about whether I would invest time in that, too.
Posts: 3
Joined: 20 Nov 2018, 22:42
Has thanked: 0 time
Been thanked: 0 time

Return to Developers Talk

Who is online

Users browsing this forum: No registered users and 1 guest

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 10 minutes)
Most users ever online was 1371 on 09 Feb 2020, 16:22

Users browsing this forum: No registered users and 1 guest

Login Form