VRChatでコントローラーのスティック入力を取得する方法

VRC VRC Udon + U# VRChat

対象

コントローラーのスティック入力を取得して色々したいなと思った人

例えば、移動の入力をドローンなどの操作の移動に変更するといったもの

検証環境

Unity2019.4.31f1 VRChatSDK-World　3.4.0 VRChatSDK-Base　3.4.0

やり方

UdonSharpBehaviorを継承して、以下のメソッドを追加する

  • InputMoveHorizontal
  • InputMoveVertical

具体的には以下の通り

public class VRCSample : UdonSharpBehaviour
{
       //水平方向の入力を受け取る
       public override void InputMoveHorizontal(float value, VRC.Udon.Common.UdonInputEventArgs args)
       {
  　  }
        
        //垂直方向の入力を受け取る
        public override void InputMoveVertical(float value, VRC.Udon.Common.UdonInputEventArgs args)
        {
        
        }
}

これらのメソッドに関しては、DeskTop、VR共にさほど変化はなく Horizontalの場合は、左移動の時は、負の数値、右移動の時は、正の数値が入力される Desktopの際は、-1,0,1と入力が返されるが、VRの場合は-0.99 ~ ,0,~0.99が返却される。

Verticalは前後移動の際に同様の数値が返却され、 前方向は正の数値、後ろ方向は負の数値が返却される。

参考

udonsharp.docs.vrchat.com

プレイヤーの中から、誰か一人を対象とした処理を行うやり方

VRC

概要

この記事は、Prestoniaさんが作ったワールドで使われている誰か一人のユーザーを取得する方法についての記事です。

ワールドはこちらから ホラワホームワールド -Japanese horror house- by Prestonia #VRChat #MadeWithVRChat

vrchat.com

この記事を読む事で、以下の内容を知る事が出来ます。 - 全員のプレイヤーの中から、一人を抽出する方法 - その対象の人に対して何かを行う方法

開発環境

Unity2019.4.31f1 VRCSDK3-WORLD-2022.04.20 16.26 U# v0.20

実際に行う事

ざっくり行う事としては、2つです。

  • プレイヤーIdの保持
  • プレイヤーIdから、特定のプレイヤーのみの処理を行う。

プレイヤーIdの保持

VRCではプレイヤーにプレイヤーIdが存在しています。 このプレイヤーIdはVRCPlayerApiから取得できます。

OnPlayerJoinと、OnPlayerLeftという関数がVRC側から提供されておりPlayerがJoin/Leftのタイミングで、以下のようなコードでVRCPlayerApi取得する事が出来ます。

public override void OnPlayerJoined(VRCPlayerApi player)
{
    //ここに処理を記述する
}


public override void OnPlayerLeft(VRCPlayerApi player)
{
    //ここに処理を記述する。
}

この時に、このIdを情報として保持しておく事で、現在存在するプレイヤーの一覧が事実上取得が可能になります。

プレイヤーIdから、特定のプレイヤーのみの処理を行う。

保持さえすれば、あとはやる事としては3つです。 1. ランダムで対象を選ぶ 2. したい処理を全体で行う 3. 選ばれたプレイヤー以外は処理しないようにする

1 ランダムで対象を選ぶ

UnityEngine.Random.Rangeで保存しているプレイヤーIdから、どれかを選択します。 この時、選ばれたものをUdonSync属性のついた変数に保存します。

2 したい処理を全体で行う

全体を行うというのは、SendCustomNetworkEventで、共通の引数なしの関数を呼び出しの事を指します。

3 選ばれたプレイヤー以外は処理しないようにする

2で呼びだした関数の処理内で、Networking.LocalPlayerでその選ばれたプレイヤーのIdの人かどうかを判断して、同じ人物だった場合処理を行い、そうでない場合は処理をしないようにします。

VRCSDK3　同期周りを調べてみた

VRC Udon VRC Udon + U#

概要

VRCSDK3とU#を使用した同期関係をまとめた記事です。

主に以下の内容について、本記事では記述しています。 - 同期のタイミング - UdonBehaviorのSynchronizationMethodの設定によるそれぞれの影響 - 設定による[UdonSync]の変数の挙動 - 違う設定のGameObject間での同期の影響について - Joinなどの挙動

確認環境

  • Unity2019.4.31f1

  • VRCSDK 2022.04.20.16.26

  • U# v0.20.3

