Aiming飲み会 #5 を開催しました


こんにちは。エンジニアの栗本です。

先月の1月25日(水)に Aiming飲み会 #5 グラフィックエンジニア新年会 を開催いたしました。
たくさんの方にご参加いただきまして、おかげさまでLTも大変盛り上がり、大盛況のうちに開催することができました。
お忙しい中お越しくださった皆様ありがとうございます。

乾杯の様子

乾杯!

LTの様子(山納)

LTの様子(山納)

ご厚意にあずかりまして、今回の発表資料の一部を公開していただきました。以下のリンクから見ることができます。
弊社エンジニアの山納: Vertex Texture Fetchの活用について
notargs様: GLSL作曲入門
柿崎様: Luaを使ったキャラクタのスクリプティング

次回のAiming飲み会は3月ごろ、デザイナーにフォーカスしたものを予定しています。
今後の情報は Aiming – connpass で公開していきますので、ご興味のある方はぜひフォローをお願いします。
改めまして、登壇者の皆様、参加者の皆様ありがとうございました。


oguma

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


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

インフラチームの小熊です。
前回(弊社インフラチームが参考にして実践しているITサービスフレームワークや利用しているOSS, Tool類の紹介をさせていただきました。)から大分空いてしまいましたが、今回は、そのツールやOSSのTips をいくつかご紹介したいと思います。

tl;dr

Ansible は、vim-ansible-yaml を入れて、CI に放り込みつつ Serverspec等で TDD / TDI すれば良い感じだと思います。
その他のAnsible tips やVagrant について書きました。
良さそうなところがあったら参考にしてみてください。

Ansible Tips

構成管理ツールは、主に Ansible が扱われています。
(AnsibleでContainer操作も可能ですが、今回Containerの話はしません)

そんなAnsible のTipsや、最近Version 2.2の注意点をいくつか紹介したいと思います。

ツールの紹介

素晴らしいツールの紹介です!
すでに世間でよく出回っている情報ですので、知っている人は読み飛ばしてください。

  • vim-ansible-yaml
    • これを入れておけば、早く書けます
    • はい、私はvimmerです
  • ansible-console
    • module の単体テスト、動作確認が出来ます
      • e.g.) 例えばvagrantの場合は以下でインタラクティブシェルが起動します
        ansible-console -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory
        
      • 上記でインタラクティブシェルに入ってから
        help

        もしくは

        ?

        と打つとhelpが参照出来ます

      • このhelpを使うことでも簡単なansible-doc のような役割も満せます
        koguma@all (1)[f:5]$ help datadog_event
        
        Posts events to DataDog service
        Parameters:
        date_happened POSIX timestamp of the event.
        alert_type Type of alert.
        title The event title.
        text The body of the event.
        tags Comma separated list of tags to apply to the event.
        app_key Your DataDog app key.
        priority The priority of the event.
        aggregation_key An arbitrary string to use for aggregation.
        api_key Your DataDog API key.
        validate_certs If C(no), SSL certificates will not be validated. This should only be used on personally controlled sites using self-signed certificates.
        
  • ansible-doc
    • AnsibleのdocumentがCLI上で開けます
      • 私はvimやatom上で利用しています
  • ansible-playbook-debugger
    • 私は使っていませんが、一応debuggerもあります

version 2の注意点

  • 最新2.2について
    • check mode の対応が変わりました
      • always_run は deprecation となり、無くなる予定だそうです
        [DEPRECATION WARNING]: always_run is deprecated. Use check_mode = no instead..

        と出ます

      • 変わりに check_mode: no を使うようにしましょう
    • group_vars/等の読み込みが変わりました
      • .yml or .yaml の拡張子が必要になりました
      • 全てのfileに拡張子をつけるようにした方が良いようです
    • service module
      • systemd の扱いが変わりました
        • SysVinit scriptのものが起動できなくなっていました
        • 2.2 からsystemd module ができていました
      • sleep option を受け付けなくなりました
    • include の扱いが変わりました
      • include を使う上で変数の扱い方によっては、それら変数を Dynamic に読み込ませるかStaticに読み込ませるか選択が必要になりました
      • 詳細は以下を確認してください

whenで、値をまとめたOR判定をする

when: ansible_env.TARGET_ENV == 'test' or ansible_env.TARGET_ENV == 'development'

と書くのは長いので、下記の様に in を使います。

例 (testとdevelopmentを環境変数 TARGET_ENVで、受け取って判定をする。)

environment:
  - TARGET_ENV: "{{ lookup('env','TARGET_ENV') }}"
tasks:
  - debug: var=ansible_env.TARGET_ENV
    when: ansible_env.TARGET_ENV in [ 'test', 'development' ]"

動作確認 (test, developmentそして、skip判定確認のためのhogeをそれぞれ順番に環境変数TARGET_ENVに入れてdebug)

