Python / Ren'Pyでテキストゲームを作成するパート2：ミニゲームと落とし穴

前の25,000シリーズの要約：私たちは海で泳ぎ、歴史に参加することについてのテキストゲームを書いています。 もともと視覚的な短編小説を対象としたRen'Pyエンジンで作成しますが、最小限の設定で必要なすべてを実行できます。 前回の記事では、シンプルなインタラクティブリーダーの作成方法について説明しましたが、ここではさらに複雑な機能を備えた画面をいくつか追加し、最終的にpythonで作業します。







前の記事は、プレイヤーがテキストを読み、写真を見て、プロットの展開に影響を与えることができるという事実で終わりました。 Braslavskyの本ゲームを移植したり、Choice of Gamesの精神でCYOAを書いたりするなら、それで十分でしょう。 しかし、ナビゲーションに関するゲームでは、少なくともナビゲーション自体のシンプルなインターフェイスが必要です。 Sunless Seaのような本格的なシミュレーターを構築するには、Ren'Pyでも可能ですが、労働集約的であり、一般に無意味です。 さらに、ブリヤートやバスで独自のサンレス海を作りたくないので、「スペースレンジャーズ」のグローバルマップのようなものに制限します。各地点からいくつかの隣接する地点に移動できます。 このようなもの：

ディスプレイ、画面、レイヤー

インターフェイス自体については、ボタン（各ポイントに1つ）と背景画像を表示するだけです。 これにはDisplayableタイプのImagemapで十分です。 基本的に、HTMLの対応するものとそれほど違いはありません。これは、それぞれ独自のアクションを持つアクティブゾーンが定義されている図です。 ただし、裸のDisplayableで作業するのは不便であり、アーキテクチャの観点から見るといです。 したがって、コードを実行する前に、Ren'Pyが表示する要素の階層を理解することは価値があります。



最下位レベルはDisplayablesです。つまり、特定のゲームの開発者が組み込みまたは作成したウィジェットです。 それらはそれぞれ、いくつかの基本的な機能を実行します。画像の表示、テキストの表示、入力の提供などです。 Displayableは通常、より抽象的な対話を提供する画面にグループ化されます 。たとえば、テキスト出力とゲーム内メニューは、実際のテキスト、背景、フレーム、メニューボタンを含むnvl画面によって実行されます。 同時に、好きなだけ画面を表示できます。たとえば、1つにはテキストがあり、他のボタンには音楽の音量を制御し、3つ目の画面にはこの上に雪が飛びます。 必要に応じて、ミニゲームで個々の画面を表示または削除したり、メニューやゲームに必要な他のすべてを保存したりできます。 そして最後に、 レイヤーがあります 。 レイヤーを直接操作する必要はありませんが、レイヤーの存在を知る必要があります。 たとえば、壁紙は画面システムとは関係がなく、マスターレイヤーでその下に表示されます。



したがって、旅行画面の説明は次のとおりです。

screen map_screen(): tag map modal True zorder 2 imagemap: auto 'images/1129map_%s.png' # Main cities hotspot monet.hotspot action Travel(monet) hotspot tartari.hotspot action Travel(tartari) # … # More of the same boilerplate # … add 'images/1024ship.png': at shiptransform(old_coords, coords) anchor (0.5, 1.0) id 'ship' transform shiptransform(old_coords, coords): pos old_coords linear 0.5 pos coords
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

map_screen（）画面が最初に宣言されます。 タグはオプションです。 「移動に関連するすべての画面を削除する」などのコマンドの画面をグループ化することができます。 Zorderは画面の「高さ」であり、これにより、どの要素が互いにあいまいになるかが決定されます。 zorder = 2を設定し、nvl画面にはデフォルトのzorder = 1が設定されているため、旅行中、プレーヤーにはテキスト付きのウィンドウは表示されません。 しかし、最も重要なことは、この画面がモーダルであるということです。つまり、画面の下の要素は入力イベントを受け取りません。 nvl画面はマップの外観でブロックされているため、ゲームの状態を自分で追跡する必要はなく、マップをクリックしてもテキストがスクロールしないようにする必要があります。



