LR

開発日誌

―リトル・リコレクターのメンバーが、それぞれの目線で開発の様子をお届けします―

ストライプ

こんにちは。デザイナーの清水です。

今日はこのウェブサイトのギャラリーページを紹介しようと思います。

このサイトのデザインをリニューアルすると同時にギャラリーページが追加され、キービジュアルを配置していました。
こんな画像ですね:

キービジュアル

今回それに加えて開発中のコンセプトアートデザインラフを公開します!

まずは拠点のアイデアラフから。

拠点アイデアラフ

こちらのアイデアラフは森くんが作ってくれました。


これがアニーとトリスタンが暮らす拠点になります。
この世界は無数の浮島が浮いている世界なのですが、二人の拠点もそのなかの一つになります。

他の浮島と違うのは、これ自体がアニーの改造によって移動能力を有している点ですね。
二人はこの拠点ごと空を移動しながら、数ある遺跡群(ワース)を冒険しています。

3案くらい出してくれたのですが、3番のたまご型が一番しっくりきたので、これが採用されました。


次に紹介するのはワースの内部のコンセプトアートです。

ワースの内部

こちらのコンセプトアートも森くん作です。このゲームのコンセプトアートは全て森くんが作成しています。


とってもいい感じですよね。
実際の素材を作るまえにこういったコンセプトアートを作成しておくのは非常に重要です。
これがあることで複数人で作業する場合でも全員が同じイメージを共有できますし、世界観を反映したデザインになっているかどうかをあらかじめ検討してから制作に入ることができます。
コンセプトアートについてのお話はまた別の機会に詳しくできればと思います。


次はゲーム内に登場するオブジェクトのアイデアラフを紹介します。

帰還ポイントの案

帰還ポイントの案

塔から出るときには帰還ポイントを通ります。
旧文明で使われていたテレポート装置で、アニーたちはこれを使って塔の外にワープすることで脱出しています。
かつて使われていた頃は主に塔の中の移動に使われていたようです。

といった感じで、Little Recollectorの開発過程でこういったラフやコンセプトアートが作られていました。
今後もギャラリーに追加していければと思っているので、ぜひ確認してみてください!

それではまたお会いしましょう。

お久しぶりです。プログラマーの堀内です。
最近は寒暖差が激しい日が続き、風邪も増えてきているようなので皆さんもお気をつけください。

さて、今回は前回に続き『リトルリコレクター』の軽量化(最適化)についてのお話になります。 前回の記事をご覧になっていない方はこちらを読んだ上で今回の記事をご覧になっていただくとおわかりやすくなっております。

計測してみたら、予想と少し違った話

最適化を始めるにあたり、まず最初にやったことは「計測」でした。
前回もお話しましたが、勘ではなく実際のデータを見ることが何より重要です。

とはいえ、正直ある程度の予想はしていました。

背景も多いし、キャラクターも動き、エフェクトも派手。
ここで実際に Unity Profilerなどを使い処理時間を確認してみると、
目立って時間を使っている箇所がはっきり見えてきました。

特に負荷が大きかったのが 描画処理 でした。

エフェクトというのは例えば、

霧の画像
ブラックホールの画像

ブラックホールや霧のエフェクト


など、ゲームを派手に見せてくれる大事な要素です。

ただし見た目の派手さと引き換えに、処理負荷が非常に高くなりやすい部分でもあります。

なぜ描画処理は重くなりやすいのか

今回特に問題になっていたのは、半透明描画が大量に重なっていることでした。 なぜ半透明の描画が重いのかですが、ゲームで画面に何か絵やキャラクターを表示した際に、前後関係を考慮する必要があるからです。 不透明なものは上から重ねてしまえば大丈夫なのですが、半透明の場合は前後関係を正しく計算をしないと色を重ねる際に、見え方が想定していたものと違って見えて破綻してしまうからです。 エフェクトは透明度を使うものが多く、描画の仕組み上どうしても処理コストが高くなります。
しかも探索中は複数のエフェクトが同時に発生するため、負荷が一気に跳ね上がっていました。

見た目ではそこまで大きく感じない小さな光や煙でも、
それが何十個と重なると処理負荷が高くなりゲーム体験に影響をしてきます。

実際に試してみたこと

そこで検証として、一部のエフェクトを一時的にオフにして動作を確認してみました。

