Collectible Card Game Headquarters

OK, later today or tomorrow I'm going to start a new SVN branch of Forge which will be used for the implementation of my next, rather big scale, project - AI personalities.

RATIONALE: Even though Forge does not feature a super advanced artificial intelligence system such as Minimax, it has a fun competitive AI that can challenge the player given the right cards and circumstances. However, one of the primary downsides to the current Forge AI as I see it is its eventual predictability - that is, since the AI makes pretty much the same choices in the same situations every time, it becomes predictable and sometimes you just know that you can go ahead and attack and not risk losing an important card because the AI won't trade early, or you have a feeling just when the AI will block your attack because it considers it's low enough on life, and so on. Therefore, implementing a system that would allow to vary the AI choices depending on personality setups (somewhat similar, even if initially on a lesser scale, to the chess engine personality systems) and, thus, eliminating predictability would make the game more fun to play, especially for people who have played Forge for a while and have, therefore, learned the common decision-making patterns the standard AI follows.

PROPOSED IMPLEMENTATION: It is planned that AI personalities will be stored as Java preference files same in format as the current configuration files Forge uses. The currently proposed location is "res/ai". In every mode except Quest, the default personality can be set in the Forge preferences from a list box similar to the one utilized for themes. The top option is "Random", which will choose a random AI personality from the available ones every time a match is started, but only once per match (so, if you play a best of three and play all three matches, the personality will be the same). Optionally, it might be possible and viable to implement an extra mode called "Random (Crazy)" or something like that, in which the personality will be randomized in every duel instead of in every match, so that the opponent will be absolutely unpredictable. For Quest mode, it should be possible to store a specific AI personality choice inside the deck file (this is *only* true for quest mode deck files), so that the profile will be chosen for the AI opponent every time. If no AI personality is stored inside the deck file, or if the personality configuration can't be loaded for some reason (e.g. the file does not exist), the game should respect the choice made by the player in the Forge preferences.

SIDE PROJECTS: As this project is being developed, relatively minor tweaks to the core AI system may be made or proposed.

DEVELOPMENT: Development will be made in a separate branch, as this is a rather global and big-scale project that may break things quite severely in the initial development stages. The implementation will be as non-intrusive as possible, the new file loaders and personality-related processing facilities will be implemented as separate classes which can then be hooked up to the AI function calls. Retrieving a given setting for a given AI profile should be as simple as calling a static method of a specialized class.

TIME FRAME: Active development should start within 1-3 days. There is no current ETA on the project. I'll try not to take too much time, but sadly my real-life work is likely to interfere with this project quite severely, so it might take a while (I want to make sure I do it properly and carefully, too) - all the more reason to start a separate branch for this project.

COOPERATION: All forms of cooperation are welcome - in the form of suggestions, advice, constructive criticism, coding assistance, and testing alike.

- Agetian

Don't store anything but cards in deck files, okay?
If there are any special AI instructions for any special deck type, it would be a much more honorable achievement to make AI recognoze deck type and choose a strategy.
In order to recognoze the deck, AI may scan the abilities of cards he was dealt (analyze their types, apitypes of abilities), and choose a strategy from the pool that is about to be developed.

My role - I won't be able to do as much as the last time, because the field is foreign to me. Will keep eliminating isHuman and isComputer from (trunk) code... not sure if it would be of help for you here.

Sounds very awesome! Just remember to make small, incremental improvements so it doesn't become "too big to merge" : ) When you get to a good point, I'll be happy to help test it out. Btw, be aware that I have a branch open right now too. I'm separating program data from user data. It mostly has to do with file IO and related constants and classes, so I don't /think/ it will impact you at all, but if I get done before you do, I'll help out with the merge.

@ Max Mtg: I see the rationale in not using the deck files to store any other data beyond cards, but in that case there will have to either be a different mechanism or no mechanism at all to associate a particular quest opponent with a particular AI profile/strategy if necessary. I agree though that improving the AI to be able to recognize useful strategy patterns based on card abilities is an amazing idea, and I'll eventually try to work towards that end as I work on profiles.

@ myk: Thanks a lot for your encouraging words and for your decision to help out with SVN merge idiosyncracies!

- Agetian

you may do anything with quest-related decks - they already contain so many fields, once Rumble has put all the card duplicatior rewards, the prized rares and whatever else into quest events files... there's also an icon and name for AI opponnet in that deck. So the whole file is not a deck but it's something inherited from the deck.

I am asking to add no extra fields in constructed mode decks.

Max mtg wrote:you may do anything with quest-related decks - they already contain so many fields, once Rumble has put all the card duplicatior rewards, the prized rares and whatever else into quest events files... there's also an icon and name for AI opponnet in that deck. So the whole file is not a deck but it's something inherited from the deck.

I am asking to add no extra fields in constructed mode decks.

Oh, sure thing, no worries then - this feature was only meant to be used for the quest mode anyway, so I'll only add this mechanism to the quest files.

- Agetian

