Collectible Card Game Headquarters

it is currently based on r9515. i'm trying to get the minimax AI changes into the repository under this branch so it doesn't mess up main line development.

Thanks. How difficult is it to create and maintain branches? Will the non-AI parts of your project be able to sync with the main branch for bug fixes?

Braids, sounds great. I didn't think Forge would ever use minimax...maybe pigs really do fly?

Rob Cashwalker wrote:Thanks. How difficult is it to create and maintain branches? Will the non-AI parts of your project be able to sync with the main branch for bug fixes?

you're welcome! the difficulty is proportional to the skill & experience in dealing with version control systems. i have a lot fo both, although not w subversion specifically. i've already created the branch. i don't think we'll need another. the very nature of a branch is to provide a means of structured & tracked synchronization - through merging.

the non-AI parts could be merged from the ai branch into the trunk (the main line yall have been using) on a file by file basis. but i don't think that's going to happen very often, though.

maintenance is mostly my doing because instead, i'll be merging the changes in the other direction, from the trunk into the AI branch, perhaps weekly. it involves editing *around* nearly every trunk change by hand. for the most prt, i remove the old code that uses new ai method calls, and i change the incoming (trunk) code to use the new method calls. these changes occur on the braids-minimax branch only. that's how i found out about a lot of card specific code being taken out. i suspect itis going to get old fast for me. i may advocate (and beg and plead) for certain subtle changes to the trunk to make my life easier. especially changing references to certain fields into method calls.

if there's something unobtrusive (for example, a serialVersionUID) that i want on the ai branch and yet the trunk would benefit, i'll probably change the trunk myself and commit it as if it were a bugfix or new card, then merge it outward to the ai branch.

as for the braids-minimax branch, well, it began as a branch off of r9515. i copied in the latest minimax source. i should have committed at that point. but instead i ran svn update, because i thought i was supposed to do that before commiting. i should have specified -r9515 to update. instead it is essentially forcing me to merge all the changes from r9515 to present into the braids-minimax branch!!! i have yet to commit

edit 6/23: add quote and politeness.

mtgrares wrote:Braids, sounds great. I didn't think Forge would ever use minimax...maybe pigs really do fly?

thank you. minimax still might suck. game trees take up a lot of memory. i'm hoping the 1st gen ai can help with that.

right now, i'm aiming to make the game state unit testable and as a side benefit, to make it serializable so people can save in the middle of a game or match.

minimax ai is long term. i have some other wants, like lazy initialization of CardFactory, and loading .DEC or .mwDeck files from the deck editor. i want to build concensus first of course.

Lazy Initialization of CardFactory would be pretty handy. We probably want to change the Cards.txt files over to use an Oracle Text Field to display card info in the Deck Editor before that happens, otherwise we lose all the benefit of Lazy Initialization there.

friarsol wrote:Lazy Initialization of CardFactory would be pretty handy. We probably want to change the Cards.txt files over to use an Oracle Text Field to display card info in the Deck Editor before that happens, otherwise we lose all the benefit of Lazy Initialization there.

id' rather do this one step at a time. CardFactory's init was slowing unit testing so much, i edited main.properties to use a different card directory and put only 5 cards in there. i think we'll get a lot of benefit except for the deck editor; we can postpone that.

once i've updated and committed the latest braids-minimax branch **grumble**, i'll see about building concensus for lazy cardfactory and hopefully converting AllZone field access to method calls on the svn trunk "src"... otherwise i'm going to be a very very unhappy merger (merge maker?).

Braids wrote:id' rather do this one step at a time. CardFactory's init was slowing unit testing so much, i edited main.properties to use a different card directory and put only 5 cards in there. i think we'll get a lot of benefit except for the deck editor; we can postpone that.

Fair enough. At the very least it'll speed up the rest of the game aside from the Deck Editor. The Oracle Text is something that has been brought up a fair amount in the last few months, and is bound to happen sooner or later.

Braids wrote:once i've updated and committed the latest braids-minimax branch **grumble**, i'll see about building concensus for lazy cardfactory and hopefully converting AllZone field access to method calls on the svn trunk "src"... otherwise i'm going to be a very very unhappy merger (merge maker?).

Merge maker merge maker, make me a merge, diff me a diff, branch me a branch....

It might be a good idea to create a separate "Note:" field for the card txt files as this would allow us to remove the bug notes from the text line.

The value in the "Note:" field could then be added to both the text field for in game notice and to the oracle field for the deck editor.

I had done some initial work in this area a few months ago but never got it working and got busy with other areas of the project.

friarsol wrote:Lazy Initialization of CardFactory would be pretty handy. We probably want to change the Cards.txt files over to use an Oracle Text Field to display card info in the Deck Editor before that happens, otherwise we lose all the benefit of Lazy Initialization there.

Didn't I mention WAY-back wanting to convert the Text field to actually use the oracle text? Then all the scripts don't have to carry so much extra baggage to populate the text dynamically, just enough to deal with interaction.