必要な知識

  • 関数がわかる人
  • 同期の仕組みが、基本的にはOwner基準で同期されるという事がわかっている事。

同期とは？

同期とは？そもそもなんなのでしょうか？ 同期は、簡単にいうと、他の人と同じ状況にする事です。

VRC内であるのはPickUpのObjectは、同期されているものため、みなさんと同じ位置に持っている物が見えている状態になっています。

そして、同期を行う際に、基本的にはGameObject単位で保持されているOwnerの環境下での状態が同期されます。 そのため、対象のGameObjectのOwnerがどの人なのかを把握しておく事が重要です。

同期されるタイミング

同期の形式は大きく分けて2種類の同期があります。 - 変数の同期 - [UdonSync]の同期 - UdonBehavior側のSynchronizationMethod設定に依存 - Continous - オーナーの値を常に同期して他の人とほぼ同じ値を共有する - Manual - RequestSerializeを呼び出した際に値が共有する。 - 関数の同期 - SendCustomNetworkEventによる「動作」が同期

[変数の同期]

変数の同期は、状態を他の人と同様にする際使用します。 たとえば、スコアや、ミラーのOnOffなどの状態です。

同期のしたい変数は[UdonSync]をつける事で同期され、インスタンスに途中から入ってきた人に対して同様の値を通知します。

同期されるタイミングは、基本的には、UdonBehavior側のSynchronizationMethodの設定によって変化します。

Continuousは、[UdonSync] がついた変数が常に同期されます。 正しい値がほぼ確実に入る一方で、常に通信を行っている事になります。

通信が多くなるため、それによる不具合などが発生した際に大幅な改修が要求されます。

Manualは、RequestSerializeを呼び出した任意のタイミングに同期を行います。

常に送るわけではないので、同期頻度によっては、通信を減らす事ができます。

一方で、同期を行うタイミングの管理を行わなければいけないため、工夫が必要です。

[関数の同期]

関数の同期は、全ての人が一緒のタイミングで始める場合に使用します。

SendNetworkCustomEvent（対象、メソッド名）で実行をします。

変数の同期と違って、その場、その時にいる人に対してのみ行われるものです。

なので、これを使ってゲームがスタートしていて、途中から入られたくない場合は、変数の同期と合わせておく必要があります。

同期のパターン

今回調べたパターンと結果はは以下の通りです。 - SynchronizationMethodの設定がContinuousの場合 - 値が常に更新される - SynchronizationMethodの設定がManualの場合 - 呼び出されたタイミングのみ更新される - ContinuousのUdonBehaviorからManualのUdonBehaviorに定義されている関数を直接呼び出す。 - 値が更新されない - ManualのUdonBehaviorから、ContinuousのUdonBehaviorに定義されている関数を直接呼び出す。 - 値が更新される。

  • ContinuousのUdonBehaviorからManualのUdonBehaviorに定義されている関数をSendCustomEventで呼び出す

    • 値が更新されない

  • ManualのUdonBehaviorから、ContinuousのUdonBehaviorに定義されている関数をSendCustomEventで呼び出す。

    • 値が更新される。

  • ContinuousのUdonBehaviorからManualのUdonBehaviorに定義されている関数をSendCustomNetWorkEventで呼び出す

    • 値が更新される

  • ManualのUdonBehaviorから、ContinuousのUdonBehaviorに定義されている関数をSendCustomEventで呼び出す。

    • 値が更新される

- ContinuousのUdonBehaviorDesirializeの挙動

  • Manual時のRequestSerializeからどれくらいの遅延が起きるものなのか？

まとめ

基本的には、[UdonSync]属性のついている変数が同期対象です。

同期タイミングが、UdonBehaviorのSynchronizationMethodの設定が

Continueの時は常に同期されます。

Manualの時は、RequestSerializeが呼ばれた時に同期されます。

またPlayerJoin時はどちらの設定にも関わらず、[UdonSync]属性がついている変数が同期されます。

カレイドスペース行ってきたので、ひとまず簡易的なレビューとか

あなた is 誰？

普段とかは、LaMerとかXOasisに行きつつ、VRCとかやりながら色々作ってたり、書いたりする人。 基本的には、騒がしいのは苦手なので、1:1とかでのコミュニケーションを好むコミュニケーション苦手勢です。 かといって、1:1だからって饒舌になるわけではないので、あくまで多数よりは少数の方が好みだよくらいの認識に思ってもらえるとです。