Instead of adding extra data fields to the deck, I'd suggest using a separate file, like "deckname.ai" or "deckname.meta" (which could include any sort of deck data beyond the card list).

@ Rob: There are already .ai files being implemented as AI Profiles themselves, I was actually thinking about making it work like this: in case there is an .ai file matching the quest opponent's name, then the quest opponent uses that particular .ai file, but then I thought that maybe it'd be necessary to associate one and the same profile with several different quest opponents, so maybe it's actually a better solution to add one extra metadata field to quest decks (only to the quest ones containing metadata, not to the standard deck files) that would specify which .ai file to use?

- Agetian

Rob Cashwalker wrote:Instead of adding extra data fields to the deck, I'd suggest using a separate file, like "deckname.ai" or "deckname.meta" (which could include any sort of deck data beyond the card list).

The data separation principle has been sacrificed in favour of ease-to-edit. They have everything in a single file now - all that things that ought to be stored in some 4-5 tables if there were a fair relational model.

As I have seen (from the implemented property of mulligan threshold) - looks like the AIprofile is global for all AI players.
Is that correct? Keep in mind that there can be up to 7 AI players, that might want to use different strategies.

@ Max Mtg: AiProfile is currently employed as a class which contains means of loading all properties from all AI profiles, as well as a place to store all the loaded properties in a map, and static functions which retrieve the properties associated with the given player. So, calling AiProfile.getAIProp(player, property_name) retrieves the correct property value for property_name for the given player (it indeed does so in a multiplayer environment). I just tested this in a 7-player multiplayer game and, indeed, each player gets his own AI profile set which is then persistent in a match (as long as the per-duel randomization mode is not set, in which case it's random in each duel instead of in every match).

You got me thinking though - since it can probably be defined as a utility class, maybe it's worth calling the class AiProfileUtil instead of AiProfile or something along those lines?

Another important part that kind of bothers me is that the only way the Player class knows about its profile is via the aiProfile option (setAiProfile / getAiProfile setter-getter pair) - everything else is the responsibility of the current AiProfile class. I doubt that this implementation is optimal but it's the best I could think of after some consideration and experiments... not sure if it's actually worth it to get rid of the setAiProfile / getAiProfile in Player altogether and thus move this functionality over to AiProfile for it to be completely responsible for everything associated with the AI profiles, or, on the contrary, delegate some more of its current functionality to the Player class (though I doubt the latter will be a good option because Player instances are getting recreated in every duel, and, thus, it's a bad place for a more-or-less persistent storage of information, I actually already had to resort to a set of special methods in AiProfile to "remember" the currently associated profile name for each player so that the information doesn't get lost across duels in a match).

- Agetian

Oh, I didn't notice there is a map of players at the first glance. So it's expected to work properly in a multiplayer game.

Actaully, yes, that class is an auxiliary one. I mean there is no entity associated with it, so it's a collection of helper methods as far as I can see.

The Player class is not a best target to hold a reference to aiprofile. A player is the entity that initially has 20 lives, can be attacked and owns cards in different zones. And that aiprofile field would make totally no sense for HumanPlayer. So placing that field somewhere about AiPlayerController would be more logical.

The entity that is persistent throughout a match is LobbyPlayer, there are also PlayerStartConditions associated with each lobby-player. If you want to save any data between duels, you might add a field to LobbyPlayer.
I designed LobbyPlayer to represent a remote or local player who has joined a match and can chat, trade cards and be added as friend (in a far away future, if it ever comes true)

Oh, OK, I was actually looking at LobbyPlayer but didn't get the exact difference immediately. Thanks for the tips! I think for starters I'll rename AiProfile to AiProfileUtil then and also move the AI Profile-related fields and methods over to LobbyPlayer so that they are a) in a more logical place, b) are automatically persistent across duels if necessary.

- Agetian

Ok, I've made the necessary changes and made the code quite a bit cleaner by doing that. Now I'm at a different dilemma - I have two ways of actually accessing the AI property, one is via a call to AiProfileUtil, e.g.:

AiProfileUtil.getAIPropInt(ai.getLobbyPlayer(), AiProfileUtil.AIProps.AI_MULLIGAN_THRESHOLD);

The other is directly via a LobbyPlayer which just wraps a call to AiProfileUtil:

ai.getLobbyPlayer().getAIPropInt(AiProfileUtil.AIProps.AI_MULLIGAN_THRESHOLD);

Not sure which one would be the cleaner/better implementation, opinions are welcome. If the first one is alright, I'll get rid of the second one to avoid duplicate functionality in different places in the code.

- Agetian

I suggest
aiPlayer.getAi().getProperty(AIProps.AI_MULLIGAN_THRESHOLD)

1. Ai settings are mostly related to AiController - that's how the AI player should behave. It would be logical to access properties from there.
2. the getProperty method may get lobbyplayer if it needs any data from there (profilename, for instance)
3. The readability of properties enum will be improved if it's moved to top level.