ブログ作成

Author: y-yamasaki

WebSite/content/other/blog_00021.md

@@ -0,0 +1,56 @@
+---
+title: UnityでUIのSE再生を実装するときに悩むこと
+date: 2025-12-11 
+category: 技術メモ 
+description: 
+tags: [Gemini, Copilot, API] 
+recommended: true 
+thumbnail: assets/img/unity_icon.png
+---
+
+こんにちは！パン君です。
+
+今回は答えの無い話にはなる上、根本的に Unity 以外でも発生する悩みなのですが  
+**UIのSE再生処理の実行責任を何が持つべきか** です。
+
+# 前置き
+
+SE(リソース)の読み込みや解放(Resource)、再生や停止(Controll)などのモジュールが単一責任に分れていることは前提です。  
+
+ここではこれらのモジュールのAPIの呼び出し箇所に焦点を絞って話します。  
+
+かといって次の章でだいぶ答えが出ているようなものなのですが、  
+筆者がゲームに携わる度に 「中途半端な使用方法」 をしている所しか見られず、
+結局一か所治せば済むはずなのに、都度オブジェクト単位の改修を要求されてしまい  
+「う～ん...」 という状態になるんですよね。  
+
+# どうしてほしいか
+
+語弊が生まれる可能性があるので、後述する内容も読んでいただきいたいmm  
+まずどうあってほしいかというのを端的に明確に話すと  
+
+> UIが再生処理を呼びたいのか、イベントが再生処理を呼びたいのかハッキリしろ
+
+これです。  
+単一プラットフォーム、もしくは小規模であるなら「実装できたら正義」でいいと思うし  
+筆者もこの考え方は肯定派です。  
+
+ただ、逆の 規模が大きいプロジェクトを作る現場に限って **資料共有が滞っている** 影響で多様な再生ロジックが実装されていくんですよね  
+複雑になるほど、情報伝達を行う人間の理解度と伝達能力に依存しますのでどこかでエラーが発生します。  
+
+よくある話です  
+
+ただ、これの対策として実際に明確にルール化したときに少し困った点がありまして  
+それは下記です。  
+> 要件が開発中に変わった際に、仕様の範囲外の要件だった時　　
+
+はい、そうです。
+対処した内容がこの時点で 「一種の多様な再生ロジック」 と化けます。  
+振り出しに戻って考え直してください。  
+
+...
+
+となるのが、基本だと思うのですが...
+私は下記のように考えます。  
+
+# 一種の多様な再生ロジックでもいいから、絞れるところは絞って管理しませんか？