カレイドスペースis何？どんなサービス

以下HPから引用

カレイドスペースとは バーチャル店舗「カレイドスペース」に所属するキャストと会話を中心としたコミュニケーションが楽しめます。 キャストとの対話は2人きりの空間で。ちょっとした雑談から秘密の相談まで、どんなことを話すかはゲストのあなた次第。

あなたとキャストの組み合わせの数だけ生まれ、何度も会いに来ることで積み重なっていく関係性。 自分だけの大切な場所をつくりませんか？

使用環境はZoomを使用します。

ゲスト（お客側）は、リアルを表示、非表示、アバターで表示の3つの方法のうち1つの方法で、キャストさんと対面する形になります。 表示、非表示に関しては、Zoomの機能として、使う事が出来ます。 アバターに関しては、別途ツールなどの使用を行う事で出来ます。

カレイドスペース全体的なざっくりな印象

予約を行う際に、ハンドルネーム＋メールアドレス＋TwitterIdを入力する必要があるのですが TwitterIdを入力を行うだけあって、キャストさん自身が入力したTwietterIdの内容とかを事前に見に来てくれてたりします。 ただ、この辺はキャストさんの裁量による部分なので、全体を通してみているというよりは、だいたい今回きてくれるお客さんはどんな人かなの把握とかを軽くやっているような感じの印象です。 30分程度だったら自己紹介とか＋話題ふりとかをお互いにやったら一瞬で時間が過ぎていくので、慣れていない人も恐らく問題がない感じです。

あと個人的に思っていたのが、視線が常に絶妙に合わない問題があると思いました。 例えば、Webカメラを見ると映っている自分の視点とかは正しいのだけど、こちらから相手が見えない。 これはWebカメラが、画面より外側に配置されているため、起きる問題です。 逆に画面をみるとカメラから見た時のこちらの視点が正面見ている感じにはならない。

セッション

1.Zoomで待機（ビデオOnOffでも良い、アバターで動作する人もいる。） 2.時間になったら、相手側から参加が許可されるのでそこからビデオ通話が開始されます。 3.時間いっぱいしゃべります。 4.いい感じの区切りとかのタイミングで、キャスト側からそろそろ時間ですねーみたいな事言われるか何かするので、最終的にゲスト側がZoomの退出ボタンを押して退出するスタイル。

Zoomとかを使用する上での良さ

良さ

個人的には、チャットとかを使えるとかが結構使おうと思えば使える感じのイメージがある。 例えば、動画のURLも共有できるし、なんなら画面共有とかで何かを一緒にみるっていうのはすごく楽にできるので、その辺の使い道とかをもうちょっと活用する手はあるんじゃないかな？と思った。

特にYouTubeで～～見ているとかおすすめとかの場合は、URLを貼るとかを行えて、共有を容易に行いやすい。 ただ、この辺のやり取りを行う時に、チャットをみるとかを慣れていない場合もあるので、一言を付け加えたりすると対応してくれたりします。

Zoomでの対面とかで感じたこと

Zoomの参加方法として 1. リアルアバターで参加 2. こちらの映像なしで参加 3. ツールなどを使用して、参加 の3種類存在していますが、個人的な感想としては、2が基本的な選択肢になるのかな？って思いました。

1の場合は、容姿のコンプレックスによる抵抗 や 最低限の身支度などが必要が出てきたりするし 3の場合は、ツールの使用が必須なわけですから、よほどZoomをアバターで普段から使っているとかでない限りは、ツールを使用するためのの学習コストが大なり小なりはあるわけです。

今回私は、1のリアルアバターによる参加を2回行ってきましたが、会話開始するまでちょっとした心理的な負担はありましたし、身なり面で、髭を沿ったり、髪を手でとかすくらいには身支度をしたりはしました。 結構自分自身がめんどくさがり屋なので、この辺はすごく大きなハードルの一種です。 それに世間的にもコロナで外に出ない人も多くはなってきているので、この辺はハードルがこれまでより高いイメージです。 それもあってか、キャストさんによるとリアルのアバターで対面するのは基本的には少ないそうです。 実際聞いた話だと、ビデオオフの状態と、アバターでの参加が割合的に多いそうです。

