ゲーム制作(続き)

2006/10/28

Vectorのレビューが付いているやつをチラチラとみてみると、どうやら見てくれが派手なもののが選択されているような印象を受ける。あるいは、単に俺が今作っているやつと比較すると派手に見えると言うだけのことなのかも知れない。

いずれにせよ、今の段階で外に出したら、他に埋没して無名の糞ゲームで終わってしまう。これでは本来の目的であるところの、webサイトのアクセス数向上に結びつかなくなってしまう。

アクセス数を増やすためには、何が何でも目立たなくてはいけない。ゲーム的なおもしろさは問題ではない。とにかく目立つことだ。そしてその為には、エフェクトが派手である方が良いらしい。

意味なんて無くたっても良い。とにかく派手でありさえすればそれでいいのだ。

だが、グラデーションの効いた派手なエフェクトというのはどうやったらいいのだろうか? そもそも、俺が使っているPCは性能が低いため、余り手の込んだ難しいことはできない。動きがガクガクになってゲームどころではなくなってしまう。

そう考えると、だんだん面倒になってきた。主筆の開発もいつまでも止めておきたくないし。

なんか、手っ取り早く派手にするための、良い方法はないものだろうか?

ゲーム制作の続き

2006/10/22

先週に引き続いて、クソゲームを作り続けている。とりあえず、今のところはまだ飽きていない。



画面を見る限りでは、先週の時点からそう大きく変わったようには見えない。しかし、敵を表示する機能、穴に落ちたときや敵に触れたときにゲームオーバーになる機能を実装しておいた。また、画面の向きを変える機能も付けておいた。

初めは向きを自由自在に変えられるようにする予定だった。だが、そうすると操作がもの凄く難しくなってしまい、ほとんどゲームとして成立しなくなってしまうから、途中でこの機能は切り落とすことにした。
しかし、それではやはり面白くないと言うことで、少し方式を変えて実装することにしておいた。

後はとりあえず、弾を撃ち敵を倒す機能、敵が弾を撃ち攻撃してくる機能、ゴールしてゲームを終了する機能を実装する必要がある。

まぁ、余りこれには労力をかけるつもりはないから、適当にやって早いうちに片付けてしまおう。

浮気

2006/10/15

ちまたの噂によれば、ゲームを作って公開すればアクセス数を稼ぐことができるらしい。やはり、絶対的なユーザー数の差がものを言うのだろう。

あるいは、客層の違いだろうか。確かにアクセス解析を見ていると、アクセス元の多くが各種のコンピュータ関連企業であることが解る。

つまり、そういったユーザは仕事中にアクセスしてきているのであり、余分なページを見て回ったり、広告をクリックしたりする事は少ないのだろう。

そういうことで、アクセス数増加と客層の変化を付けるために、少しばかりゲームでも作って公開してみることにした。それに、アクセス数の増加だけでなく、頭の悪い連中に「ゲームの一つも作れないのか」と罵られるのがしゃくに障るから、それを封じるためにもここで一発かましておいた方が良いかと思って、作ってみることにした。

作る目的が上記のような理由であるため、それ程凝るつもりもない。とりあえず見た目が派手で、ゲームの形式が整っていれば、それでいい。

だから、何となく簡単に作れそうなシューティングゲームにしておくことにした。ついでに、2Dだと見てくれが悪いから3Dにしておくことにした。

それで、適当に先週の日曜当たりから作業を進めて、今は画面中をプレイヤが移動できるというところまではできた。




上の画面からでは解らないが、一人称視点である。プレイヤは画面中をぴょんぴょんと跳びはねながら移動する。

後は、ゲームオーバー・ゴールの処理と、敵や弾などを作り込んでやればいい。そうすればとりあえず形だけは整うから、Vectorか何かに登録することができるようになるだろう。

カーソルの挙動

2006/10/08

主筆」のカーソルの挙動を変更してみた。

