平井 佑樹

さくゲーコンテストを行いました!


こんにちは、新卒エンジニアの平井です。

今年、Aiming では「さくゲーコンテスト」というイベントを行いました。

さくゲーコンテストとは

プロジェクト業務を行っているだけでは、なかなか新しいゲームエンジンなり技術に触れる機会って少なくなると思います。 また、人事や企画や運営やデザイナーなど、非エンジニアの方がゲーム開発の経験があるとすごく相互理解が深まったりしますけど、実際のところ普段の会社生活の上でそういうことができる機会ってなかなか無かったりします。 それらを踏まえて Aiming では、ゲームコンテストを定期的に行うことで、ゲーム開発する機会を積極的に作るようにしています。

前回の様子

第4回Aimingクソゲー開発コンテストを行いました!

今回のゲームコンテストはさくっとゲームを作ってもらうためさくゲーコンテストと題し行いました。テーマは「」です!
こちら大阪スタジオのみ行い、11チームの発表がありました!

会場の様子

応募作品


インクを飛ばし地面に塗り合うゲーム
某インクを塗りあうゲームを理解しようとして開発されたとのこと
通信機能により二人対戦出来るようになっています!
こちら新卒エンジニアが作成しました!


ラブレターを紙飛行機にしてそれを操作しながら女の子に届けるゲーム
Spineの勉強を兼ねてデザイナーが1人で作った作品です!
Unityでプログラミングをするのは初めてというとても開発意欲の高い方でした!

~プレイ画面~


ジャンプして相手を踏んづけた方が勝ちのゲーム
Web上で2人から遊べるようサーバを構築したとのこと
こちらWebエンジニアが1人で作成しました。


社長の椎葉をボールの魔の手から守るゲーム
守りたい人とは何かと考えたとき社長の椎葉が浮かんだとのこと
社長の椎葉の3Dモデルがとても忠実に再現されていましたw

~クリア画面~


画像認識システムを使ってUnityちゃんを守るゲーム
プレイヤーの腕を使って上から落ちてくる赤いオブジェクトをUnityちゃんにぶつからないようにするという発想がとてもユニークな作品でした!
こちら、2018年度の新卒内定者が作成しました


マイクに声をかけて手紙をポストに運ぶゲーム
発表中なかなかポストに入らず、歓声が上がるたびに軌道がずれたりなどとても盛り上がりました!
こちらも内定者が作成しました


結婚式にタイミングよく突撃することで花嫁の心を奪うゲーム
リア充を爆発させつつ自分たちはリア充になれるとのこと
花嫁をさらうのが難しくて発表者もなかなかうまくいきませんでしたw
こちらも内定者が作成しました


Aimingのキャラクターを積み上げていき、落とした人が負けとなるゲーム
最近、流行りのゲームを見習って作ったそうでサーバからすべて自作したとのこと
どこかで見たようなゲームでしたw

 

 

 

 

 

 

 

 

地獄に落ちるネコに魚を当てて天国に送り出すゲーム
おじさんに魚を当ててしまうとゲームオーバーになります
こちらも内定者が制作したのですが
実はこのチームにエンジニアがいなくて
Unityのサンプル2Dシューティングゲームをもとに作ったとのこと
とてもキャラクターが可愛らしい作品でした!


社員を札束でビンタすることでモチベーションを向上させていき資金を増やしていくゲーム
愛社精神をもとに会社をリスペクトして作ったとのこと
こちら私が作成しました
社長の椎葉から狂気に満ちたゲームだと言われましたw

 


こちらチワワが他のチワワと会話して奥に進んでいくゲーム
人事の方が作成しました、なんとその人事の方は社内ゲームコンテストに参加するのは3回目とのこと!
開発意欲がとても高く雰囲気がよく出来ています!

まとめ

今回、新人研修の一環としてさくゲーコンテスト運営をさせていただきました。
難題もありましたが、結果的にエントリー数も上々で意欲作が多かったです。
当日もとても盛り上がり、良いイベントにすることが出来たと思います!

さくゲーコンテストいかがだったでしょうか?
Aimingでは不定期に勉強会やゲーム開発コンテストを行っています。
今回はエンジニアだけではなくプランナー、デザイナーや人事が参加するなど敷居は低くかなり自由な会になりました。応募された作品はどれも個性的なゲームが多く、とても賑わっていました!

以上、さくゲーコンテスト報告でした。

最後に社長賞としてなんと焼肉をごちそうしてくれました!
社長と受賞者で美味しくいただきました!


平井 佑樹

ログレスマップエディタのパフォーマンスを改善したお話


はじめまして、17年度新卒エンジニアの平井です。

今回、新卒エンジニアの平井と西田の二人がパフォーマンス向上のため新たにUnityでマップエディタを開発しました。
その際に改善した点や苦労した点を紹介しようと思います。

マップエディタとは

弊社の「剣と魔法のログレス いにしえの女神」及び「ブラウザ版 剣と魔法のログレス」では、自社GUIツールを使用してマップデータを制作しています。地面タイルの配置や噴水などのオブジェクトを配置するだけでなく、キャラクターが移動できない位置の指定や影の設定など、マップ処理に関する様々な設定も可能です。

~新マップエディタ画面~

ログレスの旧マップエディタは、Adobe AIRで作られています。これは、先に開発されたブラウザ版ログレスがFlashで作られているため、マップ上に配置されたオブジェクトを表示したりアニメーションをしたりするためのコンポーネント群を、ゲームクライアントとマップエディターとで共有ができ、開発効率が高いためです。

旧マップエディタの問題点

旧マップエディタは以下の問題がありました。

  • ファイル読み込みに時間がかかる
  • 描画速度が遅い
  • 弊社でAdobe AIRを使えるエンジニアが少なくメンテナンス性が低い

新マップエディタでは、これらの問題を改善することが目標となります。

Unityで開発した理由

  • 弊社には Unity を使えるエンジニアが多くメンテナンス性が向上できる
  • 弊社が Unity を使った開発を活発に行なっており、情報収集が容易かつノウハウを蓄積できる
  • 新卒エンジニアとして Unity を覚えて基本的な開発方法を知っておきたい、使えるようになっておきたい

今回、Unityのエディタ拡張は行わずツールアプリとして運用します。
Unityのエディタ拡張を使わない理由は、マップデザイナーが新マップエディタを使う際に
旧マップエディタと同じ操作感に近づけるためです。

目標

  • 旧マップエディタの機能を再現
  • パフォーマンス改善

