CEDEC 2017 セガグループセッション紹介

皆さんこんにちは!
セガゲームス、開発サポート部の麓です。

このSEGA Tech BlogもCEDECの記事が2回めとなり、オープンより1年経過しました。
月日の流れの速さを感じ、技術の発展の速さに目まぐるしさも感じる今日このごろです。

皆様にとってこの一年、どんな時間を過ごされたのでしょうか?
さて、いよいよ来週に迫ったゲーム業界最大のカンファレンス
CEDEC 2017 会期:2017年8月30日(水)~9月1日(金)
ですが、今年もセガグループからも多く登壇することになっています。
今年はCEDEC登壇者及びセッションを紹介に加えて、ここでしか見れない講演内容の見どころと、当日の資料からの抜粋を一部の講演者から頂いてますのであわせて紹介していきます。



Technical Artist Bootcamp 2017 vol.1 「Automation for TA」(前半)

セッションの内容

「TA育成チュートリアル:自動化」をテーマにTAに必要な知識の学習
1.「プログラマに頼らず使えるようになる。Jenkinsを使ったTA向け自動化入門」
プログラマがいつも便利に使っているJenkins。TA(を目指す)方ならアレをうまく使ってデザイン作業の自動化もできないかと考えた事はないでしょうか。本セッションではできるだけ難しい言葉を使わずに、受講者が自分でJenkins環境を作って自動化できるようになる手順を説明します。
株式会社セガゲームス 開発技術部 ビルドエンジニア 粉川 貴至 他
8月30日(水) 11:20〜12:20

資料スナップショット

f:id:sgtech:20170821143947j:plain:w250 f:id:sgtech:20170821143942j:plain:w250

講演内容についてのコメント

「プログラマに頼らず使えるようになる。Jenkinsを使ったTA向け自動化入門」という事で、普段TAの方々が携わっているDCCツール周りの作業の自動化をJenkinsにやらせてみるための入門講義です。
せっかくのブートキャンプなので、当日はデモをお見せしながら実際に動かすところを中心にレクチャーする予定です!



無料で始める!「龍が如く」を面白くするための高速デバッグログ分析と自動化

セッションの内容

ゲーム開発では、テストプレイやツール使用中等、様々な状況でログが発生します。
本セッションでは、「龍が如く6 命の詩。」の開発期に発生する
デバッグログ(Printf出力したものやゲームプレイログを含む)を、
オープンソースの組み合わせ(Fluentd + Elasticsearch + Kibana)により収集・蓄積・分析し、
オートテスト(自動プレイテスト)、Jenkins、Redmine等と連携することで、
開発とテストのコストを削減し、ゲームの品質や面白さの向上につなげた事例についてご紹介いたします。
株式会社セガゲームス 第1CSスタジオ リードプログラマー 阪上 直樹
8月31日(木) 11:20〜12:20

資料スナップショット

f:id:sgtech:20170821141552p:plain:w250 f:id:sgtech:20170821141543p:plain:w250

講演内容についてのコメント

ゲーム開発におけるログ分析と自動化は、各社様々な創意工夫をされていると思います。
本セッションでは、コンシューマかつシングルプレイが主体のゲームでも、開発期のデバッグログを集めて分析し、自動化と組み合わせることで、ゲームのクオリティアップに貢献できた事例をご紹介いたします。
帰ったらウチでも試してみようと感じていただけるような講演を目指して鋭意準備を進めておりますので、お気軽に聞きに来ていただけると嬉しいです。



高速「体験」を生み出すレベルデザイン ~ソニックフォースの「セット」手法~

セッションの内容

レベルデザインは、プレイヤーを観察しながら調整を続けていくことが必要ですが、ポイントを押さえずに調整を続けても全く良くなっていきません。
本セッションでは、2017年冬発売予定のソニックシリーズ最新作「ソニックフォース」(アクションゲーム)の「セット」(ステージ内にオブジェクトを配置する作業)を例に、レベルデザインを行なう上でのポイントと検証改善の過程をご紹介します。
株式会社セガゲームス コンシューマーコンテンツ事業部 第2CSスタジオ プランナー 神谷 聖子
9月1日(金) 16:30〜16:55

資料スナップショット

f:id:sgtech:20170821123922j:plain:w250 f:id:sgtech:20170824164456j:plain:w250

講演内容についてのコメント

アクションゲームのステージのオブジェクトの配置について話をしようと思います。どんなことを考えながら調整しているのかを、動画を使いながら丁寧に説明していきますのでどなたでもお気軽にお越しください!!



若手テクニカルアーティストの業務効率改善への貢献、育成について話すラウンドテーブル

セッションの内容

年々需要が高まってきたテクニカルアーティスト(以下、TA)としての業務効率化。
しかし、TAは技術的な興味や知識も必要とされ、そのため一般的には経験を積んだアーティストもしくはプログラマーの中から、さらに素養が有った場合の人がなる、というレアケースが多いと聞きます。

若手もしくは新人からTAとして業務をし、業務改善や効率化への貢献は出来ないのでしょうか。TAを育てていくという考えに繋げていくことは出来ないでしょうか。

登壇者として名前を挙げているのは、新卒ながらTAとして業務経験を積んだ2人です。その経験をサンプルケースとして、ラウンドテーブル形式で参加者の方々と議論を交わしましょう。

TAとして求められる業務に若手のうちから参加していくことによる業務改善と、それによりTAを育成していく可能性を生み出し、業界への貢献につなげられる事を目標とします。
株式会社セガゲームス オンラインコンテンツ事業部 開発サポート部 エンジニア 清水 宣寿 他
8月30日(水) 16:30〜17:30

資料スナップショット

f:id:sgtech:20170821194804p:plain:w250

講演内容についてのコメント

本セッションは、当日会場に来てくださった参加者の皆様と共に議論を交わし合うラウンドテーブル形式のセッションです。
若手や新人にテクニカルアーティスト業務ができるのか、テクニカルアーティストの育成には何が必要か、
といった内容について、共に話し合いましょう。
皆様のご参加をお待ちしています。



GameVFX Bootcamp 2017 ゲームエフェクトの今を4つの視点から

セッションの内容