イメージマップ自体は、自動タグとアクティブゾーンのリストという2つの主要な要素で構成されています。 Autoには、バックグラウンドとして使用される一連のファイルへのリンクが含まれています。 それはセットであり、単一の画像ではありません。すべてのボタンが非アクティブとして描画されるファイルとは別に、すべてが押されるなどのファイルが個別に存在します。 そして、Ren'Pyはすでに各ファイルから目的のフラグメントを選択し、画面上の画像をコンパイルします。 そして最後に、アクティブゾーン（ホットスポット）。 これらは、4つの整数（座標とサイズ）のタプルとアクションのオブジェクトによって記述されます。 タプルをハードコードするのではなく、オブジェクトの属性を使用します。 画面の説明では、値の代わりに変数または属性をいつでも挿入できます。 アクションオブジェクトは、ボタンが押されたときに何が起こるかを記述し、ボタンをその時点でアクティブにするかどうかを制御します。 Ren'Pyは、スクリプトの切り替えやゲームの保存などの日常的なタスクのために、かなりの数の組み込みアクションを提供しますが、独自のアクションを実行することもできます。 最後に、船の描画と変換が最後に追加されます。これは、画面に表示されるだけでなく、ポイントAからポイントBに移動します。変換は、別のATL（アニメーションと変換言語）で記述されます。



1つの落とし穴が画面に関連付けられています。画面コードは、表示される直前に実行されるのではなく、事前に実行されます。 これは、エンジンが必要とする回数と必要な回数で発生するため、このコードでアクセスされるすべてのものは、ゲームの開始前に初期化する必要があり、他の重要な変数の状態には影響しません。

トランプ

前の記事で、Ren'Pyでインターフェースを作成する2つの方法を示すことを約束しました。 最初に見たのは、非常に単純ですが、決して普遍的なものではありません。 たとえば、画面上の言語でマウスを使用してオブジェクトをドラッグする方法を説明し、衝突を処理する方法についてはまだ理解していませんでした。 または、画面上の要素の数がゲーム中に決定される場合の画面のレイアウト方法。 さいわい、Displayableは完全なウィジェットです。他のDisplayableを含めたり、入力イベントをキャッチしたり、必要に応じて変更したりできます。 したがって、別のアプリケーションの場合とほぼ同じ方法で、ミニゲーム全体を1つのDisplayableで記述し、プロジェクトに挿入できます。



ミニゲームカードがあります。 主人公の潜在的に有用な財産と知識はすべて、強さ、知識、陰謀、お金の4つのスーツで1から10の額面を持つカードの形で提示されます。 強さは、人が息を吸う場所についての貴重な知識であり、8人の陰謀は密輸業者の間でのOfficeのエージェントの信頼できるリストです。 賄briを使用した単純なゲームは、プレイヤーが前に問題に対処したかどうか、および勝ったまたは負けたスーツを決定します。 その結果、紛争は最大8つの結果をもたらす可能性があります。各スーツでの勝利と敗北は、原則として、異なる結果につながる可能性があります。



カードゲームとは、カードがその中に表示されることを意味します。 小さな地図を表示するDisplayableのコードは次のようになります。

 class CardSmallDisplayable(renpy.Displayable): """ Regular card displayable """ suit_bg = {u'': 'images/MoneySmall{0}Card.jpg', u'': 'images/KnowledgeSmall{0}Card.jpg', u'': 'images/IntrigueSmall{0}Card.jpg', u'': 'images/ForceSmall{0}Card.jpg'} def __init__(self, card, **kwargs): super(CardSmallDisplayable, self).__init__(xysize=(100, 140), xfill=False, yfill=False, **kwargs) self.bg = Image(self.suit_bg[card.suit].format((card.spendable and 'Spendable' or 'Permanent'))) self.text = Text(u'{0}'.format(card.number), color = '#6A3819', font='Hangyaboly.ttf') self.xpos = 0 self.ypos = 0 self.xsize = 100 self.ysize = 140 self.x_offset = 0 self.y_offset = 0 self.transform = Transform(child=self) def render(self, width, height, st, at): """ Return 100*140 render for a card """ bg_render = renpy.render(self.bg, self.xsize-4, self.ysize-4, st, at) text_render = renpy.render(self.text, width, height, st, at) render = renpy.Render(width, height, st, at) render.blit(bg_render, (2, 2)) render.blit(text_render, (15-int(text_render.width/2), 3)) render.blit(text_render, (88-int(text_render.width/2), 117)) return render def visit(self): return[self.bg, self.text]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、本質的に最も簡単なDisplayableです。 これは、スーツに応じて選択された背景画像と、額面のあるテキストの2つの要素で構成されています。 Displayableが機能するには、コンストラクターを除く両方のメソッドが必要です。self.renderはテクスチャを返し、self.visitは-