これらの目標を達成するために苦労した部分や工夫した部分を解説していきたいと思います。

旧マップエディタの機能を再現

基本的な配置機能は問題なく実現できました。
しかし、旧マップエディタはFlash固有の機能を使って表現している部分があり、Unityのスプライト標準機能では表現できませんでした。

これを解決するためにUnityのシェーダー機能を使って表現しました。

~マスクブレンド~

~カラーブレンド~

ここまでは順調に開発できましたが、Unityで開発していくにあたってパフォーマンス周りの問題が発生しました。

パフォーマンス改善

  • マップファイルの読み込みに時間がかかる

ログレスの標準のマップは平均で10万個のチップやオブジェクトが配置されています。新マップエディタではUnityのGameObjectを10万個作成すると処理が重くなるため、カメラに映し出される箇所のGameObjectのみ生成し、それ以外はデータだけ保持するようにしました。それにより従来6分かかったマップを1分足らずで展開することが出来ました。

  • 描画速度が遅い

マップを読み込み時にチップやオブジェクト(GameObject)をインスタンス化した際にマテリアルも複製されていたためドローコールが増えていました。そのため、インスタンス化する際、1つのマテリアルでチップやオブジェクトを生成して、そのマテリアルのテクスチャを差し替えることで800ぐらいあったドローコールを20~30にまで削減しました。
さらに、カメラに映し出される部分のみチップを生成し、画面スクロールした際、そのチップのテクスチャのみ変更して最小限のGameObjectで描画できるようにしました。その結果、マップ読み込み時のチップ生成速度や描画速度が向上し、スムーズな視点移動が出来るようになりました。

結果

旧マップエディタでも上記の最適化は行われていましたが、平均で20~30FPSしか出ませんでした。しかし、新マップエディタでは常時60FPSを維持することが出来、描画速度の改善を達成できました。

~カメラに映る画面~

~カメラの範囲外のオブジェクト~

まとめ

旧マップエディタと比べてパフォーマンスが向上し、より快適にマップ制作が出来るようになったと思います。Unityで制作したため今後のメンテナンス性はAdobe AIRと比べてかなり上がり、今後の要望にも迅速に対応できるようになりました。

振り返り

Unityを使ったことによりプロトタイプを早く作成することが出来ました。
処理の最適化をする際にとても苦労しましたが、今思えばどうすれば処理を軽くできるかを試行錯誤して、とても良い経験になったと思います。
マップエディタを作るにあたり、どうすれば使いやすいのかを、もう一人の新卒メンバーの西田さんや先輩と話し合いながら取り組みました。
新マップエディタの制作で得た経験を、今後の業務に活かしていきたいと思っています。

ありがとうございました。


神﨑 拓人

Rails Developers Meetup 2017 で大阪会場の提供を行いました


こんにちは! Aiming ソフトウェアエンジニアの神﨑です。

Aiming は去る12月9日に東京で開催された Rails Developers Meetup 2017 のスタッフ協力及び、弊社エンジニア植森の登壇、そして弊社の大阪スタジオの一部を Rails Developers Meetup 2017 大阪会場 として提供させていただきました。

Rails Developers Meetup とは

Rails Developers Metetup (以下 Railsdm) は「第一線で活躍する開発者・導入企業から、RubyやRailsに関する発想・アプローチ・成功体験・失敗体験を学ぶ非営利勉強会」で、普段は月1回ほどのペースで平日の夜に行われています。

しかし今回の Railsdm は「2017年の最後を締めくくる超拡大版」として、休日の13時から18時までぶっ続けで、 Rails 界隈で有名な方々の発表を聞けるという非常に濃い時間を過ごせる貴重な機会でした。

大阪会場について

今回私は大阪会場の設営と当日のお手伝いをさせていただきました。大阪会場は東京の本会場で行われている発表の中継映像を視聴するもので、いわゆる「ライブビューイング」の形で行っています。こういった有名な方がたくさん登壇されるような勉強会が開催されるのは東京のほうが圧倒的に多いので、中継であってもそういった方々の発表を大阪に居ながらにして聞くことができるのは非常にありがたいことです。

また今回はセッション終了後に大阪会場で懇親会も行いました。東京に比べると小規模なものでしたが、その分参加者の方と密度の高いお話をすることができて非常に面白かったです。

さいごに

今回 Railsdm で発表に登壇していただいた方々、また主催者である平野さんをはじめ、東京・大阪会場のスタッフの方々には貴重なお話を聞ける機会を作っていただきありがとうございました。

Aiming では、新宿駅に近い東京本社及び、大阪駅直結の大阪スタジオの部屋を勉強会会場として積極的に提供を行っていますので、お知り合いの弊社スタッフか弊社公式サイトのお問い合わせまでお気軽に問い合わせください。


菅野 明洋

第4回 Game Gatling LTに登壇してきました!


はじめに

初めての人は初めまして、前回の記事(社内でエンジニア読書会をやってみた!)見てくれてる人こんにちは!
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

今回は、2017年12月9日の土曜日に大阪で開催されました第4回 Game Gatling LTにて、スピーカーとして私と藤井が登壇させていただきましたので、レポートとしてまとめました。

GGLTとは

関西でゲーム開発に携わるエンジニア、デザイナー、プランナー等の人が集まり、ライトニングトークを行うイベントになります。

今回発表させていただいた内容について

今回の発表は、ミドルウェアの性能試験などの話になります。

■菅野明洋:我流ミドルウェア性能・障害試験の心得

■藤井章暢:仕事以外でプログラミングのモチベを上げる方法

私の発表ではミドルウェアの性能試験を中心に発表しました。今回は後進向けの教育を想定した作りにしております。
プロジェクトでミドルウェアを選定する場合、枯れていないミドルウェアを用いると情報が少ないケースが非常に多いと思います。その中で、少しでも多くのノウハウを積むための考えみたいな物をまとめてみました。ミドルウェアを適切に選定や使用できなかった場合は単純に開発・検証する以上のコストがかかるケースが多いため、きちんと精査していきたいと思います。

藤井の発表では、業務外でのプログラミング活動についての話を発表しました。
日々の情報収集などをどのように行うか、通勤途中の時間や休日をどう活かすかなどの実例の紹介になります。業務上で知識を得るのも重要ですが、課外活動や日々の行動改善で知見を得るのも重要かなと思います。
詳しくはスライドをご覧ください。

■発表中の様子

発表中の菅野

