Posts in the Category: System&Game

8月
24

UnityWebGLでビルドする方法を紹介

posted on 8月 24th 2017 in System&Game with 0 Comments

弊社のシステムチームではUnityエンジンを使用したソーシャルゲームの
開発を行っておりますが、時としてクライアントワークスでは、
htmlでの閲覧を必要とするときが御座います。
そこで今回はUnityからhtmlのデータを作成する方法について紹介します。

■STEP1:まずは、プラットフォームを切り替えることを始めます。

①:Unityのメニューバーから[File]を選択します。

②:[File]のメニューの中にある[Build Settings]を選択します。

③:[Build Settings]を押したことで専用のウィンドウが表示されたことを確認します。

④:Build Settingsのウィンドウにある[Platform]の項目から[WebGL]を選択します。

⑤:WebGLが選択されたことを確認して、一番左下にある[Switch Platform]を選択します。

Switch Platformが押されると多少の待ち時間を挟みます。
切り替えが完了するとWebGLの項目の横にUnityのアイコンが表示されております。
ここまでがプラットフォームの切り替えとなります。

■STEP2:ビルドを開始する。

①:ブラウザで動作確認に含めたいSceneを開く、またはSceneデータを選択します。

②:Build Settingsのウィンドウの[Add Open Scenes]を選択します。

③:ブラウザで動作確認に含めたいSceneが全て含まれるまで①、②を繰り返します。

④:[Build]を選択します。

⑤:Buildが選択されると、保存先についてのウィンドウが表示されます。
保存したいデータ先を選択してください。
※この時、なるべく空のフォルダを選択してください。
データが混在して管理が困難になります。

フォルダの選択が終わるとビルドの処理が走ります。このとき20分程の待ち時間を挟みます。
待ち時間中にはプログレスバーが表示されます。
しかし、プログレスバーが満タンになる前にConsoleビューで赤字の出力が確認された場合
プログラムに不具合があることになります。

■STEP3:ビルド完了後について。

①:保存先に選択したフォルダの中身を確認する。

②:フォルダの中身に[Release] [TemplateData] [index.html]
これらの3つのデータが存在することを確認する。

③:出来上がったデータは[index.html]を確認したいブラウザにドラッグ&ドロップ確認することが出来ます。

■動作確認の推奨、非推奨

①:Firefox、MacPCのみSafariが安定しております。

②:GoogleChormeは非推奨です。
どうしても見たい場合はGithubや公開サービスのサーバーを
使用してURLを取得することをお勧めします。

③:Internet Explorerは11から推奨です。

④:この他にUnityとブラウザのバージョンによって正常に動作しないこともあります。

■まとめ
ここまでWebGLのデータを作成する流れについて説明してきましたが、
基本的にはIOSやAndroidのビルド方法と手段は同じです。
プラットフォームで分かれている専用のシステムをいかに理解することが、効率の鍵になると思います。
もしこの記事を見ているあなたがWebでゲームを全体公開したい場合は、
プラットフォームをWebPlayerに切り替えてUnityGameUpLoaderというUnity公式のゲーム配信サイトから投稿してみるのも面白いと思います。

Read Article
12月
14

商品開発における品質管理とデバッグの重要性

posted on 12月 14th 2016 in System&Game with 0 Comments

はじめまして。今回のブログ記事を担当いたします田中です。
東京オフィスでゲームプランナー、バナー制作、Flash/AnimateCCのアニメーション制作、といった業務を担当しております。

今回は新山からバトンを受けまして、品質管理とデバッグのお話です。

商品開発には、品質管理「QA」や不具合を取り除く作業「デバッグ」が必ず行われます。
デバッグと言うとPCを使った開発が主に頭に浮かぶ方が多いのではないかと思われますが、ゲームやWeb、アプリ開発以外でも開発と名のつくものであれば、リリース、商品化する前には必ず必要になる作業です。
私は開発側の人間ではありますが、必ずと言っていいほどデバッグに携わっております。(デバッグという言葉は広義で様々な意味を持ちますが、今回は単純に「不具合を取り除く作業」、という意味でお話しいたします)

不具合が起きた時--例えばオンラインゲームアプリのリリース時を例にあげますと、

「アイテムが消えた!」
「ログインできねーじゃん!」
「いきなり強制終了した!」
「友達登録ができない!」