ハードウェアとプログラム技術の進歩がもたらす表現力の向上により、ゲームのビジュアルを強化するVFX(エフェクト)の重要性は増し続けています。
フォトリアルを追及するもの、差別化のため独自のビジュアルを突き詰めるものなど、多種多様のタイトルがさまざまなプラットフォーム上で進化を続け、目指す表現に最適なエフェクトを突き詰めるため多くのアーティストが試行錯誤を続けています。
その中で、希少性・専門性から他に比べて共有されることの少ないエフェクト制作の現状を「アーケード」「モバイル」「コンシューマ」そして「教育」の4つの側面から切り取ります
・ゲーム全体のビジュアルにおいてエフェクトがどうあるべきか、ディレクションの観点から(マジシャンズ・デッド他)
・少人数で複数のモバイルPJを開発する際の人員管理フロー、並行してR&Dを行うノウハウ、Unity環境での効率化の実態(セガネットワークス)
・最新コンソール向けタイトルにおけるエフェクト作業の全容とそのポストモーテム(龍が如く6 命の詩。)
・ゲームにおけるエフェクト制作を理解し、その技術を身に着けるための教育(実際の現場における社内研修用資料を例に)
などを通し、2017年におけるゲームエフェクトの現状を多面的に理解し、学ぶためのセッションになっております。
株式会社セガゲームス CSOLカンパニー 第一CSスタジオ リードアーティスト 岩出 敬
株式会社セガゲームス ゲーム&デジタルサービス統括本部 IP&ゲーム事業部 開発統括部 アート&デザイン部 リードデザイナー 綿貫 正 他
8月30日(水) 14:50〜17:30

資料スナップショット

f:id:sgtech:20170824122843p:plain:w250

講演内容についてのコメント

ゲームにおけるVFX=Visual Effectsは、映画などのそれ(爆発など)だけでなく、爽快感を増すための演出(ヒットマークや軌跡)や、ルールを表すための記号(属性効果)など、様々な役割があります。
このセッションではそんなエフェクトを作る担当者が集まり、アーケード、モバイル、家庭用それぞれで磨かれてきたノウハウを共有します。
普段あまり話される事がないGameVFXの裏側を楽しんで頂けたら幸いです。




スマホゲームで物語を更新し続けること。4年間のストーリー制作コンセプトの変遷をファクトに重ねて

セッションの内容

昨年のセッション「スマホゲームにおけるゲーム性と物語性の“運用で摩耗しない”基礎設計手法~チェインクロニクル3年の運用と開発の事例を交えて~」に対して、モバイルゲームにおける物語について、より突っ込んだ話を、可能ならば実績データを交えて、という声を多く頂きましたので、そのセッションを行わせていただきます。4年間、同タイトルで物語に立てたコンセプトに、どのような結果が返ってきて、そこにどんな対応を行っていったか、その変遷を追っていきます。4年という長さで運営していることによる物語運用の知見、そして物語という作家性の強いコンテンツを運営において大切な「事実に基づく(ファクトベース)の対応」にどう結び付けるかの指針が提示できればと思います。
株式会社セガ・インタラクティブ モバイルインタラクティブ研究開発部 部長 松永 純
8月30日(水) 14:50〜15:50




これからのeSportsへの取り組み ~大会実況システムの開発と運用を通して得られた知見~

セッションの内容

本セッションでは、年間通して多数の大会を開催するセガ・インタラクティブにおける大会運営に関する独自の取り組みをご紹介します。

ゲーム大会はその性質上、上級者が集まるため、高レベルなプレイングやコアなファンとの交流が生まれる一方で、ゲーム初心者や未プレイのお客様にはわかりにくいものになってしまうリスクがあります。そこでセガ・インタラクティブではその解決方法として大会実況システムを開発し、これに対応いたしました。

この大会実況システムを使用した弊社アーケードゲームの大会運営や、社内ゲーム大会運営を通して得られた経験を元に、お客様にイベントを楽しんでいただくための技術的な課題解決のプロセスの紹介や、ショービジネスとしてのeSports運営に活かすべき知見、そして弊社の大会運営システムの機能について実施例の映像を交えて解説いたします。
株式会社セガ・インタラクティブ 第一研究開発本部 野口 洋介
株式会社セガ・インタラクティブ 第一研究開発本部 チーフプログラマ 山本 宗平
8月31日(木) 10:30〜10:55

資料スナップショット

f:id:sgtech:20170822205741j:plain:w250 f:id:sgtech:20170822205735j:plain:w250

講演内容についてのコメント

弊社ゲーム大会で運用しているゲーム大会実況システム、運用を始めてかれこれ2年となりました。
システム開発の経緯から、これまでの運用で得られた知見などをこの機会にご説明できればと考えています。
ゲーム実況放送やゲームイベントに興味のある方はどなたでもお気軽にお越しください。




[芸術科学会(Nicograph)×CEDECコラボセッション] 芸術と科学の融合とTechnical Artist

セッションの内容

近年、コンピュータエンタテインメント業界では高い技術力と表現力を必要とするため、テクニカルアーティスト、テクニカルディレクタの需要がますます高まっています。この分野では,芸術と科学の双方を理解し,それを制作のパイプラインの中で実現していく,人材が求められます.また,Siggraphなどのアカデミックな世界でのCGの研究成果を理解し,それらを応用し作品の中で利用していく能力が求められます.
本セッションでは,古くから芸術と科学との融合領域を対象に活動する芸術科学会から,この領域の研究と人材育成の先端にいる教員と,ゲーム開発の最前線のパネラーを招き,パネルディスカッション形式で実施します.「いかにしてテクニカルアーティストの人材を育成するか」と「最先端の表現技術の研究とその応用」の視点で,学術界と産業界とともに考える場とします.

※ 本招待セッションは、芸術科学会(Nicograph)とのコラボレーション企画セッションとなります。
芸術科学会の公式サイト: http://www.art-science.org/
株式会社セガゲームス オンラインコンテンツ事業部 開発サポート部 麓 一博 他
8月30日(水) 17:50〜18:50

講演内容についてのコメント

パネルディスカッション形式のこのセッションでは芸術科学会や各分野の先生方や、新進気鋭のゲーム会社の代表の方交え、実際にテクニカルアーティストとして働き、CEDECでもTAラウンドテーブルやTAブートキャンプを企画してきた麓の視点からお話をさせていただき、考える場になればと願っています。






気になるセッションはありましたでしょうか?
それでは8月末と9月初日はパシフィコ横浜 会議センター(神奈川県横浜市西区みなとみらい)で会いましょう!

将来CEDECに登壇してみたいと思っている方。
技術力豊かな、オープンで楽しいゲーム会社で働いてみませんか?
興味を持った人は以下にアクセスしてみて下さい!