発表中の藤井

感想

今回は、登壇だけでは無く運営の参加にも挑戦してみました。
業務を行いながら並行で準備するのは大変でしたが、勉強会の裏側が見れて良い経験ができたと思います。

また、登壇については、やや時間配分を間違えて残りのページを話しきれなかったのが残念でした。次回はそのようなミスが無いようにしていきたいと思います。

最後に

GGLT運営の皆様、会場に来場した方々、登壇の機会を頂きありがとうございました。色々と面白い活動の話や、明日から実践してみようと思えるような話等が聞けて良かったです。
今後も皆様とこのような場で情報交換できると幸いです。


いますぐデュアルキーボードを始めるべき7つの理由と3つの注意点


こんにちは、エンジニアの佐藤です。

突然ですが、みなさんは分割キーボードをご存知でしょうか。
キーボードが真ん中で左右に分かれており、左右のそれぞれの腕に対して自然な位置・角度に設置できるキーボードのことです。

エルゴノミクスの観点からも人気の高い分割キーボードですが、高価であることや種類の少なさなどから導入ハードルは低くありません。

そんな分割キーボードの代替手段としてあるのがデュアルキーボードです。
デュアルキーボードとは、2台のキーボードを左右に並べ、左手で左のキーボード、右手で右のキーボードをタイプするスタイルのことです。

本記事では、弊社でも多くのメンバーが採用しているデュアルキーボードの魅力についてお伝えしたいと思います。

デュアルキーボードの7つの魅力

身体にやさしい

なんといっても分割キーボード自体の魅力である、自然な腕の角度でタイピングできることが最大の利点でしょう。

初期投資がいらない

必要なハードウェアはたったの2つ、キーボードと、キーボードです。

会社に勤めている方なら、デスクには会社支給のキーボードと、私物のキーボードが備わっていることでしょう。
したがって、ハードウェアには一切お金をかけずに始められるということです。


^ 筆者は会社支給の apple wireless keyboard と私物の Majestouch2 という異色の組み合わせだが、問題なく使えている

好きなキーボードでできる

分割キーボードはまだまだ多くの種類が市場に出回っているとは言い難い状況です。
しかしデュアルキーボードなら好みの配列、キースイッチで同等の恩恵を享受できます。


^ ThinkPad キーボード愛用者である山納のデスクには、当然のごとく2台の ThinkPad キーボードが配置されている

設定が簡単である

macOS をお使いの場合、必要なアプリケーションは Karabiner-Elements のみです。
(キーボードを跨いでの修飾キーとの同時押しに必要です)

Windows の場合は、なんと設定は不要です。

スペースバーが2つになる

現実的にどちらの指でも押せる唯一のキー、それがスペースバーです。
リマップによって、左右いずれかのキーボードのスペースバーには違う役割を持たせることも可能になります。

割る必要がない

信じがたいことですが、世の中には自分でキーボードを割って分割キーボードを実現する方もいらっしゃるようです。
そのような手間とリスクをかけなくとも、デュアルキーボードならすぐに分割キーボード同等の環境を手に入れられます。


^ 栗本は薄いキーボードが好きで、市場に出回っている分割キーボードでは要求を満たせないため、デュアルキーボードにしたという

いつでも元に戻せる

もしどうしても慣れないときは、片方のキーボードを脇に寄せるだけで元の環境に戻せます。

デュアルキーボードを始めるときに注意するべき3つのこと

スペースを取る

やはり通常の2倍の面積がキーボードに占領されてしまうことには気をつけないといけません。


^ 根占は片手ゲーミングキーボードとの組み合わせで、1.5倍の面積で実現している

普通のキーボードでタイピングしづらくなる

オープンで自然なスタイルでのタイピングに慣れてしまうと、どうしても普通のキーボードでのタイピングは窮屈に感じてしまいます。

ラップトップで作業することが多い人は、知らない方が幸せな世界かもしれません。

好奇の目で見られがち

市民権を得つつあるデュアルキーボードも、まだ一般的とは言えないのが実情です。
2台のキーボードを同時にタイピングしているようにも見える姿は、同僚からの好奇の眼差しに晒されるかもしれません。

(しかしあなたは、デュアルキーボードがいかに優れているかをその同僚に対して説くべきです!)

さいごに

デュアルキーボードの魅力と注意点について述べてきました。

すでにおわかりのように、導入コストが低く、メリットが大きいのがデュアルキーボードです。
この記事が快適なタイピングのためのヒントになれば、幸いです。

あわせて読みたい: あなたの知らないキーボード拡張の世界


oguma

Aimingインフラチームを支え(てくれてい)る技術と設計(3/3)



この記事を読むのに使用する時間の目安 = 5〜10分

你好!
Magandang hapon po!
こんにちわ! インフラチームの 小熊 です。

前回 から大分時間が経ってしまいましたが、Aimingのインフラ事情をいくつか紹介したいと思います。

TL;DR

必要だと思える時にTDIでインフラ構築をするようにしています。
また、インフラのテストもCIで回すようにしています。
普段はGithubで、その結果とReview commentを見てmergeといった流れになります。
とくに新規性のある内容はありませんが、誰かの何かのヒントになればということで、Tipsなども少し載せます。

本題

TDI

TDI (Test driven infrastructure) = テスト駆動インフラストラクチャ
を指します。

インフラの「品質管理, 事故防止, 安定したリリース管理」を行うため
定義したインフラが適切に動作するかをテストしながら構築していく手法になります。

その考え方自体は古くからあり、以下のようなサイトが参考になります

前回紹介したとおり、弊社ではServerspecを使用しています。

AnsibleやKubernetes など、もともとインフラを定義するもので、さらに重ねてインフラを定義してテストを行う必要はあるのか? という議論もあると思いますが、以下の条件の際は出来る限りテストを書くようにしています。

  • private関数, local変数 のような scopeが限定的なものは基本的にテストしないが、逆にscopeが広い場合
    • Ansibleは基本的にglobal scopeになります
  • roleなどの汎用性を高くしていて組み合わせて利用している上で、それぞれのroleで依存関係もある場合
  • 全てのエラーで停止するわけではなく、楽観的なエラーハンドリングが存在する場合
    • e.g,) Ansibleだと ignore_errors, failed_whenを使っている箇所がある
  • 複数のtoolや環境を組み合わせていて、統合的なテストがしたい場合
    • e.g,) Ansible on the Vagrant, Containers + VM Instances

