Aiming to multiplayer (and better structure)
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
21 posts
• Page 2 of 2 • 1, 2
Re: Aiming to multiplayer (and better structure)
by friarsol » 21 Sep 2011, 11:49
Wow.... Unbelievable.Max mtg wrote:Thanks, I have more interesting things to do.friarsol wrote:Well, then we should fix that too. A single entry point will make sure that every function that wants access is getting it the same way.Max mtg wrote:There never was only one point into cards inside a zone. You could always obtain a zone and query cards from it directly.![]()
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Aiming to multiplayer (and better structure)
by Sloth » 21 Sep 2011, 12:38
Well, the laughing smiley was a bit surplus, but tracking down functions that grab zones and query cards from it directly is tedious to say the least.
Solution: Make AllZoneUtil.getCardsIn(Zone) use Player.getCardsIn(Zone) and put your phasing filter in Player.getCardsIn(Zone). I volunteer in testing and fixing calls that get around this.
Solution: Make AllZoneUtil.getCardsIn(Zone) use Player.getCardsIn(Zone) and put your phasing filter in Player.getCardsIn(Zone). I volunteer in testing and fixing calls that get around this.
-
Sloth - Programmer
- Posts: 3498
- Joined: 23 Jun 2009, 19:40
- Has thanked: 125 times
- Been thanked: 507 times
Re: Aiming to multiplayer (and better structure)
by friarsol » 21 Sep 2011, 13:44
Ok. Fair enough.Sloth wrote:Well, the laughing smiley was a bit surplus, but tracking down functions that grab zones and query cards from it directly is tedious to say the least.
Max, you're right, it is tedious. I was just expecting the cleaned up code to be fully centralized.
Thanks for volunteering Sloth.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Aiming to multiplayer (and better structure)
by Max mtg » 21 Sep 2011, 14:23
It looked like Sol was pointing me what to do, and I've had enough of that refactoring last Sunday. So, maybe we should (have it all centralized)... but we can't have that for now.
That zone centralization is in relativelly good condition now. Player.getCardsIn(Zone) is an utility function, which wraps a CardList around what's found in zone.getCards(). Any code comes to querying zone anyway. We cannot make private getZone() in Player, nor limit the visibility of getCards(), because many pieces of code need zones themselves (to move a card to that zone for instance)
There are lots of places which need programmers' attention more than this zone-peeking.
That zone centralization is in relativelly good condition now. Player.getCardsIn(Zone) is an utility function, which wraps a CardList around what's found in zone.getCards(). Any code comes to querying zone anyway. We cannot make private getZone() in Player, nor limit the visibility of getCards(), because many pieces of code need zones themselves (to move a card to that zone for instance)
There are lots of places which need programmers' attention more than this zone-peeking.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Aiming to multiplayer (and better structure)
by friarsol » 21 Sep 2011, 14:45
Understandable. Refactoring is a huge drain, and will rarely feel as rewarding as adding new features.Max mtg wrote:It looked like Sol was pointing me what to do, and I've had enough of that refactoring last Sunday. So, maybe we should (have it all centralized)... but we can't have that for now.
That zone centralization is in relativelly good condition now. Player.getCardsIn(Zone) is an utility function, which wraps a CardList around what's found in zone.getCards(). Any code comes to querying zone anyway. We cannot make private getZone() in Player, nor limit the visibility of getCards(), because many pieces of code need zones themselves (to move a card to that zone for instance)
There are lots of places which need programmers' attention more than this zone-peeking.
I'll figure something out when I have some time to get everything on the same track. This way Phased Out cards will be ignored when requesting through that centralized pipeline, but during the Phasing portion of the Untap step they will be available through a unique function call.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Aiming to multiplayer (and better structure)
by Max mtg » 21 Sep 2011, 15:20
Ah... I see now, you wanted to find a place in the calls chain to intercept the cardlist and exclude the phased-out ones.
The first solution I'd suggest - leave those 16 cards with phasing and concentrate on Innistrad's double faced ones.
The second... would involve modifying DefaultPlayerZone to return two lists of cards - one for all cards and second for only phased in, to use the 1st one for displaying cards and second for all game rules.
The first solution I'd suggest - leave those 16 cards with phasing and concentrate on Innistrad's double faced ones.
The second... would involve modifying DefaultPlayerZone to return two lists of cards - one for all cards and second for only phased in, to use the 1st one for displaying cards and second for all game rules.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
21 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 38 guests