検討して、うまくいきそうならOSS化する
初期調査
このプロジェクトの大部分、特にゲームのロジック、キャラクター管理、アイ
テムシステム、バトルシステム、そしてHTMLの生成方法は、25年前のウェブ技
術の典型であり、当時の制約の中で非常に高度なゲーム体験を提供しようとし
た努力が見て取れます。
- Perl CGIとファイルベースのデータ管理:
- 当時としては一般的: 25年前のウェブアプリケーションでは、Perl
CGIとファイルシステムへの直接的なデータ保存は一般的な手法でした。
データベースが普及する前、あるいは小規模なアプリケーションでは、手
軽で実装しやすい方法でした。- スケーラビリティと堅牢性の課題:
しかし、現代の視点から見ると、これは大きな課題を抱えています。
- パフォーマンス: ファイルI/Oはデータベースに比べて遅く、同時ア
クセスが増えるとボトルネックになりやすいです。- データ整合性: flock によるファイルロックは使用されていますが、
複雑なトランザクションや複数ファイルにまたがる整合性の保証は困
難です。データの破損リスクも高まります。- クエリの複雑さ: 特定の条件でデータを検索・集計する際に、ファイ
ルを直接読み込んでパースする必要があり、非常に非効率です。- 開発・保守性: データ構造がファイル内の文字列フォーマットに依存
するため、変更が難しく、バグの温床になりやすいです。- HTMLの直接生成: Perlスクリプト内でHTMLタグを直接生成する方式は、当
時のCGIでは一般的でしたが、プレゼンテーションとロジックが密結合し
ており、デザイン変更や機能追加の柔軟性が低いです。- ゲームロジックの深さ:
- 25年前の技術スタックで、これほど多岐にわたる（キャラクター作成、詳
細なバトル計算、職業システム、アイテム、オークション、チャット、マ
クロ対策の萌芽など）ゲーム機能を実装している点は、当時の開発者の熱
意と技術力の高さを物語っています。特に、職業ごとの特性や必殺技、装
備の特殊効果など、RPGとしての深みは非常に印象的です。- セキュリティの課題:
- 当時の一般的な慣行に従っているため、現代のセキュリティ基準から見る
と多くの脆弱性（例: パスワードの弱いハッシュ化 crypt, 入力値のサニ
タイズ不足、セッション管理の甘さなど）が存在する可能性が高いです。3年前の近代化（RedisとDocker化）
この古いコードベースに、比較的新しい技術が導入されたことで、運用面と特
定の機能において大きな改善が図られています。
- Docker化:
環境構築とデプロイの容易化: 25年前のPerl CGIアプリケーションを現代
の環境で動かすのは非常に困難ですが、Dockerによってその障壁が劇的に
下がりました。依存関係の管理、環境の再現性、デプロイの自動化が可能
になり、開発・運用が格段に楽になっています。分離と隔離: アプリケーションがコンテナ内で動作するため、ホストシス
テムへの影響が少なく、より安全に実行できます。- Redisの導入（特にマクロチェック）:
- パフォーマンスとリアルタイム性: ファイルI/Oのボトルネックを回避し
、ユーザーの行動履歴（アクセス頻度、IPアドレスごとの利用状況など）
を高速に記録・参照できるようになりました。これにより、マクロ（ボッ
ト）の検知がより効率的かつリアルタイムに行えるようになっています。- 既存システムへの影響最小化:
ゲームのコアロジックを大きく変更することなく、外部の高速なデータス
トアを導入することで、特定の課題（不正対策）を解決しています。これ
は、レガシーシステムを段階的に改善していく良いアプローチです。- 外部サービス連携: reCAPTCHA/Turnstile、Discourse、メール送信といっ
た外部サービスとの連携も、現代のウェブアプリケーションでは一般的で
あり、不正対策や運用通知の強化に貢献しています。総合的な再評価
このプロジェクトは、25年前の堅牢なゲームデザインと、3年前の現代的な運用・
セキュリティ対策が融合した、ユニークなレガシーシステムと言えます。
- ゲームとしての魅力: 25年前の技術的制約の中で、これほど詳細で奥深いゲー
ムシステムを構築したことは、当時の開発者の情熱と創造性の証です。テキス
トベースながらも、プレイヤーを引き込む要素が多数盛り込まれています。- 技術的課題の克服: DockerとRedisの導入は、古いPerl
CGIアプリケーションが抱える運用上の大きな課題（環境構築の困難さ、リア
ルタイム処理の限界）を、コアコードの全面的な書き換えなしに解決しようと
する、非常に実用的なアプローチです。特にマクロチェックにおけるRedisの
活用は、当時のゲームが直面していたであろう不正行為の問題に対し、現代的
な解決策を適用した好例です。- 残された課題:
しかし、ファイルベースのデータ管理や密結合なHTML生成といった、オリジナ
ルのアーキテクチャに起因する根本的なスケーラビリティ、保守性、セキュリ
ティの課題は依然として残っています。大規模なユーザーベースや複雑な新機
能の追加には、さらなるアーキテクチャの見直しが必要となるでしょう。結論として、このプロジェクトは単なる古いコードではなく、時代を超えて進
化し、特定の課題を克服してきた歴史を持つ、非常に興味深い事例です。
改善案
- 段階的な改善案 (Incremental Improvement)
このアプローチは、既存のPerl
CGIコードベースを大規模に書き換えることなく、セキュリティ、パフォーマ
ンス、運用性を向上させることに焦点を当てます。コストとリスクを抑えつつ
、システムの寿命を延ばすことを目的とします。目標:
- セキュリティ脆弱性の軽減
- パフォーマンスの最適化
- 運用・保守性の向上
- 既存のゲームロジックを最大限に活用
主要な改善点:
セキュリティ強化:
入力値の厳格な検証とサニタイズ: 現在のコードでも一部行われています
が、全てのユーザー入力（特にCGIパラメータ）に対して、より厳格なバ
リデーションとエスケープ処理を導入します。PerlのCGI.pmやHTML::Enti
ties、URI::Escapeなどのモジュールを適切に使用し、XSS (Cross-Site
Scripting) やSQLインジェクション（ファイルパス操作など）のリスクを
低減します。パスワードのハッシュ化の強化:
crypt関数は現代のセキュリティ基準では不十分です。Crypt::BcryptやCr
ypt::Scryptのようなモジュールを導入し、より強力なハッシュアルゴリ
ズムに移行します。既存ユーザーのパスワードは、ログイン時に新しいハ
ッシュ形式で再保存するなどの移行戦略を検討します。セッション管理の改善: 現在のセッション管理が不明確なため、より堅牢
なセッション管理メカニズムを導入します。Redisをセッションストアと
して活用することで、セッションハイジャックのリスクを低減し、スケー
ラビリティも向上させます。アクセス制御の徹底: 全てのCGIスクリプトが適切な認証と認可チェック
を行っているか確認し、不足している箇所を補強します。エラーハンドリングの改善: エラーメッセージに機密情報が含まれないよ
うにし、ユーザーには一般的なエラーメッセージを表示します。定期的なセキュリティ監査: コードベースの脆弱性スキャンツール（Perl
の静的解析ツールなど）の導入を検討します。パフォーマンス最適化:
- Redisのさらなる活用:
- 頻繁にアクセスされる静的/半静的データのキャッシュ: ff.ini,
syoku.ini, item.ini
などの設定ファイルや、モンスターデータなど、頻繁に読み込まれる
が更新頻度の低いデータをRedisにキャッシュします。これにより、
ファイルI/Oのオーバーヘッドを大幅に削減できます。- リアルタイム性の高いゲーム状態の管理:
バトル中のHP、WT、バフ/デバフなど、頻繁に更新される一時的なゲ
ーム状態をRedisで管理することで、ファイルへの書き込み頻度を減
らし、パフォーマンスを向上させます。- ランキングや集計データのキャッシュ: 頻繁に計算されるランキング
データなどをRedisにキャッシュし、表示速度を向上させます。- Perlスクリプトのプロファイリングと最適化:
Devel::NYTProfなどのツールを使用して、スクリプトのボトルネックを特
定し、効率の悪いループやファイルI/Oを改善します。- Webサーバーの最適化:
Apacheの設定を見直し、CGIの実行効率を最大化します。可能であれば、N
ginxをリバースプロキシとして導入し、静的ファイルの配信を高速化し、
動的コンテンツのリクエストをApacheに転送する構成を検討します。- 画像配信の最適化: ffbattle/images/
ディレクトリの画像をCDN（Content Delivery
Network）経由で配信することを検討し、ロード時間を短縮します。運用・保守性の向上:
- コードの整理とリファクタリング:
- 大規模な書き換えは避けますが、共通の処理をサブルーチンやモジュ
ールとして抽出し、重複コードを削減します。- 変数名やサブルーチン名をより分かりやすいものに変更し、コメント
を追加して可読性を高めます。- HTML生成ロジックとビジネスロジックの分離を部分的に試みます（例
:
HTML::Templateのようなシンプルなテンプレートエンジンを導入）。- ロギングの強化:
ffblogの機能を拡張し、より詳細な情報（エラーのスタックトレース、ユ
ーザー操作の追跡など）を記録できるようにします。ログのフォーマット
を標準的なもの（JSONなど）に統一し、ログ収集・分析ツール（Fluentd,
Elasticsearch, Kibanaなど）との連携を容易にします。- 自動テストの導入: 重要なゲームロジックやCGIスクリプトに対して、Per
lのテストフレームワーク（例: Test::More）を用いたユニットテストを
導入し、変更によるデグレードを防ぎます。- Docker環境の改善:
- マルチステージビルドを導入し、Dockerイメージのサイズを削減しま
す。- コンテナのヘルスチェックを追加し、サービスの健全性を監視します
。- ログの標準出力へのリダイレクトを徹底し、Dockerのロギング機能を
活用します。メリット:
- 既存のコードベースを再利用するため、開発コストと時間が比較的少ない。
- 段階的に改善を進められるため、リスクが低い。
- ゲームのコアな「味」を維持しやすい。
課題:
Perl CGIの根本的な制約（スケーラビリティ、モダンな開発手法との相性）
は残る。古いコードの複雑性や技術的負債を完全に解消することは難しい。
現代的なUI/UXの実現には限界がある。
- 完全な再構築案 (Complete Re-architecture / Rewrite)
このアプローチは、ゲームのコアロジックとデータを完全に新しい技術スタッ
クで再構築することを提案します。長期的なスケーラビリティ、保守性、開発
効率、そして現代的なユーザー体験の提供を目的とします。目標:
- 高スケーラビリティとパフォーマンスの実現
- 開発効率と保守性の劇的な向上
- 堅牢なセキュリティ基盤の構築
- モダンなユーザーインターフェースとユーザー体験の提供
- 将来的な機能拡張への対応
推奨技術スタック (例):
バックエンド (APIサーバー):
言語/フレームワーク: Python (FastAPI, Django REST Framework)
または Node.js (NestJS, Express)
- 理由:
豊富なライブラリ、活発なコミュニティ、Web開発における高い生産
性。Pythonはデータ処理やゲームロジックの実装に適しており、Node
.jsはリアルタイム性の高い機能（チャットなど）に適しています。データベース: PostgreSQL (リレーショナルデータベース)
- 理由: ゲームのキャラクターデータ、アイテム、職業など、構造化さ
れたデータ管理に最適です。ACID特性によりデータの整合性が保証さ
れます。キャッシュ/リアルタイムデータ: Redis
- 理由: 既存の活用実績があり、高速なキャッシュ、セッション管理、
リアルタイムなゲームイベント処理（例: バトル中の状態更新、チャ
ットメッセージキュー）に引き続き利用できます。ORM/ODM: SQLAlchemy (Python) または TypeORM (Node.js)
- 理由: データベース操作を抽象化し、コードの可読性と保守性を向上
させます。認証/認可: JWT (JSON Web Tokens) または OAuth 2.0
- 理由: セキュアでスケーラブルな認証メカニズムを提供します。
ロギング: 構造化ログ (JSON) を出力し、Elasticsearch, Fluentd,
Kibana (EFKスタック) などで集中管理・分析。フロントエンド (Webアプリケーション):
- フレームワーク: React, Vue.js, または Angular
- 理由: コンポーネントベースの開発により、複雑なUIを効率的に構築
できます。モダンなUI/UX、SPA (Single Page Application)
の実現に適しています。- スタイリング: Tailwind CSS, Material-UI, または Bootstrap (最新版)
- 理由: 迅速なUI開発と、カスタマイズ性の高いデザインを実現します
。既存のスキン機能も、これらのフレームワーク上で再実装すること
で、よりリッチな表現が可能になります。- ビルドツール: Webpack, Vite
- 理由: フロントエンド資産の最適化と高速な開発体験を提供します。
インフラストラクチャ:
- クラウドプラットフォーム: AWS, Google Cloud Platform (GCP), または
Microsoft Azure
- 理由:
高いスケーラビリティ、可用性、セキュリティ、マネージドサービス
（データベース、コンテナオーケストレーションなど）の利用。- コンテナオーケストレーション: Kubernetes (K8s)
- 理由: マイクロサービスアーキテクチャを採用する場合、コンテナの
デプロイ、スケーリング、管理を自動化します。- CI/CD: GitHub Actions, GitLab CI, または Jenkins
- 理由: コードの変更からデプロイまでのプロセスを自動化し、開発サ
イクルを高速化します。再構築のステップ:
要件定義と設計:
- 既存のゲーム機能とデータ構造を詳細に分析し、新しいアーキテクチャで
のマッピングを定義します。- API仕様、データベーススキーマ、フロントエンドのUI/UXデザインを策定
します。- 特に複雑なバトルロジックやマクロチェックのロジックを、新しい言語と
フレームワークでどのように再実装するかを詳細に設計します。データ移行戦略の策定:
- 既存のファイルベースのキャラクターデータ、アイテムデータ、ログなど
を、新しいデータベースに安全かつ正確に移行する計画を立てます。これ
は最も重要なステップの一つです。段階的な移行 (推奨):
フェーズ1: APIゲートウェイと新フロントエンド: まず、既存のPerl CGI
アプリケーションの前にAPIゲートウェイを配置し、新しく開発するモダ
ンなフロントエンドからこのAPIゲートウェイ経由で既存のCGIを呼び出す
ようにします。これにより、UI/UXの改善を先行させることができます。フェーズ2: コアバックエンドの再構築:
キャラクター管理、認証、アイテム管理など、比較的独立したモジュール
から順に新しいバックエンドで再実装し、APIゲートウェイのルーティン
グを新しいバックエンドに切り替えていきます。フェーズ3: バトルロジックの再構築: 最も複雑なバトルロジックを慎重
に再実装し、徹底的なテストを行います。フェーズ4: ログとマクロチェックの統合:
Redisと外部サービス連携を新しいバックエンドに完全に統合します。テストと品質保証:
- ユニットテスト、統合テスト、エンドツーエンドテスト、パフォーマンス
テスト、セキュリティテストを徹底的に実施します。特にゲームロジック
の正確性を保証することが重要です。メリット:
- 高いスケーラビリティとパフォーマンスを実現し、将来的なユーザー増加に対
応できる。- 開発効率が大幅に向上し、新機能の追加や改善が容易になる。
- 堅牢なセキュリティ基盤を構築できる。
- モダンなUI/UXを提供し、ユーザーエンゲージメントを高める。
- 長期的な保守性と持続可能性が確保される。
課題:
- 開発コストと時間が非常に大きい。
- 既存のゲームロジックを正確に新しい言語で再実装する難易度が高い。
- データ移行が複雑でリスクを伴う。
- 新しい技術スタックに関するチームの学習コストが発生する。
どちらの案を選択するかは、プロジェクトの予算、時間、チームのスキルセッ
ト、そして将来的なビジョンに大きく依存します。段階的な改善は短期的な問
題解決に適していますが、長期的な成長を目指すのであれば、完全な再構築が
より良い選択となるでしょう。
一緒に挑戦したい人が何人か集まるようなら、全面再構築 + OSS化 + アプリ化（？）まで検討したいと思います。
初めまして！
現役でネイティブアプリを開発している者です。
ネイティブアプリ（Swift、Kotlin、Flutter）開発歴は約８年になります。
FFBを始めて20年以上になります。
もしアプリ化のプロジェクトがまだ募集されてましたらぜひ参加したいです。
よろしくお願いします！
よければ以下メールアドレスに連絡いただけると幸いです。（今回用に生成した非公開メールアドレスです）
今のところ何も開始していない状況となります。
目的を持ったモチベーションの高い人が集まればやるのもいいかもしれませんが、今のところ何も考えていません。
回答ありがとうございます！
FFBは各種API化はされてるのでしょうか？
それともフロントから直接呼び出してるだけになるのでしょうか？
もしAPI化自体はされているのであれば、仕様の整理、ドキュメント化ののちアプリの開発自体は1人で出来るレベルかなと思います。
もし良かったらSlackに参加したので、Slackで会話できると嬉しいです
APIとかDBという概念はないです。
というか今からやるなら0からの作り直しになります。
こんばんは。この件はまだ思案中でしょうか。
と、質問する前にまずは簡単に自己紹介させていただきます。
NEC社員を経てなんとなく暮らしてるITエンジニアです。今は主にCMでおなじみの大手外資金融の基幹システムを設計開発/保守している現役です。歴は20年程です。
内容拝見しましたが目的がふわっとしているような状況でしょうか？
AI君が言うようにパールはレガシーな部分があるのでリファクタリングしたいという題目・思惑はおおいに賛同するのですが、そこからOSS化、APP化といった部分まで波及しており、着地点をどのように構想されているのかが把握できませんでした。AI君は4つ目標を掲げていましたが、この目標全てがkrokoさんの目標と一致したのでしょうか。個人的にはAIっぽすぎる返しで、ドンピシャで頷ける回答だったとは思わなかったです。
言語維持(CGIのまま)、言語レベルでの移行(言語は問いませんがブラウザベースならASPが妥当、ただ近年サクラからカゴヤに移行されているのでなんともですが)、一部DB化(物理設計、論理設計ともに可。MSSQL/Oracle/MySQL/ポスグレ可)、Android/iOSアプリ開発、どのような方針にするにせよあれこれお話ができるかと思います。
現状がどのようになっているかは存じませんがパールベースのFFAやENDLESS BATTLEなどのCGIはある程度目を通しています。
正直、細かな問題(特定のパラメータがNaNになってしまうなど)があるにせよベースがすごく良いので回っていますよね。ユーザさんもたくさんいます。
そんな状況で修正や0からの作り直しは腰が重いと思います。自分もそういった事は未だにいくつかあります。
ですが同じ目的意識を持った人間がいれば意外と乗り越えられるものです。AIも優秀になってきましたがまだまだ生身の人間には及びません。
よしやるか！というような気持ちがまだあるようでしたら立候補します。
その結果、何もしないという結論、もしくは微修正にとどまるのでも構いません。
コメントありがとうございます。
こんばんは。この件はまだ思案中でしょうか。
積極的ではありませんが、大まかに見れば思案中になります。
内容拝見しましたが目的がふわっとしているような状況でしょうか？
当初の目的は、AIを使って何ができるかの検証でした。
このトピック作成前にGemini Cliがリリースされたためです。
一緒に挑戦したい人が何人か集まるようなら、全面再構築 + OSS化 + アプリ化（？）まで検討したいと思います。という部分は変わりません。
とは言え、リファクタリングによるクローン作成にはあまり関心がありません。
誰もやっていない未踏の領域に手出しできるようなら、よしやるか！という気持ちになれるかもしれません。
当時は、ユーザの意志や意見が具現化（自動実装）されるような自由度の高い面白い仕組みを作れるんじゃないかな、と思っていました。
ご丁寧にありがとうございます。
一緒に挑戦したい人が何人か集まるようなら、全面再構築 + OSS化 + アプリ化（？）まで検討したいと思います。という部分は変わりません。
とは言え、リファクタリングによるクローン作成にはあまり関心がありません。
大事なポイントということですね。
既存のものをどうこうする話ではないということがわかりました。
誰もやっていない未踏の領域
面白そうですね。ワクワクします。
ユーザの意志や意見を具現化することも実現できると思います。自由度の高さをどのレベルまでもっていくかを仲間内で考える過程も面白そうです。
FFBATTLEではサポート係の人だったり当時周りになかった画期的な仕組みを真っ先に導入されていましたが、そういう感性や発想力、それを実現できる能力を尊敬しています。
AIに何かを投げるにせよ、そういった発想力ありきになってきますのでAIを活用しながらというのは有用な手立てだと思います。
krokoさんのGOサインがくるその時まで気長に待ってます。
はじめまして、20年前に@パーティをやってて、20年前に出会ったネット友達とオフ会をはじめてやりました。で、ふと今もこの業界生きているのかと調べたらここに行き着きました。
とても面白い取り組みだと思います！！@パーティーの方なので、このスレッドとは方向性が違いますが、専用のdiscordサーバー作りましたので、ご興味がありましたら、ぜひどうぞ！
ただ私もクローンな感じを維持せず作り直した方がいいのではと考えているので、見た目がだいぶ変わると思いますが