Aiming 開発者ブログ https://developer.aiming-inc.com Aiming 開発者ブログ Mon, 23 Dec 2024 10:45:03 +0000 ja hourly 1 https://wordpress.org/?v=6.5.2 /wp-content/uploads/2018/08/cropped-favicon-32x32.png Aiming 開発者ブログ https://developer.aiming-inc.com 32 32 『エンジニア採用専門サイト』ができるまで https://developer.aiming-inc.com/misc/post-11605/ Mon, 23 Dec 2024 07:35:03 +0000 <![CDATA[未分類]]> <![CDATA[インタビュー]]> <![CDATA[エンジニア]]> <![CDATA[第一事業部]]> <![CDATA[第二事業部]]> https://developer.aiming-inc.com/?p=11605 <![CDATA[はじめに エンジニアの皆さん、はじめまして。 Aiming採用担当です。 入社以来、一貫して採用業務に携わっており、多くのエンジニアの皆さんと出会ってきました。 Aimingの良いところは、何と言っても「やりたいと思ったことを形にできる」ことだと感じています。 入社後のアンケート […]]]> <![CDATA[

はじめに

エンジニアの皆さん、はじめまして。
Aiming採用担当です。
入社以来、一貫して採用業務に携わっており、多くのエンジニアの皆さんと出会ってきました。
Aimingの良いところは、何と言っても「やりたいと思ったことを形にできる」ことだと感じています。

入社後のアンケートや面談で「環境が良い」「人が良い」という声をたくさん聞く中で、“エンジニアの皆さんにAimingの魅力を知ってもらいたい!”という想いから、この度、エンジニア専用のサイトを作成しました。
このサイトを通して、Aimingの開発環境や社風、そして何より、一緒に働く仲間たちの想いを少しでもお伝えできれば幸いです。

Aiming開発者クレド

2011年の設立当初から『Aiming開発者クレド』を掲げ、開発者として働く上での指針としてきました。
しかし、会社が成長し、技術も大きく変化する中で、クレドの一部が現状と合致しなくなっていることに気づきました。
このような状況を踏まえ、私たちは、エンジニア職に特化したページを作成し、クレドの見直しを行うことにしました。
これは単なる情報の更新ではなく、私たちの仕事に対する姿勢や、エンジニアの皆さんにAimingで働くイメージをより正確に伝えるための第一歩です…!

クレドってなに?

クレド(Credo) とは、ラテン語で「信じる」という意味を持つ言葉で、企業や組織が掲げる信条や行動規範のことです。
Aiming開発者クレド は、Aimingで働く開発者たちが、日々の仕事の中で大切にしている価値観や考え方、そして目指すべき姿がまとめられたものとして掲げており、単なる指針ではなく、Aimingの開発文化を形作る根幹となるものです。

なぜクレドが必要なのか?

企業が成長していく中で、様々な課題や意思決定に直面します。
クレドはそうした場面で組織全体が共通の価値観に基づいて判断し、行動することができるのです。

こうしてブログやホームページに掲載する理由は、Aimingを知ってもらい、賛同する人に集まってもらいたいという意図もあるからです。
クレドはどのような価値観を大切にして、どのようなビジョンを持っているのか明確に示すことができます。
自身の価値観と企業の価値観が合致していると感じてもらえれば、入社後のミスマッチを防ぐことも可能だと考えています。

エンジニア採用サイト作成への道のり

発端は、採用サイトの情報が古いことに気が付いたことです。
この機会に採用サイト全体を修正することも考えましたが、
まずは、スピード感を持って『正しい情報を発信すること』を優先度高く取り組むことに決定しました。

Aimingは現在事業部制となっており、4つの部署に分かれています。
私たちが所属している「経営管理部」を除き、
「第一事業部」「第二事業部」「事業支援部」がゲームの開発に関わっています。
今回は部署に関係なく、Aimingのエンジニア専用の採用サイトを作成するために、各事業部のエンジニアマネージャーと打ち合わせをして進めました。

エンジニアが集まると話題がつきません。
クレドを決めるための会議だったのですが、話はそれにそれ、、結局会議では決ま…ら…な…

ところが会議終了後に、ある事業部のエンジニアマネージャーから「そういえば、クレドのたたきできてますよ」と情報が…!(なぜ今言うー!)
内容を他事業部のエンジニアマネージャーにSlackで共有すると、席の配置以外は全社一致! 開発指針は事業部に関係なくAimingに根付いていたことに安心しました。

クレドをたくさんの人に知ってもらうには?

次はこのクレドをどうやって浸透させていくかという課題があります。
社員はもちろんですが、社外の方にも広く知ってもらうにはどうしたらいいのか…
そもそもクレドの更新は、「私たちの仕事に対する姿勢や、エンジニアの皆さんがAimingで働くイメージをより正確に伝えるため」という想いから始まりました。
(そうだ!クレドを軸にエンジニアの魅力を伝えなければ…!)

webデザインのマネージャーからの提案を受け、クレド更新と同時に『エンジニア採用専門サイト』を作成することに。
年内までに必ず作成しよう!という決意のもと、サイト作成がはじまりました。

デザインスタート

サイト作成の課題は2つ、
・”Aimingのエンジニア”採用サイトであるということがわかるようなデザインになること
・サイトを見てくれた方がAimingで働くイメージができること
ここからぶれないようにwebデザインチームにページデザインをおこなっていただきました。
途中に出てくる案のすべてが素敵すぎて混乱した私たちでしたが、
最終的には社内のエンジニアに意見をもらいながら、細かい修正をしていただきデザインの方向性が固まりました!

Aimingの魅力は?

Aimingの魅力はやっぱり『人』
社内インタビューを進めていくと、◎◎さんって人の経歴や仕事っぷりにあこがれて入社した!面接官の◎◎さんとこういう話で盛り上がった!◎◎さんの技術が半端ない!
などたくさんの『人』にまつわる話を聞くことができます。

魅力的な社員が多く在籍していることを、ぜひたくさんの人に伝えたい!と思い、今回はインタビューページをサイト上部に掲載しました。
最近入社した方にもインタビューしたり、過去にインタビューした方の写真を撮影し直したり、新しいインタビューコンテンツにチャレンジしたり盛りだくさんの内容になりました!(新しいコンテンツは来年掲載予定です…!お楽しみに!)

こういったサイトを作成するときに外部の業者さんを使うことはよくありますが、Aimingではすべて社員で内製します。
そういった技術力がある社員が多くいるということと、なにより、自分たちが良いと思っているものを伝えるには自分たちにしかできない!と考えているからです。

ついに完成!

こうして出来上がったのが、『エンジニア採用専門サイト』です。
(…え、もうできあがったの?作成しているときは、もっと色々困難にぶち当たったはずなのに…。)
ですが、完成がゴールではありません。
私たちの仕事は、この素敵なサイトをたくさんの方々に見ていただきAimingに魅力を感じてもらえるようにすることです。

そして『世界中にAimingのファンを』増やしていくことです。

最後に

今回は、『エンジニア採用サイトのご紹介とサイトができるまで』をお伝えしました。
冒頭でもお伝えした魅力通り、今回も”やりたい”と思ったことを形にさせていただきました!
古い情報をアップデートしたいな、欲を言えばこの情報をもっとみなさんに知ってもらいたいなという私たちのちょっとした思いから、たくさんの方々を巻き込んで、新しいコンテンツが生まれました!

今後Aimingの魅力を伝えるために、色々なコンテンツが追加されます!(きっと!)
ぜひサイトをご覧いただき、Aimingが気になったら、「中の人と話す」ボタンを押してくださいね!
みなさんとお会いできるのを楽しみにしています。

エンジニア採用専門サイトはこちら
]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/12/DSC08082-scaled.jpg
熊本オフィス1周年! 開設メンバーに聞く、この1年の軌跡と未来 https://developer.aiming-inc.com/kumamoto/post-11562/ Mon, 11 Nov 2024 07:28:10 +0000 <![CDATA[熊本]]> <![CDATA[インタビュー]]> <![CDATA[ゲーム開発]]> <![CDATA[第2事業部]]> https://developer.aiming-inc.com/?p=11562 <![CDATA[はじめに 皆さん、こんにちは!Aiming 熊本オフィスの原口です。 Aiming熊本オフィスは、9月で開設から1周年を迎えました。🎉 今回は、開設当初から熊本オフィスを支えてきた2人のメンバー、吉田さんと石原さんに、この1年間を振り返っていただきながら、熊本オフィスで働く魅力に […]]]> <![CDATA[

はじめに

皆さん、こんにちは!Aiming 熊本オフィスの原口です。
Aiming熊本オフィスは、9月で開設から1周年を迎えました。🎉
今回は、開設当初から熊本オフィスを支えてきた2人のメンバー、吉田さんと石原さんに、この1年間を振り返っていただきながら、熊本オフィスで働く魅力についてインタビューをしてきましたので、その模様をお伝えします。

インタビュー

熊本オフィス開設の背景

原口:はじめにお伺いしますが、なぜ熊本にオフィスを開設したんでしょうか?

吉田(写真右):以前から事業部内で、事業拡大のためには東京だけでは限界があり、地方展開が必要だとの話がありました。そこで候補地を検討した結果、熊本が最適との判断に至りました。

原口:たくさんの地方の中から 熊本が選ばれた理由は何だったのでしょうか。

吉田: 人口が多く人材確保が見込めること、競合他社が少なく将来性があること、そして地元愛が強い人が多く定着率が高いことが魅力でした。

原口:確かに!私も熊本が大好きです!(笑)

吉田: 私は私で、当時その様な話が進んでいるとは知らなかったのですが、妻が熊本出身なので、いずれは熊本に移住することを考えていました。タイミング良くお互いのニーズがマッチする形となり、私が熊本の代表として赴任することとなりました。

原口:石原さんも元々東京に住んでいたと聞いていますが、お二人の熊本オフィスで働く決め手はなんだったのでしょうか。

石原(写真左): 私は熊本出身で、以前は東京のゲーム会社で働いていたのですが、親も高齢になってきたので心配もあり、熊本に戻りIT業界で働いていました。Aimingが熊本でオフィスを開設すると聞き、熊本であきらめていたゲーム開発の仕事に戻れる!と思いすぐに応募しました。

立ち上げ時代を振り返って

原口: 最初は仮オフィスからスタートしたそうですが、その頃の様子を教えてください。

吉田: 石原さんが入社した昨年7月時点ではまだオフィスの工事が終わっておらず、レンタルオフィスを借りることになりました。

石原:4畳半ほどの部屋で、2人でデスクを並べて作業していましたね。

原口:正式なオフィスが開設してからはどのような感じだったのでしょうか。

石原: オフィス開設と同時にスタッフも増えて、変化の多い時期でしたね。

吉田: 当時は業界未経験のスタッフも多かったので、石原さんに無茶ぶりして、ゲームが動く仕組みについての勉強会を開いてもらいました。懐かしい思い出です。

この1年で変わったこと

原口: この1年で大きく変わったことはありますか?

吉田: 開所からの1年でスタッフ数は2人から25人に増えました。11月に1名入ったので現在は26名ですね。

石原: スタッフが増えてオフィス環境も整い、安定してきたと感じています。最初の頃は、新しいスタッフが次々と入ってくるたびに環境のセットアップなどで大変でしたが、最近は落ち着いて業務に集中できるようになりました。

吉田: 増員に伴い、各職種の代表者を集めて会議を行う様にしました。現場の動きを報告してもらい、困っている事があれば解決に向けて必要なアクションを取り、私から会社の方向性や今取り組んでいる課題を共有することで、メンバーが安心感を持って、モチベーションを維持できるように努めています。

熊本オフィスで働く魅力

原口: 熊本オフィスで働く魅力はどんなところですか。

吉田: 皆が仕事をしやすい様な環境を整備したり、東京と連携しながら熊本スタッフを育てていくということに、やりがいを感じています。スタッフにも、熊本が1つの開発スタジオとして成長していくためにいろいろなアイデアを出してもらいながら、一緒にやっています。組織づくりの面白さは他では経験できないと思います。

石原:熊本と東京は組織上の区別は無く、同じプロジェクトの一員として開発を進めてます。熊本で100万DLに達する様な本格的なゲーム制作に携わることができるのは、大きな魅力だと思います!

今後の展望

原口:今後の展望について聞かせてください。

吉田:熊本オフィスは今後もメンバーを増やし、将来的には熊本発のゲームを開発することを目指しています。
設立当初は「1年目に地元採用で人員を確保し、開発や運営の教育を行う」「2年目に東京で運営しているタイトルを熊本で引き継ぎ、リーダーとなる人材を育成する」「3年目に熊本でいちから開発を始め、リリース、運営まで行う」という計画を立てていました。
おかげさまで、1年目は計画通り人員を確保し、25名体制を築くことができました。未経験者も積極的に採用し、育成にも力を入れてきました。

2年目は、開発ノウハウをさらに深めていきたいと考えています。熊本からリーダーが育ち、将来的には熊本発のゲームを開発するという目標に向けて、チーム一丸となって邁進していきます。

また、熊本県や市が進めるコンテンツ産業の発展を後押しするため、地元企業や学校、行政との連携を強めていきたいと考えています。具体的には、学校でのゲーム開発に関する講義の実施やインターンシップの受け入れ、地域イベントへの参加などを検討しています。
そのためにも、意欲のある方を募集しています。

原口:それは楽しみです!今後の熊本からも目が離せませんね!

おわりに

Aiming熊本オフィス開設1周年を記念したインタビュー、いかがでしたでしょうか?
立ち上げメンバーの生の声を通して、熊本オフィスの成長と未来への展望を感じていただけたのではないでしょうか。
次回は、実際に熊本オフィスで働くスタッフに焦点を当て、それぞれの仕事内容ややりがい、熊本での生活について詳しくお話を伺います!
熊本オフィスでは新しい仲間を募集しています!
ゲーム開発に興味がある方、地方での暮らしに興味がある方、ぜひAiming熊本オフィスで一緒に働きませんか?
ご興味のある方は、お気軽にこちらのフォームよりご連絡ください。

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/11/IMG_6467-scaled-e1730965225135.jpg
[Unity]Unity ECS v1.3.2を使ってゲームを作ってみました (1)―紹介編 https://developer.aiming-inc.com/unity/unity-ecs-sample-game-1-introduction/ Thu, 07 Nov 2024 11:55:47 +0000 <![CDATA[C#]]> <![CDATA[Unity]]> <![CDATA[エンジニア]]> https://developer.aiming-inc.com/?p=11457 <![CDATA[[outline] はじめに はじめまして、 第二事業部 エンジニアの孫(ソン)と申します。 普段からUnity ECSを勉強しながら、ゲーム開発を行っています。 ネットに公開されている記事は概念的な説明が多く、 実戦的にゲームを組み立てた内容が少ないです。 そこで、わずかながら […]]]> <![CDATA[

[outline]

はじめに

はじめまして、 第二事業部 エンジニアの孫(ソン)と申します。
普段からUnity ECSを勉強しながら、ゲーム開発を行っています。
ネットに公開されている記事は概念的な説明が多く、
実戦的にゲームを組み立てた内容が少ないです。
そこで、わずかながら個人の経験を共有させていただきます。

Unity ECSで得られるメリット

Unity ECSは、structでEntity、Component、Systemを作成できるようサポートしています。これにより、データ処理をSIMDに変換する最適化コンパイラ[Burst Compiler]が活用可能になります。
さらにSystem内でJobを使いScheduleParallel()を実行することで、配列データの走査を均等に分割し、マルチスレッドで並行処理が可能になります。
上記のUnity DOTSはECSなしでも使用できますが、ECSアーキテクチャと組み合わせることで、DOTSの利点を最大限に引き出し、高速なコードが書きやすいと思います。

DOTSを使うとどのぐらい速くなるか?

CodeMonkeyさんのJob検証動画では下記のような検証がなされています。
1フレームごとに実行する処理で、1000個のSpriteオブジェクトに対してmath.exp10(math.sqrt(value));を1000回実行しています。
以下がその結果です。(動画 20:43 以降でまとめられています)

foreach ScheduleParallel +Burst Compiler
処理負荷 ms 140ms 40ms 4ms
フレームレート fps 7fps 21fps 220fps
速くなった倍率 1倍 3倍 30倍

foreachで重い計算処理を実行すると、140msの負荷がかかり、7fpsしか得られませんでしたが、「ScheduleParallel」を使用すると約3倍速くなり、さらに「Burst Compiler」を加えると30倍の速度向上が見られたとのことです。

今回作ったサンプルゲーム

約1000体のハイポリゴンモデルを作成しながら高fpsを保てるかどうかのサンプルゲームを作成しました。
動作環境はCPU Xeon E3-1230V5 3.40GHz、GPU NVIDIA Quadro K1200です。
Unity ECS未使用だったときは50体ほどで60fpsを保てなくなりましたが、実際に試して60fps保てた1000体まで60fpsを維持することが出来ました。

プレイヤー(カメラだけ)は敵(ユニティちゃんコスプレイヤー)の魅力に耐えながら勝利を目指すゲームです。
シャッターチャンスの良い角度で写真を撮ることで、敵を退場させることができます。

レンダリング最適化のアプローチ

サンプルゲームではハイポリゴンモデルを使って、Unity ECSパフォーマンスの向上を検証しました。
CPUの処理よりもGPUの描画がボトルネックになりやすいです。サンプルゲームではハイポリゴンモデルの描画が非常に負荷が高いです。
そのため、Unity最新の大量描画APIであるBatchRendererGroupを使用したEntities Graphicsパッケージを導入しました。
シェーダーも色々と改修し、DOTS Instancingと頂点シェーダーアニメーションを追加することで、アウトライン付きの高価なアニメシェーダーの見た目を保ちながら、約1000体のハイポリゴンモデルを60fpsで描画することができました。
Androidの端末でもLODを強めることで、約1000体のハイポリゴンモデルを出すことができました。

次回予告

今回の記事はここまでとなります。
次回の投稿では最新のECSの書き方を説明します。興味を持った方は、ぜひお楽しみください。

参考資料

Getting Started with the Job System in Unity 2019
【Unity】ECS向けのアニメーションシステムを実装してみた
Entities[1.3.2]Changelog
© Unity Technologies Japan/UCL

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/10/1.jpg
第2事業部 企画部の取り組み ~企画部勉強会の開催~ https://developer.aiming-inc.com/misc/post-11520/ Wed, 30 Oct 2024 10:40:48 +0000 <![CDATA[未分類]]> <![CDATA[第2事業部]]> https://developer.aiming-inc.com/?p=11520 <![CDATA[初めに こんにちは! 第2事業部企画部プランナーの西川です! 今回は企画部が開催している勉強会について紹介したいと思います! プランナーにとって学びやすい環境が整備されていますので、もし興味を持って頂けたら幸いです! 勉強会とは? 特定のテーマに対して、知識を持っている有識者の方 […]]]> <![CDATA[

初めに

こんにちは!
第2事業部企画部プランナーの西川です!

今回は企画部が開催している勉強会について紹介したいと思います!
プランナーにとって学びやすい環境が整備されていますので、もし興味を持って頂けたら幸いです!

勉強会とは?

特定のテーマに対して、知識を持っている有識者の方に講演をしてもらい、
今いるプランナーにノウハウを共有する

皆さんが想像されている勉強会のイメージと大きな差異は無いかと思います。
例えば「ダメージ計算式について」や、前回私も登壇者として参加させて頂いた「2024年度のCEDECを見て学んだこと」など、テーマに対して知見を持っている人だったら誰でも登壇OKな環境で、幅広い分野で勉強会を行っています。

勉強会に参加する人は新たな知見を吸収できる。
登壇した人は資料作成技術の向上や、大人数の前でプレゼンをする経験ができる。
お互いwin-winな関係性で開催をしています!

過去の開催リスト

勉強会の目的とは

知識に対して興味を持つキッカケを提供し、
気になった時にすぐに手が伸ばせる場を作る

ゲームを作っている以上、期日前であったり、佳境タイミングであったりと、どうしても業務に追われるタイミングがあります。
この時期は毎日忙しく楽しい日々を送ることができますが、どうしても日々の生活等に押し流されて、知識に対する収集欲や勉強にかける時間が減少しがちになってしまいます。
そんな忙しい人達でも
短ければ15分、長くても60分。
気軽に興味を持った分野の新しい知識を得ることができる場を提供する

という目的で勉強会は運用されています。

本を読む、SNSで検索してみる、実際にやってみる、etc…
新しい知識を得る手段は沢山あります。ですが
「社員として見知った人が様々な分野の知識を、
 触りから少し深堀ったところまで分かりやすく教えてくれる」

このような機会は普段の生活では中々ありません。
知識を得る為の手段の1つとして、強力な助っ人になること間違いなしです。
自分が興味を持った分野の最初の1歩としては大きな大きな1歩になるのではないでしょうか。

参加できなかった人へのサポート体制も充実

勉強会は全て画面録画と会場の録画、資料の共有が行われています。
今回のブログに貼ってある資料もすべて過去の動画から持ってきています。

会議や〆日前など、どうしてもタイミングが合わない方もいると思います。
そんな人達が後からでも見返せるように、社員全員が見れるフォルダに勉強会フォルダを設けています。
そこに今まで開催した勉強会全てのデータが入っていますので、いつでも確認が可能になっています。

忙しい人でも、いつでも、誰でも。
大きな最初の1歩を踏み出す為の手段の1つになるような場。それが我が社の勉強会です。

勉強会で学んだことが役に立つ


先日、私はゲームクリエイターとして初めてプロジェクト(以下PJ)の佳境というものを経験しました。
初めてということもあり、上で挙げたタイミングの例に洩れず業務に追われてしまい、「思ったよりも新しいことに手を伸ばせていない、勉強に時間を割けていない」という焦りを抱えていた時期がありました。

そんな中、勉強会として「進行管理のやり方」という内容で勉強会が開催されました。
進行管理の方とやり取りをすることが何度かあったのですが、何をされているのかを実はちゃんとよく知らない。そんな私にとって凄く気になるタイトルに惹かれて参加しました。
進行管理が何をしているのか、入口~少し踏み込んだ内容までを教えて下さったこの勉強会は私にとって「PJをどう進めてくと良いのか、進行管理って何をしているのか?」の1歩を踏み出す大きなきっかけになりました。
入口さえ分かってしまえばどんどん踏み込んでいけます。最初の1歩を勉強会で知ることができたおかげで、進行管理の方のことを知ることができ、有意義にお話しを進めることができる場面が何度もありました。

知識としては入口を踏み出す小さな1歩かもしれませんが、僕にとってはとても大きな1歩になった良い経験だったと今でも感じています。

勉強会実行委員が勉強会を運用


勉強会の運用を実現する為に、そしてより良い勉強会を開催することを目標に、勉強会実行委員が発足しました。
現在メンバー8人で活動しており、勉強会開催日のスケジュール立て、勉強会で開催する内容と登壇者の選出、当日の会場セッティングや録画など、勉強会に関することを全て取りまとめています。

小規模ではありますがイベントを開催する裏方の練習になったり、沢山の人とやり取りをする為、コミュニケーション能力が上昇したりと、日々の業務では力として付きづらい要素を磨くことができます。
いくつものPJの人が参加する貴重な機会でもありますので、沢山の人と意見交換をする場として、忙しくも楽しい委員会を過ごしています。

最後に


今回は弊社の企画部が開催している勉強会について紹介してみました!
プランナーが知識を得る為の手段として、これ以上ない手段かなと思います!

当社の開発文化や働き方に少しでも魅力を感じていただけたら幸いです!
ご興味のある方は、ぜひ採用ページをご覧ください!

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/10/1_d2study.png
Gemini勉強会に参加しました! ~AIってすごい!人事の仕事にも役立つ?~ https://developer.aiming-inc.com/study/post-11470/ Tue, 29 Oct 2024 04:43:43 +0000 <![CDATA[勉強会]]> https://developer.aiming-inc.com/?p=11470 <![CDATA[はじめに こんにちは!人事担当です。 先日、社内で開催された「Gemini勉強会」に参加してきました。 Geminiって何か、正直よく分かっていなかったのですが、「AIで業務効率化できるらしい」という噂を聞きつけ、興味津々で参加しました。 今回は、AIツールにあまり馴染みのない私 […]]]> <![CDATA[

はじめに

こんにちは!人事担当です。
先日、社内で開催された「Gemini勉強会」に参加してきました。
Geminiって何か、正直よく分かっていなかったのですが、「AIで業務効率化できるらしい」という噂を聞きつけ、興味津々で参加しました。
今回は、AIツールにあまり馴染みのない私のような人事担当者でも理解しやすいように、勉強会の内容をレポートしたいと思います。

Gemini for GWS って?

勉強会では、まず「Gemini for GWS」について説明がありました。
Gemini for GWSは、Google Workspaceで使えるAIツールで、Gmailやドキュメント、スプレッドシートなど、普段使っているツールと連携して、様々な作業を効率化してくれるそうです。
例えば、
 ・長文メールの要約
 ・議事録の作成
 ・スプレッドシートでのデータ分析
 ・プレゼン資料の作成
など、色々なことができるみたいです。
AIって聞くと、なんだか難しそう…と思っていましたが、Geminiは普段使っているGoogle Workspaceで使えるので、親近感がわきました。

Gemini App ってどんなアプリ?

次に、Gemini Appについて教えてもらいました。
Gemini Appは、チャット形式でGeminiとコミュニケーションをとることができるアプリです。
質問に答えてもらったり、文章を作成してもらったり、アイデアを出し合ったり、色々な使い方ができるみたいです。
実際に、アプリを使って、Geminiに質問をしてみました。
「人事採用の仕事でAIをどのように活用できますか?」と聞いてみたところ、
 ・候補者 screening
 ・面接のスケジュール調整
 ・研修資料の作成
 ・社内コミュニケーションの活性化
など、活用方法を提案してくれました!

サイドパネルって便利そう!

Google Workspaceのアプリで使える「サイドパネル」も便利そうでした。
サイドパネルを開くと、Geminiが常にサポートしてくれるので、作業中に分からないことがあってもすぐに質問できます。
例えば、ドキュメントで文章を作成しているときに、サイドパネルで「もっと分かりやすく表現するにはどうしたらいいですか?」と聞いてみると、改善点を提案してくれたり、言い換え表現を教えてくれたりします。
これなら、私のような文章力に自信がない人でも、質の高い文章を作成できそうです。

アイデアを出し合ってみた!

勉強会の後半では、グループに分かれて、Geminiを活用した業務改善のアイデアを出し合いました。
他職種のメンバーと意見交換することで、新たな発見がたくさんありました。
エンジニアチームからは、100を超えるスレッドになってしまったSlackの要約をGeminiにしてもらい、さらに回答者の心理状況を分析するという斬新なアイデアが出てきました。
これは、膨大なコミュニケーションデータから重要な情報を抽出するのに役立ちそうです。
企画チームでは、ゲームのシナリオやレベルデザインについての案出しにGeminiを活用していました。
AIの力で、よりクリエイティブな発想を生み出せるようになるかもしれません。

今後の展望

今回の勉強会では、実用的なものまでアウトプットすることはできませんでしたが、それぞれのチームで持ち帰り、今後業務でGeminiを利用できないかを検討することになりました。
私自身もGeminiを活用して、人事の仕事をもっと効率化できないか、色々試してみたいと思います。

早速Geminiを使いました!

ということで、早速Geminiを活用してみました!
まず、アイキャッチ画像もGemini作成です。
架空のセミナールームを作ってもらいました!
そしてブログはGeminiに作成してもらったんです!
文章が完成するまで何度かプロンプトを入力しました。

最初のプロンプト

まずは、ざっくり勉強会のブログを書いてほしいと入力しました。
それだけではさすがに記事のアウトプットはでませんが、構成を考えてほしいときはこの内容でも問題なく利用できそうです。
タイトル例も3つほど出してくれました。

2回目のプロンプト

今度は指示通り、参加者、勉強会の構成、勉強会の結果、書いた人を入力しました。
ほとんど箇条書きにしては、それっぽいブログができました。

3回目のプロンプト

実際にどういった内容がアイディエーションで出てきたかを追記しました。
簡単に作りたかったので今回はここでプロンプトの入力を終了。
今回はテストということもあり、Geminiが出してくれたブログ案をほぼそのまま活用しました!

最後に

正直、自分が時間をかけてうーんと唸って出した構成より見やすいですw
0ベースからブログを書いていくよりも、Geminiに案を出してもらう方が圧倒的に時間の短縮となりました。
一方で修正が必要な部分もあり、ブログの構成と初稿をGeminiにお任せしてそこから人間の力で整えていく!
というのが今の理想的な使い方だなと感じました。

そして何より、正しいプロンプトを入力することがとても大切です。
ふわっとしたプロンプトだとふわっとした回答がでてきてしまうので、そこは使用者が注意しないといけない点ですね。

今回の勉強会を通して、よりAIツールの便利さや可能性を実感できました!
GeminiのようなAIツールが、私たちの働き方を変えていくのかもしれません。
今後は採用チームで定期的にGemini勉強会を実施する予定です。
良い活用ができたらこちらでまたGeminiと一緒にブログを書きたいと思います!

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/10/Gemini_Generated_Image_6f4dif6f4dif6f4d.jpg
第一事業部(TWILO)配属プロジェクトのデザイナー研修 https://developer.aiming-inc.com/design/post-11019/ Fri, 11 Oct 2024 03:00:41 +0000 <![CDATA[デザイン]]> <![CDATA[新卒研修]]> <![CDATA[第一事業部]]> https://developer.aiming-inc.com/?p=11019 <![CDATA[はじめに はじめまして、第一事業部新卒デザイナーの田中と秦(チン)と申します!今回はチーム内で行った、配属プロジェクトのデザイナー研修についてお伝えします。 第一事業部(TWILO)配属プロジェクトのデザイナー研修 スケジュール 新卒デザイナーの研修は、「事業部の研修」→ 「配属 […]]]> <![CDATA[

