Splitting GameActionUtil

[DennisBergkamp]

Another big file is GameActionUtil (I've been adding some new cards and mechanics to this file, my local file is over 11,000 lines now).
Splitting this should be much easier than CardFactory. But how do you guys think it should be split up?

GameActionUtil currently consists of:
- Upkeep effects (lots of code)
- "Play card" effects (Standstill, Gilt-Leaf Archdruid, Sigil of the Empty Throne, etc.)
- "Draw Triggered" effects (currently only 3 cards: Niv-Mizzet, Hoofprints of the Stag and Lorescale Coatl - but this will most likely grow as well
- Some misc stuff: exalted, lifelink, a check to see if Rafiq of the Many is in play, "vampiric effects" (Sengir Vampire, ...), Guilty Conscience triggers, ... not even sure if these should be in this file.
- Ally effects
- Landfall effects
- "Destroy card" effects, this is what I've been playing around with, I've added cards like Fecundity, Dingus Egg, Dingus Staff, Goblin Sharpshooter and Dauthi Ghoul
- "Player combat damage" effects (Shadowmage Infiltrator, Hypnotic Specter, etc.)
- Last but not least, State Based Effects (Glorious Anthem, Goblin King, Nightmare, Engineered Plague, Fervor, etc.) which I think takes up most of the code.

What do you guys think? Should it be split up in 7 - 8 parts ? Or maybe for now just split the Upkeep, State Based Effects and the rest into three separate files?

[Marek14]

Another big file is GameActionUtil (I've been adding some new cards and mechanics to this file, my local file is over 11,000 lines now).
Splitting this should be much easier than CardFactory. But how do you guys think it should be split up?

GameActionUtil currently consists of:
- Upkeep effects (lots of code)
- "Play card" effects (Standstill, Gilt-Leaf Archdruid, Sigil of the Empty Throne, etc.)
- "Draw Triggered" effects (currently only 3 cards: Niv-Mizzet, Hoofprints of the Stag and Lorescale Coatl - but this will most likely grow as well
- Some misc stuff: exalted, lifelink, a check to see if Rafiq of the Many is in play, "vampiric effects" (Sengir Vampire, ...), Guilty Conscience triggers, ... not even sure if these should be in this file.
- Ally effects
- Landfall effects
- "Destroy card" effects, this is what I've been playing around with, I've added cards like Fecundity, Dingus Egg, Dingus Staff, Goblin Sharpshooter and Dauthi Ghoul
- "Player combat damage" effects (Shadowmage Infiltrator, Hypnotic Specter, etc.)
- Last but not least, State Based Effects (Glorious Anthem, Goblin King, Nightmare, Engineered Plague, Fervor, etc.) which I think takes up most of the code.

What do you guys think? Should it be split up in 7 - 8 parts ? Or maybe for now just split the Upkeep, State Based Effects and the rest into three separate files?

Well, "State-Based Effects" is a bad name here (it means something different), better just call them "static effects". I think they should be definitely separate.

As for draw triggers, other possible cards for them are Diviner's Wand, Moonring Mirror, Kederekt Parasite, Mind's Eye, Phyrexian Tyranny, Psychic Possession, Spiteful Visions, Underworld Dreams

[DennisBergkamp]

Ah, you're right! Wow, I even made a class called "StateBasedEffects.java" which keeps track of these "static effects". I guess I completely misnamed it

[zerker2000]

Is it just me or should "some misc stuff" be moved to Combat?

[Rob Cashwalker]

I think it should be completely blown away.

Each individual card's code should be translated into an Execute method of a Command object, defined in CardFactory_{Type}. This Command is assigned to an array of Commands defined by the card. Whenever the state effects code would have executed the code it once contained it instead calls the execute method of the appropriate command for the card.

[DennisBergkamp]

Yes, this would be ideal. I will start messing around with this and move some of the code into Commands.

[zerker2000]

"Drat, foiled again!": I do remember thinking along the exact same lines, but ended up not posting for some reason .

[Rob Cashwalker]

this approach would open up the ability to keyword static pumps and other standardized static effects.