2019年07月31日

Kubernetesについて

こんにちは。
サーバプログラマのオカダです。
現在関わっているプロジェクトでKubernetesを使う事になりそうなので、その辺のところをお話します。

https://www.redhat.com/ja/topics/containers/what-is-kubernetes
「Kubernetesとは、Linuxコンテナの操作を自動化するオープンソース・プラットフォームのことです。」

そして、Linuxコンテナとは、システムの他の部分とは分離された一連のプロセスです。
https://www.redhat.com/ja/topics/containers/whats-a-linux-container
と、あります。訳が分からないですね。

さて、プログラムというのが何か、というと要するにデータを加工するものです。
その考えでいくとプログラムの簡単なモデルというのはこんな感じですね。
図1.png
しかし、これだけだと中でだけ完結してしまって何の役にも立たないから入出力を付ける訳です。
キーボードなりマウスなり、更にはディスクなりから入力されたデータを、
プログラムを通してディスプレイなりに出力する。
しかし、キーボードやマウスなどは付け替えることができますね?
別の機器に付け替えても問題なく使える、という部分は、簡単に言うと
WindowsなどのOSが受け持っているのです。
そして、複雑なプログラムなんかだと複数のプログラムが組み合わさって動作しているので、こんな感じですね。
図2.png
では、このプログラムの言うなれば「塊」をまとめて扱えるようにしたらどうなるか?
ここで、Linuxコンテナの話が出てきます。
イメージとしてはこんな感じでしょうか?
図3.png
この例に出てくる「入出力を管理するプログラム」はつまり、プログラムとOSの間に挟まって管理する事で、自身の上で動いているプログラム全体を管理する訳です。
入出力を握られると、中のプログラムにとっては一つのサーバマシン環境のように見えるので、ホスト側からはこの全体(1つのサーバ環境)自体を一つのプログラムのように扱えます。
つまり、「プログラムを一つ立ち上げるように」サーバを立ち上げる事が出来るようになるのです。

Kubernetesは、以上の技術を応用して、主にサーバプログラムを管理するものとなります。

Kubernetesのカバー範囲が広いので全てを1つの記事で説明する事は困難ですが
例えば、オンラインゲームを運用していると
期間限定イベントの開催などでアクセスが集中するような事があります。
アクセスが集中しても問題ないようにイベント期間中はサーバを増やしたい、
そのような時にKubernetesを使用していれば以下のようなマニフェストを発行します。

--------------------------------------------------------

apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 30
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80

--------------------------------------------------------

replica: 30という行がありますが、
この行は「同様のサーバを30個建てる」というような意味合いになります。
その上、それぞれのサーバを監視して落ちた場合には
マニフェスト通りに30のサーバが再度立ち上がるように管理してくれるのです。
イベントが終了したら、replica: 3とでも修正して適用すれば
アクセスが無くなったサーバから落としていって3つだけサーバが立ち上がった状態、
つまりイベント期間外である通常の状態に戻してくれます。

このように数字を設定するだけで管理はKubernetesが自動で行ってくるので
容易にサービスを拡縮することができます。
この管理というのは、前述のようなサーバ監視部分であったり、
サーバを複数立ち上げようとした際のポートの管理であったりと実に様々なことが考えられます。
本来であればそういった点は自力でケアする必要がありますが
Kubernetesを導入していればある程度カバーしてくれるので
柔軟で堅牢なサーバ環境を構築できるのです。



以上Kubernetesについて一部紹介しました。
弊社ではまだ検証中のところはありますが既に様々な企業や分野で導入されています。
サーバプログラマを目指している方は知っておいて損することは無いのではないでしょうか。
それでは。

posted by byking at 17:05| 開発

2019年07月24日

夏の初体験

こんにちは。デザイナーのナリアイです。
まだまだ長い梅雨を抜け出せない毎日ですが、
7月になりバイキングにも夏季休暇の季節が参りました。

バイキングの夏季休暇は少し変わっていて、
7月から9月の間の好きな日に3日間休日を取得できる制度になっています。
3日連続で取得するのも、1日ずつバラバラに3回取得するのも自由です。

僕は旅行が趣味なので、夏季休暇を利用して夏らしい場所に行ってきました。
夏といえば海!…という事で選んだ先は沖縄の石垣島ですっ!

東京は記録的なほど日差しの少ない状態ですが、
石垣島は一早く梅雨明けをして、夏らしい日差しが照り付けていました。


1907241.jpg


実は、今回の旅行には目的がありました。
それは『初体験』をすることです!
(…まさか卑猥な事を想像してませんよね?)