% for ENV in test development hoge;do TARGET_ENV=${ENV} vagrant provision test | grep -A 4 'TASK \[debug\]';done
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
ok: [test] => {
    "ansible_env.TARGET_ENV": "test"
}
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
ok: [test] => {
    "ansible_env.TARGET_ENV": "development"
}
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
skipping: [test] => {
    "changed": false,
    "skip_reason": "Conditional check failed",

TARGET_ENV=hoge だけ

    "changed": false,
    "skip_reason": "Conditional check failed",

になったので正常に判定ができています。

Testについて

  • ansible-spec というtoolが用意されています
    しかし、Ansible 以外のtoolとも連動させたインフラテストを行っていきたいので Serverspec と Infrataster を利用するように絞りました

    • Serverspec
      • TDD / TDI全般 で利用
    • Infrataster
      • deploy後のBDD で利用

これらについて細かいことは次回投稿する予定です。

必ず、Ansible でServerspecが実行されるようにしている

  • playbookに書いています。
    • post_tasks を使うと毎回 Serverspec でテストしてくれます
      これで 半ば強制的に TDI を実現するようにしています

Ansible playbookからの強制Test実行の注意点としては
事前にsshでアクセスできるようにしておく必要があります。(vagrant sshではなく)

[補足] Vagrant 側で用意されている vagrant ssh-config をplaybook側で実行し、~/.ssh/configに書き込むことも考えました。

しかし vagrant ssh-config に初期化 = ~/.ssh/config をワイプしてくれる機能がないので、各環境で用意したり考慮していくのも面倒だと思えました。 (Jenkinsなどでvm を作ったり消したりしながらテストをバンバン回していく環境など)

そこで、環境構築手順の簡略化も考慮し、Vagrantfile にssh pub auth 登録の処理を書いてしまっています。

playbooksが煩雑になるのを避ける

通常のansibleはplaybooksを直下に横並びで置くため、多くなってくると見づらくなる問題があります。
我々のチームの特定Projectでは、良いか悪いかは別としてplaybooks が煩雑にならないように playbooks dir 配下におけるようにしています。

具体的には以下のような構成です。

├── playbooks
│   ├── addusr_ssh.yml
│   ├── disable_selinux.yml
│   ├── gce-instance-provision_and_init.yml
│   ├── gce-lb-provision.yml
│   ├── instance-provision_and_init.yml
│   ├── monitoring-tool.yml
│   ├── td-agent.yml
│   ├── test.yml
│   ├── vuls.yml
│   └── wordpress.yml
├── plugins
│   └── inventory
├── roles
│   ├── add_ssh_user

# ..<snip>

通常は以下の構成になります。
https://docs.ansible.com/ansible/playbooks_best_practices.html#directory-layout

どうやっているか

  • Custom role path という機能を使っている
    • ansible.cfg に以下の設定をしています
      [defaults]
      roles_path = roles
      
  • group_vars, host_varsを対応させる

    Ansible galaxy でも落とせるようにしてあります。

    ansible-galaxy install aim-oguma.init-for-integrated

1/30追記: ansible-init-for-integrated に一部不備があったので訂正しました。

Ansibleの小ネタ

普段の運用でも、ansibleをよく使っています。
その中でちょっとしたネタ的な使い方を紹介します。

クラスタオペレーションツールとしてリソースを監視する例 (CPU使用率を表示)

[devinfra@test-festa ansible]$ ansible -i inventory all -m shell -a "sar -u ALL | awk 'NR==6,p{if(m<\$4) m=\$4} END{print m}'"
test-festa-slave2 | SUCCESS | rc=0 <<
0.44
test-festa-master | SUCCESS | rc=0 <<
0.39

test-festa-slave1 | SUCCESS | rc=0 <<
0.37

Vagrant

下記に内容を示します
具体的なcodeは纏めて記載します。

For Ansible provision

引数で各playbook 名を指定して、それで動くようにしています。
各種playbookがそのまま同じVagrantfileで利用可能なようにしています。


@vm_name = ARGV[1]

playbook = {
  :disable_selinux => "playbooks/disable_selinux.yml",
  :target => "playbooks/#{@vm_name}.yml"
}

Vagrant の高速化

virtioを使うようにしたり


    vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
    vb.customize ["modifyvm", :id, "--nictype2", "virtio"]

local repositoryを使っています (ちなみにvagrant-cachierは問題起こすので現在利用停止中)

社内にLocal yum repositories を立てていて、社内いるときだけそれを使うように動的な処理を入れています。


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

# ..

  # 社内の場合はLocal repositoryに向けて高速化する
  if Network.global_ipaddr.inhouse?
    config.vm.provision :shell, :inline => <<-EOT
      sudo sh -c "echo '#{MYCORP_LOCAL_REPO}' > #{MYCORP_LOCAL_REPOFILE}"
    EOT
  else
    config.vm.provision :shell, :inline => <<-EOT
      if [ -f #{MYCORP_LOCAL_REPOFILE} ];then
        rm -f #{MYCORP_LOCAL_REPOFILE}
        sudo yum clean all
        sudo yum repolist
      fi
    EOT
  end

Vagrantfile

Vagrant Cloud を利用しているので vagrant login はしておいてください。

このままでは動きませんが、playbookを用意したり、Vagrantfile に<>で書かれている部分を適宜設定していただければ利用出来るはずです。

最後に

こちらでのご紹介が、誰かのお役に立てれれば幸いです。

今回はここまでです。

次回は CI (Jenkins) や TDI tool (Serverspec), BDD tool (Infrataster)についてや、重要な脆弱性診断が行えるツール vuls について近日公開したいと思います。


s-kuroki

Ruby関西勉強会に会場を提供しました #rubykansai


大阪スタジオのwebエンジニアの黒木です。

1/14(土)に開催された第76回 Ruby関西 勉強会に大阪スタジオのセミナールームを提供しました。

Ruby関西は関西では最も歴史の古いRubyコミュニティで、現在も2ヶ月に1度勉強会が開催されています。また、主催イベントに過去6回開催されている関西Ruby会議があり、次回開催が今年の5/27(土)に予定されています

勉強会の発表内容は毎回多岐に渡っています。前回は私も発表させてもらいました(スライド)。

今回は弊社の植森が「ゲーム会社でのRuby : rails活用事例」と題しまして、AimingでRubyとRailsをどのように利用しているのかという話をさせてもらいました。

Aimingでは勉強会への会場提供を積極的に行っています(東京大阪)ので、いつでも気軽に問い合わせしてください。をはじめ、Aimingスタッフに連絡してもらってもOKです。お待ちしています。


Aiming飲み会 #5 グラフィックエンジニア新年会 を開催します!


こんにちは。エンジニアの栗本と申します。

来る1月25日(水)に Aiming飲み会 #5 グラフィックエンジニア新年会 -ちょい先のスマホグラフィックについて語る会- を開催します!
Aiming飲み会 #5 グラフィックエンジニア新年会 – connpass

Aiming飲み会とは

Aiming飲み会と言うのは勉強会のような堅い雰囲気ではなく、お酒を飲みながら比較的ラフな雰囲気でLT(LightningTalk)大会を行おうという企画で、2015年夏から不定期で開催しています。
前回の第4回ではアクセルマークさんのご厚意により会場をお借りし、WonderPlanet 社 CTO の村田知常さんをお招きしてLT大会を開催することができ、大変盛況でした。

第1回の様子

第1回LT

第4回の様子

第4回LT

第5回Aiming飲み会

第5回になります今回は
「グラフィックエンジニア新年会 -ちょい先のスマホグラフィックについて語る会-」
というテーマで開催します。
LT 登壇者としては、 notargs さん、 rita さん、弊社エンジニアの山納に加えて、Cygames の方とアカツキの方をお招きすることになりました!

会場の都合上参加者を増やすことは難しいのですが、募集はまだ行っておりますので、興味のある方はconnpassイベントページからの参加登録をお願いいたします。
スマホグラフィックのこれからが気になる方、LTを聞きながらお酒を飲みたい方は是非お越し下さい!


Unity3DのDIフレームワーク、Zenjectの紹介


はじめまして。エンジニアの石井と申します。

今回は現在担当プロジェクトで使用しているUnity(ゲームエンジン)用DIフレームワーク、Zenjectを紹介させていただきます。

Zenjectとは

https://github.com/modesttree/Zenject

ZenjectはUnity3D向けに作成された、DI(依存性の注入)フレームワークです。
Zenjectを使うことでオブジェクト間の依存関係を外部から解決することができます。
簡単になにが良いかを説明しますと、
依存オブジェクトを別の入れ物(コンテナ)に格納しておきコンテナ経由で使うことで、
コンストラクタやメソッドの引数で渡していたり、自身でnewしていたり、FindObjectしていた部分をなくすことができます。

Zenjectサンプル

Zenjectを使ってのUIイベント処理の簡単なサンプルを作っていきます。
今回はボタンが押された時のイベントを処理するサンプルです。

1.インストール

AssetStoreからか、
https://github.com/modesttree/Zenject/releases
からダウンロードしてUnityのプロジェクトにインポートしてください。

2.Contextの作成

シーン上にContextを作成します。
右クリックからScene Contextを選んでください。
Zenject_context

3.Installerの作成

コンテナへの格納(Bind)にZenjectはInstallerというスクリプトを使用します。
今回はSingletonとしてオブジェクトをBindしていきます。

シーン上にGameObjectを作成して、
下記スクリプトをAdd Componentしてください。
※直接SceneContextでも問題ありません。
Zenject_Installer

using System;
using Zenject;

public class InstallerSample : MonoInstaller<InstallerSample>
{
    public override void InstallBindings()
    {
        Container.Bind<ZenjectSample>().AsSingle();
        Container.Bind<IInitializable>().To<ZenjectSample>().AsSingle();
        Container.Bind<IDisposable>().To<ZenjectSample>().AsSingle();
    }
}

4.ContextにInstallerをアタッチ

ContextにInstallerをアタッチすることでInstallerが機能します。
SceneContextのInstallersに、作成したInstallerSampleをアタッチしてください。

Zenject_Context_Installer0

5.UIの作成

UIを作成していきます。
下記のようにボタンを2つ作成し、
Zenject_UI_hierarchyZenject_UI

それぞれ下記のようにスクリプトをAdd Componentします。
Zenject Bindingスクリプトにより、Installerに定義しなくてもBindすることができます。
Identifierを使うことで、個別にInjectすることもできます。

Zenject_UI_Parts

using UnityEngine;
using UnityEngine.UI;
using UniRx;

public class UIView : MonoBehaviour
{
    [SerializeField]
    Button button;

    [SerializeField]
    Text text;

    public IObservable<string> OnClickObservable()
    {
        return button.OnClickAsObservable().Select(_ => text.text);
    }
}

イベントの変換はUniRxを使い、Textをstringで送出します。

6.サンプルクラスの作成

サンプルクラスを作成します。
[Inject]アトリビュートにより先ほど作成したUIViewが注入されます。
IInitializable.Initializeメソッドにより初期化され、
各ボタンのClickイベント購読し、押されたらOnClickメソッドが呼ばれるようになっています。
Sceneの切り替えやゲームの終了などでContextが破棄されるタイミングでIDisposable.Disposeメソッドが呼ばれ、
購読を停止しています。

using System;
using System.Collections.Generic;
using UniRx;
using Zenject;

public class ZenjectSample : IInitializable, IDisposable
{
    [Inject]
    List<UIView> buttons;

    List<IDisposable> subscriptions = new List<IDisposable>();

    void IInitializable.Initialize()
    {
        UnityEngine.Debug.Log("Initialize");

        buttons.ForEach(button =>
        {
            subscriptions.Add(button.OnClickObservable().Subscribe(text => OnClick(text)));
        });
    }

    void OnClick(string buttonText)
    {
        UnityEngine.Debug.Log(buttonText);
    }

    public void Dispose()
    {
        subscriptions.ForEach(subscription => subscription.Dispose());
        subscriptions.Clear();

        UnityEngine.Debug.Log("Dispose");
    }
}

7.動作確認

Sceneが読み込まれる際に、Initializeメソッドが呼ばれ、
ボタンが押されるたびにボタンのTextがログに表示され、
最後にDisposeが呼ばれていることがわかります。

Zenject_log

おわりに

簡単に紹介させていただきましたが、
他にもZenjectには様々なContext、Installerが用意されていますので、
依存関係の解決でお困りの方はぜひ一度試してみてください。


oguma

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


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

初めまして。
Aimingでインフラを担当している 小熊(oguma) と申します。

普段は、ウェブサイトの構築/運用管理や
東京と大阪のネットワーク設計/構築/運用管理、
backoffice toolなどのinfra/inhouse開発および
技術指導/教育やフレームワーク導入や運用設計を行なっています。

それと最近は機会が減りましたが、たまにゲームインフラ構築や
内部統制および情報システム管理や人事関連をやっています。

LLによる開発や、Infrastructure as Code、 Tuning、 Serverless、 Container、 システムの自律化関連にとても興味がある音楽と雪山が好きな酒好きです。

今日も元気に飲みにいきましょう!!

さて、本題に入りますが
今回は、その中でAiming インフラチームが
どのような業務スタイルで、どんなツールを使っているのかや、ちょっとしたTipsなどを少し紹介させていただきたいと思います。

それらを 計3回に分けて投稿します。

今回、このblogを読む上で得られる情報は以下になります。

  • この記事で得られる情報
    • AimingインフラチームのワーキングスタイルとITサービスフレームワーク
    • Aimingインフラチームの使用しているツール, OSSなどの各種情報
      • その中から一部のツールのTips
        • Ansible 2.x
        • Vagrant
        • Serverspec
        • Infrataster
        • vuls

今回は、Container や Serverless などの話はしませんが、
少しでも皆様のお役に立てる情報になれば幸いです。

利用しているツールやフレームワーク

さて、
我々は以下のようなツールやフレームワークを採用しています。

  • IT サービスフレームワーク
    • ITIL を参考にしています
      • 強いチーム、業務プロセス改善、ITサービス運用レベルの向上にはうってつけの教本ですね
  • 構成管理
    • Ansible
  • TDI (Test Driven Infrastructure)
    • TDD
      • Serverspec
    • BDD
      • Infrataster
  • 環境
    • Mac
    • Vagrant
    • Container
    • Docker (個人利用 & 一部Projectで本番環境も利用開始)
    • Kubernetes
    • AWS
    • GCP
    • GMOアプリクラウド
    • IDCF
  • コード管理/ CodeReview
    • Github
    • Gerrit
  • 監視 / 解析
    • Mackerel
    • NewRelic
    • Cacti
    • Nagios
    • Zabbix
    • Datadog
      • 最近導入を開始
  • 脆弱性検査
    • Vuls
    •  (app検査は別途やっています)
  • CI
    • Jenkins
  • Integration / ChatOps
    • Slack

検証や個人利用を含めますと他にもありますが、チーム内ではだいたい上記を利用させていただいています。
そして、この場を借りて作成者に心からの敬意を表します。

[DevOps] Infrastructure as Code / Configuration as Code と 品質管理 / TDI

弊社でも
CodeでInfraを管理する
という業務を主体としています。

インフラ自体の品質管理も考慮していて、
テスト = Test Driven Infrastructure (TDI: これについては後ほど説明をします。) も、行うようにしています。

以下の記事が大変参考になり、強く共感しました。

Ito naoyaさんの Infrastructure as Code
https://speakerdeck.com/naoya/infrastructure-as-code
あるべき姿をコードにする、自動化するだけではない まさに構成管理の本質を捉えた言葉だと思っています。

このインフラを定義/宣言するやり方/捉え方は、現在のDockerでもInfraKit でReleaseされているものが近い思想に見えます。(InfraKitは、Docker for AWS/Azule からの流れとのこと)
https://blog.docker.com/2016/10/introducing-infrakit-an-open-source-toolkit-for-declarative-infrastructure/
https://github.com/docker/infrakit/blob/master/README.md
http://qiita.com/yamamoto-febc/items/2cd260ba956e1a3da78e

ちなみに Consul 等のClusterでも同じことが行えます。(Infrakitほど楽にできるかどうかは別として)
このあたりは目指している方向が同じと言えそうです。 (システムの自律化, NoOps)
期待しています。

CodeReview

重ねますが、品質管理/変更管理/リリース管理 は常に意識していて
我々も日々CodeReviewを行っています。

_WIP__Ansible2_2_support_by_aim-oguma_·_Pull_Request__412_·_aiming_infra-ext

私たちは新卒1年目から積極的にDevOps, CodeReviewに参加させています。
CodeReviewは、本当に素晴らしいと思います。

Banners_and_Alerts_と__Ansible_severspecでカーネルパラメータをチェックするロールの作成_by_sycho21_·_Pull_Request__326_·_aiming_infra-ext

合理的かつ、安全性や品質が上がり、スキルも全体的に上がるなど
チーム全体どころか会社全体どころか社会的にも良いことだらけです。

他社のインフラ関連のエンジニアで
CodeReviewを取り入れている会社は多々ありますが、
もし まだCodeReview を取り入れていないインフラチームがありましたら、ぜひ Github-Flow で取り入れることを強くオススメします。

AimingInfraStudy__Ansible編_Vol-1_

今回はここまでです。

次回は少し技術よりの話にして
Ansible の Tips, 最新版2.2の注意点、
VagrantのTipsなどをいくつかご紹介していきたいと思います。


mori

インターンシップに参加した学生さんにインタビューしてみました@大阪


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

毎年10月、Aimingには、HAL3校(東京/名古屋/大阪)から、インターン生の皆さんがやってきて、1カ月に渡って社内でゲーム制作を中心に、みっちりと就業体験を行います。

今日は、大阪スタジオでのその様子について、学生さんへのインタビューも併せて、レポートしたいと思います!今年は大阪へ、16名の学生さんがきてくれました。

まずは概要から。

概要1

16名を2チームに分け、それぞれでゲームを制作してもらいます。

今年はのテーマは、

「「Aim(狙う)」をコンセプトに、Unityを使って、通信機能のあるPCゲームをつくろう!」です。各チーム、エンジニア5名、プランナー2名、デザイナー1名という構成で行います。メンターとして、Aiming新卒スタッフの2名がフォローにあたりました。

(どんなAimなゲームが出来るのでしょうか、わくわく・・・!)

概要2

ゲーム制作以外にも、「先輩トーク」なる、Aimingの様々な職種、レイヤーのスタッフがそれぞれの分野について紹介するという講座を全7回で実施しました。

また、

いくつかの題材について、グループワークも行いました。

 

その中から、「アジャイル開発をぎゅぎゅっと凝縮、LEGO®を使ったスクラム体験」を紹介します。(インターンさんから、これがおもしろかった!という意見が多数あったため。)

スプリント計画

スプリント計画の様子

(プロダクトバックログに従い、LEGO®を触ってイメージを描きます。)

タスク管理はカンバンで

タスク管理はカンバンで

(落とすべきアクションが具体的になっていきます。全てDONEできるかな?)

成果物!

成果物!

(プロダクトオーナーもびっくりの立派なお城ができました。)

 

成果

最終日、1カ月かけて作ってきたお互いのゲームを、Aimingスタッフに向けてプレゼンし、試遊会を行いました。

Aチーム、Bチームそれぞれのゲームをちょこっと紹介

Aチーム

チーム名: あいサー ゲーム: IMPERSOMAID

タイトルA

(3Dの隠れんぼと鬼ごっこを足したような通信対戦ゲーム。侵入者は屋敷内のお宝を狙い、メイドロボット側は侵入者をつけ狙います。窓を拭くなどのメイドらしいアクションもできたりします。)

ゲーム画面Aゲーム画面A_2

3D三人称視点による、侵入者とそれを撃退するロボット側とに分かれての4人通信対戦のゲームです。侵入者はロボットに紛れ、広い屋敷内にある金塊を一定数盗み出せば勝利。ロボット側は仲間とスタンプでコミュニケーションを取りつつ、侵入者用の転送装置を全て破壊できれば勝利というのが基本ルールです。

お互いに気づかれないように行動する必要があり、プレイ中は緊張感が絶えずハラハラドキドキしたプレイ体験ができる中々手応えのあるゲームが完成しました!

ロボットが気付かれないように、窓を拭いて演技をする仕草が可愛かったです。


 

Bチーム

チーム名: はがねで じゅうはち えふ ゲーム: ハロウィンパーティーホラーゲーム

(なかなか個性的なチーム名ですね。)

スクリーンショット 2016-11-04 10.33.01

(ハロウィン感たっぷりの可愛らしい仕上がり。ロゴも決まってます。演出が凝っていて、演出だけに1人を割いて仕上げてきた完成度はすごい。ローディングもおしゃれで楽しい。)

キャラクターセレクトBゲーム画面B

3D見下ろし型の人とおばけによる鬼ごっこ。1人vs3人で通信対戦ができます。人はロウソクを拾って3つの燭台に火を灯せば勝利。おばけは3人を気絶させれば勝利というのが基本ルールです。灯したロウソクの明かりの範囲内に入るとおばけの姿が見え移動が遅くなったり、気絶から復帰できたりと、このロウソクがゲームデザインのコアになっています。

鬼ごっこの追われ逃げ惑うという体験が再現されており、ロウソクによるゲーム的なフィーチャーも上手く作用して楽しいゲームプレイができます。ロウソクの操作に慣れるまではおばけがとても強い!試遊会の一発目は、おばけに瞬殺されていました。また、タイトルやマッチング画面などインゲーム以外のヴィジュアルも凝っていて見て楽しいゲームになっていました。

 

学生インタビュー

各チームを代表して、それぞれのリーダーに、この1カ月を振返ってのインタビューを行いました。(インタビュー:森、Aチームリーダー:張くん、Bチームリーダー:白水君)

森:1カ月お疲れ様でした!インターンを通して、率直にいかがでしたか?

張:すごく勉強になりました。これまで学校で経験したチーム制作は、「チーム制作」とはいえど、出来る人の力量に頼って個人が進めていくことが多かった。ですがここで経験したチーム制作は、本当に役割を分業し、切り分け、全員で制作にあたることができました。

白水:概ね良好に進めることが出来ました。今回ここに集まったメンバーは、皆が意欲、モチ ベーションがすごく高いので、何か問題が発生した時に、チーム全員がその解決に向けて 全力で取り組む姿勢があった。その中で開発を行うことが出来た経験は自分にとってもプラスになりました。

森:インターン期間に期待していた体験ができましたか?

白水:実際の現場でネットワークや運営知識を吸収したいと期待していましたが、まさにその体験ができました。調べても出てこないところを現場の方に掘り下げて聞くことが出来たことが本当に良かったです。

張:プロの開発現場の雰囲気を知りたいと思ってました。実際、現場を見て不安が減りました。開発室が一体となっていて、作業をこなすというよりは、「皆でゲームを作ってる」という雰囲気を肌で感じることができた。

森:一番印象に残ってることを教えてください。

張:全部が勉強でした。学校の勉強より、「勉強してる」と実感しました。グループワークのスクラム体験はとても面白かったです。

白水:初日です。16人をまとめて会社に連れてきた時、「大丈夫かな」と心配だったけど、 スタッフの方が温かく迎えてくれたので、安心しました。でもすごく緊張していました。あと、学校に戻ったら、教わったアジャイル開発の知識を生かせるかもしれない。チーム作業に取り入れてみたいと思いました。自分は職歴があり、前職はSEをやっていたから、上流工程、下流工程の意識が根付いてた。なのですごく新鮮でした。

森:Aimingのココが変だなって感じたところはありませんでしたか?

白水:良い意味で、なのですが、プランナーの人ってもう少し、ガツガツと自分の意見を通していく、推しの強いイメージがあったのですが、Aimingで接したプランナーは皆さん物腰が柔らかく、丁寧で意外でした。それでもおっしゃる意見は核心をついていて、コミュニケーション力の高さを感じました。

張:イメージでは、「ゲーム業界=辛い」、皆がヘロヘロになり仕事してると思ってたけど、そんな雰囲気を感じなかった。

森:(そんなこともないのですけどね、辛そうな時もありますけどね)

森:成果物を自己採点すると?

張:60点です。皆良い意見を持っていて、それぞれが良い意見なので、想いが強く、まとまらない時があった。後半は改善しようとしたけど、コミュニケーションをもっととるべきだった。もっと他者を理解すべきだった。プログラムがバグだらけになってしまった。でも演出は素晴らしい、演出担当の2人のおかげです。

森:ハロウインの演出は本当によく出来ていて、驚きました!

白水:80点くらいです。やりたいことは詰め込めたけど、ゲームを面白くするところまで持っていけなかった。試遊した人が「おもしろい」って素直に言ってくれる人が少なかったです。それは、そこまでいけなかったから。あと、チーム間でもっと連携し、閉鎖的にならず、コミュケーションとりあった方がよかったね。

張:鎖国になってしまってごめんね。

森:(実際の開発でもありそうだね)

 

森:学校に戻ったらこの経験は生かせそうですか?

白水:プログラミングについての理解が深くなりました。就職作品展にも活用できそう。

森:それは楽しみ!

張:ゲーム会社に入りたい気持ちが一層強くなりました。頑張らないと!

森:ありがとうございました!

まとめ

11月に入り、16名の皆さんは学校に戻られていきました!インターンでの体験が少しでも役立ち、参考になれば嬉しいです。Aimingでは、通年を通してインターン生の受入れを行っておりますので、学生の皆さま、是非お越し下さいませ。

※社会人も歓迎です。

おまけ


リザルトB

 

 

 

 

ハッピーハロウィン(おそい)

おわり。


夏季インターンシップ


基盤開発チームの内藤です。

弊社では夏季インターンシップを二回予定しておりその一回目を実施した際にメンターをやらせていただきました。すっかり秋めいて冬の訪れを感じる季節になってしまいましたが、その時のことを書きたいと思います。

 

まず、インターンシップの内容としては参加人数は3人で職種は全てエンジニア、期間は2週間、一本のゲームを作ってもらおうという内容で実施しました。

ざっと期間中の内容を羅列すると

  • 作成するゲームの決定(Photonを用いてネットワーク対応)
  • メンターによる開発に関する説明
  • インセプションデッキ、MVPの作成、ユーザストーリーの作成及びポイント見積もり
  • Github, PRをベースとした開発の説明
  • 成果物発表、プレゼン
  • メンターによる成果物へのコードリーディング、レビュー
  • KPT

と、かなり盛りだくさんとなっており

ただ、コードを書いてゲームを作るというだけでなく

我々の実際の業務フローに近い形を経験してもらい、なぜ我々がそういった開発手法を

用いるのかということも経験してもらおうという狙いです。

常日頃から思っていることですが、ホワイトボードはいろいろなことに使える万能ツールとして圧倒的な正義を感じます。

 

KPT

インターンシップ終了時にKPTを行いました。

Keep

Keepから見ると、ゲームが完成した喜び、新しい技術に挑戦したことによる達成感が大きいようです。チームが仲良くできたのも良かったですね。

今回githubでPRベースでの開発を行いチーム開発を知ってもらえたのも良かったですね。

Keep

KPT01

Problem

ゲームを作る上でどこまでもブラッシュアップしたいという気持ちは当然として

gitは慣れていないと大変なのだなぁという感想です。

今回は自分のほうでgitへのサポートを手厚めにすることを意識したのですが、それでもなおgitに苦戦する姿が印象的でした。(怖くないよmerge, rebase)

Problem

KPT02

Try

Tryに関しては直接ホワイトボードに書き込みました。

インターンシップ終了時に行ったのでKPTのサイクルからは外れてしまいますが

あるある感があるやつが多いので今後の活動に役立つといいですね。

Aiming側のインターンシップの課題

弊社ではインターンシップ終了時KPTを行ってきましたが、毎回違う社員がメンターを行っており、うまく次のメンターとの連携が取れずTryを次のインターンシップに活かしきれていないというのを感じています。

これまでAimingでは何度かインターンシップを実施させていただきましたが、

今後はより質の高いインターンシップのために、インターンシップそのものの改善にも取り組みたいと思っています。

手始めに過去のKPTの画像からどんな事が出てるのかまとめ始めています。

最後に

小難しいことは抜きにして、単純にインターンシップが楽しかった、得るものがあったと言ってもらえたのでよかったですね。少しでも弊社インターンシップでの経験が今後の社会人、エンジニア人生に役に立てば幸いです。

内藤でした。


菅野 明洋

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


はじめに

初めての人は初めまして、前回の記事(まべ☆てっく vol.1に登壇してきました!)見てくれてる人こんにちは!
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

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

GGLTとは

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

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

今回の発表は、剣と魔法のログレス いにしえの女神で使われている技術やノウハウの話になります。

■菅野明洋:スマホ版ログレスでグローバル展開を想定したサーバ構築をAnsibleで試してみた話

■藤井章暢:スマホ版ログレスにポストエフェクトを組み込んだ話


私の方ではAnsibleでの設定例を中心に発表しております。
Ansibleとなりますと、色んな書籍やブログ等でベストプラクティスや使用方法が記載されていると思いますが、今回の発表ではグローバル展開を想定した際に、どのように工夫をしたのかをまとめました。
グローバル展開を行ったとしても、サーバの構成が一切変わらないとなれば特に悩む必要はないのですが、現地のインフラ事情や新規実装を行うとなると日本版と全く同じサーバ構成と言うわけにはいかないケースもあると思います。
構成を国やデータセンター毎の差分を管理を行い、各地で行った改善内容を別の地域へ反映するなど相互的に良い事を取り込み合うことが出来たら良いかなと思いました。

藤井の発表では、クライアントにポストエフェクトを導入した話になります。
戦闘中のシーンに合わせて放射線状にブラー処理を入れ、従来の戦闘シーンをより迫力のあるシーンにしています。詳しくはスライドをご覧ください。

■発表中の様子

2016102402

発表中の菅野

2016102401

発表中の藤井

感想

LTとなりますと、「あれもこれも話したい。でも時間がない」といった葛藤があります。
ベースとなる発表資料は一週間から数日前には完成していたのですが、発表直前までスライドの編集したり脳内練習したり等、発表直前まで調整していました。

結果的には、一回目のドラがなったラスト1分前で私の喋りがスピードアップし、制限時間の終了を表すドラと同時に「ご静聴ありがとうございました」と言う形になりました(ギリギリセーフ?)。

最後に

GGLT運営の皆様、会場に来場した方々、登壇の機会を頂きありがとうございました。
とても貴重な経験をさせていただくことができました。


taki

剣と魔法のログレスにおけるバックアップのお話


ご無沙汰しております、ソフトウェアエンジニアの滝です。
今回は、Webブラウザ版 『剣と魔法のログレス』 (以下ログレス)のデータバックアップのお話です。

1日あたり数GBという膨大なデータが出力されるため、どのようにしてバックアップを取りどのように保管しているかについてお話したいと思います。

何のバックアップを取っているか?

ログレスでは、お客様のサポートや動向調査のために、行動履歴データが含まれるログデータやデータベースのバックアップを行っています。

バックアップはいつとっているのか?

データベースは毎朝定期的にバックアップを出力しています。
所要時間は1時間程度ですが、1日につき数GBのダンプデータが出力されます。
ログデータは、ゲームサーバーが出力したものを取得します。
これらのバックアップファイルは、社内のログ管理サーバーにキャッシュされ、定期的に圧縮作業を行っています。

バックアップデータはどのように保管されているのか?

ログレスでは月に一度、LTO(磁気テープ)にバックアップデータを書き込みます。
バックアップするデータは毎月cronで月初に圧縮され、一時的に別のディスクスペースに置かれます。
バックアップが完了すればメールが届くので、内容を確認してLTOに書き込みます。
数年前のプロジェクトでは、当時DVD-Rを使ったバックアップを行っていましたが、技術が進歩し記録メディアの大容量化進んで単価が安くなったため
現在そのプロジェクトでは、ブルーレイディスクでのバックアップを取っています。
ログレスも2016年5月まではブルーレイディスクへバックアップをしておりました。
しかし、ログレスのバックアップデータは圧縮しても1月あたり約160GBありますので、ブルーレイディスクを複数枚に渡って書き込む必要があり、それらの作業を自動化するには難があったため、LTO化することになりました。

終わりに

簡単ではございますが、ログレスのバックアップのことについてお話させていただきました。
オンラインゲームを運営する上では、あまり表の話に出ないバックアップですが
バックアップは、データ復旧などのもしものことがあった時だけでなく
様々な調査や分析にも使われる大切なデータです。

今回は、現場の裏側のそのまた裏の話ということで、以上バックアップのお話でした。