……といった苦情をアプリレビューやSNSなどで多数見かけたり、あるいは実際に体験された方も多いのではないでしょうか。
しかし、どんな開発においても不具合というものは付きものなのです。だからこそ、デバッグという作業が発生します。

私は過去に様々なジャンルのゲーム開発においてデバッグに携わりましたが、どの会社でも、同じチームの方は必ず口を揃えてこう言います。

「バグがゼロの時ほど怖いものはない」……と。

開発においてデバッグに費やせる時間と予算はほんの一握りです。会社によってはデバッグチームがなく、開発者が自らデバッグを行うこともあります。
だからこそ、デバッグの際には短時間で効率良くチェックをする方法が必要になります。
デバッグや開発未経験者に何も説明せずにデバッグをお願いするとかなりの量で報告が来ますが、そのほとんどが仕様だったり、今の段階では見なくても良いような箇所だったりします。これでは時間の浪費(ロス)につながります。

 

では、どのようにして短期間でチェックを行うのでしょうか。
以下は開発環境でのデバッグ方法です。

はじめに理解しなくてはならないのは、「今回チェックすべき範囲」です。これは、その時実装するものに限られます。
初めて商品をリリースする場合は全体的なチェックが必要になりますし、既にリリースされていて新機能(オンラインゲームなら期間限定イベント、新キャラ・新ステージなど)を追加する際は、その辺りを重点的に見ることになります。

チェックを行う人は、まず実装物の仕様を仕様書や口頭などでしっかりと確認し、チェック項目の目処を付けます。
その後、実装前に一度、チェックシートをExcelシートなどで作成します。出来れば、重要度に応じてS、A、B、Cといったランク付けを行うと良いでしょう。
一例をあげますと、項目には「街で主人公のグラフィックが表示されていること」のように、どのようになっていれば正しいのかを記載します。チェック内容が明確な時は「街:主人公の表示」といった風に簡略化することもありますが、他のチェック者にも理解出来る内容を記載し、注意点は備考欄に記載します。

そうしてチェックシートが出来ましたら、特に重要なものや外せないものを再度リストアップし、一項目辺りにかかる時間から総チェックにかかる工数を決めます。
特にメンテナンス時は1時間中の30分だけ、といった短い時間で行うことがほとんどですので、特に重要度の低いチェックは開発環境でのチェック時に全て済ませておきます。

チェックは修正に時間のかかるものから順番に行います。動作に関わるようなシステム、グラフィックなどが特にそれに当たりますね。
テキストの誤字などは動作には関わらないバグですので、こちらは修正が後回しになることが多いです。(ノベルゲームではむしろ最優先となりますが)

チェックが終わったら(或いは随時)、発生した不具合をまとめ、それぞれの担当者に報告して修正依頼を出します。
後ほど修正された時にその項目だけをチェックし、バグがなくなったところで再度全体的なチェックを一度行い、これで開発環境のチェックが完了します。

つまり、リリース直前は既にチェックと修正を行い、バグがなくなった状態(これらの作業工程をまとめてデバッグと言います)なので、メンテナンスではそこまでのチェックをしなくても良いわけです。
メンテナンスで行うのは「本番環境に正しく開発環境の状態が反映されているか」です。特に画像の反映を忘れていたりすると、しょっぱなから何も表示されなかったりします。もちろん、デバッグモード(RPGだと倍速移動やエリア移動コマンドなどのチェック用機能)の封印も忘れずに行い、そのチェックも行います。

以上が大まかなデバッグの流れとなりますが、それでも本番に不具合を洩らしてしまうケースはよく見かけます。こうしたものはお客様からのお問い合わせによって運営へ、さらにデバッグ担当者や開発者へと伝えられます。特に、大勢のユーザーに影響するような重大な不具合を見つけた場合は、すぐに緊急メンテナンスを開くことになるでしょう。

オンラインゲームにおいては、不具合を修正した際に大抵「補填」が行われます。ゲームによって内容や条件は様々ですが、もらえるものは有料アイテムだったり、ガチャを回すための宝石(詫び石とか言われていますね)だったりします。

しかし、それらはデータでいくらでも渡せるとはいえ、決してタダではありません。補填には有料アイテム分の損失があり、ひいてはゲームの寿命を浪費する結果となるのです。時には数十〜数百万円もの損失になることもあります。
ただでさえ基本無料で提供することの多いオンラインゲームでは、サーバー設備費や多くの人件費などで資金がカツカツになりますし、ギッシリと詰まったイベントの準備もあって開発期間に余裕がありません。このようなミスで資金を浪費するのは、なるべくして避けなければならないのです。