他にも、重要な箇所で安心感を得るために書いた方が良いときは書くようにしていて、Jenkins等のCIでテストを回すようにしています。

pipelineで全ての環境変数による設定のテストを行い、それで問題を発見した場合はmerge前にfix commit を入れるようにしています。

Serverspec Tips

基本

以下を参考にroleで分けるようにしておくと扱いやすいです。
http://serverspec.org/advanced_tips.html#how-to-use-host-specific-properties

また、一般的ではありますが環境変数で制御するようにすると汎用的に扱えて良いです。
例えば、Jenkins によるテストの場合はどうするとか、タイトルにより特別な設定があるといったこともテストができるようにした方が良いと思います。

Rakefile サンプルコード

require 'rake'
require 'rspec/core/rake_task'
require 'yaml'
require 'highline/import'
require 'json'

unless ENV['ANSIBLE']
ENV['TARGET_HOST_YML'] = ask("Enter servers.yml path (spec/env/servers.yml): ")\
  if ENV['JENKINS_SERVER_COOKIE'].nil?
end
ENV['TARGET_HOST_YML'] = 'spec/env/servers.yml'\
  if ENV['TARGET_HOST_YML'].nil? || ENV['TARGET_HOST_YML'].empty?

desc "Run serverspec to all hosts"
task :spec => 'serverspec:all'

namespace :serverspec do
  properties = YAML.load_file(ENV['TARGET_HOST_YML'])
  task :all => properties.keys.map {|key| 'serverspec:' + key.split('.')[0] }

  properties.keys.each do |key|
    msg_for_test="on Vagrant" if "#{key}" === "wordpress"
    desc "Run serverspec to #{key} #{msg_for_test}"

    RSpec::Core::RakeTask.new(key.to_sym) do |t|

      # 環境変数チェック #########

      # Setされているか検証したい環境変数
      verify_env_vars = %w[PJCODE TARGET_ENV SERVER_NAME]

      # verify_env_vars の環境変数 を使用していないServerspec roles = 環境変数Set有無の検証をしたくないrole
      no_verify_roles = %w[vuls] # このroleは上記の環境変数は使っていないから存在チェックもしない

      properties[key]['roles'].each do |role|
        no_verify_roles.each do |no_verify_role|
          if !role.include?(no_verify_role)
            verify_env_vars.each { |env_var| raise NameError, "環境変数 #{env_var} がセットされていません" if ENV[env_var].nil? }
          end
        end
      end

      ENV['TARGET_HOST'] = key
      t.pattern = 'spec/{' + properties[key]['roles'].join(',') + '}/*_spec.rb'
    end
  end

  properties.values.each do |role|
    json = JSON.load(role.to_json)
    ENV['SERVERSPEC_ROLES'] = json['roles'].to_s
  end
end

Serverspecで、あいまい(範囲)判定がしたいとき

厳密性が必要なく、あいまいな判定にしておきたいときもあると思います。

たとえば、サーバのSpecで自動的に設定される値をテストしたい場合
(e.g,  リソースが異なるサーバが数種類あるけど、計算上は全てこの範囲に収まっていれば問題ない。など)

そのようなときは以下のようにすると判定ができます。

describe command("awk '\$1~/start_servers/{ print \$3}' /etc/php-fpm.d/#{ENV['PJCODE']}.conf") do
  its('stdout.to_i') { should be_within(14).of(20) }
end

この場合、14が差分になります。
20に対して、+-14 以内が許容される という意味になります。

上記の例ですと、
下が6 までok, 上が 34 まで ok
となります。

mariadbのinnodb_buffer_pool_size を自動的に設定している場合も範囲で判定しています。

mariadb10のspec sample

# spec/mariadb_10/variables_spec.rb
require 'spec_helper'

describe command("awk '\$1~/innodb_buffer_pool_size/{ print \$3}' /etc/my.cnf") do
  its('stdout.to_i') { should_not be_within(99.9).of(100) }
end

上記の例は、should_not判定なので
俺の innodb_buffer_pool_size が 0.1 から199.9 の範囲に収まるわけはない
もっと多く割当たるはずだ
という判定になります。

ちなみに上記で、
innodb_buffer_pool_size         = 2000MB
など、MBなどの単位が入っていても問題なく判定できます。

https://ja.stackoverflow.com/questions/23703/serverspec-%E3%81%A7-%E7%AF%84%E5%9B%B2%E6%8C%87%E5%AE%9A%E3%82%92%E3%81%97%E3%81%9F%E3%81%84-rspec-%E3%81%A7%E3%81%84%E3%81%86-be-within-of-%E3%82%84-start-with

その他のテストツール: infrataster

インフラ面から見てエンドツーエンドのテストを簡単に行えるように出来るツールです。
CapybaraやSelenium のようなインフラ用のツールです。
deploy後のチェックに使ったりします。

こちらも割と多くの記事が出ていますので
細かい説明や手順は載せません。

この記事は、要所だけということで。

infratasterの設定について

通常は以下のように設定します。

Infrataster::Server.define(
  # Name of the server, this will be used in the spec files.
  :proxy,
  # IP address of the server
  '192.168.0.0/16',
  # If the server is provided by vagrant and this option is true,
  # SSH configuration to connect to this server is got from `vagrant ssh-config` command automatically.
  vagrant: true,
)

これを汎用的に使いたい場合は、同じく環境変数でハンドリングするようにしますが、設定情報はyamlでまとめておいた方が楽なので、以例えば、以下の様に環境変数 SERVER_NAME にSETするようにして、該当するYAML内の残りの設定を読み込ませるようにすると良いと思います。

spec/spec_helper.rb の例

# spec/spec_helper.rb
require 'infrataster/rspec'
require 'highline/import'
require 'yaml'

raise "Error: 環境変数 SERVER_NAME が入っていません\n\
`コマンドラインからecho $SERVER_NAME` で確認の上、`export SERVER_NAME=xxx を実行してください`\n\
e.g.) export SERVER_NAME=wordpress  # for vagrant"\
  if ENV['SERVER_NAME'].nil? || ENV['SERVER_NAME'].empty?

# Jenkinsのテストでは対話式にしない
ENV['TARGET_HOST_YML'] = ask("Enter servers.yml path (spec/env/servers.yml): ")\
  if ENV['JENKINS_SERVER_COOKIE'].nil?

ENV['TARGET_HOST_YML'] = 'spec/env/servers.yml'\
  if ENV['TARGET_HOST_YML'].nil? || ENV['TARGET_HOST_YML'].empty?

