制作物一覧

  • 萃香と百鬼兵
  • スペルカード戦記
  • ぷちらいすけーき
  • ザ・グレイトアリス<br>~戦え!ゴリアテロボ!~
  • はしれーせん!! 3D
  • はしれーせん!!

これからのイベント

C88サークルカット

終了イベント

連絡先

E-Mail:info[アット]ricecake.st

Web拍手はこちらへ

アーカイブ

記事カテゴリー

イベントリンク

コミックマーケット
東方崇敬祭
月の宴 例大祭

同人ショップリンク

メロンブックスドットコム
とらのあな
あきばお~こく
D-Stage

第四回全ゲ連交流会まとめ

おはようございますこんにちはこんばんは。お餅です。
2009年12月5日、第四回全ゲ連交流会が開かれました。
今回は第一周年記念ということで、社会人からゲストを招いて講演会を行いました。

目次
第一部 講演会
1.30分で完成させるゲーム製作 D.K(あるふぁ~秘密基地)
2.たのしいゲーム画面 ~(プレイヤーが)よくわかるUIデザイン~ おめが(OMEGA)
3.Androidケータイでゲームを作ってみよう! 藤枝 崇史(GAPCOM)
4.仮想テクスチャ 導入 ~このテクスチャをどう思う?すごく…大きいです~ q@nonoil(Non oiL)
第二部 パネルディスカッション

1,2の講演は、特別ゲストの講演で、ゲームのデザインに関する講演でした。
3,4は学生による講演で、技術系の講演でした。

第一部 講演会

1.30分で完成させるゲーム製作 D.K(あるふぁ~秘密基地)
ゲームに入れるべき要素がわからない→「なんか面白くない」
必要な要素を理解しておけば方向を見失わない

迷わないようにする→明確な基準を持つ、ゲームの構成要素を知っておく

例として、えぐぜりにゃ~(おめがさん作)をアレンジしてみる

○やることを明確に:目的
 道具がある→使い方は?
 ゲームルール、操作方法
 RPGやアドベンチャー→どういう結果を目指すのか、という目的地や方向性を伝える
  →これらの情報でプレイを誘導
○やったことをほめる:評価、演出
 いいことをした場合は派手にする→プレイが正しいと伝える
 スコア→プレイの評価
 ストーリーの進行→行動に対し、場面が展開していく:評価になる
 プレイに反応を返す
○やってみたいと思わせる(動機)
 プレイすると評価が行われる、という期待値から生まれる
 15~30秒で変化が起こると先に進む
 複数のリズムを重ねると非常に有効
 ・別のキャラクター、ギミックが登場、雑魚的、アイテム、中ボスの出現の時間
 ・背景などの絵の変化が起きる。中間ポイントを取ったときや、ステージクリアしたとき
 ・戦闘シーンになるなどの場面の変化
○要約
 プレイヤーの心理
 目的を見つける→評価、演出で喜ぶ→次の目的への動機を探す→目的へ戻る

○要素を入れてみよう(えぐぜりにゃ~のアレンジ)
 チュートリアルの作成:ゲーム中に入れる
 敵弾排除をやめ、単純に爆発の数→スコアとした
 敵を倒したときに爆発→連爆を起こそう!というコンセプト
 →10連爆したら音を変える、連爆が続くとパラメータ部分が光ったりする(なんだかすごい!と思わせる)、大爆発が起きたらブラー演出
  →変化を与える。やってみたいと思わせる。ボーナスの表示をする
 ナスやたこ焼きは、15秒単位で出現
 ボスの出現:30秒間隔
 約60秒でレベルアップ演出をする→敵が多くなり、演出が派手になる
○まとめ
 要素を意識して作ると、ゲームの質が大幅に変わる
 規模の大小にかかわらず、面白さを伝えることは難しくない
 作る面白さの次にある、遊んでもらう面白さを味わおう

2.たのしいゲーム画面 ~(プレイヤーが)よくわかるUIデザイン~ おめが(OMEGA)
STGにおける画面設計(ほかのジャンルにも応用可能)
○かっこいいもの×かっこいいもの
 組み合わせによっては残念…