ただ、その中でどうしてリアルアバター選んだかというと、理由は単純な事でキャストさんとのコミュニケーションのしやすさを重視しました。 VRの場合だと手振りとか、首の動きとかで会話以外の部分などで、相手の反応を見る機会が存在します。 しかしながらZoomの場合だと、ビデオがない場合は声だけの場合相手の声色だけで判断せねばならないため、その辺の負担を減らすために行いました。 アバターという選択肢もあったのですが、それは今回学習コストの面で選択肢としてはなかったです。 あと単純にどれくらいの負担と感じるかとかも興味あったのもあります。

　キャストさんについて

一応どちらも30分程度の短い時間での中での感想なので、推測などが入っている部分もあります。 というか30分程度だとぼんやり像がわかるかわからないかくらいですかね？

小紫ふうさん

以下自己紹介動画 https://youtu.be/5BzkCMQQWgQ

30分での印象

結構おっとりな感じの印象。 緊張していたからかはわからないが、ドジっ子の属性とかある？っていうそんな感じあぶなっかしさはある感じがかわいいのかなと思いました。

塩見らいちさん

以下自己紹介動画 https://youtu.be/5jY_KaI_KW0

30分での印象

そこそこに落ち着いている印象の中に、ちゃんと相手の事を気にかけて会話とかを投げてくれる感じの気回しがうまい感じなのかなと思いました。

期間限定"お砂糖"「錯花林」を体験してきた

VRC 体験談

錯花林とは

らいずさん(@_mumumu)が行っている期間限定でお砂糖っぽい事を行おうといったもの。 日付を決めて、その期間を一時的なお砂糖相手として、過ごすといったもの。 1日or3日の日程を、ある程度まとまった期間の日程に調整して、その期間を過ごすもの。

詳細は以下のTweetから https://twitter.com/_mumumu/status/1455417334445731843?s=20

今回偽糖してもらった相手

今回相手してもらったのは、Lminaさん。 相手をお願いした理由というのはいくつかあって

  • 話のテンポ感が比較的にゆっくりだった。（テンポが早すぎると、私があわあわしちゃうので）
  • 落ち着いた声だった。（声大事！）
  • 話のキャッチボールがしやすい相手だと思った。（私もときどきはしゃべりたいので）

実際体験した感じどうだったか？

すっごく良い3日間を過ごす事ができました。

これの一言に本当に尽きている感じで、相手にも伝えたのですが、本当に最初の偽糖の相手でよかったなっていう感じです。

あくまでも個人談ですが、恋人っぽい事をたくさんした気がするし、お互いに好意的な気持ちを、何かしらの表現で送りあっている状態ってすっごく心地いいなっていう感じです。

すっごいほわほわする感じだし、精神的な満たされはありました。

準備期間でのやりとりとかで感じた事とか。

私の場合、偽糖を決めた時期が、12月の末でした。 決めた相手と3日間の予定を合わせた結果、決まってから始まるまで、1か月ほどの期間がありました。

会話の中身とかは見せられないので、具体的な想像とかはすごくしずらいかもしれないですが、

  • 定期的なあいさつとかを送ってくれる
  • 提案した事に対して、ちゃんと返信をくれる

この辺とかが、私にとってはすごく嬉しくて、楽しい部分とかでもありました。 定期的なおはよーとかは意外とそこからの会話のきっかけになってたりしてました。 たとえば、天気の話、気温の話とか、今どうしてるみたいな感じから始まって、さらにそこから深堀りした感じとかをとてもしやすかったです。

Discordなどのテキストベースの会話においては、私の価値観が「何か用事がないと相手に迷惑をかけてしまう」っていうのが常に頭の中にあって、本当に送って大丈夫かな？めんどくさくない？みたいな事がどうしても考えてしまって、自分からメッセージとか書けないので、こういった相手から定期的なものとしても送られてくるのはすごく会話しやすかったです。 数日もそれらの日々が過ぎる頃には、相手からメッセージが届くのを楽しみになっていたりしました。

準備期間中もなんだかんだで、年明けに私が寂しくなっているタイミングで、相手が起きていたので、ちょっと通話してもらったり。

なんだかんだで総じて、偽糖みたいな感じのやりとりとかを行っているような感じがして、少しこうむずむずーみたいな感じながらやり取りしてたりしてました。

準備期間にやっておいてよかった・やっておけばよかったとか

やっておいてよかった