ビデオゲームというのは、
ユーザーに様々な疑似体験をしてもらうコンテンツだと思います。
その為、ゲームの開発者は様々な体験をしておくことが重要だと思っています。
そこで今回まず行った「初体験」はスキューバダイビングです。


1907242.jpg


数メートル潜っただけで来る水圧による耳の痛さや、
呼吸を気にしないと生死に関わる感覚は想像以上でした…。

ただ馴れてしまえば、
息切れを気にせず海底に居られる感覚はなんとも不思議。
テレビの映像などではわからなかった感覚です。

次の「初体験」は乗馬です!


1907243.jpg


漫画『キングダム』が好きな僕は、
自分で馬を操作する乗馬に憧れていました。

今回は浜辺を乗馬できる初心者用サービスを利用しました。
馬の乗り方や手綱の使い方を教えて頂き、浜辺のお散歩に出発です。

キングダム好きとしては馬に跨(またが)った時、
やはり『これが将軍の見る景色…』と思いましたw。
(…浜辺で馬なので、どちらかというと「暴れん坊将軍」ですね。)

また自分が操作するとはいえ、
相手は生き物なので車などとは全く違う感覚です!
これもまた貴重な経験になりました。



今回の旅行で体験した経験は、
今後のゲーム開発のどこかに生かしていきたいと思います。

ゲーム開発に興味がある皆さんも、勿論ゲームの経験や知識は大事ですが、
たまにはコントローラを置いて変わった体験をしてみてください。
きっと新しい体験をユーザーに届けれるきっかけが見つかるかもしれませんよ。


posted by byking at 15:46| 日記

2019年07月17日

休日の過ごし方 〜プランナー編その2〜

こんにちは。
企画のノグチです。

突然ですが、
自分の行ったことのない場所に行くのってワクワクしませんか?
自分がやったことのないゲームでもそうですし、みたことがない映像作品、漫画、書籍、料理なんでもですが新しいものに触れると自分はワクワクします。
殊更、新しい場所に行くのは見たことのない景色に触れられるので、とてもワクワクします。

ということで、まだ見ぬ出会いを求めて休日に福岡に行ってきました。
※とあるイベントに参加するためでもあります

今回はその模様を書きたいと思います。


まずは羽田発のフライトで北九州空港へ。
目的地は博多だったのですが、どうせ同じ県内だし近いだろと北九州行きを選びました。
到着まで1時間30分ぐらい かなり早く着きますね。
これは存分に観光できるぞ〜とうきうきでした。

が、
北九州についた後はバスと電車に揺られること2時間弱。
ようやく博多につきました。思ってたのと違う。

調べろという話なのですが……。
こういうハプニングも旅の楽しみですね!
人によりますが。

博多についた後は、
イベントが始まるまで色々なところを観光しました。

まずは、腹ごしらえに博多豚骨ラーメンと明太子ご飯
写真1.png

いわゆる泡系豚骨というやつです。
とてもクリーミーで大変美味しく、替え玉までいただきました。


ご飯を食べた後はぷらっと天神方面を目指して歩きました。
その中でこんなものを見つけました
写真2.JPG

なんでもお祭りがあるらしくそれのお神輿だそうです。
残念ながらお祭りは日程的に見ることができず……。
次は見に行きたいですね!

そうしてぷらぷらしていると小腹がすいてきます。
そんなときにはこれ、久留米ラーメンです。
写真3.JPG

ろくすっぽ下調べしていかなかったので、
ラーメンぐらいしか知識がなく、ラーメンばかり食べています。

こちらは博多ラーメンとは違ってかなりこってりした味わいです。
後麺もこちらのほうが若干太い感じがしました。


最後は時間が来たのでイベント会場近くで海をぱしゃり
写真4.JPG

2日間いましたがとても楽しい街です。
もっと色々なところを見て回りたかったです。


なんでもそうですが、
やっぱり新しいものに触れるのはとっても楽しいことですね。
この楽しさが学びの楽しさだなと思います。
日々勉強するためにも、
仕事だろうとプライベートだろうと
常に新しいことに挑戦していきたいですね。

ではでは。

posted by byking at 14:55| 日記

2019年07月10日

UE4のデリゲートについて

こんにちは、プログラマのカコです。

今回はUE4のデリゲートについて紹介したいと思います。
と言っても初歩的な事ばかりなので
デリゲートをあんまり使ったことが無いという方に向けた内容となっております。
また、詳しい使い方はUE4の公式ドキュメントを見れば済むので
ここでは簡単な使い方や個人的な使用感を適当にかいつまんでお話します。
https://api.unrealengine.com/JPN/Programming/UnrealArchitecture/Delegates/index.html