採用情報|株式会社セガゲームス -【SEGA Games Co., Ltd.】

採用情報|株式会社セガ・インタラクティブ




※複数社登壇の場合でもセガの社員のみ表記しています

セガ新人日記を別ブログにて新規開設しました!

はじめまして!

セガ・インタラクティブ新人、プランナーのYです!



新入社員として会社に入ったばかりの時に

どんな研修を受けているのか興味はありませんか?

部によって様々な研修のスタイルがあるのですが

今回は、我々セガインタラクティブの第一研究開発本部の

新人研修の様子を紹介させていただきたいと思います!

実は!私たち新人でブログを立ち上げました!!!

このブログでは、特に「プランナー」の研修って何するの?っていうところと

ゲーム制作研修の様子をお伝えします!

バナーも私たちがつくっちゃいました!笑
sgtech:20170807171921p:plain

こちらのブログで紹介させていただきます!!!!

※技術ブログではありません

めったに出てこないセガの開発者の話を聞けるかも・・・?

セガの一員として研修の様子を精一杯お伝えいたしますので

皆様、宜しくお願い致します!

まだまだ入社したばかりですが、色々なことにチャレンジできる会社です!

セガのモノ創りを体験してみたい方など、もしご興味持たれましたら、

弊社インターンシップサイトをご確認下さいね!

http://sega.co.jp/info/internship/ 

セガ新人日記もよろしくお願い致します!

デザインデータを共有しよう

セガゲームス、第1CSスタジオ テクニカルアーティストの熊です。
いつもはデザイナーが扱うDCCツール(PhotoshopやMayaなど)のスクリプトを書いたり、プログラマーとデザイナーの仲介役などやっています。
2年ほど前までは背景デザイナーとして普通にデザイン作業をモリモリやっていたんですが、ある日突然コーディングに興味が沸いて今ではPythonやJavascriptをモリモリ書いてます。
そんな経緯なので、プログラマーさんほど書けるわけでもないけど、デザイナーでもない。中途半端な立ち位置で毎日楽しくお仕事させてもらっています。

今日は今まで作った数あるスクリプトの中から一つ、デザインデータの共有ツールをご紹介します。

デザインデータの共有ツールとは?

ここでいうデザインデータというのは、簡単に言うと椅子とか車とかのアセットと呼ばれる部品(パーツ)の事です。
こういうパーツをデザイナーの方がコツコツと作り、部屋や街のステージに配置していきます。
このパーツをデザイナーみんなで簡単に共有出来たら楽だなぁ~と思って、このツールを作りました。


そもそもなぜ必要?

大規模なプロジェクトは、外部開発会社さんも含めるとかなりの人数です。
この人数で一日に作られるデザインデータの数は相当なもので、
誰が何を作ったかを把握する事はもう、ほとんど不可能です。

そうなると、他のデザイナーが並行して制作したパーツや、すでに作ってあるパーツを探せず、同じようなものを個々で作ってしまって、無駄に時間使っちゃった。という事がよく起きるんです。
この時間のロスが多くなるとスケジュールが遅れたり、最悪、製作費の肥大化の原因になっちゃいます。

こういう無駄を防ぐ為にデザインデータの共有ツールは必須なのです。


共有ツール『K_Parts_Studio』紹介!

私が作った共有ツール『K_Parts_Studio』をご紹介します。


f:id:sgtech:20170721201800j:plain:w600


このツールを制作するに当たって、いくつかコンセプトがありました。

・パーツの登録、修正、利用が簡単で直感的あること
・検索方法が豊富であること
・起動が速いこと
・絶対に間違った登録が出来ないようにすること
・とにかくシンプルであること



まずはサクッと使い方を紹介します


1.モデルを用意

f:id:sgtech:20170721202005j:plain

まずはモデルを用意します。


2.フォルダ名、ファイル名、タグ、説明の欄に記入

f:id:sgtech:20170721201932j:plain

次に項目に必要な情報を記入します。
これで登録に必要な作業は終わりました!


3.登録!

f:id:sgtech:20170721201915j:plain

登録すると、全自動で登録作業が行われます。


4.登録されたパーツを確認

f:id:sgtech:20170721201846j:plain

ちゃんとスクリーンショットが撮られて登録されていれば成功です。


5.スクリーンショット画像をクリックしてシーンにインポート

f:id:sgtech:20170721201846j:plain

シーンにインポートします。
リファレンスとかで持ってくる事が出来ます。


6.あとは自由に配置

f:id:sgtech:20170721201829j:plain

一連の流れはこんな感じです。
登録から利用までスムーズに行う事が出来ました!



パーツの登録、修正、利用が簡単で直感的あること

特に登録の部分が非常に大事です。
デザイナーがめんどくさいと感じた瞬間に登録がされなくなります。
登録がされないと利用されなくなり、すぐにツールがゴミ箱行きになっちゃいます。

まずは登録が簡単であること。
これは絶対に外せません。

これを実現する為にさまざまな情報を自動取得させて、デザイナーが登録時に必要な作業は

・フォルダ名
・ファイル名
・タグ付け
・説明

のみとなりました。
このくらいであればそんなに負担になりませんね。

f:id:sgtech:20170721203202j:plain



検索方法が豊富であること

検索がちゃんと実装されていないと、これもまた誰も使わなくなります。
ツールを作る時、自分でめんどくさいと感じた事はみんな同じように感じています。
まずは、自分がこれ簡単で便利~♪と思えるレベルまで持っていく事が大事だと思います。
検索機能にしても、こういう検索出来ないのかなぁ?と思ったら
どんなに大変でも実装するべきです
今回は登録したすべてのキーワードでの検索とタグ検索(複数可)を実装しました。

f:id:masashi_kuma:20170718204337j:plain



起動が速いこと

起動の速さもまた大事です。
レスポンスの良いツールはストレスが少なく、利用されやすくなります。
非常に大事ですね。



絶対に間違った登録が出来ないようにすること

間違ったデータを登録しようとするとエラーになり、修正方法をメッセージで誘導します。
何が間違ったのか? 何を修正すればいいのか?
これを明示的に指示する事で大きなミスは格段に減ります。
例外に対するケアも非常に大事な要素です。



とにかくシンプルであること

こういう統合ツールは非常に機能が多くなり、煩雑になりがちです。
ですが、手軽に使ってもらうにはシンプルである事が最重要となります。
表向きシンプルでありながらも、内部は複雑な関数の塊という形が理想ですね。
ボタンの数や配置に気を遣う必要があります。
ユーザビリティを大事に。