あくまで、個人的な感想ではあるものの、やっておいてよかったなぁと思った内容ですが - 偽糖プロフィール帳

偽糖プロフィール帳

みなさんは小学生の時に、プロフィール帳なるものに触れたことはありますか？ プロフィールを埋めて、相手の意外な一面をしったり、秘密とか書いたりするあれです。 すごく知れるきっかけ作りにも使えるし、振り返りの際に、後から見れるのもいいですよね。 なお、私は、書いたことも触れたこともありませんでしたが、楽しいものだったんですよね？ その辺の雰囲気も知りたかったので、相手の方にお願いして書いてもらったりしてました。

もちろん自分も書いて、どんな事書くのかな？みたいな事思いながら結構楽しかったです。

実際に使ったプロフィール帳っぽい項目とかは以下の通りです

名前：
職業（専攻）：
好きな食べ物：
嫌いな食べ物：
趣味：
寒いのと暑いのどっちが好き？：
休みの日何してる？：
得意な事（好きな事）：
苦手な事（嫌いな事）：
人におすすめしたい事：
こだわりのある事：
実はこう見えて、、、：
甘えたい時：
どんな甘やされ方が好き？：
偽糖中にしてみたい事（3つくらい）：
・
・
・

序盤とかは、適当に「プロフィール帳　項目」とかで検索してでてきたものを使いました。 後半3つくらいは、この偽糖のために合わせてどんな感じとかしたいのか？されたいのかを知る為に作った個人的に作った項目です。

実際に、期間中に過ごす方針とか、どんな過ごし方、ワールドの巡り方とかを決める時には、便利な項目だったように感じました。 人によっては、行ってみたいワールドとかの項目とかはあったらなおいい感じになったりはしたかもしれませんね。

また甘えたい時とかは、自分・相手がどちらも甘えたい感じの雰囲気があったので、それらをしてほしい素振りをわかるように補助する形であったのはよかったんじゃないかなと思いました。

やっておけばよかった

プロフィール帳を書いたおかげで、だいたいのやりたい事とかは決められていたけれど、それを行うにあたってどこのワールド行くかみたいな話合いとかはできるとなおよかったかなと思いました。

いずれも相手のおかげで、どこいこうか？みたいなで1時間すぎるみたいな事とかは発生しなかったです。 ただ、その場合に限らない場合もありますよね？

たとえば、どこどこ系のワールド行きたい場合に、「どこ」を決めるか、「誰が」それを準備しておくべきものなのか？などはあったほうがよかったのかな？と。

この辺を思った理由としては、不明瞭な状態は私の特性状、少し不安を感じやすいのと、どの部分までは要望として出すタイミングなのか？みたいなのが「明確になる」ため。

この「明確になる」というのは、私にとってかなり重要なもののためのものではあるけれど、多くの人はそうでもないのかもしれませんね。

今回訪れたワールド

最後に、今回の期間中に行ったワールドをご紹介します。

1日目

水の休息所 -UnderwaterLounge-

vrchat.com

学校の怪談～Ghoststories～

vrchat.comhttps://vrchat.com/home/world/wrld_1b49a852-f6ae-481e-9611-71e1476cbaa5

Infinite Night

vrchat.com

2日目

この日は、通話だったので、ワールドは行ってません。

3日目

Starry Ocean

vrchat.com

DEEP FOG ILLUMINATION

vrchat.com

FA-18F Aircraft Carrier World v1.80

vrchat.com

Progetto Rosso v0.6.4

vrchat.com

Winter Company

vrchat.com

最後に期間中にすごく良い感じの写真取れたのでぺたり

f:id:herie270714:20220122230237p:plain

NianticLightShipARDKが配布されているので、AR空間上にCube置くまで

技術

概要

この記事は、現在配布されているNianticLightShipARDKをとりあえずUnityProjectに導入し、BasicPlacemetTutorialの内容をビルドを行うまでの記事です。

なお、BasicPlacementTutorialの内容は、lightshipの内容のリンクから飛べるYouTubeを参考にしたものです。

完成するものは、最終的には、認知した平面状に、Cubeをおくためのサンプルです。

2021/12/05時点

導入までの簡易な流れ

  1. https://lightship.dev/ にアクセス

  2. Get Started on ARDKから、ぽちぽちしていく

  3. 開発ユーザー登録する（必須っぽい）

  4. ダウンロードしたUnityPackageをUnityに導入