これに含まれるすべてのDisplayableのリスト。 彼女は小さな地図を描きます。 デッキ画面に表示されるこれらのカードのいくつかを次に示します。







すでに悪くはありませんが、カード自体は画面上にしか表示できず、誰かがそこに置いた場合のみです。 実際にミニゲームをプレイできるようにするには、入力を処理し、ゲームロジックを計算できる外部Displayableを追加する必要があります。 テキストフィールドと背景がマップの一部であるのと同じ方法で、マップと他のインターフェイス要素が含まれます。 このDisplayableは、入力としてPyGameイベントを受け取るself.event（）メソッドの存在が異なります。 PYGAME.EVENTへのリンク次のようなもの（完全なコードは、Tableクラスのgithubで利用可能です）：

 def event(self, ev, x, y, st): if ev.type == pygame.MOUSEBUTTONDOWN and ev.button == 1: # … # Process click at x, y # … elif ev.type == pygame.MOUSEMOTION and self.dragged is not None: # … # Process dragging card to x, y # … renpy.restart_interaction()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イベントのキューについて心配する必要はありません。エンジン自体は、現在アクティブなすべての要素にすべてのイベントを配信します。 このメソッドに残っているのは、インシデントに関心があるかどうかを確認し、イベントに応答して相互作用を完了することです。 Ren'Pyの相互作用は、他のエンジンのゲームロジックのティックとほぼ同等ですが、時間に制限はありません。 一般的な場合、これは1人のプレイヤーのチームとそれに対応するゲームの応答ですが、場合によっては（たとえば、テキストをスクロールするとき）、対話は自分で終了することができます。

このDisplayableは、他のすべての人と同様に、画面にまとめています。

 screen conflict_table_screen(): modal True zorder 9 add conflict_table
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合のconflict_tableはクラス名ではなく、対応するDisplayableが格納されるグローバル変数です。 スクリーンコードは原則としていつでも実行できますが、ショーの前に必ず実行されます。そうしないと、ゲームは実際に表示する必要があるものを認識しません。 したがって、conflict_table.set_decks（player_deck、opponent_deck）のようなことを行い、プレイヤーが必要なものを正確に見つけるという事実に依存することは、ミニゲームの直前に完全に安全です。 同様に、ミニゲームの最後に、同じオブジェクトに保存されている結果にアクセスできます。



グローバル変数の使用はRen'Pyの制限ではなく、私たち自身の決定であると言わなければなりません。 画面とDisplayableがサポートされており、引数を受け取って値を返すことができますが、それらはやや複雑です。 まず、このような画面の動作は十分に文書化されていません。 少なくとも、画面が最初のインタラクションを開始する正確な瞬間と、正確にスクリプトに制御を戻すタイミングを把握することは非常に困難です。 これは非常に重要な質問です。答えがわからない場合、競合が始まる前に競合の前のテキスト全体が表示され、競合の後のテキストが表示されないことを保証するのは困難です。 第二に、グローバル変数を使用すると、ミニゲームに必要なオブジェクトのほとんどが一度だけ初期化され、実行するたびに属性が変更されます。 そうしないと、競合が発生するたびに必要なファイルをすべてロードする必要があります。 HDDに同時にアクセスする場合、たとえばトレントとウイルス対策の場合、ゲームは大幅に遅れます。 最後に、競合画面だけでなく、他のいくつかの画面もカードを参照しているため、必要な場所で同じDisplayableを使用するのが論理的です。

あとがき

これにより、開発の実際のソフトウェア部分が終了し、ゲームへのコンテンツの充填が開始されます。 ゲーム内の文献は主に私が作成したものではないため、ストーリーの構造とスタイルについては説明しません。 このテーマについては、たとえばCYOAの構造に関する古典的な記事を読むことをお勧めします。 または、 80日間の脚本家から説得力のある独立したNPCを作成するための優れたガイドです。

その他のリンク（および最近の英語の作品と関連記事のレビュー）は、 Emily Shortのブログにあります。