(とは言っても、やはりボタン数は多くなりがちです・・・)

f:id:sgtech:20170721203138j:plain

モード切り替えの際など、今の状態を一目で分かるようにUIカラーを変更しています。



使う人の気持ちを考える

このツールを作った時、一番に考えたのはインターフェースの見やすさや使いやすさでした。
デザイナーの作業というのは非常に複雑で、日々さまざまなツールの機能を利用して一つの絵を完成させていきます。
単に作業しているだけでも大変なのに、そこにさらに複雑なルールや膨大な数のボタン群を見せられても、ウンザリするだけです。
テクニカルアーティストというのはデザイナーとプログラマーの気持ちを理解出来る唯一の存在です。
いかに複雑なシステムをデザイナーが扱いやすい構成に落とし込めるかが課題になります。

たくさんの機能を搭載するかではなく、どれだけシンプルな構成に出来るかを重要視する事が大事です。



コミュニケーションは大事

ここまで書くと、ずっとPCに向かって黙々とコーディングしているように思えますが、
実はけっこうな頻度で仕様についての話し合いや情報交換をしています。
丸一日ずっと仕様決めの為に色々な人と話す事もあります。
誰が何の作業で困っているのか?昨日までの仕様は変わっていないのか?というのをしっかりと把握していないと、
頼まれたツールが完成した頃にはもう、必要なくなっていた・・・。
なんて悲しい事になってしまいます。

テクニカルアーティストって、コミュニケーション能力も大事なんです♪



まとめ

というわけで、一通りツールの説明からツールを作る時に心掛けている所などを書かせていただきました。
書きながら今までの仕事を振り返っていたんですが、やはり、周りのデザイナーの皆さんの協力があったからこそ、いくつものツールが完成してきたんだと感じました。

テクニカルアーティストの仕事は多岐に渡りますが、デザイナーとプログラマーの間を行き来出来るちょっと面白い立場です。
デザインをロジカルに考えることが出来る方や、毎日新しい課題に取り組むのが好きな方はきっと、楽しめると思います。

こんな仕事してみたい!と思っていただける方がいましたら、ぜひ一緒に働きましょう!


ご興味を持たれましたら、弊社グループ採用サイトをご確認ください
採用情報|株式会社セガゲームス -【SEGA Games Co., Ltd.】

WebGLでレイトレしてゲームを作ってみた

すべての色をつなげよう WHOLE MATCH PUZZLE

操作方法

 マウスのドラッグ(タッチパネルの場合はスライド)で玉を一列横か縦にスライドさせることが出来ます。

ルール

 同じ色同士ですべての玉をつなげると一面クリアです。そのとき100点が加算されます。

20170620164101
ひとつの解答例。赤は赤同士、青は青同士、上下左右どこかでつながっていればよい。

 クリアするたびに色が増えていき最大で5色まで難易度が上がります。
 パズルの完成度(パーセント)がスコアの下2桁になります。
 2分の制限時間内で可能な限り玉を消して高得点を狙ってください。
 目指せ1000点!

※最新のfirefoxとchromeで動作を確認しています。
 また、一部のスマホでも動作を確認しています。

結果をツイート
タイトルに戻る

はじめに

 ドーモ、セガゲームスは開発技術部所属の栃木と申します。
 業務ではライブラリの制作や絵周りのことでコードを書いていることが多いです。
 今回は、タイトルの通り、WebGLでレイトレをしてゲームを作ってみました。

目次

  • WebGLとは
  • レイトレとは(CG初心者対象)
  • ゲームを作ってみた(ゲームを作ってみたい人対象)

WebGLとは

20170620164051 ブラウザ上で動作するOpenGLのことです。このブログを読むような方は見聞きしたことがあるのではないでしょうか。
 今回はWebGLをつかうことでレイトレをGPUで高速に動作させています。 

レイトレとは

 Ray Tracing(レイトレーシング)の略です。レイトレーシングとはレイ(光線)を投げて当たったところの色を取ることでCGをレンダリングする手法です。
 レイトレはひたすらレイを投げて当たり判定を取るだけでそれっぽい絵が出来るので、CG入門としてはおすすめな手法です。透視変換行列を必要としませんし、シャドウマップも必要もありませんし、環境マップも必要ありません。すべてレイを投げることで解決します。
 ただどういうふうにレイを投げるかで出来上がってくる絵が変わってきます。
 「CGを学びたい」けど「DirectXやOpenGLがよくわからない」、けど「Unityまでいくといじれる所が少ない(どこをいじっていいかわからない)」と感じる人は、いっそそういったグラフィクスライブラリやゲームエンジンを使用せずに、CPUでレイトレーシングを書くと幸せになれるかもしれません。
 レイトレースの第一歩はライティングされていない単色の球を1個書いてみるところからです。
 まず目とスクリーンと球を規定します。球はスクリーンに収まるように配置しましょう。スクリーンはあらかじめ適当な色でクリアーしておきましょう。
 そして、目からスクリーンのピクセルの位置に対してレイ(直線)を投げます。あとはその直線と球の当たり判定をとって、当たっていたら球の色を描きます。これをすべてのピクセルで繰り返します。レイトレースの完成です。あとはこれをいろいろと拡張していくだけでいいのです。

20170620164057
目からスクリーンにレイを飛ばしまくる。

 ね?簡単でしょ?

 以下のサンプルコードは、レイトレースをLambertのライティングまで拡張したものになります。ボタンを押すと結果が描画されます。(このサンプルコードではCPUのみでレイトレースしています。)