○画面の役割
 ゲームプログラム⇔プレイヤー
 画面(Output)がぼやけると、入力だけの一方向コミュニケーション
 「削る」「優先順位」
○プレイヤーが最初にしたいこと・したくないこと
 STGなる:ミスしたくない
 自機、敵、敵弾>>>>>>>>その他
○目立たせる
 明るく、鮮やか、点滅、コントラストを下げる。。。
○見せない・埋もれさせる
 暗く、彩度を下げる、。。。
 ざっくり言うと、背景を暗くする
 輪郭をはっきり
 当たり判定が絵より小さい→中心がわかりやすいデザイン
 具体例で→背景暗く、自機に蛍光色のオーラ、ディティールを消した、・・・

これだけでも、結構いい見た目になる。
 
3.Androidケータイでゲームを作ってみよう! 藤枝 崇史(GAPCOM)
○スマートフォンって何?
 iPhonのようなケータイ
○Androidってなに?
 Googleが無償で提供している携帯用OS
 AndroidOSを搭載したAndroidケータイがたくさん出回っている
○開発利点
 Javaで開発できる
 DalvikVMで動作
 比較的系家インの浅いプログラマでも比較的容易にできる
 一方…iPhone
  Objective-C:初心者には難しい
  (Objective-Cは)文法キモイ…
 Windows、Mac、Linuxで開発できる
 すぐに開発可能。SDKを入れる→Eclipseを入れる これでOK
  実機でも、USBつなげるだけでOK
 iPhoneの場合
  iPhone Developer Programに登録、SDKをインストール、Mac上で証明書作成、IDPに登録→IDPから証明書をダウンロード、システムへ登録→開発に使用するiPhone,iPodTouchなどをIDPに登録→…
 Market登録料が安い
  Android:初回登録料25ドル(初回のみ)
  iPhone:毎年99ドル

○ゲームの開発の仕方
大体.NETっぽい。ソースコードによる実装例が大半なので、メモを取っていない部分が多々あります。
後日、資料としてWeb上に公開されるようなので、興味がある人はそちらを見ていただいたほうが詳しいことが書いてあると思います。

・アクティビティを作る
 Activityクラスを継承した各クラスを作り、実装
  –ソースによるexample
 glSurfaceViewを使い、描画画面部分の処理
 FPSを制御する場合→自分でonDrawFrameに関してスリープ処理を行う
 onSurfaceChangedメソッド:ビューのサイズ変更時
 onSurfaceCreatedメソッド:ビューが作られたときに呼び出される
・タッチの検出
 onTouchEventをオーバーライド
 マルチタッチ:Android SDK 2.0でサポート
 →2.0アップデートがいつ来るかわからない
・傾き検出
 SensorEventListenerインターフェースを実装
 onSensorChangedメソッド:センサーの値が変わったとき
 重力定数:GRAVITY_EARTH、GRAVITY_MARS、GRAVITY_DEATH_START_I(デススター:スターウォーズ)。。。 など、無駄にたくさんある
 SensorManagerへ、SensorEventListenerを実装したクラスを登録
 onPauseが呼ばれたとき、いったんManagerから登録を解除
・テクスチャの読み込み
 Eclipseで、リソースフォルダにD&D→自動的に登録される
 →リソースIDが自動的に割り振られる
・画像の描画
 Canvas:簡単だが、とても重い
 Basic Vert Quads:OpenGL ESのもっともオーソドックスな利用方法
 VBO:頂点バッファを用いる。OpenGLES 1.1の機能
 Draw Texture Extension:平面であることを前提にTextureを描画する方法
 3Dなら→VBO使うべき
  glXXXXは遅いので、呼び出しを極力抑えるべき(OpenGLが遅いのではなく、ネイティブ関数の呼び出しが遅い)
・文字列の描画
 SpriteTextサンプルをパクれ!!
 文字列が描画されたテクスチャを生成する
 NumericSpriteを使えば、数字も作ってくれる。0~9に限らずとも、123とかでもできる
・音声を鳴らす
 MediaPlayerクラスを使う
 Wav,mp3は重い
 Oggを使う
