DELiGHTWORKS

DELiGHTWORKS株式会社の開発に関する情報を発信していきます。

ゲームデザイナーに必要なスキルはなんですか?

ディライトワークスの田村です。
たまに絵も書けないし、プログラムも組めないので、ゲームデザイナーを目指します!という話や、プログラマーをある程度やってから、ゲームデザイナーになりたいです、という話を聞いたりします。

でも、これって非常に難しいことなんですね。
ゲームデザイナーを夢見る皆さんのために「ゲームデザイナーに必要なスキル」について書いてみます。
とはいえ、私はゲームデザイナーではありませんから、
「The Art of Game Design」の記載を借りることとしました。

Jesse Schellは言います。

要するに「(ゲームをデザインするのに必要な能力は)すべてである」と。
彼が本書の中でアルファベット順に挙げてくれていた幾つかの項目を見てみましょう。

アニメーション(Animation)

現代のゲームは、生き生きとしたキャラクターでいっぱいです。
「アニメーション」という言葉は「命を与える」という意味なのです。
キャラクターアニメーションの力と限界を理解することで、世界がまだ見たこともないような巧妙なゲームデザインのアイディアのドアを開くことができるでしょう。

 

人類学(Anthropology)

自然の生息地で聴衆を勉強し、心の欲望を理解しようとすれば、あなたのゲームはその欲望を満たせるかもしれません。

 

建築(Architecture)

あなたは建物以上のものを設計します。都市全体、世界全体を。
人と空間の関係を理解する建築の世界に精通していることは、ゲームの世界を創造する上で大きな足跡を残すでしょう。

 

ブレインストーミング(Brainstoming)

あなたは何十という新しいアイディアを創造する必要があるからです。

 

ビジネス(Business)

ゲーム業界では、殆どのゲームはお金を稼ぐために作られています。
ビジネスの先端を理解すればするほど、夢のゲームをつくれるチャンスが増えます。

 

映画撮影(Cinematography)

多くのゲームは動画を持っています。
ほぼすべての現代的なゲームは仮想的なカメラを持っていますし、リアルで魅力的な体験を提供したい場合は、映画撮影の技術を理解しておく必要があります。

 

コミュニケーション(Communication)

ここに記載されているすべての人と話す必要があります。
論争を解決し、コミュニケーションの問題を解決し、チームメイトやクライアント、顧客が実際にあなたのゲームについてどのように感じるかの真実について学ぶ必要があります。

 

創造的な執筆(Creative writing)

あなたは架空の世界と、そこに住む人口を創造し、そこで起こる出来事を決めなければならないでしょう。

 

経済(Economics)

多くの現代的なゲームは、複雑なゲーム内リソースの経済を特徴としています。
経済学のルールを理解することは、驚くほど役に立つでしょう。

 

エンジニアリング(Engineering)

現代のビデオゲームには、今日の世界で最も複雑なエンジニアリング技術の幾つかが含まれています。
新しい技術革新は、新しい種類のゲーム体験を可能にするでしょう。
革新的なゲームデザイナーは、それぞれの技術がもたらす限界と力の両方を理解していなければなりません。

 

ゲーム(Games)

当然のことながら、ゲームに精通していることは大いに役に立ちますが、作成しようとしているゲームの種類に精通するだけでは足りません。
ロバの絵にしっぽをつけるゲーム(Pin the Tail on the Donkey)から、パンツァードラグーン(Panzer Dragoon)まで、あらゆる種類のゲームについての知識は、今ゲームを作成しようとする際に必要な原材料となります。


歴史(History)

多くのゲームは歴史的な設定を持っています。
ファンタジーの設定をされたものでさえ、歴史から驚異的なインスピレーションを得られるでしょう。

 

マネジメント(Management)

チームが目標に向かって一緒に働いているときはいつでも、何らかのマネジメントをする必要があります。
優れたゲームデザイナーは、管理が失敗していても成功することができます。

 

数学(Mathematics)

ゲームには、一般的にコンピュータグラフィックスやコンピュータサイエンスの背景にある数学はもちろんのこと、すべての数学、確率、リスク分析、複雑なスコアシステムなども含まれています。
熟練したdesignerは、時々、数学を掘り下げることを恐れるべきではありません。

 

音楽(Music)

音楽は魂の言語です。
あなたのゲームに人々が触れ、夢中になり、それを抱擁するならば、音楽なしでは成り立たないでしょう。

 

心理学(Psychology)

あなたの目標は人々を幸せにすることです。
人間の心の働きを理解していないとすれば、暗闇の中でゲームデザインしているのと同じです。

 

演説法(Public speaking)