今までの状態でも、大体その他のエディタと同じ様な動きをするように作ってはあったのだが、一部業界標準とは異なる動きをする部分があったからそれを修正しておいた。

具体的な内容は下記の通り。


  1. 一番末尾の行で下矢印キーを押下した場合に、カーソルをテキストの末尾に移動するようにした

  2. テキストの先頭行で上矢印キーを押下した場合に、カーソルをテキストの先頭に移動するようにした

  3. 矢印キーが押下されたがカーソルが移動できない場合(たとえば、テキストの先頭で上や左矢印が押下された場合)で、かつ、範囲選択されており、かつ、矢印キーが押下されたときにShiftが押下されていなかった場合には、範囲選択を解除するようにした



非常に細かいところではあるが、使っていて気になったので修正した。

また、第16版から、カーソル位置を記憶する機能を実装したが、その機能を停止する機能も付けておいた。まぁ、一般的にこの機能を停止するという需要があるとも思えないが、ありとあらゆる機能は停止することができるようにするべきである、というのは俺の信念でもあるので、とりあえず実装しておいた。さしたる手間がかかることでもないし。

主筆のHTML対応

2006/10/07

水曜日は仕事が速く終わったから、「主筆」をいじってHTMLの構文強調表示に対応しておいた。

ところで、こうやって単なる事実を書き連ねてもあまり面白みがないから、中でどうやっているのかを書いてみるのもいいかもしれない。

まずは、HTMLのソースが与えられた場合に、各文字の色をどうやって決定するかについて考えてみる。

まず大前提として、テキストは先頭から順番に処理していかなければならない。当然のことのように思えるかもしれないが、これは単に当然と言うだけではない。文法の制約上必ず必要なことなのである。

HTMLに限らず、テキストのとある一部分だけを見て、それが文字列(ダブルクォーテーションなどにより囲まれた文字列)の一部なのか、キーワードの一部なのか、それ以外の文字なのか、を判断することはできない。判断するためには、その前後の文字も参照する必要がある。また、指定された文字がダブルクォーテーションにより囲まれた文字列なのか、HTMLの場合であればタグの中なのか外なのかを判断するためには、その前の文字がどのようになっているのかを知ることが重要である。たとえばHTMLであれば、指定された文字の前に<があれば、そこはタグの中であるといえるが、そうでない場合はタグの外と言うことになる。

よって、テキストは必ず先頭から順番に読み込んで処理していかなければならない。

話を戻すが、最初にHTMLのソースが与えられたときの色決定処理だが、大まかに書けば下記のようになる。

  1. <が出現するまではタグの外であるため、全部黒にする。

  2. <が出現して、次に>が出現するまでは、タグの中であるため全部青くする。

  3. ただし、<!--が出現した場合はコメントであるため、-->が出現するまでを全部緑にする。

  4. タグの中でダブルクォーテーションもしくはシングルクォーテーションが出現した場合は、そこから対応する記号が出現するまでを文字列として、暗い赤にする。

  5. タグのなかにある単語(非英数字で区切られる)が、キーワードとして登録された単語であれば、それを赤くする。



ここまでは特に難しいことはない。だが問題は、テキストの一部が変更された場合にどうすればいいか、ということだ。

たとえば、テキスト中に下記のような記述があったものとする。

あいうえお<!-かきくけこ

上記のルールに従えば、「かきくけこ」の部分はタグ内の文字列であるものとして、青く描画されることになる。だが、もしユーザが「か」の前に「-」を入力したらどうなるだろうか。

その場合、「かきくけこ」の部分はコメントとなり緑色にする必要がある。

ここで気にしなければならないのは、「-」が入力されたことでコメントの開始(<--)が形成された、ということを判断するためには、文字の入力位置よりも前の方を見てみなければ分からないと言うことだ。

つまり、テキストの変更時に構文強調表示を行うためには、文字の入力位置よりもある程度前の方に遡って、そこから色を更新しなければならないと言うことだ。