・デバッグ
 「adb logcat -d」を実行
 Eclipse上でLogCatウィンドウを表示

○Androidの欠点
 ネイティブコードが実行できない
 C言語などと比べると実行速度はやはり遅い
 Googleカンファレンスで、ネイティブ対応しろよ、といわれてきた
 →NDKを利用すれば、ネイティブコードライブラリを生成し、Java側から呼び出すことは可能
  iPhoneはネイティブコード動作可:ゲーム開発ではほとんどCを使い、Objective-Cを使う部分を極力減らす
○高速化
 GCが走ると長時間とまる。場所を考える
 あまりメソッドを使わない。staticメソッドを使う
 なるべくローカル変数を
 ネイティブコードはJavaを介すので、なるべく使わない
○エミューレータがくそ
 アプリ実行までかなり時間がかかる。1,2分かかる
 iPhoneのエミュの起動は早いらしい
 実行速度も遅い:ソフトウェアレンダリング
 メモリ食いすぎ:400~500MBは食う
○AndroidMarketがくそ
 PCからの閲覧が実質不可能
 レビュー機能が貧弱
 マーケット自体が使いづらい
 販売価格が自国の通貨でのみ
 支払いはGoogle checkoutのみ
 ダウンロードがとまることが多い
○端末自体がはやってない
 日本ではHTC-03aのみ
  宣伝下手、スペック低い、値段高い
 来年はSony EricssonやSharpが出すらしい
 Android関連書籍もぜんぜん売れてない
 大学機関などでは、徐々にはやりだしてる模様

○質問
・開発にどのくらいかかる?:タッチ等の基本部分を作ってしまえば、楽
・傾向は?:ゲームはiPhoneにいく。メモ帳とか、天気ソフトとか、そういったものが今はある
・登録審査は?:9月段階では、ノー審査だった
・iPhoneに対して買ってるところは?:導入コスト、開発環境

4.仮想テクスチャ 導入 ~このテクスチャをどう思う?すごく…大きいです~ q@nonoil(Non oiL)
対象者:ちょっとだけ、未来を感じたい人。全員。
ゲームの地面、タイリング。ずっと同じものが続いているのはおかしい。

○なぜこんなことをする?(3Dのタイリング)
 VRAMの節約
 単純に作るのが楽
 →繰り返し同じものを見てもつまらない
 
 10万×10万Texelの超テクスチャ!
 hugeTexture = LoadTexture(“hugeTexture.dds”) ← だめ?
 10万Texel→メモリ64GB
 対策方法
  1.ムーアの法則に頼る
  2.分割して描画。必要な部分だけ描画
  3.ストリーミング。仮想テクスチャ(VirtualTexture,MegaTexture)
○仮想テクスチャ概要
 「よく見えているところ」を重点的にロード
 「よく見えないところは」荒いテクスチャで済ます
 実行中にテクスチャをストリーミング
 実際に作られるテクスチャは常識的なサイズ→新しい管理が必要
 →特定の領域をゲットする方法
  ゲットしたテクスチャを賢く管理する方法
  管理しているテクスチャを賢く描画する方法
○テクスチャピラミッド
 解像度が低いテクスチャから高いテクスチャへと、ピラミッド的に見る
 →部分的にロード可能
○物理ページテクスチャ
 必要な部分を並べて敷き詰めていく
 →そのまま描画しては、変に描画されてしまう
 どのくらいテクスチャをずらすか、の情報が必要
 どのくらい拡大するか、の情報が必要
○ページインデックステクスチャ( = ミップレベル + インデックス)
 ページインデックスを参照して、描画時に復元

○メリット
 バッチ回数(SetTexture,DrawIndexedPrimitive)が一回ですむ
 UVがユニークになったため、ライトマップなどを別途作る必要がなくなった
 テクスチャメモリを性格に制御できる

○問題点
 急激な視点移動による、物理ページ+ロードの遅延
 フィルタリング:ニアレストネイバーのみ。物理テクスチャ上での連続性は、実際のテクスチャでは意味を持たない
 ロック
 どうやって巨大な画像を作る?:エディタを作らないといけない
 CD-Rに入らない:とりあえずddsに。ピラミッドの特性を利用して圧縮。ハードディスク頒布すればいいんじゃね?

