[議論用] autogamesのプログラム構成について about autogames HOT 15 OPEN

あと、エラー処理用のクラスとそのテストを作る作業は僕に残しておいてくれると嬉しい

from autogames.

これじゃ足りないとか，分かりにくいとかあると思うので，意見が欲しいです．

from autogames.

具体的に言うと、

• server.pyは、ゲーム人数の管理をゲームクラス側ではなくてserver側で行った方が良いと思っています。あと個人の主観なのですが、dispatch関数という名前に親しみがなくて混乱することがありました。
• client.pyは、putとかget_fieldという関数名が良くないと考えています。gameクラスのメンバ関数名とかぶるので。あと、client側から次の手を送った直後にserverからの返事を待っていますが、次の自分の順番が回ってきたときに初めてserver側から返事が返ってくる、とかでいい気がしました。
• tictactoe.pyを含むgameクラスは、主要なメンバ関数名やメンバ変数名を異なるゲーム間で統一したいですね。そのために分かりやすい親ゲームクラスを作りたいですね。あと、プレイヤーのソケットアドレスはserverクラスやclientクラス内のみで操作して、gameクラスには持ち込まないようにしたいです。

from autogames.

自分で言ってて思い出しましたが、serverクラスにはclient登録関数とかゲーム開始関数とかも必要ですね。上のポンチ絵、色々至らないところが多くて申し訳ないです

from autogames.

ちょっとまって〜今日の夜、見てみます。休みで早く作業したいところすまんな

from autogames.

server.pyは、ゲーム人数の管理をゲームクラス側ではなくてserver側で行った方が良いと思っています。

ゲーム人数はゲーム固有の変数だから, ゲームクラスのメンバ変数であるべきで, だとしたら, ゲームクラス内で管理を完結させるべきだと思うんだけど. もし, サーバーでも管理することになると, サーバーにもゲーム人数をメンバ変数にもたせる必要が出てきて, 同じものを表す変数が２つ管理しないといけないのでトラブルを生みそう。

あと個人の主観なのですが、dispatch関数という名前に親しみがなくて混乱することがありました。

何かいい名前はありませんかな〜。。

client.pyは、putとかget_fieldという関数名が良くないと考えています。gameクラスのメンバ関数名とかぶるので。

賛成です。そもそも, gameクラスのget_fieldというメンバ関数も, なんかへんな感じがする. 自分でつけておいてあれだけど。game が get するわけじゃないという意味で。クラス名とメンバ関数は, 主語, 動詞の関係になっているといいとどこかで読んだ。

あと、client側から次の手を送った直後にserverからの返事を待っていますが、次の自分の順番が回ってきたときに初めてserver側から返事が返ってくる、とかでいい気がしました。

賛成です.

tictactoe.pyを含むgameクラスは、主要なメンバ関数名やメンバ変数名を異なるゲーム間で統一したいですね。そのために分かりやすい親ゲームクラスを作りたいですね。あと、プレイヤーのソケットアドレスはserverクラスやclientクラス内のみで操作して、gameクラスには持ち込まないようにしたいです。

賛成です.

from autogames.

ゲーム人数はゲーム固有の変数だから, ゲームクラスのメンバ変数であるべきで,

僕はserver側で管理できると考えています。管理と言っても、次がどのthreadの番かを管理するだけですが。
そもそも僕がserver側でゲーム人数を管理したいのは、別ゲームを導入する毎に新しく人数管理プログラムを書くのがめんどくさいかな、と思ったからです。

from autogames.

あのポンチ絵を書いたのは、僕と石田さんでプログラム構成を共有することによって無駄なプルリクエストの出し合いを防ぎたかったからです。
なるべく分かりやすい構成を目指しましょう！

from autogames.

あと、個人的にはclient側とserver側の両方でgameクラスを管理するのが馬鹿らしいように感じるのですが、これはしょうがないんですかね、、、

client側で次の一手を考えたい場合、やはりgameクラスを管理するしかない気はするんですが。

from autogames.

僕はserver側で管理できると考えています。管理と言っても、次がどのthreadの番かを管理するだけですが。そもそも僕がserver側でゲーム人数を管理したいのは、別ゲームを導入する毎に新しく人数管理プログラムを書くのがめんどくさいかな、と思ったからです。

game_manager で一回書いてしまえば, それを継承した個別のゲームには書かなくていいと思ってたけど、そうじゃないのかな

あと、個人的にはclient側とserver側の両方でgameクラスを管理するのが馬鹿らしいように感じるのですが、これはしょうがないんですかね、、、

client側ではゲームクラスを管理しなくても, get_field関数でサーバ側にあるゲーム・フィールドをとってきて, そのとってきたfieldを引数としたthink関数をclientがわにおけると思う、、

from autogames.

game_manager で一回書いてしまえば, それを継承した個別のゲームには書かなくていいと思ってたけど、そうじゃないのかな

ありがとうございます、そのとおりでした。
そうします

client側ではゲームクラスを管理しなくても, get_field関数でサーバ側にあるゲーム・フィールドをとってきて, そのとってきたfieldを引数としたthink関数をclientがわにおけると思う、、

think関数の中で、例えば、gameクラスには次に打てる手一覧を表示する関数とかcheckmate関数とか、field情報以上の情報が欲しい場合がある気がするんですよね。
まぁやりたい人はthink関数の中で自分でgameオブジェクトを作ってね、という感じになるんですかね

あと、ソケット通信は全てjsonで行うのがいいんですかね？json.dumpが便利なので。
そうするとすると、_send関数とかは全部jsonを使うように書き換えたほうが楽かも？

