2012年4月10日火曜日

平日不調

本業がそろそろ忙しい時期を脱したと思ったら、まだまだ色々と忙しい。
随分前から、「今がピークだ」と自分に言い聞かせながら仕事をしていますが。
しかし、中々ピークが終わらない。
恐らく、去年の6月ぐらいからピークが続いているので、そろそろ一年か。。。

ゲーム作りの方は、ゲーム根幹部分のシステムを調整中。

「タッチ専用」&「ソフトボタン無し」というスペックでシューティングを作ろうとすると、どうしてもボムを入れることができません。ただ、実は、個人的にシューティングにボムとパワーアップが本当に必要なのか、甚だ疑問です。パワーアップについては保留中ですが、少なくともボムは入れません。

ただ、回避処置が何も無いのもつまらないので、非タッチ状態を有効に活用して回避処置を設けています。
ちなみに、Android用のシューティングゲームはショットがオートなものばかりですが、私が開発中のものは、ショットはタッチ中のみオートで、非タッチ中はショットを打たない仕様になります。
常にフルオートでショットを出すのは、どうも間が抜けてる気がするので。


その非タッチ状態を活用した回避処置のことをAtomicLaserと呼んでいます。
そのAtomicLaserをどのようにスコア稼ぎ要素にするか・・・といった辺りを創意工夫中。

2012年4月8日日曜日

なかなか快調

なかなか快調です。
GWにテストバージョン(1面のみ&無料)をAndroidマーケットに流すのも無理では無さそうです。
現時点の画面は↓こんな感じ。

ただ、そろそろ情報処理技術者試験が近いので、勉強した方が良いかなぁ・・・
受験区分はプロジェクトマネージャで、実質2回目の受験。
2回目だから勉強しなくても良いか、2回目だからこそ勉強すべきか。

迷いどころです。
1回目なら迷わず勉強するしかありませんが。

去年、味見で受験した実績では、勉強をしなくても論文以外は何とかなった(論文がB評価で不合格だった)ので、論文の対策(=ネタの仕込み)だけは必要な気がしますが、そうやって高を括って受けると案外、午前や午後1で落ちそうな気がします。

ただ、焦って取る必要がある程のものではないから、開発作業を優先したいところ。
ついでに、本業であまりプロマネ的な仕事はしたくないから、下手に合格してしまうと墓穴を掘りかねない。
もちろん、受験料が勿体無いから受験はするし、受験する以上、最後まで受けますが。

受験する唯一の目的は、合格祝い金です。

同じレベル4の区分の中でも結構高いんですよね、この試験。
個人的には、スペシャリスト系(同じレベル4)の方が難しい気がします。
だけど、スペシャリスト系だと合格祝い金が大分安い。


 金、金、金! 騎士として恥ずかしくないのか!

と、言われてしまいそうですが。

2012年4月7日土曜日

敵アルゴリズム

ようやく、敵を登場させるシステムの骨組みが完成。

あと、敵の絵やらアルゴリズムもどんどん追加していくだけ。

敵のアルゴリズムは、スクリプト化する派とプログラムでいく派が居ると思いますが、私は後者。
以下のように、アルゴリズム関数を関数配列で管理して、キックする感じでやっています。
STGの場合、このやり方で作る方がスクリプトのシステムを作るよりも効率が良い気がします。

敵アルゴリズム以外の部分が、まだ、色々とできてませんが。
敵のドット絵とか。
上のキャプチャはSHOT03のドット絵の流用物なので、若干・・・というより、かなり浮いている。
(このままでは流石に使えない)


システム的な面では、爆破やら、敵弾やらがノータッチ。


とりあえず、爆破パターンのドット絵はSHOT02の頃から使っているものを流用しようとしていますが、爆破ギミックは少し凝らせたいので、結構時間が掛かりそう。個人的に、爆破はシューティングの華だと思っているのですが、割とそういう議論をあまり聞かない・・・と、思っていたら、2chに専用スレッドがあり、色々な意見が見れて面白かったです。色々と参考にしながら試行錯誤してみようと思います。

敵弾も割と重要だし厄介。
ちなみに、弾幕STGにするかは微妙です。
個人的に高速な弾を高速な自機で避けるのが好きなので。
ただ、高速な弾主体にすると、必然的に自機狙いや自機外し(つまり、真っ直ぐに飛ぶ弾)が中心になってしまうから、それは避けたい。今回はもっと多彩な弾を飛ばせるようにするつもりです。
ですが、アクション・パズルゲームにはしたくない。
アクション・パズルゲームが嫌いな訳ではないですが。(寧ろ、好きな方)