○質疑応答
・なぜプレゼン用のマシンでデモできなかった?:わからない
・処理のボトルネックは?:ロード、UV計算、フィルタリング(テクスチャフェッチが4倍になる)
・エディタないでしょ?:512×512を作って、境界をまたがないようにつなげれば・・・

第二部 パネルディスカッション
第一部の講演とは別に、特別ゲストとして、黄昏フロンティアのののたろうさんを迎えて行われました。
パネラー:藤枝(GAPCOM)、少佐(Neetpia)、あらいげた(新雅)、ののたろう(黄昏フロンティア)、おめが(OMEGA)、D.K(あるふぁ~秘密基地)

○議題1 ゲーム製作を始めたころの話。何からはじめたか、どんなものを作ったのか、その後どんな感じでステップアップしたか
おめが:小学校4年生ぐらいから。PC-88を親が買ってきた。
    親の知り合いに、パソコンクラブの教師がいて、その人のところに行っていた。
    中学校までBASICあさりをしていた。大学あたりからCとかDirectXとか。

D.K :中学生のときから。学校にPCが導入された。
   高校でてから働き出すまでパソコンに触れてなかった。
   主に雑誌媒体から影響を受けた。

ののたろう:家にファミコンがなかった。
      家でゲームがやりたかった。家にポケコンがあった。
      本を渡され、そのBASICプログラムをひたすら打っていた。
      中高はBASIC。大学で友人に誘われてCを始めた。

あらいげた:小学時代、VBSでエクスプローラーをたくさん起動するプログラムを作ったりしていた。
      中学校でBASIC。少林寺拳法の部活からコンピュータ部に、移り、ゲームを作る。

少佐:中学校のとき、コンピュータ部に拉致られ、ゲームを作り始めた。

藤枝:大学2年ぐらいからはじめた。
   ゲームを作りたい、という理由から。いろんな人のソースを読み、ライブラリを作ったりしていた。

○議題2 開発環境 どんなツールを使っているか、自作のエディタなどはあるか
D.K :プラットフォームの問題。大体の人はWindowsを対象にしているんじゃないだろうか。
    →フリーゲームブームも廃れてきた。規模を拡大したいと思い、マルチプラットフォームへ。
     現在は、C+SDL。D+SDL+OpenGLなんかも触れたことが。WindowsでならHSPも悪くないんじゃないか。

おめが:VisualStudioがあったりすれば、C#なども使う。
    特に何もない場合は、テキストエディタ+Dで作ったり。
    データ管理は、プレーンテキストや、ソースべた書き。
    独自形式は使わないことが多い。MS Paint使ってる。
    ツール導入、移行コストが面倒なので、あまり使わない。

ののたろう:使えそうなものは流用する。必要最小限なものだけ作る。
      (ツールのSSが移される。よくこの大量のパラメータを設定する人がいるもんだ・・・、とのこと。)

あらいげた:C#を利用している。VC# Express Edition。最近はSAIで絵を作ってる。
      案外適当にテクスチャ作っても、見えない。スクリプトはvim。

少佐:SS→エフェクトエディタ。エフェクトエディタを作っている。
   新作SS:ボーンが楽しいことに。XSIを利用している(AquaStyle)。C++とDirectX

藤枝:2Dアニメーション用のツールを作ってる。
   マップエディタも作ってる(オブジェクトの配置、当たり判定を引く、シーンの切り替えを設定)。

○議題3 開発者側が想定しているプレイヤー像、プレイヤー環境
D.K :大体中高生を想定して、キャラクタの作成等をしている。
   アニメ的なキャラクタではなく、童話的なキャラクタが受けがいいのではないか、と思っている。
   キャラクタから、世界観等を決めている。
   環境はあまり考えてない。SDLだけで作っておけば、大体どこでも動くだろう。
   ボタンも3ボタン以下にすれば、困る人はそんなにいないだろう。