@properties = YAML.load_file(ENV['TARGET_HOST_YML'])

Infrataster::Server.define(:"#{ENV['SERVER_NAME']}") do |server|
  server.address = @properties[ENV['SERVER_NAME']]['address']
  server.vagrant = @properties[ENV['SERVER_NAME']]['vagrant']
end

spec/env/servers.yml の例

# For infrataster

example.com:
  address: '192.168.1.1/24'
  vagrant: false

# { Vagrant
wordpress:
  address: 'wordpress'
  vagrant: true

# } End of Vagrant

例えばこれで、
SERVER_NAME=wordpress bundle exec rspec
など。

こうしておくことで汎用的かつ、特定の対象をテストしやすくなります。

もちろんspec側でもその環境変数は有効に利用できます。

require 'spec_helper'

_uri = "http://#{ENV['SERVER_NAME']}/"

describe server(:"#{ENV['SERVER_NAME']}")do
  describe http(_uri) do
    it "reponse status" do
      expect(response.status).to eq(301)
    end

    it "responds with content inflated automatically" do
      expect(response.headers['content-encoding']).to be_nil
    end
  end

  describe capybara(_uri) do
    it 'shows welcome page' do
      visit '/'
      expect(page).to have_content 'WordPress へようこそ'
    end

    it 'shows sample page' do
      visit '/?page_id=2'
      expect(page).to have_content '新しく WordPress ユーザーになった方は、ダッシュボードへ行ってこのページを削除し、独自のコンテンツを含む新しいページ
  作成してください。'
    end

    it 'shows unclassified page from sample page' do
      visit '/'
      click_on '未分類'
      expect(page).to have_content 'カテゴリー: 未分類'
    end
  end
end

各ツール共通で使える値は、共通で扱える環境変数名にしておくとintegrationしやすいです。

e.g,)
export SERVER_NAME=”wordpress”
docker, k8s, ansible, serverspec, infrataster でも同じ環境変数を利用

Security check

vuls や専用ツールで定期的にチェックを入れています。

Kubernetes

最近、弊社でもKubernetesを扱うようになってきました。

Kubernetes-helmで YAML生成するのも良いと思うのですが、以下のようなsnippetツールを見つけたので、紹介させていただきます。

https://github.com/ipedrazas/kubernetes-snippets

少しは楽できるかな?と思い、使い始めたところです。

さいごに

誰かにとって少しでもお役に立てれば幸いです。
Aimingではインフラエンジニアも募集しております。
ご興味のある方がいましたら、ぜひご応募ください。


CephFSとGlusterFSの性能比較検証


こんにちは! インフラエンジニアの趙です。

業務では、主にゲーム公式サイトのインフラまわりを担当しています。

弊社の一部公式サイトでは、WordPressを用いてオートスケールを導入しています。データ以外でステートフルな部分はCephFSにまかせています。

CephFSの運用につきましては、弊社小熊の記事に詳細がありますのでご参考にしてください。

ちまたではCephFSよりもGlusterFSを使っている方が多く、理由の一つとしてその速度がよくあげられていますが、特に比較記事が存在しないようでしたので検証してみました。

今回、用いたCephFSは2017年の8月にリリースされたばかりのLuminousになります。
リリースノートを見る限りでは、jewel(前のLTS ver)よりも速度の面においてかなり進化してる模様です。

検証に用いたOSS一覧

OSS Version
CephFS 12.2.2
GlusterFS 3.10.5
nginx 1.10.1
php 7.1.9
MariaDB 10.1.26

CephFSの構成図

GlusterFSの構成図

検証方法

  • 測定するたびに必ずLinuxのcacheをpurgeする。
    • e.g. ) echo 3 > /proc/sys/vm/drop_caches
  • 測定結果は3回測定した後の中央値とする。

 

検証結果

  1. ddコマンドを用いて、大型のファイルを作成する時間を測定
  2. ddコマンドを用いて、小型のファイルを大量に作成する時間を測定
  3. アパッチベンチで100セッションを同時に送り、Request per secondを測定
  4. Fioでのベンチマーク
    1. random writeで10MBを16個並列で作成
      1. fio -name=r -direct=1 -rw=randwrite -bs=4k -size 10M -numjobs=16 -runtime=16 -group_reporting
    2. random readで10MBを16個並列で読み込み
      1. fio -name=r -direct=1 -rw=randread -bs=4k -size 10M -numjobs=16 -runtime=16 -group_reporting

結果

  • 今回の環境においては、単一のファイル作成、並列でのREADはCephFSのほうが速い。
  • 並列でファイルを作成する場合においては、GlusterFSのほうが速かった。

 

まとめ

  • 読み込みではCephFS、書き込みではGlusterFSの方が優秀と一長一短な結果となりました。
  • 弊社のWordPressを用いている案件では読み込みの方が重要なので、CephFSの方を採用すべきです。しかし、最新のCephFS検証において以下の不具合が発生したため、これからはGlusterFSを採用しようと考えています。
    • CephFSの不具合
      • FIOで(random write)のサイズを一定以上大きくした場合に、処理が止まってストレージにアクセスできくなる

 

最後に

“gluster backed block storage” を作成し、メンテナンスを容易にするgluster-blockが現在開発中のようです。これが上手く機能すれば、CephFS並の読み込み速度を得られるのではないかと期待しています。
検証してみたかったのですが、CentOS7では動かないようなので、今回は見送りました。
WordPressでオートスケールを構築する際、ストレージ候補の参考になれば幸いです。


takezawa

HALインターンシップレポート(東京本社編)


こんにちは。
人事の竹澤です。

大阪スタジオで実施した「HAL大阪/名古屋インターンシップ」に続き、
東京で実施した「HAL東京インターンシップ」について書きたいと思います。

東京本社では、HAL東京から7名の学生様におこしいただき、
実際の開発現場にてゲーム制作をおこないました。

チームは、プランナー2名、デザイナー3名、エンジニア2名。
チーム一丸となってゲーム制作に臨みます。
Aimingのインターンでは、各職種1名づつのメンターがつき、
不明点や疑問点をフォローをしながらをゲーム制作をおこなっていきます。

期間中のミッション&カリキュラムは以下の通りです。

ミッション&カリキュラム

「自律したチーム」「心理的安全性の確保」

  • 発言しやすい空気を作り、ミスを許容できることでチームの生産性を上げること
  • 課題や問題が発生したとき、まずは自分たちで”考えて”からメンター相談すること