あなたは頻繁にアイディアをグループに伝えなければいけません。
時々、あなたは彼らのフィードバックを得るためにも話すでしょう。
また、時には天才的な新しいアイディアについて話すことがあります。
理由が何であれ、自信を持って、自然に、そして伝わるように話さなければいけません。

 

音響制作(Sound design)
音響は、それがその場所にあることを心に納得させるものです。
言い換えれば「聞くことは信じることだ」です。

 

技術文書(Technical writing)

仕様の穴や隙間を残すことなく、複雑なデザインを明確に記述した仕様書(ドキュメント)を作成する必要があります。

 

視覚芸術(Visual arts)

あなたのゲームはグラフィクスの要素でいっぱいになります。
なので、あなたがグラフィックデザインの言葉に精通しており、ゲームに持たせたいイメージを伝えるために、言葉を使う方法を知っていなければいけません。

 

さて、ゲームをデザインすることの大変さが伝わったでしょうか。
それにしてもゲームデザイナーが覚えなければいけないことは驚くほど多岐に渡りますね。
本当にこんなゲームデザイナーがいるのでしょうか?
しかし、真実は誰にもこんなことはできない、ということなんです。

 
でも、考えてみてください。
世の中にはこれらの要素が複合した本当に素晴らしいゲームは存在しています。

では、なぜこれらの要素が絡み合った複雑で素晴らしいゲームができるのか、それを次では書きたいと思います。

どうしたらゲームプログラマーになれますか?

ディライトワークスの田村です。
ゲーム開発の仕事をしていると、ゲームの仕事に就きたい人から、
「ゲームが作りたいです」
「ゲームを作ることが夢でした」
「私でもゲームを作れますか?」
「どうしたらゲームを作れるようになるでしょうか、未経験でもゲーム開発の仕事に就けるでしょうか?」
「最初はCをやればいいでしょうか、それともUnityでしょうか、Unreal Engine4でしょうか?」
そんな話を聞くことがあります。
では、その答えはなんでしょうか?

 答えを教える前に一つお話を。
私が尊敬するプログラマーに、Jesse Schell氏がいます。
彼は「The Art of Game Design: A book of lenses」の著者であり、VRやARなどの開発で有名な「Schell Games」の経営者です。
彼はもともとはサーカスのジャグラーであり、IBMや電話会社、ディズニーで働いたことがあるプログラマーでもあります。
残念ながら彼がプログラマとして素晴らしいソースを書くかどうかは私は知りません。しかしながら、彼のゲーム開発に関する考え方に強く共感しています。
彼は非常に多くの素晴らしい話をしているのですが、ここで一つ紹介します。

彼の著書である「The Art of Game Design: A book of lenses」の冒頭には、こんな記載があります。

ゲームデザイナーになりたい人にしばしば訊かれます。

「どうやったらゲームデザイナーになれますか?」

答えは簡単です。

ゲームをデザインしましょう!いますぐ!待ってはだめ!この会話を終わらせてもだめ!いますぐデザインしよう!さあ、いま!

彼は多くの人が「ゲームデザイナーでなければゲームをデザインできず、ゲームをデザインすることでゲームデザイナーになれる」と考えているようだ、と言います。
でも、彼は教えてくれます。
もし、あなたがゲームデザイナーになりたいのであれば、今すぐこの魔法の言葉を言えば良いんだよと。
その魔法の言葉とは、

「私はゲームデザイナーです(I am a game designer.)」

です。
彼は真剣にゲームデザイナーになりたい人のために、それを言っています。今すぐ大声でそれを言うべきだと。恥ずかしがらずに、さあ!と。

 私はゲームプログラマーになるのも同じだと考えています。
そうです、まずゲームを作れば良いんです。
仕事じゃなければゲームを作れない、なんてことはありません。
作りたいのであればいつだって作り始められるんです。
汚いソースコードだって良いんです。まずは動くものを作りましょう。
最初から完璧にできる人なんていないんですから。
(私が最初に真面目にゲームを作った環境はVB5でした)

もちろん、最初から世の中にリリースされているAAAタイトルを作ることはできません。
でも、「ゲーム」と呼ばれるものはいつだって誰だって作れるんです。
たとえ最初は掌に収まるような小さなゲームであっても、小さなゲームさえ作れない人がAAAタイトルを作ることはできません。
基礎を勉強してからじゃないと作れない、なんてことを言っていたらいつまで経ってもゲームは作れないんです。
最初の一歩は小さくても良いのです。
だから、ゲームプログラマーを目指す方にも私は自信を持って「魔法の言葉」を言ってほしいです。

「私はゲームプログラマーです」と。