function raytrace() 
{
    // 各種便利関数
    function setVec3( v, x, y, z )
    {
        v[0] = x; v[1] = y; v[2] = z;
    }
    function minus( a, b )
    {
        var ret = new Array(3);
        ret[0] = a[0] - b[0];
        ret[1] = a[1] - b[1];
        ret[2] = a[2] - b[2];
        return ret;
    }
    function dot( a, b )
    {
        return a[0]*b[0]+a[1]*b[1]+a[2]*b[2];
    }
    function mad( a, m, b )
    {
        var ret = new Array(3);
        ret[0] = a[0] * m + b[0];
        ret[1] = a[1] * m + b[1];
        ret[2] = a[2] * m + b[2];
        return ret;
    }
    function length( v )
    {
        return Math.sqrt( dot(v,v) );
    }
    function normalize( v )
    {
        var len = length( v );
        v[0] /= len;
        v[1] /= len;
        v[2] /= len;
    }

    // キャンバス取得
    var elem = document.getElementById("raytracesample");
    var canvas = elem.getContext( "2d" );
    
    // クリア
    canvas.fillStyle = "rgb(64,160,255)";
    canvas.fillRect(0,0,256,256);

    // 目の場所は( 0, 0, 128 )
    var eye = new Array(3);
    setVec3( eye, 0, 0, 128 );
    
    // 球の場所は( 0, 0, -64 )、大きさは32
    var sphere = new Array(3);
    setVec3( sphere, 0, 0, -64 );
    var spheresize = 32;

    // 平行光
    var dlight = new Array(3);
    setVec3( dlight, 1, 2, 2 );
    normalize( dlight );
 
    // ピクセル数レイを飛ばす
    var ray = new Array(3);
    var screen = new Array(3);
    for( var y = 0; y < 256; ++y )
    {
        for( var x = 0; x < 256; ++x )
        {
            // スクリーンは(-31.5,-31.5,0)-(+31.5,+31.5,0)のXY平面
            setVec3( screen, x*0.25 - 31.5, 31.5 - y*0.25, 0 ); // ピクセルに対するスクリーン位置

            // 目からスクリーンへのベクトルをレイとする
            ray = minus( screen, eye ); 
            normalize( ray ); // 正規化

            // レイと球の当たり判定
            var v = minus( sphere, eye );
            var d = dot( v, ray );
            if( d > 0.0 )
            {
                var p = mad( ray, d, eye );
                v = minus( sphere, p );
                var len = length( v );
                if( len < spheresize ) 
                {
                    // 球に当たったので各種情報を求める
                    len = len / spheresize;
                    d = Math.sqrt(-len*len + 1.0*1.0) * spheresize;
                    // 衝突座標
                    p = mad( ray ,-d, p ); 
                    // 法線
                    var nrm = minus( p, sphere ); 
                    normalize( nrm );
                    
                    // ライティング
                    d = Math.max( dot( nrm, dlight ), 0 );
                    
                    // 結果を描画
                    var col = Math.floor(255*d);
                    canvas.fillStyle = "rgb("+col+","+col+","+col+")";
                    canvas.fillRect( x, y, 1, 1 ); // 点を打つ機能がないのでfillRectで代用
                }
            }
        }
    }
}


 この程度の短いコードから始められるのがレイトレのいいところです。
 ちなみに、今回のゲームのレイトレでは、球16個、無限平面5面、魚眼、直接光(LambertとGGX、および直接光への遮蔽(影))、鏡面反射、自己発光、まで拡張したものをGPUで動作するようシェーダーで実装しています。
20170620164046興味がある方は、このページを右クリックしてソースを表示でコードを確認できますので覗いてみてください。
 頂点入力から頂点シェーダー(とフラグメントシェーダーの先頭)でレイを作成し、フラグメントシェーダーで当たり判定をとりシェーディングをしています。 

ゲームを作ってみた

 今回のゲームを作っていった過程を交えてゲームの作り方を紹介していこうと思います。
 一介のプログラマーの作り方の紹介なので、こういう作り方の人もいるんだなぐらいの温度感で読んでください。
 同人ソフトやGameJamなどでのゲームの作り方の参考の一つにでもなれば幸いと考えています。

手段の選択

 なんらかのソフトウェアを作れる手段が必要です。
 それは”プログラムを書ける”でもいいですし、”Unityを使える”でもかまいませんし、”RPGツクールがさわれる”でもかまいません。
 それが出来るのがあなたである必要もありませんが、他人に無理強いはやめましょう。
 いっそ、ゲームが作りたいという理由から、これらを学ぶというのもよいと思います。ゲームを作りたいという動機は、学ぶ原動力として大きく働くと思います。

 今回は、ブログに直接プレイできる形で載せたかったため、HTML5+Javascriptを選択しました。

ルールを考える

 とにもかくにも、ルールを考えなければ何も出来ません。
 「何を作りたいのか?」「何が出来るのか?」「ジャンルは何にするのか?」
 今回は私一人で作ったため、悩むことは少なかったですが、時間や予算、自分の技術力、チームで作る場合はチームの力量を踏まえて何がどこまで作れるかをあらかじめ想像しておかなければいけません。
 たとえば、無限のお金と時間があればだれでもAAA級タイトルを目指せるわけですが、現実に無限な資源など存在しないわけです。

20170620164041今回は技術ブログに掲載するということで、技術的にレイトレースを使うということは決めていました。
 そして、レイトレースの鏡面反射を正確に表現できるという特徴を利用するために、パズルゲームのルールを考えたのですが……。 

プロトタイプ的なものを作る

 当然といえば当然なのですが、最初に考えたルールが必ずしも面白いとは限りません。
 なので、ゲーム開発初期段階でなんらかのプロトタイプを作ってゲームが面白いかどうか、面白く出来るかどうかをおおよそつかむ必要があります。
 最近ですとゼルダの伝説BotWが初期に2Dプロトタイプを作って新しいゼルダの面白さを提示したというエピソードが話題になりましたが、あそこまでしっかりしたことをするかどうかは別として、なんらかのプロトタイプ的なものを作ることは重要です。

 今回のゲームの場合も、非常に荒削りな状態でゲームのルールだけ確認できるものを最初に用意しました。
 で、最初に思いついたルールを組み込んだプロトタイプをプレイしてみたところ……面白くないことがわかりました。
 最初に考えたパズルゲームのルールはこうでした。

4x4の玉を4面鏡に囲まれた箱の中に配置する。鏡の中も含めて同じ色を8個以上つなげたら消える。合わせ鏡で無限につながったら大きな得点を得られる。連続で消すとチェインボーナス得点を得られる。

 今回公開したものとは似ても似つかないルールです。
 脳内テストプレイでは「お、面白くなりそう。」と思っていたわけですが、実際に実装してプレイしてみたら、これがうーん、つまらない。想定どおり消えるし、得点も得られるけど、つまらない。
 いろいろと原因は考えられましたが、単純にパズルとして考えることが少なすぎるのがつまらなさの最大の原因でした。
 このルールでも解空間を広げることで面白さが出せるのではないかとも考えたのですが、レイトレースで実装することを考えるとオブジェクト数が増えることは処理負荷が増えることに直結しますし、また構想段階からできればスマホで動かしたいという思惑もあり、解空間を増やしての実験は行わずに、根本的にルールを見直すことを考えました。
 まぁ詳しくは省きますが、なんやかんやあって、ある程度面白さを感じられる今のルールに落ち着いたのです。