講義

  • 企画の仕事について
  • デザイナーの仕事について
  • エンジニアの仕事について
  • git/レビュー講義&アジャイル開発について



フィードバック

  • スプリントレビュー(週1)
  • 中間発表
  • 最終発表
  • Aiming社員試遊会
  • Aimingマネージャーからの作品フィードバック(職種別)
  • コードレビュー(エンジニア)


社員交流会

  • マネージャーとの座談会
  • ランチ会
  • 懇親会

 

 

 

スプリントレビューやKPTなど振り返りを多くとることによって、現状を把握し問題点を早期発見することができました。
今回の制作では、(ほぼ)全ての管理をgithubでおこない、仕様や制作中の画像、バグ報告など一元管理することに成功しました!(github使ったことないメンバーもいたのにすごい!)

それでは、1か月の成果を簡単に紹介します。

制作物

【BOMBTET】


ジャンル:オンライン爆発アクションゲーム
ターゲット:20代の男女
コンセプト:協力して敵を倒す楽しさ


爆弾の爆破を利用して、仲間と協力し敵を倒すオンラインアクションゲームです!
遊び方は簡単!
自爆して、仲間を爆風で飛ばして、敵にぶつけて攻撃する!というもの。

1人で突撃しても攻撃できますが、部位ごとに与えられるダメージ量が違うので、
協力することで大ダメージを与えることができます!
スタンプを使ってうまく連携するのがポイントです。

また、キャラクターごとに特徴が違うので選択するキャラクターによっても
ゲームの難度が変わります。

試遊会では実際にオンラインで4人対戦したのですが、うまく爆風にのって攻撃できたときの爽快感がすごかったです!
(ちなみに私は下手すぎて全然違う方向に飛んだり飛ばしてしまったりでした…)

総評

フィードバックされたアドバイスを一身に受け止め、
こちらが提案した内容を自分たちなりに「考え」、出した答えを共有してくれる…
そんな素晴らしいチームでした。

チーム内の情報共有はもちろん、メンターへの報告や連絡を欠かさずおこなってくれたので
早い段階で問題を解消することができ、余裕をもって最終日を迎えることができました。

それぞれが自分の役割を果たし、相手を尊重できるそんなチームだったと思います。

毎日顔を合わせていたので少し寂しくなりましたが、
今回の経験を活かして新たなゲーム制作をおこなってくれることを楽しみにしています。



mori

HALインターンシップレポート(大阪スタジオ編)後編


こんにちは。人事の森です。

前編に続きまして、「HALインターンシップ」後編では、素晴らしい活躍を見せてくれた3チームの各リーダーに突撃インタビューを行いましたので、その様子をお送りします。

 

まずは、リーダーの紹介。

向かって左から、

  • Aチーム「Dengeon」:岡野 浩之さん(HAL名古屋)
  • Bチーム「コウモリたちのバッドディ」:横山 慈永さん(HAL名古屋)
  • Cチーム「キツネットワーク」:蒲生 大地さん(HAL大阪)

 

こちらの爽やかなお三人が様々答えてくれました。

 

(HALインターン リーダーインタビュー) ※敬称略

 

森:まずは、Aimingのインターンに参加しようと思った理由を教えて下さい。

・・・すごく緊張気味の3人ですが、まずは岡野くんから・・・!

 

岡野:僕はHAL名古屋から来てますが、HAL名古屋は先生からの紹介によってAimingさんを勧められました。僕のインターン先がAimingと知って、テンションあがりました。ログレスをやっていたので、とても嬉しかったです。

横山:僕はAimingのことはよく知らなかったですが、スマホゲームの会社だと聞いて嬉しかったです。最先端の開発を知ることが出来ると思いました。

蒲生:僕はHAL大阪で、HAL専科(夜間に行われる特別ゼミのような授業)でAimingさんの授業を受けていたので、Aimingのことはよく知っていました。そこで働く人達にとても興味を持ったので、インターンに行きたいと思い応募しました。

 

・・・Aimingは、HAL大阪で「専科」を受け持っています。「オンラインゲームプランニング専科」や「オンラインゲーム開発専科」など。蒲生君はプランニング専科の受講生でした。

 

森:3人はどうしてリーダーになったのですか?

全員:皆の推薦です。(全員一致)

 

森:Aimingでは、チーム開発を行う上で、「リーダー/リーダーシップ」は非常に大切なものだと思っています。社内では、随所でこの力が重要視されます。皆さんはリーダーって何だと思いますか?心掛けてることとかあったら教えて下さい。

岡野:皆を引っ張っていきながらも、前に出すぎるのではなくて、共に歩きながら肩を組み、周囲を鼓舞することを心掛けていました。リーダーはすごく有能な人じゃなくても出来るんだ、と思うようにしています。飛び抜けた技術がなくても、コミュニケーションをしっかりとることでリーダーシップを発揮しようと思いました。

横山:制作は終わりが見えないこともある。リーダーとは、「闇を払っていく役割」と思います。他の人を置いてけぼりにしてはいけない。

森:リーダーは「闇を払っていく」役割。良い言葉ですね。(闇を駆けるコウモリとかかっているいるのかしら・・・?) ※以下参照画像。

 

蒲生:チームメイトの仲を保つこと。今回のインターンでは、HAL名古屋の人は、大阪勢より人数が少ないので、肩身の狭い思いをさせないように気を付けました。そして、納期を守ることを厳守しようと思いました。過去に、クオリティを上げる事に必死になり納期を守らなかった経験があるので、その反省が元になっています。

森:Cチームの進捗報告、素晴らしかったです。あと何が残っているのか、この先の展望と合せて説明されていて、とても良かったです。

 

森:1ヵ月過ごした中で、「面白かった」ことを教えて下さい。

蒲生:学校でもチーム開発は経験していますが、ここに来てる人達はモチベーションが元々高いので、何もかもがスムーズだったことです。人生で1番楽しいチーム開発でした。チームメンバーの頑張りで、新技術を取り入れることも出来たし、たくさんのチャレンジがありました。

横山:リーダーを経験できたことです。リーダー経験は初めてではないですが、チーム全体のSlackの会話を俯瞰して眺めるようにしたり、全体把握に努めました。

 

森:では逆に、開発中に1番苦労したことはなんですか?