はじめに

はじめまして、第一事業部新卒デザイナーの田中と秦(チン)と申します!今回はチーム内で行った、配属プロジェクトのデザイナー研修についてお伝えします。

第一事業部(TWILO)配属プロジェクトのデザイナー研修

スケジュール

新卒デザイナーの研修は、「事業部の研修」→ 「配属プロジェクトのデザイナー研修」の二段階で行われます。

・・ところで、表を見ていただけると分かるように、新卒デザイナーは担当セクションだけでなく、他セクションの内容も経験する形になっていますよね?

このようになっている意図について説明します!

研修の目的

各セクションを経験する形になっている今回の研修の目的は、

  • これから関わる方々とのコミュニケーション
  • セクションごとの基本的な用語・手法の学習
  • 制作の流れを経験する
  • 制約の中で面白いものを表現する
  • 各セクションの苦労点や面白い点を感じ取る

のように多岐に渡っていますが、

その中でも特に重要なのが、お互いへのリスペクトを育てることです!

ゲーム開発はチームプレイで、個人の技術だけでなく一人一人が広い視野と互いへの尊敬を持つことが求められるため、お互いの作業を体感する内容になっています。

研修課題

今回の研修課題は・・・

「架空のゲームのガチャリザルト画面を作る!」ことです✨

今回は1ヶ月半で全ての工程を進めましたが、実際の業務ではもっと時間をかけて作ります。

セクションごとの先輩方にサポートしていただきながら制作することができました。

さっそく制作過程を紹介します!


コンセプトイメージ(キャラクターデザイン+三面図)【約2日間】

登場するキャラクターについては、以下のような課題が与えられていました。

この設定を元に、まずはキャラクターデザインを描き起こしました。

田中                  秦(チン)

デザインだけでなく、キャラが動く所を想像できるようなメモも描かれていて面白いです✨

このキャラクターデザインラフを元に、ガチャリザルト画面のイメージラフと三面図を描き起こしました。

▼ガチャリザルト画面イメージラフ

田中                  秦(チン)

▼三面図

田中

秦(チン)

 


UIデザイン【3日間】

次は、ガチャのリザルト画面に必要なUIデザインの作業に入ります。 

UIはユーザー・インターフェース(User Interface)の略称です。

ゲームにおけるUIは、プレイヤーがゲームを操作するため、触れるための重要なツールとなります!

▼UIデザイン

 

田中                  秦(チン)

プレイヤー視点でガチャリザルトでは、どのような要素が必要なのかを考えて作成しました。


3D・キャラクターモデル【4日間】

今回の研修では、なんと!

お互いデザインしたキャラクターを交換して、3Dモデルを制作しました!

「コンセプトデザインは他者に対して書くもの」ということを理解するためです。

相手のキャラクターデザインを再現するために、お互いにコミュニケーションを取りながらの制作でした。

Aimingで3Dモデリングの際に使用されているMAYAを、今回の研修でも使用しています。

MAYAの制作経験がないため不安でしたが、ソフトの基本的な操作からモデリングの制作手順まで、しっかり学ぶことが出来ました✨

完成品がこちらです。

▼キャラクターモデリング

田中                  秦(チン)

 

  

 


キャラクターモーション【5日間】

制作した3Dモデルに、動き(モーション)を付けていきます。(リグやウェイトは先輩方に用意していただきました。)

まず、演出の2Dラフアニメーションを作成しました。

(ちなみにこれは研修内容に含まれていたものではなく、新卒デザイナー2人が勝手に制作したものです。)

実際の業務では絵コンテと3Dモデルでのビデオコンテを作成し進めることが多いそうです。✨

田中                  秦(チン)

この演出イメージを元に、MAYAで3Dモデルに動きを付けていきました。

▼モーション

 

田中                  秦(チン)


背景3Dモデル【3日間】

3D背景のテーマは「図書館」です。

今回は時間が限られているため、本や本棚など、複製のしやすいモデルを上手く配置して組み立てることで、効率UPを図りました。

▼背景モデリング

田中                  秦(チン)

▼テクスチャを貼って完成!

田中                  秦(チン)


Unity・UIアニメーション【3日間】

まず、前過程で制作したUIをUnityに組み込みます。

そして次に、Unityアニメーションカーブでキーを打ち調整することで、UIにアニメーションをつけていきました。

▼UIアニメーション

田中                  秦(チン)


エフェクト【4日間】

研修最後の内容はエフェクトの作成です。

エフェクトはゲームを盛り上げるために必要不可欠な「演出」の部分です✨

今までの制作物をUnityに組み込み、演出ラフアニメーションを元にエフェクトを作成しました!

▼エフェクト

田中                  秦(チン)

今回は背景のライティングに、ライトではなくエフェクトを使用することで空気感やキャラを引き立てる演出をしています✨

 


最終成果物

田中

秦(チン)

 

おわりに

いかがでしたでしょうか?

今回は24年新卒の第一事業部チーム内デザイナー研修の制作内容をお届けしました!

各セクションを経験することでゲーム開発における視野が広がる、とても充実した研修でした。

また、今回の課題を制作するにあたって、各セクションの先輩方には分からない事の解決策や、制作上のテクニックなどを丁寧に教えて下さいました。

こうした経験を通じて、研修の目的にも掲げられていた「お互いへのリスペクトを育てる」ことに関しても、実感を得ることが出来ました✨

Aimingではこのような、ゲーム開発をする上で重要になる”芯”を作るような研修を始めに行うようにしています。これから先、より深く学んでいくにはリスペクトがあると無いのとでは、習得スピードが違うためです。

研修の内容またはその他のことについての質問は、こちらのフォームよりご連絡下さい!

 

 

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/11/ccdf9966b7140cc31c4ca488d156bdf7.jpg
リリステ_アート開発話・3Dモデル https://developer.aiming-inc.com/game/11216/ Mon, 30 Sep 2024 05:35:55 +0000 <![CDATA[2.5次元の誘惑(リリサ)天使たちのステージ]]> <![CDATA[ゲーム]]> <![CDATA[デザイン]]> <![CDATA[第2事業部]]> https://developer.aiming-inc.com/?p=11216 <![CDATA[はじめまして。Aiming第ニ事業部アート部シニアマネージャーの板井です。 今回紹介するタイトル「2.5次元の誘惑(リリサ)天使たちのステージ」(以降「リリステ」)では、アートディレクターを担当させていただきました。 今回はそのリリステの開発について、キャラクターの見せ方とモデリ […]]]> <![CDATA[

はじめまして。Aiming第ニ事業部アート部シニアマネージャーの板井です。

今回紹介するタイトル「2.5次元の誘惑(リリサ)天使たちのステージ」(以降「リリステ」)では、アートディレクターを担当させていただきました。
今回はそのリリステの開発について、キャラクターの見せ方とモデリングを中心に少しだけ紹介させていただきます。


開発開始段階でのアートの課題と対策について

 本開発の開始から半年前の2022年12月末、試作開始前で課せられた課題は「高品質な3Dキャラクターモデルに挑戦する」ことでした。
更に、タイトルとしてリリステの女の子の魅力を最大限に感じてもらうため「より近くでキャラを見たい」という課題もありました。
今回は、その為の試行錯誤を3つほど紹介します。


▲アニメ設定画と3Dモデルの比較(左がアニメ設定画・右が3Dモデル)▲

▲3Dモデル360度回転イメージ▲

課題1:より魅力的な3Dキャラクターモデリング・骨格表現の強化

リリステのキャラクターモデルは、最大8人表示する事を想定し、約40000ポリゴンとしました。
コレは、今までの第ニ事業部のタイトルに比べ、約2倍以上となります。
理由の一つとしては、上記に記載した「アップでキャラクターを見た際に、耐えうるクオリティにするため」です。
そのクオリティの基軸として「アニメの再現性」を重視しました。
キャラクターの顔・表情については、より重点的に気を使いました。

また、キャラクターの動きのリアリティを追求するために、関節表現の強化に注力しました。
特に、アニメーションの自由度を確保しつつ、自然な動きを実現するために、映像作品に近いリグ(骨格構造)を導入しました。
このリグ構造は、より柔軟かつ滑らかな関節動作を可能にし、キャラクターの動きに説得力を持たせることができました。


▲脇周りのモデルの挙動イメージ▲

▲ゲーム画面上での見た目▲
質感については、これまでAimingで使用してきたトゥーンシェーディングの機構を活かしつつ、アニメのイメージを壊さない範囲での、服の質感表現に力を入れました。
また、アニメと違い、カットに合わせた表情をはっきり見せるため、前髪が透ける処理などを加味しています。

課題2:物理表現の強化

今回は細部の動きをこだわるため、髪の毛・スカートと言った「ゆれもの」の表現の強化も取り組みました。
開発当初は、作業時間の緩和も想定し、物理シミュレーションを重点的に使用した開発を考えていましたが、複雑な服装やアップになった際の演出向上の為、状況に応じて手動でのモーション作成を組み合わせています。


▲物理シミュレーションのセットアップイメージ。▲

▲プレイヤーの入力によって変動するシーンでは物理シミュレーションを採用▲

▲SPスキルやカットシーン等、固定化されてる演出は手動でのアニメーションで対応▲

課題3:キャラクターを魅力的に見せるカメラ演出法

最後に、キャラクターの魅力を最大限に引き出すためにとった演出方法の一部として「バトル待機カメラ」を紹介させて頂きます。
リリステでは「キャラクターの心理描写」や「視聴者の物語への没入感」をなるべく高揚させる演出にしたいという企画的な要望がありました。
その際、チップ選択のようなゲーム的な画面で没入感を阻害しない画面づくりが求められました。
そこで、実際に「群衆を実際に撮影している雰囲気」に寄せる演出を試みました。
まずカメラは、アニメで多用される「キャラを中心に手前と奥の配置物が高速移動をするカメラワーク」を軸に考えました。
その流れになるべく乗せつつ、俯瞰カメラやアップを組み合わせることで「動きのあるカメラワーク」と「実際にコスプレを撮影するとき臨場感」を演出しました。
この取り組みは、作品のテーマ性とキャラクターを様々な視点から見せる表現として効果的でした。


▲ゲーム構想段階のバトルカメラの挙動イメージ▲

▲実際のゲーム画面▲

最後に

今回は、主に3Dキャラクターモデリングと見せ方についてを中心に書かせて頂きました。
他にもリリステにはモデル以外のアート面から企画面にまで「戦わずに魅せ合うバトル」を引き立てるための工夫が多数含まれております。
今後の開発ブログでもご紹介していきますので、是非また読んでください!!

©橋本悠/集英社・リリサ製作委員会 ©Aiming Inc.

]]>
https://developer.aiming-inc.com/wp-content/uploads/2018/07/ogp-default.png
ゲームロジックを複数のアプリケーションで共有する https://developer.aiming-inc.com/unity/post-10909/ Mon, 09 Sep 2024 09:00:28 +0000 <![CDATA[Unity]]> <![CDATA[C#]]> <![CDATA[エンジニア]]> <![CDATA[ゲーム開発]]> <![CDATA[第1事業部]]> <![CDATA[設計]]> https://developer.aiming-inc.com/?p=10909 <![CDATA[ソフトウェアエンジニアの後藤です。 今回は私が所属するプロジェクトで行った、ゲームロジックのクラスライブラリ化について紹介します。 経緯 開発初期にゲームの戦闘パートなどの、所謂「メインゲーム」を Unity のプロジェクト内に実装していました。 しかし開発が進むにつれて、 Un […]]]> <![CDATA[

ソフトウェアエンジニアの後藤です。

今回は私が所属するプロジェクトで行った、ゲームロジックのクラスライブラリ化について紹介します。

経緯

開発初期にゲームの戦闘パートなどの、所謂「メインゲーム」を Unity のプロジェクト内に実装していました。

しかし開発が進むにつれて、 Unity を使わずにメインゲームを動かしたい場面が出てきました。その例を以下に挙げます。

  • AI に1000回バトルさせて勝率を記録する
  • サーバに送られたログから戦闘を再現できるか検証し、ユーザーがチートしているか調べる

これを実現するため、メインゲームの機能を Unity から分離して他のアプリケーションでも利用できるようにしました。

目的・問題設定

サンプルとして簡素なRPGの戦闘パートを作成しました。

サンプルのRPGの戦闘パート

[ゲームルール]

■キャラクターは「味方」と「敵」のチームに分かれる

■素早さが高い順に1人ずつ、誰かに攻撃する

■HP が 0 以下になったキャラクターは戦闘から離脱する

■どちらかのチーム全員が戦闘から離脱したら終了

この戦闘の主要な機能について、構成図を以下に示します。

BattleScene という MonoBehaviour スクリプトをエントリーポイントとして、以下の流れで処理が進みます。

  • ①マスターデータから必要なパラメータだけを取り出し、モデルのインスタンスを生成
  • ②モデルのインスタンスを Repository に保存
  • ③バトルを開始し、ゲームルールに沿って進行
  • ④キャラクターを操作し、ダメージや命中の計算をして、結果をヒット演出や GUI で表示

今回はバトルの進行に必要な機能(以降、コアロジックと呼びます)を Unity から分離して、コンソールアプリケーションで利用することを目的とします。

コアロジックが Unity に依存しないようにする

依存関係の整理

Unity の外に移したコードは UnityEngine の機能を使えなくなります。
そのため、 MonoBehaviour や ScriptableObject を使う機能とコアロジックは分けて実装しておきます。

先程のクラス図の機能を以下に分類しました。

  • Unity : MonoBehaviour 等の Unity のコンポーネントを継承しているか、メンバーに持つ機能
  • データ定義・シリアライズ : キャラクターやスキルのパラメータを設定するマスターデータに依存する機能
  • コアロジック : それ以外でバトル開始〜終了までに必要な機能

ただし上図のままではコアロジックが Unity 側の機能に依存しているので、インターフェイスを定義してコアロジック側に含めます。
Unity 側の機能がインターフェイスを継承することで、依存の向きが Unity → コアロジック のみになりました。

また、 Unity に依存するライブラリもコアロジックでは参照できなくなります。

今回の対応では UniTask を使っていますが、後述するクラスライブラリのプロジェクトに .NET Core 用の UniTask パッケージ を追加して解決しました。

コアロジック中の UnityEngine API の差し替え

元々 Unity プロジェクトでコアロジックを実装していたので、様々な場面で利用する機能にも UnityEngine の API を利用していました。Unity に依存しないようにするために、以下の対応が必要でした。

  • UnityEngine.Random → System.Random に差し替え
  • UnityEngine.Mathf → System.Math に差し替え
  • UnityEngine.Debug.Log → ログ出力機能を interface で抽象化

コアロジックをクラスライブラリ化する

コアロジックを Unity の外に移していきます。
クラスライブラリ化には以下の記事を参考にしました。
neue cc – .NETプロジェクトとUnityプロジェクトのソースコード共有最新手法

1. プロジェクトの用意

Unity プロジェクトの外にクラスライブラリ用のソリューションとプロジェクトを作成します。

コアロジック用のクラスライブラリプロジェクトを作成

クラスライブラリは Unity 側にコード共有されるので、 C# や .NET のバージョンは Unity に合わせます。
今回はサンプルを作成した Unity に合わせて C# 9 と .NETStandard 2.1 に設定します。

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <LangVersion>9.0</LangVersion>
        <TargetFramework>netstandard2.1</TargetFramework>
        <Nullable>enable</Nullable>
    </PropertyGroup>

</Project>

2. コード共有の設定

まずクラスライブラリのビルド時に生成される binobj を Unity に共有されないようにします。

これには Directory.Build.props を .sln ファイルがある場所に配置してUnity がインポートしない名前のフォルダを出力先に設定します。
今回は .artifactsというフォルダを出力先にしました。

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <!-- Unity ignores . prefix folder -->
        <ArtifactsPath>$(MSBuildThisFileDirectory).artifacts</ArtifactsPath>
    </PropertyGroup>
</Project>

次に、クラスライブラリ側で Unity 用のファイルを無視します。

package.jsonasmdef は Unity の PackageManager で参照するために必要なファイルで、クラスライブラリには不要です。
また Unity から参照されたとき meta ファイルが生成されるのでこれも無視します。

プロジェクトの .csproj ファイルに以下の項目を記述します。

<ItemGroup>
    <None Remove="**\package.json" />
    <None Remove="**\*.asmdef" />
    <None Remove="**\*.meta" />
</ItemGroup>

最後に package.jsonasmdefを作成します。

{
  "name": "com.sample.2d-battle-core",
  "version": "1.0.0",
  "displayName": "2d-battle-core",
  "description": "2d-battle のコアロジック",
  "unity": "2022.3"
}
{
    "name": "2d-battle-core",
    "rootNamespace": "",
    "references": [],
    "includePlatforms": [],
    "excludePlatforms": [],
    "allowUnsafeCode": false,
    "overrideReferences": false,
    "precompiledReferences": [],
    "autoReferenced": true,
    "defineConstraints": [],
    "versionDefines": [],
    "noEngineReferences": false
}

以上の作業を済ませたフォルダ構成を以下に示します。

クラスライブラリプロジェクトのフォルダ構成図

これらの設定を済ませると PackageManager から package.jsonを置いたフォルダ以下のコードを共有できるようになります。

パッケージを参照するときは manifest.jsonを開いて相対パスを直接記述します
PackageManager ウィンドウの「 Add package from disk 」で追加すると絶対パスになってしまいます。

クラスライブラリを参照

記述したらPackageManager ウィンドウを開き、パッケージが追加されているか確認します。

PackageManager でクラスライブラリを参照できているか確認

3. コアロジックをクラスライブラリに移す

Unity からクラスライブラリの asmdef ファイルがあるディレクトリにコードを移します。
このとき Unity への依存が残っているとコンパイルエラーが出てしまいます。

また、コアロジックのユニットテストも Unity の外に移せます。

クラスライブラリのソリューションにユニットテストプロジェクトを作成して移します。
ユニットテストは Unity とコード共有しないので、クラスライブラリと後方互換性があれば C# や .NET のバージョンは任意です。

クラスライブラリを使ってアプリケーションを作る

今回は以下の状況と機能を実装した最小のバトルを構築します。

■ 味方と敵は1人ずつ

■ 使用するスキルは1つだけ

■ キャラクターに行動順が回ってきたらスキルを相手に撃つ

■ キャラクターやスキルのパラメータはコードに直接書く (マスターデータは使わない)

まず、コンソールアプリケーション用にソリューションとプロジェクトを作成します。
クラスライブラリと後方互換性があれば、 C# や .NET のバージョンは任意です。

コンソールアプリケーションプロジェクトの作成

クラスライブラリを参照することでコアロジック側の機能を使えるようになります。

クラスライブラリを参照する

これを利用してバトルを組み立てます。
また、 Unity から分離するとき抽象化したインターフェイスも実装します。

これらのサンプルコードを以下に示します。

// ---- Program.cs ----
// プロジェクト共有によりコアロジック側に定義した Actor や BattleProcessor 、Repository を参照可能

// キャラクターのインスタンス作成
var ally = new Actor(id: 1, hp: 100, mp: 100, attack: 30, defence: 20, agility: 10, isMine: true); // true なら味方、 false なら敵
var enemy = new Actor(id: 2, hp: 80, mp: 50, attack: 20, defence: 10, agility: 5, isMine: false);
var actorRepository = new ActorRepository();
actorRepository.Set(ally.Id, ally);
actorRepository.Set(enemy.Id, enemy);

// スキルのインスタンス作成
var commonSkill = new Skill(id: 1, damageEffect: 30, requiredMp: 5, accuracyPermil: 1000);
var skillRepository = new SkillRepository();
skillRepository.Set(commonSkill.Id, commonSkill);

// インターフェイスの実装
var commandPlanner = new FixedCommandPlanner(ally, enemy, commonSkill);
var performanceProcessor = new DummyPerformanceProcessor();
var logger = new ConsoleLogger();

// バトルの構築
var battleProcessor = new BattleProcessor(
    actorRepository,
    skillRepository,
    commandPlanner,
    performanceProcessor,
    logger);

// バトルの実行
await battleProcessor.Run();
// コアロジック側に定義したインターフェイスを実装する

// 行動するキャラクターが味方なら敵に、敵なら味方に共通のスキルで攻撃
public class FixedCommandPlanner(Actor ally, Actor enemy, Skill commonSkill)
    : ICommandPlanner
{
    public UniTask<Command> Planning(Actor performer)
    {
        var performerId = performer.Id;
        var targetId = performerId == ally.Id ? enemy.Id : ally.Id;
        return UniTask.FromResult(new Command(performerId, commonSkill.Id, targetId));
    }
}

// 演出や GUI は描画しない
public class DummyPerformanceProcessor : IPerformanceProcessor
{
    public UniTask PlayBattleStart() => UniTask.CompletedTask;
    public UniTask PlaySkill(SkillResult skillResult) => UniTask.CompletedTask;
    public UniTask PlayBattleEnd() => UniTask.CompletedTask;
}

// UnityEngine.Debug.Log の代わりにコンソールに出力
public class ConsoleLogger : ILogger
{
    public void WriteLog(string message) => Console.WriteLine(message);
}

この例はとても簡素ですが、プレイヤー操作やGUIの描画をせず自動でバトルを動かせます。ここから ICommandPlanner を差し替えて、強さを評価したい AI に行動を決定させたり、ログの内容を操作に変換して行動させるアプリケーションも作成できます。

なお、サンプルコードではクラス図中の「データ定義・シリアライズ」の機能は未使用です。マスターデータを扱うときはこれらの機能が必要になり、コアロジックと同様に Unity から分離してコード共有する必要があります。

考察・まとめ

コアロジックを Unity から切り離し、他のアプリケーションで利用できるようになりました。
Unity を使わないアプリケーションでは、 C# や .NET のバージョンを Unity に合わせずに済みます。

一方で、この方法は分割に見合うメリットがあるかの検討が必要です。

Unity から切り離した部分は Unity の機能や、 Unity に依存するライブラリも使えなくなります。

また、分割したあとはアーキテクチャの保守コストが発生します。
追加する機能はどのプロジェクトに含めるか考えたり、開発メンバーが新規参加したときにアーキテクチャを理解する必要があります。

プロジェクトの開発体制によっては、分割しない方が開発スピードが出るかもしれません。

本記事が Unity を使った機能設計の参考になれば幸いです。

参考資料・リンク

サンプルゲームのキャラクター画像には以下を使用しました。
Unity-Chan! コーゲンシティ・オールスターズ キャラクター立ち絵パック Vol.2
Unity-Chan! コーゲンシティ・オールスターズ キャラクター立ち絵パック Vol.3

© Unity Technologies Japan/UCL

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/08/system_architecture-890x500-1.png
キャラクターを例にしたデザインのつくり方 https://developer.aiming-inc.com/design/post-10438/ Tue, 27 Aug 2024 04:09:02 +0000 <![CDATA[イラスト]]> <![CDATA[デザイン]]> <![CDATA[キャラクター]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=10438 <![CDATA[はじめまして、第一事業部2Dデザイナーのyonezawaです。 現在、業務では主に既存IPのキャラクターイラストの作成を担当しています。 今回は下のキャラクターを例に、デザインのつくりかたについて、自分なりの考え方や工程についてご紹介します。 こちらはブログ用に描いたオリジナルキ […]]]> <![CDATA[

はじめまして、第一事業部2Dデザイナーのyonezawaです。
現在、業務では主に既存IPのキャラクターイラストの作成を担当しています。
今回は下のキャラクターを例に、デザインのつくりかたについて、自分なりの考え方や工程についてご紹介します。
こちらはブログ用に描いたオリジナルキャラクターの絵になりますが、業務では絵柄寄せメインで描いているため新鮮ですね。

ターゲット層を決める

デザインの狙いを定める

多くの共感を得るために、まず最初にターゲットを明確にしてから、狙いを定めてデザインの方向性を導き出していきます。
今回は商品としての絵ではありませんが、デザインがブレない様に諸々大まかに決めておきました。
ターゲット層は訴求力を意識して、下記の想定にしました。

■最近流行しているソーシャルゲームをプレイしている方
■年齢は10代後半~30代後半あたり

そのため絵柄は、デフォルメでありつつ、質感はリアルが混ざっている感じで行こうかなと計画しました。

界観設定

キャラクターの前に世界観を設定する

世界観はキャラクターの性格や言動、服装など、あらゆる要素に大きく影響する事が想定され、とても重要です。
キャラクターデザインといっても説得力を持たせるためには

■世界観設定→ストーリーの大筋→キャラクター設定→ストーリーの細部→キャラクターデザイン

といった流れが個人的に良いと思っています。

とはいえ今回は、ブログ用のキャラクターである事、デザイン(視覚的)の作り方を中心にした記事である事から、各設定はとてもざっくりの状態になります。
設定や話を作り込んでしまうと違和感や矛盾が出てきてしまい、辻褄合わせや情報収集が必要になってくるため、その時間を省略したいという気持ちもあります。
この辺りはシナリオや企画をテーマにした解説の方が参考になると思いますので、そちらをご覧頂けますと幸いです。

時代や流行を意識する

さて世界観ですが、先ほど決めたターゲット層に合わせて流行りの『サイバーパンク』を想定しました。
メカやネオン街がでてきたり近未来的な雰囲気の世界になります。
(少し治安が悪そうな感じだと、戦闘シーンなども出てきてカッコ良さそうだな等と思いつつ…)
デジタル化が進みAIや仮想現実が身近なものになった令和の時代では、関心が高そうなテイストだと思います。

キャラクター設定

普段描かないので、練習を兼ねて可愛い女の子を描いてみようと思いました。
また、ゲームユーザーの多くが男性とのデータがあるようなので、人気を考えるとやはり可愛い女の子が王道かな等と思いつつ。

■ストーリーの軸となる世界を牛耳っている権力者の娘、門限など厳しい家庭環境の為、外の世界をあまり知らない
■好奇心旺盛でちょっぴり反抗やイタズラなんかもしたい、そんなお年頃(13歳くらい)
■隙を見つけて家を抜け出し、外でおさんぽ
■秘密裏に作らせた特注の護身メカを身にまとっている
■普段甘やかされているので泣き虫
■衣装はロリータ

世界観と合わせてキャラクターもざっくり設定を作ってみました。
感情移入の点から主人公は平凡寄りな雰囲気が好まれそうな気がしますが、デザインの解説的に面白みにかけそうかなと思い、個性強めのサブキャラポジションの想定になります。
ここには載せられていないのですが、イメージに近い参考画像を沢山収集して、キャラクターのイメージを膨らませていきます。

W1Hの把握とメモ

『ゴール』を可視化して迷走を防止する

諸々の設定を決めましたが、すぐに絵を描き始めてしまうと、デザインがコンセプトから離れてしまったり、自分の好みに偏ってしまったり、あれもこれもと要素を複数盛り込んで迷走をしてしまったり…と、スムーズに作業を進め難い印象があります。
そのため、ゴールへのヒントを文字で可視化しておきます。
5W1Hの視点から、企画に合ったデザインを起こしやすくする為のヒントをまとめておきます。
5W1Hとは、下記を略した言葉になります。

■いつ(When)
■どこで(Where)
■誰が(Who)
■何を(What)
■なぜ(Why)
■どのように(How)

こちらを把握しておくことで、企画に合ったデザインを作りやすくなります。

今回の場合で応用する

今回の場合で当てはめてみます。

■いつ(When)→普段、昼夜問わず
■どこで(Where)→サイバーパンクな世界、やや治安が悪い、メカが沢山ある
■誰が(Who)→女の子、年齢は13歳くらい、権力者の娘、普段甘やかされているので泣き虫、衣装はロリータ
■何を(What)→おさんぽする
■なぜ(Why)→好奇心が強いので楽しそうな物を探しに
■どのように(How)→親に隠れてこっそり、治安が悪いので護身しながら、色々厄介なので顔は見られたくない正体不明

情報を補足するなどして、こちらもざっくり書き出してみました。

アイデアの関連ワードのメモ

『らしさ』も可視化して迷走を防止する

こちらは、5W1Hとは少し違い、自由に『それっぽい』と思って頂きやすくなりそうなヒントを色々と書き出してみます。
モチーフや、配色、シルエット等、取り入れるとそれっぽくなりそうだなと思う要素を、文字で可視化しておきます。

■サイバーパンク→メカ・重厚・ベルト・ファスナー・メッシュ(髪色)・ネオン街・夜・治安が悪そう・高彩度・ピンク・水色・黒・光沢素材(革・ビニール・エナメル系)の衣装
■ロリータ→少女・可愛い・ぴんく・フリル・リボン・スカート・うさぎ・丸いフォルム・デフォルメ・ツインテール

ラフを描いてデザインを固めていく

デザインの検証

これまでの工程を踏まえて、ラフを描きながら検証を繰り返してデザインを固めていきます。

ポーズ

ポーズですが、作画時間短縮+3Dモデル作成を想定して構造が分かりやすいものにしたかったので、単純なAポーズにしました。
素体や顔は早い段階でしっかり目に描いて、似合いそうな衣装を検証しました。

