街や人の名前を決める時、関連性を持たせることがよくある。
食べ物の名前で統一したり、全て有名人の名前からとったり。
名前を考える手間が省けるうえ、プレイヤーに
「次はどんな名前が出るかな?」
と思わせる事ができる。そして忘れにくい。
あまり重い雰囲気のゲームでは使えないのが欠点か。
食べ物の名前で統一したり、全て有名人の名前からとったり。
名前を考える手間が省けるうえ、プレイヤーに
「次はどんな名前が出るかな?」
と思わせる事ができる。そして忘れにくい。
あまり重い雰囲気のゲームでは使えないのが欠点か。
製作中のゲームのデータや素材などが
事故で消えてしまうのはもちろんショック。
しかしながら「消してしまう」ことも
同じくらいショックだ。
もう必要ないと思ってゴミ箱に捨ててその直後に
ゴミ箱を空にしてその後で実は必要だったと言うことが発覚したり。
もう制作が凍結したからと言ってプロジェクトを削除した
あと、しばらくしてからまた作りたくなったり。
自分の手によるものなので悔やんでも悔やみきれない。
ゴミ箱を空にするときはよく考えてからのほうがいい。
ちなみに私が今日、こういう被害に遭ったわけではない。
なんとなく思っただけ。
事故で消えてしまうのはもちろんショック。
しかしながら「消してしまう」ことも
同じくらいショックだ。
もう必要ないと思ってゴミ箱に捨ててその直後に
ゴミ箱を空にしてその後で実は必要だったと言うことが発覚したり。
もう制作が凍結したからと言ってプロジェクトを削除した
あと、しばらくしてからまた作りたくなったり。
自分の手によるものなので悔やんでも悔やみきれない。
ゴミ箱を空にするときはよく考えてからのほうがいい。
ちなみに私が今日、こういう被害に遭ったわけではない。
なんとなく思っただけ。
お金が絡むと物事は厄介になるのが常だがフリーソフトの場合、
お金が絡まないがゆえの厄介さというのもあると思う。
フリーソフトに限らずフリー素材などに関しても同様だ。
シェア、製品の場合はお金が取引き材料になるので
誠意の方向性は明確である。つまり売り手にのみ求められる。
フリーの場合はお金が介在しないので制作者とユーザーの双方に
誠意が求められているとも言えるが、たとえ片方(もしくは両方)が
誠意を見せなくても事が済んでしまう場合も少なくない。
ここが問題である。お金が絡まないということが双方の
(あくまでも取引きをする時だけの)上下関係を不透明なものに
してしまっているわけだ。
お金が絡まないがゆえの厄介さというのもあると思う。
フリーソフトに限らずフリー素材などに関しても同様だ。
シェア、製品の場合はお金が取引き材料になるので
誠意の方向性は明確である。つまり売り手にのみ求められる。
フリーの場合はお金が介在しないので制作者とユーザーの双方に
誠意が求められているとも言えるが、たとえ片方(もしくは両方)が
誠意を見せなくても事が済んでしまう場合も少なくない。
ここが問題である。お金が絡まないということが双方の
(あくまでも取引きをする時だけの)上下関係を不透明なものに
してしまっているわけだ。
顔グラフィックの役割
2004年9月18日 コラム顔グラフィックの主な役割は話し手を明確にするためのもの
(同じキャラで表情が異なる多数のグラフィックを使っている場合は
その限りにあらず)である。
その他に話し手を明確にする手段として話し手の名前を
ストレートに表示する手法とウィンドウの表示位置を
調整する(フキダシのように)手法、そしてボイスによる手法などが
挙げられる。
おそらく多くのRPGではこれらの方法を併用するだろう。
ツクールXPの場合はスクリプトを使えばウィンドウの表示位置を
調整する手法がより簡単に行えるのでやってみるといいかも。
(同じキャラで表情が異なる多数のグラフィックを使っている場合は
その限りにあらず)である。
その他に話し手を明確にする手段として話し手の名前を
ストレートに表示する手法とウィンドウの表示位置を
調整する(フキダシのように)手法、そしてボイスによる手法などが
挙げられる。
おそらく多くのRPGではこれらの方法を併用するだろう。
ツクールXPの場合はスクリプトを使えばウィンドウの表示位置を
調整する手法がより簡単に行えるのでやってみるといいかも。
ゲームの途中経過をセーブする意味というのは二つある。
ひとつは一度ゲームを中断するための手段。
特にRPGはクリアに時間がかかるので"はじめから"を選んで
そのままエンディングまで直行する事はまずない。
もうひとつはゲームオーバーやそれに準ずるペナルティ(バグも含む)
を受けたときにやり直しを短縮するための手段、つまり保険。
両者は混同してしまいがちだが、実質は大きく異なる。
後者の場合、制作者があえて制限する事に意味が存在する。
そのエンタテインメントがゲームであることを示すには
ペナルティが存在するかどうかを考えればいい、と言っても
過言ではない。それだけ重要な要因である。
いつでもセーブが出来る場合、ペナルティの脅威が減ることになる。
だからこそある程度の制限を加えるのだ。少なくとも戦闘中に
セーブ可能なゲームはほとんどない。
前者の場合、制作者がそれを制限する理由も意味も全くない。
当り前である。
となるとここで当然の如く問題が発生する。
ペナルティの脅威をプレイヤーに示すためにセーブを制限すると
プレイヤーの都合でゲームを中断せざるを得なくなった時に
セーブできなくなる。
かと言っていつでもセーブできるように設定するとゲーム性を
損ねてしまう可能性がある。さらにセーブを制限するもうひとつの
理由として「ゲームオーバーがほぼ確定の状態でセーブすることで
進退窮まってしまうことを防ぐ」が挙げられるがいつでもセーブ可能
なら上記のような状態に陥ってしまう可能性も充分にある。
そこで最近の市販RPGには中断というシステムが用いられる事が
少なくない。これはロードした際にセーブ内容を削除してしまう
システムのことでゲーム性とプレイアビリティの両立に成功している。
さて、この中断システムだがツクール200Xでは導入不可能な
システムだったがXPでは導入可能(のはず)である。
私はスクリプト素材サイトについてよく知らないが
もう既にこのようなスクリプトを公開しているサイトが
あるのではないだろうか。
このシステムはメリットこそあってもデメリットのない
システムなので(システムというほどのことでもないが)
導入を検討してみるのも悪くないと思う。
ひとつは一度ゲームを中断するための手段。
特にRPGはクリアに時間がかかるので"はじめから"を選んで
そのままエンディングまで直行する事はまずない。
もうひとつはゲームオーバーやそれに準ずるペナルティ(バグも含む)
を受けたときにやり直しを短縮するための手段、つまり保険。
両者は混同してしまいがちだが、実質は大きく異なる。
後者の場合、制作者があえて制限する事に意味が存在する。
そのエンタテインメントがゲームであることを示すには
ペナルティが存在するかどうかを考えればいい、と言っても
過言ではない。それだけ重要な要因である。
いつでもセーブが出来る場合、ペナルティの脅威が減ることになる。
だからこそある程度の制限を加えるのだ。少なくとも戦闘中に
セーブ可能なゲームはほとんどない。
前者の場合、制作者がそれを制限する理由も意味も全くない。
当り前である。
となるとここで当然の如く問題が発生する。
ペナルティの脅威をプレイヤーに示すためにセーブを制限すると
プレイヤーの都合でゲームを中断せざるを得なくなった時に
セーブできなくなる。
かと言っていつでもセーブできるように設定するとゲーム性を
損ねてしまう可能性がある。さらにセーブを制限するもうひとつの
理由として「ゲームオーバーがほぼ確定の状態でセーブすることで
進退窮まってしまうことを防ぐ」が挙げられるがいつでもセーブ可能
なら上記のような状態に陥ってしまう可能性も充分にある。
そこで最近の市販RPGには中断というシステムが用いられる事が
少なくない。これはロードした際にセーブ内容を削除してしまう
システムのことでゲーム性とプレイアビリティの両立に成功している。
さて、この中断システムだがツクール200Xでは導入不可能な
システムだったがXPでは導入可能(のはず)である。
私はスクリプト素材サイトについてよく知らないが
もう既にこのようなスクリプトを公開しているサイトが
あるのではないだろうか。
このシステムはメリットこそあってもデメリットのない
システムなので(システムというほどのことでもないが)
導入を検討してみるのも悪くないと思う。
経験値曲線と言えば2003の超素敵仕様を思い出します。
その反動かどうかは分かりませんが現在製作中の作品では
EXPはレベルに関わらず100でレベルアップとして
現在のレベルによって入る経験値の量を変えるシステムを
採用することにしました。
これのメリットはメニュー上で経験値を表示する際に
桁数が2桁で済むので楽(さらに軽い)だという点です。
となると元の経験値から獲得経験値を算出する式が必要になります。
で、この式を考えたのですが…
難しい。
基本のかたちは「元のEXP÷LV」か「元のEXP-LV」として
それに色々、式や値を付け加えようと思ったのですが
これがどうもうまくいきません。
ツクールで扱う変数はC言語などで言う「int型の変数」のみなので
「÷」はやや扱いにくいため「-」にしようと考えたのですが
こうなるとレベルが上がっていくにつれその差が気にならなく
なってしまいます。
どうしたものか。ちなみに丁寧語はきまぐれです。
>>charさん
それなら体育の授業の時にペアで筋トレをやらされた際に
ちょっとやったことがあります。
10回が限界で、しかも最後の方は足が床についてましたが…
その反動かどうかは分かりませんが現在製作中の作品では
EXPはレベルに関わらず100でレベルアップとして
現在のレベルによって入る経験値の量を変えるシステムを
採用することにしました。
これのメリットはメニュー上で経験値を表示する際に
桁数が2桁で済むので楽(さらに軽い)だという点です。
となると元の経験値から獲得経験値を算出する式が必要になります。
で、この式を考えたのですが…
難しい。
基本のかたちは「元のEXP÷LV」か「元のEXP-LV」として
それに色々、式や値を付け加えようと思ったのですが
これがどうもうまくいきません。
ツクールで扱う変数はC言語などで言う「int型の変数」のみなので
「÷」はやや扱いにくいため「-」にしようと考えたのですが
こうなるとレベルが上がっていくにつれその差が気にならなく
なってしまいます。
どうしたものか。ちなみに丁寧語はきまぐれです。
>>charさん
それなら体育の授業の時にペアで筋トレをやらされた際に
ちょっとやったことがあります。
10回が限界で、しかも最後の方は足が床についてましたが…
ツクールにおいて面倒なのが街。
街は人工と自然の中間に位置している場合が多く
オブジェクトの規則性をどの程度にするかなどで迷う。
ところで私の場合は街の周囲を壁や水などの障害物で囲む事にしている。
そうすることで街の入口が分かりやすくなるからだ。
しかし周囲を障害物で囲む事を前提とした場合うまく作らないと
なんとなく違和感が出ることも多いのだが。
>>ゲンさん
おお、ありがとうございます。
街は人工と自然の中間に位置している場合が多く
オブジェクトの規則性をどの程度にするかなどで迷う。
ところで私の場合は街の周囲を壁や水などの障害物で囲む事にしている。
そうすることで街の入口が分かりやすくなるからだ。
しかし周囲を障害物で囲む事を前提とした場合うまく作らないと
なんとなく違和感が出ることも多いのだが。
>>ゲンさん
おお、ありがとうございます。
ゲームにおける不具合には2種類あるような気がしたので勝手に分類した。
問題の原因がプレーヤーにもおおよその見当が付く場合と付かない場合だ。
そりゃ、"A"と"Aでないもの"という分け方をしたらどんなものも
二種類になるわけだけど、それは置いといて…
誤字脱字や顔グラフィックのミスなどは前者
画面がブラックアウトしたまま元に戻らないとかは後者だ。
市販の場合、後者はよくある(確率により発動するのがほとんどだけど)
のだが前者はなかなかお目にかかれないレアな不具合である。
よってプレーヤーは後者の不具合に遭遇すると怒るのだが
前者の場合は喜ぶのである。(私だけかも)
※ちなみに私のゲームの場合は前者の不具合も多いのであまり
レアではありません。
問題の原因がプレーヤーにもおおよその見当が付く場合と付かない場合だ。
そりゃ、"A"と"Aでないもの"という分け方をしたらどんなものも
二種類になるわけだけど、それは置いといて…
誤字脱字や顔グラフィックのミスなどは前者
画面がブラックアウトしたまま元に戻らないとかは後者だ。
市販の場合、後者はよくある(確率により発動するのがほとんどだけど)
のだが前者はなかなかお目にかかれないレアな不具合である。
よってプレーヤーは後者の不具合に遭遇すると怒るのだが
前者の場合は喜ぶのである。(私だけかも)
※ちなみに私のゲームの場合は前者の不具合も多いのであまり
レアではありません。
戦闘アニメを自作する際(素材の自作ではなく)
たくさん作っているとそのうち内容が似たりよったりに
なってしまう。
そういう時はセルのアニメーションを逆にしてみると
いいかも知れない。セル画を12345とするところを
54321にするわけだ。
こうすると普通は爆発などに使用するアニメ素材で
エネルギーが収束しているような演出をすることができる。
もちろん、ほとんどの場合は意味不明なものが
出来上がって終わるのがオチなため苦肉の策ということで。
>>ゲンさん
こちらこそよろしくお願いします。
たくさん作っているとそのうち内容が似たりよったりに
なってしまう。
そういう時はセルのアニメーションを逆にしてみると
いいかも知れない。セル画を12345とするところを
54321にするわけだ。
こうすると普通は爆発などに使用するアニメ素材で
エネルギーが収束しているような演出をすることができる。
もちろん、ほとんどの場合は意味不明なものが
出来上がって終わるのがオチなため苦肉の策ということで。
>>ゲンさん
こちらこそよろしくお願いします。
どうでもいいけど…
のあとに続く文章がどうでもいいわけがない。
どうでもいいなら書かない。
管理人さん不快でしたら削除してください。
で終わる文章を本当に削除して欲しくて書いているわけがない。
削除して欲しい文章なんて投稿しない。
つまり言葉のあやである。
しかしながらこれらは特にネット上のコミュニケーションにおいて
誤解を招く要素になったり、思わぬかたちで相手に不快感を
与える事になる。
例えば後者の文章は削除するか否かの判断を管理者に任せている
ようにも見える。(実際にそういう意味で使う時もあるが)
このように一部の言葉のあやは投稿者の意図を不明瞭にしてしまう
一面があるので使わない方がいいと思う。また、みる側もこの手の
文章は言葉のあやなんだと最初から理解していれば問題ない。
のあとに続く文章がどうでもいいわけがない。
どうでもいいなら書かない。
管理人さん不快でしたら削除してください。
で終わる文章を本当に削除して欲しくて書いているわけがない。
削除して欲しい文章なんて投稿しない。
つまり言葉のあやである。
しかしながらこれらは特にネット上のコミュニケーションにおいて
誤解を招く要素になったり、思わぬかたちで相手に不快感を
与える事になる。
例えば後者の文章は削除するか否かの判断を管理者に任せている
ようにも見える。(実際にそういう意味で使う時もあるが)
このように一部の言葉のあやは投稿者の意図を不明瞭にしてしまう
一面があるので使わない方がいいと思う。また、みる側もこの手の
文章は言葉のあやなんだと最初から理解していれば問題ない。
文章の最後には"。"が必要である。
だが実際に打ち込んでみると"。"が邪魔かな、と思う場面が若干ある。
そういう時は消す事にしているのだが消したら消したで
やっぱりあった方が… などと思うこともしばしば。
統一感がないのがもっともよくないわけだが…
だが実際に打ち込んでみると"。"が邪魔かな、と思う場面が若干ある。
そういう時は消す事にしているのだが消したら消したで
やっぱりあった方が… などと思うこともしばしば。
統一感がないのがもっともよくないわけだが…
HTMLヘルプファイルとツクール2000
2004年8月23日 コラム実はちょっと似てたりする。
まずオープンソース。丸見えである。
見られたくない人はソースの中に「見るな」とか仕掛けたりする。
そして画像は丸出し。
ファイル数が多くなりがち。どれをクリックすればいいのか
よく分からない。
でも敷居は低い。それがメリット。
違う点といえばHTMLファイルはコンパイルすれば
CHMファイルになってひとつにまとまるところか。
これのせいでツクールXPに暗号化機能が搭載されたとき
それをコンパイルと混同してしまった人がいたとか、いなかったとか。
そうえいばXMLというのはHTMLと似ているが
独自タグを作成できるらしい。
ツクールXPとほんの少し似ているかもしれない。
まずオープンソース。丸見えである。
見られたくない人はソースの中に「見るな」とか仕掛けたりする。
そして画像は丸出し。
ファイル数が多くなりがち。どれをクリックすればいいのか
よく分からない。
でも敷居は低い。それがメリット。
違う点といえばHTMLファイルはコンパイルすれば
CHMファイルになってひとつにまとまるところか。
これのせいでツクールXPに暗号化機能が搭載されたとき
それをコンパイルと混同してしまった人がいたとか、いなかったとか。
そうえいばXMLというのはHTMLと似ているが
独自タグを作成できるらしい。
ツクールXPとほんの少し似ているかもしれない。
製作とは実用的なものを
制作とは芸術的なものをつくること。
ではなにが芸術的で、なにが実用的なのか。
前にも似たような話をしたかも知れないが
対象が「手段」なら実用的、「目的」なら芸術的
というのかもっともしっくりくる回答だろうか。
ゲームは実用性皆無なので制作が正しいのだろうが
正直、使い分けは難しいと思う。
もともと意味の近い熟語であるうえ字も似ている。
その微妙な違いは辞書を引くなどしないとなかなか分からない。
日本語の熟語にはこの手のものがとても多い。
その全ての正確な意味を知るのは困難であるし
熟語の意味など時とともに容易に移り変わってしまう。
だが、だからこそ日本語は細かい表現に優れている。
ある意味、日本語は芸術的な言語であり英語は実用的な言語である
と言えるのではないだろうか。
>>くろさん
カードを使ったシステムみたいですね。
市販でもフリーでもそういうシステムのRPGは
まだやったことがないので楽しみにしてます。
制作とは芸術的なものをつくること。
ではなにが芸術的で、なにが実用的なのか。
前にも似たような話をしたかも知れないが
対象が「手段」なら実用的、「目的」なら芸術的
というのかもっともしっくりくる回答だろうか。
ゲームは実用性皆無なので制作が正しいのだろうが
正直、使い分けは難しいと思う。
もともと意味の近い熟語であるうえ字も似ている。
その微妙な違いは辞書を引くなどしないとなかなか分からない。
日本語の熟語にはこの手のものがとても多い。
その全ての正確な意味を知るのは困難であるし
熟語の意味など時とともに容易に移り変わってしまう。
だが、だからこそ日本語は細かい表現に優れている。
ある意味、日本語は芸術的な言語であり英語は実用的な言語である
と言えるのではないだろうか。
>>くろさん
カードを使ったシステムみたいですね。
市販でもフリーでもそういうシステムのRPGは
まだやったことがないので楽しみにしてます。
今回は敵キャラをピクチャーで表示させているので
予想以上に重くなって対処法を考案中です。
(原因は他にもありそうですが)
それはそうとプライオリティ。
2003の素敵仕様ではピクチャーより戦闘アニメの方が
上に表示される。2000は知らないけど多分同じ。
だがしかし、昔はピクチャーの方が上だったのだ。
それがバージョンアップと共に突然、入れ替わった。
確かに当時戦闘アニメよりピクチャーの方が上に表示される
ことに不満を持っていた人は多かったと思う。
その時、私はネットをやっていなかったので断言はできないが。
でも、もしピクチャーが上に表示される仕様を受け入れて
制作を始めた人がいたとしたら突然、仕様が変わることで
企画が台無しになる可能性も否定できない。
プライオリティは自作システムを作る上で非常に重要な仕様である。
ところで同じプライオリティのイベントが重なった時の
優先順位が曖昧な気がするのは私だけだろうか。
てっきりIDがキーになるのかと思っていたがどうやら違うらしい。
>>くろさん
スクショ、じっくり拝見させてもらいました。
やっぱり自作戦闘はツクールの華ですね。
システムの詳細が気になります。
っと、これは後のお楽しみですね。
>>charさん
総合サイト、結構知らないのもありますね…
ツクール界は思ったより広いんですね。
予想以上に重くなって対処法を考案中です。
(原因は他にもありそうですが)
それはそうとプライオリティ。
2003の素敵仕様ではピクチャーより戦闘アニメの方が
上に表示される。2000は知らないけど多分同じ。
だがしかし、昔はピクチャーの方が上だったのだ。
それがバージョンアップと共に突然、入れ替わった。
確かに当時戦闘アニメよりピクチャーの方が上に表示される
ことに不満を持っていた人は多かったと思う。
その時、私はネットをやっていなかったので断言はできないが。
でも、もしピクチャーが上に表示される仕様を受け入れて
制作を始めた人がいたとしたら突然、仕様が変わることで
企画が台無しになる可能性も否定できない。
プライオリティは自作システムを作る上で非常に重要な仕様である。
ところで同じプライオリティのイベントが重なった時の
優先順位が曖昧な気がするのは私だけだろうか。
てっきりIDがキーになるのかと思っていたがどうやら違うらしい。
>>くろさん
スクショ、じっくり拝見させてもらいました。
やっぱり自作戦闘はツクールの華ですね。
システムの詳細が気になります。
っと、これは後のお楽しみですね。
>>charさん
総合サイト、結構知らないのもありますね…
ツクール界は思ったより広いんですね。
宝箱が4つあるとする。どれか1つにだけ当たりがあり
どれか1つだけ開けることができるとするならば
当たりを開ける確率はいくらか?
もちろん25%である。
こんなミニゲームを作ろうと思った時
ツクールではどのように作るだろうか?
まず4つの宝箱に便宜上の番号を付け、さらにイベント前に
乱数(1-4)を取り宝箱を開けたときに宝箱に付加した
番号と乱数を比較して一致した場合は当たり、と。
まっとうなやり方である。
しかしこのように作ることもできる。
どうせ当たる確率は25%だ。だったら宝箱を開けたときに
乱数(1-4)を取り1の時のみ当たりの分岐をすればいい。
プレイヤーは宝箱を開けるときにどれが当たりか悩むだろう。
しかし後者の場合、そのプロセスは完全に無意味のように思える。
(前者も実質上は無意味だが) どれを選んでも実行する処理自体が
全く同じものなのだから。
しかし本当は無意味ではない。例えばプレイヤーが宝箱を開けたあと
それがはずれでその左の宝箱が当たりだった場合、プレイヤーは
「ああ、左を空けていれば…」と思うだろう。プレイヤーはそのような
後悔が無意味だと頭のどこかで分かっていてもやはり後悔するのである。
たとえ、宝箱を開いた時に確率分岐が行われたとしても、また
そのような処理が行われていることをプレイヤーが知っていた
としても、である。
ゲームがプレイヤーに向けて発信する情報をプレイヤーは何倍にも
増幅して、補完して受け取っているのである。これはゲームに
限った話ではない。ゲームにしろ小説にしろ楽しめるかどうかは
この増幅の度合いにかかっている。つまりプレイヤー次第なのだ。
ところで市販ゲーム(ゼルダやマリオパーティなどのミニゲーム)は
こういうとき、中でどのような処理を行っているのか気になるところである。
どれか1つだけ開けることができるとするならば
当たりを開ける確率はいくらか?
もちろん25%である。
こんなミニゲームを作ろうと思った時
ツクールではどのように作るだろうか?
まず4つの宝箱に便宜上の番号を付け、さらにイベント前に
乱数(1-4)を取り宝箱を開けたときに宝箱に付加した
番号と乱数を比較して一致した場合は当たり、と。
まっとうなやり方である。
しかしこのように作ることもできる。
どうせ当たる確率は25%だ。だったら宝箱を開けたときに
乱数(1-4)を取り1の時のみ当たりの分岐をすればいい。
プレイヤーは宝箱を開けるときにどれが当たりか悩むだろう。
しかし後者の場合、そのプロセスは完全に無意味のように思える。
(前者も実質上は無意味だが) どれを選んでも実行する処理自体が
全く同じものなのだから。
しかし本当は無意味ではない。例えばプレイヤーが宝箱を開けたあと
それがはずれでその左の宝箱が当たりだった場合、プレイヤーは
「ああ、左を空けていれば…」と思うだろう。プレイヤーはそのような
後悔が無意味だと頭のどこかで分かっていてもやはり後悔するのである。
たとえ、宝箱を開いた時に確率分岐が行われたとしても、また
そのような処理が行われていることをプレイヤーが知っていた
としても、である。
ゲームがプレイヤーに向けて発信する情報をプレイヤーは何倍にも
増幅して、補完して受け取っているのである。これはゲームに
限った話ではない。ゲームにしろ小説にしろ楽しめるかどうかは
この増幅の度合いにかかっている。つまりプレイヤー次第なのだ。
ところで市販ゲーム(ゼルダやマリオパーティなどのミニゲーム)は
こういうとき、中でどのような処理を行っているのか気になるところである。
自作ゲームの宣伝に関しては以前にもちょっと日記に
書いたのだがもう少しいろいろ考えてみる。
◆文章によるアピール
文章による宣伝はおもにストーリーに関するものになるだろう。
ストーリーについて宣伝する際はやはり簡単な序盤の
あらすじを書いておくのが一番だ。
感動の、とか構想○年の、とか壮大な、とか
抽象的な宣伝文句だけだと子供に限り好印象を与えられる。
エンディングや落ちに関して言及するのはあまり勧められない。
例えば「衝撃のラストが」「予想を遥かに上回るオチ」などと
書くとプレイヤーは身構えてしまいオチに対してあまり驚かなくなる。
これからダジャレを言うよ、と宣言したあとにダジャレを言うようなもの。
◆スクリーンショットによるアピール
スクリーンショットでは文字制限では言及しきれないシステム関連の
アピールをする場合が多い。ただ、大半はデフォルトを使用し
シナリオで勝負する場合は文章の方で書いたあらすじを視覚的に
表現するスクリーンショットを載せるといいだろう。
沈黙は金という言葉は今の日本にも確かに残っている。
雄弁すぎる宣伝は嫌われるのだ。スクリーンショットは実際
どんな文章よりも雄弁なのだが見ている側はそれを感じない。
◆市販ゲームのパッケージ
市販のゲームの箱の裏側に書かれている宣伝文句は
プロの手によるものなので宣伝文やスクリーンショットを
決める上で参考になるだろう。ただ、市販のものより
若干、抑えたほうがいいように個人的には思う。
>>charさん
やっぱり夏休みは運動不足になりがちですね…
書いたのだがもう少しいろいろ考えてみる。
◆文章によるアピール
文章による宣伝はおもにストーリーに関するものになるだろう。
ストーリーについて宣伝する際はやはり簡単な序盤の
あらすじを書いておくのが一番だ。
感動の、とか構想○年の、とか壮大な、とか
抽象的な宣伝文句だけだと子供に限り好印象を与えられる。
エンディングや落ちに関して言及するのはあまり勧められない。
例えば「衝撃のラストが」「予想を遥かに上回るオチ」などと
書くとプレイヤーは身構えてしまいオチに対してあまり驚かなくなる。
これからダジャレを言うよ、と宣言したあとにダジャレを言うようなもの。
◆スクリーンショットによるアピール
スクリーンショットでは文字制限では言及しきれないシステム関連の
アピールをする場合が多い。ただ、大半はデフォルトを使用し
シナリオで勝負する場合は文章の方で書いたあらすじを視覚的に
表現するスクリーンショットを載せるといいだろう。
沈黙は金という言葉は今の日本にも確かに残っている。
雄弁すぎる宣伝は嫌われるのだ。スクリーンショットは実際
どんな文章よりも雄弁なのだが見ている側はそれを感じない。
◆市販ゲームのパッケージ
市販のゲームの箱の裏側に書かれている宣伝文句は
プロの手によるものなので宣伝文やスクリーンショットを
決める上で参考になるだろう。ただ、市販のものより
若干、抑えたほうがいいように個人的には思う。
>>charさん
やっぱり夏休みは運動不足になりがちですね…
近頃、成績のことが気になって仕方がないせいか始終、胃が痛く
日記の文章もそのせいで壊れかかっている状態ですみません。
無理矢理関連付けようとしても無駄だった。
関連付けと言えば拡張子なわけだが(?)これは
人によっていろいろ拘りがある。
htmとかjpgとか本来4文字の拡張子を3文字に縮めるのは嫌だとか
(昔は拡張子は3文字と決まっていてその名残らしい)
大文字じゃないとだめだとかその逆とか…
私は文字数はどうでもいいけど拡張子は小文字がいいと思う。
メールなんかでも全部大文字だとなんか叫んでいるように見える
というので避けた方がいいというのが一般的見解なのだ。
確かにTXTとか書くとまるで号泣しているようじゃないか。
ちなみにWindowsは大文字小文字を区別しないので
TxTと書けばさらに泣き顔に。
※全部大文字だと〜 と拡張子とは全く関係ありません。
今日の日記は全部ネタです。
日記の文章もそのせいで壊れかかっている状態ですみません。
無理矢理関連付けようとしても無駄だった。
関連付けと言えば拡張子なわけだが(?)これは
人によっていろいろ拘りがある。
htmとかjpgとか本来4文字の拡張子を3文字に縮めるのは嫌だとか
(昔は拡張子は3文字と決まっていてその名残らしい)
大文字じゃないとだめだとかその逆とか…
私は文字数はどうでもいいけど拡張子は小文字がいいと思う。
メールなんかでも全部大文字だとなんか叫んでいるように見える
というので避けた方がいいというのが一般的見解なのだ。
確かにTXTとか書くとまるで号泣しているようじゃないか。
ちなみにWindowsは大文字小文字を区別しないので
TxTと書けばさらに泣き顔に。
※全部大文字だと〜 と拡張子とは全く関係ありません。
今日の日記は全部ネタです。
一つのRPGを創り上げるのに必要な時間はどのくらいだろうか。
例えば一日平均4時間を制作に費やし制作期間が半年の場合は
180×4で720時間である。
多分、上記の場合は中編かちょっと短い長編くらいのものが
完成するだろう。本格的な長編の場合は1000時間を超える。
短編の場合はせいぜい200時間くらいだろうか。
(言うまでもなくこれらは素材やシステムの自作の度合いなど
によって大きく変わるのだが)
これらが長いか短いかはやっぱりひとそれぞれだろう。
例えば一日平均4時間を制作に費やし制作期間が半年の場合は
180×4で720時間である。
多分、上記の場合は中編かちょっと短い長編くらいのものが
完成するだろう。本格的な長編の場合は1000時間を超える。
短編の場合はせいぜい200時間くらいだろうか。
(言うまでもなくこれらは素材やシステムの自作の度合いなど
によって大きく変わるのだが)
これらが長いか短いかはやっぱりひとそれぞれだろう。
そういえばシェアにもう一つ種類があった。ゲームの場合である。
送金しないと途中までしか進めませんよ、と。
もしシェアのゲームが
プレイ時間が10時間を過ぎるとロードできなくなります。とか
試用版では魔法が使えません。とか…
試用版クリアを目指す猛者が現れそうだ。
それにしてもシェアでゲームを購入した事のあるひとって
どのくらいいるんだろう…
送金しないと途中までしか進めませんよ、と。
もしシェアのゲームが
プレイ時間が10時間を過ぎるとロードできなくなります。とか
試用版では魔法が使えません。とか…
試用版クリアを目指す猛者が現れそうだ。
それにしてもシェアでゲームを購入した事のあるひとって
どのくらいいるんだろう…
シェアウェアのツールには2種類ある。
機能制限のあるものと期間制限のあるものだ。(両方の場合もあるけど)
私は機能制限のあるもののほうが
利用者側の立場からすればありがたいと思う。
ある人が言うことには機能制限の場合、
購入後に追加された機能が予想と違っていたと後悔することが
多いから試用期間を設けたほうがよいのだそうだ。
しかしシェアウェアは基本的に多機能である。
試用期間(1ヶ月が一般的だろうか)中ではその全ての
機能を使い切るのは困難だ。
利用者だって試用期間中ずっとそのツールのことだけを考えて
いるわけにもいかない。他にする事だってある。
すると満足に使えないまま期限が来てしまい仕方ないからといって
購入したあとにこんなはずじゃ… ということになりかねない。
事実、そういった真理を利用した完全なインチキシェアを販売して
いた人がいた。(もうずっと前の話だが)
反面、機能制限の場合はゆっくり試用できる。
暇な時に試してじっくりと考えればいい。
そのぶんだけ機能制限は製作者側にとって都合が悪い部分もあるため
難しいのだが。
>>黒吉さん
とりあえずこちらの方で呼ばせていただくことにしました。
次回更新時にリンクもはらせて頂きます。
ということでこれからも宜しくお願いします。
>>ランダムジャンプ
ちっともツクラーの日記に辿り着かない。
それとも私が気付かずに素通りしているだけだろうか…
機能制限のあるものと期間制限のあるものだ。(両方の場合もあるけど)
私は機能制限のあるもののほうが
利用者側の立場からすればありがたいと思う。
ある人が言うことには機能制限の場合、
購入後に追加された機能が予想と違っていたと後悔することが
多いから試用期間を設けたほうがよいのだそうだ。
しかしシェアウェアは基本的に多機能である。
試用期間(1ヶ月が一般的だろうか)中ではその全ての
機能を使い切るのは困難だ。
利用者だって試用期間中ずっとそのツールのことだけを考えて
いるわけにもいかない。他にする事だってある。
すると満足に使えないまま期限が来てしまい仕方ないからといって
購入したあとにこんなはずじゃ… ということになりかねない。
事実、そういった真理を利用した完全なインチキシェアを販売して
いた人がいた。(もうずっと前の話だが)
反面、機能制限の場合はゆっくり試用できる。
暇な時に試してじっくりと考えればいい。
そのぶんだけ機能制限は製作者側にとって都合が悪い部分もあるため
難しいのだが。
>>黒吉さん
とりあえずこちらの方で呼ばせていただくことにしました。
次回更新時にリンクもはらせて頂きます。
ということでこれからも宜しくお願いします。
>>ランダムジャンプ
ちっともツクラーの日記に辿り着かない。
それとも私が気付かずに素通りしているだけだろうか…