AIで音楽をもとにダンスモーションを作りたい
EDGEという音楽をもとにダンスモーションを自動で作ってくれるAIを試してみました。試してみたら大量のキーフレームが打たれててblenderがしばしば固まりました。
EDGEの環境構築
python 3.10とCUDA 11.8でやります。
py -3.10 -m venv venv
これで環境を立ち上げてインストールします。
download.shが動かないので、中身を直接みてください。wgetが入れ子になっています。内側のURLにアクセスすると、Google driveがウイルススキャンできないと文句を言うのでダウンロード。powersellにwgetやsedを入れて直接実行してもうまくいかないので注意。
海行さんの記事を見ながらインストールすれば上手くいきます。たまにtorchのバージョンが上がってたりするので、適宜uninstallして入れ直してください。ここまで頑張ってもFBXのconverter.pyが死んでます。
コードブロックほぼ全体がtry-exceptで囲んであるので、エラー原因を特定するために外してください。os.path.joinがたぶん想定外の動作をします。面倒なのでos.path.joinの部分だけ外して、filename.replaceを直接代入してください。
これで、モーションデータのあるディレクトリにFBXが生成されます。FBXはASCII形式でblenderで読み込めない場合があるため、読めない時はautodesk FBX converterを使ってください。
バイナリ形式のFBXを生成できたらblenderで読み込みましょう。
blenderでゴニョゴニョ
rokokoを使ってFBXとVRMをリターゲティングします。そのままやると5分のダンスに対して1時間以上は変換に時間がかかります。
だるいので、キーフレームを削減しましょう。FBXのモーションに対して比率0.95でキーフレームを削減しましょう。それからリターゲティングしてみてください。30分ぐらいは短縮できると思います。
なお、キーフレームの削減はとても時間がかかります。諦めてください。
ここから、VMDに変換してMMDに読み込むなどのワークフローが考えられます。物理演算をしたいならモーションをVMDに変換してMMDでレンダリングしましょう。
ちなみに、AIでダンスを生成するよりもキーフレーム削減の方が時間がかかりました。それでも時間短縮できるレベルなのでblenderの作業が長すぎますね。
個人的には、blenderの作業が厄介でした。あるのは知ってるんだけど、どこにあるのかさっぱり。
AIでダンスを生成した感想
そこまでクオリティは高くありませんでした。たぶん、デモなどはベストクオリティのものを出したのでしょう。
ハウンドドックのrocksをベースにダンスを生成しました。それっぽく踊っていますが、何もしないより動いている方がいい程度の完成度だと思います。
ダンスというものは音楽に対応する身体表現のようなもので、いわば楽器のようなものです。楽器なのだから音楽に合わせなきゃダメなんですが、生成されたダンスはなんか動いているだけです。
例えば、イントロはタメの多い動きを期待しますが、ジャカジャカ動いています。メロやサビに至っては一貫性がなくて動いていることだけしかわかりません。
そこまでAIに性能を求めるのは酷かもしれませんが、それぐらいはAIにやってもらわないと困ります。ハードディスクの肥やしみたいなものですから。
ダンスってただ動けばいいものではないんですよ。例えば、フラメンコでは踊り手が演奏に指示を出します。踊り手に合わせて音楽を奏でるのがフラメンコの特徴です。では、この指示がバラバラだとどうなるか？ 演奏隊は困るわけですね。
つまるところ、表現と意味が一致していなければなりません。音楽という意味に対してダンスという身体表現が一致しなければ、なんか音楽に合わせて動いている人しか生成できないわけです。だから、世にあるダンスは独創性が高いんですよ。
例えば、ブレイクダンスでも音楽に合わせてトリックができなければそれは空気が読めない人になってしまうわけです。
世に蔓延るAIには有象無象があります。ダメなAIは哲学的な問題提起がなされていません。sunoも最初はダメでした。でも、最近はいい音楽とは何かをユーザに問いかけて、いい音楽という方向性を導き出そうとしていると思います。
なぜ、AIに哲学的な問いが必要なのか？ それは学習によって統計的な傾向を見つけて、入力に対してそれらしい傾向を出力するように工夫されています。ここで学習と工夫が必要なのです。学習と工夫に対して正しい問いを設定することで、はじめてAIと呼べるようなものが出来上がります。
EDGEにはいくつか欠けていると感じたことがあり、それはダンスとは何かということです。発表者のうちダンスのしたことがある人がいるかもしれませんが、AIにダンスとは何かを組んだようには思えないからです。
GitHubを見れば明らかです。forkだらけで、issueがほったらかしになっています。成果物に対して執念めいたものがないです。
ダンスと音楽を記録して、時間的に学習し、それを出力しているだけのようにしか見えないのです。根源的にダンスとは何か、そして良いダンスとは何かまでたどり着いていません。
研究の根源の部分なのでこれから研究しようとなると、潤沢な資金があれば最短で1年ほどで成果らしい成果が出てくるのではないかな、と思います。それまでは待つしかないですね……。
裁判ラジオをどう面白くするか？
はじめに
とりあえず、裁判ラジオを作ってみようと仮定しよう。裁判ラジオを作るにあたりどのような仕組みを取り込むべきか考えなければならない。特に、裁判を面白くするには、ストーリーにある種の過酷さが必要だと考えている。というのも、地裁だと何でそうなるのか全く意味がわからない判決文も出されるからだ。そうなると視聴者も納得できないし、学習ソースが判決文だというと裁判所が不条理に感じる人も出てくるだろう。
そういうわけで、裁判ラジオには原告に対して過酷さを要求したい。判決が原告に傾くような判例を作りたい。
過酷な判例
過酷な判例は面白い。世の中には信じられないほど過酷な判例があったりする。過酷な判例を見るとなかなかドキドキするものだ。最後に裁判所の判断を見ながらこればどっちが有利か考えると、これもなかなかに面白い。
過酷な判例の多くは労働災害が多かったりする。遺族がいるとかなり過酷だ。ただ、そこまで過酷にするとただただしんどいので、見ていてエキサイトする判例が欲しい。いい感じにエキサイトするのがDV裁判や契約関係の損害賠償請求だ。互いに平行線で結論が見えなかったり、最後になって重要な事実認定があったりする。これが面白い。
過酷な判例ほど見ていて興味をそそる。いい判決文が出たと満足する。
その判例をベースに証人尋問を組まなければならない。つまり、ストーリーありきとして作らなければならない。なかなか難しい話だ。
gpt-4だといくらでもプロンプトを投げられるので、実験をそこそこやらないとならない。特に、複数のAIと組み合わせるため、お互い協調しやすい指示を投げなければならない。難しい。
例えばこんなこともできる。
裁判所の判断（争点ごと）
争点1：上司Aによるセクハラ行為の有無
• 裁判所の判断
原告が提出した物的証拠（社内チャットのログ、メールの文面）には、上司Aが「もっと女性らしくすればいいのに」「俺と食事に行かない？」といった内容が含まれており、これらは社会通念上セクハラ行為と認められる。また、原告の同僚BおよびCの証言により、Aが会議中に「Xさん、そんな服装じゃ男性にモテないよ」と発言した事実も確認された。
一方、被告の主張である「冗談や親しみの表現である」との弁解は、当該発言が一貫して原告を対象としており、原告が不快感を示した後も継続していた点から認められない。
結論：上司Aの行為はセクハラに該当すると認定する。
争点2：会社の対応の適切性
• 裁判所の判断
被告は、原告からの相談後に調査を行ったと主張するが、提出された調査記録は非常に簡素で、聞き取り調査は形式的に終わり、Aの行為を問題視した証拠はなかった。また、原告の申告後も具体的な措置（加害者との接触回避、職場環境の改善）が講じられておらず、むしろAが原告に「なんで俺を悪者にするんだ」と詰問した事実が同僚Dの証言で明らかとなった。
被告が行ったセクハラ防止の研修も、報告後の事後対応には含まれず、労働契約上の配慮義務を尽くしたとは言えない。
結論：会社はセクハラ問題に適切な対応をせず、配慮義務違反が認められる。
争点3：セクハラ行為とうつ病発症の因果関係
• 裁判所の判断
原告が提出した診断書では、主治医が「長期間にわたる職場での心理的負荷」がうつ病の主要因と明記しており、また同医師が証人として出廷した際も「特にセクハラの被害が主な原因」と証言した。一方、被告は「業務上のストレスや私生活の問題の可能性」を指摘したが、それを裏付ける具体的な証拠は提出されなかった。
また、原告がセクハラ相談後もAとの接触を余儀なくされたことが、精神的負担を悪化させたことは、同僚Eの証言や原告の日記（物的証拠）からも確認される。これらの証拠から、セクハラ行為とうつ病発症の因果関係は十分に認められる。
結論：セクハラ行為が原告のうつ病発症の主要因であると認定する。
総合判断と判決
上記の争点を総合的に判断し、裁判所は以下の結論に至った。
1. 上司Aの行為はセクハラに該当する。
2. 被告会社は原告の相談に適切に対応せず、配慮義務に違反した。
3. セクハラ行為とうつ病発症の因果関係は立証された。
よって、被告会社には損害賠償の責任があると認められ、原告に対し慰謝料500万円および治療費150万円、計650万円を支払うよう命じる。
文字が大きいがスマホだと編集が難しいので勘弁して欲しい。実際の判決文はもっと長いので、これをもっと長くし、最終的な判決文を出力させる必要がある。
争点もたくさんあるはずなので、争点をもっといっぱい用意してもらわないとだめだ。実際には細かく指示する必要がある。
判決文を作ったら証人尋問のストーリーを作成する。ストーリーが決まれば、采配師にキャラごとの振る舞いを要求する。その要求に応じ、キャラは発言しなければならない。
だんだん頭の中で、構成が決まってきた。問題となるのはどうやってテーマを選ぶかだ。テーマ選びは2人の原神キャラが雑談するシステムでも問題になった。何事もテーマを決めるのは難しいということだ。
テーマ選びのアルゴリズム
原神キャラ雑談は任意のカテゴリ、トピック、サブジェクトを自分で定義して、ランダムにその内容を選んでもらっていた。
今回もその方法を考えている。カテゴリには労働審判、損害賠償、知的財産、などなどがカテゴリになると思う。トピックは、さらに深掘りしてDV、夜逃げ、離婚、慰謝料等々に分けられる。さらにサブジェクトでは、流れの方向性を決める個々の事象を定義する。誰が悪いかとかそんな話だ。
これをランダムに切り替えてくっつけておけば、テーマは完成すると思う。と思ってる。実際に成立するかはやってみないとわからない。
とにかくたくさん列挙させて、ランダマイザがよしなにやってくれることを期待するしかない。テーマを自動で作るのは意外と難しいものだ。気持ちとして1000行ぐらいあれば被ることはないと思う。
というよりむしろ、判例を片っ端から集めてきてChatGPTにテーマを判断させた方が早いかもしれない。それでテーマを集めてきて、ランダムに組み合わせることで、とんでもない内容の裁判が出来上がる気がする。
結言
複数人のキャラクターが会話するためのアイデア
はじめに
「複数人のキャラクターが音声を用いて自動会話するシステム」と称することにしよう。前々からこの件について悩んでいる。会話のテーマが自由だと交互に会話するのが難しい。1つの会話あたり2分の文章量が限界かもしれない。そして会話のストーリーがとても大事だ。
会話のテーマを固定すれば会話しやすくなる。今のところ考えているテーマは裁判が思い浮かぶ。裁判の判決文はストーリーがある。証人尋問はとてもわかりやすい。会話のターンが厳格に決まっているからだ。法廷で不規則発言をすれば止められる。規則的なところがAIにとってストーリーを考えやすい。
他に似た性質の会話がないか考えてはいるものの大抵は1対1だ。ストーリーを持たせるのも難しい。TRPGはやったことないのでこれも難しい。
裁判判例を学習する戦略
裁判判例を学習して、架空の裁判をでっち上げる必要がある。当然、架空の裁判判例を作り、そこからストーリーを練る必要がある。
判決文には大まかに主文、事実、裁判所の判断、まとめの構成で書かれている。判決の事実を作るには、ストーリーが必要だ。何らかのストーリーを与えることで判決文を書けるようになり、双方の争いが成立する。
争いで最も注目したいのが証人尋問だ。1人の証人に対して原告弁護人、被告弁護人、裁判官から質問がある。証人は複数人いる。会話も制限されているので秩序だっている。非常にプログラム化しやすい。
裁判以外で複数人がトークできるテーマが思いつかない。TRPGぐらいだ。あるいは学会のような質疑もあるが、プレゼンが必須なので会話が成立しにくい。
判例を作ってそれを元に証人尋問をしたほうがシステムが作りやすい。
ところで、その判例はどこから取ってくるか？
裁判所にデータベースがあるので、一件一件取ってきて、学習用のプロンプトを組み立てる。これを元に文書を学習させて、判決文をでっち上げる作戦にしようと考えている。できれば文書を構造化したい。判決文はフォーマットのあるツリー構造で作成されている。ツリー構造を作成して、プロンプトに落とし込みたい。
裁判ラジオは面白いのか？
裁判は大半の人にとって非日常だ。やって離婚調停ぐらいしかやらない。調停は裁判ではないので、やはり裁判は非日常だ。
ところが裁判所はとても忙しい。次回期日が3ヶ月後とかざらにある。裁判が終わらないではないか。
もちろん、民事に限らず刑事裁判も年がら年中行われている。裁判所も忙しいのだ。
しかしながら、証人尋問はなかなかスリルのあるものだ。証拠を元に相手から発言を引き出すためには心理テクニックも必要になる。証拠を出す順番も重要だ。
証人尋問は物証と違い人証という重要な証拠の最後の牙城とも言える。証人尋問と人証証拠をもとに裁判所は事実を組み立てる。事実に矛盾が生じれば、裁判所が判断する。そのために事実がとても重要になる。
裁判は意外と面白い。非日常だし録音機などの持ち込みは禁止されているから裁判の中身なんて普通の人はわからない。そこに面白さが潜んでいると思う。裁判所に行って傍聴しなければその面白さはわからないと思う。
それが原神キャラクターがランダムに選ばれて証人尋問をする。とてもハラハラする内容になると思う。クレーが裁判官だったら面白いし、ヌヴィレットが被告人だったらそれも面白い。
裁判の内容も、損害賠償請求から地位確認、解雇無効、知的財産、さまざまな容態が考えられる。そこに面白さが潜んでいる。
証人尋問は長くなりがちにはなるが、面白さを発揮する展開になると思う。
私が来年度にやりたいこと
そろそろ年末ですね。来年の抱負を早めに書きたいと思いました。
今年の振り返り
今年に入ってから本格的に活動をしていたように思います。ディオナちゃんになると決めてさまざまなことがありました。
今年はディオナちゃんでいろいろなことをしました。楽しい年だったと思います。無事、収益化が通り、少しだけの収益が入るようになりました。ありがたいことに、様々な人の支えがあって活動を続けられています。
様々な人も訪れました。コメントをくださる人は原神を頑張っていて、自分も原神頑張らなければなと思う限りです。elinにハマってしまって今はそれどころじゃないですね。
いろんなタイトルのゲームもやりました。面白いゲームもあれば操作のわからないゲームもあり、充実した1年だったと思います。
そして年度末に控えて色々慌ただしいです。やらなければならないことを複数抱えています。配信ができない日があって困ることもありますが、活動をうまく続ける方法を模索中です。
案件も一つ貰いました。定期的に表に出すつもりでいます。幸い、著作権をこちらで持つ契約ができたので、何かあれば配信していこうかなと思っています。
思い返すと長いようで短かった気がします。1年はあっという間に過ぎるものですね。
来年の抱負
来年はやりたいことがいくつかあります。
まずはホヨバと何かできないか、ということです。私はいま音声合成で生成AIを使った自動セリフ生成を手元に持っています。これをもっと発展させてテーマに対して複数人のキャラで会話をさせたいです。これを持って、ホヨバと何かできればいいなとか考えています。
課題があるとすればコネクションがないということでしょうか。ホヨバとコネクションを作るところから始めなければなりませんね。
他にもやりたいことはあります。未踏アドバンストに応募してみてもいいかなとは思っています。ただ、これは複数人のキャラが会話することをさらに発展させる必要があると思います。大変ですね。
あとは、もう少し収益を増やしたいです。ただ、広告収益だけだと、同接1000はないと日給5000円に届かないです。あまりにも馬鹿げていますね。私でもそりゃ無理だと思います。なので、安定した基盤を作るのに色々やることがありそうですね。
私事ですが、片付けられるものは片付けたいです。これは私が頑張らなければならないことですが。なかなかこれも難しいですね。しばらくすれば楽になると思うので頑張ります。
総括
私は私なりに技術的な深度を深めていきたいと思っています。技術的な深度を深めることで、他者には追随できない何かを作ることができると思っています。
プログラミングの技法
プログラミングには技法があるか？
プログラミングには技法はないです。なんかミラクルな方法でプログラミングしているわけではなく、淡々と動くためのアルゴリズムと手続きを書いているだけです。なので、考え方が向いていればそれだけでプログラミングする才能があると言えます。
ここで書くのは考え方です。
Googleで検索する
Googleで検索してコードをコピペします。言葉通りですね。Googleへの検索力が必要です。そして、目的のコードを探り当てる。そのためにはある程度のしつこさが必要です。
コードが転がっていてもそのまま使えるわけではありません。コード規約がキャメルケースなのに、スネークケースをそのままコピペするのは芸がありません。なので、コピペしたコードを読解するための勘のようなものが必要です。
そしてコピペを自分のものに書き換えます。書き換えて動くように工夫します。動くように工夫するのも努力の一部です。やりたいアルゴリズムを組み込むこともあります。
検索しても見つからないがドキュメントはある
たまに本当に情報がないときがあります。サンプルもなく、ただドキュメントがある。そのときはドキュメントを理解する必要があります。
ドキュメントの理解と深掘りは大変な作業です。たまにAPIだけ生えてて何が返ってくるか不明な時があります。そんなときはひたすらAPIを叩くしかないです。
使用しているアーキテクチャを理解して操作する努力が求められることがあります。アーキテクチャの理解が進むほどドーパミンが出るタイプの人は、コアなことをやる才能があると思います。
何もない
ワンダーランドです。普通はこんなことないのですが、ファミコン(NES)、ゲームボーイ(Z80)などの開発では参考にできるコードが皆無です。あるいはSIMDでもいいかもしれません。
いずれもドキュメントはありますが何もないです。自分で最初からアルゴリズムを組み立てなければなりません。まあまだZ80が現役のところもありますから、もしかすると放り込まれるかもしれません。
やるべきことはわかってる。だけど全部自分で考えなければならない。そういうのが好きな人はゲーム開発が向いてます。しかももっとプリミティブな開発が好きかもしれません。
プリミティブな開発は難易度が高いです。できた時の嬉しさはかなり大きいです。
何をすればいいのか見当もつかないがやる
普通は誰もがやりたがらないことです。点Aから点Bまで導くための関数fを探せ、といったことです。とにかく速くする、見つける、絞り込むなど、枚挙に暇がないです。
競技プログラミングはこの傾向があります。研究もこういう壁にぶつかることがあります。短期決戦になることが多いです。
好きな人は好きです。私はこの傾向が強かったと思います。
技法というより考え方の癖
色々な考え方があると思います。後になるほど癖が強いです。考え方の癖の度合いによって向いていることと苦手としていることが異なります。考え方の癖が強ければ、なおのことその考え方が好きである可能性が高くなります。
よくプログラミングで挫折した、という話がありますが、私は試行回数が足りていないのではないかと感じています。なぜなら、今学習しているプログラミングが必ずしも適性があるとは限らないからです。
例えば、学習教材を使って習うより、その都度調べた方がわかりやすい、ということもあります。学習教材だとどうも難しくて取り組みにくい、という人もいます。必ずしも学習教材がプログラミングの全てとは限りません。たまたまそのとき作りたいものがなくてモチベーションが湧かなかったというのも考えられます。
なので、プログラミングは何度も挫折することが求められます。私もC言語のポインタはわかるけど、関数がわからないということがあり、1度挫折しています。でも、作りたいものが見つかった時、無心で作りたいものを作ろうとC言語を使いました。
他にも挫折したことはあります。C言語のリンカがわからなくて挫折しました。そのかわり、1つのプログラムで書くということもやりました。今ではVSがあるので何も考えなくていいですが、cmakeは今でも書くのが難しいです。
結局、プログラミングというものは、挫折と再起の繰り返しなのです。これが悪いと思わなければ、もしかするとプログラミングの才能があるかもしれません。
アイデアを練る〜多人数で何か会話する
原神キャラほぼ全てが入れ替わり立ち替わりさまざまな会話を編み出す何かを作りたい。当初はTRPGを想定していましたが、TRPGでは私の知識量が不足していて到底、何かをできるような気がしません。調べれば調べるほどこれは経験が必要な分野だと分からせられるのです。
でしたら水平思考で別のことを考えればいいのです。多人数のキャラクターが何か喋ることです。多人数で何か喋ることはあるのでしょうか？
多人数で何か喋ること
一つ思い浮かぶことは、極めて政治的ですが国会です。大臣や閣僚らが代わる代わる何か喋っています。過去の国会の議事録を学習して、疑似国会をやるというものです。これも答弁とか面白いので何か喋らせるには面白いと思いました。
しかし、一応原神のガイドライン的には政治的な内容はあんまやんないでということなので、これはちょっと保留しましょう。やったら面白いですけど。
次に、多人数で何か喋ると言えば証人尋問です。原告弁護士、被告弁護士、証人、裁判官が質問して、あーだこーだ話をします。これがなかなか知略を巡らす必要があるのでなかなか面白いわけです。
政治的かと言えばギリセーフです。しかし、ストーリーラインの構築が難しいです。証人尋問の段階ではわからないこともあります。事件概要を作って、それに沿って証人は証言しなければなりません。原告質問、被告質問、裁判官質問があります。そして証人は複数います。クレー弁護士はちょっと不安です。
そして、私は刑事の専門ではなく、あくまで民事しかやったことがありません。刑事の場合はどうなるかわかりません。しかし、民事の場合、結審のとき小さな部屋で裁判官3名と被告、原告で集まって判決が下されます。刑事よりフランクだと思います。結論だけ要点を絞って話を進めます。
民事の面白いところは登場人物が最低7人も必要なことです。たくさんのキャラに発言する義務が生じます。しかし、これはキャラごとに役割を持たせて、ストーリーラインという大きなワーキングメモリを保持しなければなりません。
多人数会話の実装方針
多人数会話を抽象化してみましょう。
まず、マザーエージェントがストーリーラインを構築します。
チャイルドエージェントがストーリーラインをワーキングメモリに記憶しながら、ステップごとに役割を采配します。例えば、チャイルドエージェントは弁護士質問ということで原告弁護士と証人で会話を行わせるなどです。
次に会話エージェントが会話文を生成します。会話エージェントは話をすぐにフラッシュします。
その次に会話内容を記憶するために速記エージェントに会話を記憶させます。速記エージェントはチャイルドエージェントからたまに疑問点のある会話を問い合わせることがあります。
最後にチャイルドエージェントにステップを進行させ、チャイルドエージェントに処理を委譲します。もし、必要な会話が終わっていれば、これで会話を終了します。
多人数での会話システムではこのような形になるでしょうか？ チャイルドエージェントはステップ単位で複数作ってもいいし、単一でもいいです。
マザーエージェントは1度しか動かしません。あるいは、ステップごとに細かい話を作ってもらう必要があるかもしれません。ステップごとに細かい話があるならステップが進むたびにチャイルドエージェントにその内容を伝えます。
チャイルドエージェントは基本的に采配を司ります。誰を立てて、どんなストーリーで会話するか組み立て、ストーリー立てます。具体的な会話は会話エージェントにやらせます。
速記エージェントが必要なのは、会話内容を思い出させるためです。チャイルドエージェントと速記エージェントは別々のエージェントなので橋渡しをしてあげます。これで、会話の疑問点を引き出すことができます。
具体論に戻る
これでだいたいの複数人会話を実装できると思います。複数のAIをエージェントとして組み合わせることで、ワーキングメモリの少なさを補います。
ただし、ここまで省力化しても会話内容を覚えてもらうのにトークンをバカ喰いします。速記エージェントだけcommand Rのような手元で動かせるAIの方がお金がかからないかもしれません。
複数人で何かを会話する、というテーマで何かを考えればいいので、その何かが何か明らかになると具体的な実装に落とし込めそうですね。
Elinはヤバそうだぞ〜
正直、elonaの後継作と聞いていたので期待していたけれども、elonaそのものを鳥瞰視点で移植しつつ、elonaのストーリーをわかりやすく整理した意欲作だった。elinはelonaよりも操作がしやすい。特に、魔法関係がかなりテコ入れされていて、インベントリの操作もやりやすくなってる。
elonaは5年かけてやっと整うと言われるぐらい難しかった。elinは領地を作る概念があるので、人生がぶち壊されるほどのインパクトがある。GOTYを取ってもおかしくはないと思う。
それぐらい完成された意欲作だと思う。
今後どうするか？
もともとelonaを何ヶ月かやった。elinは何ヶ月では済まなそうなぐらい難易度が高い。税金の支払いの関係で領地に戻って、また税金を払いにいかなければならない。税金の高さによっては高すぎて急いで金策に走らないとまずいこともありそうだ。
そんなわけで、elinはしばらく遊べるゲームだと思う。しばらく遊びたい気持ちが高まってる。まずは領地を作ること。領地を作って持続的に税金を納められるようになりたい。