結果として、どのエフェクトの描画処理が重たいのかを再確認し今後どうやって軽量化をしていくのかを検討することが出来ます。

それに加えて細かくエフェクトを切り替えることでどれが一番処理負荷がかかっているかを特定できます。

ここでやっと原因が見えてくるのですが、「重そうに見えるもの」と「本当に重いもの」は必ずしも一致しません。

今回の調査で改めて感じたのは、最適化はまず原因を特定するところから始まるということです。

なんとなく削るのではなく、

  1. 計測する
  2. 重い部分を特定する
  3. 仮説を立てる
  4. 実際に切って確認する

この繰り返しがとても重要になります。


次回は、このエフェクト周りを どうやって軽くしたのか
見た目を大きく崩さずに負荷を下げるために行った工夫についてお話していきます。

こんにちは。デザイナーの清水です。

年明けの記事をご覧になった方はすでに見ているかもしれませんが、今年のウニコの年賀状はリトル・リコレクターの絵でした。

年賀状の完成形

今回は、この年賀状が作られるまでの流れでどのような変遷があったかのお話をしようと思います。

まず、リトル・リコレクターを題材にして今年の年賀状を描かないかというお話をもらった時点で4つほど案を出しました。

アニーとトリスタンが餅を突いている絵
アニーとトリスウタンがこたつに入っている絵
アニーとトリスタンが凧上げをしている絵
アニーとトリスタンがワースの前で記念撮影をしている絵

1枚目以外間違えて2025になってしまっています。

年賀状って毎年この間違いしませんか……? 僕だけですか?


見ていただくと分かると思うのですが、4つめの案以外は全ていわゆる正月の行事であったり過ごし方に関する絵になっています。
しかし、個人の年賀状ならいざ知らず、会社として出す年賀状となると、お渡しする相手も会社さんが中心ですから、その会社さんが受け取る大量の年賀状に埋もれてしまって印象に残りません。

また、せっかく自社開発の新規タイトルを制作中なのだから、もっとこのタイトルを前面に出したものを作ってもよさそうです。

そういったことをアドバイスされまして、確かにと思いましたので、タイトルの世界観が伝わるような内容で再度考えてみることにしました。

そうして描いたのが次の2つです。

ワースの中で馬の像を見つけたアニーとトリスタン その1
ワースの中で馬の像を見つけたアニーとトリスタン その2

最初に思い付きくらいの感じで1枚目を描きました。しかし、状況をただ絵に起こしただけという感じでなんとなく印象があまりよくなかったのと、せっかく塔なのだから見下ろすよりも見上げたいなと思い、上に伸びる空間が広く見えるような2枚目の構図にしました。

しっかりパースのきいた絵でなんとも難しく、なかなか大変でした。ちなみになんだかんだで4日くらいかかってしまいました。かなりヘビー級な年賀状です。

ということで、今年の年賀状を描いたよ! というお話でした。
それではまたお会いしましょう。

こんにちは。プログラマの寺沼です。

先日、インゲームのUIとして、次のような表現が必要になりました。

3色に塗られた円

中が空洞になった円が3色で塗り分けられています。このような画像を、色が塗られている範囲を変えて、複数パターン用意する必要があったのですが、パターンごとに画像を作るのは手間がかかります。

このような場合は、パターンごとに画像を用意するより、Unityのシェーダーで色を塗る機能を作成した方が早いです。

シェーダーとは、GPUで動くプログラムで、グラフィックの描画に関する処理を書くことができます。 普通、シェーダーは専用の言語で記述しますが、UnityにはShader Graphという機能があります。

Shader Graphを使うことで、ノードベースでシェーダーを記述することができます。

こんな感じで、角度や色などのパラメータを元に、それぞれの色の範囲を合成し…

Shader Graph

自由に表示範囲や色を設定できるUI素材を用意することができました。

シェーダのパラメータを動かしている様子

Shader Graphはプログラムを記述する必要が無いため、プログラマ以外でもシェーダーをいじれるのが強みですね。

それでは。

【新年のご挨拶とリトル・リコレクターの今後について】

皆さま、あけましておめでとうございます。 いつもリトル・リコレクターへの応援をありがとうございます。

2026年のご挨拶とともに、『リトル・リコレクター』の今後についてお知らせいたします。

