About decoupling GUI from game

[Max mtg]

I thought of how would forge be playable from a remote host. Like a person or AI program is giving commands to forge to play certain cards and perform other actions. But how is it possible when ability factories have hardcoded calls to GUI?

It looks like to me that depending of type of active player the input method will vary: GUI for local human player, some api calls for local AI, and over network iteraction for one who plays remotelly - no matter against who.

That means that all players interactions should be untied from rules enforcement engine. I guess

Code: Select all

final Object o = GuiUtils.chooseOne("Choose first creature to exile", chooseGrave);

should turn into something like

Code: Select all

activePlayer.getCommuncation().chooseOne("Choose first creature to exile", chooseGrave)

Communication class will be able to show window to local player or send a message to a remote one and wait for him to choose - depending of the class that implements the IPlayerCommunication inteface to be designed.
It does not even require to remove all those if-else's for different actions for AI and human player. AI code might even stay in its place.

So, I think that all the human player interaction should be somehow wrapped to make an overload with a different behaviour possible.

[friarsol]

I like where this is headed and the possibilities of using a fake remote player to handle AI vs AI.

[moomarc]

This is when I wish I had more coding experience so that I could help out, but at the moment I'd do more harm than good. Sounds great though. Definitely a step in the right direction!

[silly freak]

Good idea, might just mention "Actor" as a better name than "Communication", though I'm weak on the naming department as well.

[Max mtg]

First step: remove getHumanPlayer() calls from GUI code - use FControl.getPlayer() instead.
I'll commit the prerequisites at the first opportunity - that is in 8 hours (if the site does now fall down again)

This should bring us a step closer towards controlling any player from UI, not just the only human.
It should bring the project closer to hotseat games (though it would be completelly senseless if an opponent would see your hand)

[moomarc]

First step: remove getHumanPlayer() calls from GUI code - use FControl.getPlayer() instead.
I'll commit the prerequisites at the first opportunity - that is in 8 hours

I don't really know the potential problems involved, but is it not worth waiting an extra day or two until after we release the RtR beta before we start changing every human player call?

[friarsol]

It seems like this may be something that's worth creating a branch for?

[Max mtg]

It seems like this may be something that's worth creating a branch for?

I'll commit prerequisites to trunk, they are not likely to break a lot.

As for the changes - yes, they are going to be massive.
A branch would be great (but I have little knowledge on merging and reintegrating them)... although I used to implement even larger changes without branches.

[friarsol]

A branch would be great (but I have little knowledge on merging and reintegrating them)... although I used to implement even larger changes without branches.

Think of it as decoupling massive compile/runtime errors from the trunk

[Max mtg]

A branch would be great (but I have little knowledge on merging and reintegrating them)... although I used to implement even larger changes without branches.

Think of it as decoupling massive compile/runtime errors from the trunk

Compile errors do not get commited from my side.
Runtime - yes, these are possible. On the other hand no headache for integration and merges into branches.

Generally, I do not want a branch because many other changes were made without them: the new UI by Doublestrike, my changing of predicates, new quest saves along with moving pets to data files, and cardprinted introduction a year ago. There was nothing that broke build for a significant time

[silly freak]

I'd say a branch is worth it when you can expect the whole feature to take longer to implement with unstable states in between. The GUI changes would be something I'd say would qualify. Changing to predicates was practically just refactoring, and extracting a Communication/Actor interface is as well.

Any real logic changes can be made after the refactoring, and since it's basically adding an additional implementation of that interface, there should be little error potential while the feature is unfinished. On the other hand, that means that the potential for conflicts is small.

[Doublestrike]

This is exciting! To add fuel to the fire, multiple playing fields in the match UI should be ready to go with minimal work.

@Max not sure what the big picture is but for multiplayer it may be best to not hard-code "human" or "computer" and perhaps have a list of Players with their types? Or, a list of Humans, a list of AI...just off the top of my head.

Cool!