質感

近未来感を出すために、衣装に光沢素材を入れることができないか検証しました(結果)。
スムーズに3Dモデルの作成が行える様にする為にも、質感も考慮してデザインを固めていけると良いですね。

構造

動きを落書きしてみて、ギミックの干渉や構造も検証してみたり。

視覚に訴える説得力を強化する

また、そのキャラクターにしか通用しない要素を組み込んで、視覚に訴える説得力を強化していきます。
『デザイン画=企画や設定を絵に変換する作業』という認識です。
説明なく絵を見た瞬間に、それが何であるかが見る側に伝わるデザインにする必要があります。

■権力者の娘なので、エリザベスカラー+ドレスっぽいシルエットのジャケットで裕福そうな感じ
■護身用のメカの腕を装備したい
■正体を知られたくないので顔を隠したい、メカの腕を付けたいけどヘルメットで頭もメカっぽくするのはどうだろう
■サイバーパンクなのでネオン要素を入れたい、補色の水色にしてみたら合いそう
■泣き虫なので、下がり眉+たれ目+小さな口でそれっぽくなりそう
■髪は綺麗に整えて上品な印象がいいかも、メッシュでサイバーパンク感を入れてみよう
■上品といえば、歩くときにヒールのコツコツ音を出したいかも(ちょっと偉そうな感じも出せそう)、腕に合わせて靴もメカがいいかも
などなど…

清書

デザインが固まったら清書をしていきます。

素体

まず最初に素体を仕上げました。
隠れる部分も描いておくことで、デザインの構造の破綻を防ぐことができます。
また、上に重なる衣装の調整も行いやすくなります。
しっかり目に描いてしまいましたが、隠れる部分は多くの場合もっとざっくり描く感じで大丈夫です。

衣装

次に衣装を仕上げました。
メカなしのこの状態も良く登場するイメージです。

衣装の生地ですが、黒は綿でマット、ピンクはエナメルで光沢素材の想定です。
全ての布をマットな素材にしてしまうと現代的な普通のロリータっぽい印象になってしまうと思い、ジャケットを光沢素材にして近未来感を混ぜました。
ここでは載せることができませんが、質感指定で実物の参考画像を添付できると3Dモデル作成の際に分かりやすくて良いですね。

見えないのですがジャケット背面のお尻付近にうさぎの尻尾がついている想定だったりします。
RPGの場合ユーザーはプレイ中、キャラの背面を見ることが多い様に思うので、走るときにしっぽがふりふりしていると可愛くて癒しになるのでは?などと思いつつ。
ツインテールもぴょこぴょこ動くと可愛いだろうなとも。

メカ

最後にメカを仕上げました。
各所、同じボルトを組み込んだり、シルエットを丸くしたりなど、共通点を持たせてデザインに統一感をだしました。
ターゲット層、世界観設定、キャラクター設定、諸々の企画に合ったデザインにできた様に思います。

おまけ(性格や雰囲気)

 キャラクター設定を見ながらこんなシーンが有りそうかなと、ざっくり浮かんだアイデアも描いてみました。

↓初めて夜の街に来た時、サイバーパンクなネオン街にわくわくする女の子。
試しにチラッと下見に来た感じのイメージです。
表情と背景を見せたかったのでメカは無しにしました。大体の雰囲気が伝わればと思います。
街ですが大通りは賑やかな繁華街だけど、脇道に入ると薄暗く落書きやステッカーが沢山有って少々怖そうな感じを想定しています。

↓主人公との出会い、暇つぶしに喧嘩を売るが負けて大泣きして退散する。

権力者の娘で偉そうな衣装ですし、プライド高めのツンデレっぽい性格でしょうか。
視覚的な可愛さを中心に考えたキャラクターですが、ツンデレ女子が好きな方には性格的にも可愛いと思って頂けるかもしれません。

まとめ

個人的にデザインを行うときに大切なのは、最初にゴールを明確にして何のためのデザインなのかを意識しながら描く事だと思っています。
自分の好きなように絵を描く事はとても楽しく素敵ではありますが、
業務では、企画、〆切や売り上げ等が関係し、期限内に狙い通りのものづくりを行う必要があるため、業務としての絵を描くスキルが別途必要になってきます。
日々学びが多いです。

余談ですが、ぴんくには癒しの効果があるようで、いつも身の回りに置いています。
色の効果等も知識が有れば、生活に取り入れて気分転換をしたり、デザインに取り入れて意図に沿った説得力をプラスしたりできますが、楽しいですね。

参考書

デザインは一から独学のため、色々な本を読んで自分で学習をしてきたのですが、その中でも、特に良書だと感じたお勧めの書籍をいくつかご紹介させてください。
初心者の方からデザインの考え方を学べます。
センスは知識から始まる
勝てるデザイン
ターゲットの心を掴む スタイルのあるブランディングデザイン
欲しくなるパッケージのデザインとブランディング

後に

Aimingに入社して強化したスキル

Aimingに入社したことで、強化されたと感じるスキルについてお話をしたいと思います。
何かスキルアップをしたいのであれば、そのスキルの高い方が多い環境に身を置くことが近道のように思いますが、Aimingで業務を行っている現在、『画力』や『行動力』が入社前よりも大きく強化できたように感じています。

画力

私がAimingに入社を決めた理由の一つに、『画力』を大きく向上出来そうだと感じたことがあります。
キャラバンストーリーズの画集や開発者ブログの記事オルガができるまでなどを見た際に、
デザイン画はもちろんですが、インタビューや解説に説得力があり内製がとても強そうだと思いました。
私はこれまでに幾つかのゲーム会社での業務経験があり、在籍当時ではありますが個人的に難易度の高いタスクは外部会社へ依頼している状況が多かった印象があります。
ですが、今現在私の所属している2Dデザイナーのチームではタスク量が多い場合を除き内製で完結しており、とても技術レベルが高い印象です。

行動力

何かを成し遂げたい時に技術的なスキルは勿論ですが、『行動力』もとても重要になってくるように思います。
行動を起こし挑戦しなければ、スタート地点にすら立つことができません。
今こちらをご覧頂いている方の中に、何か成し遂げたい目標がある方も多くいらっしゃるのではないでしょうか。
Aimingでは、頻繁に勉強会や自己紹介(ライトニングトーク)を行っているため発表のチャンスが多く、また、優しい方が多く丁寧にご指導を頂けるので、未経験の分野でも挑戦しやすい環境のように思います。

副業で自分の好きな形でスキルを活かす

副業が許可されているので、磨いたスキルを自分の好きな形で楽しく発揮してみたり…ということも素敵ですね。

仲間を募集中です

もっと画力をあげたい、行動力を身に着けて目標を達成したいという方には、うってつけの環境だと思います。
気になった方は、是非一度ご応募ください。

 株式会社Aiming第1事業部では一緒にゲームを作る仲間を募集中です!!
中途採用 → 積極採用中です! あなたの経験をフルに活かしてください!
新卒採用 → 未経験者も含め、熱意あるみなさまを歓迎します!
詳しくは採用ページと事業部紹介ページをご覧ください!
■採用ページ
https://recruit.aiming-inc.com/career/
■事業部紹介ページ
https://recruit.aiming-inc.com/twilo/

]]>
https://developer.aiming-inc.com/wp-content/uploads/2030/07/8c3af0ccbd86d910e89e577d026437c5.png
UniRxで課題だったRxとasync/awaitの連携がR3では楽になった件 https://developer.aiming-inc.com/csharp/post-10773/ Mon, 26 Aug 2024 08:12:26 +0000 <![CDATA[C#]]> <![CDATA[エンジニア]]> <![CDATA[第一事業部]]> https://developer.aiming-inc.com/?p=10773 <![CDATA[こんにちは。ソフトウェアエンジニアのyashiheiです。 最近はお絵描きにハマり毎月100時間ぐらいのめり込んでます。上手い絵は全然描けないですがコツコツものを作ってる感覚があり楽しいですね。 さて、筆者が関わってるプロジェクトではCysharp様が開発されているOSSのR3を […]]]> <![CDATA[

こんにちは。ソフトウェアエンジニアのyashiheiです。

最近はお絵描きにハマり毎月100時間ぐらいのめり込んでます。上手い絵は全然描けないですがコツコツものを作ってる感覚があり楽しいですね。

さて、筆者が関わってるプロジェクトではCysharp様が開発されているOSSのR3を導入しています。R3はまだリリースされてから日も浅いのですが、これまでUniRxで開発してて感じてた課題を解決しており、良い方向に進化していると感じました。その中でも特にRxとasync/awaitの連携はずっと欲しかったものであり、この記事では背景なども振り返りつつ掘り下げようと思います。UniRxからR3に移行しようと考えてる人の参考になれば幸いです。

Single Observable問題

R3から入門する人にとってはあまり関係が無い話ですが、UniTaskが無かったころは非同期処理を全てUniRxで書いてた時代がありました。単発の非同期処理をObservableで表現するので、1回しか流れないObservable(Single Observable)が現れます。

下のコードは以前所属してたプロジェクトのコードから適当にSingle Observableのコードを見繕ってきました。async/awaitで書き直したものも置いてます。どちらが読みやすいでしょうか?async/awaitで書いたほうが素直に読めると思います。

これならまだマシな方で、もっと数多くのSingle Observableが複雑にチェインされたコードもあった記憶があります。そうなるともう全然読めないです。

// HogePresenter.cs

// Single Observable
public IObservable<Unit> ShowAsObservable()
{
    return Observable.Defer(() =>
    {
        return dialogView == null
            ? Observable.Return(Unit.Default)
            : dialogView.CreateAsync() // 開発途中からUniTaskが入ったので中途半端にUniTaskになってたりする…
                .ToObservable()
                .Do(_ => Subscribe())
                .SelectMany(_ => dialogView.ShowAsObservable());
    });
}

// async/await
public async UniTask ShowAsync()
{
    if (dialogView == null)
    {
        return;
    }

    await dialogView.CreateAsync();
    Subscribe();
    await dialogView.ShowAsync();
}

なので、neueccさんのR3の思想にはとても共感できます。

R3のメイン思想としてSingle Observable死すべしというのがあり、というかUniTaskと併用してるなら不要というかむしろ使うべきじゃないはずなのに意外と残ってる感があり、Observable.ContinueWithやWhenAllの存在がそれを誘発しているのなら真っ先に死すべしという。

https://x.com/neuecc/status/1759718937162600537

単発の非同期処理はasync/awaitで表現しましょう。素直に上から下に読むことが出来るプログラムが読みやすいです。第一事業部だとまだUniTaskが無かった頃の非同期処理がSingle Observableで書かれてることが多く、未だに排除出来てない印象です。

UniRxではどうやってRxとasync/awaitを連携してたか

Single Observableを排除したところで、UniRxでRxとasync/awaitを連携させるのは工夫が必要で落とし穴もありました。プロジェクトごとに流派はありましたが、筆者が見てきた中だと以下のような実装です。

  • UniTask#ToObservableしてSelectManyなどに繋ぐ
    • .SelectMany(_ => HogeAsync().ToObservable())
    • Taskのキャンセルが出来ない
      • (全体的にCancellationTokenをリレーさせてないコードベースだったので見逃されてたという背景もあります)
      • SelectManyを通ってしまうとToObservable内でTaskがFire and Forgetされるので制御出来ないTaskがあった
      • UniTaskをCancellationTokenを指定しながらToObservableするメモObservableConverter#FromUniTask のような対策を積む必要があると思います
  • Subscribe内でUniTaskをFire and Forget
    • Subscribe(_ => HogeAsync(ct).Forget())
    • HogeAsyncの中に一連の非同期処理を全て詰める
    • イベントが連続するとTaskが並列に走ってしまう問題がある
  • TaskQueueを使う

UniTaskAsyncEnumerableでは駄目なのか

ViewのイベントをUniTaskAsyncEnumerableに変換してForEachAwaitAsync内で非同期処理を書くことも出来るのですが、Observableの互換として扱うには厳しいという判断になりました。以前社内のknowledgeにその理由を書いてたので引用します。

  • UniTask.LinqはUniRxのオペレーターを完全に補完は出来ない
    • 具体的には
      • Switch
      • WithLatestFrom
      • Throttle あたりなど
    • UniTaskAsyncEnumerableはPullベースなのでObservableの完全な互換が出来ない
    • 一時変数を用意したりとか泥臭い書き方になった記憶
      • あとSwitchやろうとしたらキャンセルがめっちゃめんどい
    • やっぱPushなObservable欲しい
  • UniTaskAsyncEnumerableは書き手がクセを理解しないと怖い
    • 期待してたブロッキングにもなるが、逆にQueue挟まないと歯抜けしてしまうケースなども有りそう
    • Pushに慣れたチームにはしんどいかも(Pullから入ったら自然に思えるかもしれない)
  • イベント通知用にChannelをラップしたPubSubを作って公開してたが何処からもPublish出来るのちょっと怖いなってなった
    • UniRxでSubject生成して外部にObserveableを公開してたところ

R3のSubscribeAwait

R3ならば上記のことは気にしなくて良いです。

var subject = new Subject<int>();
var timeProvider = new FakeTimeProvider();

var liveList = new List<int>();
using var _ = subject
    .SubscribeAwait(async (x, ct) =>
    {
        await Task.Delay(TimeSpan.FromSeconds(3), timeProvider, ct);
        liveList.Add(x * 100);
    }, AwaitOperation.Sequential);

https://github.com/Cysharp/R3/blob/1.2.6/tests/R3.Tests/OperatorTests/SubscribeAwaitTest.cs#L16-L25

(R3のテストコードから抜粋)Subscribe内でasync/awaitが書けるようになります。むしろ最初からこう書きたかったぐらい自然な構文だと感じました。実際UniRxに習熟してないメンバーがSubscribeに渡すラムダ式にそのままasync/awaitを書いて、レビューで指摘されるケースが多かったです…。

Select/Where でも同様の対応が積まれてます。

挙動を理解したい

挙動を理解したかったので、R3のSubscribeAwait周辺のコードを写経しました。Ver.1.2.6を参照してます。どのように実装が使われているか証明されているテストコードから写経することで、全体像が理解しやすかったです。

AwaitOperation

当然ながらイベントの間隔と非同期処理の長さは一致しません。なので非同期処理が重なる場合どうやって扱うか決める必要があります。SubscribeAwaitではAwaitOperationを指定することで制御できます。

AwaitOperation解説図

AwaitOperationObserver

/// <param name="maxConcurrent">This option is only valid for AwaitOperation.Parallel and AwaitOperation.SequentialParallel. It sets the number of concurrent executions. If set to -1, there is no limit.</param>
public static IDisposable SubscribeAwait<T>(this Observable<T> source, Func<T, CancellationToken, ValueTask> onNextAsync, Action<Exception> onErrorResume, Action<Result> onCompleted, AwaitOperation awaitOperation = AwaitOperation.Sequential, bool configureAwait = true, bool cancelOnCompleted = false, int maxConcurrent = -1)
{
    switch (awaitOperation)
    {
        case AwaitOperation.Sequential:
            return source.Subscribe(new SubscribeAwaitSequential<T>(onNextAsync, onErrorResume, onCompleted, configureAwait, cancelOnCompleted));
        case AwaitOperation.Drop:
            return source.Subscribe(new SubscribeAwaitDrop<T>(onNextAsync, onErrorResume, onCompleted, configureAwait, cancelOnCompleted));
        case AwaitOperation.Parallel:
            if (maxConcurrent == -1)
            {
                return source.Subscribe(new SubscribeAwaitParallel<T>(onNextAsync, onErrorResume, onCompleted, configureAwait, cancelOnCompleted));
            }
            else
            {
                if (maxConcurrent == 0 || maxConcurrent < -1) throw new ArgumentException("maxConcurrent must be a -1 or greater than 1.");
                return source.Subscribe(new SubscribeAwaitParallelConcurrentLimit<T>(onNextAsync, onErrorResume, onCompleted, configureAwait, cancelOnCompleted, maxConcurrent));
            }
        case AwaitOperation.Switch:
            return source.Subscribe(new SubscribeAwaitSwitch<T>(onNextAsync, onErrorResume, onCompleted, configureAwait, cancelOnCompleted));
        case AwaitOperation.SequentialParallel:
            throw new ArgumentException("SubscribeAwait does not support SequentialParallel. Use Sequential for sequential operation, use parallel for parallel operation instead.");
        case AwaitOperation.ThrottleFirstLast:
            return source.Subscribe(new SubscribeAwaitThrottleFirstLast<T>(onNextAsync, onErrorResume, onCompleted, configureAwait, cancelOnCompleted));
        default:
            throw new ArgumentException();
    }
}

https://github.com/Cysharp/R3/blob/1.2.6/src/R3/Operators/SubscribeAwait.cs#L20-L48

SubscribeAwaitの内部では、渡されたAwaitOperationに応じたObserverが生成され購読されます。

AwaitOperation.csにこれらのObserverが実装されてます(WhereとSelectにも対応する必要があるので各Observerがabstractで実装されてますがここでは説明を省略します)

AwaitOperationのObserver実装をOnNextCoreから読むことでより具体的に挙動が掴めました。

Observerの実装
  • AwaitOperationSequentialObserver
    protected override sealed void OnNextCore(T value)
    {
        channel.Writer.TryWrite(value);
    }
    
    • OnNextCoreでChannel(容量制限無し)にWrite
    • RunQueueWorkerで順次Read
  • AwaitOperationDropObserver
    protected override sealed void OnNextCore(T value)
    {
        if (Interlocked.CompareExchange(ref runningState, 1, 0) == 0)
        {
            StartAsync(value);
        }
    }
    
    • 既にrunningStateが1なら無視
  • AwaitOperationSwitchObserver
    protected override sealed void OnNextCore(T value)
    {
        CancellationToken token = cancellationTokenSource.Token;
        lock (gate)
        {
            if (running)
            {
                if (IsDisposed) return;
                cancellationTokenSource.Cancel();
                cancellationTokenSource = new CancellationTokenSource();
                token = cancellationTokenSource.Token;
            }
            running = true;
        }
    
        StartAsync(value, token);
    }
    
    • 一つ前のTaskをキャンセルしてから新たにTaskを実行
  • AwaitOperationParallelObserver
    protected override sealed void OnNextCore(T value)
    {
        Interlocked.Increment(ref runningCount);
        StartAsync(value);
    }
    
    • そのまま実行
  • AwaitOperationParallelConcurrentLimitObserver
    protected override sealed void OnNextCore(T value)
    {
        lock (gate)
        {
            if (runningCount < maxConcurrent)
            {
                runningCount++;
                StartAsync(value);
            }
            else
            {
                queue.Enqueue(value);
            }
        }
    }
    
    • 無印Parallelとは違ってmaxConcurrentを超えてたら一旦Queueに入れる
  • AwaitOperationThrottleFirstLastObserver
        protected override sealed void OnNextCore(T value)
        {
            channel.Writer.TryWrite(value);
        }
    

まとめ

  • 単発の非同期処理はasync/awaitで表現するのが読みやすい(R3ではSingle Observableを誘発しない設計になっている)
  • R3はRxとasync/awaitの連携を迷うことなく書くことが出来る
  • 非同期処理が重なったときもAwaitOperationでパターンに応じた対応が出来る

紆余曲折があってやっと書きたかった形でViewのイベントと非同期処理が書けるようになったという印象です。R3使っていきましょう。

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/08/image-1.png
大原学園 生徒訪問(^^)/ https://developer.aiming-inc.com/academic-industrial/post-10413/ Wed, 24 Jul 2024 08:31:59 +0000 <![CDATA[産学連携]]> <![CDATA[ゲーム開発]]> <![CDATA[採用]]> <![CDATA[熊本]]> <![CDATA[第2事業部]]> https://developer.aiming-inc.com/?p=10413 <![CDATA[こんにちは、Aiming Team Caravan、熊本ベースの原口です。 7月23日、私達のオフィスに学校法人 大原学園 熊本情報ITクリエイター専門学校の生徒の皆さんが訪問されました!! 熊本ではゲームクリエイターを目指す人向けの学校が少ない中、今年開校したばかりの学校で、そ […]]]> <![CDATA[

こんにちは、Aiming Team Caravan、熊本ベースの原口です。
7月23日、私達のオフィスに学校法人 大原学園 熊本情報ITクリエイター専門学校の生徒の皆さんが訪問されました!!
熊本ではゲームクリエイターを目指す人向けの学校が少ない中、今年開校したばかりの学校で、その第1期生の皆さんです!
今回は、その模様をお伝えします。

企業紹介とゲーム開発の勉強会

初めに、熊本オフィス代表の吉田より、Aimingの企業紹介の後、ゲーム業界の事や各職種の役割、開発の流れなど、詳しく説明を。実際にUnityでゲームが動くところを見ると、生徒さんからもたくさんの質問があがり、興味深く学習してもらえた様子でした。

スタッフとの懇談会

座学形式での説明の後は、それぞれ興味のある職種に分かれて、Aimingスタッフとの懇談会を行いました。スタッフからは、入社した経緯や今やっている仕事の話などを。生徒さんからは「在学中に作成経験しておいた方がよいゲームはなんでしょうか?」「エンジニアとアート、どっちにするか迷っている」「企画でエンジニアやアートとバチバチにやりあった経験談を聞きたい」といった質問や相談がありました。

懇談を通して、生徒さん達にとっても現職の人の声を聞ける貴重な経験となったと思いますし、Aimingスタッフにとっても、自分の仕事を見つめ直す良い機会になりました!

Aimingスタッフの感想

ここで、懇談に参加したスタッフからの感想を掲載します!

Aimingプランナー
最初はプランナー志望が2名と聞いていましたが、
当日は5名とプランナー志望の方が多くてちょっと嬉しかったです。
また、質問を想像していたより多くして頂き、たくさんいろいろと話せて良かったです。
特に、プランナーって何だっけ?という部分を改めて考える機会にもなり、自分にとっても有意義な時間だったと感じられました。
Aimingエンジニア
エンジニア志望の方は多くて、お一人ずつ詳しい話を聞くことはできなかったですが、
色々と質問してもらった中で、少しでも業界で働いていくイメージが具体化してもらえたなら幸いです。
また、業界を志すエネルギッシュな方々と久々にふれあい、自分自身より努力を重ねていこうと思いなおす機会となりました。
Aimingアート
少数でしたが、アート枠志望の方もいてうれしかったです!
自分自身入ったばかりということもあり、新卒での就活時の自分を思い出し、自分だったらどんなことが気になるかというのも鑑みながら質疑応答したのですが、大変興味深く聞いてくれてこちらとしても自分のやっている仕事の振り返りをすることができました。

生徒さんの質問に答えることで、スタッフの振り返りの機会になったり若者達にパワーを貰えたようです。

さいごに

大原学園の皆様、ご訪問ありがとうございました!

Aiming熊本では、熊本・九州のゲーム業界の発展のために、これからも地元企業や学校との交流を深めて行きたいと思います。

熊本での採用も随時行っていますので、興味のある方はこちらのフォームより、お気軽にご連絡ください(^ ^)/

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/07/20240723_143920-scaled-e1723535769632.jpg
C# Source Generator 開発チュートリアル https://developer.aiming-inc.com/csharp/source-generator-tutorial/ Thu, 18 Jul 2024 09:04:29 +0000 <![CDATA[C#]]> <![CDATA[エンジニア]]> <![CDATA[プログラミング]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=10334 <![CDATA[こんにちは、そして、お久しぶりです。 Aiming の土井です。 今年はファミリーベーシック40周年だそうです。小学生の頃に触れて、ゲームのプログラムを書く仕事を志したという思い出があり感慨深いですね。年齢は秘密です! 今回は「C# Source Generator の作り方」に […]]]> <![CDATA[

こんにちは、そして、お久しぶりです。
Aiming の土井です。
今年はファミリーベーシック40周年だそうです。小学生の頃に触れて、ゲームのプログラムを書く仕事を志したという思い出があり感慨深いですね。年齢は秘密です!

今回は「C# Source Generator の作り方」について書いていきます。

ソースジェネレーターとは

ソース ジェネレーターとは、.NET Compiler Platform (“Roslyn”) SDK で提供される、「コンパイル時コード生成機能」です。自動生成されたソースコードは、裏側に隠れ、生成コードを使用していることを意識せず、動的なコード生成による柔軟な実装を行うことができるようになります。

ソースジェネレーターは、アセンブリ単位毎に、コードに変更が入ったタイミングで動作し、任意のコード生成処理を実装することができます。

ユースケース

外部 DLL を参照することなく「ソースコード自動生成による機能」を追加することができます。また、コンパイルする C# ソースコードの構文木を解析し、適応したソースコードを生成することもできます。

インターフェースを追加する

既存のクラスにメソッドを生やすといったことができます。実装を伴うインターフェースを、継承関係を無視して導入できる。アスペクト指向なアプローチが可能です。

C#コードをスキーマ定義として使う

型として表現されたスキーマを基に、シリアライザ、通信コードといった付随するボイラープレートコードを自動生成し、煩雑で似たようなコードが増加することを防ぎ、本質的なロジックを書くことに集中できます。

リフレクションを避ける

ランタイムリフレクションを使わずに、自動生成されたコードに置き換え、処理の最適化や可読性の向上が期待できます。

Rider を使ったチュートリアル

ソースジェネレータープロジェクトの作成

  • クラスライブラリ
  • ターゲットフレームワーク netstandard2.0

として、ジェネレータープロジェクトを作りましょう。

続いて、NuGet パッケージ Microsoft.CodeAnalysis.CSharp version 3.8.0 をインストールします。
バージョン 3.8.0 と少し古いバージョンとなっている点に注意しましょう。これは、Unity でも動作するジェネレーターを作るために指定されているバージョンとなります。

 

動作確認用プロジェクトの作成

  • コンソールアプリで適当に作り、ソリューションに追加
  • ソースジェネレータープロジェクト csproj へのプロジェクト参照を作成し、csproj を直接編集して、以下のように、Analyzer として動作するように設定する
  • ここは .csproj を直接編集する必要があります。Analyzer として指定しないとソースジェネレーターが動かないので注意
<ItemGroup>
  <ProjectReference
     Include="..\SimpleSourceGenerator\SimpleSourceGenerator.csproj"
     OutputItemType="Analyzer"
     ReferenceOutputAssembly="false" />
</ItemGroup>

最小のサンプルコード

  • Untiy のドキュメントに示されたサンプルコードを、ソースジェネレータープロジェクト側に実装する。
  • 動作確認用プロジェクトをビルドすると、以下の場所に、コードが自動生成されていることを確認できる

※ Rider を使っている場合、ジェネレーターに依存したコードは初回の生成が行われるまではコンパイルエラーとして警告されます。
これは、まだ生成したコードが存在しないためです。

ソースジェネレーターのデバッグ

ソースジェネレーターを開発するためには、デバッグができないと相当しんどいです。
まずは、デバッグ環境を整えましょう。

ソースジェネレーター側のプロジェクトに、Properties フォルダを掘り、launchSettings.json というファイルを以下のように作成します。
targetProject には、動作確認用プロジェクトの csproj を指定します。

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "Generators": {
      "commandName": "DebugRoslynComponent",
      "targetProject": "../ConsoleTest/ConsoleTest.csproj"
    }
  }
}

Rider で launchSettings.json を開くと、再生ボタンが表示されているので、ここからデバッグ起動を行うことができます。
これで、動作確認用プロジェクトのソースコードがジェネレーターに渡り動作確認ができるようになります。また、ソースジェネレーター側のコードのブレークポイントが有効となりデバッグ可能となります。

デバッグ実行を行い、ジェネレーター内のブレークポイントで処理が停止することを確認しましょう。

デバッグ実行環境セットアップのまとめ

  • 動作確認用プロジェクトの csproj を直接編集し、ジェネレーターとして扱われるように参照を記述する
  • デバッグ環境を必ず整える

構文木を渡り歩く

次は、コンパイルされるソースコードの構文木を解析して、コードの内容に従ったコード生成を行ってみましょう。

ジェネレーターコールバックに渡される GeneratorExecutionContext にはコンパイルするソースコードの構文木が格納されています。

構文木は SyntaxNode という基底クラスのコンポジットとなっています。
単純な木構造のデータなので、foreach で子を探索していくことももちろん可能です。
しかし、一般的なシナリオを扱う場合には便利な機能が用意されているのでそちらを使いましょう。

ISyntaxReceiver

ISyntaxReceiver を継承したクラスを作成することで、SyntaxNode 毎に呼び出されるコールバックを登録できます。
ここで、ノードの判定を行うことで、木構造を意識することなく必要なノードだけを取得することができます。
クラス定義、関数定義といった定義を基点にコード生成を行うことが多いので、これで十分機能します。

最小の SyntaxReceiver

クラス定義をすべて抽出する SyntaxReceiver は以下のようになります。

    // クラス定義をすべて抽出
    class ClassReceiver : ISyntaxReceiver
    {
        public List<ClassDeclarationSyntax> Classes { get; }
            = new List<ClassDeclarationSyntax>();

        public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
        {
                Classes.Add(classDeclarationSyntax);
        }
    }

作った SyntaxReceiver をジェネレーターに登録するには、
ジェネレーターの Initialize で以下のように GeneratorInitializationContext.RegisterForSyntaxNotifications() を呼び出します。


   public void Initialize(GeneratorInitializationContext context)
   {
       context.RegisterForSyntaxNotifications(() => new ClassReceiver());
   }

より複雑な解析