最低要件

記載されていたUnityのVerの最低要件と、AndroidおよびIosの要件です。

以下登録後に見れるDevelopDocumentation内に記述されている所抜粋(開発者登録後見れる)

lightship.dev

今回の使用環境

導入（詳細）

PackageDownLoadまで

  1. https://lightship.dev/ にアクセス　

f:id:herie270714:20211218142033p:plain

  1. もう一画面

f:id:herie270714:20211218142057p:plain

  1. 開発者SignInが要求されるのでログイン（なければ開発者登録する必要がある）

f:id:herie270714:20211218142113p:plain

  1. 開発者登録（まだしていない場合）

f:id:herie270714:20211218142134p:plain

  1. ログイン後左のタブのDownLoadの部分を押したのちに出てくる画面でダウンロードする。

この時、その下にあるExampleProjectsもダウンロードしておく必要がある。 追加パッケージ的な雰囲気を出しているが必須のコードがこのパッケージに入っており、むしろ必須。

Unity導入に導入編

UnityPackageを作成したプロジェクトに導入する

サンプルっぽいものを動かす

見落としはあるかもしれませんが、サンプルっぽいものは、別途ダウンロードできるものに含まれています。 しかし、今回はチュートリアルに沿った形で、 開発者登録後に見れる以下のサイトから https://lightship.dev/docs/moderate_semantictextures_tutorial.html

Tutorialの項目から行っていく必要があるみたいです。 なお、Turorialの項目は、執筆現在全部で14項目ほどあります。

手順

  1. 新しいSceneを準備します
  2. MainのCameraに以下のComponentをつけます
    • AR Rendering Manager
    • AR Camera Position Helper
    • AR Session Manager
      • この時追加でCapability CheckerというComponentが付いてきます。
    • AR Plane Manager
      • Plane Prefabの項目にはPlane PrefabというPrefabを追加します。
    • Android Permission　Requester
      • Permission Size 1に設定
        • Cameraを設定
    • AR Cursor Renderer(ARDKと別途ExsampleのPackageを入れる必要がある。)

これだけだと、以下のような感じのエラーが出ます f:id:herie270714:20211218142155p:plain

  1. Project Settingの設定を変更します。（この段階でSceneを実行するとエラーが出ます）
    • Edit>ProjectSettings>Tags and Layersの項目を開く
      • Layersの部分に　ARDK_MockWorldを追加

f:id:herie270714:20211218142342p:plain

いくつかのはまりポイント

UnityEditorで動くが、ビルドして以下の症状に見舞われたら？

  1. アプリが起動しない

  2. 真っ暗な画面が表示される。

  3. 追加したパッケージがうまく解凍できない

アプリが起動しない

  1. アプリのビルドする先のAndroidのAPIレベル30以上だった場合はandroidmanifestの作成が必要なようです。 https://lightship.dev/docs/building_android.html

真っ暗な画面が表示される

A.Androidのビルドする際の設定が足りていない可能性があります。

以下を確認してみて下さい

  • AndroidStudio等のSDKManagerに対象のビルドターゲットのAPIが追加されているか？
  • ARの機能が使用する事ができる端末かどうか？

追加したパッケージがうまく解凍できない

12月18日時点では改善されたかはわからないのですが、友人に教えてもらった感じ 圧縮されているファイルは２重で圧縮されておりその結果解凍しても.unitypackageがでてこない現象が起きているとの事

解決手段として提示してもらったのが以下の通り

  1. 解凍する際のソフトウェアをラプラスで解凍する

「Lhaplus」定番の圧縮・解凍ソフト - 窓の杜

  1. 以下の手順を行う

①ardk-getting-started-1.0.1.tarを解凍する

②ardk-getting-started-1.0.1(拡張子なしができる)

③ardk-getting-started-1.0.1(拡張子なし)を解凍する

④ardk-getting-started-1.0.1(目的のフォルダ)が生成される

noshというサービスを利用したのでレビュー

体験談 日記的な

noshというサービスを利用したので振り返り

nosh(ナッシュ)とは？

noshとは、 - ヘルシー・低糖質の冷凍宅食を、定期で配送してくれるサービス - 決めた週の間隔で、決めた食数を配送してくれる。 - 一番短い間隔は1週間に1回の配送 - 最低食数は6食から

私isだれ？

