”面白い”と”楽しい”を定義してみました。(あくまで私とその周辺での話)
面白い:見たり、読んだりなど外側から。
楽しい:遊んだり、参加したりなど内側から。
例えば、アニメ、スポーツ観戦や祭りを見てるときは「面白い」を使う。
ゲームを遊んだりスポーツをしたり祭りをやる側の場合は「楽しい」を使う。
ユーザーさんがゲームを買う前は、「面白そう」かどうかで判断し、ゲームをプレイした後は「楽しい」かどうかが重要。
チームでゲームを作るとき(個人で企画を考えるときも)、上記の「面白い」と「楽しい」は使い分けると意図を明確にしやすくなると思います。
(ツイッターでゲームの面白さについて意見交換できたので、思考を深めつつメモ)
一般的に「面白い」というと幅が広すぎるので、
ゲームを(それ以外でも)作るうえではもっと細かく言葉(概念)を分けておくほうが都合が良いです。
「面白い」は、大きく「楽しい」、「面白い」、「好き」の3つに分けられます。
「楽しい」... 直感的、本能的な感覚。操作感や視覚効果、音や声による外的な刺激。
「面白い」... 思考的、理性的な感覚。選択肢で悩んだり、未来を踏まえての戦略的な思考。
「好き」... 個人の趣向的な感覚。本能+記憶から来る内的な刺激。
それぞれ重要ですが、ゲームによってこれの優先順位が違ってますね。
また、遊び手側も個々に優先順位を持っています。
例えば、千葉にある某有名テーマパークを楽しめる人とそうでない人の違いは、
前者は「楽しい&好き」を得られている人、後者は「面白い」が無く「好き」でもない為。
という言い方ができますね。
Processingでゼロワンのイメージアニメーションを作ってみました^^
タイトルは、「ゼロワン(時空転移エンジンⅡの改良版)」です。
動画: https://twitter.com/StudioGIW2/status/1167936841808412672
ソースコードはこちら。
void setup(){
size(508,340); noStroke();
textAlign(CENTER,CENTER);
}
float p,x,r=508,n=170;
void draw(){
fill(0,5,9,15); rect(0,0,r,r);
translate(r/2, n);
fill(250,20,0); textSize(70); text("01",0,-8);
fill(230+p%20,250,0);
p=(p+.4)%n;
for(x=0;x<n;x++){
rotate(sin(p)); ellipse(p,sin(p)*r,1,p*.3);
rotate(cos(p)); ellipse(p,cos(p)*r,50,p*4%2);
}
fill(250,20,0); textSize(16); text("01",90,0);
}
====================
最近、1ツイート内でプログラムを書いて、その動画等をアップしてます^^
アート+太鼓の達人ネタ+学習サンプル用な感じでしょうか。
プログラムは自由にコピー&編集して頂いて大丈夫です。
尚、どんちゃんの絵を描画するKao関数は、ナムオリの「void setup」の歌詞からそのまま持ってくる必要があります。
(制作順)
無題
https://twitter.com/StudioGIW2/status/1165177283058921472
機械思考
https://twitter.com/StudioGIW2/status/1165222768213815296
ドンちゃん
https://twitter.com/StudioGIW2/status/1165200331698921472
多元時間
https://twitter.com/StudioGIW2/status/1165442587211091968
時空転移エンジン
https://twitter.com/StudioGIW2/status/1165967522782302208
時空転移エンジンⅡ-時空の瞳-
https://twitter.com/StudioGIW2/status/1166470828805873664
無限太鼓
https://twitter.com/StudioGIW2/status/1166485836507959297
非公認キャラ「れんちゃん」
https://twitter.com/StudioGIW2/status/1166843648396279809
劇場版どんちゃんズ
https://twitter.com/StudioGIW2/status/1167226878630907905
螺旋宇宙崩壊
https://twitter.com/StudioGIW2/status/1167600504307736576
画面の色を表すのに、ハイカラーというモードがあります。
通常、パソコンでRGBを表現するには24Bit必要ですが、ハイカラーは16Bitで表現します。
24Bitの場合は、R(レッド)が0-255の8Bit、G(グリーン)とB(ブルー)も同じ。
16Bitハイカラーの場合は複数の種類があって、メジャーなのは、555と565のモードです。
555モードは、RGBそれぞれを5Bit(0-31)で表現します。
2進数の並びは、最初の1Bitは未使用で、"0RRRRRGGGGGBBBBB" です。
565モードの場合は、Gだけ6Bit(0-63)で、"RRRRRGGGGGGBBBBB"となっています。
※他には、5551モード等があります。
あと、昔のゲームは、8Bit(256色)で色を表現していました。
更に前(MS-DOSの頃)だと、4Bit(16色)ですね。
256色以下の場合はパレットという色データが別にあって、そのパレット番号を8Bit(0-255)で指定して画面に色を出していた感じです。
ざっくりした説明なのでよくわからないと思いますが、画面に色を表示する方法はいろいろありますよということで^^
<前巻までのあらすじ> ※前回はこちら
エルフに転生して魔王と戦った二人は、更なる異世界へと飛ばされた。
浴室や寝室でのラノベ的展開をこなした後、
遂に、深淵の謎、アカシックレコードに挑むのだが、その前にやるべきことを思い出す。
「そうだ、まだ”未来のプログラミング技法”というのを教えてもらってなかった!」と。
<第十七章・星系プログラミング入門>
令和元年のこの世界では、システムが外側にあると考えるのが一般的じゃ。
しかし、ワシの星系プログラミングではシステムが内側にある。
――ここでいうシステムとは、OSのことじゃ。例えるなら世界の理(ことわり)。ワールドシステムじゃ。
星系プログラミングでは、このワールドシステムを内側に持つ。
面倒なので具体的にいうと――、WorldSystem() という関数を作り、その中でOS関連の全ての処理を行う。
これを使えば、純粋なワールドループ処理が可能となる――のだが、その前に少しだけ平成時代に一般的だったシステムを解説してやろう。
――平成時代は、ワールドシステムが外側にある。その為、関数内で無限ループを作ることはできない、ああ――スレッド処理は除くぞ。
その結果、1つの関数には1工程分の処理しか書けず、それらの関数を自前のタスクで管理するという複雑な工程が必要になっておったのじゃ。
――さて、星系プログラミングでは全体の仕組みをシンプルにすることで、CPUやメモリへの負荷を減らし、作りやすさや視認性を向上させることができる。
作りやすくて視認性が高いということは、バグが発生し難く、バグが出ても直しやすいということじゃな。
星系プログラミングとは、星系を作るようにプログラムを組み立てることから名付けられた。決してカッコ良いからとかそういうことではない――ぞ?
オホン。
星系を作るには、星が必要じゃ。この星1つが1つの関数。それぞれがWorldSystem()を内包しておる。
この星のことを「Star関数」と呼ぶ。
Star関数から別のStar関数を実行し、星系を構築する。以上じゃ。
これだけで、どんなジャンルのゲームでも作ることができる。
書いてるプログラマはシングルタスクやスクリプトを書くような感覚で、マルチタスクのプログラムを組むことができるというわけじゃ。
具体的な例を書くと――。
「……しょう、…師匠! 大変です! 奴らの! 奴らの艦隊が後ろに!」
「…………」
「師匠!」
――っ! 覚醒したワシは、こやつの顔の近くの壁に「ドンッ!」と右手を叩きつけながら言った――。
「聞こえておる。想定内じゃ。 ――では、行こうかの」
星魂歴584年。
アカシックレコードとの最後の戦が始まる。
END.
<あとがき>
(星系プログラムの例↓ エラーチェックなどは省いてます)
// オプション&オープニング&タイトルを表示
void GameStart()
{
// オプション画面を実行
StarSettingWindow();
// OPをスクロール表示
StarOpening();
// タイトル画面表示
StarTitleFadeIn();
// クリック待ち
StarTitleClickWait();
}
// タイトル用のクリック待ち
void StarTitleClickWait()
{
while(1)
{
// 画像を描画
DrawTitle();
// その他の処理(入力系やマウス描画などの任意のワールドシステム処理)
WorldSystem();
// クリックしてたら戻る
if(in.ml) return;
}
}
※StarTitleClickWait()以外は省きますが、内部でWorldSystem()を使用してループさせています。
という感じで、普通のC言語な書き方で、どんなゲームでも作れます。
更に、C++のクラスやnamespaceを利用すれば大規模なゲームにも対応できます。
※StudioGIWのゲームは、全てこの方式(C/C++&星系プログラミング)で制作しています。
WorldSystem()関数ですが、Windowsの場合は、PeekMessage、TranslateMessage、DispatchMessageを利用して実現できます。
もっと簡単なのは、DXライブラリのProcessMessage関数ですね。
※WorldSystem()関数はゲーム毎に必要な処理を書いておく感じです。自身で考えてみてください。
尚、C言語以外でWorldSystem()関数を作れるかは不明です。(私の知る限りではありませんが、今後実装されるかも?)
<前巻までのあらすじ>
高校のゲーム研究部に所属する主人公の前に突如現れた謎の美少年、彼はなんと未来人で「30年後の未来でプロのゲーム作家をやっている」らしい。
彼は左手で自分の左目を隠しながら言った。
「ワシの名は、漆黒の紅き白龍、ラグナヴァス・ディストランド。星魂の新世界、エル・ダールを継ぐ者じゃ」と――。
最初は徹底した中二病だと感心していた主人公も、保健室でのあれこれや、
雪山で遭難した時のなんやかんやで、実は美少年ではなく”美少女”だったことが判明。
次第に彼の話を信じるようになり、「師匠」と呼ぶようになるが――。
<第六章・核となる企画はメモしない>
「ちょ、ちょっと待ってください師匠。 ”遊んでもらう人や状況をイメージする” ということは分かりました。けど、”アイデアをメモしない”というのは? メモしないと忘れちゃいますよね?」
私は師匠、と言っても16歳くらいに見える自称316歳の美少年――実は美少女だったのだがそれは二人だけの秘密――から目線を外しながら、そう訊ねた。
師匠はどこか遠く、ここではない場所を見ながら答える。
「忘れる企画は必要ない。忘れる、ということは大したネタではなかったということじゃ」
「なるほど…、脳の機能まで利用して企画を作るなんて――、流石です師匠!」
「うむ。それにな、書くことで”企画が確定してしまう”ではないか」
「え? 企画が、確定しては、まずいのでしょうか?」
「まずい、大いにまずい。何故ならば、それ以上の妄想発展が起こらなくなる。最初の企画、つまり核となるアイデアが完璧であれば良いが、もし仮に70点のアイデアだったとして、そこで確定してしまうと、70点の企画でゲームを作ることになってしまう」
「おお。確かに、それは大惨事ですね、流石師匠! つまり、脳内で揉んで揉んで揉みまくって100点の企画になってから企画書を書くべしと」
「そうじゃ、それこそが、”創る”に値する面白いアイデアなのじゃ。ところで貴様、今何をしておる?」
「え、師匠のお言葉をメモして――あっ! すみません師匠」
パタン。と、私は開いていたノートPCを閉じた。そして師匠の顔を見る。もちろん師匠の眼は直接見ない。
師匠の眼は”邪眼”、見た者は呪われる――という理由ではもちろんなく、武道でいう”目付け”。相手の一か所を見るのではなく全体を見る。
相手の心の動き、感情や違和感を捉え、言葉に含まれていない何かを読み取ることができる。
「うむ。貴様は愚かじゃが――、少しはましな愚者じゃな」
「あ、えと、恐縮です」
私は質問を続ける。
「それで師匠、超面白くて直ぐにでも作りたいゲーム企画ができたとして、その後は、師匠の場合、何から作り始めますか?」
「ふむ。そうじゃな、ワシの場合、その超面白い企画――、さっきも言ったがこの段階ではゲームの核となるアイデアのことじゃが、そのアイデアに名前を付ける」
「アイデアに名前を!? それは初めて聞きました、どういうことでしょう?」
「なに、誰もがやっとることじゃよ。ここで付ける名前とは即ち、ゲームのタイトルじゃ。この名付けにより、ゲームに最初の命が宿る。ゲーム誕生の瞬間じゃ」
「おおおおお、ただタイトルを考えただけなのに、何か凄いことをした気になりますね、流石師匠!」
「ふん、ただ名付けるだけではないぞ。膨らませたゲームのアイデア、つまり世界設定やゲームシステムを踏まえ、最も相応しい名前を付けねばならぬ。ここで確定させたゲームの核を元に、数か月、ゲームの規模によっては何年も同じ作品を作ることになるのじゃからな」
「とてつもなく重要な決定を、最初に行うわけですね」
「うむ、そうじゃ。そして、核が固まれば以降の決断、つまり”何を入れて何を削るか”を決めやすくなる」
「何を入れて、何を削るか……」
ここで師匠はジュースを一口飲んだ。
師匠が自分で未来から持ってきたらしいミドリムシ入りのジュースを。
因みに食用ミドリムシ入りのジュースはユーグレナと呼ばれ、現代でも既に売られている。未来ではもっとメジャーになっているらしい。
「あ、師匠、今更ですけど。核となるアイデアというのは、どのくらいのものなんでしょう。その、規模感的な意味で」
「ゲームによるが、そうじゃな、ワシの代表作を例に話してやろう」
「師匠の代表作! 未来で師匠が作ったゲームですよね、そっちも気になります、是非」
「うむ。そのゲームの名は、”ヴァジアルサーガ愚民化戦略”。愚民を洗脳して戦場へ送り込み、領土を拡大しつつ、有能な武将に子作りさせて、より良い遺伝子を持った武将を作ったりする国盗り戦略シミュレーションゲームじゃ」
「うお、なんか、ヤバそうなゲームですね師匠!」
「当然じゃ。 で、核の話じゃが、このゲームの場合、まずさっき言った愚民洗脳・子作り・国盗りSLGの部分がそうじゃ。世界設定とゲームシステムの両方が絡み合って核になっておる」
「えっと、どちらか片方だけでは核にならないということでしょうか?」
「ならないわけではない。これもゲームによるのだが、基本的に世界設定とゲームシステムは車の両輪だと考えておる。どちらか片方だけを先に作りこんでしまうと、もう片方を繋げる時に苦労するのじゃ。まさに”後からとって付けたような感じ”になってしまう」
「世界設定とゲームシステムは両輪……」
「うむ。この両輪を絡ませながら企画を練りこむことが、善いゲームの核を作る為の秘訣だとワシは考えておる」
「分かりました師匠、世界とシステムの絡みが重要、脳に刻んでおきます」
「さて。核ができ、タイトルも決まった。貴様なら次に何を作る?」
「えーと私の場合は、最初から順番に作ることが多いので、オープニングのストーリーを考えるか、タイトル画面を作ります」
「ほう。具体的にするべきことが分かっていることは良いことじゃ。何を作るかは好き好きじゃが、ワシも最初から作ることにしておる。大抵はロゴじゃな」
「ロゴ、というとタイトルロゴですね、確かにこれがないとタイトル画面が作れない」
「うむ、核を踏まえて、その世界観に合ったロゴを描きながら更にゲームのイメージを広げていく。そのロゴから更にタイトル画面が生まれる。このようにして全ての素材を核から派生させていくことでゲームの世界を構築していくわけじゃ」
「ロゴを美術部の知り合いに頼むこともあるのですが、この場合は?」
「作り手の人数が増えても同じじゃ、核を踏まえて発注し、自身はそれ以外の部分を作っていけば良い」
「おおー、師匠、なんかだいぶ分かってきました! 核を中心に世界とシステムを練りこみながら徐々に輪を拡大していく感じですね。そしてメモは取らない」
「いや、ゲームを作り始めてからはむしろ積極的にメモを残していくのじゃ」
「え!? 師匠、言ってることが矛盾してますよ?」
「黙れ小童(こわっぱ)! メモを取らぬのは核を作るまでの話じゃ。確定させてからは、気付いたこと、これから作る予定のアイデアをどんどんメモしていく。もちろん最初の核に沿ったアイデアをじゃ。そしてそれを優先度順に上から並べ替えておく」
「やるべきことをメモし、優先順位を付けて並べ替える――」
「さよう。あとは上から順番に作業を進めれば、いつかゲームは完成する」
「作っても作ってもどんどん新しいアイデアが生まれてきたら?」
「当然、どんどんメモを追加し、どんどん作っていく。むしろそれが自然な流れじゃ。最初は数行から始まり、ゲームが完成する頃には”OK”や”完了”の印を付けたメモが下側に数百、又は数千行積まれた状態になる」
「作り終わったアイデアも下に残しておくんですね」
「ワシの場合はな。ああ、それと、作る前に”本当にこのアイデアは必要か”ということを核を踏まえて検証する必要はあるぞ。――それに、重要なアイデアはやはり直ぐに書くのではなく、脳内で揉んでから出力した方が良い」
ここで師匠はまたミドリムシのジュースを飲んだ。
それをじっと見ていたら、師匠がそのジュースを私に差し出してきた。
「ほれ。そんなに気になるなら味見してみるか?」
「あ、はい、では少しだけ――」
ゴキュ。……うーん、特にミドリムシっぽい味はしない。ミドリムシがどんな味なのかは知らないけど。
「普通のフルーツジュースみたいですね」
「うむ、ミドリムシは味付け次第じゃ。ゲームも同じ。元のアイデアにどんな味を付けていくかで、ゲームは様々な味に変化する」
「師匠、上手いこと言った気になってますね?」
「ば、ばかもの。事実を言ったまでだ」
と言いつつも照れてるように見える師匠。ちょっとかわいい。
「さて、このまま味付けをしていけば、いつかはゲームが完成する。が、実は核や味付けよりももっと重要なことがある」
「核や味付けよりも重要なこと、ですか? うーん、他にやるべきことは――、あ、バランス調整?」
「ほほう。愚民の分際でよくわかったな。誉めてやろう」
「はっ! ありがたき幸せ! で、師匠、バランス調整ってゲームの企画よりも重要なんでしょうか?」
「超重要じゃ。如何に素晴らしい企画でもバランスが最悪ならそれはクソゲーじゃ。逆にクソな企画であってもバランスが神なら、それは面白いゲームとなる」
「なるほど、です」
「まあ当然、核が優れているに越したことはないがな。ミドリムシ自体が旨ければ、味付けもバランス調整も楽になる」
「世界設定とシステムを合わせてよく揉んだ核と、それを活かす為の味付け。そしてそれらのバランス調整、ですね。 わかりました師匠! 今日もご教授ありがとうございます!」
「うむ、まあワシにもメリットはあるでな」
「え? 何か仰いました?」
「いや、何でもない。次は”未来のプログラミング技法”について教えてやろう」
この時の師匠の笑みが何を意味するのか、今の私には知る由もなかった――
To be continued...(第七章へ続く) ※続きはこちら
最も優れた関数は、存在しない関数。
つまり、「呼び出す必要が無い」ということ。
例えば、生成後に必ず解放関数を呼ばせるような仕様は不可。
update系関数も、可能なら大元の関数一つにまとめる等。
ライブラリを使う側の工数を最小にすること。