最初から一流の開発ができる人はいません。誰だって最初は小さく始めるんです。
そして、もっともっと面白いゲームを作りたいと思ったら、ゲーム会社の門戸を叩けば良いんです。

プログラマーとして生きていくこと

ディライトワークスのプログラマーの田村です。

最近プログラマーとして考えていること、を書かせて戴ければな、と思います。

プログラマーのみなさん、プログラマーとしてずっと生きていこうと考えているでしょうか。

それともどこかで限界が来ると考えているでしょうか。

たまにこんな話も聞きます、スペシャリストにはなれないからマネージャーになろうかな、ディレクターになろうかな、プロデューサーになろうかな。

はたまた、人と話したりするのは苦手だからスペシャリストになろうかな、なんて話です。

凄いプログラマーに出会ってしまうと、自分がプログラムやらなくてもな……、なんて事を考えてしまうことありますよね。

凄いゲームデザイナーに出会えば、ああはなれないからプログラムを頑張ろう、なんてことも思うかもしれません。

では、プログラマーとして生きていくとしたとき、何が必要でしょうか。

一言で言えば大事なのは「問題を解決する力」です。

プログラマーはプログラムが書ければプログラマーなのでしょうか。

きっとそうではありません。

世の中の殆どのプログラムは問題を解決するために存在しています。

人間がやったらミスしそうなことを自動化するとか、演算するとか、代わりにやってくれたり、ゲームでいえば、ユーザーさんに快適かつ、面白いと感じて戴くために様々な問題を解決する必要があります。

AIならユーザーさんが気持ち良く戦えるようなAIが必要かもしれません。

当たり判定もオブジェクトが単に当たれば良いのでは無く、UIのボタンは単に押せれば良いのではありません。

「面白いゲームを遊んで戴けるにはどうしたら最適か?」

という問題を解決する必要があるんですね。

プログラマにとって「言われたとおり動いているでしょう」はプロとして失格です。

仕様書にそう書かれていたからそう実装した、ではいけないんですね。

例えば医療機械のプログラムで「確かにこう書いたら患者さんが危険だけれども、仕様書にはこう書いてあったから」ではすみませんよね。

同様に「仕様書に書いてなかったから想定していません」も危険です。

アクションゲームの仕様書に「Aボタンを押したら剣を振る」 と書いてあったら、剣を振る実装をするのではありません。

「何故剣を振らなければならないのか、剣を振った結果どうなるのか、仕様書を書いた人の意図はなにか、最終的にユーザーさんはどんな操作やどんな体験をするのか」まで考えなければなりません。

プログラムは0と1しかない、だからロジカルだとよく言われます。

しかし、私はそう思いません。プログラマほどアナログでファジーな仕事もなかなかないと思っています。

同じ仕様書があっても、10人のプログラマがいればそれぞれ違ったゲームやシステムが産まれる筈です。たとえ見た目が同じように見えたとしても。

言ってしまうとプログラマーとして生きていくこと、というのはずっとこうした問題と向き合っていくことになります。

そして、自分たちは常に「面白いゲームを創るにはどうしたらいいか?」という問題と向き合っています。

「ただ純粋に、面白いゲームを創ろう。」

という事を実現するためにです。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

 

 

48時間後…

こちらは48時間後に突然サービスが瞬断される状況が頻発し、生きた心地がしなかった、という備忘録です。

AWS Summitでお話しさせて戴いたAWSへの移行ですが、その中にAuroraは出てきませんでした。しかし、実際にはFate/Grand Orderは一度Auroraへ移行をしていました。そして、再度RDSに切り戻しています。

こちらに関して既に問題は解決してはいるのですが、こんなこともあったということで知見を共有させていただきます。

4月末、私たちはRDS(MySQL)をAuroraへ移行しておりました。これはDBの分割前に行った対策になり、暫くは問題無く稼働していました。

しかし、稼働から48時間後突然のスパイク(アクセス障害)が訪れました。これに関してはまさに「この瞬間には何もしていない」のに発生したスパイクで、アクセス数が急増した訳でもなかったため、解決には非常に困難を極めました。

原因はAuroraにあることは明らかですが、原因が思い至りません。

こちらに関してあらゆるパラメータの精査、MySQLコネクター周りの実装確認、かつ自社側のプログラム側の確認、を行いましたが解決出来ず結果としてRDS(MySQL)への切り戻しを行いました。

 

その後、調査を進め私たちは問題を突き止めることができました。

問題は何だったのでしょうか?

答えはRDS(MySQL)への切り戻しのために設定したbinlog(バイナリログ)でした。

