作者: 機械伯爵
日時: 2002/5/19(19:29)
「P は Python の P ＜実戦編＞」
　〜やるぞ作るぞRPG！〜


NP-5 GUI化の検討

　本来はGUIにまで拡張する予定は無かったのですが、若干問題がでてきたので、
新しいシステムに進む前に、GUI化を考えてみたいと思います。

　GUI化には、直感的に操作できるというメリットがありますが、マウスによる
アプリケーションの操作は、慣れてもあまり速くならず、だんだんうざったく
なってくる、というデメリットがついてまわります。

　また、プログラミングも複雑になり、それだけプログラム構造もそれを理解
するための知識も必要となりますので、私個人としては(HSPのような、ホント
にお手軽なGUIアプリ作成システム以外)、あまりGUIアプリケーションは作りた
くないと思っていました。

　しかし、コンソール表示では、表示画面のクリアさえままならない、という
現状から、あえてGUI化を考えました。

　まぁ、発展的に考えれば、グラフィックの表示などの可能性もでてきたわけ
なので、あまり深刻に考えずにとりくんでみたいと思います。

※前回ようやく完成にこぎつけたメニューモジュールについても、基本的な方
  針はそのままで、GUI化してみたいと思います。

　GUIモジュールは、標準のTkinter(Python/Tk)を使用します（他のものを使う
には、まだ資料と経験が不足しているので）

　日本語表示については、どうもあまり面白いことになりそうにないので、ど
うしても、というときは裏技(画像表示)でごまかそうかと思います。

　また、Tkの本家、Tclだと、コマンドの拡張によるプログラミングスタイルが
基本ですので、数値処理とか画面処理とかあまり考えないでがんがん書いてい
くのが正統なのでしょうが、折角Pythonを使っているわけですし、RPGという拡
張の可能性が非常に高いゲームをプログラムする以上、今まで同様、オブジェ
クト指向・モジュール化推進の方向で、できるだけやっていきたいと思います。

　まず、非常に大まかな形から設計してみましょう。

　　入　力[Tk]
　　　↓
　　処　理[Python]
　　　↓
　　出　力[Tk]

　入出力を別モジュールにする必要はありませんが、GUIモジュールの内容はで
きるかぎり見映えと操作性だけに抑え、実際のゲーム進行や内容を扱うモジュー
ルは、分離しておくようにします。

　さらに、各々のモジュールが別々にGUIモジュールを呼び出すのはまずいので、
定石どおり代理人を使ってみましょう(無論、素人の私が理解できる代理人モデ
ルの意味なんて、この程度です。勘違いしてたら、誰か訂正して☆)

＜基本形１＞
　　GUI(入力)
　　　↓
　　代理人
　　　↓
　　各種処理モジュール
　　　↓
　　代理人
　　　↓
　　GUI(出力)

　これで、実装(GUI)にかかわるのは代理人だけになるので、GUIの変更などが
あっても変更は最小限で済むわけです。

※GUIと書いた部分は、実際はTkinterを使ったPythonによるインターフェイス
  をコーディングしてるだけですけどね。

　Tkinterのmainloop()が始まると、Tkinterを通してしかプログラムは呼び出
せなくなるので、ゲームの進行状態を管理するスケジューラがどうしても必要
になります。

　代理人がどの処理モジュールを呼び出すかについても、基本的にはスケジュー
ラに問い合わせることになります。

＜基本形２＞
　　GUI(入力)
　　　↓
　　代理人←スケジューラ
　　　↓
　　各種処理モジュール←→スケジューラ
　　　↓
　　代理人
　　　↓
　　GUI(出力)

　代理人とスケジューラをまとめてしまいたいのは人情ですが、激しい出入り
や、頻繁な仕様変更が予想される代理人の中にスケジューラを内包する危険性
は、とりあえず避けましょう。

　PythonはModula-3から受け継いだ強力なモジュール化機能を使えば、モジュー
ル化に必要な労力はほとんど必要無いはずです。

　あと、代理人はスケジューラから情報は得ますが、スケジューラ自身の情報
を更新するメッセージは、各種処理モジュールのみから行います。

　ホントは、スケジューラにも代理人を立てると良いのかもしれませんが、そ
こまで複雑にする必要はないでしょう(スケジュール情報を管理するクラスのメ
ッセージの出入りチェックをしっかりしておけば十分でしょう)。

　さて、これに各種データを管理するデータベースクラスを加えます。

　あまりやりすぎると機能分析アンチパターンに陥る(笑)ので、セーブファイ
ルのなどの入出力については、データベースクラスのオプションとします。

＜基本形３＞
　　GUI(入力)
　　　↓
　　代理人←スケジューラ
　　　↓
　　各種処理モジュール←→スケジューラ
　　　↓　　　　　↑
　　代理人　　　　↓
　　　↓　　　　データベース
　　GUI(出力)

　実際のRPGにおいて、スケジューラとデータベースが何をするかと言えば・・・

　スケジューラ・・・ゲームの進行(フラグ管理、現在位置管理)
　データベース・・・パーティ、キャラクターデータ（可変）
　　　　　　　　　　エネミーデータ（可変）
　　　　　　　　　　モンスターデータ（不変）
　　　　　　　　　　アイテムデータ（不変）
　　　　　　　　　　マジックデータ（不変）
　　　　　　　　　　NPCデータ（不変）
　　　　　　　　　　シナリオ，ダンジョンマップ（不変）
※NPC(Non Player Character)シナリオ内で登場する、主人公以外の固定キャラ。

　オブジェクト指向言語を使わずに、ちょっとしっかりしたコンピュータRPGを
作ろうと思うと、かなり詳細な企画書と設計図が必要になると思われます。

※そーいえば昔、ゲーム会社を立ち上げでメンバー募集してたので、プログラ
  マとして応募したけど、結局話が流れてしまった。そこで、中心となってた
  ゲーム会社に勤めてたという某氏は、RPGのプログラムなんて簡単で、データ
  の打ち込みだけが面倒だと言ってたが、それは、本当のRPGを知らなかったか
  らだろうと、私は思う。

　プログラムのフレームとしてはこんな感じとして、次からはゲームシステム
について再考してみたいと思います。

　　　機械伯爵