datamllab / rlcard

Reinforcement Learning / AI Bots in Card (Poker) Games - Blackjack, Leduc, Texas, DouDizhu, Mahjong, UNO.
http://www.rlcard.org
MIT License
2.91k stars 630 forks source link

GUI for Gin Rummy program #76

Closed billh0420 closed 4 years ago

billh0420 commented 4 years ago

I am working on a gui interface for my Gin Rummy program.

Is it ok with you for me to submit it?

There are two parts. Do you want the smaller part submitted first or both parts submitted at once?

The first part is a simple gui program with 8 python files. It does not interface with the rlcard environment. It has a menu bar, a preferences window, an about window, and the main window with 52 cards laid out in a 4 by 13 grid. A card can be clicked on and its name is printed in the console. A card can be right clicked or shift tapped and it flips over.

The second part has 22 python files. It interfaces with the rlcard environment of gin rummy.

daochenzha commented 4 years ago

@billh0420 Hi, thank you for the contribution. We are still working on your previous pull request. It takes time because we are not quite familiar with the game rule.

For the GUI, it seems that your GUI has lots of codes, since you mentioned there are 22 files. May I know more about your implementation? We would prefer to make the GUI simple and light-weighted in rlcard, e.g., the demo of Leduc Hold’em. Too fancy GUI may contains lots of redundant codes.

We would prefer to put more fancy GUI into a separated repo. We have implemented the GUI for Leduc Hold’em and Dou Dizhu with HTML and JS in a separate repo

https://github.com/datamllab/rlcard-showdown

We really appreciate your contribution, but I would like to know more about your GUI. Thanks.

billh0420 commented 4 years ago

The GUI uses tkinter to do the graphics. This is a standard python package. My code uses python only. I will give a line count and the names of my files (I don't know if that will help you):

This is about 2000 lines of code.

daochenzha commented 4 years ago

@billh0420 Hi, thank you for the update. I feel like for easier maintenance, we need to separate the GUI part from the environment and make it as a HumanAgent. Currently, the interfaces of Leduc Hold'em and UNO are implemented within the environment. I feel like it is not easy to merge your GUI under this design. Do you think separating the GUI as a HumanAgent makes more sense? We may work on it on the dev branch. Thanks a lot!

billh0420 commented 4 years ago

I have no problem of where to put my code. Which of the following two possibilities do you think best (or give a third suggestion):

Choice one: a) short program rlcard.examples.gin_rummy_human.py to run as a gui with human agent (this would be the equivalent of uno_human.py); b) a folder rlcard.rlcard.agents.human_gin_rummy_agent that holds the code and images.

Choice two: a) a folder rlcard.examples.gin_rummy_human that holds the code, images, and the short program to run the code.

daochenzha commented 4 years ago

Hi @billh0420 We have just updated the dev branch, where we separate the human agent from the environment.

I would suggest to follow the style in dev branch. Specifically, 1) Put gin_rummy game engine in https://github.com/datamllab/rlcard/tree/dev/rlcard/games 2) Put environment wrapper in https://github.com/datamllab/rlcard/tree/dev/rlcard/envs 3) Put human agent in https://github.com/datamllab/rlcard/tree/dev/rlcard/agents. We could follow the style as in https://github.com/datamllab/rlcard/blob/dev/rlcard/agents/leduc_holdem_human_agent.py 4) Put example in https://github.com/datamllab/rlcard/tree/dev/examples

We would really appreciate it if you could put your GUI in the human_agent. Separating out the GUI from env will benefit future maintenance. Please don't hesitate to let me know if you have any suggestions! Thanks!

billh0420 commented 4 years ago

There is a difference in the needs for the gui as opposed to a text based presentation. I need to show the moves of the opponent. The text based presentation doesn't report back as the moves of the computer player are accepted and processed. I keep a record of all moves made in the game so that could allow me to overcome this problem, but it would require more work.

The approach that I have been using is to have my code to request legal moves from the env. If it is a human turn to move, then I insure that the human makes a legal move. If it is a computer turn to move, then I ask the computer agent what action it will take. In either case, the move is shown in a gui manner. Finally, the action that was taken is posted to the env to carry out. The process is then repeated until end of game. This approach is more of the agent pushing to the env.

The text based presentation is more of the environment pushing the state information to the human player when it is his turn. This approach is more of the env pushing to the agent.