この時期のAuroraはbinlogをPurgeする際に「Init DB」という高負荷のクエリが頻発し、サービスが瞬断される症状があり、Purgeが走り始める48時間後に突然性能が低下し、問題が発生したのです。

(Fate/Grand Orderではbinlogの保持期間を48時間に設定していたため)

なお、この問題に関してはEfficient Storage of Binary Logsという変更が入り、解消されていますが、この時点ではこの変更はlab mode(実験中)でしか提供されておらず、問題となったのでした。

 

Auroraの使い方につきましては、

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.CrossRegion.html

の “Before You Begin”に”you must be running the most recent version of the Aurora database engine"

とあるように、最新のバージョンを利用することが推奨されています。

なので、皆さんは是非最新をご利用下さい。

 

既に問題は発生しませんが、リリースされているEfficient Storage of Binary Logsの変更に関してはこちらをご覧下さい。

https://forums.aws.amazon.com/ann.jspa?annID=3793

 

ということで、48時間後に突然の障害に見舞われたお話でした。

このような障害も時にはありますので、いつでもインフラは気を抜けません。

このときは直ぐには原因が思い至らず、本当に冷や汗が出ました。

元々切り戻しのためのbinlogに対する障害なので本末転倒感がありますが、切り戻しで解決したときは胸をなで下ろしたものです。

やはり何事にも準備が必要ですね。

……が、より快適に遊べるゲームを目指し再度Auroraへの移行を行う予定です!

AWS Summit 2016で登壇致しました

Fate/Grand Orderの事例に関しまして、AWS Summit 2016で登壇を行いました。

お越し戴いた皆様、誠に有り難うございました。

こちらのスライドですがあまりにも多くの事があったため、時間内にすべてを入れ込むことが出来ず、こちらにはまだ続きがあります。別の機会にはログ解析や、Amazon Auroraに関してもお話できればと考えております。改善に関しても継続して行っておりますので、それらに関してもお話する機会を得られれば幸いです。

また、インフラエンジニアが今も不在ではないか、というご指摘を受けましたので補足を致しますと、現在はスライドの中にも登場する株式会社スカイアーチネットワークスさんのインフラエンジニアさんと、社内のインフラエンジニアで一緒に運用をしております。クライアントやサーバーのエンジニアに関しましても、一緒に開発をしたいという仲間が続々と集まっております。

ただ、引き続き募集はしておりますので、どうか宜しくお願い致します!

こちらは頂きました記念品です。

f:id:delightworks:20160609102519j:plain

Amazon様、登壇の機会を戴き誠に有り難うございました。

また、改めまして講演を聴講戴いた皆様も本当に有り難うございました。

ディライトワークスではAWSを利用しています

あけましておめでとうございます。ディライトワークスの磯波です。

AWSへ移行致しました

昨年、私たちが開発しているゲームをAWS(Amazon Web Services)へと移行致しました。

ゲームを遊んで頂いている皆様にはご心配、ご迷惑をお掛け致しました。

当初の想定よりもより多くのユーザーの皆さんに遊んで頂くことができ、以前の環境でも最高スペックのサーバーとデータベースを用意していたのですが、それでも通信が詰まってしまうという現象が発生しておりました。

それに対応すべくプログラムの最適化を進めてはいたものの、ユーザーの皆さんにより快適に、安定して遊んで頂けるように総合的な判断としてAWSを選択致しました。

AWSに移行することで、よりスペックの高いサーバー構成に変えることができ、今回は倍以上のスペックへと変更致しましたが、さらに良いパフォーマンスの環境への移行を検討しています。

以前の環境では、用意されているスペックなどが現状に見合わず、性能を引き出すことも出来ていませんでした。

AWS のEC2インスタンスを使うことで数分でサーバー台数を増やすこともでき、サーバーやデータベース、メモリキャッシュのスペックも柔軟に対処することができます。

これでアクセスが集中しがちなイベントでも対処ができるようになります。

これはゲームの幅が広がることでもあり、アイディアを形にしやすくなるということでもあります。

また、サーバー管理の方法を全面的に見直し、以後も構成を最適化していくことを検討しています。

検証に際して

検証に関しては既にリリースをされている検証用のアプリと、既にリリース済みのアプリの両方での動作検証を行いました。

実際にクライアントアプリにとってはサーバーはAWSだろうと以前の環境だろうと同じように同じデータを返してくれれば構いません。

その検証をするために、iPhoneやAndroidをPCのプロキシ経由でネット接続するようにし、PCのhostsを書き換えて新しいサーバーにAPIを向けることで検証を行いました。