ここまでくれば、あとは、構文木を解析する部分のコードをどう書くか、という問題のみになりました。
ここでは、属性付与されたクラスを抽出し、そのクラス定義に従って何かをするコードを書いてみます。
また、partial として定義されたクラスのみを扱うようにしてみます。

SyntaxNode の判定

Syntax Node は木構造のノードを表現するコンポジットです。
インスタンスの型とデータをみて、所望のデータかどうかを判定します。

クラスの判定

クラス定義は、ClassDeclarationSyntax という型のノードなので、これを判定します。

        public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
        {
            // クラス定義か?
            var isClassDeclaration = syntaxNode is ClassDeclarationSyntax classDeclarationSyntax;
            if (isClassDeclaration)
            {
                Classes.Add(classDeclarationSyntax);
            }
        }

partial の判定

classDeclarationSyntax.Modifiers に partial キーワードが指定されているかの情報が含まれています。

        public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
        {
            // クラス定義か?
            var isClassDeclaration = syntaxNode is ClassDeclarationSyntax classDeclarationSyntax;
            // partial か?
            var isPartial = classDeclarationSyntax.Modifiers.Any(c => c.IsKind(SyntaxKind.PartialKeyword));

            if (isClassDeclaration && isPartial)
            {
                Classes.Add(classDeclarationSyntax);
            }
        }

属性の判定

        public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
        {
            // クラス定義か?
            var isClassDeclaration = syntaxNode is ClassDeclarationSyntax classDeclarationSyntax;
            // partial か?
            var isPartial = classDeclarationSyntax.Modifiers.Any(c => c.IsKind(SyntaxKind.PartialKeyword));
          // Hoge属性か?
            var hasAttribute = classDeclarationSyntax.AttributeLists
                    .Any(astx => astx.Attributes
                        .Any(x => $"{x.Name.ToFullString()}Attribute" == "HogeAttribute"));

            if (isClassDeclaration && isPartial && hasAttribute)
            {
                Classes.Add(classDeclarationSyntax);
            }
        }

これで、Hoge 属性を持つクラス定義を拾ってくることができました。
取得する属性を外側から指定できるようにした最終的なコードを以下に示します。

特定の属性を持つ partial クラスを取得する SyntaxReceiver 例

    // [T] 属性を持つクラスを抽出
    class AttributedMethodReceiver<T> : ISyntaxReceiver
        where T: Attribute
    {
        public List<ClassDeclarationSyntax> Classes { get; }
            = new List<ClassDeclarationSyntax>();

        public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
        {
            var targetName = typeof(T).Name;
            if (syntaxNode is ClassDeclarationSyntax classDeclarationSyntax &&
                classDeclarationSyntax.Modifiers.Any(c => c.IsKind(SyntaxKind.PartialKeyword)) &&
                classDeclarationSyntax.AttributeLists
                    .Any(astx => astx.Attributes
                        .Any(x => $"{x.Name.ToFullString()}Attribute" == targetName)))
            {
                Classes.Add(classDeclarationSyntax);
            }
        }
    }

コード生成

いよいよ、抽出したクラス定義に基づいたコード生成を行ってみましょう。
ここでは、該当するクラスに Log() メソッドを自動的に生やす実装をしてみたいと思います。

抽出したクラスをつかって Log メソッドを生やす例

用意した AttributedMethodReceiver に抽出したクラス定義を確認し、クラス名を取得します。
クラス名は、partial クラスの生成コードに埋め込み、生成されるコードのファイル名にも使用しています。
ここでは、単純に文字列としてコードを表現しています。

    public class SimpleSourceGeneratorLoggingAttribute : Attribute
    {
    }
    [Generator]
    public class SimpleSourceGenerator : ISourceGenerator
    {
        public void Initialize(GeneratorInitializationContext context)
        {
            context.RegisterForSyntaxNotifications(() => new AttributedMethodReceiver<SimpleSourceGeneratorLoggingAttribute>());
        }

        public void Execute(GeneratorExecutionContext context)
        {
            var syntaxReceiver = (AttributedMethodReceiver<SimpleSourceGeneratorLoggingAttribute>)context.SyntaxReceiver;

            // 対象のクラスを順番に処理する
            var classes = syntaxReceiver.Classes;
            foreach (var c in classes)
            {
                var className = c.Identifier.ToString();
                var code = new StringBuilder();

                // コードを文字列として組み立てる
                code.Append("using System;");
                code.Append($@"
public partial class {className}
{{
    public void Log(string text) 
    {{
        Console.WriteLine($""{{text}}"");
    }}
}}");
                // 生成したソースコードを書き出す
                context.AddSource($"{className}.g", SourceText.From(code.ToString(), Encoding.UTF8));
            }
        }
    }

このジェネレーターを通して生成されるコードは以下のようなものとなります。

using System;
public partial class GenTestClass
{
    public void Log(string text) 
    {
        Console.WriteLine($"{text}");
    }
}

このジェネレーターを使うことで、以下のように Log メソッドが定義されていないクラスで Log() 呼び出しができるようになりました。動作確認用プロジェクトを実行して、実際にログが出力される様子を確認してみましょう。

    [SimpleSourceGeneratorLogging]
    public partial class GenTestClass
    {
        public void SomeMethod()
        {
            Console.WriteLine($"Some method called");
            Log("MyLogger");
        }
    }

サンプルコードの注意

このサンプルコードは要点をシンプルにするため簡略化されています。クラスを namespace 下に定義すると、生成コードが機能しません。対象クラスの SyntaxNode を親方向にたどって、NamespaceDeclarationSyntax ノードを探し、見つかった場合は、namespace で囲ったコードを生成する必要があります。

暗黙的に関数が定義されることには注意が必要です。ジェネレーターを使うことによる学習コストの増大とプロジェクトの方針をきちんと擦り合わせ、ドキュメントなどを用意して機能の周知をする必要があるでしょう。

さいごに

ソースジェネレーターは、アスペクト指向な設計や、スキーマを要求するようなプロジェクト、フレームワーク開発にとって非常に有用なツールだと感じました。
(すいません、Unity で動かすところまで、書ききれませんでした。)

Unity でも使えるので、いろいろ応用がききそうですね!
本記事が、皆さんのジェネレーター開発の土台作りに役立てばと思います!

参考資料

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/07/14d9bb73a591c2dd5cc4696e7ce831cb.png
事業部配属後研修(第二事業部)(^^)/ https://developer.aiming-inc.com/activities/post-10310/ Thu, 11 Jul 2024 08:25:21 +0000 <![CDATA[取り組み]]> <![CDATA[新人研修]]> <![CDATA[第2事業部]]> https://developer.aiming-inc.com/?p=10310 <![CDATA[はじめに こんにちは!人事担当です! 前回は第一事業部配属後の研修をお届けしましたので、今回は第二事業部の研修についてお伝えします。 第二事業部(Team Caravan)の配属後研修 第二事業部では、基礎研修後すぐにプロジェクトに配属となり、OJT形式で先輩社員とペアになり少し […]]]> <![CDATA[

はじめに

こんにちは!人事担当です!
前回は第一事業部配属後の研修をお届けしましたので、今回は第二事業部の研修についてお伝えします。

第二事業部(Team Caravan)の配属後研修

第二事業部では、基礎研修後すぐにプロジェクトに配属となり、OJT形式で先輩社員とペアになり少しずつ業務を覚えます。
業務に必要な情報やスキルを、入社後すぐに学べるため実践経験を多く積むことができます。

今回はその中でも「デザイナー」職の研修について詳しくお伝えします✨

デザイナー研修スケジュール

基礎研修後、デザイナーは、ご自身の担当セクションのみならず、他セクションについての研修も受講していただきます。
他セクションへの理解を進めることで、業務での連携や、スキルや裁量にも幅が出ます!
研修ではトレーナーと呼ばれる先輩社員がつき、先輩が優しくサポートするため安心です✨

さっそく順番にそれぞれの研修の中身を紹介します!

MAYA研修

Aimingでは3DモデリングソフトとしてMAYAを使用しています。
なぜかというと、ゲーム、映像等CG業界に最も広まっているソフトツールだからです。

MAYA研修では、基礎的なMAYAソフトの使用方法から学ぶことができ、MAYAを用いたモデリング経験がなくても、研修でしっかり学べます(^^)/
そもそもモデリングとは??や、
どういう手順を踏んでモデルを作るのか
作るモデルには、ポリゴン数の制限もあるため、限られた中でどこにポリゴンを割くと見栄えがするか、質感の表現ができているかなど意識してモデルを作っていきます!

モーション研修

さてモデルを作ったら実際に動かす研修です。

モデルに動きを付けることによって、大きく印象が異なります。
性別、年齢、服装、どういったバックグラウンドのあるキャラクターなのか等…キャラクターに物語を持たせることができますね!

人間は筋肉が動くことで、身体が動きます。
キャラクターにも同様に動く仕組みがあります。
魅力的な動きをつけるために、概念部分から学び、実際にボーンを入れて動かしていきます。

エフェクト研修

素敵なモーションがついたモデルの動きに併せて、視覚的な効果をつける仕事としてエフェクトデザイナーがいます!
キャラクターが使う攻撃以外にも、電気や水といった自然表現、UIで使用する特殊効果など、ゲーム画面の中には様々なエフェクト表現があります。
エフェクト表現一つで、攻撃しているのかダメージをうけたのか、防御スキルが発動したのか等、動きだけでは判断できないものが一目でわかるようになります。

研修では炎、爆発、竜巻、剣閃といった、攻撃モーションにつくようなエフェクト素材の作成を作成しました!

UI研修

最後にUI研修を実施します!

プレイヤーがゲームを操作できる部分、ユーザーインターフェースのデザイン業務です。
ホーム画面、キャラ育成画面、戦闘画面等、ゲームの画面の目的によって、様々なレイアウトを作成します。
画面作成だけでなく、わかりやすく、コンセプトにあったアイコンやバナー作成等も担当します。
ただ、とてもかっこいいアイコンを作っても、小さすぎて押せない…!となっては意味がないため、全体的な画面構成を考えつつ、ユーザーにとって最適なレイアウトを考えます。

今年の研修では、実際にUIデザイナー業務の体験を研修としてカリキュラムを作成しましたよ(^ ^)/

研修の完成品

すべての研修を通して完成した作品がこちら!
初めて取り組むことでも、研修を通して学ぶことができるので安心です✨



おわりに

いかがでしたでしょうか?
今回は24年新卒の第二事業部研修についてお届けしました!

事業部毎に実施する研修内容は異なりますが、③業務に必要なスキルを身に着ける、を目的としてカリキュラムを組んでいるため、どちらも充実した研修を実施していますよ✨

研修の内容やその他のことでも、
Aimingに対して気になることがあれば是非こちらのフォームよりご連絡ください(^ ^)/

それではまた次のブログでお会いしましょう~!

]]>
https://developer.aiming-inc.com/wp-content/uploads/2018/07/ogp-default.png
24年新卒ゲーム開発研修【魔法鍋へのリクエスト】 https://developer.aiming-inc.com/activities/post-10138/ Fri, 28 Jun 2024 04:32:40 +0000 <![CDATA[取り組み]]> <![CDATA[ゲーム開発]]> <![CDATA[新卒研修]]> <![CDATA[第一事業部]]> https://developer.aiming-inc.com/?p=10138 <![CDATA[  はじめに はじめまして、第一事業部 プランナー 香港出身の林(レム)と申します。 今回は、4月中の研修で学んだことを生かすことを目的として行われた「ゲーム開発研修」についてお話します! 1ヶ月間のゲーム開発活動では、プランナー1人、デザイナー2人、エンジニア 2人の […]]]> <![CDATA[

 

じめに

はじめまして、第一事業部 プランナー 香港出身の林(レム)と申します。
今回は、4月中の研修で学んだことを生かすことを目的として行われた「ゲーム開発研修」についてお話します!
1ヶ月間のゲーム開発活動では、プランナー1人、デザイナー2人、エンジニア 2人のもとに、ゲームの企画立案から最終発表まで行いました。
このブログはチーム全体の5人でお届けします。ぜひ最後までお読みいただければ幸いです!

回作ったゲームについて

今回は【魔法鍋へのリクエスト】という名前の料理シミュレーションゲームを作りました🍲

ゲーム概要

対応プラットフォーム:Windows
プレイ人数:1人
ゲームターゲット:中学生以上の人、創作料理が好きな人、試行錯誤しながらプレイする人

世界観

千年前の「ミーロン流星群」の後、1人のドワーフは魔法の鍋を発見した。
その鍋と共にドワーフはキッチンカーでスープ屋をしながら、旅をしていた。
もうすぐ、千年ぶりの流星群が見られるらしい…

コンセプト

・食材の特徴と要望に沿って、料理の組み合わせを考えること
試行錯誤と模索の過程を重視し、考えさせるようにすること

セールスポイント

1. ユーモアのある、かつ考えさせるような表現

お客さんの注文や食材の特徴について、あえて曖昧な表現にしました。
くわえて、お客さんそれぞれの設定に工夫し、独特な口調や注文内容にこだわって作りました。

時には、辛辣なコメントもあったりします….笑
それによって、ユーザーの想像を巡らし、自ら食材の組み合わせを考え、評価を楽しめます!

2. ファンタジー的な絵柄と独創的な料理

今回は、企画段階からリアルの食材を参考にしつつも、奇妙さを重視し、ファンタジーに近い方向性にしました!
私からの提案で、すべての食材に動きを足して【動詞+食材】に命名しました。

・はねる魚肉
・ケルベロスの肉
・さけぶ白菜
・おどるゴーヤ
・ねるレモン

職種が意識したこと

企画について

今回の研修では、ゲームデザイナーとして企画考案、仕様書作成、スケジュール管理、バランス調整などを担当させていただきました。
特に1ヶ月という短い開発期間を考慮し、チーム内のコミュニケーションを意識し、橋渡しになるように立ち回りました。
また、スムーズな開発ができるように、以下のことを意識して開発を進めました!

・仕様書の作成

今回は「わかりやすさ」に特化した仕様書を作成するように心がけました。
4月の仕様書作成の研修を経て、他の職種の人にとっても読みやすく、かつわかりやすいことが重要であると理解しました。
そのため、今回はとりわけ表やイメージ画像を活用しつつ、他の人が読んでもわかるように工夫しました。

▼仕様書のイメージ画像

▼実際のゲーム画面
このように、想像したゲーム画面のイメージ画像を作成し、UIの配置やそれぞれのサイズ感をわかりやすく伝えました。

・スケジュール管理

1ヶ月の開発期間という前提もあって、チームメンバーと話し合った結果、今回はまず「完成」を目標にしました。
4月の研修やメンターとの相談を踏まえ、スケジュール管理においてプランナーは、各メンバーが動きやすいように調整する必要があると実感しました。
したがって、今回は1ヶ月内に「完成」できるように、必要な内容を洗い出し、タスクの削減に努めました。

そのほか、各職種がスケジュール通りに作業できるよう、以下のことを意識しました。

各職種と相談し、予定を設定したこと
・素材追加の締切を早めに設定したこと
デバッグの時間をしっかり用意すること

・世界観の表現・色の調整

デザイナーと相談しながら、世界観に合うようなBGMや効果音、フォントを選定しました。
特に、時間をかけて色の調整に工夫しました!
ゲーム内のテキストは、多様な色覚に配慮し、色のシミュレーターを使って何度も調整を重ねました。

食材メニューで使用した色

デザインについて

・2D関連

食材と料理のデザインにユニークさをもたせるように、こだわりました。

一部の食材と料理

 

シナリオは、キャラクターへの愛着を感じてもらうことや、ゲームのボリュームに合わせたすっきりとまとまったものにすることを大切にしました!
エンディングスチルでは、ステージ内に描写のなかったキャラクターたちの一面」を描いたうえで、ラストの一枚絵に繋げるような演出になっており、とても気に入っています。

シナリオの画像

コンセプトデザインを担当したこともあり、愛着を持って制作にこだわることが出来ました。
また、自分の仕事だけでなく、チーム全体の状況を把握して、タスクの優先順位をつけていくことを学びました。

・3D関連

1ヶ月という短い制作期間の中で画面を完成させるには、以下の3つが重要だと考え、制作に臨みました。

共通化による効率的なアセット作成
ユニーク(1点もの)による世界観
ビジュアルの表現

具体的に、以下は「共通化」と「ユニーク」についてお話します!

・共通化

・アニメーションの使いまわしができるように、各キャラクターをHumanoidに対応
・量産しやすいよう、一度作成したメッシュを流用・調整

・ユニーク

・ステージごとに異なる環境エフェクト、グローバルボリューム等の調整を行い、ステージごとの見た目の違を実装
NPCの反応を楽しんでもらえるように、キャラクターリアクション(表情)をそれぞれ制作
・このゲームならではのビジュアル表現を目指し、その他シェーダーグラフ等を活用

お客さん3Dモデル画像

実装について

・大まかな設計

チーム開発研修前に行ったコーディング研修で、ゲーム開発における設計について詳しく学びました。
その研修では主にMVCやSolid原則、アジャイル開発における手法などについて学びました。
今回の開発はそこを意識して、基本的には機能単位で、MVPをベースとしたつくりになっています。
ゲーム全体はStateパターンを意識した制御を行いました。

・意識した内容

特に意識した点は動作物を最優先に作ることです。
短い期間での開発となるので、とにかく動くものを最優先に開発を進めました。
また、エンジニアの方以外でも調整しやすいように、コードではなくアニメーションやスクリプタブルを使って開発を進めました!
4月の研修を通したことでエンジニアとしてだけではなく、他職種を理解し、それに寄り添える開発ができたと思っています。

修への感想

プランナー:林
今回は私の初めてのゲーム開発でしたが、スケジュール通りにゲームが完成されたことに達成感を感じました。初めての仕様書作成、スケジュール管理、エフェクト作りなどなど、初めてのことにいっぱい挑戦できた1ヶ月でした。
タイトなスケジュールにもかかわらず、予定よりはやくタスクをこなしてくださったチームメンバーの努力の賜物だと思います!
研修で初めて使用したGitやUnityの技術も今回のゲーム開発に活かせて、より「プランナー」としての役割やチーム内の立ち回りを実感したと思います。まだまだプランナーとしての反省点が多いですが、今回の経験を踏まえて今後のゲーム開発もがんばっていきたいと思います!

2D担当のデザイナー:田中
色々挑戦の多いゲーム開発になり、とてもいい経験が出来たと思います。
研修の座学で学んだGitを使用したことは、今後の業務においても役に立ちそうです。
ビジュアル面に関して、世界観やキャラクターデザイン、一枚イラストなどは比較的得意とするところでしたが、それ以外のUIやマップデザインなどが上手くいきませんでした。
ただ全体のコンセプトデザインが出来てとても楽しかったです!これからも精進します。
3D担当のデザイナー:岩井
過去に3Dゲーム開発の経験はあったのですが、ほぼすべての3D工程を担当することは初めてでした。そのため過去の経験や研修で学んだGitやUnityなどの知識を活用することで開発を滞りなく進める事ができました。
またエフェクトやアニメーション・表情切り替えなどについては、ほとんど経験がなかったため新鮮で楽しかったです。半面、タスクが非常に多くなってしまい、実現できなかった事も多くありました。今後の開発ではこのような事がないように実力を付けて行きたいと思います。
インゲーム担当のエンジニア:廣瀬
今回のゲーム開発では、エンジニア以外もGitを使用しての開発となりました。
Git、Githubのエンジニアからのアシストを満足に行えず、なかなかうまくチーム開発を進められず、反省点が多い開発となりました。しかし設計に関してはコーディング研修で行った部分を生かすことができとてもよかったです。
今回の研修で培った知識や技術を業務でも生かしたいです。
アウトゲーム担当のエンジニア:下田
目標としていたラインの成果物が、余裕をもって完成させることができました。
また、デザイナー研修やプランナー研修を通したことで、多職種への配慮をした開発ができました。
しかし、設計やGit/Githubと、理解が足りていない点があり時間がとられることがありました。今後の業務で、より良いエンジニアとなれるよう努力していきます。
]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/06/ED.png
24年新卒ゲーム開発研修【五右衛門の猫娘】 https://developer.aiming-inc.com/activities/post-10179/ Fri, 28 Jun 2024 04:32:26 +0000 <![CDATA[取り組み]]> <![CDATA[ゲーム開発]]> <![CDATA[新卒研修]]> <![CDATA[第一事業部]]> https://developer.aiming-inc.com/?p=10179 <![CDATA[はじめに 僕たちは新卒Bチームとして運営1人、デザイナー2人、エンジニア2人の5人チームでゲームを作成しました。 今回のブログではまず一番最初にゲームの説明を軽くして、5人それぞれの担当したこと、研修を通して学んだことについて書いていきたいと思います。 最初のゲームの紹介は、運営 […]]]> <![CDATA[

はじめに

僕たちは新卒Bチームとして運営1人、デザイナー2人、エンジニア2人の5人チームでゲームを作成しました。
今回のブログではまず一番最初にゲームの説明を軽くして、5人それぞれの担当したこと、研修を通して学んだことについて書いていきたいと思います。
最初のゲームの紹介は、運営の照井が書きます。

今回作ったゲームについて


今回のゲーム制作では、企画の一番最初の段階は5人全員で相談して決めました。
研修の前に何時間か時間をとっていただき相談したのですが、ゲームのジャンルすらなかなか決まらなかったです。
途中で「もうそろそろ決めないとまずい」となって、わりとごり押して決めた覚えがあります(笑)
ただゴリ押したのも悪いことだとは思っていなくて、全員の考えを広く聞くのもいいですが意見をある程度聞いたら、だれかがゴリ押して中身を詰める時間をもっととってもよかったなとは少し思います。
「船頭多くして船山に登る」ということわざがあるように、5人そろうとみんな経験や知識も違うのでだれかが多少強引にでも方向を示さないとチームで物事を決めるのは難しいと感じました。

ジャンル

盗賊ビルドRPG


企画を考えるにあたって、まずどんなゲームジャンルにするかを決めました。短い制作期間しかないですが、楽にできるものでなく、しっかりやりごたえのあるゲームにしたいということで、要素さえ作ってしまえば組合せでおもしろくして行けるビルドのあるゲームを作ろうということになりました。はじめはローグライクだったのですが、制作期間の都合や社員のかたに遊んでいただける試遊時間が短いという理由から、周回要素を
削りました。
もう一つの要素である盗賊のほうなのですが、ただ敵を倒してビルドでは独自性がたりないということで、倒すかビルドするかの選択肢をもたせることにしました。ポケモンのように相手の装備を盗んだら、戦闘に勝利でき、かつポケモンとは違いミニゲームで相手の武器が盗めるか決まるところにこのゲームの新しさがあります。

世界観・テーマ

五右衛門の物語x擬獣化した世界

ゲームジャンルに盗みという要素をいれたので、世界観にも盗みの要素を入れたいということになり昔の日本の義賊である五右衛門を登場させ、五右衛門の娘を主人公にしました。
けもの要素はデザイナーが決めてくれました。全体的に和風でかわいい感じになり、けもの化してよかったなと感じてます。

ターゲット

10~30代
ある程度RPGに慣れ親しんでる人
ビルドの要素を楽しみたい人

ここはとってつけたようにあとから考えました。ただもう少し早めに決めておくと企画や難易度設定の指針にもなったかなと思います。

ゲームの売り

上の要素からこのゲームの売りはしたの二つになりました。

RPGx盗みシステム

敵の武器を盗んで、リソースの組み合わせで多様な体験を作ることができる

和風xケモノ

戦国時代を舞台にして、擬獣化したキャラクターたちが登場する

あらすじ

元忍者で義賊のゴエモンとその娘モモは悪い人から宝を盗んで、貧しい人々に配っていた。次のターゲットは、太閤秀吉。秀吉は民衆からバナナや宝を無理やり奪い取り、バナナを独占していた。独占されたバナナを盗みにゴエモンとモモは秀吉の城に侵入するが、その途中でゴエモンがモモをかばい捕らえられてします。何とか逃げ出すことができたモモは、父を助けに行くことを決意する。果たしてモモは無事に父を助けることができるのか!

ゲームサイクル

企画 照井

改めまして、第一事業部運営の照井です。このチームにはプランナー職が居なかったため、今回のゲーム制作研修では企画、ディレクターを担いました。今回は私が担当したことや企画ディレクターとしての反省点、ゲーム制作研修を通して感じたことについて書いていこうと思います。

担当作業

・仕様書作成
・データ周りのプログラム
・バランス調整
・進行管理

上記のことを中心にいろんなことをやっていました。
仕様書作成は、研修で教えてもらってはいたもののはじめての作業だったので網羅しきれず、作業が進むにつれ、網羅しきれていない部分、抜けている部分が浮き彫りになってしまいました。
これは仕様書レビュー会を行えば防げたかなと思います。
またゲームにデータを入れるプログラミングも行いました。大学院ではそこそこプログラミングをしていたのでもうすこしかけるかなと思いましたが、チーム制作やゲーム制作特有の流儀があり、なかなか苦戦しました。一方でエンジニアたちが設計をしっかりやってくれていたのもあって、どこにデータを入れれば動くかがわかりやすかったのでそのあたりはやりやすかったです。エンジニアさんたちには逆に手間をとらせてしまいましたが、いままでしっかり考えてこなかった設計やモデルについて学ぶことができとても楽しかったです。また新卒研修で学んだGitの使い方やプログラミングの考え方も作業やエンジニアさんとのコミュニケーションをとるうえで役立ちました。
バランス調整は本当に大変でした。今回作ったゲームがローグライク要素の強いゲームとあって調整するパラメータが多かったです。正直この短い期間ですべてをバランスよくするのは難しいため、まずどこを中心にバランス調整をするか考えました。自分は「困難を乗り越える」ときにこそゲームのおもしろさを感じられると考えたので、今回はボスを中心にバランス調整を行いました。結果として少し難しくしすぎたので、やはりバランス調整は一筋縄ではいかないのだなと実感しました。

企画ディレクターとしての反省点

作業をやりすぎた

企画をやったことないため、何をしていいのかわからなかったので、エンジニアの作業をやることが多くなってしまいました。そのため自分の目の前のタスクのことでいっぱいいっぱいになり、ディレクターとして行うべきチームの考えの統一や進行管理が甘くなってしまいました。結果、制作の最後のほうではゲームには盛り込めないタスクもいくつか出てしまいました。自分の手元の作業がないと不安になりますが、ディレクターは作業をやらずに心の余裕をもって全体の把握に務めるのがよさそうだと感じました。

口頭でおこなった相談は文章としても残しておくべき

口頭で相談をよくしていたのですが、記録をのこしていなかったため齟齬が生じました。自分でも言ったかどうか、何処まで言ったかはわすれてしまうためしっかり文字として記録することが大切だと実感しました。

ゲーム制作研修を通して感じたこと

チームでものを作ること、ゲームを作ることはたのしいなと感じました。自分の考えたことがエンジニアのコードやデザイナーの絵で形になっていき、一人ではとても完成できないものを作り上げることができて感動しました。制作終盤がこのゲームが本当に面白いものになるのか不安なタイミングもいくつかあったのですが、手触りやバランスの調整をこつこつとおこなっていくことで、「おっ、このゲームちゃんとおもしろいじゃん!」となっていったときはすごくうれしかったです。このゲーム自体にもやり残したものはありますし、この研修で味わった感覚をまた味わいたいので、今後もたくさんゲームを作っていきたいです。

エンジニア 神原

第一事業部、クライアントエンジニアの神原です。
今回の開発で担当した作業の内の、マップの設計について簡単に書かせていただきます。
また、開発全体を通しての良かった点や反省点も書いていこうと思います。

やりたいこと

進めるマスが複数存在し、その中の1つのマスを選んで進むといった仕様になっているため、マスに選べるかどうかの状態を持たせる必要があります。
また、そのマスがどんなマスなのかをアイコンで示すので、アイコンの表示も必要です。

設計

表示する要素とデータを連動させたいため、MVRPパターンを使いました。
ライブラリとしてUniRxやUniTaskを入れていたため、実装しやすい環境だったのも決め手の1つです。
主な流れは、マップシーンに遷移したあと、MonoBehaviourを持つPresenterにModelを流し込み、それを見てViewを更新し、アイコンの表示や次のマスまでの道の表示をしています。
また、渡されたModelに応じてマスが選ばれたときに任意の処理を発火する処理を仕込みます。
例えば、敵と戦うマスが選ばれたらバトルシーンへ遷移する、といった感じです。

良かった点

序盤から、ある程度きれいな設計を意識しながらコードを書けたので良かったです。
特に恩恵を感じたのは、バグが起きた際にどこが悪いのかはっきりした点です。
クラスや関数の責任をはっきりさせることで、修正すべきコードがすぐに見つかり、作業時間の短縮に大きく貢献しました。
また、研修でペアプロやモブプロについて学んだのですが、設計をするときやPRのレビューをするときに学んだことが活かせたと思うので良かったです。
特に、思考の順序や基準、気を付けていることや避けている書き方などが分かり、その後の設計やレビューがより効率的になりました。

良かった点

研修の中で行ったペアプロ/モブプロに近いことを、開発研修でも出来たのは良かったと思います。特に実装時に何を考えてコードを書いているのかを知ることが出来、知らない技術などを学ぶ機会になりました。

反省点

