Collectible Card Game Headquarters

The named classes contain hardcoded data about players.

Code: Select all

    // Instantiate non-singleton tab instances
    private final IVDoc field0 = new VField(EDocID.FIELD_0, AllZone.getComputerPlayer());
    private final IVDoc field1 = new VField(EDocID.FIELD_1, AllZone.getHumanPlayer());

    private final IVDoc hand0 = new VHand(EDocID.HAND_0, AllZone.getComputerPlayer());
    private final IVDoc hand1 = new VHand(EDocID.HAND_1, AllZone.getHumanPlayer());


If we are to play other types of matches, I suggest the VMatchUI to be instantiated for every match with its specific options and appropriate players.

Doublestrike, please change the needed classes so that they are not singletons any more.

Similiar hardcode is found in forge.gui.match.controllers.CPlayers.update()

First of all, I don't think anyone appreciates being given orders, Max.

===

I'd be happy to have a look when I have time. This is not high on my list though so it's faster to do it yourself.

At present, the only thing to instantiate is a new Field and Hand for each player.

I would not recommend you re-instantiate the match UI each time, for four strong reasons:

1) Doesn't fix the problem: You'll run into a "hardcode" problem again, when the user tries to load a previous layout which had more players than their current layout. This cannot be avoided, unless the layouts are not saved.

2) Caching benefits lost: Currently, the UI loads once, and only once, at startup (or, it should be working that way ). By caching the various UI states, it will respond faster. Yes, there's a few issues to fix, but that's the general idea.

3) Inconsistency: The entire UI architecture is already built using enum singletons.

4) It's a lot of work: You'll be slaving away by yourself for a long time with little support or encouragement. People may even heckle you, which is no fun when you think you're doing a good thing.

If I was doing this, my solution would involve dealing with hard-coded values from the save file and instantiating fields/hands as appropriate.

Doublestrike wrote:First of all, I don't think anyone appreciates being given orders, Max.

===

I'd be happy to have a look when I have time. This is not high on my list though so it's faster to do it yourself.

At present, the only thing to instantiate is a new Field and Hand for each player.

I would not recommend you re-instantiate the match UI each time, for four strong reasons:

1) Doesn't fix the problem: You'll run into a "hardcode" problem again, when the user tries to load a previous layout which had more players than their current layout. This cannot be avoided, unless the layouts are not saved.

2) Caching benefits lost: Currently, the UI loads once, and only once, at startup (or, it should be working that way ). By caching the various UI states, it will respond faster. Yes, there's a few issues to fix, but that's the general idea.

3) Inconsistency: The entire UI architecture is already built using enum singletons.

4) It's a lot of work: You'll be slaving away by yourself for a long time with little support or encouragement. People may even heckle you, which is no fun when you think you're doing a good thing.

If I was doing this, my solution would involve dealing with hard-coded values from the save file and instantiating fields/hands as appropriate.

Orders? Ok, let's put it another way:
UI instantiates VMatch assuming that there is only one human and one AI. Does it at startup and probable instructs some components that there are only two specific players. With new game options this assumption becomes wrong. What should we do?

===
1. Should store several layouts based on number of players. Even just three: for 2, 3 and 4 ppl.
2. Not really a benefit. Change some starting conditions (number of players in our case) and you'll won't be able to use the cached instance.
3. Singletons - that is the worst that happened to forge ever since. Global variables meant that there is an only player, an only ai, no more than one match and game handled at a time. So, who else wants to deal with all of these to make a forge-based multiplayer server?
4. When you like the what you are doing there is no enslavement and you don't depent on others' opinion that much.

See, when you put it that way, it makes people want to get involved because of an interest to help you out, rather than being ordered to do something. It's a big difference.

I'm pretty sure it works fine with several players. I definitely tested it when I built it with that in mind.

The point of the forge.gui.match.nonsingleton package is to handle nonsingleton cases like the ones you're referring to. I can have a look this weekend and see what can be done to help. Do you have a branch started that I can work with?

@Max - match UI is now ready for multiplayer (except for avatars). I've added slots for up to 8 fields (more/less if you want, pretty easy) and up to 4 hands (also easy to adjust). A little ahead of schedule

@Everyone - Please delete the layout called "match_preferred.xml". I had to make a small addressing change that will affect previous saves. Everything else should dovetail neatly.

Max mtg wrote:

friarsol wrote:

Max mtg wrote: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

Per your request to avoid branches I've committed directly to the trunk. (The initial testing ground is in the home screen, under "Multiplayer" submenu.)

If multiplayer is now possible, you might want to add the rest of Elbrus, the Binding Blade since im pretty sure its not coded for

Doublestrike wrote:@Max - match UI is now ready for multiplayer (except for avatars). I've added slots for up to 8 fields (more/less if you want, pretty easy) and up to 4 hands (also easy to adjust). A little ahead of schedule

Per your request to avoid branches I've committed directly to the trunk. (The initial testing ground is in the home screen, under "Multiplayer" submenu.)

Thank you.
I ve had a great vacation with the X-Com and now it's time to return to the project

Hey, Doublestrike,

I have parametrized the IVDoc for you so that when you invoke getLayoutControl from an implementing class you get an object of matching type, and don't have to cast it from ICDoc to a specific type.

Hope you like it