おめが:キャラクタは好き勝手やっている。
    動作環境は、下のほうにあわせてやっている。
    EeePCをテスト環境に持っておくといいんじゃないだろうか。
    開発者が見落としがち:開発機にはいいグラボなどをつんでいるので、それを忘れがちになっている

ののたろう:最初はスペックをあまり気にせず作る。
      DirectX+Shader1.1で動くように作っているつもり。
      (動かないというメールがたくさん来てて、あれー?なことに)。

あらいげた:学祭に間に合うように、動くものを。中学生ぐらいをターゲット。
      開発環境はIntelオンボ。自分のところで動けば大体どこでも動くんじゃないか。
      SiSで動いてたものをほかに持っていったら、動かなかったことも。

少佐:コミケで受けそうなものを作っている。
   新作のSS:どこで動くんだろう…、というボーン数
   DX9のシェーダで、一応動作する(FPSとかは無視して)。
   DX11でのプレイ推奨。シェーダ全部切って、今の段階ならIntelオンボで60FPSでる。

藤枝:学祭向け。子供やカップルが来るので、とてもぬるくしている。
   Wiiのバランスボード+コントローラ。
   コミケに向けて作っているものは、ゲーマーが多いので、割ときつめ。
   みんなができるように、C++とDirectXで。DirectX Runtimeは同梱したほうがいい!
   ネットブックを1台所有しているといいかもしれない(おめがさんと同じ意見)。

○課題4 製作体制や、スケジューリングについて。完成までの製作プロセス
D.K :固定メンバーでない。プロジェクトごとに人を集める。
   自分で作れる期間、でスケジュールを見積もる。協力している側は、「手伝っている」という気になる。
   頼んだ人ができなくても、自分でフォローして完成できるスケジュール(自分でカバーすることを想定)。
   自分がフォローする分もスケジュールに含める。
   期間をオーバーしそうになったら、能力に基づいて、仕様を削ったりする。期間を延ばしたりは基本しない。
   できないならこっちでやるよ、といった感じでやっている。

おめが:一人でやっているので、スケジュールについてはあまり考えずに適当にやっている。

ののたろう:企画とスケジューリングについては担当していない。
      メインの企画の人を一人決める。その人が仕事を割り振る。
      アクションゲームなら、1ステージ動くこと、対戦ゲームなら1キャラ動くこと、を目指してガッと作る。
      その後、コースを増やしたり飾り付けをしたり。
      締め切りはイベントあわせ。

あらいげた:一人でやっているので、思いつきではじめて終わる。
      イベント直前は、キリのいい形にするために、ToDoをまとめたりする。

少佐:週単位で進捗報告、ミーティングを行っている。

藤枝:プログラマ、サウンド、絵がそれぞれ1人。プログラムが動かないとポシャる。
   エディタを最初につくり、別のメンバーに投げ、動くものにする。ほかのメンバーと平行してやる。
   スケジューリングはやろうやろうと言っているが、結局1ヶ月前ぐらいにガッとやっている。
   メンバーが家に居候しているので、ミーティングとかはその場でマンツーマン。
   メンバーが体力あるので、それでなんとかなっている。
   メニュー画面とかをほっておいたら、締め切り前に体調を崩してきついことになった。

D.K :複数人でやるときは、ネット越しにやっている。
   仕事を頼むときは、必ず仮素材が入っているものを渡す。
   画像や曲を差し替えれば動くものを渡す。これが一番大事。

○課題5 企画ってどういう段取りを踏むの?どうやって着想を得るのか?ゲームのネタが浮かぶ場面および1作品の構想が固まるまでにどれくらいの没ネタが出るか
D.K :ちょっと改善したらもっとよくなる、というものを遊んだとき、すごくいいものをオマージュしたくなったとき。

おめが:もう一声、って感じのゲームや、コンセプトはいいけどいまいち突き抜けてない、といったゲームを遊んだとき、作る。
    手持ちのアイデアストックから細かいところをぺたぺたくっつけていく。
    蛇足にならない程度に、単純なルールを考える。

ののたろう:企画でないので、No Comment

あらいげた:新しく作るとき→学祭前。
      過去にやったゲームが頭にあるが、ほかのゲームをやったから、というものはない。学生らしい感じ。