開発期間に対してやりたいことが多すぎたので、実装しきれなかった仕様がいくつかありました。
特に反省すべきだと思うところは、機能や仕様のそぎ落としを開発中盤〜終盤にかけて行ってしまったことです。
せっかくデザイナーさんに書いていただいた絵がゲーム内に出てこないなど、エンジニアの都合で実装できなかったものが多く、申し訳ない気持ちでした。
開発期間を見て工数を見積り、序盤や企画段階で仕様のそぎ落としをしていれば、このような事態にならなかったのだと思います。
また、序盤に作ったきれいな設計に引っ張られて、中盤以降も序盤と同じくらい設計を吟味していました。
時間が足りなくなっているので設計のレベルを落として開発速度を上げるべき場面でしたが、当時はその判断ができませんでした。
さらに、終盤になって急にレベルを落とし始めたので、初心者のようなコードが残ってしまいました。
この日からはレベルを落とすことを許容する、といったように速度を上げる期間を明確に決めておけば良かったと思います。

感想

全体を通してかなり楽しめたと思います。
エンジニアとして楽しかったことは、コードを書いているときはもちろん、PRのレビューや設計、実際にコード通りにゲームが動くところです。
また、チームの一員として楽しかったことは、ゲームの仕様を考えたり、非エンジニアにgitを教えたり、デザイナーさんに仕上げていただいた素材を見たりすることです。
ゲームを作ることは大変だと思いますし、今回も大変でしたが、優秀なチームメンバーのおかげで良い作品に仕上がったと思います。
チームの皆さん、本当にありがとうございました。

エンジニア 武藤

第一事業部でクライアントエンジニアをしている武藤です。
担当した箇所の説明をすると複雑になりそうなので、今回は攻撃した場合のバトルの流れについて簡単に説明していきます。

バトルの入力処理

やりたいこと

前提として、このゲームはバトル中に、行動を決めるフェーズと実行処理を行うフェーズがあります。
実行処理を神原君が担当してくれるということで、入力処理ではユーザーによって決定された行動を渡すという実装になっています。
前述のように、攻撃のみの説明になるためザックリとしたクラス図を書いてみました。(初めてクラス図を書いたので、大目に見てもらえると幸いです)
それをもとに説明していきます。

バトルの全体をまとめるTurnControllerがBattleInputPresenterの入力待機の関数を呼び、結果が返るまで待機します。
Viewは複数のButtonを持っており、Buttonが押されると対応した武器のModelがBattleInputPresenterを経由してTurnControllerに返されます。
ここで返ってきた武器のModelがBattleStateControllerに渡され、その後の実行処理で使用されることになります。
実行処理を終えるとTurnControllerが再度、入力待機の関数を呼ぶという感じになります。

行動を決めるフェーズには攻撃のほかに、敵の武器を盗むアクションがありますが、そちらも同じようなことをやっています。

反省点

期間と工数

今回は1か月という短い期間の開発だったのですが、未実装のまま終わってしまった要素が多くありました。期間に対して設計の時間を多く取りすぎてしまったというのが原因です。
開発期間から逆算して、実装にかける工数を決めることに慣れていなかった為、これが上手く出来ていれば、もっといい開発が出来たのかもしれないと思いました。
使われなかった素材たちを供養したい…

コードレビューは急がば回れ

バージョン管理をGitで行い、エンジニアがPRを確認するやり方で開発を進めていたのですが、マージ後に問題が起きることがありました。PRの確認を丁寧にしていなかったことが原因です。
スケジュールが押していて急ぎたい気持ちだったのですが、結果的にマージ後の問題対応をすることで、さらに遅れが生じることになりました。少ない時間の中で、どこに時間を掛けなくてはいけないのかを考える必要があったと思います。

デザイナー 宓

担当分野

第一事業部、デザイナーのミです。

今回のゲーム開発研修でビジュアル担当の二人はともに2Dデザイナーですが、それぞれの得意分野や経験を活かし、お互いの不得意な部分を補完し合うことで作品を完成させました。

私は昔2Dアニメーションでゲーム制作した経験があるので、アニメーションを描く際の注意点や、Unityでの実装操作をスムーズに行うことができます。一方、チンさんはゲームジャムに参加した経験があり、キャラクターデザインやステージの背景などを短時間で高クオリティのイラストを完成させることができるので、全てを任せました。

これからは、それぞれ工夫した内容や反省点、感想をお話します。

アニメーション

アニメーション担当のミです。 今回のゲーム制作では、主に以下の四つのアニメーションに分かれています。

・キャラクターアニメーション
・エフェクト
・異常状態
・背景アニメーション

一番時間がかかったのは、当然ながらキャラクターアニメーションです。主人公は16種類の武器のアニメーションに加え、待機やHPが削られた時などのアニメーションも描く必要がありました。元々は全ての敵にも待機アニメーションをつける予定でしたが、締め切りが迫っているため、割愛し、ボスのアニメーションだけ用意しました。

主人公アニメーションは、下記の流れで制作しました。

先ず、アニメーションスプライトを準備します。注意点としては、全てのスプライトのイラストが同じサイズであることと、キャラクターが同じ位置に配置されていることが重要です。これにより、アニメーションを切り替える際にずれがないようにします。

また、主人公だけで計19体のアニメーションがあり、一つ一つ丁寧に描く時間がなかったです。短期間で完成させるように、以下の2点を工夫しました。

1.アニメーションを分けて制作する
2.アニメーションを再利用する


1.攻撃アニメーションは、「武器を取る」、 「武器で攻撃する」、 「武器をしまう」の三つのアニメーションに分けて制作しました。武器を出す際に不自然さを解消するため、一度手を後ろに隠し、次のフレームで武器が現れるようにしました。これにより、アニメーションをスムーズに見せるだけでなく、作業量も削減することができました。

2.似たような攻撃動作、例えば投げ道具のクナイと石、を同じアニメーションで利用し、武器だけ入れ替えました。また、短刀と草刈りは全く異なる武器ですが、同じアニメーションを使っても違和感なく使っていました。
ただ、その中に絶対に妥協できないこだわりがあります。例えば刀と短刀、大筒と小筒。これらは同じ種類の武器ですが、重量や跳ね返りの影響を受けるため、両手で武器を持つことや、体の重心が後ろになるアニメーションに変更する必要があります。

その後はUnityで作業を進めます。上記の画像通りに、一連の作業をUnityで行い、すべてのアニメーションを完成させました。指定された武器のボタンを押すと、待機アニメーションから攻撃アニメーションに切り替えることができます。

上記の画像通りに、一連の作業をUnityで行い、すべてのアニメーションを完成させました。指定された武器のボタンを押すと、待機アニメーションから攻撃アニメーションに切り替えることができます。

反省点

説明の仕方

チームメンバーに何かをお願いする時に、いつも自分の視点で考えてしまっていました。デザイナーとしてビジュアル面にこだわりがある一方で、他の職種が理解しにくい内容もあり、説明が不十分でした。聞き手が理解しやすいようにするため、先に追加や修正を行う理由を具体的に説明したり、内容をまとめて書き留めたりすることが良いかもしれません。

優先順位の設定

ゲーム制作において、やりたいことは山積みです。例えば、プレゼン資料の背景やレイアウト、グッズなど優先度の低い作業がほとんどでしたが、「面白い」、「納得できない」という気持ちから、最終日にも多くのタスクが残ってしまいました。優先順位を最適化するため、チーム内で共有や、緊急の課題に優先的に取り組むよう努め、ガントチャートの活用、制作期間を明確に決めておいたほうが良いでしょう。

感想

初めてチームでゲーム制作を経験して、良い作品を完成できたことがとても楽しかったです!デザイナーの作業内容だけでなく、研修で学んだGit、GitHub、Mayaなどの知識を実際の制作に活かすことができたのも嬉しいです。これからもさらに成長し、業務に入っでも活躍できるよう努力していきたいと思います。お疲れ様でした!

デザイナー 秦

第一事業部、デザイナーのチンです。
今回の開発では主に2D関連の部分を担当しました。多分担当分野からも分かる感じなのですが、デザイナーの仕事内容は強みには分けていなく、お互い意見なども出し合い共に作業する内容も多い感じでした(世界観設定やUIなど)。
設定では「けもの」でしたので、キャラクターの個性(役目?)や動物の特徴などを重視してデザインをしました。
ゲーム開発前の研修で色々学ぶことができて助かりました。特にGITの構成や原理、プロセスなど事前に把握することで、実際触る時に慌てるのを少し緩めることができました。レポートをしっかり取ることで、重要な内容や使い方を復習できました。自分はデザイナーなのですが、講義でゲームの遊び方(ゲームならではの重要な所)を「ウリ(魅力)」に繋げることを学び、ゲームクリエイターとしての意識をより深めることができたと思いました。
最後まで楽しく作業できました!

良かった点

タイムリーなコミュニケーション

タイムリーなコミュニケーションをとることで、繰り返し作業や無駄な作業を控えることができました。そしてその時間を有効活用しゲーム全体のビジュアルをより良く仕上げることができました(ブラッシュアップなど)。「自分では分からない、理解できない」の場合、タイムリーにほかのメンバーに聞くことも重要なことです!勉強になりました!

重要度を元にスケジュールを立てる

作業内容の優先順位を事前に決めて、自分の作業効率を図ったうえで、時間の配分をバランス良く調整しました。(→緊急度と重要度のマトリクス←)スケジュールでは、最後の修正(ブラッシュアップ的な)の時間を予備することで、万が一のトラブル発生に対応できます。

反省点

作画に時間配布過ぎ

時間が殆ど作画に取られ、ほかの仕事をする余裕があまりありませんでした。色々な所で(gitは特に…勉強になりました)チームのメンバーに助けてもらいました。本当にありがとうございます!色々細かい作業内容(アニメーションとかエフェクトとか)も機会があったら作ってみたいです。

デバッグの説明がざつ

デバッグの時に、初めは気になる部分を口頭で伝えていました。その内容を文章にまとめて伝える方が良かったと思いました。

感想

自分としては、ほかのメンバーと共に同じ目標を目指してそれを達成できたので、今回のゲーム開発研修は素晴らしい体験だと思いました。絶対に一人では出来ないことを、仲間がいたからこそ、ここまでたどり着くことができたと思っております。Bチームの皆さん、サポートやご指導などしてくださったメンターさん方、本当にありがとうございます!この一か月間お疲れ様でした!今後もよろしくお願いいたします!

最後に

改めまして、この企画を企画していただいた人事、第一事業部の皆様、そして日々の日報から制作中の技術サポートまで様々なところで力を貸してくださったメンターの方々に感謝を申し上げます。
一か月間ありがとうございました。
また一緒にゲームを作ってくれたチームメンバーにも深く感謝しています。
この一か月間大変なこともありましたが、たのしかったです。また機会がありましたらこのメンバーでゲーム作りたいです。

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/06/8d3ae22041757e42baf0bc690ce227a1.jpg
事業部配属後研修(第一事業部)(^^)/ https://developer.aiming-inc.com/activities/post-10271/ Fri, 28 Jun 2024 04:32:12 +0000 <![CDATA[取り組み]]> <![CDATA[新人研修.]]> https://developer.aiming-inc.com/?p=10271 <![CDATA[はじめに こんにちは!人事担当です! 今回は以前公開した基礎研修後の、③業務に必要なスキルを身につけることを目的として実施した事業部配属後研修の一部を公開します。 今回のブログでは第一事業部の研修をご紹介します! 第一事業部(Twilo)の配属後研修 第一事業部の全体スケジュール […]]]> <![CDATA[

はじめに

こんにちは!人事担当です!
今回は以前公開した基礎研修後の、③業務に必要なスキルを身につけることを目的として実施した事業部配属後研修の一部を公開します。

今回のブログでは第一事業部の研修をご紹介します!

第一事業部(Twilo)の配属後研修

第一事業部の全体スケジュールはこちら!

社会人としての基礎的な文章作成講義をはじめ、オンラインゲーム開発をする上で必要な知識を座学と実務を通して学びます!
職種関係なくオンラインゲームにかかわる職種全体の業務を把握するために、
エンジニアでもMAYAを使って実際にモデリングをする講義を受講し、プランナー/デザイナーでも実際にUnityを使って実装等を研修で学び、他職種への理解を深めます。

そして、研修で得た知識や技術を活用し「ゲーム開発研修」も初の試みとして実施しました!
そちらについては新卒が別途ブログを更新しますので、お待ちください!(^ ^)/

全ての研修の紹介ができないので、今回のブログでは「MAYA研修」「Unity基礎研修」の内容を簡単に紹介しようと思います!

コーディング研修についてはこちらで執筆していますので、是非ご一読ください

MAYA研修

入門CGデザイン-CG制作の基礎-[改訂新版]に沿って講義を進め、座学として知識を一通り学びます。
その後、実際に「ローポリモデルの作成」として各自デザイン案から考え、256ポリゴン内でモデリングをしました!
入門CGデザイン-CG制作の基礎-[改訂新版]に沿って講義を進め、座学として知識を一通り学びます。
その後、実際に「ローポリモデルの作成」として各自デザイン案から考え、256ポリゴン内でモデリングをしました!

講師には新卒入社社員4名がつき、新入社員のモデリング作業の補助をしました。
MAYAソフトを使用したことがない新卒でも、問題なく作業を進めることができていました(^ ^)/

そして作ったデータについて、制作意図、拘りを社員の前で発表してもらいました!

Unity基礎研修

Unityの教科書 Unity 2022完全対応版を教材として、講義をしました!
Unityを全く使ったことがない新卒入社社員は、同期のエンジニア新卒や講師に聞きながら、作業を進めて行きます。

そして今年は「MAYA研修で作成したモデルを動かす!」が講義内容に追加に!

自分自身が作ったキャラがUnity上で動いていることに多くの新卒が感動していました✨

実際に講義を受けた新卒のコメント

(エンジニア)
普段出来上がったモデルしか見てこなかったので、デザイナーの苦労が身に染みて気付くことができ、とても有意義な体験だった。
MAYA自体の機能があまりにも多く、モデルを少し変形させたいだけなのに、ボーンのせいで引き延ばされたり、意図していない頂点が動いたりしました。
今後使うことはありませんが、デザイナーの苦労が知れる良い機会でした。
(デザイナー)
これまでUnityでゲーム制作に参加した経験はあったのですが、システム部分やゲームのイベント部分といったゲームの根幹に触れて制作することは初めてでした。
そのため非常に新鮮でプログラミングも興味深く、正しくゲームとして動作していることに感動しました。
またこれを仕事としているエンジニアの方々のすごさも実感できました。

と研修の目的だった「他職種への理解を深める」を体感しており、とても良い研修になったかなと思います!

おわりに

いかがでしたでしょうか?
今回は24年新卒の第一事業部研修についてお届けしました!
第一事業部の新卒だけでゲームを開発したゲーム開発研修についてのブログもぜひ読んでください!

次回は第二事業部の研修についてお届け予定です!
お楽しみに✨

]]>
https://developer.aiming-inc.com/wp-content/uploads/2018/07/ogp-default.png
24年新卒基礎研修について(^^)/ https://developer.aiming-inc.com/activities/post-10122/ Mon, 17 Jun 2024 08:37:23 +0000 <![CDATA[取り組み]]> <![CDATA[新卒研修]]> https://developer.aiming-inc.com/?p=10122 <![CDATA[はじめに こんにちは!人事担当です! 2024年は感染症も落ち着き、数年ぶりに全ての研修を対面で実施できました! 今回は24年新卒向けに実施した新人研修内容を公開します! Aimingの新人研修は、まずはじめに、所属事業部関係なく基礎的な全体研修を実施します。 その後、事業部毎に […]]]> <![CDATA[

はじめに

こんにちは!人事担当です!
2024年は感染症も落ち着き、数年ぶりに全ての研修を対面で実施できました!
今回は24年新卒向けに実施した新人研修内容を公開します!

Aimingの新人研修は、まずはじめに、所属事業部関係なく基礎的な全体研修を実施します。
その後、事業部毎にそれぞれのカリキュラムに沿って研修をおこないます。

新卒の基礎研修実施の目的は、①②です。

①社会人として必要なスキルを身に着ける
・社会人としてのマナー、コミュニケーションの取り方
・情報の取り扱い方
②業界や会社知識を身に着ける
・Aimingという会社の事業、理念の理解
・ゲームクリエイターとして必ず知っておかなければ行けない法律知識
③業務に必要な基礎スキルを身に着ける

本日は研修ブログ第一弾として、①②を達成するために実施した「基礎研修」の内容をお届けしようと思います!

基礎研修スケジュール

研修目的①②を達成するために、今年は3日間で下記スケジュールにて実施しました。

1日ずつご紹介していきます!(^^)/

基礎研修1日目

Aimingでは内定式等は実施していないため、
4/1に配属部署、配属プロジェクトの発表を行います!
当日は、経営管理部部長から新卒へ辞令を手渡ししましたよ(^ ^)/

その後、弊社代表の椎葉から新入社員への挨拶がありました。
組織が大きくなるにつれて、社長と直接話せる機会は減りますが、新卒に対しては、入社初日に必ず椎葉と話す時間を設けています。
今年は時間が延長になるくらい、椎葉宛への沢山の質問があり大盛り上がりでした!

午後からは、会社員として会社と労働者間で締結している「雇用契約書」の読み合わせをはじめ、
「会社ルール」や「給与明細のみかた」等、社会人として知っておかなければならない事柄についてを労務担当がしっかり説明します!

最後に「SNS講義」を実施しました。
Aimingでは社内でSlackというチャットツールを用いてやりとりをしています。
SNS等の文字でのコミュニケーションに慣れていても、業務上で上手くコミュニケーションをとれるかは別です。そのため、業務上気を付けなければいけないポイント等を詳しく講義でケーススタディとともに学んでもらいます。
相手を不快にさせないコミュニケーションを心がけたいですね。

基礎研修2日目

2日目は、さらに座学を通して大切なことを学びます。
まず会社についての理解を深めていただくために、「会社概要」「事業内容」「各事業部」を始め、プロジェクトについても簡単に話します。

そして情報の取り扱いにどう向き合う必要があるか、万が一社用pcを社外のどこかで紛失してしまったらどう対応すべきか等、セキュリティ部門の担当者からの講義を受けます。
また、ゲームを開発する上で知識として絶対に知っていなければならない法律や事例を、実際過去起こった問題やケーススタディを元に学びます。

さらにAimingは上場している企業のため、インサイダー取引には絶対に気を付けなければいけません。
入社してすぐの社員にも不公正取引防止のための啓発活動(インサイダー取引規制研修)を実施し、防止に努めています。
インサイダー取引規制研修自体は、社内で定期的に実施しており、全社員基本参加のもと行っております。

基礎研修3日目(最終日!)

メール文章の作成方法や敬語、身だしなみといった、基本的な内容から、名刺の渡し方や仕事を効率的に進めるための管理方法等、働く上で必要な常識やマナーについての研修を実施しました。

そして毎年人気の、新卒社員のLT大会を実施しました。
当日は社内の一番大きい会議室からオンラインでも中継し全体で300名程度が参加し、大盛り上がりでした✨
新卒LT大会のお題は「自己紹介」で1人5分の持ち時間で自由に発表していただきました!

相互理解がスムーズにできるように、ご自身の趣味やこれまでの経験、出身地について様々な事柄を発表していただきました。
入社後すぐに、全社員の前での発表は緊張したと思いますが、またとない機会でとても良い経験になったのではないかと思います!


発表をきいた後、同郷の社員や、共通の趣味を持った社員が新卒社員をさっそくSlackのhobby窓(趣味等を話すチャンネル)に招待していました!

さいごに

今回は24年新卒に実施した基礎研修内容を簡単にお伝えしました!

3日間という短い期間で、多くの知識や情報の詰め込みがあったため、新卒の方は大変だったかと思います。
ただ、講義終わりに積極的に質問したり、同期同士で相談したりしており、理解を深めようとする姿が印象的でした!
これからも研修で学んだことを忘れずに、業務に励んでいただきたいです!

基礎研修については以上です!
研修目的③業務に必要な基礎スキルを身に着ける、を目的に実施した各事業部研修についても別途ブログを更新予定ですのでお待ちください(^ ^)/

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/06/48671a73336f6b1e504a4b7621f8d4b9-scaled.jpeg
技術書典16に参加しました(^ ^)/ https://developer.aiming-inc.com/activities/post-10106/ Mon, 03 Jun 2024 07:21:39 +0000 <![CDATA[取り組み]]> <![CDATA[エンジニア]]> <![CDATA[技術書典]]> https://developer.aiming-inc.com/?p=10106 <![CDATA[はじめに こんにちは!人事担当です! 以前から告知していたとおり、技術書典16に参加してきたので、レポします! Aimingブースについて 池袋サンシャインまでは、迷うことなくすいすい行けたのですが、展示ホールDに行くまでに迷ってしまいました…💦 ただ、技術書典のスタ […]]]> <![CDATA[

はじめに

こんにちは!人事担当です!
以前から告知していたとおり、技術書典16に参加してきたので、レポします!

Aimingブースについて

池袋サンシャインまでは、迷うことなくすいすい行けたのですが、展示ホールDに行くまでに迷ってしまいました…💦
ただ、技術書典のスタッフさんが優しく誘導してくださりなんとか辿りつくことができました!

当日は11時開始だったので、サークル通行証を登録し9時30分からブース設営をしました✨
設置したAimingブースはこんな感じです!!
他企業様のブースもとても素敵で、レイアウトの勉強になりました…✨

弊社ブースでは、執筆者2名が売り子として参加していました!
Tech Bookの内容に興味をもってくださった参加者の方が話しかけてくださり、技術の話で盛り上がりました~✨

そして告知していた通り、第二事業部のマスコットキャラクターも応援に駆けつけました!
沢山の方が一緒に写真を撮ってくださりとても嬉しいです(^ ^)

Aiming Tech book Vol.4

技術書典16(オフライン)でだけ、本誌として配布しました!
多くの方に興味をもっていただき、当日配布分の200冊は早い時間に完売してしました><

もし内容気になっていた~!という方は、6/9(日)までこちらのサイトから無料でDLできますよ(^ ^)/
逃してしまってもboothではいつでも購入できます!✨(もちろん過去分も!)

ちなみに購入いただくと、こういったメールが届きます。
とても嬉しい気持ちになります(笑)

購入した本紹介

技術書典には様々な方が参加されていました!
弊社のように会社内の有志メンバーで技術について執筆しているところもあれば、個人出展でこれまでに得た知識をまとめた本や、勉強会運営するための内容をまとめた本まで、様々なケースがありました。

弊社エンジニアが技術書典で気になって購入した書籍の一部をこちらで公開します✨

最後に

実際にブースまでお越しいただき、Aiming Tech Book Vol.4を購入してくださった方、電子版を購入いただいた方、弊社にご興味をもっていただきありがとうございました!
また来年の技術書典にも参加したいな~と考えていますので、楽しみにしていてください!

そして、是非Aimingの有志メンバーの一員となり、Aiming Tech Book Vol.5 を執筆しましょう!
ご興味のある方は、是非こちらのフォームよりご連絡ください(^ ^)/

それではまたの機会にお会いしましょう!!!

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/05/560726f6eac05f8ba1089fbabeb53e3d-scaled.jpg
技術書典16参加直前ですね!(^^)/ https://developer.aiming-inc.com/activities/post-10070/ Wed, 22 May 2024 03:03:08 +0000 <![CDATA[取り組み]]> <![CDATA[イベント]]> <![CDATA[エンジニア]]> <![CDATA[技術書典]]> https://developer.aiming-inc.com/?p=10070 <![CDATA[はじめに こんにちは! 人事担当です! 以前こちらで告知した通り、 5/26(日)に実施される技術書典に今年も参加します! ■イベント概要 オフライン 会期:2024/05/26 (日) 11:00~17:00 会場:池袋・サンシャインシティ 展示ホールD(文化会館ビル2F) 参 […]]]> <![CDATA[

はじめに

こんにちは!
人事担当です!

以前こちらで告知した通り、
5/26(日)に実施される技術書典に今年も参加します!

■イベント概要
オフライン
会期:2024/05/26 (日) 11:00~17:00
会場:池袋・サンシャインシティ 展示ホールD(文化会館ビル2F)
参加:入場無料

オンライン
会期:2024/05/25 (土) 〜2024/06/09(日)
会場:技術書典オンラインマーケット

引用元:技術書典16 イベント情報

実施が直前に迫ってきました!
ブース場所や、表紙がきまったので一足先に公開します!✨

ブース場所について

今回、Aimingはゴールドスポンサーとして参加します!
場所は「協 07」で、入口すぐの場所です。
当日は是非弊社のブースに遊びに来てくださいね!

Tech Book Vol.4 表紙が完成!

以前のブログでは、社内で公募したよ!というところまでお伝えしていましたね。
公募の結果、23年新卒入社社員(HN:現象)のデザインに決まりました✨

とってもかわいいです!
昨年までの制作モチーフ「干支(辰年)」を今年も採用しており、
追加で社名の「Aim(狙いを定める)」を入れてデザインされたそうです。
また周りではじけているキャラクターは、第一事業部(Twilo)第二事業部(TeamCARAVAN)それぞれの事業部のマスコットキャラクターです。

ちなみに当日はステッカーを配布しますので、是非ゲットしてください(^ ^)/
また、第二事業部のキャラクターが登場する予定なので、もし会えたら写真もとれちゃいますよ!

執筆内容をちょこっと…!

「Aiming Tech Book」Vol.4は事前告知した通り、無料配布です!
執筆内容はこちら!

・JobSystemによる3Dシューティングゲーム
・小さなPull Requestに思いを込める
・URP12からURP14へのアップグレード
・Unity × F# でデータ指向ゲーム開発
・メイドインアクションズ
・UniMonad ー UnityでMonadを使う話

その中で今回はこちらの2つの記事の冒頭をちょこっと先に公開します✨
・JobSystemによる3Dシューティングゲーム
・URP12からURP14へのアップグレード

JobSystemによる3Dシューティングゲーム

まずは「HN:したかみ」の執筆した「JobSystemによる3Dシューティングゲーム」です。

本書の前作となる「Aiming Tech Bool Vol.3」1にて「Collider を避ける魚群シミュレーション」を執筆しました。
これはUnityのJobSystemを使用し、実用的な群れのシミュレーションを作成した内容になっています。

今回はこの魚群シミュレーションを使いまわし、群れの個体との衝突判定を実装してシューティングゲームに昇華することを目的にしています。

とのことです!
シューティングゲームの動画を撮ってもらったのでこちらで公開します!✨

URP12からURP14へのアップグレード

続いて「HN:さくたろう」の執筆した「URP12からURP14へのアップグレード」です!

対象読者:
URP12からURP14への移行を考えている方
URP14でRendererFeatureを使用する予定がある方

本文中の本当に一部ですが、スクショで公開します!

ちなみに紹介した2名は前回のTechBook vol3でも執筆しているので、
気になる方はチェックしてくださいね(^ ^)

さいごに

いかがでしたか?
表紙もかわいいですし、執筆内容もすごく面白そうですよね✨

5/26(日)池袋・サンシャインシティ 展示ホールD(文化会館ビル2F) 協 07 ブースにてお待ちしてます!
執筆者も売り子として参加する予定です、是非是非弊社ブースに遊びに来てくださいね!(^ ^)/

]]>

https://developer.aiming-inc.com/wp-content/uploads/2024/05/TechBook_vol4.png
新人研修の一環として実施したコーディング研修のスライドを公開しました https://developer.aiming-inc.com/activities/2024-coding-training-slide/ Fri, 10 May 2024 03:01:37 +0000 <![CDATA[取り組み]]> <![CDATA[エンジニア]]> <![CDATA[新人研修]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=10051 <![CDATA[こんにちは。 Aiming エンジニアの珍田です。 Aiming Twilo スタジオ(第一事業部)では、2024 年の新入社員研修を実施中です。 現在は、1ヶ月間の基礎研修を終えて、新入社員メンバーでのゲーム開発に取り組んでいます。 例年実施している本研修では、ビジネスマナー、 […]]]> <![CDATA[

こんにちは。
Aiming エンジニアの珍田です。

Aiming Twilo スタジオ(第一事業部)では、2024 年の新入社員研修を実施中です。
現在は、1ヶ月間の基礎研修を終えて、新入社員メンバーでのゲーム開発に取り組んでいます。

例年実施している本研修では、ビジネスマナー、文章の書き方等といった基礎的な研修から、Maya を使ったモデリング研修、データ分析研修、全職種が使用することになる Git/GitHub の研修といった専門的な内容に関するものなど、様々な研修を行ってきました。

私は「コーディング研修」として、エンジニアの仕事内容に焦点を当てた研修を担当しました。
ここでは、この研修で使用したスライドの紹介をします。

スライド

実施内容について

開発エンジニアとして身に着けてほしい内容をソフトウェア工学の知識、アジャイル的手法、チーム開発といった観点から説明しています。
各セッションの終わりには、Ruby を用いた実習課題に挑戦してもらいました。

※ Ruby を選択している理由は、エンジニア以外も参加する研修であり、導入や実行が簡単、比較的コードを読むのが容易、コンパイルの必要がない、インデントや括弧、空白による文法エラーが少ないという点を鑑みて選定しています。

ソフトウェア工学のトピックス

当社はオンラインゲームを手掛けており、リリース後の運用フェーズが不可欠です。追加開発も必要です。
追加開発の容易さや、リグレッションに気がつけるようなしくみといったものが必要となります。
それらのために、設計手法やパターン、テスト手法などといった武器があることを知ります。

アジャイル的手法のトピックス