具体的な評価の前に、あなたがどんな人かというのを軽く紹介 基準とかの参考にどうぞ - 30代くらいの男性 - 普段から料理とかはする - 野菜とかをあらかじめ切って保存 - 使いたい時に必要な分だけ使う - メニューとかは少し偏りがち - 1日3食

- 食べられる量

総評とか

個人的には、味とかももちろんあるが、料理作って心的に満たされている側面があるので、たぶんもういいかなと言った感じです。 ざっくり良いところ、ここは～っていうところをまとめると以下の通り

  • 良いところ

    • 疲れて帰ってきてもレンジで済むのでむっちゃ楽
    • 後かたずけも捨てるだけなので楽
    • 皿の中に小さいおかずも混みで4種も食べられる！

  • 個人的にはちょっとと思ったところ

    • 男性には量が足りない
      • 実際食べる時に、汁物やご飯を追加で足す等はしてた。
    • 味のあたりはずれが大きい。
      • 半々くらいのあたりはずれがあるイメージ
        • あたりの場合も、少し味が濃いめだったりする感じでした。
    • 冷凍庫が圧迫される
      • 普段冷凍庫使わない人とかなら全然いいけど、使う人だと6食でもいっぱいになる。

今回頼んだメニュー

  • 焼き鳥の柚子胡椒

    • 柚子風味っぽい気がする胡椒をつけた感じのもの
    • 柚子胡椒の味付けが付いた部分が液体
    • 肉は、少しパサついた感じの硬さ f:id:herie270714:20211128160437j:plain

  • ロールキャベツのチーズデミ

    • かかっているデミグラスソースが結構な美味しさ。
    • チーズに関しては、溶けて固まるため、最終的にデミにある程度の塊をフォンデュする形式でたべる感じにはなる。
    • ファミレスくらいに行った感じにはなる。 f:id:herie270714:20211128160359j:plain

  • 旨だれペッパーチキン

    • 肉的には美味しい部類
    • ちょっと味が濃いめの印象を受けるくらいには濃いかも？
    • 夏場とかの汗かく時期とかならちょうどよいかもしれない。 f:id:herie270714:20211128160732j:plain

  • チリハンバーグステーキ

    • 一番押しているだけあって、結構良い感じ。
    • ただ、美味しいハンバーグかどうかと言われたら、少し微妙
    • ハンバーグっぽい何かを食べる気分だとちょうどいいかも？ f:id:herie270714:20211128155749j:plain

  • 鯖のコク旨だれ

    • たれ自体は結構良い感じ。
    • 少し味は濃いめで、ごはんは欲しくなる感じではある。
    • 電子レンジしている時に、魚独特の匂いはするけれど、食べ始めたら、そこまで気にならないレベルではある。 f:id:herie270714:20211128160535j:plain

  • 牛肉の麻婆ごまだれ

    • 肉が少し固めのタイプのもの
    • ゴマダレが、少量なので、かかっている部分とかかっていない状態になる。 f:id:herie270714:20211128161159j:plain

  • チキンと半熟卵のカルボペンネ

    • カルボナーラの感じがでて、結構美味しい。
    • 半熟卵は中心部分がちゃんと半熟になっている。
    • チキン系は、少し肉質固めではあるが、歯ごたえ的な意味合いではちょうどいいかもしれない。 f:id:herie270714:20211128160255j:plain

  • 四川風エビのピリ辛

    • エビの食感とかはすっごいいい感じ
    • 四川風？な疑問を感じるくらいのさっぱりした味付け
    • 付け合わせで、ついていた、ミニシューマイみたいなのとか付け合わせが実はメインなのでは？ってくらいには美味しい f:id:herie270714:20211128160224j:plain

  • 鮭のマッシュポテトアヒージョ

  • 豚肉とメランザーネのミートソース

    • 肉自体は、焼きすぎた肉みたいな感じの食感だった。
    • 味自体は、濃すぎず、薄すぎずでミートソースしてた。
    • 可もなく不可もなく。 f:id:herie270714:20211128161101j:plain

  • チキンとトロトロ卵のデミ

    • 卵はトロトロからは少しほど遠い感じ、朧卵くらいの感じ
    • チキンに関しては少し固め。むね肉みたいな硬さ。
    • 味に関してはバランスのとれた感じで良い。 f:id:herie270714:20211128160954j:plain

  • 担々豆腐麺 まだ食べてない。