Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Geronimoo]

https://github.com/Geronimoo/Geronimoo-s-Dominion-Simulator

So yeah, I've finally decided to open source my simulator. Since the official app will have a very simple AI (according to Jay) my simulator can be a good alternative: seemingly strong AI because of strong buy scripts and decent built-in play rules. Now we only need to write the playing interface that uses simulator engine. I already started with a basic GUI, but I suck and hope someone else is better at that stuff.

This is my first open source project (and setting up Github was a pain despite all the tutorials), so any advice is going to be helpful...

[^_^_^_^]

Question: I downloaded the zip file and unzipped it but I can't seem to figure out how to use the simulator itself. The ReadMe also comes up blank o.O.

[DStu]

+100

[ftl]

Awesome!!!

BTW, your code is very nice.

[ftl]

Question: I downloaded the zip file and unzipped it but I can't seem to figure out how to use the simulator itself. The ReadMe also comes up blank o.O.

If you want to just use the simulator, you don't need to get the source code, just go to http://dominionsimulator.wordpress.com/ and click on the 'launch the simulator' button in the top left.

[ecq]

Awesome!  Thanks for this.

DomDeck#doOverhandShuffle and DomDeck#doRiffleShuffle intrigue me.

[Geronimoo]

DomDeck#doOverhandShuffle and DomDeck#doRiffleShuffle intrigue me.

I coded these to find out if the shuffling IRL has an impact on the win rate. This was after I didn't reach the final in a real life tournament. I got last place in a match where according to simulations I had a 65% win rate and the girl finishing second had only 3%. I noticed I rigorously riffle shuffled while my opponents did 2 overhand shuffles (which isn't really shuffling), so I thought their less shuffled decks might have improved their win rate.
I found out the different shuffling has an impact, but sometimes more randomness was better and sometimes not. Also, I think my implementation of these shuffling techniques could be improved to better copy a human shuffling. Feel free to play with it/improve it/incorporate it into the editor.

[ecq]

DomDeck#doOverhandShuffle and DomDeck#doRiffleShuffle intrigue me.

I coded these to find out if the shuffling IRL has an impact on the win rate. This was after I didn't reach the final in a real life tournament. I got last place in a match where according to simulations I had a 65% win rate and the girl finishing second had only 3%. I noticed I rigorously riffle shuffled while my opponents did 2 overhand shuffles (which isn't really shuffling), so I thought their less shuffled decks might have improved their win rate.
I found out the different shuffling has an impact, but sometimes more randomness was better and sometimes not. Also, I think my implementation of these shuffling techniques could be improved to better copy a human shuffling. Feel free to play with it/improve it/incorporate it into the editor.

The bigger issue, especially in a tournament setting, comes when the human is aware of his or her shuffling patterns. 

It's easy to keep track of the general location of cards if you're just doing a couple of overhand shuffles.  If you're conscious about it, you can use the information when making game decisions.  You can also use different shuffles to impact game play.  Is your Mountebank near the bottom of your discard pile?  Make sure that part of the deck ends up in the middle so it doesn't miss the next shuffle.  Lots of terminal collisions recently?  Shuffle thoroughly.  Terminals nicely spread out?  Give the deck a couple of quick overhand shuffles.

Anyhow, I don't mean to derail this thread.  I think it's really cool that you were looking into this, and it's really cool that you've open-sourced the simulator so the rest of us can reason about these things.

[theory]

Also, I assume Geronimoo implemented a mostly random overhand shuffle, and that is a kindly but perhaps naive assumption to make of your opponents.

[Geronimoo]

So is anyone going to help me out with the playing interface? I'm a bit stuck there...

[ecq]

So is anyone going to help me out with the playing interface? I'm a bit stuck there...

I've been looking at the code here and there.  Programming in my spare time will be so much easier when Isotropic shuts down .  I think there are two things that make the play interface challenging, one legal/ethical and one technical.

On the legal/ethical side, writing a play interface that could be an alternative to the official app is begging for a cease and desist letter.  Currently the simulators will almost certainly be allowed to stick around because they don't compete with the official product but supplement it.  Transforming one into a single-player game seems like it crosses a line.

On the technical side, looking through the code, it seems like it's pretty hard to do.  The problem is that the card definitions are very tightly coupled with how they're played.  So, for instance, the ApprenticeCard class not only defines what Apprentice does but it also picks a card to trash.  It needs to give +1 action, ask the current player to pick a card to trash, then give +cards.  The current player would be a Java interface that could be implemented by a bot containing the current trashing logic or some code that prompts a human player for a card to trash.  Implementing this would mean gutting the code, though.

I don't think you should add a playing interface on account of the legal/ethical point; however, I do think that separating card definitions from play decisions is a good thing to do for other reasons (maintainability, interop, ability to swap out play styles, user-defined AIs, etc).

[Geronimoo]

Thanks for looking into it ecq. I don't think the legal/ethical thingy is an issue as long as we're not using the official card images.

The technical thingy is what's been keeping me from working further on it. I realized as you did that all the cards need to be refactored so the play decisions are no longer part of the card, but rather a stand alone AI-class(es).

I'm very curious to see how strong the AI will be of the official app, but if it's rather basic as suggested by Jay, the simulator engine should be a very strong alternative and it's going to be worth it to do all the refactoring.

If in the meantime anyone should start the work, I'll be happy to help, but for now I'm a bit bored with it.