20170620164220このように、プロトタイプを作ることでつまらないゲームになることを事前にある程度防ぐことが出来るわけです。いうなれば、料理で言うところの”味見”みたいなものですね。
 ここで美味しくなるまで企画をちゃんと練るのが重要だと思います。 

作りこむ

 だいたいの面白さは確保できたら、作りこみフェーズに移行します。

  • グラフィック・BGM・テキストなどの必要なリソースを用意する。
  • タイトルなどのゲーム以外のシーケンスを用意する。
  • ゲームバランスを調整する。
  • エフェクトの追加など見た目を良くする。
  • 逐次、バグがあれば除去する。

 プロトタイプで出来た骨子に肉付けしていくイメージです。
 これを完成するまで続けます。
 ゲームのボリュームに比例して大変な作業となります。
 実際のプロジェクトではここからが作業の本番といえるでしょう。特にグラフィックやBGM、テキストなどのリソースを用意するのは物量を必要とするため一番大変です。
 最初に夢見がちな企画を考えてしまうと、ここであえなくオダブツとなってしまうため、実力と時間にみあった計画をしましょう。

20170620164215今回のゲームは1人で短期間で作るためにゲームの仕様を最小限に止めた為、ここではリソース作成の作業は発生しませんでした。(させませんでした。)
 せいぜい、タイトルやタイムアップ画面などの追加、ハイスコアの保存やゲームバランスの調整、ささやかな演出の追加など、コードの追加実装のみで作業は完結してます。 

完成

 ひと通りできたら完成です。
 完成したら公開することをお勧めします。身内に見せるだけでもいいですが、ネット上に公開したほうがより多くの人の目に付くので良いと思います。いろんな人にプレイしてもらえるだけでもモチベーションがあがります。
 なにより、人にプレイしてもらってこそのゲームなのです。
 同人ゲームだったらコミケに出すのもいいかもしれません。
 また、就職活動でゲーム会社を受けたときに、面接時に「こういうゲームを作りました」というアピールにも使えるでしょう。

20170620164210今作はブログにて公開と相成りました。皆さまプレイはしていただけたでしょうか?得点はいくらほど取れたでしょうか?面白い、楽しいと少しでも感じていただけたでしょうか?得点や感想などをブクマやツイートをしていただけると幸いにございます。 

最後に

 今回は技術ブログでゲームを公開するというチャレンジをしてみたわけですが、技術としては特段変わったことはしていないので、あまり書くことがなかったというのが執筆していてつらかったところです。
 あまり堅苦しいブログになってほしくない、ライトな層にも見ていただきたいという思いからゲームを公開してみようと思い立ったのですが、皆様のこころに少しでもささってくれればうれしいなと思います。

 また、セガでゲーム開発やその周りに携わりたい、もしくは興味があるという方がいらっしゃいましたら、下記の弊社グループ採用サイトをご確認ください。
 いっしょに働きましょう!

採用情報 | セガ企業情報サイト

GameJamで覚えるタスクボード(カンバン)

セガ・インタラクティブ 第三研究開発部 プログラマの石畑と申します。よろしくお願い致します。
今までアーケードゲームのタイトル開発(電脳戦機バーチャロン・シリーズ、デカスリート、パワースマッシュ3、WORLD CLUB Champion Football(WCCF)、CODE OF JOKER(COJ) )を中心に仕事をしております。
最近はマネージャとしての仕事をしつつ、社内アジャイル開発コミュニティの運営も行っております。


今回は、業務の改善に繋げるための見える化を行う手法「タスクボード」についてお話ししてみましょう。


内容は以下の6つになります。

タスクボードは、業務の見える化の代表的な手法として簡単に導入できるのですが、プロジェクトで使おうとすると、そのタスク量の多さから踏み切れないケースも多いです。
そこでGameJamでタスクボードを試しながら、実際のプロジェクト「WCCF」「CODE OF JOKER」に活用していき、その中でも改善を続けていった事例をご紹介します。

見よう見まねでプロジェクトでタスクボードを使い始めたのですが最初はうまくいかず、最初のGameJamでもうまくいかなかったものの、GameJamの回数をこなす毎に洗練され、プロジェクトへの導入、改良を進めることができるようになりました。


実際の時系列では、GameJam → プロジェクト → GameJam → プロジェクト と、交互に行っているのですが、まとまりに配慮してGame Jam、実プロジェクトという順に今回は解説していきます。


それでは1つずつみていきましょう。

タスクボード(カンバン)は、仕事を見える化するツール

皆さんは自分たちの周囲の改善をどのように進めているでしょうか?
改善をするためには、まず問題を明らかにしなければ改善する所自体が見つかりません。


では問題を明らかにする方法にはどんなものがあるでしょうか?
自分達でいろいろ考えても、なかなか何が問題なのかわからないことも多いでしょう。
問題を発見するのに役立つのは、問題だと考えている周辺を「見える化」することです。


見える化」の手法は様々ありますが、仕事の進め方で問題を感じていたならば、タスクボードを使うことで見える化ができます。


タスクボードを使うメリットには、以下のようなものがあります。

  • 残作業が一目瞭然になる
  • 優先順位通りに進められるようになる
  • 誰が何をしているのか見えるようになる
  • 作業の流れが見えるようになる


このように業務が見える化されていけば、問題がどこにあるのか発見することができ、そこから改善を始めることができます。
タスクボードの運営で気をつけることは、業務の見える化により問題は見えるようになりますが、タスクボードは問題の解決方法は示してくれません
見つかった問題を解決する方法を考えるのは、チーム自身です。問題は見える化されて共有されているので、皆で話し合いながら改善していきましょう。


それではタスクボードの使い方の紹介です。

タスクボード(カンバン)の使い方

まずタスクボードとはどんなものかを簡単に説明します。


ここで扱うタスクボードとは、実現したいものを機能そしてタスクに分解し、そのタスクがどのような状態にあるかを「見える化」するツールです。
カンバン、カンバンボード、タスクかんばん、アジャイルかんばんなど、いくつも名称があります。
トヨタ生産方式でのカンバン、システムとしてのカンバン、目的によって使い方も変わるのですが、ここでは「見える化」としてのツールとして使うことについて扱います。


使い方は単純です。
例えばあるゲームを作るとします。
使い方の流れは以下になります。


1. ゲームを作るのに必要な要素、機能をリストアップします。
2. 要素、機能を実現するために必要な作業をタスクとしてリストアップします。