from autogames.

think関数の中で、例えば、gameクラスには次に打てる手一覧を表示する関数とかcheckmate関数とか、field情報以上の情報が欲しい場合がある気がするんですよね。まぁやりたい人はthink関数の中で自分でgameオブジェクトを作ってね、という感じになるんですかね

たしかに、そう考えるとクライアントがgameオブジェクトを作るのは自然ですな。 クライアントが作るgameオブジェクトとサーバー側でもってるものは違うものであるべきな気がする。たぶんクライアント側が, 戦略を考える時, 例えばNステップ後の手までを総当りとかするとき, checkmate, available_position``とかは必要 とかそういうのが必要なだけであって, game_managerクラスにある add_player、, whos_turn, go_next_turn`とかそのへんのマネジメント関数は必要ない気がする.

そう考えると, クライアント側に必要なのは特定のゲーム(tictactoe.py)のクラスであって, それに付随して継承元のGameManagerの関数もくっついてくるのは変な気がしてきた。そこで提案なんだけど, tictactoeのインスタンスをGameManagerのメンバ変数として扱うのはどうかな(提案構成)。イメージの説明になってしまって申し訳ないけど例えば, tictactoeクラスはいわばルールブックで, GameMangaerは試合の審判みたいに考えると, 提案構成は審判がルールブックをもっていることになって(has-a関係)辻褄があう. もとの継承スタイルだと, ルールブックは, 審判の一種である(is-a関係)ということになっておかしい気がする.

あと、ソケット通信は全てjsonで行うのがいいんですかね？json.dumpが便利なので。
そうするとすると、_send関数とかは全部jsonを使うように書き換えたほうが楽かも？

そう思う

from autogames.

クライアントが作るgameオブジェクトとサーバー側でもってるものは違うものであるべきな気がする。

これは確かにそのとおりですね。ということで、client側（ゲームのアルゴリズム用プログラム）は、必要に応じて勝手にgameオブジェクトを持ってもらうようにしたほうがいいですね。

tictactoeのインスタンスをGameManagerのメンバ変数として扱うのはどうかな

審判の例は、なるほど、となりました。（僕の頭が混乱しているだけかもしれない？）
とにかく僕も賛成です。で、まとめると、以下のような感じですかね？

server側

• serverクラスは、メンバ変数としてGameManagerオブジェクトを作る
• GameManagerクラスは、tictactoeクラスなど各ゲームクラスのオブジェクトをメンバ変数として持つ
• tictactoeクラスなど各ゲームクラスは、GameManagerと通信しやすいような親クラス(RuleBookクラス)を継承する

ただ現状を書きますと、ここでいうserverクラスとGameManagerクラスが一つにまとまったクラスをserverクラスとして使っていて、さらに、serverクラスが各ゲームクラスのオブジェクトをメンバ変数として持っています。コードも100行ちょっとに収まっています。
この場合、もはやserverクラスとGameManagerクラスで分ける必要はないのでは？と思いました。

client側

• clientクラスは、メンバ変数としてtictactoeクラスなど各ゲームクラス(server側と共通のクラスを使う)のオブジェクトをメンバ変数として持つ。
• tictactoeクラスなど各ゲームクラスは、clientが次の一手を打つためのthink関数を備えておく。
  (2019/08/25更新)
• clientクラスは、server.py(server1)と通信するためのプログラム(client1)とアルゴリズム用プログラム(僕はまずpythonで実装したので、agent.pyと名づけました。)と通信するためのプログラム(client2)を持つ。
• agent.py (に加えてagent.cppやagent.javaなども)の中ではclientクラスと通信するためのプログラム(server2)を持つ。

現状、client側はこのような実装になっています。

from autogames.

もしかするとこれ以上の議論は、これ以上の機能を実装しないと無意味になってしまうかもしれませんね。（今日一日めっちゃ頑張ったので、最初やりたかったことは形になってきたように思います。）

今後の予定としては、以下のような感じでしょうか。

• 別のボードゲームの実装
  • (石田さんがオセロとか実装してくれないかなぁ...)
• 別言語でのエージェント実装(例えばthink関数をjavaで書きたい)が出来るようにする。
  • となると、think関数はgameクラスから独立する気がする。clientクラスとエージェントプログラムは別言語で書かれているが、socket通信でjsonを受け渡しすることでゲーム情報を通信（？）
  • その場合、「serverプログラム(socket1のserver) - clientプログラム(socket1のclient + socket2のclient) - エージェントプログラム(socket2のserver) 」というようなプログラム構成になる（？）
• サーバを立てて、世界中の人と対戦できるようにする。
  • お金どうしよ
• WindowsやMacでも使えるようにする。
  • 実は今のままでも出来る説（謎）
• プログラミング初心者だがアルゴリズム実装はしたい人（例：情報系大学2年生など）でも簡単に使えるよう、READMEを充実させる。
  • インストール方法と使い方、実行可能環境と使える言語あたりを、メチャクチャ詳しく書く
  • とにかく見た目をカッコよくして、使えそう感を出す(プログラム実行中のgif入れたり、盤面の可視化を貼ったり、使える言語のロゴ入れたり、テスト環境とbuild statusを入れたり、、、)
  • autogamesの一言説明(パッケージの真下にかからら文字列)を、カッコよくする
• PyPIに登録してpipでインストールできるようにする
  • バージョン管理とか頑張る

from autogames.

@HiroIshida
kindly ping

上の2つのコメントについて、時間があるときでいいので、考えを聞かせて欲しいです。

from autogames.