開発においてデバッグはかなり後回しにされがちな工程ですが、ここまでの話でどれだけ重要な作業であるか伝わりましたでしょうか。
はじめにも述べましたが、上述の内容は決してゲームやアプリ開発に限ったことではありません。開発とつくものがあれば、どんな商品にも品質管理があり、不具合(不良品)のチェックがあります。

我々開発者の前には必ずお客様がいらっしゃる--そのことを常に念頭におき、極力不具合をなくすよう努めながら開発していきたいものです。

Read Article
10月
12

ゲーム企画のお仕事

posted on 10月 12th 2016 in System&Game with 0 Comments

Guten Tag 今回ブログを担当する新山です。
松山オフィスでゲームプランナーやディレクションを担当しています。

去年までは東京のゲーム開発会社で企画職をしていましたが、
娘が生まれたことをきっかけに地元へUターンして転職しました。
生まれ育った松山の落ち着いた環境で仕事と子育てに勤しんでいます。

さて、私の仕事であるゲームプランナーですが
「どんな仕事なの?」と聞かれることが全く無いので
一方的に私から説明させてもらおうと思います。

「ゲーム開発」に携わる仕事をものすっごいザックリ分けると概ね以下の職種に分かれます。
・プランナー
・プログラマー
・デザイナー
・サウンド
※プロデューサーとか偉い人は割愛で。

で、これらの職種の役割をものすっごいザックリ言うと、
プログラマーはゲームを動かす人。
デザイナーは動くものを作る人。
サウンドはBGM、SEを作る人。
です。

ではプランナーは?というと、
どんなゲームをどう作るか考える人です。

これだけ聞くとなんだかすごく楽しそうだし、
他の職種から比べると簡単そうですね。

順を追って補足します。

 

1.
まず企画を作るところから始まります。
自分が開発会社の場合は大体クライアント様から企画のお題を頂きます。
「RPG作りたいんだけど」とか「このキャラを使ったゲームつくりたいんだけど」とか。
そんなクライアント様のご要望に合わせて企画書というものを作ります。
こんなゲームを作りますよ~、という説明資料です。

この時に勘違いしてはいけないことが「僕が考えた最高に面白いゲーム」にならないことです。
いや、それが世の中の皆様に受け容れられるのであれば何の問題も無いのですが。。。

クライアント様に認めて頂かないとお仕事として成立しませんので、
当然クライアント様のオーダーに応えた内容である必要がありますし、
持っている、用意できる技術、人員で開発ができる必要もありますし、
最終的なお客様であるユーザーの皆様にも楽しんで頂ける必要があります。
決して独りよがりではなく、周りを納得させられる説得力のある企画でないといけません。

はい、なんだかハードルが上がりましたね。

無事企画書ができましたらクライアント様に提出です。
このまま一気に開発突っ走るぜ!という事は少なく、大体コンペです。
コンペというのはアレです。コンペディションです。競争です。
クライアント様はいくつもの開発会社へ声をかけてたくさんの企画を集めます。

クライアント様も当然良い企画が欲しいですし、
それが安く作れるのであればそれに越した事はありません。
集まった企画の中から良いものを選び、それを提案した会社に開発を依頼します。
(企画だけ拾っておいて開発は他の会社に、、、ということはないハズです。)

言い忘れましたが企画書の提出とともに、これくらいの費用で作れますよ!という見積もりも出します。
この見積もりというのもプランナーやディレクターが現状の情報をかき集め、
プログラマーやデザイナーに「こんなの作るとしたら何日かかるよ?」
という確認をして金額に落とし込みます。
この時点で開発のスケジュールも用意したりします。先々を見越しておかないとダメですね。

何としても受注したいがためにプログラマーやデザイナーから言われた工数を少なくして
見積もりをつくったりすると、後から大変なことになりますのでここはうまくやりましょう。

企画書と見積もりを提出し、見事コンペに勝ちぬいたらようやく開発スタートです。
負けた場合はフリダシに戻ります。

 

2.
さて、コンペの時に出した企画書は嘘とは言いませんが、夢や希望が詰まっていたりします。
実際開発するにあたって、現実的な「仕様」というものに落とし込む必要があるのですが、
この現実的な仕様が企画書と乖離が大きいとクライアント様から「新山くんちょっといい?」
ということになるので、ここはバランス感覚が必要です。経験を積んで養いましょう。
この辺をこれ以上具体的に言うと揉めたり怒られたりするので割愛します。