ソフトウェア開発において工数見積もりやスケジューリングはエンジニアにとっても悩みの種の一つです。
開発サイクルとしてテスト手法などの開発手法を組み込みつつ、振り返りやカンバンなどを取り入れたシステム化された開発を意識します。

チーム開発のトピックス

昨今のゲーム開発はチームなしに進みません。
チームメンバー間での共通認識がなければ、上述した要素も意味をなしません。チームの一体感を高め、互いに助け合う環境を目指します。

研修を実施してみて

座学パートでは、速いペースで進めていったのですが、質問をしてもらったり理解を深めようという姿勢が見受けられました。
紹介した多くの書籍に対しても興味を持ってもらえたようで、ぜひ時間をかけて少しずつ読み進めてもらいたいと思います。

実習では、慣れない Ruby を使ってのコーディングに苦労している様子が見受けられました。
当社は Unity を使用することが多く、例年 C# 経験者が多くなります。毎年、Ruby を使用することの難しさを感じているようですが、リファレンスを参照したり、互いに教え合いながら取り組むことで、問題解決のやり方の実感を持ってもらえていると嬉しいです。

実習の最後に行ったモブプログラミングでは、意見のすり合わせに苦労したり、目指すゴールの共有ができていなかったりする場面があったりと、チーム開発の難しさを感じながらも、議論を通じてゴールに向かって進められていたようです。
今後もどんどん経験を積んでチーム開発の経験を積んでほしいと思います。

なぜこの研修を行っているのか

スライドを見ていただけるとわかると思うのですが、開発エンジニアに知っておいてもらいたい内容を表面的に提示したスライドと実習課題をセットにした内容となっています。

座学で説明を受けただけで理解して、使えるようにはなりません。
理解したつもりになることはできますが、いざやってみると何も理解していなかった、というのは経験したことのあることではないでしょうか。
かといって、限られた実習時間では、すぐに身になるものでもありません。
まずは、会社の置かれた状況や技術や手法を採用している理由を理解してもらい、実務で実感を持って徐々に深い知識を身につけていってもらいたいと思っています。
いつか、そういえばあんなこと言っていたな、と思い出してもらえる日が来ることを楽しみにしています。

このスライドが、どなたかの参考になれば幸いです。

新卒エンジニアも通年募集しています。
興味を持たれた方は、ぜひ応募をお待ちしています!

株式会社Aiming第1事業部では一緒にゲームを作る仲間を募集中です!!
中途採用 → 積極採用中です! あなたの経験をフルに活かしてください!
新卒採用 → 熱意あるみなさまを歓迎します!
詳しくは採用ページと事業部紹介ページをご覧ください!
■採用ページ
https://recruit.aiming-inc.com/career/
■事業部紹介ページ
https://recruit.aiming-inc.com/twilo/
]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/05/GMFFNCtbQAApXVD-scaled.jpeg
技術書典参16に参加します!(^^)/ https://developer.aiming-inc.com/misc/post-10007/ Mon, 11 Mar 2024 08:38:11 +0000 <![CDATA[未分類]]> <![CDATA[エンジニア]]> https://developer.aiming-inc.com/?p=10007 <![CDATA[はじめに こんにちは! 人事担当です! 5/26(日)に実施される技術書典に今年も参加するため、 去年の実施内容と今年の取組みについて書こうと思います(^^)/ 技術書典とは? 技術書典について、公式サイトにイベント趣旨が説明されているので、本文まま引用します。 技術書典とは、新 […]]]> <![CDATA[

はじめに

こんにちは!
人事担当です!

5/26(日)に実施される技術書典に今年も参加するため、
去年の実施内容と今年の取組みについて書こうと思います(^^)/

技術書典とは?

技術書典について、公式サイトにイベント趣旨が説明されているので、本文まま引用します。

技術書典とは、新しい技術に出会えるお祭りです。技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。技術書を中心として出展者はノウハウを詰め込み、来場者はこの場にしかないおもしろい技術書をさがし求める、技術に関わる人のための場として『技術書典』を開催します。

引用元:技術書典とはなんですか?

企業や一般サークル出展者を募り、参加者各々が持っている技術を書籍にして発表する場です。
Aimingも過去3回参加していて、Aiming社員が本業での仕事にかかわらず、自分の興味に基づいて書いており、Aiming社員の「好き」が詰まった一冊を販売していました。
その名もAiming Tech Book!

過去3冊については、boothにて販売していますので気になる方は是非チェックしてください!
https://aiming.booth.pm/

昨年、Aimingは4年ぶりに参加! 執筆者が売り子としても立ち、興味を持ったお客様と直接技術について話す等、有意義な時間を過ごせました(^ ^)

写真は執筆者のAiming社員2名です!

参加の目的と意義

弊社に所属しているエンジニア社員は、業務時間はもちろんのこと、業務時間外も新しい技術に触れたり、自学をしてスキルアップに励んでいる社員が多いです。
そこで、社員の業務で得た知識や興味のある技術についてアウトプットする場を会社として設けることを目的としています!

去年と今年で異なる取組みの方法

去年までは弊社の台湾スタジオに所属しているデザイナーに表紙デザインを描いてもらっていましたが、今年は東京本社所属社員内で公募することにしました!
応募多数で沢山の社員が挙手してくださり、現在ラフ作成の段階に入ってもらっているので、どんな表紙が生まれるのか今からとても楽しみです✨
決まったらいち早く弊社X(旧:Twitter)でお知らせできればと思います(^ ^)/

ちなみに過去表紙はこちら↓

このイラストの秘話として、
「Aming Tech Book vol1」と「Aming Tech Book vol3」の女性キャラには実は関連があったり、昨年は卯年ということもあり、vol3の表紙キャラはうさぎモチーフだったり…と表紙にも遊び心満載なんですよ!
今年はどんな表紙になるか楽しみですね!(^ ^)

また、昨年までは有料版として作成しましたが、今年は無料版で制作を進めています。
より多くの方に手に取っていただけると嬉しいです(^ ^)/

『Aiming Tech Book vol.4』について

今回の記事内容は現時点では下記を予定しています(予定は未定なので変更になる可能性がありますっ
・PRの書き方
・JobSystemによるシューティングゲーム
・グラフィックス周り
・GitHub Actions の知見等
・Unity + F# で関数型ゲーム開発をやってみた
・・・などなど!

どんな記事が出来上がるのか、今から楽しみです!

終わり

さてさて、Aiming有志社員が新たな「Aiming Tecg book vol4」を誠意制作中です(^ ^)/
またお届けできる情報が集まったらブログにしますので、皆様お楽しみに!

]]>
https://developer.aiming-inc.com/wp-content/uploads/2018/07/ogp-default.png
[Ruby]うるう日の午前0時から9時までに起動したプロセスでのみ再現するサーバー障害 https://developer.aiming-inc.com/ruby/leap-year-bug/ Mon, 04 Mar 2024 09:23:00 +0000 <![CDATA[Ruby]]> <![CDATA[ゲーム]]> <![CDATA[バグ]]> <![CDATA[プログラミング言語]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=9915 <![CDATA[こんにちは、サーバーサイドエンジニアの市東です。 今年の2月29日にゲームサーバーの障害が発生したため、今回はその現象と解決策について紹介します。 環境 Ruby 3.1.4 ActiveRecord 6.0.0 TZ “Asia/Tokyo” MySQL […]]]> <![CDATA[

こんにちは、サーバーサイドエンジニアの市東です。
今年の2月29日にゲームサーバーの障害が発生したため、今回はその現象と解決策について紹介します。

環境

Ruby 3.1.4
ActiveRecord 6.0.0
TZ “Asia/Tokyo”
MySQL 8系
時刻に関して、サーバーロジックはJSTで、データベースではUTCで扱っています

要約

障害の発生:
日本の時刻で2024/02/29 0時以降に、一定確率でデータベースへのINSERTが失敗するようになりました。

再現条件:
この現象は2024/02/29 0~9時 JSTに起動したプロセスでのみ再現しました。

原因:
INSERTが失敗するのは、過去の時刻が2023/02/29などの存在しない時刻になることが要因でした。その時刻が生成されるのは、Ruby3.1.4特有のバグでした。

解決策:
うるう日の9時以降に再起動すれば直ります。また、Rubyのバージョンを3.2以上にアップグレードすることで、この問題は発生しません。

将来の影響:
次に同様の日付が回ってくる2028年2月29日までには、Ruby3.1.4はサポート終了(EOL)を迎えるため、影響を受けるシステムはほとんどないと予想されます。

謝辞

この度の問題解決に至るまでには、ruby-jp Slack ワークスペースの皆様からの貴重な情報提供が不可欠でした。皆様の知識と経験に基づく支援に心から感謝申し上げます。

障害発生の状況

時刻 状況
2024/02/29 00:24 JST ActiveRecord::StatementInvalid
Mysql2::Error: Incorrect datetime value: '2023-02-29 21:10:22' for column 'created_at' at row 4
というエラーが発生し始める
発生件数は非常に少ない
2024/02/29 07:00 JST 該当のゲームタイトルはコンテンツアップデートのためオフラインになり、エラー通知が止む
2024/02/29 14:00 JST 該当のゲームタイトルのメンテナンスが終了し、オンラインになる
2024/02/29 14:03 JST 同様の Mysql2::Error: Incorrect datetime value エラーが発生し始める
発生件数は徐々に拡大する

原因調査

エラーの発生箇所の特定

このエラーIncorrect datetime valueはデータベースのdatetime columnに対して不正な値を書き込もうとしたことが原因で発生しています。通常のINSERT statementを使って、過去の時刻を書き込むことはほとんどありませんが、MySQLなどに用意されているINSERT … ON DUPLICATE KEY UPDATE statementを使って複数の行を更新するときには、過去の時間を使ったクエリが生成されます。
例えば、複数の消耗品を所持しており、1つのクエリで複数の所持数を変更するときは、下記のようになります。

// PK(user_id, item_id)
SELECT * FROM items WHERE user_id = 123;
 user_id | item_id | quantity |     created_at
---------+---------+----------+---------------------
   123   |  10001  |   2000   | 2023-02-28 21:10:22 
   123   |  10002  |   3000   | 2024-01-10 12:58:09 
//正常なINSERT statement
INSERT INTO 
 items (user_id, item_id, quantity, created_at) 
VALUES 
 (123, 10001, 2005, '2023-02-28 21:10:22'), 
 (123, 10002, 3019, '2024-01-10 12:58:09')
ON DUPLICATE KEY UPDATE 
 quantity=VALUES(quantity)

正常であれば、’2023-02-28 21:10:22’となるはずですが、’2023-02-29 21:10:22’という存在しない日付になっていることが問題になります。データベース上の値を読み込んで、書き出すときに別の値になるということは、該当のserialize/deserializeの実装に着眼すると良さそうです。あとは再現することができれば、解決に近づきます。

再現方法

ところが、手元で実行しても再現しません。より環境の近いステージングにおいて、同様のデータを用意しても全く再現しません。
困っていたところに、Rubyコミュニティの方々から、「うるう日の0~9時に実行すると再現する」という情報をいただきました。faketimeを使ったり、システム時刻を直接書き換えたりすることで、再現することができました。

$ RBENV_VERSION=3.1.4 faketime '2024-02-29 08:00:00' \
 ruby -ve "p Time.utc(2023, 2, 28, 21, 10, 22, 0)"
ruby 3.1.4p223 (...)
2023-02-29 21:10:22 UTC

手元でもステージング環境でも、確認していた時刻がすでに9時を過ぎていたため、再現しなかったことがわかります。また、該当のタイトルはメンテナンス日で、ちょうど9時前に起動したプロセスがたくさんある状態でした。メンテナンス前の0時に発生していたエラーは、何らかの要因で自動的に再起動したサーバープロセスがいたと推測できます。

短期的対処

プロセスの起動時刻に依存した挙動であることがわかったため、サーバーを再起動すれば直ることが期待できます。詳細の原因はまだ特定できていませんが、リリースされている環境で正常に動作させるために再起動を行いました。この結果、エラー通知は止み、本番環境は正常な状態に戻ったと観測できました。

原因の詳細

さて、挙動はある程度理解できましたが、いつ再発するかわかりません。もしかしたら明日の午前0時に再発するかもしれませんし、1ヶ月後に再発するかもしれません。これらの不安を払拭するためには、原因を特定する必要があります。プロセスの特定の起動時刻に依存して、時刻のserialize/deserializeの挙動が意図しない形になることを調査するためには、該当のRubyの実装を読むと良さそうです。任意の好きなエディタでデバッグすると、うるう日とそれ以外で呼び出される関数に変化があることがわかりました。これが今日の本題です。
私の場合は、エディタはJetBrains CLionを、debuggerはMacOSのためLLDBを使いました

RubyのTime.utcは、CRubyではtime_s_mkutcという関数で定義されています。

rb_define_singleton_method(rb_cTime, "utc", time_s_mkutc, -1);
// https://github.com/ruby/ruby/blob/v3_1_4/time.c#L5664

ここの実装をたどると、下記の挙動をしていることがわかります。いくつか簡略化しています

  • 1. 入力値からエポックタイムを計算する。
    • 1-1. 現在時刻を元に366日後までの未来のうるう秒情報を初期化する。
    • 1-2. 以下のいずれかが実行される:
      • 1-2-a. 未来のうるう秒がなければ、入力値に対してうるう秒なしのエポックタイムを返す。
      • 1-2-b. 未来のうるう秒があり、うるう秒が適用される最大の時刻より、入力の時刻が大きければ、入力値にうるう秒を加算したエポックタイムを返す。
      • 1-2-c. a,bでなければ、入力値にうるう秒が適用されるエポックタイムを二分探索して返す。
  • 2. エポックタイムから時刻構造体を再構築する。
    • 2-1. 現在時刻を元に366日後までの未来のうるう秒情報を初期化する。(メモ化されているため何もしない)
    • 2-2. 以下のいずれかが実行される:
      • 2-2-a. 未来のうるう秒がなければ、エポックタイムに対してうるう秒なしの時刻構造体を返す。
      • 2-2-b. 未来のうるう秒があり、うるう秒が適用される最大の時刻より、エポックタイムが大きければ、それに対してうるう秒を減算した時刻構造体を返す。
      • 2-2-c. a,bでなければ、うるう秒を考慮した時刻構造体を返す。gmtimew_noleapsecond

この未来のうるう秒情報を初期化する init_leap_second_info 実装では、最初に評価した結果をメモ化しています。ここが、うるう日の特定時刻に起動したプロセスで発生する原因となります。
また、1-1や2-2-cなどの処理では、エポックタイムからうるう秒を考慮した時刻構造体を返すgmtime_with_leapsecond関数を使用しています。この実装にはバグがあり、Ruby3.2では修正されていますが、Ruby3.1.4にはバックポートされていません。
これは、現地時刻が03/01で、UTC時刻が1日前のとき、うるう年にかかわらずUTC時刻は02/29を返すという挙動をしてしまいます。これを元に未来のうるう秒を計算すると異常値が発生し、未来のうるう秒が存在しなくても、存在する分岐の方へと流れてしまいます。

これらを組み合わせると、下記のような挙動になります。

現在時刻: 2024/02/29 0~9時 JST (2024/02/28 15~24時 UTC)
入力値: 2023/02/28 21:10:22 UTC
の場合
  • 1. 入力値からエポックタイムを計算する。
    • 1-1. 現在時刻を元に366日後までの未来のうるう秒情報を初期化する。
      • gmtime_with_leapsecondを使っているため、366日後は2025/03/01 0~9時 JST (2025/02/29 15~24時 UTC)という異常値になる
      • 未来のうるう秒情報がマイナス値になる
    • 1-2-c. 入力値にうるう秒が適用されるエポックタイムを二分探索して返す。
  • 2. エポックタイムから時刻構造体を再構築する。
    • 2-2-c. gmtime_with_leapsecondを使い、うるう秒を考慮した時刻構造体を返す。
      • [現地時刻が03/01で、UTC時刻が1日前のとき、うるう年にかかわらずUTC時刻は02/29を返す] ため、UTCで’2023-02-29 21:10:22’となってしまう

出力値: ‘2023-02-29 21:10:22’ (Timeオブジェクト)

現在時刻: 2024/02/29 9時以降 JST (2024/02/29 0時以降 UTC)
入力値: 2023/02/28 21:10:22 UTC
の場合もちろん、現在時刻は0時より前も該当します
  • 1. 入力値からエポックタイムを計算する。
    • 1-1. 現在時刻を元に366日後までの未来のうるう秒情報を初期化する。
      • gmtime_with_leapsecondを使っているが、366日後は2025/03/01 9時 JST (2025/03/01 0時 UTC)という正常値になる
      • 未来のうるう秒情報が0になる
    • 1-2-a. 未来のうるう秒がなければ、入力値に対してうるう秒なしのエポックタイムを返す。
  • 2. エポックタイムから時刻構造体を再構築する。
    • 2-2-a. 未来のうるう秒がなければ、エポックタイムに対してうるう秒なしの時刻構造体を返す。

出力値: ‘2023-02-28 21:10:22’ (Timeオブジェクト)

これが、JSTのうるう日の午前0時から9時までに起動した(正確には、Time.utcなどの呼び出しで未来のうるう秒情報を計算した)プロセスでのみ、JSTで03/01、UTCで1日前になる時間をパースすると全てUTCでは02/29になる現象の正体でした。
該当の時刻に起動したサーバーで、任意のユーザーが2023/02/28 15:00 UTCや2021/02/28 23:00 UTCなどに入手したアイテムを、消費や獲得などで複数の行を更新するときに2023/02/29 15:00 UTCや2021/02/29 23:00 UTCという無効な時刻でクエリを生成し、データベース側でエラーになります。これはアイテムなどにかかわらず、複数の行を更新する実装すべてに影響がありました。

原因は特定でき、1ヶ月先に突然再発することはないため、夜も安心して眠れそうです。

解決策

短期的対処ではサーバーをうるう日の9時以降に再起動する対応をしましたが、長期的な対処としてはRubyのバージョンを3.2にすることが推奨されます。この現象が次に再発するのは2028/02/29ですが、その頃にはRuby3.1.4はEOLを迎えているため、特に気にする必要もないでしょう。

最後に

今回の経験から、重要な教訓を得ることができました。非常にありきたりなものですが、それは使用しているプログラミング言語やライブラリのアップデートを先延ばしにしないことの重要性です。日々進化するテクノロジーの世界では、バージョンを頻繁に安定版の最新に更新することで、潜在的な問題を未然に防ぐことができます。今回発生した障害は、非常に限定的な条件下でのみ現れる珍しい現象でしたが、それだけに、貴重な学びを提供してくれました。
時刻処理は想像より複雑で、自分自身もまだ理解できていない部分があります。もし興味を持たれた方がいらっしゃれば、ぜひこの機会に直接コードを試してみて、理解を深めていただければ幸いです。

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/03/7f32aafa65cc72bf6e5f250261a2d965-e1709625678740.png
購入した技術書を紹介します https://developer.aiming-inc.com/other/introduce_new_techbook/ Mon, 22 Jan 2024 03:14:02 +0000 <![CDATA[その他]]> <![CDATA[C#]]> <![CDATA[アジャイル]]> <![CDATA[エンジニア]]> <![CDATA[プログラミング]]> <![CDATA[プログラミング言語]]> <![CDATA[書籍]]> <![CDATA[第1事業部]]> <![CDATA[設計]]> https://developer.aiming-inc.com/?p=9872 <![CDATA[こんにちは。 Aiming 第1事業部エンジニアの珍田です。 今日は先日購入した書籍を紹介します。 本を買いました。 私の所属する Aiming 第1事業部はオフィスが手狭になったことから、昨年、隣のビルに事業部ごと引っ越しました。 その際、多くの書籍を旧オフィスに残したため、新 […]]]> <![CDATA[

こんにちは。
Aiming 第1事業部エンジニアの珍田です。

今日は先日購入した書籍を紹介します。

本を買いました。

私の所属する Aiming 第1事業部はオフィスが手狭になったことから、昨年、隣のビルに事業部ごと引っ越しました。
その際、多くの書籍を旧オフィスに残したため、新しいオフィスの本棚は現在空っぽの状態です(隣のオフィスに行けば読むことはできますが)。

現在、第一事業部では週に n 日出社し、残りの (5 – n) 日は在宅勤務するというハイブリッドな勤務体制を採用しています。
コロナ禍のフルリモート時代と比較して、オフィスにいる時間が増えたため、エンジニアにとって必読の書籍を選んで購入しました。
なるべく、定番となりそうな書籍を選びました。

壁全面の大きな窓で開放感のあるオフィスです。

コーディング、コード設計

リーダブルコード

良いコードとはどんなものでしょうか。
実行処理が短いことだったり、文字数が少ないことが正義だったりと、その判断をする価値基準は現場における要件やメンバーなどによって変わるでしょう。

そんな中でも読み手に誤解させないこと、というのは大事な要素です。
price という変数に文字列が格納されていたり、 getData() というメソッドで データの更新も同時にしている、というのは良くないコードと言えるでしょう。
長大なメソッドで読み解くのに小一時間かかるようなコードも望ましくないコーディングの一例です。

私たちはチームで開発をしています。チームメンバー(あるいは将来の自分)にとって読みやすいコードであることは開発の難度を下げます。
逆に読みにくいコードが存在するプロダクトでは、コードを読み解く時間がかかったり、意図しない場所でバグを生み出したりと、遅々としてプロジェクトが先に進まなくなってしまいます。
私たちは、読み手にコードを誤読させないコードを書くスキルを身につける必要があります。

命名のような些細な点から始まり、読みやすいコードにするための具体的なテクニックまでを紹介してくれている本です。
GitHub の Pull Request のコメントがどうしても多くついてしまうという人は、読みづらいコードだからという可能性があります。
定期的にこの本を読み返してみると良いかもしれません。

=> リーダブルコード

リファクタリング(第2版)既存のコードを安全に改善する

リファクタリングの第二版です。
サンプルコードの言語が Java から Javascript になりました。個人的には Ruby 版がお気に入りなのですが、こちらは絶版のようです(何度も読みました)。
リファクタリングとはコードを綺麗にすることだ、といった認識でとどまりがちな印象を個人的には持っているのですが、どうでしょうか。
リファクタリングを、ふわっと「こっちの方が良いかな?」なんて感じでやると、あっという間に「前の方が良かったかな」とか、「もっと別の方法の方が良いかも」などと袋小路に入ってしまい、どれが相応しいコードかの基準が定まらなくなってしまいます。

この書籍ではリファクタリングのパターンを体系的にまとめています。
個別のリファクタリング手法について、なぜやるのかという「動機」から、そのリファクタリングを実施する「手順」を提示します。そして、サンプルコードを用いて手順通りに実施した「例」が示されます。
目的を持ってリファクタリングができるようになると、「自分の直感できれいにしてみました」ではなく、なぜそのリファクタリングが必要だったのかが説明できるようになるはずです。

とはいっても、リファクタリングそのものは決して敷居の高いものではありません。気軽に、そして頻繁に帽子を被り直しましょう。

=> リファクタリング(第2版)既存のコードを安全に改善する

テスト駆動開発

順番が前後しますが、リファクタリングをするにはテストが欠かせません。
リファクタリングではアプリケーションの挙動が変わってはいけません。そのためには、先にテストコードありきで、後からコードに手を入れるのが安心安全な開発です。
そもそも最初の実装から(設計段階の仕様から)テストを記述して進めていけば、仕様に沿ったソフトウェアができ上がります。

オンラインゲームは継続してアップデートがされることが前提にあります。
そうなると、一度書いたコードを二度と触らないということはほとんど起きません。
何らかの変更が、誰かの手によってされます。
テストコードを書くというのは、堅牢なアプリケーションにする側面もありますが、未来のチームメンバー(自分かも知れませんが)へのメッセージでもあります。
テストコードのないコードに変更を入れるには、(別にあるメンテされているかもわからない)仕様書を読み、コードを読んで完全に理解した気になって不安に襲われつつ実装をするようなものです。

=> テスト駆動開発

ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本

ドメイン駆動設計(DDD) は「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」という鉄板本がありますが、少々長大で難解な面があるのが難点です。

これらの本以前の入門本として、この書籍をお勧めしたいと思います。
モデリングについては扱っていませんが、DDD におけるパターンを C# のコードでわかりやすく解説しています。
まずはパターンという武器を理解し使えるようにすることで、DDD への理解を進めるために適した本だと思います。

=> ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本

Adaptive Code ~ C#実践開発手法 第2版

C# での開発経験を積んだエンジニアに一読して欲しい書籍です。
冒頭の「本書の対象読者」の項には、「本書の目的は、理論と実践の橋渡しをすることです。本書の対象読者は、デザインパターン、SOLID原則、ユニットテストとリファクタリングなどの実用的な例を求めている経験豊富なプログラマーです。」とあるように、C# での開発経験を一通り体験したあとに読むとすっと腹落ちするようなことが多いのではないかと思います。
特に、テストからリファクタリングに続く章立てや、SOLID 原則を丁寧に解説しているところ、近年の開発ではぜひ理解しておいて欲しい依存性の注入の章があることなどがおすすめポイントです。
なお、原題は “Adaptive Code: Agile coding with design patterns and SOLID principles, Second Edition” で、第1版では邦題も「C#実践開発手法~デザインパターンとSOLID原則によるアジャイルなコーディング」でした。

=> Adaptive Code ~ C#実践開発手法 第2版

ちょうぜつソフトウェア設計入門: PHPで理解するオブジェクト指向の活用

第一章がクリーンアーキテクチャから始まるという珍しい構成ですが、読み進めると納得の章立ての構成です。
全体を通して感動を覚えるような流れるような解説が進行していきます(FizzBuzz のあんな実装は始めて見ました)。
ゆるふわな表紙に対して表紙詐欺と言われるほど内容は硬派ですが、とてもわかりやすく、いろんな本を読んではみたけどいまいちピンとこなかったという人にピッタリの本だと思います。

「Adaptive Code」も「ちょうぜつ…」もアジャイルやデザインパターン、SOLID 原則、TDD、リファクタリング、DI といった、開発の現場で有益な内容を一冊で扱っており、ある意味良いとこどりな書籍となっています。
最初に読んでからトピックを別の本で深掘りすると良いかもしれません。
なお、PHP とありますが、言語の経験の有無やサーバエンジニアかどうかにかかわらず読める本です。

いずれの書籍も現場での開発プロジェクトの経験を 2, 3 件くらい積んだエンジニアに刺さるものが多いのではないかと感じます。
もし、どちらも読むのであれば、「ちょうぜつ」 ⇒ 「Adaptive Code」 の順で良むと良いかなと思います。

=> ちょうぜつソフトウェア設計入門: PHPで理解するオブジェクト指向の活用

(物理本がまだ届いていないので写真がありません)

Game Programming Patterns ソフトウェア開発の問題解決メニュー

デザインパターンは座学で知る方も多いかと思いますが、古臭い何かと思われるかも知れません(そういうものもある。)が実務でもよく使用されるものです。
外部ライブラリを使った実装をするときや、OSS のコードなどを読んでいて、HogeFactory や Observer などと命名されたクラスを目にすることもよくあるでしょう。
実装に使用するのはもちろん会話でも使われるので、代表的なパターンを押さえておくのは重要なことです。
パターンに名前がついているということは重要なことで、会話でその名前を出せばすんなり話が通じるのは良いことです。
この本では、特にゲーム開発に焦点を当てたパターンを紹介している稀な本です。

一般的なデザインパターンについては、「Java言語で学ぶデザインパターン入門」などで一通り把握しておきたいところです。

=> Game Programming Patterns ソフトウェア開発の問題解決メニュー

ネットワーク・セキュリティ

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

ネットワークセキュリティや攻撃手法とその対策などを網羅的に記した本です。
サーバエンジニアやインフラエンジニアにとって、アプリケーション実装やインフラ構成、採用しているサードパーティのアプリケーションといった対象について、攻撃され得る脆弱性がないかどうかは最大の関心ごとであると言って良いものです。
知らない攻撃手法を事前に対策することはできないので、まずは知ることが必要です。
なお、当社ではサービスのリリース前には必ず脆弱性の診断をおこないリリース可否を判断するフェーズによってセキュリティの担保をはかっています。

余談ですが「体系的に学ぶ安全なスマートフォンアプリケーションの作り方」という姉妹本を刊行していただけないかなとずっと思っています。

=> 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Google の SRE(Site Reliability Engineering)チームの面々が執筆した、より実践的な運用に関わる知見や手法をまとめた本です。
上記の「体系的に…」はアプリケーションとそのネットワーク経路上のセキュリティに焦点を当てたものですが、こちらは日々の監視や運用に焦点を当てたものです。
オンラインゲームの世界は一般的なウェブサービスに比べると、サーバへのアクセスが多いのが特徴です。
動いていて当たり前と思われるシステムを、ちゃんと動かしたままにするというのはなかなか困難なミッションです。

=> SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム

開発手法

アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法

プロジェクトやエンジニアチームのリードをするようになると、工数見積もりやスケジュール調整に時間を割くことが多くなります。
そもそも、リーダでなくとも見積もりやスケジュールからは逃れられず、チームメンバー全員が向き合わなくてはなりません。
プロジェクトを進めていく上で大切なことの一つは定期的に計画を見直すことです。アジャイルマニフェストにもあるように、変化への対応を価値とするのです。