リリース日について

まずは、リリースを心待ちにしてくださった皆さま、大変申し訳ございません。
2025年リリースを目標に取り組んできました『リトル・リコレクター』ですが、 諸般の事情により、リリースが延期となりました。

なってしまいました、というのが正しいかもしれません。こればかりはどうしようもありません。

我々『リトル・リコレクター』開発チームは、以前の記事でも触れたことがありましたが、 3人のディレクターと2人のプログラマーとデザイナーの5名がコアメンバーとなり、 社内で余裕がある人や少し手伝える人を募りながら、開発を進めています。

TGSを終えてからゲームのパッケージ感が固まり、どんどん開発を進めていこう、というタイミングだったのですが、 受託開発をメインで進めている会社である都合上、ドッと人数をかけて推し進めていくことが難しくなってしまいました...
つまるところ、みんな別の仕事で忙しくなってしまったのです。
(かくいうディレクター陣も別の仕事で忙しく、平行して進めるのも一苦労でして...)

ちょっぴり想定外のことも起きたりして、年末近くはバタバタしていたのもあり、 新年このタイミングでのご報告となってしまいました。
具体的な日程についても調整中となりますが、 本年中のリリースは死守できるようにいたしますので、どうぞ引き続きの応援をお願いします!!

リリースに向けて

作業者の確保ができない状態ではありますが、ディレクター陣をはじめ、コアメンバーは引き続き開発を続けていきます!

スケジュールが変更になったことの良い側面を見れば、期間自体は伸びた形となりますので、各所ブラッシュアップを続け、皆さんにより良い形での『リトル・リコレクター』をお届けできるようにして参ります。

リリースまでの間にいろんな施策を考えておりますので、楽しみにしていただければです!

開発者メッセージ

各メンバーからもメッセージもお届けします。 ぜひご覧くださいませ。

先にも述べましたように、『リトル・リコレクター』を皆さんにお届けする時期が遅くなってしまい、申し訳ございません。

ですが!このピンチをチャンスに変えるべく、各メンバーとともに『リトル・リコレクター』のブラッシュアップを続けてまいります。

昨年のTGSで試遊いただいたみなさんから頂いた感想をもとに、『リトル・リコレクター』は更なる進化を続けています。
『リトル・リコレクター』をお届けするまで、まだ少々お時間いただきますが、引き続きの応援を何卒よろしくお願いします!

プロモーション観点でも、皆さんに楽しんでもらえる施策はたくさん考えていますし、具体化に向けて話も進めております!
ぜひご期待くださいませ!!

『リトル・リコレクター』ディレクター: 笹口 陸

ユーザーの皆様にはお待たせする形になってしまい申し訳ありません。

関わる人数は減ってしまいましたが、その分こだわり抜いてアート面からゲームを彩っていこうと思いますので、今しばらくお待ちください!

TGSではお見せしていないステージ背景やアニーたちのかわいい追加モーションなども作成中ですので、リリースした暁にはぜひチェックしてみてください!

『リトル・リコレクター』アートディレクター: 清水 祥平

発売を楽しみにしていただいていたにもかかわらず、リリース延期となってしまい、誠に申し訳ございません。

より面白いゲームとして完成させ、皆様のもとへお届けできるよう努めてまいりますので、もうしばらくお待ちください。

『リトル・リコレクター』プログラムディレクター: 寺沼 優

ユーザーの皆様、あけましておめでとうございます。本年もよろしくお願いいたします。
プロジェクトの体制は縮小しましたが、開発は継続して進めています。

今後も操作の手触り改善と最適化に注力し、より快適な体験をお届けできるよう進めてまいります。
リリース時にはぜひ遊んでいただけると嬉しいです。引き続き応援よろしくお願いいたします。

『リトル・リコレクター』リードプログラマー: 堀内 瑠海

皆さま、あけましておめでとうございます。

事情はどうあれ、延期という形になり大変申し訳ありません。
持ち味をより一層深められるように努めますので、ぜひ今後のリトル・リコレクターをどうかよろしくお願いいたします!

『リトル・リコレクター』リードデザイナー: 森 大雅

最後に

アートディレクターの清水くんが年賀状を描いてくれました。
皆さんの一年が良きものになりますように!

年賀状2026
1 2 9  > 

page top