・どんな場面で使うか。

実に多岐に渡り利用することができます。

例えば、プレイヤーの攻撃が当たった時を考えます。
まず攻撃が当たったとき用のデリゲートを用意します。

攻撃が当たったときに画面上にヒット表示を出したいとなれば、
ヒットくんをこのデリゲートに登録します。

190710@.jpg

これで攻撃が当たった時にプレイヤーは何も知らなくても
当たった!と発信するだけで勝手に画面上にヒット表示がでます。

190710A.jpg

与えたダメージを集計したい場合があるかもしれません。
その時もスコアくんをプレイヤーの同じデリゲートに登録します。

190710B.jpg

こうすることでプレイヤーは当たった!と発信するだけで
ヒットくんが画面上にヒット表示を出し、スコアくんが集計をしてくれます。

190710C.jpg

このように必要になった時に都度登録することで、
その時に誘発して発生する処理を簡単に呼び出すことが可能になります。
またこの時プレイヤーは発信しているだけなので勝手にデリゲートに登録したヒットくんやスコアくんの存在を知らずともそれぞれの処理を呼び出しています。

他にも攻撃を当てられたとき用デリゲートや倒されたとき用デリゲートなどが考えられます。
この時にこうしたいああしたいといった対応が必要になりそうな物はデリゲートにしておくと開発が楽になるでしょう。




・UE4のデリゲート
C#のデリゲートに似ている気がします。
宣言できる物が複数ありますがざっくりと以下のような感じです。

@ デリゲート
登録できる関数:1個
A マルチキャストデリゲート
登録できる関数:複数
B イベント
Aの発信できるクラス制限版
C 動的(マルチキャスト)デリゲート
@とAのブループリント公開版

大概はAのマルチキャストデリゲートを利用します。

ブループリント上に公開されるときは「イベントディスパッチャー」と表示されるので、
それに乗っ取り弊社では「On~EventDispatcher」という命名規則で宣言しています。
-----------------------------
AMyCharacter
// 攻撃が当たった時のイベントディスパッチャー宣言用マクロ
DECLARE_MULTICAST_DELEGATE(FOnHitAttackEventDispatcher);

// 攻撃が当たった時のイベントディスパッチャー
FOnHitAttackEventDispatcher OnHitEventDispatcher;
-----------------------------


この作成したキャラクターのイベントディスパッチャーにヒット表示用widgetの関数を登録します。
-----------------------------
UHitWidget
// 攻撃が当たったらヒット表示
void OnHitAttack();

// 登録
MyCharacter->OnHitAttackEventDispatcher.
AddUObject(this,&UHitWidget::OnHitAttack);
-----------------------------

あとはキャラクターが攻撃を当てたタイミングで、

OnHitEventDispatcher.Broadcast();

を呼ぶことでAMyCharacterはUHitWidgetの存在を知らずとも
UHitWidgetのヒット表示関数を呼び出せるようになります。

この作成したキャラクターのイベントディスパッチャーにヒット表示用widgetの関数を登録します。
-----------------------------
UHitWidget
// 攻撃が当たったらヒット表示
void OnHitAttack();

// 登録
MyCharacter->OnHitAttackEventDispatcher.
AddUObject(this,&UHitWidget::OnHitAttack);
-----------------------------

あとはキャラクターが攻撃を当てたタイミングで、

OnHitEventDispatcher.Broadcast();

を呼ぶことでAMyCharacterはUHitWidgetの存在を知らずとも
UHitWidgetのヒット表示関数を呼び出せるようになります。




・引数の追加
実行するときに引数を渡すことができます。

宣言用マクロの末尾に「_OneParam」や「_TwoParams」と追加することで任意の引数を渡すことが可能です。
先程の攻撃が当たった時のイベントディスパッチャーにどれくらいのダメージ量だったかを追加してみます。
-----------------------------
AMyCharacter
// 攻撃が当たった時のイベントディスパッチャー宣言用マクロ
DECLARE_MULTICAST_DELEGATE_OneParam(FOnHitAttackEventDispatcher, float);
// 実行
OnHitEventDispatcher.Broadcast(DamageValue);
-----------------------------
UHitWidget
// 攻撃が当たったらヒット表示
void OnHitAttack(float DamageValue);
-----------------------------

これでダメージの値を渡すことができるようになりました。
「_NineParams」まであるようなので他にも何か伝えたい情報が増えてもあと8個追加することができます。