海外向けプロモーションの準備概ね完了

現時点で、Android用に有償アプリ、無償アプリを各1本を作って公開中。
ちなみに、有償アプリ(INVADER BLOCK 2)と無償アプリ(VGE Chiptune music)は全くの別物です。
有償アプリの機能制約版(Lite版?)を配り、プロモーションするやり方ではありません。
「INVADER BLOCK 2」の場合、ゲームの性質上、機能制約に向かないので。

無償アプリの方は公開から数週間で30本程度ダウンロードされました。
しかし、有償アプリは公開しただけでは全然売れません。
当然といえば当然。

独自の技術(Video Game Engine)により、Windows上で全く同じ動作をするものを作り、Windows用をVectorでフリーで配ってみたところ、少しだけ売れましたが。なので、何かしら無料版を試す機会を提供するのが必須だと思います。

ちなみに、無償アプリの方は世界各国、様々な地域でダウンロードされましたが、有償アプリの販売実績は日本のみ。現状、Vectorでしか配っていないためだと思います。という訳で、ダウンロード数を伸ばすためには海外向けのプロモーションが必須であろうということで、米国のソフトウェアダウンロードサイトに登録しました。

海外サイトに登録するのは中々厄介でした(ウェブサイトの英語化や英語ドキュメントの準備など...)が、何とかSuzukiPlanがCNETのカンパニーとして登録が承認されたようです。Windows版「INVADER BLOCK 2」を登録する手続きも済ませたので、あとは、それの審査待ち。

これで、海外向けに少しは売れるのか・・・は、未知数ですが。
ちなみに、カンパニーというのは和訳すると会社ですが、SuzukiPlanは法人ではないです。
日本の場合、(会社法上の)会社は法人でなければなりませんが。
住民税を支払えるほどの収入も無いし、そもそも法人制度の意義に当てはまらないので。

法人というのは、一種の法律テクニックとして、自然人以外のものに自然人の一部の権利能力(制限された権利能力)を与えた論理的な人を存在させるものです。その意義は、複数の人の意思を統合してひとつの意思として活動することが第一義だと私は考えています。
成人の自然人(但し、制限行為能力者を除く)には強力な権利能力が有るので、同じ事業を複数の人が同時にやろうとすると、取引の安全性が損なわれてしまう恐れがあるから、特定の目的に限って活動する別の人として法人という物理的に存在しない論理的な人を作る必要があるという訳です・・・あくまでも、私の勘ですが。
よく、法人化の目的として節税対策や損益の繰越の仕組みの違いなどが挙げられますが、これは副次的なもの(=おまけ)で、重要なのは複数の人間が経営に携わっているか否かという点です。“経営に”という部分が少し重要。つまり、従業員や(普通の)中間管理職の人は含まれません。経営に携わる人というのは、法人の意思決定について権限を持つ人のことだと思います。なので、一般的な会社であれば、株主、取締役、執行役などが合計二人以上居る場合は法人化すべきで、そうでない場合は法人化する必要は無いと思います。法人の種類によっては、人数が「x人以上」という決まりがあるものもありますが、いずれの法人も意思決定機関が必須でそれが複数(二人以上)であることが法律上の要件になっているんじゃないかと思います。あくまでも勘ですが。(私は法律の専門家ではないので)

余談が長くなりましたが、英語のカンパニーというのは、事業として営利活動をしていれば当てはまります。
自然人か法人かは不問です。つまり、個人事業主も含まれます。
個人事業主は「Sole proprietor」ですが。
カンパニーとしておけば、より広い範囲で含まれるから便利。(company limitedもcompanyの一種)

2012年4月3日火曜日

STGにおける敵情報のデータ設計

シューティングゲーム(STG)の作り方を解説しているサイトは数あれど、敵のオブジェクト情報をどのように設計するかについて言及しているサイトは割と見かけないような気がするので、軽く解説しておきます。

そんなん、単純に構造体で管理だろJK

・・・かもしれませんが、この部分のデータ設計を予め如何に適切におこなっておくかで、ゲームの表現の幅が大分変わります。私はそのことを、SHOT01~SHOT03(3作品)の開発での失敗を経て実感しています。