こちらは思いの外うまくいき、既に皆さんのお手元にある既にリリースされたアプリがAWSのゲームサーバーでもうまく動作することが確認できたわけです。

(寧ろ、うまく動きすぎていて内心はドキドキしていました)

マネージドなサービス

AWSはRDSという強力なマネージドデータベースを持っています。

高速なストレージを持ち、加えてデータも高い冗長性を持っています。

ElastiCacheも同様にマネージドなインメモリキャッシュです。

双方に備わっているMulti-AZという仕組みは1つのデータセンターが津波や地震に襲われたとしても、もう1つのデータセンターがデータを保全し、かつサービスも止めないようにしてくれるという仕組みとなっています。

これらの仕組みによって、皆さんのデータを守り、ゲームを快適に遊び続けられる事を担保していきたいと考えております。

開発者にとってのメリット

また忘れてはいけないのは、今後のエンジニアのスキルとしてクラウドコンピューティングが欠かせないということです。

以前はオンプレミスのサーバーでは、サーバーを担いでデータセンターに持っていき、サーバラックに突っ込むなんていう運用もありました。

寒いサーバールームで必死に対応した、なんて思い出をお持ちの方も多い筈です。

しかし、これらの思い出話は苦労話としては成り立つでしょうが、以後役に立つ経験値とは言いがたいはずです。

5年後、10年後、もっとゲームは進化するでしょう。その時に、サーバーを担いでデータセンターに向かう経験よりも役に立つ開発経験があるはずです。

また、今ではクラウドを徹底的に活用することで、開発者がゲームを面白くする、快適に遊んで頂くというところに集中できるようになりました。

最後に

ということで、お時間を戴いてしまいましたが移行したサーバーが年始年末も安定して動作しており胸をなで下ろしています。

今年も何かとあるかとは思いますが、何卒宜しくお願い致します。

そして、ディライトワークスはエンジニアを積極的に採用中です。

もしご興味があればお気軽にご応募ください。

オブジェクト指向は衰退しますか?

最近はGolangをさわり始めている磯波です。

IT業界やゲーム業界でもオブジェクト指向が持てはやされた時期がありました。

ファイナルファンタジーIからファイナルファンタジーIIIまでを開発していた天才プログラマ、ナーシャ・ジベリさんがファミコン上でのアセンブリでオブジェクト指向を用いていたなどという逸話もあります。

アセンブリが全盛であったころは難しかったものの、ハードウェアの進歩はめざましくゲーム業界でもC言語やC++を用いたオブジェクト指向プログラミングが盛んにおこなわれてきました。

昔はメモリ食いで実行も遅いということで嫌われていたんですけど、時代は変わるものです。

オブジェクト指向=クラス

オブジェクト指向とは「振る舞い」であるという話を聴いたことはないでしょうか?

確かにオブジェクト指向言語と呼ばれるものはクラスベースで開発されているものが多いです。

クラスが存在しないJavaScriptやLuaのような言語はプロトタイプベースではありますが、プロトタイプを用いた擬似的なクラスのようなものをつかってオブジェクト指向を実現します。

では、クラスやプロトタイプという概念がないGolangはオブジェクト指向言語ではないのでしょうか?

インターフェイスで会話をすること

代わりにGolangはインターフェイスという仕組みを持っています。

これはまさしく「振る舞い」の為の機能です。

ダックタイピングという言葉を聞いたことがないでしょうか?

「もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである("If it walks like a duck and quacks like a duck, it must be a duck")」という意味です。

「それ」(=オブジェクト)が、アヒルのように歩き、アヒルのように鳴けるのであれば、例え腕が4本あろうと、足が8本だろうと、双頭であろうとアヒルとして扱っても良いという意味です。

プログラムの用語に置き換えるのなら、「インターフェイス」が適切に実装されているのであれば、どんなものもアヒルのように振る舞うことができる、という意味です。

この例であれば、「歩く」と「鳴く」ということが出来るのが「アヒル」としたとき、その2つが「適切に」行えるマンティコアが渡されても実行できるという意味です。

ideone、なかなか便利なので良かったらためしてみて下さい。

これだとマンティコアがアヒルのように歩いたり鳴いたりすることがわかると思います。

Golangという言語

長い間CやC++を使ってきた人間からすると、Golangはなかなか愉快な言語です。

今までの言語とは明確に違った特徴を持ちながらも、どこか懐かしさすら憶える言語です。

それでいて、コンパイルできる言語ですから速度的にもスクリプト言語に比べて非常に有利でかつ、マルチプラットフォームで動作します。

簡単なツールをつくるのであれば十分な実力を持っている言語だと思います。

良かったら皆さんも触ってみて下さい。