当然このイベントディスパッチャーに登録した関数の引数も増やす必要があります。
もし数十種類のオブジェクトが関数を登録している場合、その数だけ引数を修正することになるでしょう。

こうなる前に引数が増えそうで登録数の多くなりそうだと予想されるイベントディスパッチャーの引数はクラスや構造体にしてまとめておくのがオススメです。
そうすればメンバ変数を増やすだけで済みます。
「_FourParams」辺りになってきたら実装を見直すべきかもしれません。




・その他小技
当然エンジン側の実装でもデリゲートが出てきます。
例えば以下は、アセットの非同期読み込みに利用されるデリゲートです。

DECLARE_DELEGATE(FStreamableDelegate);
FStreamableManager::RequestAsyncLoad(…,FStreamableDelegate DelegateToCall, …);

読み込みリクエストの関数の引数として登場し、読み込みが完了した時に任意の関数を呼んでもらうことができるようになります。
ただし引数無しデリゲートなので特に情報を渡すことができません。

例えば、読み込んだアセットを固有の整数型で管理していた場合、読み込み完了したことが分かっても何番のアセットが終わったかまでは分かりません。

エンジンのソースを変更して引数を追加してもいいですがそれも手間です。
そんなときは、登録時にCreateUObjectを呼ぶことで任意の引数を渡すことができるようになります。

-----------------------------
RequestAsyncLoad(…,FStreamableDelegate::CreateUObject(this, &FMyClass::OnComplete, AssetId),…);

// 読み込み完了
FMyClass::OnComplete(int32 AssetId);
-----------------------------

こうすればエンジンのコードに手を加えることなく独自の実装をすることが可能です。
覚えておけば役に立つ日が来るかもしれません。



・終わりに
以上かなり説明を省きましたがUE4のデリゲート紹介でした。
呼び出す側がオブジェクトの型を知らずとも任意の関数を呼び出せるということは、余計な参照を増やさずに済むのでデリゲートを使いこなすのはかなりオススメです。

UE4はデリゲート以外にもまだまだ便利な機能はあります。
公式ドキュメントや個人ブログなどUE4は情報が充実していますので
読み漁ってみては如何でしょうか。

それでは、また。
posted by byking at 17:30| 開発

2019年07月03日

激論!?リグナイト!

こんにちは、モーション担当のこでらです。
去年の暮れの話となりますが、BACKBONE様のお誘いでリグナイトという
集まりに参加させていただきましたので、今回はその時の話をしたいと思います。

さて…いきなりですが、
みなさんはモーションの仕事ってどういうものか具体的に答えられますか?

大抵の方は「キャラクターを動かす」或いは「カメラワークをつける」
といったあたりを想像するかと思いますが、
実は他にも絶対にはずせない超重要な作業がひとつあります。

それがリギングという工程です。

例えるならば、関節のある人形に操作する糸を括り付けたマリオネットが如く、
アニメーターが実際にモデルを動かせるようリグ(仕掛け)を組み込んでいく
工程となります。

1907041.jpg
リグの精度はクオリティと作業効率に直結するモーションの生命線!

このリギング作業をする人のことをリガーと言いますが、
アニメーターの要望を踏まえてリグを設計する必要があるため、
この両者の意思疎通がとても大事になってくるわけです。

その中で、リガーが言いたいこと、アニメーターが言いたいこと、
また、会社や業種による違い
といった、普段なかなか話されにくい事を
気楽にみんなで話しましょう!というのがこのリグナイトなのです。

今回のお題は「GUIとコントローラー」ということで、
映像業界とゲーム業界から一線で活躍するリガーやアニメーター達によって
議論が進められました。
内容はかなりコアな部分まで掘り下げられたところもありますので
詳細は割愛しますが、ざっくりとした感触では
映像とゲームでは求められるところが違うんだなーというのを
あらためて再確認した感じです。

映像は平面重視でレンダリングした画像が全てですが、
ゲームはあくまでもデータとして立体重視なので出力を意識した設計
というのが大きいですかね。

1907042.jpg
より簡単に操作できるようにするために、その裏側では複雑な計算式が仕込まれている

ただ、それでもリグの触り心地というものは業種間を超えた共通理解も多くて、
「リガーあるある」や「アニメーターあるある」が議論のなかに
たくさん出てきました。
普段お会いする機会のない方々なのに、何度も「ですよねー」と
うなずける場面に出会えたのはとても楽しい体験でしたよ。

リグナイトの内容分析はBACKBONE様のブログにまとめてありますので興味ある方はぜひご一読を。
http://backbone-studio.com/rignightv02-secondpartact/

ではまた。



posted by byking at 10:22| 日記