MVC框架

表示层+业务逻辑层+数据访问层，从这种角度理解该游戏框架（仅个人理解）

我们可以将InventoryManager视为维护itemList的管理中心，当有物品需保存时，负责将该物品的ItemDetails添加到该列表中。

至于ItemDetails则根据ItemName作为索引找到对应的 ItemDetails

【资料图】

对于InventoryUI，很像是一个业务逻辑，主体是OnUpdateUIEvent(ItemDetails itemDetails, int index)函数，顾名思义，就是通过找到的 itemDetails,index 来更新UI，根据 itemDetails交于SlotUI处理，用于负责物品框显示物体图片

那么SlotUI也就是直接能被用户看到的部分，也就是表示层

还有我们用户实际上是通过点击鼠标触发OnUpdateUIEvent事件逻辑，那么CurSorManager属于和用户直接交互模块，也就是表示层。

而鼠标点击我们需要调用的自然是底层的业务逻辑item代码，主要是ItemClicked()函数，用于添加到背包后隐藏物体：

我感觉就像我们做这种游戏，首先肯定考虑制定框架，包括场景转换框架，事件框架，但是具体的逻辑还要细分，仅仅就“我们点击鼠标，保存并隐藏该物品，最后显示在物品框里”这个大 的逻辑的实现上，需要考虑物品自身属性，以及我们保存物品肯定需要一个列表，当然需要维护，并且通过事件触发，但是这些数据从哪里来，就得通过前端鼠标点击，记录该物品（itemName），并完善执行后续隐藏物品，显示物品框图片的操作。

那么这些代码实际上也不需要做的和教程完全一样，差不多方向的设计都能实现这种逻辑。

可互动逻辑部分笔记

这部分先记录一些：

首先是Interactive，这个应该算是业务逻辑的部分，挂载在需要同物品交互的物体上

在CurSorManager脚本里，如果点击到的是可交互物体，那么触发下面部分进行Check

至于从物品框调取物品，激活手的鼠标图案，通过下面部分执行：

并且通过这块代码确定currentItem来贯穿整个这块的逻辑

SlotUI下面的这个函数触发该事件

很显然，这部分不会涉及到数据访问层。