まずは、実際に設計中のデータ(実物)を見た方がイメージが沸き易いかと思います。
なので、現在開発中のSHOT04で作成途中のデータ構造を例示します。

クラス構造としては、敵、オブジェクト、パーツの3種類。

E-Rで表記すると、

  • 敵:オブジェクト=1:n(最大8)
  • オブジェクト:パーツ=1:n(最大8)

という感じ。
つまり、1匹の敵は最大64パーツ(8^2)持てます。
数は今後、コロコロ変わっていくんでしょうけど。

実は、SHOT01の頃は単純な1個の構造体で敵を表現していました。
ただ、それだと当り判定が複数個所に分かれるような場合、処理が面倒になります。
そこで、SHOT02とSHOT03では、1つの敵を複数のオブジェクトで表現する感じにしました。
ただ、それでも処理が厄介な部分があったので、今回は、敵、オブジェクト、パーツの3層構造のスキーマを定義。(予定)

オブジェクトには、有するパーツ数+パーツ情報を定義します。
例えば、グラディウスの多節足の敵の場合、根っこの部分、胴体の部分(複数)、頭の部分みたいなパーツをグループ化したものが、ひとつのオブジェクトになります。

それなら、オブジェクトとパーツだけ(2層構造)で十分だ・・・と普通は考えます。
(だから、SHOT02とSHOT03はその形態にしました)

ただ、例えば多節足を2本持っていて、足単位でパーツ破壊できるような敵(足×2+本体)というものを作ろうとするとプログラムが複雑になってしまいます。だから、オブジェクトを更にグループ化した、クラス(Enemy)を追加・・・という訳です。これで、どんなものでも簡単な処理で表現できる筈。まだ、作ってないから確証は持てませんが。

ちなみに、クラスだとかスキーマだとか、オブジェクト指向の用語を使っていますが、プログラム言語はCのみです。私は、C++やJavaが大嫌いなんですが、オブジェクト指向の考え方自体は、重要だと思っています。(ついでに、iPod touch化するときにもに楽になる筈)

2012年4月1日日曜日

背景

背景がクロマティだと寂しいので、マップ機能を実装。

以前、GAME06という名称で作っていたアクションRPG(※開発断念)用に作ったマップエディタとマップシステムを、シューティング用にカスタマイズして作るだけだから、システム自体は一瞬で作れました。

問題は、リソース(チップセットの画像)。

私には絵心がほぼ無いので、ハムコロサマさんの素材あたりを使いたいところですが、フリーゲームで使うのならともかく、商売で作っているものに他人の著作物を使うのは(現時点の使用許諾は未確認なので、実際にダメかどうかは定かではないですが)トラブルの元なので、下手ですが、自分で描くことにしました。
地面の線路(のつもり)と、飛行機のサイズを影の大きさから計算して見てみると、明らかに寸法がおかしかったりしますが、気にしない方向で。

ちなみに、飛翔鮫みたいな感じの左右スクロールはしない方向です。
左右固定(=東方と同じ方式)。
左右スクロールのプログラム自体、簡単に作れるのですが、マップを作るのが(広い分)面倒だし、ゲームバランスの調整も面倒になるので、左右は固定です。
要するに手を抜きます。

GW中には、ステージ1のみのトライアル版(無償)をマーケットに流したいから、開発効率優先で。

上下移動(実装)

上下移動を実装してみました。
かなり良い感じです。

少なくとも、Android市場に出回っている作品の中では、随一の操作性で、尚且つ全盛期(90年代)のシューティングゲームを求めるコアなシューターが満足できる水準のモノを仕上げることが出来ると思います。(たぶん)
問題は、コアなシューターがAndroidユーザーの中に居るかどうかですが。
たぶん、そんなに居ないんじゃないかと思っています。
満足のいく水準に達している作品が想像以上に少なかったので。
ただ、潜在的にはかなり居ると思っていますが。
というのも、Androidはデフォルトが縦画面(=シューティング専用)なので。

とりあえず、この作品の1面が出来た段階のβ版(トライアル版)を無償で市場に流してみて、様子見をしてみるつもりです。そして、売れそうな感触だったら本気で作り、そうでなかったら、このゲーム(SHOT04)の開発はヤメにして、別路線を探るつもり。

ニーズが無くとも、完成させる可能性も大ですが。

合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...