テキストクエストの愛好家。 コンストラクター。

12月31日、私は、ユーザーが自分のテキストクエストを作成して投稿できるサイトを作成するというアイデアを提案しました。 それからかなり長い新年がありました、そして、ここで私は再びランクにいます。



このトピックでは、プロジェクトの最も重要な要素であるクエストデザイナーに関する私の考えを共有したいと思います。 計画されている機能とアーキテクチャ全体についてのあなたのコメントを聞きたいです。







主な構造要素については、場所を取ることにしました。 場所は、名前、説明、写真で説明されます。 場所間で移動することが可能になります。 次の要素を場所に配置できます。



1. アクション

どちらがテキストリンク（アイコン付き）として表され、次の要素であるイベントの実行につながります。 アクションにはいくつかの標準タイプがあります-今のところは、物をとる/与える、または単にイベントを出力するためにのみ発生します。



2. イベント

アクションの結果。 イベントは、名前、説明、写真でも説明されます。 イベントごとに、イベントのロード時にリストに表示されるアクションを無制限に添付できます。 例-ロケーションに移動すると、デフォルトアクションがロードされます-インデックスは、ロケーションの説明を表示するイベントをトリガーします。



3. NPC

ゲームのキャラクター。 名前、説明、写真で再度説明します。 場所でキャラクターのリンクをクリックすると、ウィンドウが開き、使用可能なダイアログが表示されます。 ちなみに、ダイアログはコンストラクタの別のモジュールで作成され、同じアクションとイベントであり、わずかに異なる形式で表示されます。



また、ダイアログを作成するとき、ブランチの1つまたは別の続行または別のものの取得（交換）に必要なものを示すことができます。



モノ（アイテム）



物事を受け取る/返す可能性についてはすでに述べました。 私の意見では、これはテキストクエストの可能性を大きく広げます。 「Petka and Vasily Ivanovich」などのクエストをプレイした人は、「コンドームを得るために燭台を与える必要があり、将来は重要な情報を所有する売春婦に行くために使用する必要がある」という永遠の問題を覚えていると思います。 面白かった？



友好的な方法では、プレーヤーアイテムを含む配列は、ユーザーIDに関連付けられたキーによってキャッシュに保存する必要がありますが、そのためには少なくともvpsを取得する必要があります。 3月までにプロジェクトを開始し、サーバーを用意しますが、3月まで私たちを待ってはいけませんか？ したがって、私は最初に、セッション中の物を配列に保存できると思います。



ダイアログとアクションの結果を保存する



まず、例。 私はNPCを「失礼」にし、彼は私にキーアイテムを提供することを拒否します。 ダイアログの結果を保存しない場合、再実行できます-つまり すべてが愚かにもオプションの検索にかかっています。 したがって、ダイアログの結果は同じセッションに残り、作成者がイベントの開発に他のオプションを提供しない場合、クエストは散らかされます。 この点について考える価値があります クエストで文盲を使用すると、行き止まりが表示されます。



この機能は、開始するには十分すぎると思います。 その後、より興味深いものを追加することが可能になります。 私はすでに数日より多くの時間を費やすことを計画していました。