あ、「仕様」というのはゲームの設計とかつくり方とかです。
考えた内容を実際プログラマーやデザイナーに作ってもらう際に、
このように作ってね、という指示を出すための資料です。
決して口頭だけにならないよう、書面としておくことが重要です。(戒め)

 

3.
開発を進めながら更なる仕様やデータ(キャラのパラメータなど)を作り続けていくのですが、
順調に開発が進んでいるかどうか、進捗具合を確認していくのもプランナーのお仕事です。
順調に進んでいないようであれば担当者から問題点を聞き出して解決方法を模索します。
安易にスケジュールを伸ばすとかは許されないのです。(戒め)

具体的な解決方法は概ね「がんばる」「もっとがんばる」「睡眠時間を生贄に作業時間を召喚」となるのですが、
色んな人の知恵を出し合うことで、「効率的なつくり方」が見つかる場合もありますので、
意見を吸い上げる場を設けることができる、ということもプランナーとしては重要な能力だったりします。
パソコンと向かい合っているようなイメージのお仕事ですが、それ以上に人と向き合わねばなりません。

 

4.
あとは開発終了まで3を延々と繰り返していくことになるのですが、
最近のスマホのゲームとかだとリリースしてからが本番だったりします。
お客様がどのように遊んでいるか、ということを数値で分析して改善を続けていきます。
よく遊ばれているコンテンツと遊ばれていないコンテンツの違いは何なのか、
なんかこのボタンあまり触られてないけど不要な機能なのかしら?それとも場所が悪い?
などなど。
こういったリリース後の問題を分析し、改善策を出すというのもプランナーのお仕事です。

長々と書きましたがゲームの開発工程のような話になりましたね。
とはいえプランナーというのは開発工程全てに関わるような職種ですので、大体このような感じです。
他のサイトを見て確認しましたが概ね間違いはなさそうです。(錯乱)

 

以上です。

千鳥足の駆け足で説明しましたが、ゲームプランナーというお仕事をなんとなくご理解頂けたでしょうか?
なんとなくで結構でございます、会社が変われば細かい部分は変わりますので。はい。

さてさて、一段落ついたところで話は変わってリクルートなお話です。
こんな私でも10年ボチボチはゲームプランナーとしてご飯を食べていますが、
「なぜ?を理解・説明できる(論理的な思考)」
「ちゃんと人と話すことができる(コミュ力)」
「ゲームが好き(情熱)」
「色んな意味でのバランス感覚」
という要素が備わっている人がゲームプランナーに向いているのかなと思います。
他のサイトでも似たようなことを書いていたので概ね間違いはなさそうです。(錯乱)

ちなみに私が前の会社でプランナーとして就職した際は「ただのゲーム好き」という程度でしかなく、
どこにでもいる元自衛隊員の色物枠でした。
経験を積んでいく上でその他の能力は身についていきましたので、
細かいことは気にせず熱い情熱を持ってウチに企画書を送りつけてくればよいと思います。

ただし、絵も描けないしプログラムも組めないから、じゃあプランナーを目指そう!
というのは勘弁な!

次回予告!
ひんかん
(品質管理)

Read Article
10月
11

ロスト・イン・トランスレーションな話

posted on 10月 11th 2016 in System&Game with 0 Comments

皆さん、こんにちは、オートクチュールでゲームのディレクターをやっている加藤です。

ゲームの企画面の話は、他のできるプランナーがすると思うので、海外版を作る時の簡単なこころ構えの話をしようと思います。

「ロスト・イン・トランスレーション」、前にスカーレット・ヨハンソンとビル・マーレイがでていたあの映画とはあんまり関係がないのですが、「翻訳のプロセスに置いて失われるもの」が直訳になります。
タイトルから想像できるように言語の翻訳についての話です。
翻訳をする時、①字幕翻訳の場合、②音声翻訳の場合、それと③翻訳者の技量によって、様々な情報が失われることがあります。
それらの知っておくと良いポイントについてざっくりと述べてみます。

 