不確実性コーンの図から始まる本書は、見積もりの不確実性を認めた上で、どのように見積もりの精度を上げていくのかをプランニングの実践的な手法を合わせて説明していきます。
表題にある通り、アジャイルの要素も含まれていますが、見積もりとタスク管理、スケジューリングについての普遍的な内容だと思います。

ここであげた本の中で、私がこれまで一番繰り返し読んだ本です。

=> アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法

アジャイルサムライ――達人開発者への道

上記「アジャイルな見積もりと計画作り」と似たテーマを扱っていますが、よりアジャイルに焦点を当てており、また、読みやすいライトなテイストで書かれています。
この本で個人的に最も重要な点の一つだと考えるのは、トレードオフスライダーだと思います。荒ぶる四天王をうまく手懐けられるようになると最高です。
エンジニアだけではなく、プロジェクトに関わる全員で同じ概念を共有して開発を進めるべきです。
また、インセプションデッキやエレベーターピッチ、やらないことリストを作る、など、PJ の途中からでもすぐにチームで実行可能なメソッドも紹介されているので、ぜひ実践してみましょう。

=> アジャイルサムライ――達人開発者への道

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

ペアプログラミングやモブプログラミングは、スキルアップやノウハウの共有など多くの面でメリットがあるプラクティスです。
当社でもペアプロやモブプロを現場で取り入れています。
ただ、朝から晩までペアプロをやると大変に疲れるので、必要な場面や定期的に実施する、などのやり方で折を見て実施しています。

本書では、長年のモブプログラミングの経験をもとに、実践的な多くのプラクティスを示してくれます。

なお、「ペアプログラミング―エンジニアとしての指南書」という書籍もあり、ペアプロの基本を教えてくれる良本です。
ケーススタディ方式で「専門家 – 専門家」ペア、「専門家 – 新人」ペア、「外向型 – 内向型」ペアなどのいくつかのケースを想定した面白い読み物があって好きだったのですが、残念ながら今は絶版になっているようで入手が難しいかも知れません。

=> モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モチベーション

最後に、エンジニアとしてモチベーションの上がるような書籍をチョイスしました。

Team Geek―Googleのギークたちはいかにしてチームを作るのか

チームにおいてリーダは役割です。チームメンバーが各々のタスクのオーナシップをもち、リーダシップを発揮して問題解決に向けて進む。
こんなチームが自己組織化された良いチームの一つと言えるのではないでしょうか。
リーダーシップにもいろいろな形があります。率先して引っ張るのが得意なタイプもいれば、サーバントリーダーシップが得意なタイプもいます。
本書ではチームがうまく行くための三本柱 HRT(謙虚、尊敬、信頼)や、アンチパターンなどの例などでメンバ一人ひとりが主体となったチームづくりの秘訣を教えてくれます。

=> Team Geek―Googleのギークたちはいかにしてチームを作るのか

世界一流エンジニアの思考法

Microsoft の Azure Functions チームに飛び込んだ牛尾剛さんの書籍です。
とにかく読んで欲しい、自分もやろう!という気にさせてくれる一冊です。

=> 世界一流エンジニアの思考法

最後に

読みたい本や読んで欲しい本、押さえておくべき教科書的な本など、まだまだたくさんあるのですが、際限がないので現在の事業部の状況に合わせた選書をしてみました。

絶賛エンジニアの採用もおこなっていますので、このラインアップを見てビビッときたエンジニアの方、応募をお待ちしております。

株式会社Aiming第1事業部では一緒にゲームを作る仲間を募集中です!!
中途採用 → 積極採用中です! あなたの経験をフルに活かしてください!
新卒採用 → 未経験者も含め、熱意あるみなさまを歓迎します!
詳しくは採用ページと事業部紹介ページをご覧ください!
■採用ページ
https://recruit.aiming-inc.com/career/
■事業部紹介ページ
https://recruit.aiming-inc.com/twilo/
]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/01/DSC00395-scaled.jpg
ざっくりUIアニメーション・エフェクト作成の話  https://developer.aiming-inc.com/design/post-9733/ Fri, 12 Jan 2024 04:27:22 +0000 <![CDATA[デザイン]]> <![CDATA[ゲーム]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=9733 <![CDATA[お疲れ様です、今回開発ブログを書くことになった第1事業部デザイナーのryamagishiと申します。初投稿です。 普段はUI関連作業諸々・アイコンイラストの制作や発注まとめを主に担当しております。 今回はUIでのアニメーション付け・エフェクトの作業内容と使用ツールについて、おおま […]]]> <![CDATA[

お疲れ様です、今回開発ブログを書くことになった第1事業部デザイナーのryamagishiと申します。初投稿です。
普段はUI関連作業諸々・アイコンイラストの制作や発注まとめを主に担当しております。
今回はUIでのアニメーション付け・エフェクトの作業内容と使用ツールについて、おおまかに記載していこうと思います。
(わりと自己流なので、こういった感じで作っている人もいる、くらいの空気感で記載してます。)

UIアニメーション・エフェクトの作業内容

まずそもそも実際何を作成しているのか?という点について、おおざっぱに分けて下記を作っています。

  • UIオブジェクトや画面の挙動
  • 画面をリッチに見せる装飾
  • 印象付けるための演出

 

(挙動・コントラストの補足説明用にモノクロGifを添付しています)

UIオブジェクトや画面の挙動

 

ボタンを押したときの反応だったり、別画面に遷移するときの一瞬の変化・ワイプなど、UI内のちょっとした挙動を指します。
ぱっと見目立たないポイントに見えますが、操作しやすさ・気持ちよさに関連するところなので大事なポイントと思っています。

画面をリッチに見せる装飾

普段とは異なる特別なUI等には、より豪華に見せたい際にアニメーション・エフェクトを付けたりします。
たとえばクリスマス時期のイベントUIで背景に雪を降らせたり、夜空の星を光らせたりetc. 基本的に静止画で構成しているUIに動きをつけて盛る作業をしています。

印象付けるための演出

バトルの開始や、何かしらの報酬を獲得した際等、プレイヤーに印象付けるための簡易アニメーション演出を作成することもあります。
こちらは仕様で表示要件が決まっていたりすることが多いので、要件から逸れないように意識しています。

これらの作成をUnity内の下記ツールで作成・実際に出力しています。

 

UIアニメーション・エフェクト作成で使用するツール

現在所属しているプロジェクトではUnityで開発しています。UIアニメーション・エフェクト関連についてはとくに自社ツール等は使っていません。

SimpleAnimation

(作成内容やPrefab状態次第ですが)8割くらいメインでこちらを使用しています。
https://github.com/Unity-Technologies/SimpleAnimation
Unity内にすでにAnimationが入ってますが、Contorollerがだいたい不要なのでこちらを採用することになりました。
Prefab内のオブジェクト位置や名称が変わるたびに参照が外れるのは既存と変わらないのでそのたび修正は必要ですが、画面比率やオブジェクトサイズの動的変化に対応できるので使いやすいです。

 

ParticleSystem

とくにカスタムすることなく、Unityにデフォルトで入っている機能そのままです。
ランダム性の高いアニメーションを作成する際にはSimpleAnimationよりこちらで作成することが多いですが、
Particleを大量に長時間発生させると負荷がかかるので、ループアニメーションの場合にはとくに発生量を減らして、不足分を他で足しています。
また、カメラ見切れやOrder in Layer値による画面貫通など細かい箇所で表示がくずれることがあるので、使用した際にはゲーム内での確認をより念入りにしています。

 

Tween

開始と終了を設定するシンプルな挙動付けツールです。
https://assetstore.unity.com/packages/tools/animation/dotween-hotween-v2-27676?locale=ja-JP
他ツールとの違いは

  • 軽い
  • (カーブ付けで少しはできるけど)細かい挙動変化はできない
  • 1回再生したら再度再生はできない ※プロジェクトで使用しているものが古いので、もしかしたら今は違うかも?

…といった感じで、細かい作業には向かないけれど、オブジェクトを動かすくらいの小さな挙動付けに適してます。
他にも、読み込み等で画像がどうしても表示されないタイミングの補完など限定的な応急処置で使ったことがあります。

自分は主に、頭の中でぼんやりシミュレーション→画面内で実際に動かすタイプなので、仮置きオブジェクトを入れたり直接触りながら、上記ツールで試行錯誤して作成しています。

まとめ

今回はUIでのアニメーション付け・エフェクトの作業内容と使用ツールについて、とてもおおまかですが記載させていただきました。
自分がこの作業をするきっかけ(?)がわりと偶然…たまたまそこに居たから担当になった感じで、最初のほうは作り方もわからずバグも連発でいろいろ苦い思い出がありました。
けれど数作っていくうちにだんだん慣れ始めると、逆にいろいろアイディアが出てくるようになってきました。最近では業務であり半分くらい趣味の作成といった感じで楽しみながら作業しています。
(こだわりすぎると作業〆がこちらを覗き始めるので、そのあたりはうまいこと進める必要はありますが…)

昨今はUIをグラフィカルに見せることはもちろん、挙動などにも個性をつけるゲームが増え、デザイナーはUIの使いやすさ以外の要素も含め「画面全体的な」クオリティの高いものを要求されているなぁ…としみじみ思います。自分も全然まだまだなので、今後とも精進していていきたい所存です。
今回の記事が、もし今までUIアニメーション・エフェクトに触ってみたいけど実態がよくわからない方や、UIデザイナーを目指す方にとってなにかしらの一助となれば幸いです。

・・・

第1事業部のUIデザイナーはたたき台・レイアウト~Unity入れ込み、UIアニメーション作成までUIのほぼすべてを作成する機会が多いので、全部自分で作りたい意欲のある方に向いた環境です。
興味がありましたらぜひ一度応募してみてください。