少佐:好きだったゲームを真似る。Age of Empiresの解析をしていた。既存のゲームをコピーする感じ。

藤枝:大学のサークル活動として、みんなで話し合い。アイマスなら今みんな流行!
   みんなで話し合っているので、もめたら終わる。

会場から質問
○デバッグにどれだけのコストをかけているか
D.K :バグの種類 ファイル入出力ミス、あたり判定ミス、仕様漏れ の3つのバグ。
    ファイル入出力ミス:ちょっと本気入れて
    当たり判定ミス:ステージのレベルデザインに力を入れているので、その作成中に直す
    仕様漏れ:レベルデザイン中に大体出てくる。
   基本的に、レベルデザイン中に直す。

おめが:D.K さんと大体同じ。遊んでる時間のほうが多い。

ののたろう:素材とかができてきたら、知り合いと遊びながら。
      1ヶ月ぐらい前に、「デバッグしたいんだけど」と企画に言っても、ぎりぎりまでリソースを作ろうとする。
      デバッグできない。

あらいげた:開発者は想定した動きしかしていない。ほかの人に任せるとバグが出てくる。

少佐:ソフトが落ちるレベルは直す。リプレイバグとかは、場合によっては放置。適当に直す

藤枝:自身がバグをよく見つけるので、ツール等もバグを相当落としてから渡す。
   後に、ちょっと遊んでぽちぽちつぶす。
   出たらその場で直す。

○不正コピーについて
D.K :やわらかライセンスというライセンスをつけている。名前も記す必要はない。
   リソースも込みで自由に使える、という風に公開している。
   すべてフリーで公開している。
   外部に頼んでいて、ライセンスについて了承が得られない場合は、説得するか、その人をはずす。

おめが:基本すべてフリー。忘れなければソースも。

ののたろう:いたちごっこになってる。半ばあきらめてる。

あらいげた:自分としては、ばら撒かれてもあまり気にならない。しかし、ほかの人が気分を害するかも。
      身内に配るぐらいにしてほしい。

少佐:どうしようもないないと思っている。せめてP2Pで配るなら、タイトルぐらい間違えないでくれ。

藤枝:プロテクト対策はいたちごっこ。それより1本でも多くゲームを作ったほうがいいと思う。

○うれしい反応とへこむ反応
D.K :反応をどこから得るか。作業員が楽しかったか。作業員が楽しかったといってくれて、次も作ろうか、となる。
   いい、といってくれる人がいれば、仲間内に伝えて次へのモチベーションにする、程度。

おめが:テストユーザからの反応が一番てっとりばやい。
    ロケテゲームショウのようなところで、後ろから眺めてると面白い。
    メールは来ない。メールにはあまり期待できない。ブログ等で感想をちょろっと見る。
    無料ゲームを集めて紹介するように見せてアフィリエイトを集めるサイトで、
    管理がきちんとなされていなかったときはイラっとした

ののたろう:仲間内から、面白いという言葉がもらえたり。
      メールは、面白いという意見や、クソゲーという意見が来る。

あらいげた:学祭で、「東方っぽい」といわれたり。なんともいえない気分になる。
      あとはTwitter。Twitterは発言が見えるので、あまり否定的なことは言われない。

少佐:微妙に意見が来にくい。いい意見はうれしいし、否定的な意見はへこむ。

藤枝:一番来るメール:DirectXの最新版を…
   あまり感想的なものは来ない。
   へこんだメール:コミケ次の日に、「面白かったんですが、…」と始まり、その後バグリストが続いたメール。

第二部終了後、ゲーム交流会として、参加者同士の交流や、プロジェクタを使ってゲームを紹介したり、ということがありました(時間がなくて15分程度でしたが)。
時間がなかったのでゲームを紹介したのは、AmusementMakersさんだけでしたが、楽しい時間になりました。

今回は一周年記念ということで特別ゲストを招いて行いました。
次回からは通常通りの開催になりますが、皆さんのご参加をお待ちしてます。

1 comment to 第四回全ゲ連交流会まとめ

コメントを残す

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>