Would you accept this dual approach? Or do you want me to work around it and solve the problems of waiting for state information only when it is the human turn to play. In that case, the moves taken by the computer opponent(s) would have to be reconstructed and presented in the gui interface before the human is allowed to make a move.

daochenzha commented 4 years ago

Thank you for posting this out! This is exactly what we are thinking about. The current text-based presentation in the dev branch follows what you described, i.e, record the legal actions, actions of the other players.

We prefer this style over the agent pushing to environment for the following reasons: 1) it could make environment cleaner, since we put all the codes in human-agent side. 2) it is more scalable. Think about if we want to include a different GUI. With the new design, we just simply need to implement a new human-agent. However, with the old design, we may need to put more codes to environment, which makes it more and more difficult to maintain in the future. Also, the new design can also adapt to multiple human agents.

Thus, we wish to let the package be consistent and cleaner with the new design. It would be nice if you could reorganize your code a little bit. And we can work together to make your game better! Thanks!

billh0420 commented 4 years ago

I am close to finishing my GUI Gin Rummy program. There are png and svg images for the cards. I use only the png images.

My question is: Do you want me to upload the svg images also in case someone can make use of them?

The folder for the svg images is 8.5 MB. The folder for the png images is 4.4 MB. The folder for rlcard in total (including both images folders) is 45 MB.

On my apple computer, using the current version of the os, png images scale perfectly without looking jagged. Thus, I don't need to use the svg images.

daochenzha commented 4 years ago

@billh0420 Hi, png file will be good enough. We need to keep the library light-weighted. Before moving forward to GUI, could you first help us fix some issues in Gin Rummy engine? We need to make the engine well-structured with appropriate comments and testing scripts. See https://github.com/datamllab/rlcard/pull/71

billh0420 commented 4 years ago

I am about ready to upload my GUI Gin Rummy code.

I use the following two packages: tk and PIL.

My question: Are requiring these packages a problem? They would be optional if the user doesn't want to use the GUI code.

I use tk (version 8.6.8) to handle the GUI (windows, buttons, menus, etc). I don't think this would be a problem since it is probably already part of python.

I use the Python Imaging Library PIL that I obtained from pillow (version 5.2.0) to handle the card images.

daochenzha commented 4 years ago

@billh0420 tk can be ignored. Pillow can be directly put into setup.py. Also, we could an example of playing with GUI of Gin Rummy, with some comments about how to install tk in linux/windows.

billh0420 commented 4 years ago

Question 1. What is setup.py? Do I put pillow in there?

Question 2. In examples, I have one example of human playing against the novice model agent and another example of two novice model agents playing against each other. You want these examples placed somewhere else than in the examples folder?

Question 3. I don't know how to instal tk in linux/windows. I use anaconda to setup my python environment. I suspect that it would be the same in linux/windows if you use anaconda. If one is using anaconda it is straightforward to install tk and pillow for the versions needed. Is that sufficient?

daochenzha commented 4 years ago

When running pip install rlcard, the packages listed in setup.py will be automatically installed. You can put pillow in the install_requires

You can put both the examples in /examples

We can provide two common ways in the comment. One is the anaconda. The other is for Ubuntu since not everyone uses anaconda. For Ubuntu, we can install it with apt-get install python-tk. For other cases, users can search it on google. Do you think it is clear?

billh0420 commented 4 years ago

A) I made the following change for setup.py by adding the requirement for pillow:

    install_requires=[
       'numpy>=1.16.3',
       'matplotlib>=3.0',
       'pillow>=5.2.0',
       'termcolor',
    ],

Question: Are you going to test it? Do I test it (it will be some of amount of work to do so)? Or, do we just sight verify it? I know that pillow is in my search path for anaconda since otherwise it would not appear. Is pillow in the path that setup.py looks at?

B) Where do I put in rlcard directory the comment for the two common ways to install tk?

daochenzha commented 4 years ago

@billh0420 It looks perfect. To test whether it will work, you may follow the following procedure. First, create a new python virtual environment. Second, use pip install -e . to install rlcard and also the extra packages. Third, test some examples to see whether it will work. We will also test it once you upload the code.

You could put the comments in your example of running the GUI just like the human example for Leduc Holdem.

As a side note, it would be nice if you could take a look at this issue https://github.com/datamllab/rlcard/issues/98 I am curious whether further improvement is possible.