①字幕翻訳の場合
映画の字幕を思い出してもらうとわかるのですが、普通の人が一度に読める文章量は2行程度です。
文字で説明する際、3行以上かかってしまう内容だとニュアンスの一部を削らなければいかんのです。
後は自然に音声中の鼻での笑いやため息などの演技を入れ込もうとするのも苦労します。
ともあれ、これは字幕の宿命です。
プランナーの人は一つの文節に多くのニュアンスを込めず、大事な情報は複数の文節に小分けにしてくれるとうれしいですが、そうも行かない世の中です。
シン・ゴジラの英文翻訳とかのお仕事は大変だろうなと思いました。
制限に合わせて翻訳調整を頑張ることになります。

 

②音声翻訳の場合
尺の中であれば言葉以外の付加情報を入れられます。
一般的に字幕より情報量が多くできる上、息を使うことで感情表現を豊かに出来ます。
「しゃべっている間は音声を入れられる」、という点と「鼻で笑う」、「ため息」などのニュアンスを文字に比較して短い時間で盛り込めます。
それでも制限があることには代わりませんが、圧倒的にこちらの方が「失われるもの」を少なく出来ます。
ただ、音声収録は予算がかかるので何回もできないことが多く、収録での失敗が許されない場合が多いので収録前はいつも大変です。
準備が全てなので、翻訳と収録準備を頑張ることになります。

 

③翻訳者の技量
音声の時、字幕の時、いずれの場合もここが全てです。
これは「どこまで母国語以外のボキャブラリーを持っているか」、「領域外の単語をどれだけ知っているか」になります。
政治で使われる言葉、下品な言葉、上品な言葉、方言、それぞれを翻訳する際にどこまでらしくするか。
英語でも「The」を「Da」といったり、イギリス訛りとアメリカ訛りとフランス訛りなどがあり、日本にも東西南北それぞれの方言があります。
英語の一人称は「I」、日本語は「オレ」、「私」、「僕」、「アタシ」、「ワイ」、「自分」等色々あります。
これらを当てはめるか、標準語に全部直すのか。
頭の悪そうなトロールは「オレ」とか「オデ」とか話して欲しいし、そういうのがいれば「私」と話す頭の良いトロールを引き立たせることも出来ます。

こういったものを表現する際、文字数にも気をつけねばなりません。
例えば「I」を「わたし」で表現すると3文字分の長さ、「おいどん」で表現すると4文字分の長さになります。
音声だと「わたし」と「おいどん」で1文字の長さの違い、字幕だと「私」と「おいどん」で3文字の違いがでます。
方言でも語尾が「です」、「ですねん」、「だっちゃ」、などで増えたり減ったりします。

これらは全ての単語に当てはまるので、常に方言やシチュエーション的な情報を削ぎ落とす必要性に迫られます。
知識がなければ全て削ぎ落とされますし、技術があればある程度の担保が出来ます。
制限と表現のせめぎあいなわけです。

あと、当然ですが翻訳時、収録前の映像等の確認作業はめんどいですが超大事です。
ここに手を抜くと後々、間違いにつながります。

例)
「It’s a piece of cake」=「朝飯前さ!」
文章だけみると、これで成立してます。
でも、実際のシーン中で「俳優がケーキを片手にもって言葉遊び的なものをしていた場合」は話が違ってきます。
ケーキと朝飯、「朝飯前さ!」だと日本語にした際に俳優のアクションが無駄になっちゃますし、違和感を感じます。
某ゲームで「Remember, No Russian」の訳について話題になったことがありますが、翻訳時に映像と合わせることでそういったリスクを減らせます。

 

上記は、文章や音声ファイルだけの提供での翻訳だと充分に起こり得ることなので、プランナーの諸兄はドラマ的なものが絡む全てのシーンをムービーに取って翻訳者に送るように。
大事なことなのでもう一度言います、ドラマ的なものが絡むシーンをムービーに取って翻訳者(とローカライズ担当)に送るように。
というわけで市場のグローバル化が叫ばれる昨今、日本の開発者と開発者の卵の皆様には、よりローカライズのプロセスに目を向けて欲しいわけです。
あと、英語を習得するだけで世界が広がります。
マジで。
だから、若者は勉強してブロークンでも良いので喋れるようになってください。
ブロークンでも続ければうまくなります。
僕なんか、最初はファックとシットとビッチしか話せなかったのに、今ではファックとシットとビッチで色んなコミュニケーションが取れるようになりました!

ざっくりとですが、これにてロスト・イン・トランスレーションの話をおしまいとさせてもらいます。

次回公開予定日は10月24日(月)、弊社ディレクターの新山のブログをお届けします。

 

Read Article