では、どれぐらい前に遡ればいいのだろうか。単純に考えれば、常にテキストの先頭から更新すればいいと言うことになるのだが、それはあまりにも非効率というものである。

だから俺は、下記のようなルールで更新開始位置を決定することにした。(なお、「編集開始位置」というのは、テキストが変更された範囲の開始位置のことを言う。「編集終了位置」は同様に、テキストが変更された位置の終端のことをいう。)


  1. 編集開始位置の直前の文字がタグ外の文字列であれば、一文字だけ遡る。

  2. 編集開始位置の直前の文字がタグ内の文字列ないしキーワードであれば、英数字以外の文字もしくはタグ外の文字まで遡る。

  3. 編集開始位置の直前の文字がコメント開始記号であれば、コメント開始記号以外の文字まで遡る。

  4. 編集開始位置の直前の文字がコメント終端記号であれば、コメント終端記号以外の文字まで遡る。

  5. 編集開始位置の直前の文字がコメントないし文字列であれば、一文字だけ遡る。



HTMLの場合は、エスケープシーケンスにより文字列中にダブルクォーテーションやシングルクォーテーションを含めると言うことができないため、文字列に対する扱いが単純になる。もしこれがCやC++であれば、文字列中の文字が変更された場合の処理はもっと複雑になる(たとえば、「\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"」の末尾にある「"」は文字列の終端を示すダブルクォーテーションなのだろうか、それともエスケープされた文字なのだろうか)。

いずれにせよ、上記のようなルールにより更新開始位置を決定することで、更新範囲を最小限にとどめることができる。

そして次は、更新をどこまで実施すればいいのかを考える必要がある。先と同様、単純に考えればテキストの末尾まで更新してしまえばいいのだが、それはあまりにも非効率である。

だからおれは、色の更新を下記の条件が成立するところまで、と決めた。


  1. 編集終了位置を越えていること。

  2. 更新前後で文字の色(文字の種類)が変わらないこと。



これにより、色の更新を必要最小限の範囲にとどめることができるはずである。

まぁ、簡単に書けば上記のようなアルゴリズムで構文強調表示をおこなってはいるのだが、実際にはもっと生々しい問題がたくさんある。正確なところはソースコードを参照して欲しい。

HTML対応

2006/10/02

引数の半角空白を含む値を指定することができない問題は、結局、起動用スクリプト内で「主筆クライアント」を起動するコマンドに「"$@"」と指定してやればいいことが判った。

全く、何だってこんな意味不明な記号を駆使するのか。「$@」という記号からは、与えられた引数を全て展開するという機能を全く予測することができないではないか。こういった、恣意的な記号の割り付けや、マジックナンバーを駆使するような仕様は、ユーザビリティという観点からすれば最悪といわざるを得ない。

だがまぁ、shはユーザビリティがどうのといわれる以前から存在するものだし、今更文句いっても始まらないのだが。

また、上記以外に、ファイル名に半角空白が含まれていると正常に保存・読み込みを行うことができない問題にも対処しておいた。結局原因は、エンコード変換用のプログラムを起動する際にsystem関数を使っていたことだった。「主筆」では、子プロセス起動用の「CProcStart」というクラスを作り込んである。。それを使えば、引数中の半角空白だのなんだのを気にすることなくプロセスを起動することができる。なのに、何で初めからそれを使わないのか。我ながら、頭が悪いといわざるを得ない。とりあえず、修正だけはしておいた。

そして、今現在は構文強調表示機能を拡張してHTMLに対応できるようにしている。いろいろあって、HTMLのソースに対する色づけを行うプログラムは作ってあったから、それを転用すれば簡単にできるかと思ったのだが、そうでもないようだ。HTMLモードにして文字を入力すると、その瞬間にプロセスが落ちる。

まぁ、簡単には行くまいとは思っていたことだし、まぁいいか。ゆっくりデバッグするまでのことだ。