3. ホワイトボードや、模造紙、イーゼルパッドなどに「ToDo」「Doing(In Progress)」「Done」の3つの列を用意します。
 この時に「Done(作業完了)」の定義をしておきます。レビューができる状態になったら、バグがあっても「Done」とする等です。

【付箋の例】
f:id:sgtech:20170522102355j:plain:w300

4. リストアップしたタスクを付箋紙に書いて、「ToDo」の列に貼り付けます。優先順位が高いタスクを上に配置しましょう
f:id:sgtech:20170522102347j:plain:w200

5. 付箋に書かれたタスクに手を付け始めたら、付箋に自分の名前を書いて「Doing」の項目に移動します。
f:id:sgtech:20170522102339j:plain:w300

6. 作業が完了したら(3.で決めた状態)、付箋を「Done」に移動します。

7. 全部「Done」になっていたら、ゲームは完成です。
f:id:sgtech:20170522102330j:plain:w300


上の4,5,7の写真は、2016年7月開催「第九回SEGA Game Jam」で使ったタスクボードです。

タスクボードの作成は作業開始前にやらないといけないものではありません。
プロジェクトの中盤でも終盤でも、また一部のパートだけでも、いつでもどこでもどんな状況でも導入してください。


ゲームを作る際に、皆さんがいつもやっている作業なので難しいことはないはずなのですが、実行しようとするとなかなか難しいものです。
例えば、プリプロ作成の場合だと、(1)の段階でリストアップしきれなかったり、大規模プロジェクトでは、(2)でタスクを全てリストアップすることがあまりに多くて難しいなどです。


私も実際にいきなりプロジェクトにタスクボードを導入できたわけではありません。
タスクの粒度がバラバラだったり、更新頻度が不定期になったりしてうまく活用できていませんでした。
ワークショップや小さいプロジェクトで練習ができないものかと考えて、活用したのがGameJamです。


GameJamとは、短期間で即席チームによりゲームを制作するイベントです。
短期間ですので、結果がすぐにわかりますし、失敗してもダイジョーブ!な安全なイベントなので、実験には最適です。


以下では、私が実際にGameJamでのタスクボードを活用した事例を紹介します。

GameJamでのタスクボード運用例

初回:Global Game Jam 2012
f:id:sgtech:20170522102324j:plain
やってみたこと

  • ToDo 機能リスト作成

最初のGameJamでは、ゲームに必要な機能を付箋にリストアップしていきました。
ただし、粒度がそろわず、タスクに分解できていない項目が多く残りました。

結果としてToDoリストとして使うことはできましたが、作業が未着手なのか、完了したのか共有されておらず、運用している状態ではありませんでした。
最初のタスクボードはここからスタートでした。
振り返り
振り返りでは、タスクに分解する粒度をそろえること、進捗管理の方法が改善点としてあがりました。


2回目:福島GameJam 2012
f:id:sgtech:20170522102524j:plain
f:id:sgtech:20170522102518j:plain:w200f:id:sgtech:20170522102513j:plain:w200f:id:sgtech:20170522102507j:plain:w200
やってみたこと

  • ToDo 機能リストからタスクへ分解
  • Doneの定義(コミットしたらDone)

2回目では、実装する機能をタスクまで分解することでタスクの粒度の問題が改善し、そして完了Doneを意識して付箋をToDo→Doing→Doneと管理して、タスクボードの運用を開始することに成功しました。
ただし、忙しさのあまり終盤で進捗確認の頻度が低くなり、リリース直前に何が入っていて、何が入っていないかわからなくなり、うまく運用したとはいえなくなりました。
振り返り
振り返りでは、どうやって最後まで定期的な進捗管理として機能していくかが課題となりました。


3回目:Global Game Jam 2013
f:id:sgtech:20170522102502j:plain

【マイルストーン】
f:id:sgtech:20170522102633j:plain
やってみたこと

  • マイルストーン設定
  • マイルストーン毎にレビュー会開催

3回目では、マイルストーンを設定し、マイルストーンのタイミングでレビュー会を行い、ここで進捗確認と、次のマイルストーンまでに何を行うかを明確にするように組み合わせてタスクボードを運用することで、定期的に進捗管理のタイミングが生まれ、時間を意識したタスク管理ができるように改善されました。


ここで始めてタスクボードによる運営が成功したといえるでしょう。


4回目以降:Global Game Jam 2017
f:id:sgtech:20170522102626j:plainf:id:sgtech:20170522102619j:plain

【レビュー会】
f:id:sgtech:20170522102610j:plain

やってみたこと

  • 職種別に付箋の色分け
  • 付箋に担当者を記入
  • 付箋にいつまでに終わらせるか期限を記入

4回目以降では、タスクの分解、職種別に色分け、担当者の記入、レビュー会を意識したタスクの割り振りにより、小さな成功を積み重ね、モチベーション維持しながら毎回最後まで運用できるようになっています。


結果として、タスクボードを運用できるようになるまでに3回かかっており、これを実際のプロジェクトで試そうとすると、チャンスを与えてもらえないと何年も改善しないまま進むことになります。
GameJamは短期間でプロジェクトが終わるので、最高に安全な場であり、今回の例のようなタスクボードだけでなく他にもチーム運営、技術などの導入、改善に最適です。
ぜひお試しください。

プロジェクト(WCCF)でのタスクボード運用例

GameJamで練習したら次は、プロジェクトでの活用です。
実際にプロジェクトでの運用をどのように進めていったかの事例を以下に紹介します。

WCCF2010-2011 Ver.2.0
f:id:sgtech:20170522102604j:plain
やってみたこと

  • ネットワークパート内で、1人でテスト
  • ToDo は、タスクではなく実装する機能

プロジェクトでの最初は、ネットワークパート内でタスクの一部を管理するスモールスタートでの導入開始にしました。
ほぼ個人での活用だったため、他の人にはほとんど意識されず、改善にはつながらないタスクボードとなりました。
それでも初回のGameJamの経験があったので、運用の形にはなりました。
振り返り
振り返りとしては、多少なりとも周りを巻き込まないと、見える化の浸透のしようもないことが明確になっています。


WCCF2011-2012
f:id:sgtech:20170522103008j:plain:w200f:id:sgtech:20170522103003j:plain:w200f:id:sgtech:20170522102957j:plain:w200
f:id:sgtech:20170522102951j:plain
やってみたこと

  • エンジニア全体でタスクボード運用の対象にする
  • ToDo は、機能から分解したタスクにまで分解する
  • タスクには、工数を入力する
  • 工数を合計して、バーンダウンチャートを作成