株式会社Aiming第1事業部では一緒にゲームを作る仲間を募集中です!!
中途採用 → 積極採用中です! あなたの経験をフルに活かしてください!
新卒採用 → 未経験者も含め、熱意あるみなさまを歓迎します!
詳しくは採用ページと事業部紹介ページをご覧ください!
■採用ページ
https://recruit.aiming-inc.com/career/
■事業部紹介ページ
https://recruit.aiming-inc.com/twilo/

]]>
https://developer.aiming-inc.com/wp-content/uploads/2024/01/Title-1.png
[Unity][C#] 非同期コールバック関数パターン https://developer.aiming-inc.com/csharp/unity-csharp-async-callback-patterns/ Fri, 05 Jan 2024 05:29:03 +0000 <![CDATA[C#]]> <![CDATA[Unity]]> <![CDATA[エンジニア]]> <![CDATA[プログラミング]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=9320 <![CDATA[こんにちは、そして、お久しぶりです。 Aiming の土井です。 今回の開発者ブログでは、コールバックを伴う非同期プログラミングのデザインについて整理していこうと思います。 非同期関数をコールバックする 早速ですが、皆さんの中で UniRx, UniTask といった非同期ライブ […]]]> <![CDATA[

こんにちは、そして、お久しぶりです。
Aiming の土井です。
今回の開発者ブログでは、コールバックを伴う非同期プログラミングのデザインについて整理していこうと思います。

非同期関数をコールバックする

早速ですが、皆さんの中で UniRx, UniTask といった非同期ライブラリを使って開発している方も多いのではないでしょうか。最近では、Unity 単体でも Task を簡単に扱えるようになっており、手続き的な非同期処理を、見通し良く書くことができるようになりました。
非同期処理の代表的なデザインとして、メッセージをコールバック関数で受けるというやり方があります。こういった設計のフレームワークやライブラリを使ったこともあるのではないでしょうか。

コールバックの例(UniRx)

...
void Start()
{
    HogeObservable.Subscribe(_ => Hoge());
}

void Hoge()
{
    // 同期処理
    Debug.Log("Synchronous");
}

UniRx だと、こんな感じですね。
ストリームになにかメッセージが流れてきたら、Subscribe() に渡されたコールバック関数が呼び出されます。
コールバック関数では Hoge() が呼び出され、コンソールに文字列が表示されます。

では、Hoge が非同期関数の場合どうなるでしょう?

非同期コールバック関数の例

...
int counter = 0;

void Start()
{
    HogeObservable.Subscribe(_ => HogeAsync());
}

async Task HogeAsync()
{
    counter++;
    await Task.Delay(1000);
    Debug.Log($"{counter}");
}

コールバック内で非同期関数を呼び出しています。await Task.Delay(1000); のところで1秒待ってから、コンソールに文字列を出力し、処理を完了します。
しかしながら…このコード、なにか臭います。
1秒以内に HogeObservable のストリームに3つのメッセージが流れてきた場合の結果を見てみましょう。

出力
3  // 1を期待していた
3  // 2を期待していた
3

非同期コールバック関数を扱う場合、このように、並行に処理されてしまうことが原因で、意図しない挙動をすることがあります。
コードをパッと見るだけでは気づきにくい、非同期処理特有の問題と言えるでしょう。

今回の開発者ブログでは、非同期コールバック関数に注目して、設計時に役立つデザインのパターンを考えていきたいと思います。

レースコンディションについて理解する

複数の処理が並行していることが原因で生じる問題をレースコンディションと言います。

先程の HogeAsync() の例では、同時に3つのコールバック呼び出しが並行し、意図せぬ結果を招いていました。まさに、レースコンディションです。
レースコンディションを回避するためには、関数の実行状態を管理・制御したり、処理の順序を見直したり…といった対策は取れるのですが、これが結構たいへんです。

レースコンディション対策のためのコードを加えていくことによって、本質的な処理とは無関係なコードが混ざってくるので、見通しが悪くなり、コードが読みにくくなっていくのが常でしょう。
同期処理では起きることのないこの問題に対して、解決策を見出して行かなければなりません。

そこで、非同期処理を設計する際の指針として、以下のようなパターンを3つ考えてみましょう。

非同期コールバック関数を扱うパターン

並列(並行)処理パターン

きっと全部うまくいく。気にしない(ドキドキ)

レースコンディションを意識しなくて良い処理。非同期処理が並行して実行されることを許容するパターンです。処理が並行に行われても大丈夫なように実装がされている必要があります。

直列処理パターン

はいはいー、順番にやるから、そこに1列に並んでね。列の後ろの方にある処理は、実行が遅れることもあるから気をつけてね

すべての非同期処理を直列化(同時に一つだけ実行するように)して、処理が並行して実行されることを防ぎ、レースコンディションを回避します。

スイッチパターン

マジ、差し込みでスマンだけど、こっちの仕事最優先でおねがい。え?さっき振った仕事?あれは、もうやんなくていいよ?気持ち切り替えていこ?

実行中の処理は止めて、最後に発生した非同期処理だけを実行し、レースコンディションを回避します。

どのパターンが適切か判断する

実装しようとしている仕様に対して、レースコンディションを回避する必要があるか否か、どのようにレースコンディションを回避するかでこれらのパターンに振り分けると良いでしょう。
次に、これらの判断基準をもう少し明確に持てるよう、具体的な実装例を踏まえて詳しく紹介していこうと思います。

Unity + シングルスレッドを想定しています。スレッド間の競合を意識しなければならないような状況では、排他制御が必要になるなど、ここで紹介するパターンでは扱いきれないため、注意が必要です。

並列(並行)処理パターンの例

非同期コールバックが並行しても問題ないと言い切れるなら、何も考えずに非同期コールバックを呼び出してしまいましょう。


HogeObservable.Subscribe(_ => HogeAsync());
async Task HogeAsync()
{
    // 非同期処理
    await Task.Delay(1000);
    Debug.Log("Asynchronous");
}
```

HogeAsync は1秒まってから、文字列をコンソールに表示するだけの関数です。コンテクストに依存せず、何度呼び出されても結果は同じですね(冪等性を持っている)。こういった冪等性を持った関数は、ほとんどの場合、並行実行しても問題ないでしょう。これを一つ判断基準として持っておくと良いでしょう。

上述のコードのような、await されない HogeAsync() 呼び出しは、警告が表示されてしまいます。また、非同期処理内で例外が発生した際に気づくことができなくなります。
そのため、以下のように、UniTask の Forget() を使いましょう。

HogeObservable.Subscribe(_ => HogeAsync().Forget());
async UniTask HogeAsync()
{
    // 非同期処理
    await Task.Delay(1000);
    Debug.Log("Asynchronous");
}

直列処理パターンの例

非同期処理を要求された順に従って、一つ一つ順番に実行します。原理的に非同期処理が並行実行されることが無いので、レースコンディションが発生することはありません。
ただし、前の処理が完了するまで後続の処理は待たされるため、実行に遅延が発生することがあります

マルチスレッドデザインパターンにおける、Producer-Consumerパターンに含まれるパターンといえます。
ここでは処理を直列化する機能をもった調整役を置き、一つ一つ順番に実行していくことでレースコンディションを回避します。

直列化するためには、非同期キューを使うのが良いでしょう。自前で開発しても良いですが、拙作の非同期タスクキューライブラリ(TaskQueue)がありますので、ここではそれを利用したコードをサンプルとして示したいと思います。

TaskQueue には他にも、キューサイズの制限や、優先度による実行順の制御など、細やかな制御を行うための機能があります。

TaskQueue を Unity Project にインストールして、非同期処理を直列化します。


TaskQueue taskQueue = new();

void Start()
{
    taskQueue.Start(destroyCancellationToken);
    HogeObservable.Subscribe(_ => taskQueue.Enqueue(HogeAsync));
}

async Task HogeAsync(CancellationToken ct)
{
    // 非同期処理
    await Task.Delay(1000, cancellationToken: ct);
    Debug.Log("Asynchronous");
}

コールバックが呼び出されるたびに、非同期関数をキューに追加していくようにします。キューに積まれたタスクは、その順番に従って一つずつ実行されていきます。

UI においては、先行入力を許容するようなケースであったり、
ゲームのロジックにおいては、非同期処理中心のコマンドパターンを扱っているなど、実行順が重要な場合は、直列パターンが最適といえます。

直列処理は、遅延が発生する可能性があるため、キビキビとした反応を要求する局面では有用では無いかもしれません。その場合は、次のスイッチパターンを適用できないか検討してみましょう。

スイッチパターンの例

実行中の処理があれば停止し最新のコールバック要求のみを処理するようにします。非同期処理呼び出しの遅延は発生しません。

一見、安全そうで使いやすいパターンに見えますが、進行中の処理を中断するということは、相応の危険があります。実行中の処理を安全に中断ができるかどうかは非同期処理の実装次第です。キャンセル処理を慎重に実装する必要があるでしょう。

実行中の処理を中断する機構を作るのは、これまた意外と大変なので、先程紹介した TaskQueue を使っていきます。

TaskQueueを使ったスイッチパターン

TaskQueue のキューサイズを制限し、キューが溢れた場合に処理を入れ替える(TaskQueueLimitType.SwapLast)指定をして、タスクスイッチングを実現します。


TaskQueue taskQueue = new TaskQueue(TaskQueueLimitType.SwapLast, maxSize: 1); // キューのサイズを1に制限し、あふれる場合は処理を入れ替えるようにする

void Start()
{
    taskQueue.Start(destroyCancellationToken);
    HogeObservable.Subscribe(_ => taskQueue.Enqueue(HogeAsync));
}

async Task HogeAsync(CancellationToken ct)
{
    // 非同期処理
    await Task.Delay(1000, cancellationToken: ct);  // キャンセルできるようにしましょう
    Debug.Log("Asynchronous");
}

ストリームにメッセージが来たタイミングで、実行中の処理はキャンセルされ、レースコンディションを防ぎつつ、メッセージに対しても即座に応答ができるようになります。

[おまけ] UniRx + UniTask の例

最後に、TaskQueue を使わないで実現する方法も考えてみます。
UniRx で受けた非同期コールバックをキャンセルするのは、意外と大変です。

UniTaskをCancellationTokenを指定しながらToObservableするメモ @toRisouPさん
これを実現するために有用なポストがあったので、まずは、この記事を参考に ObservableConverter.FromUniTask を実装してしまうのが近道です。

Observable の Dispose と連動して非同期処理をキャンセルできるようになれば、あとは、Select().Switch() でつなぐだけでスイッチパターンを実現することができるでしょう。


HogeObservable
  .Select(_ => ObservableConverter.FromUniTask(ct => HogeAsync(ct)))
  .Switch()
  .Subscribe();

async UniTask HogeAsync(CancellationToken ct)
{
    // 非同期処理
    await Task.Delay(1000, cancellationToken: ct);  // キャンセルできるようにしましょう
    Debug.Log("Asynchronous");
}

最後に

いかがでしたでしょうか?
今までこの手の非同期処理を曖昧にしていた人(私)は、コールバックをともなう非同期処理に補助線をひいて考えることができるようになったのではないでしょうか?
非同期処理は難しいとよく言われます。難しいからこそ、シンプルな記述で、流れを簡単に追えるようにしておきたいですね!

それでは、また。

]]>
https://developer.aiming-inc.com/wp-content/uploads/2023/12/20230804-P8040261.jpg
本と上手く付き合うには https://developer.aiming-inc.com/other/post-9692/ Tue, 26 Dec 2023 02:53:49 +0000 <![CDATA[その他]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=9692 <![CDATA[ソフトウェアエンジニアのyashiheiです。最近、本との付き合い方について思いを巡らせる機会が多かったので記事にしてみようと思いました。 (記事で言及してる本は技術書がメインですが、話の内容としては別に技術書に限った内容では無いかなと思います) 本の見つけ方 そもそも本ってどう […]]]> <![CDATA[

ソフトウェアエンジニアのyashiheiです。最近、本との付き合い方について思いを巡らせる機会が多かったので記事にしてみようと思いました。

(記事で言及してる本は技術書がメインですが、話の内容としては別に技術書に限った内容では無いかなと思います)

本の見つけ方

そもそも本ってどうやって見つければ良いの?という疑問が以前僕にはありました。今必要な本を引き抜くのって結構難しいと思うんですよね。あまりにも沢山の本が溢れてるから何を基準にして選べば良いか分からない。ランキング上位とか星評価高いやつからかなとか。

ただ上から選ぶみたいな選び方は好きではなかったです。多くの人が望んでいる情報が自分にとって最適とは限らないんですよね。それに常に新しいものが良い訳でも無い。日頃から指向性のあるアンテナを組み立てていく必要があるのかなと。これはコンテンツ全般に言えそうですね。

僕がやってる方法を書くと

  • 特定の人(思想が近い人、作った作品が好きな人など)の発信を追う
    • このためにRSSリーダーをまだ使っています
  • 気に入った本、ノベルゲームの引用などから芋づる的に追う
  • Kindleの購入画面後のおすすめされる本

などなど。何処かを起点にしてそこから伝っていくと広がってくイメージかなと思います。

起点となる本

例えば「プリンシプル オブ プログラミング」は様々なプログラミングに関する技術書(技術書以外にも)の入り口として最適なのではないかなと思います。様々な名著から良いエッセンスを抽出してまとめてる本なので、各項目で気になる本があれば深掘りしていけるかなと。

僕は「コンテキスト(※)」について気になったので「リファクタリング・ウェットウェア」も当時読んだのですが、これは非常にインパクトのある本で出会えて良かったと思ってます。僕は、日頃から問題解決の際にコンテキストを大切にしてるのですが、それはこのあたりの本から受けた影響もあると思います。

※コンテキスト…周りの状況や背景のこと。文脈とも言います。例えば、牛丼屋で店員さんがオーダー取るときに「牛丼並、牛丼大盛り」ではなく「並、大盛り」と呼ぶのは「牛丼」というコンテキストが十分に共有されてるからだと思います。変数の命名などにも通じるところがありますね。

本を読むタイミング

たとえば過去のプロジェクトで、前ページの脚注にあげたGoF本に出会ったばかりの開発者がいました。この開発者は興味津々で、GoFデザインパターンを使ってみたかったのです。それも全パターンを同時に、簡単なリポートを生成するだけの小規模なコードの中で。この開発者は誰かに注意されるまで、どうしようもないコードの中に、GoF本に紹介されている23パターンのうち、およそ17個を詰め込んだのでした。 (Andy Hunt著, 武舎 広幸・武舎 るみ訳, リファクタリング・ウェットウェア, 2009)

初学者がいきなり読んだら混乱してしまう本というのはあると思います。最初読んだときは全然分からなかったけど、経験を積んでから読むことでスッと入ってきたといった経験は多くの人にあるのでは無いでしょうか。

これ怖いなあと思うのが、やはり本に書かれてることってコンテキストに左右されるとは思ってて、初学者にはこの分別が出来ないところですね。自分よりずっと経験ある著名な人が書いてるものだから何でも信じてしまう。なので「レシピ」として扱ってしまい時には大事故を起こしてしまう。結構ありがちですよね。

輪読会の良いところ

上記のことを考えると、輪読会はとても良いですね。本をより多面的に読むことが出来ます。一人で読むと気づけなかったことや、誤解してしまったことも、よりベテランの視点だったり専門が違う人々の視点を通じて、新たな発見をすることが出来ます。

これに似たような経験として、ソーシャルゲームのストーリーを自分で読んだあと、推しの配信で見たときに推しが全然違うところに着目してることに驚いたことがあります。

シミュレーションとして

本は色んな状況をシミュレーション出来る強みがあると思います。人生で経験出来ることには限りがありますが、本を読んで色んなケースを蓄えておくことで、いざというとき判断材料を増やせます。実際の経験には敵わないですが…。

本は読んだ方が良いのか

僕は座学がかなり苦手です。ただそれでも本は好きで読書の習慣はある方なのですが、それは能動的に、現実逃避か興味本位で読むことが多いからなのだと思います。

だから宿題っぽく本を押し付けるのはあまりやりたくないな~って思ってしまいます。良い本だと分かってても、その本を読む準備が自分に出来てただけで、相手にも出来てるとは限らないからです(なので、ケースバイケースですが、新卒に本をいっぱい押し付けるのもどうかなと)

学校の勉強とかが身につかなかったのも(高専のクラス内成績順で48人中46位とかになった記憶があります)やはり知識に対して能動的じゃなかったところが大きいのかなと振り返ってみて思います。今ではゲーム制作を通じて、他のことにも興味持てるようにはなったのですが、当時は好きなプログラミング以外が壊滅的でした。

難しいですね。如何に素晴らしい本があったところで、受け取る準備が出来てないと知識は身につかないのです。

身近な興味があるところから踏み込んで行くのが良いと思います。例えば、僕はアウトゲームに関わることも多いのでGUIをよく研究してるのですが、あるゲームに使われてるフォントが気になって調べたところ、ロダンNTLGであることが分かりました。そこからニタラゴの秘密を知る→そういえばこのフォント、ゲームや街中で結構見かけるなと気付く→フォントの歴史が気になってDTP以前の写植時代の書体についても知る(ゴナ、ナールなど)→欧文フォントのことが気になって「となりのヘルベチカ」を読む→日本語組版に関する連載を読む…、といった感じで繋がっていった経験があります。

本と上手く付き合いたい

とりとめなく書いたので特にまとめることは無いのですが、本と上手く付き合いたいですね。という内容でした。雑談だったりtimesで喋ったことをこうやってアウトプット出来たので良かったです。

]]>
https://developer.aiming-inc.com/wp-content/uploads/2018/07/ogp-default.png
新卒クソゲーコンテスト ~エンジニア・運営編~ https://developer.aiming-inc.com/programming/post-9480/ Wed, 13 Dec 2023 01:48:09 +0000 <![CDATA[プログラミング]]> <![CDATA[ゲーム]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=9480 <![CDATA[今回は、2023年度新卒メンバー数人で社内のクソゲーコンテストに参加した際に作ったゲームについてお話しします。 このブログはエンジニア2名と運営1名の計3名でお届けします。少し長めになっていますが、ぜひ最後までお読み頂けましたら幸いです! 今回作ったゲームについて TPSのローグ […]]]> <![CDATA[

今回は、2023年度新卒メンバー数人で社内のクソゲーコンテストに参加した際に作ったゲームについてお話しします。

このブログはエンジニア2名と運営1名の計3名でお届けします。少し長めになっていますが、ぜひ最後までお読み頂けましたら幸いです!

今回作ったゲームについて

TPSのローグライトなゲームです。
魔法とその魔法の性質を変えるエンチャントを集めつつ、オリジナルの魔法を構築し、ダンジョンの踏破と魔法の収集を目指します。

プレイ動画


見ての通りゲームは未完成です!
魔法に対してエンチャントを装備し、魔法を強化していく過程を簡単に収めたプレイ動画です。

インゲーム実装編

第一事業部でサーバーエンジニアをしている堀江です。
今回は、魔法とエンチャントに関する実装の一部についてお話しします。
Unity/C#に関しては独学で得た知識がほとんどのため、暖かい目で見てくれると助かります。

魔法・エンチャントを作る

このゲームのメインの遊びである、魔法とエンチャントの組み合わせによる魔法の性質の変化の実装について紹介したいと思います。

作りたいもの

このゲームでは魔法を駆使して敵を倒しつつ奥へと進んでいきます。
そして、魔法に装備できるエンチャントがあります。魔法の性質に変化を与えるものです。
ダメージ量や速度などのパラメータを変化させたり、着弾時に爆発を発生させるようにしたりなど、様々です。

大まかな設計

魔法が自身に装備されているエンチャントの配列を持ち、魔法の発動時に魔法が持つエンチャントのEnchantメソッドに、魔法クラスが持つSpellStatusを渡しエンチャントを実行します。

Enchantメソッドは加工したSpellStatusを返り値として返します。魔法の速度の変更など、魔法のパラメータを変えるようなものはこの時点で効果が反映されます。

その後、発動時/発動中/何かにぶつかったタイミングで、エンチャントによって魔法に登録されたアクションが発動するようになっています。

反省点

いきなりですが、このゲームでは反省すべき実装が多く生まれてしまいました。
1つ1つ挙げてもキリがないため、どうしてそうなったのか?という話をしたいと思います。

実装イメージが固まっていない

実装を進めていく上で、実装イメージを固めてから実装するということをしていませんでした。
実際にコードを書いてみて、修正が必要そうだったら都度修正するといった感じです。
拡張性のない実装が生まれるのもそうですが、根本的な部分を後から変更したくなることが出てきます。

そうして自分で自分を苦しめた結果、1つのクラスに複雑な役割を持たせることになり、クソコードが生まれていきました。
仕様に対して、懸念点などないか検討し、実装イメージを沸かせてから手を動かすことが大事です。

色々やろうとし過ぎた

今回は多くのライブラリや試してみたかった実装パターンなどにチャレンジしてみました。
結果としては、多くのことが中途半端になってしまいました。
自分の経験の浅さもありますが、どれだけ時間を費やせるかをあまり考えれていなかった部分もあります。

作るゲームの規模を考え、与えられた時間を考え、学習コストを踏まえ、今回のゲームは何が重要で、どこを頑張るかということをしっかりと考えておくべきでした。
そうすることによって、後々自分が苦しまずに済んだかも…?

UI実装編

第一事業部、クライアントエンジニアの鈴木です。
今回のクソゲーコンテストでは主にUIの実装を担当しました。
制作を通して頑張ったことや感じたことを書かせていただきます。

UniRxを使った実装

UIの実装では、私が所属しているプロジェクトでも使われているUniRxというライブラリを活用しました。
UniRxは今まであまり使ったことがなく、実際に私が所属しているプロジェクトで触ることが多いので、勉強する良い機会だと思いました。

エンチャント交換画面

ほぼ全てのUIでUniRxを使っていますが、特に多用したエンチャント交換画面を紹介します。
主な流れは、敵がドロップしたエンチャントに触れると発火するObservableを購読し、流れてきたエンチャントのモデルクラスを基に新しいエンチャントをUIに反映させます。
後は好きなスロットをクリックすることで取得したエンチャントがプレイヤーに反映されて、UIも更新されます。

コードリーディング

今回のチームはエンジニアが2人なので、必然的に堀江君が書いたコードを読みながら実装することになります。
エンチャントの取得やプレイヤー周りの処理は堀江君が作ってくれていたので、それをもとにエンチャントやステータスなどをUIに反映する必要がありました。
コードは人によって特徴があるので、自分だったらこうするけどこんなやり方もあるんだな~と勉強になることが多かったです。
業務でもコードを読む力は非常に重要なので、これからはもっとコードを読む習慣をつけていきたいと思いました。

ゲームを完成させよう編

第一事業部、運営の島です。
今回のクソゲーコンテストではスケジュール進行と成果物のレビューとゲームタイトル命名を担当しました。
このゲーム制作で特に感じた「ゲームを完成させる」について書かせていただきます。

誰がゲームを完成させるのか

コンテストに制作物を提出して発表するということは、もちろん締め切りというものがあります。
締め切りまでにゲームを完成させなければなりません。
ここで問題となったのはどの程度のクオリティを「完成」とするかです。
今回の制作ですと、ゲーム全体の仕様が固まらないまま完成させようとしていたのです。
風呂敷は大きく広げて、「あれもこれも実装したい!」に対して「いいね!」だけの会議が行われていました。
誰かがコンテンツを削る役になれていれば短期間でスムーズに仕様書を決めれて、そのあとのスケジュールも上手くいっていたかもしれません。
ですが、なかなか人の案に対して「ダメ」とは言いにくかったです。
自分がヘイトを受けつつも、ゲームを完成させる責任をとれるようになりたいですね。

責任をとれる楽しさ

とはいっても、責任を取ることは正直やりたくないし、失敗したとき誰かのせいにしたいと思います。
自分もミーティングで物事を決定することを避けていました。
この仕様で行くぞ!って決めて実際ゲームを作って面白くなかったら自分のせいになっちゃいますからね。
でも、逆に言えば責任さえとればゲームの方向性を自分の一存で決められるってことです。(一存はかなり大げさですが)
責任をとれる立場に今いるかは置いておいて、自分好みのゲームをメンバーの手を借りて作れるのは楽しいことですよね。

メンバーのモチベーション

それじゃあ自分の独断でメンバーにあれやってこれやってとなると、なんか嫌な奴ですよね。周りからのヘイトも溜まります。
周りの意見を聞く気が無いならミーティングする意味も無くなります。
一人ひとり大なり小なり作りたいゲーム像があるのでそこをしっかり聞いてあげましょう。
今回のゲーム制作では「聞きすぎた」ところが問題でした。
メンバー間の亀裂を生まないように、全員の提案を聞きながら折衷案を導き出して、結果ふわっとした仕様書が完成しました。
そしてふわっとしたゲームが完成してしまったわけです。

結局どうしたらよかったの?

ここまで失敗談をつらつらと書いていますが、結局どうしたらよかったのか。
簡単な解決方法は実績がある人が責任を取ることだと思っています。
「すごく面白いゲームを作った人」が、周りの意見を聞きながら物事を決定してくれるのであれば信頼できます。
ですが、今回の制作では「すごく面白いゲームを作った人」が見当たりませんでした。
となると「締め切りを意識」して、「責任を取ることを恐れず」、「周りの意見も聞き」、「進むべき方向に舵をとれる」人間になれればうまくいっていたかもしれません。
なんか文字に書き出すと大仰な感じがしますが、実際やってみるとやりがいがあるかもしれません。
いつか舵をとれる人間になって、さらに先で「すごく面白いゲームを作った人」になってみたいですね。

まとめ

メンバーそれぞれが今回のゲーム制作を通して感じたことをまとめたいと思います。
堀江

基本的にあまり考えずに手を動かして、後から後悔することが多かった気がします。
クソゲーコンテストを通してクソゲーの作り方を学びました。
例え少人数での開発であったとしても、ある程度計画性を持って取り組むことは求められそうです。
反省の多い作品になってしまいましたが、その分良い経験にもなったと感じています。

また、技術的な話などは関係なしに、チームでゲームを作るということ自体が楽しかったです。
次回も機会があれば、ちゃんと完成するようなゲームを作りたいと思います。

鈴木

あまり作業時間が取れず、全体的に動くことを優先して綺麗なコードを書くことができなかったのが心残りです。
ですが、学んだことも多く何より楽しくゲーム制作ができたので良かったです。
他の方たちが作ったゲームを見ることもできて、良い刺激になりました。
次回も開催されたら参加しようと思っているので、今よりもっと技術を身に着けて面白いゲームを作りたいです。

もっと独裁者になればよかった、、、

最後に

ここまで記事を読んで頂きありがとうございました!
例え少人数での開発であったとしても、メンバー間でのコミュニケーションや目標意識の共有はとても大切だということが分かりました。

株式会社Aiming第1事業部では一緒にゲームを作る仲間を募集中です!!
中途採用 → 積極採用中です! あなたの経験をフルに活かしてください!
新卒採用 → 未経験者も含め、熱意あるみなさまを歓迎します!
詳しくは採用ページと事業部紹介ページをご覧ください!
■採用ページ
https://recruit.aiming-inc.com/career/
■事業部紹介ページ
https://recruit.aiming-inc.com/twilo/
]]>
https://developer.aiming-inc.com/wp-content/uploads/2023/12/a9513c4f15644eeeb4d9f4b164548389.png
新卒クソゲーコンテスト~デザイナー編~ https://developer.aiming-inc.com/design/post-9424/ Thu, 07 Dec 2023 04:05:04 +0000 <![CDATA[デザイン]]> <![CDATA[ゲーム]]> <![CDATA[第1事業部]]> https://developer.aiming-inc.com/?p=9424 <![CDATA[今回は、2023年度新卒メンバー数人で社内のクソゲーコンテストに参加した際に作ったゲームについてお話しします。 このブログは3Dデザイン担当と2D/UIデザイン担当のデザイナー2名でお届けしますので、少し長めになっていますが、ぜひ最後までお読み頂けましたら幸いです! [outli […]]]> <![CDATA[

今回は、2023年度新卒メンバー数人で社内のクソゲーコンテストに参加した際に作ったゲームについてお話しします。

このブログは3Dデザイン担当と2D/UIデザイン担当のデザイナー2名でお届けしますので、少し長めになっていますが、ぜひ最後までお読み頂けましたら幸いです!

[outline]

3Dデザイン編

はじめまして、第1事業部で3D制作をしているカイです。
社内ゲーム制作コンテストに参加しており、キャラデザインと3D制作を担当しました。
今回はどういう考え方でキャラクターデザインをしているのかについて書かせていただこうと思います。

んなゲームですか?

テーマは「ひらく」ですが、明確な要件がないため、自由と同時に迷子になることも(笑)
簡単な会議を数回行った後、ゲームの制作方向を決定しました。

・三人称視点3Dゲーム
・ローグライクな要素を持つ
・冒険ゲーム
・ファンタジー的な世界観

ャラクターのデザインと制作について

デザインについて

利用可能な時間が少ないので、詳細な企画書は作成せず、それぞれの得意な方法で制作しました。

主人公:かわいいドラゴン獣人

BOSS:巨大なドラゴン生物

なぜドラゴンなのか?

個人の興味が一部分で、ドラゴン自体は多くの動物の特徴を持っているため、高い自由度のランダムデザインに適しています。

使用したツールは?

主にBlenderとSubstance Painterを使用しました。

特に強調したいポイントは?

小さなキャラクターが大きなモンスターに挑む姿には特有の迫力があると思っているので、二人の体格の違いを特に大きく設定しました。
主人公の方は、彼の明るくかわいい特性を強調したく、
基本の色としてシトラスの酸っぱい色を主色として選び、
服はダークカラーを主として、キャラクターに少しクールで落ち着いた感じを持たせました。
全体的には少しカートゥーン調です。PBRのテクスチャの使用も、衣服の質感や金属の表現に限定されています。

BOSSの巨大なドラゴンとしては、体型の巨大さを強調するだけでなく、彼がさらに圧迫感を持つことを望みました。
そのため、石のような低彩度の白と紫を基盤として選び、宗教的なリチュアルの感じを持つ多くのデザインを作成しました。

しかし、デザインには故意にいくつかの鋭い部分を追加して、複雑な曲線のデザインがもたらす視覚疲労をバランスさせました。
結果的に、彼はガンダムのような巨大なロボットの雰囲気を持っているが、生物的な感じも持っていると感じます。
これらの詳細を強調するために、彼の表現をもっと立体的で写実的にすることにしました。身体の異なる部分の質感を表現するために、より多くのPBRテクスチャを使用しました。

Unityにセットアップ

ゲーム内でキャラクターがより良い表現を出すため、制作時に物理効果を実現するための多くのボーンをキャラクターにバインドしました。

そのため、キャラクターが移動する際、より生き生きとしたディテールが表現できます。

ザインの過程で印象的だった部分は何ですか?

最初は小さなドラゴンがどのような冒険者であるか定まっていませんでしたが、途中で私たちのプランナーの島さんが魔法の瓶のような要素を装飾として追加することを希望したため、キャラクターは魔法の騎士(?)として決定しました。

3D製作の過程での心得は?

1.髪の毛は自動ボーンバインドツールが欲しい

2.透明度設定は慎重に

3.レンダリングスタイルは一貫性をもつ

1については、今回の髪の毛は主にカーブで制作しました。髪の毛のボーンバインドには多くの時間がかかったので、将来は髪の毛のボーンバインドを自動で行うプラグインを開発できることを望んでいます。
そして2は、透明度があるマテリアルボールはUnity内で表示の競合が生じる可能性があり、慎重な設定が必要です。
最後に3は、主人公とBOSSのレンダリングスタイルは一貫性を持っていませんでした。今後の制作で、もっと一貫性を考慮する必要があるかもしれません。

UIデザイン編

はじめまして、第一事業部 UIデザイナーのナイトウです。

社内ゲーム制作コンテストに新卒チームで参加しており、2D/UIの制作を担当しました。
私からは「UIデザインが出来上がるまでの流れ」について簡単に書かせていただこうと思います!

使用したツールは?
UI作業はすべてphotoshop、アイコン作業はIllustratorを使用しています。

画面遷移の作成

初期段階のファンタジー感強めの画面遷移図

まずは仕様書を確認しながらモノクロで大雑把に下書きした後、現段階でイメージするUIのデザインをのせた画面遷移図を作成しました。
最初に決定した世界観が「ファンタジー」だったのでファンタジー感強めのデザインで最初は作成していましたが、3D担当のカイ君が作成してくれた主人公がかわいらしく、服装がスタイリッシュな雰囲気だったので、それに合わせてUIデザインの方向性を調整。

主人公の服飾やカラーリングを参考に、ゲーム画面とキャラクターがなじむようなUIを意識して制作をすすめました。

 

デザインの確定

魔法カードのデザインを複数考え、メンバーにアンケートをとったりアドバイスをもらいつつデザインを固める作業を続行。

右と左のデザインの投票率が高かったので、両方の要素を組み合わせてカードのデザインをブラッシュアップしたところ、キャラクターの雰囲気と、作品のファンタジーな雰囲気、どちらにも合うものができあがりました。

このカードの完成をきっかけに、デザインの方向性が固まりどんどん制作が進んでいきます!

ブラッシュアップ後のカードデザイン

統一感は大事!

 

トーン&マナーがある程度決まった段階でインベントリ画面を作っていましたが、いざ清書をすると、全体(画面遷移)で見たときに印象的なUIである魔法カードやキャラクターとの親和性がない画面になっていることに気づきました。

先ほどのカードデザインからUI全体の色合いを考えなおすことにし、グラデーション+紺色の枠が「EncatalMl」(このゲームのタイトル)らしくなるUIの重要な要素だと気づいたため、それらを用いて作り直したところ一気に統一感がでてオリジナリティのあるデザインになりました!

あとは、UIのサイズ調整、仕様やモーションのことを考えて画像とボタン部分を別々に書き出し、組み込みと実装をエンジニアさんにお願いすることになります。

最後に

カイ

このゲームの制作に参加することで、多くのことを学ぶことができました。
好きなキャラクターを制作するだけでなく、同期の新卒メンバーとのコミュニケーションや理解も深めることができました。

ナイトウ

私はゲーム開発自体が初めてだったのですが、今回のゲーム開発を通して特にコミュニケーションをとることの重要さを実感しました。
一人だとなかなかモチベーションが続かずグダグダしてしまうことがありますが、毎週のチームミーティングでメンバーと話す機会があったことでモチベーションを維持してゲーム制作に取り組めました。

0からの制作であったため、私は最初のデザイン案出しにかなり悩んでいましたが、チームメンバーに「作ることを楽しんだらいいよ!ナイトウさんなりのペースとアイデアでいこう!」と言ってもらえたことで次第に自信をもって自由にアイデアが出せるようになり、結果それぞれの得意分野や個性を感じられる新しいゲームを作ることができました。

今回のゲーム開発の経験を糧に、より良いゲームを作っていけるようこれからも精進していきます!

 

ここまで読んでいただき、ありがとうございます~またの機会にお会いしましょう!

株式会社Aiming第1事業部では一緒にゲームを作る仲間を募集中です!!
中途採用 → 積極採用中です! あなたの経験をフルに活かしてください!
新卒採用 → 未経験者も含め、熱意あるみなさまを歓迎します!
詳しくは採用ページと事業部紹介ページをご覧ください!
■採用ページ
https://recruit.aiming-inc.com/career/
■事業部紹介ページ
https://recruit.aiming-inc.com/twilo/
]]>
https://developer.aiming-inc.com/wp-content/uploads/2023/11/9589ac39621efcb2d329a4ce3360bd3e.png
HAL3校から総勢12名が集結! インターンシップの記録 https://developer.aiming-inc.com/internship/post-9545/ Wed, 29 Nov 2023 07:57:45 +0000 <![CDATA[インターン]]> https://developer.aiming-inc.com/?p=9545 <![CDATA[はじめに こんにちは! 株式会社Aiming採用担当です。 今年も専門学校HAL生とのインターンシップを実施したのでブログを書こうと思います! インターンシップ概要 今年はHAL3校(東京/名古屋/大阪)から総勢12名の学生様にお越しいただき、 第一事業部ではチーム制作でゲームを […]]]> <![CDATA[

はじめに

こんにちは!
株式会社Aiming採用担当です。
今年も専門学校HAL生とのインターンシップを実施したのでブログを書こうと思います!

インターンシップ概要

今年はHAL3校(東京/名古屋/大阪)から総勢12名の学生様にお越しいただき、
第一事業部ではチーム制作でゲームを完成させるという目的で、
第二事業部では企業での就業体験という目的でインターンを実施しました!
実施期間は10月の1か月間です。

Aimingのインターンでは、各職種にメンターがつきます!
学生様の不明点や疑問点はメンターがフォローをしながら、インターンを進めていきます。

実施内容

第一事業部

カジュアルゲームを1か月で作成していただきました!
そのゲームについて紹介します!

タイトル名:【NEO’n】
ジャンル:ハイスピードランゲーム
コンセプト:最高速度で走り抜け
ゲーム内容:障害物や敵の攻撃を避けながらゴールまでの時間を競う

遊び方はとってもシンプルです!
横移動やジャンプで障害物や敵の攻撃を避けて、スピードを落とさないようにゴールを目指し、ゴールまでのタイムを競い合うゲームです。
障害物や敵の攻撃に当たってしまうとスピードダウンしてしまいますが、
タイミングよく避けることでスピードアップします!
だんだんとスピードが上がっていく爽快感が凄く、「次はゴールまでのタイムをもっと縮めたい!」とやり込みたくなるゲームでした!

第二事業部

現在Aimingにて開発中のタイトルのチームへ実際にアサインし、ゲーム開発の流れや進め方、定例MTGへの出席等、実際の開発現場に近い形での就業体験をしていただきました!


作業としては主に
・実際に開発中のゲームの規格に合わせた3Dモデルの作成
・開発中のモデルにモーションを付与
・アドベンチャーパート(ADVパート)の作成
を担当していただきました。

3Dモデルの作成では、ポリゴン数やテクスチャ解像度に制限がある中、
ポリゴン数の制限に収まるように不要なポリゴンを削除したり、厚みのバランスを調整したりと試行錯誤しながら作成をしていました!

モーションの付与では、開発中のモデルの待機アニメーションを作成したり、武器と盾を持たせて戦闘モーションを作成したりしました!体の動きはもちろん、カメラワークや髪の揺れなど細部までこだわりをもって調整をして作成していました!

また、アドベンチャーパートの作成も経験していただきました!アドベンチャーパートとは、シナリオに沿ってテキストとともにキャラクターのイラストやモデルを動かしたり、ボイスを再生したりして、シナリオに没入感を与える大事な要素です。
キャラクターの表情やポーズ、カットシーンなどフィードバックをもとに試行錯誤を重ねながらブラッシュアップを行っていました!

最終発表

今年もたくさんの社員に発表の様子を見ていただけるように、Google Meetでのオンライン配信も実施しました!

最終発表では、インターンシップ期間中に学んだことや実施したこと、最終成果物の発表をしていただきました!
Aiming社員からのフィードバックやアドバイスを踏まえて、改善したポイントなどを分かりやすく発表いただきました。

▼第一事業部参加メンバー最終発表の様子


▼第二事業部参加メンバー最終発表の様子


振り返りKPTの実施

最終発表終了後は、学生とメンターで1か月間のインターンシップを振り返るため、KPTを実施しました!Keep(できたこと/継続すること)・Problem(改善するべきところ)・Try(挑戦したいこと)を洗い出し、今回のインターンシップを通じて学んだことや反省するべきところを振り返りました!
今後の成長につながればと思います。

総評

東京校・名古屋校・大阪校と3校合同での実施であったため、初対面の方ばかりの環境だったと思うのですが、皆さん初対面とは思えないくらいとても仲が良く・楽しそうに開発している姿が印象的でした!

メンターを含めAiming社員からのフィードバックやアドバイスをもとに、試行錯誤しながらみんなで協力しながら成果物を作っていく、という姿は素晴らしいものだったと思います!

1か月間という短い時間ではありましたが、今回のインターンシップがご参加いただいた学生の皆様にとって有意義な時間になっていれば幸いです。
一か月間お疲れ様でした!(^ ^)/

]]>
https://developer.aiming-inc.com/wp-content/uploads/2018/07/ogp-default.png
帰ってきた!第8回クソゲー開発コンテスト!(^ ^)/ https://developer.aiming-inc.com/activities/post-9338/ Tue, 31 Oct 2023 02:39:16 +0000 <![CDATA[取り組み]]> https://developer.aiming-inc.com/?p=9338 <![CDATA[はじめに こんにちは!クソゲー開発コンテスト運営担当です! 約4年ぶりにクソゲー開発コンテストを実施したため、ブログに書こうと思います✨ イベント紹介 クソゲーコンテストとは、 皆で個人的に小さいゲームを作って気軽に発表できる場所という趣旨のもと開催されているイベントです。 イベ […]]]> <![CDATA[

はじめに

こんにちは!クソゲー開発コンテスト運営担当です!
約4年ぶりにクソゲー開発コンテストを実施したため、ブログに書こうと思います✨

イベント紹介

クソゲーコンテストとは、
皆で個人的に小さいゲームを作って気軽に発表できる場所という趣旨のもと開催されているイベントです。

イベント概要
・イベント名:第8回 クソゲー開発コンテスト2023
・参加条件:Aiming 関係者であること(社外の人もOK)
・開発人数:個人、チームどちらでもOK
・テーマ:「ひらく」
・発表日:10月13日(金) 20:10~ 22:00

※テーマについて
クソゲーコンテストは毎年、ゲームを作る上でテーマを決めていますが、
必ずしもお題に沿って作成する必要はありません

イベントの目的と意義

「クソゲーコンテスト」という名称は、
エンジニア以外の人でも気軽に参加できるようにハードルを下げる狙いがあり、あえてこの名前にしています。

普段のタスクでは使う技術が固定化しがちなため、新しい技術に触れる機会がなかなかありません。
そのため、Aimingではこのようなイベントを定期的に行うことで、皆が普段使ってない技術に触れる機会を積極的に作るようにしています!

イベントの運営について

4年ぶりの開催ということもあり、できるだけ多くの社員に参加してもらえるように運営チームで考え、過去実施していない下記の取組みを追加しました!

非開発者が気軽に参加できるようにする

いろんな職種の方に参加してもらえるように、今回は思い切ってコンテスト部門を「エンジニア部門」「非エンジニア部門」の2つに分けてみました!
結果、それぞれの参加者は下記の通りでした!

エンジニア部門 参加数(チーム含む)7組
非エンジニア部門 参加数(チーム含む)3組

非エンジニアの参加を見込みたく
コンテスト部門を分けて実施した結果、非エンジニアの参加が過去最多だったので大成功の施策だったと思います✨
次回開催の際も、非エンジニアが参加しやすいような環境を作ろうと思います。

進捗共有兼相談チャンネルの作成

エンジニア、非エンジニア関係なく、クソゲー開発をするにあたり気軽に相談できるチャンネルをSlack上に開設しました(^ ^)/

(非エンジニアが質問してコンテスト出場はしていないエンジニアが回答している図です)

ゲームを作ったことがない人でも作れるように社内wikiを作成

今回運営メンバーとして、エンジニアの方に入ってもらい、unityのダウンロードの仕方や、
使いやすいアセットの紹介等を社内wikiにまとめ共有しました!(^ ^)
これさえあればunity触れる!という部分まで作り込んでもらったので、次回開催時もそのまま使えるクオリティです✨
実際に私は、非エンジニア部門に採用チームの一員として参加したのですが、このマニュアルに何度も助けられました。

賞と景品の作成

過去実施のときは、賞や景品が決まっておらず、その場に居合わせた役員や、エンジニアマネージャーの自費で景品等が渡されていましたが、
今回は部門によってそれぞれ賞と景品を用意しましたよ✨

非エンジニア部門
・椎葉賞 ゲーム機&ゲームソフト
・田村賞 食器洗い乾燥機

エンジニア部門
・椎葉賞 ゲーム機&ゲームソフト
・田村賞 食器洗い乾燥機
・エンジニアマネージャー賞(堀井) 電動歯ブラシ
・エンジニアマネージャー賞(鈴木) 電動歯ブラシ

また景品をすでに持っている方や、チームが受賞したことを考えて「3万円分のお食事券」へ変更できるように決めました!

審査員の設置

社内イベントのコンテストとして実施するため、今回は事前に審査員を決めました!
代表の椎葉はもちろん、非開発部署部長兼役員の田村、エンジニアマネージャーの鈴木と堀井が審査員となり、発表者のクソゲーをしっかり吟味しました笑

リアルだけでなく配信も実施

Aimingでは、東京本社だけでなく、東京分室や熊本オフィス等、オフィス間に距離があります。
本社からのリアル参加ができない社員向けに、初めての試みとしてオンライン開催を実施しました!

結果、リアル参加は60名以上、オンライン参加は最大60名程度の参加で大多数のスタッフが参加してくれました✨

受賞作品の紹介

受賞作品について掲載許可のとれた作品をいくつか紹介します!


非エンジニア部門
椎葉賞:第二事業部所属運営のKさん

ゲームがスタートした瞬間の画面です!これ以上はネタバレになってしまうという衝撃…!どう操作したらいいのかすら分からないゲームでした。

Kさんからゲームの説明をもらったのですが…
・某有名OSのシンプルなUIをしっちゃかめっちゃかにしたい衝動から生まれた謎解きゲーム
・ゲームプレイにあたってユーザーが感じるクソゲー感は大体UIからなことに着目し、「無駄に目立ち」「視認性が悪く」「直感的に分かり辛い」をテーマに考えてみた

とのことで、ユーザーに長く遊んでもらうための施策を日々考えている運営担当ならではだな…と思いました。

エンジニア部門
椎葉賞:第一事業部のエンジニアTさん


スクショでは全然面白さをお伝えできないのですが、
直線コースを走り、配置された壁をスクワットで持ち上げるVRゲームです!

走るときはプレイヤーが全力でコントローラーを振り、有酸素運動をします。
正面にUIを配置し、プレイヤーに注視させることで、正しいスクワットを促すことができるVRならではの面白さがあります。

発表中のシュールな動きも込みでクソゲーという判定で、見事、椎葉賞を受賞されていました!✨

エンジニアマネージャー賞(堀井)
第一事業部所属デザイナーMさん

かわいいクマのすごろくゲームです!
詳細はあまり書けないのですが、完成後にリリースする予定とのことなので、是非興味を持った方は遊んでみてください!

エンジニアマネージャー賞(鈴木):23年新卒5人組チームが受賞!
今年入社の第一事業部配属5人組の合作

TPSのローグライトゲーム!
魔法とその魔法の性質を変えるエンチャントを集めつつオリジナルの魔法を構築し、ダンジョンの踏破と魔法の収集を目指すゲームです!
エンジニア2名、プランナー1名、デザイナー2名のチームで制作されています!
こちらのゲームについては、今後開発を担当したメンバーからのブログが公開予定なのでお楽しみに!✨

イベント振返りも実施!

今後定期的に開催できる社内公式イベントにするために、運営メンバーでちゃんと振返りも実施しましたよ(^ ^)
振返りについてはKPT形式で実施しました!
全社向けにアンケート取得も行い、次回開催への準備もばっちり整っています✨


おまけ

受賞を逃したすっごく惜しいクソゲーをご紹介します!

第二事業部エンジニアMさんの作品

英単語の意味を当てるゲームで、ステージクリア毎にだんだん英単語の難易度が上がっていきます!
英単語の中身はChatGPTで出力されているそうです(^^)

第二事業部エンジニアFさんの作品

テーマが「ひらく」なので「ひろがる円」をモチーフに作成されたそうです!
ひろがる円で敵を倒しスコアを取得します!プレイヤーが死亡するまでのスコアを競うゲームです。

エンジニア1人で作成しましたが、コスト安ながらリッチなグラフィックができた点に満足しています。
とコメントもいただきました(^ ^)/

経営管理部採用チームの作品

「ひらく」というお題から「心をひらく」をテーマに、乙女ゲームを作成!
全員が開発未経験のため、登場人物は主にフリーのAI画像生成、シナリオはChatGPTで作りました!
Unityプラグイン「宴」を使いシナリオパートを作成するにあたり、
こちらのブログを参考にしました!(^^)/

まとめ

さてさて約4年ぶりに開催された「クソゲー開発コンテスト」、いかがでしたでしょうか?
実施後にとったアンケートでは、
大変満足:51%、やや満足:22%とかなり好評なイベントでした!

Aimingでは、不定期に有志開催の勉強会や、
このように社員が気軽に楽しく参加できるイベントを実施しております(^^)/

ここ最近は社内イベントを開催できていませんでしたが、今後は定期的に開催していきたいですね!

このブログを読んで少しでも弊社に興味をもってくださった方は、
是非一度お気軽にこちらのフォームよりご連絡くださいませ✨
クソゲー開発について熱く語りましょう!

今回は運営メインの話でしたが、
来月から実際にコンテストに出場した方のブログを順次公開予定です!
お楽しみに~~(^ ^)/

]]>
https://developer.aiming-inc.com/wp-content/uploads/2023/10/0cb8133ff608580f24d75ee2b3f7b2f0-scaled.jpg