※本記事は２０２３年１０月１４日に書いたものです。
(記述中に日を跨いだ為、
「今日」の部分は１４日で置き換えてください)
前に今のままのペースで作成すれば、
600年くらいかかるんじゃね？
さて、どうするか
と書きましたが、
とりあえず、何も考えずこのままペースで作っていきます。
600年かかるなら600年生きたら良いんですよ(暴論の極)
今週は、本業のほうで頭をフルに使う日が多く、
制作はあまりしておりません。
今日描いたのがこれ。
これは一応見ずに描いてますが、
まあ、違和感はあまりなかったので、
このまま清書してもいいかなと思っています。
あと、シナリオテキスト部分などをちょこっと修正し、
二分割時にどちらのテキストが表示されているか、
直観的にわかるようにしました。
→黄色枠をつけただけですが。。
ちなみにこの過程で、
枠用のレイヤーを追加したところ、
ティラノ側でエラーが発生し少しタイムロスしました。
エラー内容的によくわからんかったので、
ぐぐってみたら、
「JavaScript側でプロパティの定義がされていないから」とでてきましたが、
その目線で考えると嵌るタイプのエラーでした。
エラー解消する際は、まずは問題を切り分けないといけません。
この場合では、
自分の記述が間違えているかどうか
記述はあっているがティラノ側の仕様かどうか
システム側の問題かどうか
ですかね。
まず、システム側のエラーだと強○終了とかになって、
綺麗にコンソールにログが測れないと思いますし、
そもそもそうそう起きないので除外。
自分の記述が間違えているかどうかですが、
今回エラーになった発端は、
レイヤーを増やした記述(３つめのレイヤーの使用中)でしたので、
１つ目、２つ目のレイヤーの書き方と同じかどうか
それと
追加した順番、場所、位置関係をみる。
結果として、
１つ目、２つ目のレイヤーの追加と同じやり方で、
３つ目を追加しているのは間違いなかったので、
記述ミスではない。
となると、ティラノ側の仕様によるエラーになります。
ここでぴんときたのが、
ティラノ上で使えるレイヤー数は、
３つ以上あるのですが、
何個までレイヤーを使えるかどうかを設定出来る場所がある。
というのを、
ティラノ公式サイトで書いてたなと思いだしたので、
そこの設定を弄る。
という感じでエラーを解消。
今回のケースのように、
ググるだけでは解消できないこともあります。
公式サイトで使い方を見るのもわりと重要でした。という話。
はい、今日もう一つ試したのが、
ティラノで制作中のプロジェクトをパッケージ化する方法。
→私が作ったものを他の人もできるように配布するには？という話。
これは、
ティラノスクリプト上でパッケージ化するボタンがついているので、
わりと楽だったのですが、色々調べていたのでそこそこ時間がかかりました。
何を調べていたのかというと、
パッケージ化した際に、
私が書いたソースを配布された側が見れるかどうか。
→厳密に言えば絶対に見れなくする方法は、
ない(最新暗号化技術とかでない限り)と思いますが、
ここでは簡単に見れるかどうかという観点で話を進めます。
とりあえず、
何も考えず公式の説明通りにパッケージ化した所、
普通に私の書いたソースや、
絵なども含めて、
構成そのものが全てみれるようになっていました。
いやいや、これはあかんでしょ。
コピペで丸パクリできるじゃん
と焦り、調べました。
ネットで調べるのも良いですが、
ここはまず、自分が今まで買った同人ゲーで、
ティラノを使ってゲーム化している作品があるかどうか、
という観点で調査。
もし、あればその人たちがどういう方法で、
パッケージしているかがわかります。
ちなみに、私が今まで購入した同人ゲーは、
少なく見積もっても1000作品以上はあります。
それらは概ね外付けハードディスクで管理しているので、
それをティラノのワードで検索をかけます。
出てきたのが、３，４作品ほど、サークルさんでいうと２サークルさん。
すくな！と思ったが、
私は基本的にノベルゲー買わないからなー
と少なさに納得した。
ちなみにヒットしたものは、
ノベルゲーではなく調教シミュレーションです。
→ティラノはクリックゲーには強いので、
調教シミュレーションとはそこそこ相性が良いかもしれません。
※マウスホバーやドラッグ操作は制御しづらいので、
お触り系はちょいと難度が高くなるかもという印象(偏見)です。
で、結果として、
サークル１さんは、ソースが見えない状態でパッケージ化していて、
サークル２さんは、ソースが見える状態でパッケージ化していました。
ちなみにサークルさん２のほうのソースを確認したところ、
めちゃくちゃソース書いててビビりましたが、
ソースの書き方が綺麗すぎる感じがしたので、
もしかしたら有料版で自動生成されたソースかなと思いました。
→本人に聞いたわけではないので、真偽はわかりませんが。
で、気になるのはサークル１さんのほう、
まあ、手段としてはソースを見えなくする方法はある、
といった感じでしたので、
もう一度パッケージ化する時の設定項目を確認しました。
で、
ファイルを隠ぺいする
という項目があったので、
そいつにチェックを入れてパッケージ化したところ、
望み通りの形になりました。
ただ、この項目にチェックを入れると動作が重くなるみたいなことが、
書かれていたので、
懸念点としてありますが、
私の制作分はそこまでボリュームは大きくならないと思うので、
今のところは気にしなくて良いかなと考えています。
ちなみにその時にできたやつがこれ
tyranoproject-win32-x64.7z (58.76MB)
ダウンロード
遊んでもらうようというよりは、
パッケージ化とダウンロードテスト用です。
しかし、
今まで作った所までの部分と、
その先のテキスト部分も同梱していますので、
ネタバレOKという方は自由に使ってもらって構いません。
→後半部分のテキストは最初期に書いたものを、
入れてるだけなので前半部分と整合性が、
とれていない可能性があります。
→音は入っていません
→ある手順を踏むとエラーになる箇所があります
→７ZIPで圧縮したので、解凍する場合は７ZIPでお願いします。
→パスは私の名前にしてあります。
注意点
いないとは思いますが、
2次配布はとりあえず今はやめてください。
モザイクは一応全てにかけている認識ですが、
漏れがある可能性もなくはないので、
まずいやつがあればこっそり教えてください。
■僕はどう作るかの話
少しまじめな話をします。(いつも真面目ですが)
サークル活動をする方は、
日に日に増えてきているのは、
フォロワーのフォロワーを見ていればなんとなくわかりますが、
それと同時に消えていくサークルさんもちょくちょく見かけます。
中には辞めたいけど、
辞めれない状況に陥っているサークルさんの記事も見かけました。
個人的に思う、制作の引き際パターン。
１、技術的に詰まる
２、制作した作品が立て続けに売れなかった
３、完成の目途が立たない
１について
やりたい事が実現することができないというパターン。
私の想像ですが、考えられることとしては、
そもそも使用しているゲームエンジンでは実現できない事をやろうとした、
と言うのが原因として挙げられます。
エンジンはゲームを簡易につくれるのが
最大の目的だと考えると、
より複雑なシステム、斬新なシステムの実装は、
非常に困難となる。(プラグイン待ちとなる)
その為、ツールの機能に頼った制作をしていると、
おのずとゲームのシステムはツールの機能に依存してきます。
これってお絵描きツールにも同じような事が言えますよね。
お絵描きツールの専用機能に頼った描き方をすると、
いざそのツールが使えなくなった時、
同じものが作れなくなる。
かもしれないということです。
２について
生きるには金がいります。
制作するものにも金がいります。
制作したものが売れなければ、
活動の継続は物理的に厳しくなるでしょうという、
どの業界でも同じようなことが言える基本の話。
プロ級の方も同人業界に参画しているように思う為、
より素人が見よう見まねで制作した作品で活躍するのが、
厳しくなってきています。
同人を本業としていくやっていくのは、
相当の覚悟が必要になるなーと思います。
また、時間をかけて作ったものが、
想定より売れなかった時の衝撃は、
現時点の私では測りかねますが、
いずれそれが分かるときが来るかもしれないですね。(,,#ﾟДﾟ)
３について
今の私のような状態。
初めは小さく小さく作るのが良いと思いますが、
何に一番時間がとられるのかを分かっていないと、
どこを削ればいいのかがわからなくなる状態。
ずっと走り続けても、
ゴールが見えてこないとしんどい的な？
あと、作りたいものが何なのかをわからなくなる。
と言ったこともここに含まれますね。
作品のイメージやコンセプトが、
ざっくりとしたものであった場合、
いざ作ってみると、
なんかしっくりこないという感覚を、
常に感じてしまう状態になります。
開き直って、
色んなパターンを全て作ってみるというのも、
悩んで先に進まないよりはましなので、
失敗してもいいやんという気持ちもいるかもしれません。
１，２，３に言えることは、
設計思想に関わる所になるかなーと思います。
WEBシステムでは、
MVCモデルという基本の設計思想というのが存在しますが、
ゲームのシステムにはそれはあるのか？
とふと思いました。思うだけで調査には至ってませんが。
ゲームを制作する側が、
最低限認識しておかないといけないことは、
今自身がゲーム画面で目に見えている挙動は、
「勝手にそうはならない」
ということです。
そういう挙動になるように作っている。
(そう見えるように疑似的に作られていることが多いと思われる)
当たり前の事を言ってるように見えて、
その見えない部分に思いを馳せることはとても難しいです。
なので、自身が他の人が作ったゲームをやっていて、
こうしたほうが良いのに、
という部分が、誰もやったことがないものであれば、
どうすればそれが実現できるかを、
自身で編み出さなければいけないです。
「勝手にそうはならない」からです。
例のごとく、前置きが長くなってしまいましたが、
これを踏まえて
僕はどう作るか
なんですけど、
私のゲーム制作方針は、
今年の２月あたりにざっくりとしたものは書いています。
なので、
同じ方針で良いかという観点と、
別の方針でつくるとしたらという観点で、
話を進めていきます。
結論を言うと、
私が今作ろうとしているものについては、
現時点ではまだ、
今のままの方針(シナリオ重視、ゲーム性低め、エロ度上げる)で、
良いと思っています。
問題はそのあとです。
将来的には、
シナリオに沿ってゲーム性をあげていきたい
と考えていますが、
やみくもに作ろうとすると、
先に挙げた引き際パターン１に陥る可能性が高まります。
例えばの話ですが、
RPGを作ろうとした場合、
私個人の考えでは、
RPGの面白さというのは、
攻撃手段の多さに比例すると思っています。
FFが良くわかりやすいと思いますが、
FFの世界ではジョブ式という言葉があり、
ジョブごとに攻撃手段を切り替えることができます。
子供時代にそれがすごく楽しかったという事を覚えています。
しかし、同人ゲームにあるRPGでの、
攻撃手段といえば、
戦う(武器ごとの攻撃)
魔法(レベルかアイテムで増える)
特技(レベルかアイテムで増える)
基本はこの形です。
プレイヤー側が出来ることと言えば、
お金を溜めて、
新しい武器を買う。
またはレベルを上げて新しい魔法(特技)を覚える。
となります。
これだと先が見えて面白くないですよね。
でも、
この基本システムはゲームエンジンに依存しているので、
エンジンそのものを改造しなければ、
攻撃手段を変えることはできない。
少なくともウォルフエディタでのゲーム制作を検索してみたら、
そんな印象を受けました。
こういった話は、
作りたいものが先にあって、ゲームを作るのか、
作れる技術が先にあって、ゲームを作るのか
の違いになりますが、
ゲーム制作の成功率が高くなるのは後者です。
エンジンでできることを先に調べた上で、
ゲーム制作に挑む方が、
まだイージーなやり方です。
ただし、
作れる技術に合わせてエロを構築しないといけないので、
発想やセンスが必要となってくると思います。
私には前者で作成を考えてしまう傾向が強いので、
ここで躓きそうな気配を感じています。
とりあえず、
現時点でのざっくり目標としては、
当面は
ティラノ、ウォルフエディタで、
シナリオ重視、ゲーム性低め、エロ度上げて、
の方針でゲーム制作。
ゲーム性を高くしたい時は、
Unityあたりで、
アセットかC＃でなんとかする。
何とかできるのを確認した上で、
ゲーム制作を考える。
という感じでしょうかね。
あとは、
色んなゲームエンジンを一通り触ってみるとかも、
良いかもしれないかな。
■最近プレイしたゲーム
くすぐりオークション
パンダスキャナーズ
をプレイしました。
これ、とてもよかったです。
私は同じサークルさんの最新作もプレイしていますが、
個人的にはこっちのほうがエロいと思いました。
このゲームの主体はくすぐりになります。
以前、「性癖討論会」というゲームの感想で、
くすぐりではシコれなかったという話をしましたが、
これはいけますわ。
絵面としては、
非暴力のように見えるのが、
くすぐりでシコれない原因だったと言いましたが、
このサークルさんは、
非暴力で強い暴力を表現するのが、
非常に上手だと思いました。
ここで重要なのは、
対象がして欲しくないことを、
無理やりやるということです。
そのポイントは、
完全拘束せずに、
少し逃げれる余地を残しておく、
ということにあると思いました。
逃げれるからこそ、
「して欲しくない」を大きく表現でき、
逃げた先で「やる」からこそ、
強い暴力性や征服感を表現し、それに乗じて興奮度が高まるという、
人間がもつ
「いじめの心理」
を見事に再現したゲームでした。
少し毛色が違うかもしれないですが、
好きな子(気になる子)にちょっかいをかけて、
反応を見るのが好き、
という感覚も、
このゲームには含まれているかも、
と思いました。
そんなに複雑なゲーム性ではないですが、
システム的には結構斬新さがありました。
ありていに言えば、
ありそうでなかった部類のゲームですかね。