岡野:UNETの勉強が難しかったです。初めて触ったので、進捗が上手くいかず、何も出来ない状態が最初の1週間続きました。間に合うのかな・・と不安になりましたが、上手くいって本当に良かったです。他にはネットワークの環境構築やエフェクト、アニメーションの作成も、「苦労」とは違いますが、頑張りました。

横山:企画が決まるのが遅く、コンセプトを練るのに苦労しました。制作では、結合する時にバグが発生してしまい、バグをとったらまた別のバグが出る・・・これは大変でした。エンジニア全員でPhotonの勉強をやったことも印象的です。

蒲生:企画が2週目の水曜日まで決まらなかったので、エンジニアに負担をかけてしまいました。HALではまだネットワークをやっていないので、Photonを初めてやったし、Sub versionを触るのも初めてでした。初めてのことは大変ですが、インターンを通して学べたことは大きいです。

・・・初めての経験を試行錯誤してちゃんと成果物として完成できた、素晴らしい・・・!

 

森:幾つか行ったグループワークはいかがでしたか?

岡野:紙飛行機のワークショップが印象に残ってます。丸めて飛ばしたのは僕のチームですが、飛びはしたけど、「品質としてはお客様に出せないよね」と言われたのが気付きでした。思考錯誤の過程も面白かったです。ログレスディスカッションは、緊張して頭真っ白だった。記憶がないです(笑)

横山:マシュマロチャレンジや紙飛行機のように、ルールを初めて知り、限られたツールや時間の中で実施する体験は初めてでしたが、発想力を持ってチームワークで改良してくのが楽しかった。

・・・チームワークで見事に改良した結果がこの笑顔^^
蒲生:僕も、紙飛行機チャレンジが印象的です。クオリティを求めすぎて、求められてるのは「3メートル以上飛ぶことを量産する」なのに、6メートル以上飛ぶことを誇ってしまった。他には、見積もりと結果という考え方や、固定概念に囚われないこと等、「なるほど」と思うことが多かったです。

・・・これですよね。めちゃくちゃ飛んでましたよね。歓喜の声が響いてました。

 

 

森:Aimingのスタッフ(主にメンターさん)と交流しての印象を聞かせて下さい。
蒲生:とにかく「優しい!」です。先程褒めて頂いたタスク管理の方法は、メンターさんに教わったんです。すごく参考にしました。ホワイトボードに アナログトレロを書いて「タスクの見える化」を教えてくれたのもメンターさんです。見える化は凄く大事。身をもって知りました。これを取入れてから、開発が一気にスムーズになりました。メンターさんは自分より年が3つだけ上とは思えない程、しっかりしている。何か相談したら、最初に必ず「それ分かる」って共感してくれるんです。この言葉にすごく安心しました(笑)

横山:メンターが自分たちを信頼してくれてると感じました。お母さんが息子を見るような温かい目で見てくれました(笑)気軽に沢山のことを相談させて頂きました。

 

・・・試遊会では、ディレクターがゲームの感想を伝えます。メンターも同席し、フィードバックを確認。真剣そのものです。

 

岡野:色んな指導の仕方があるのだということを知りました。厳し目なお言葉も貰いましたし、成果物を見て褒めてもくれました。砂漠とオアシスを両方持っていて、締める所はちゃんと締めてくれてる。厳しさとやさしさを併せ持っている印象です。

 

森:何かしらの成長がありましたか?

全員:YES!

・・・最後の言葉、「YES!」を聞いて、私たちも心底「よかった」といえるインターンシップでした。参加してくれた学生の皆さん、1ヵ月本当にお疲れ様でした。

 

 

(まとめ)

1ヵ月を通して、皆個々にチャレンジがあり、成長を実感できる体験が出来たとの言葉、何より嬉しく思います。3チームともに素晴らしかったのは「チームワーク」。リーダーに協力しようという姿勢があり、リーダーはメンバーを思いやる心があり、終始明るい雰囲気のまま進行しました。また、インタビュー中には「メンターさんが厳しい言葉をくれた」との回答がありましたが、該当メンターは入社1年目の新卒スタッフ。後輩が出来、指導する立場となってその難しさに直面し、言わなくてはいけないという責任感から出た言葉なので信頼関係が生まれる。こちらにとってよい学びの機会となりました。

 

 

・・・こちらの写真↑ Bチームメンバーと、一昨年にこのHALインターンのメンターを努めてくれたAimingスタッフの姿も。昨年メンターを努めたスタッフが、翌年にはメンターさんのアドバイザー的なポジションとして、順繰りに後輩をサポートしていく仕組みがあります。

 

Aimingでは通年を通して多くの職種でインターンシップを受入れています。広々スペースで思い切り議論し、物作りに没頭することが出来ます!カリキュラムやスケジュールは柔軟に対応していますので、興味ある皆様、エントリーお待ちしています。

 

 

(おまけ)

 

最終日の打上げにて。多くのAimingスタッフも参加し、盛り上がりました。

 

 

             ★皆さんの未来に乾杯★

 

(完)

 

 


mori

HALインターンシップレポート(大阪スタジオ編)前編


こんにちは。人事の森です。

今日は、毎年恒例、大阪スタジオ10月の風物詩でもある「HALインターンシップ」について書きたいと思います。

大阪スタジオでは、HAL大阪とHAL名古屋から総勢24名の学生さんにお越し頂き、今季増床したばかりのオフィススペースを使ってインターンシップを行いました。広々としたスペースなので、活発な議論を交えながら伸び伸びと制作活動を行うことが出来たと思います。

今年のテーマは「伝える」「伝える」をテーマにしたゲームを制作してもらいます。24名をA、B、Cの3チームに分け、ゲーム制作を行います。1チームの内訳は、エンジニア4、プランナー3、デザイナー1。なかなか良いバランスではないでしょうか。
さて、3チームから、どんな「伝える」ゲームが生まれるのか・・・楽しみしかありません。

インターン生のフォロー体制としては、管理者やアドバイザーの他、最もインターン生と身近に接する「メンターさん」を任命します。このメンター任務を任されたのは、入社1年目の新卒エンジニア、新卒デザイナー、2年目のプランナーが2名という4人の若者達。彼らにとっても、学生を指導することで学びや気づき等、得るものがあることを期待して、インターンシップは始まりました。

 

1ヵ月という、長くて短いこの期間中に詰め込んだミッションやカリキュラムはざっと以下の通りです。

  • 「伝える」をテーマにゲームを制作(メイン)
  • 「中間発表」「最終発表」「Aimingディレクター試遊会」「Aimingスタッフ試遊会」による4段階のフィードバック(これも大事)
  • PDCAサイクルやチームワークの活用に着目したグループワーク(盛り上がりました)
  • 「ログレス」を分解するグループディスカッション(ログレスディレクターを前に、緊張で記憶がないという子がいました)

 