自分が直接関わるエンジニアには、タスクボード運用に参加してもらうように協力をとりつけ、見える化の範囲を広げることができています。
2回目のGameJam経験から、最初から欲しい機能を担当者が作業可能になるところにまでタスクを分解することで、粒度が統一され、タスクボードの運用として改善しております。
この時点で付箋には「工数」が入力されています。
これによりバーンダウンチャートが導入可能になっており、進捗管理に関しては大きく改善することができました。

バーンダウンチャートとは、縦軸に残作業工数、横軸に時間を設定したグラフです。タスクがDoneになったら、その工数の数字分残作業量から減らたところにプロットしていくと、グラフの傾きからマイルストーンまでに作業が消化できるかどうかが明確にすることができます。

ただし、実装内容などの見直すポイントはわかるようになったものの、見直す際の優先順位が明確でなく、結局作業がある程度進んだ後で優先順位を変えることになってしまいました。
振り返り
振り返りとしては、優先順位の再確認の時期をどう設定するか、という改善点が残ることになりました。


WCCF2011-2012 Ver.2.0
f:id:sgtech:20170522102944j:plain:w200f:id:sgtech:20170522103111j:plain:w200f:id:sgtech:20170522103106j:plain:w200
f:id:sgtech:20170522103100j:plain
やってみたこと

  • タスクボードの運用を、プランナー、デザイナーにも広げる
  • 優先順位の確認を2ヶ月に1回実施する

3回目では、バーンダウンチャートと合わせてタスクボードを運用すること、タスクボードをプランナー、デザイナーの分も書き出すことで、プロジェクト運営として全体をコントロールできるように改善しました。
これは3回目のGameJamでの経験から、チーム全体で活用しないと、プロジェクト全体をみていることにならないと気付いたため、全体に適用しています。
優先順位も定期的に確認することで改善しています。
ただし、タスクボードの適用範囲をチーム全体に拡大したため、管理するタスク量がかなり多くなることで目が行き届かなくなり、手戻りが発生するという問題が発生しました。また工数だし時には明確になっていない要素が、作業を始めると予想以上に多く工数が足りなくなり、そのために見送った機能が出ています。
振り返り
振り返りとしては、安定して開発ができるようになったものの、お客様の満足度が向上していない点が改善したいこととしてあげられています。


WCCF2012-2013
f:id:sgtech:20170522103055j:plain
f:id:sgtech:20170522103049j:plain

【レビュー会の様子】
f:id:sgtech:20170522103146j:plain

やってみたこと

  • 工数出しに、プランナー、デザイナーに参加してもらう
  • レビュー会を月に1回実施する

4回目では、工数出しにプランナーにも参加してもらうことして、タスクもれ減少、工数の精度の改善を行っています。
定期的なレビュー会と組み合わせることで、手戻りを減らし、質を高めるように改善することができました。


安定したタスクボードの運営には4回必要としました。
それぞれタスクボードを運用することで見えた問題点について、一歩ずつ解決し続けています。


時系列では、GameJam → プロジェクト → GameJam → プロジェクト と、交互に行っていくことで、タスクボード運用改善のスピードを早くすることにつなげています。
これはWCCFが半年単位で新しいバージョンをリリースしていたので、改善のチャンスが多かったことはタイミング良く導入できたことに繋がったと考えています。

他のプロジェクトでのタスクボードの運用について

WCCFの例が完成形ではありません。プロジェクトが変われば、運用方法もプロジェクト毎に変わります。
例えばCOJでは、今までよりもさらに短期リリースが必要とされたため以下の運用に変更しました。

  • 工数出しにプランナー、グラフィックデザイナーも参加して、よりタスク量、工数の精度を上げる
  • 優先順位の変更の指標にするために、機能毎にToDoを分けて、機能単位の合計工数を書いておく(オレンジと緑)

f:id:sgtech:20170522103143j:plainf:id:sgtech:20170522103137j:plain:w300

これにより、無駄なタスクを減らし、継続的に短期リリースができるような体制を構築しております。

他の例では、以下のような運用もあります。

  • 割り込みタスクを赤い付箋で追加する
  • バグ修正もタスクにして管理する
  • Doneの前に、「レビュー」を入れる

付箋については、Redmineから直接プリンタを使って付箋を作ったりしたこともあります。


自分達のプロジェクトに合わせて、自由に変えられるのがタスクボードの強みです。
ですので、最初はアナログな手書きで始めると、何度も簡単にやり直せるのでおすすめです。

まとめ

タスクボードをGameJamで運用して、プロジェクトに適用することで以下のことがわかりました。

  • タスクボードの使い方は簡単だが、チームに合わせて何度も変更することで安定運用になります。
  • GameJamで試してからプロジェクトに適用すると、失敗のリスクを減らすことができます。
  • タスクボードによる見える化のテスト中でも、問題点は次々に明るみになるので、見える化の効果は高い。

  ただし、タスクボードによって問題点は見えても、問題そのものの解決方法はチーム自身で皆で協力して考えて改善してください。


今回はタスクボードによる業務の見える化について話してみました。
タスクボードの使い方は難しくありませんが、実際の運用には多くの問題が発生してきます。
なぜなら問題点が見えるようになることが、タスクボードを使う目的だからです。


最初からうまくいくはずはありませんし、これが最終形でもありません。
完璧を目指さず、シンプルにはじめ、必要になったら後からいくらでも変えていきましょう。


さあ明日からタスクボード、始めてみましょう!


タスクボードを最初から最後まで一通り試してみたい、という方には短期間でゲーム開発ができて、失敗してもダイジョーブ!な環境、「GameJam」でタスクボードを試してみませんか?
セガグループでは、失敗してもダイジョーブ!な環境、「SEGA Game Jam」を開催しております。
次回、記念すべき「第十回 SEGA Game Jam」は2017年7月15日~16日開催です!


私達、第三研究開発部では、このような取り組みにも積極的な方と一緒に働きたいと考えています。
もしご興味を持たれましたら、弊社グループ採用サイトをご確認ください。

採用情報|株式会社セガ・インタラクティブ
採用情報|株式会社セガゲームス -【SEGA Games Co., Ltd.】


アーケードで稼働中の「WORLD CLUB Champion Football」もよろしくお願い致します!
www.wccf.jp

Powered by はてなブログ