進捗報告 / パーツを組み立て始める
以前報告していた中耳炎ですが、結局薬だけでは改善されず鼓膜切開しました。そんなこんなで色々ありましたが、ついにnoteも１周年超えです。
肝心のゲーム制作も少しずつですが進んでおります。
Pythonプログラムの状況
関数型プログラミング志向で進める
前回から腹を括って、Pythonでプログラムを進めています。
どうやらオブジェクト指向で書くのが嫌だったみたいで、関数型プログラミングで書くと前よりはストレスなく書けている気がします。
これまた前に書きましたが、RenPyに持っていくときも関数になっていれば楽であろうし。
データ構造とかは仮で
データ構造とかどうしようかとずっと考えてたのですが、どうせ後から変わるだろうということで、全部リスト、辞書、その組み合わせ、で進めることにしました。
こうしておけば、Lispで書いてChatGPTにPythonコードにしてもらうときも大きな問題は無いだろうし。
pythonだけに限ってみても、リストじゃなくてタプルのほうが良いのかな、という箇所もあるんですが、そこら辺のリファクタリングは後回しします。
それよりもChatGPTに変換してもらったところに無駄があったりしたので、そこら辺を直しています。でも無駄なことしててもちゃんと動くものに変換してくるのは凄いと思う。
今日の時点では、最小限のキャラデータと大きなストーリー部分のデータが動いてます。
大きな物語のメカニクスと小さなエピソードのメカニクス
大きなストーリーはすごろく
現時点でBooCarDiでは、大きな物語はストーリー上のすごろくを行う、ということに戻ってきています。すごろく、というインスピレーションを頂いた、以前引用させていただいた記事は以下。
最初は小規模な社会シミュレーションとかしないと面白いストーリーが生まれないかな？とか考えていたのですが、ボードゲームとかの勉強をして、ぐるっと1周回ってレースで十分面白い展開は作れるし、プレイヤーにストーリーを追ってもらうなら、シンプルにした方がプレイヤーが余計なノイズを感じなくて良いのでは、と思っています。
ゲーム内データとしては、複数チームによるすごろくで、プレイヤーおよびNPCが個々にイベントをこなしていくことでストーリーポイントと呼ばれる数値が増えていき、その数値分、各チームのコマが進んでいく、コース上にはストーリー上の盛り上がりとなるチェックポイントがあって、ここのイベントをクリアするとストーリーレベルが上がって先に進めるようにします。これはストーリー前半で大勢が決まってしまうことを防ぐための対策。
小さなエピソードはTRPG
複数チームは数名のNPCから構成されていて、プレイヤーはプレイ開始後は無所属。プレイヤーが起こすイベントやその結果は各チームのストーリーポイントに影響していて、その影響の大小によってチームから勧誘を受けたり敵対されたりすることを考えています。
ダイスのシステムとしてはニンジャスレイヤーRPGを簡単にした様なもので、現時点ではあまり凝ったものを考えていません。
一応、他のTRPGシステムを応用したPCゲームとか色々見てきてはいるのですが、大きな物語のところは力が入っているけれど、繰り返し起きる小さなイベントとかはあっさりしたものが多くて、自分としては満足させてくれるものになかなか巡り会えません。
BooCarDiではコンピュータを使う強みを活かすこととテキストに注力することで、この小さなエピソード群にこそ注力する予定です。エピソードを増やしまくるのではなく、基本的にはそのエピソードが起きたシチュエーションとその結果に対するNPCのリアクションのバリーションをたくさん作っておくということなんですけど。
それと、大きなストーリーを一気に語って感動させるというような事は考えていなくて、背後にある大きなストーリーが垣間見えるようにしたい、というのが大きいかもしれません。
NPCが起こすイベントはそのNPC達と関係が無ければ内容を知り得ないし、間接的に知った場合には誰がそのイベントを起こしたか分からない様にしようと思っています。おぼろげながら大きなストーリーが見える、という演出には、天拝山クエストで実験してみたウィキシステムが役に立ちそうです。まあ以前にも書いた通りDTからアイディアを頂いている訳ですが。
とりあえず、今日はnoteに使う時間はこのくらいにしておきます。
この記事が気に入ったらサポートをしてみませんか？