↓ ディレクターやメンターによる試遊会。思いがけないバグも発見されました。

 

↓ スプリント中に、「3メートル以上飛ぶ紙ヒコーキを幾つ生産できるか」というグループワーク。PDCAを上手く回して、チームで紙ヒコーキを作ります、飛ばします、そして数えてまた作ります。かなり忙しくスプリントを回していきます。

 

こ、これは・・・! 紙くず・・・? ゴミ・・? いや、紙ヒコーキ・・?

驚異的な数が3メートルを超えていますが、これを「紙ヒコーキです」とお客様に出すことはで出来ないでしょう。「紙ヒコーキ」の固定概念に囚われない姿勢は良いかもしれません。

 

 

それでは、1ヵ月の成果であるゲーム作品を、それぞれ簡単に紹介したいと思います。

 

まずはAチームから・・・

「Dengeon-美女と呪いの冒険」 

 

「伝達」の「デン」+「ダンジョン」=「デンジョン!」ピクトグラム(絵文字)によって「伝える」をデザインした最大4人同時プレイのマルチプレイヤーローグライクゲーム。
画面構成はサイドビューで、基本的にキャラクターの移動やバトルは自動で進行していきます。そこでこのゲームの肝となるのが絵の伝達というものです。(出た!伝える!)

各プレイヤー毎に示された異なるピクトグラムを全員が同時にお絵描き板に描く。そのピクトグラムを伝えあうことで、扉の先に待ち受けている様々な要素を推測していきます。その推測結果を元に有利な道を選択し、体力の回復、強力な武器の取得などを重ね、最終的にはボスを倒せればゲームクリアーとなります。
ローグライクというランダム要素がベースにありながらも、情報を的確に伝達することで最適な道を選択できる!ですが、お絵かきには時間制限があるので、うまく伝えられない時は、ランダム性による不安定なゲームプレイになってしまうという、何とも絶妙なこの塩梅がこのゲームの面白いところです。

 

 

続いて、Bチームは、ホラーゲームが好きなメンバーによる

「コウモリたちのバッドディ」

最終発表会は、10月31日。つまり「ハロウイン」です。季節感にちなんだ作品を制作するなんて乙だなぁと感想を述べたところ、それは関係ないとのこと。でもコウモリがパンツ履いていて可愛いので問題ありません。

このゲームは、3人 vs 1人の4人同時プレイ、鬼ごっこタイプのマルチプレイヤーホラーアクションです。3人チームのコウモリ側と、1人のコウモリ駆除ロボット側に分かれてゲームをスタート!

逃げるコウモリ、追いかけるロボット・・・まさしくホラーです!でも赤や黄色のパンツがとってもキュート。

 

コウモリ側はマップに散らばった脱出用アイテムの歯車を一定数集め脱出すると勝利になります。また、一定時間以上逃げ延びても勝利です。(私はひたすら逃げ延び、そして勝利しました・・・!)

ロボットは制限時間内にコウモリを全て捕まえると勝利です。
コウモリは、暗闇の中、音波を飛ばして壁に反射させることでマッピングを行い視覚化することが出来ます。また、その視覚化したマップ情報をコウモリチーム間で共有し、これを脱出に活用します。(出た!伝える!)
ロボットは高性能なので自身が出した音と、さらにコウモリの音波もキャッチして有利にマップを走破できます。
暗い工場という不気味なマップの中を追われる恐怖と、追い詰め捕まえるという緊張感を味わうことができるゲームです。(でもカラフルなパンツがキュートです。)

 

最後はCチーム

「きつねっとわーく」

プレゼンがとっても上手なCチーム。発表会では、まるで自社商品を売り込むかのようなプレゼンで、私も思わず「早く遊びたい!」と言ってしまいました。チュートリアルもゲームプレイしながら体験できるようになっていて、とても分かりやすかったです。

このゲームは、3人同時プレイのマルチプレイヤープラットフォームアクションです。プレイヤーはそれぞれのキツネを操作して、全員でゴールとなる鳥居を目指して走ります。キツネにはそれぞれ、「目の良いキツネ」、「鼻の良いキツネ」、「耳の良いキツネ」と能力が割り振られており、その能力で道中に仕掛けられた様々な罠を発見することができます。

ですが、各キツネには1つの能力しか割り振られていないので、自分に分かる罠は他の2人では気付くことができません。そこで「いいね!」と「危険!」の2つのエモーションを使って罠や、見えない床の存在などを知らせる必要があります。(出た!伝える!)
コミュニケーションに使えるのは2つのエモーションのみなので危機の伝達を行うものの、上手くいかないこともあります。時にはジャンプや左右への移動などの身振りも合わせてコミュニケーションを模索しますが、上手く伝わったり、伝わらなかったりと、何とも言えないもどかしさがあります。これを開発チームは演出したかったのでしょう。このもどかしさが意外な程に心地よく、ワイワイと盛り上がる要素になっていて、パーティゲームとしてもとても楽しめました。(私は、「もう1回だけ」と言いながら何回もプレイさせてもらいました!)

 

(まとめ)

それぞれに個性の光る「伝える」ゲームが完成しました。フィードバックの場では、鋭い指摘やアドバイスをたくさん受ける場面がありましたが、落ち込む素振りもなく、真剣に意見を吸収しようとする姿勢がとても印象的です。今年のインターンは、3チームともに「チームワーク」が素晴らしかったです。

いつも、インターンの開発現場に入ると、元気いっぱいに「おはようございます!!」「お疲れ様です!!」。そんな元気な挨拶から始まり、最後は「ありがとうございました!!!」と、これまた気持ちの良いご挨拶を下さりました。

些細なことかもしれませんが、こんな元気な挨拶は、チームだけでなくインターン全体の雰囲気を明るく前向きに動かし、チームワークの醸成を促し、良いゲーム作り、チーム作りに繋がっていくのではないかと感じました。

次回、後編では、この3チームそれぞれのチームリーダーに、1ヵ月間を振返っての直撃インタビューを行いましたので、その様子をレポートします。

 

(おまけ)

最後は皆で記念撮影。賑やかだったスペースが静かになって少し寂しいです(´;ω;`)

 

皆さん、お疲れ様でした。後編に続く。