写在前面
首先是日常招募擅长像素艺术，对主视角模拟经营游戏感兴趣的小伙伴组队。
目前正在等待godot4早日发布。
最近阅读了godot官方文档：最佳实践，磨刀不误砍柴工，在后续开发中可以避免许多坑。
团队成员变动
目前我主要负责功能实现和系统文档审核。
最近新加入一个策划伙伴，帮我补充了部分系统的文档。
之前的美术伙伴很久没消息了。
目前依然长期招募能负责美术方面的伙伴。
目前也需要对topdown感兴趣，熟悉tilemap可以负责游戏关卡设计和制作的小伙伴。
游戏设计相关
方向性设计
目前已经确定的设计：游戏为女性主角，主要面向女性玩家。玩家经营一家甜品店，并努力和小镇居民搞好关系。在和居民们的相处中解锁更多甜品配方和背后的故事。
与常规牧场经营类游戏的主要区别在于经营的目标从 农作物 变为 甜品（这似乎是一句废话），因此带来的核心玩法的改变：玩家扮演的主人公需要收集订单、想办法获得各类食材制作出某种甜品，送到指定的位置，从而改变NPC的行为和剧情走向。
游戏卖点
- 围绕女主性格成长（记忆找回）的主线剧情
- 程序生成叙事的支线剧情
- 更活泼的NPC
- 重复可玩性：带有随机性的情报系统（目前可透露的不多）
烹饪系统设计
烹饪系统作为整个游戏的玩法核心，我对其的设计理念反而非常“简单”。我希望烹饪本身是简单高效的。而复杂的部分在于主角领取订单、收集食材到最终送货上门这整个流程闭环。因此对于烹饪系统，我追求的简单步骤就是：
- 放入食材
- 点击烹饪
- 烹饪进度条
- 食材消失，食物出现
- 取走食物
当然，你可能注意到烹饪按钮旁的食谱按钮，这其实是一种快捷方式，对于玩家反复烹饪达到一定次数的食谱配方，可以一键快捷添加食材。但这是后话了。
基于资源Resource 的组件系统重构
因为看了godot官网提供的最佳事件，我开始考虑 使用node 来实现组件的必要性。组件的好处就是易于管理，可以将组件放置在节点树中，这也同样方便调试。
但实际上很多node的逻辑和数据我们是不需要的，我开始思考使用更底层的类，我考虑到object，最后决定选择使用resource，值得庆幸的是，这并没有消耗太多重构时间。
因为component 中更多是逻辑实现，自身并不包括数据（这一点与ECS很不同）。component 的数据应该是从其所属的entity中获取的。所以其生命周期可应该由其所属的entity来管理。
这里需要注意的是，godot中的resource是一种“资产”，其在内存中是唯一的，这就导致，如果不在entity ready的时候动态的new resource 的话，会导致对于resource的数据修改影响其他entity的component，这也是我目前没有找到更好办法的地方，我现在将所有component都设置为runtime 动态加载了。我不确定这是否很蠢，如果你知道更理想的方式，请告诉我，感谢。
主角player_character 的状态机
上一期开发日志我提到了 procedure （流程）的概念，其实就是一个全局的状态机，用来管理game state，但我很快发现，在游戏的main procedure 中依然需要细分各种状态，一个明确的需求就是游戏中的Inventory_bar （玩家的背包栏）针对背包栏中的道具，在不同状态下应该有不同的表现，比如，常规条件下，右键道具应该是“使用道具”，但当主角处于烹饪状态下，右键道具就变成了添加食材。
这部分我想到多种实现方式，比如给Inventory_bar 设置 状态机，或者像我现在做的，给主角设置状态机。
就像我现在做的，状态机是基于godot的 Node 的，这其中 StateMachine 是通用的，这是一个自定义节点。而我们要做的就是自定义各种StateBase的扩展脚本。外部只需要和state_machine交互就可以，在state_machine中会持有当前状态方便外部调用，而各种状态自身也在初始化时持有其所属的stateMachine（尽管也可以通过get_parent()来获取）。
道具和背包功能重构
上一篇开发日志有讲到，我们的道具系统是包括逻辑和表现两方面。逻辑层和表现层通过事件通信。逻辑层就是各个实体上的inventory组件。表现层则分为 itemtile、itemslot和inventorybar三部分组成。
这次是针对表现层的代码重构。原因是烹饪系统需要用到道具槽，并根据道具槽中的道具匹配食谱来产生食物。
我最开始想法是创建一个食材槽widget，但在实际制作过程中发现这个所谓食材槽和道具槽功能十分相似，但也有不同，比如道具槽点击是切换选中状态，右键点击是使用道具。道具的拖放逻辑也有所区别。
然后我意识到这些差异不应该是道具槽本身的差异。而应该是上层容器的差异。同样是道具槽，在背包界面、烹饪界面和未来的商店界面都是不同的。
想明白了这一点，就需要对itemslot进行重构，将其中的处理逻辑移到上层的inventorybar中去实现。这样三者的关系也就清晰了。
itemtile负责正确显示道具信息，仅此而已。
itemslot除了一些必要的属性外，还需要接受玩家的输入，包括鼠标进去退出，点击的拖拽等。但本身不处理，而是抛出相应的signal交给上层处理。
invertorybar或cookerbar则是实际处理前端逻辑，并且和玩家身上的相应组件交互的地方。
写在最后
3月即将结束，这月的目标就是实现烹饪系统，并尽可能维护现有框架代码，让其可扩展、可维护。
4月开始制作游戏NPC，主要的功能包括行为树、对话和任务系统这些，如果这期间有新的成员加入，也许可以并行完成游戏剧情和关卡的制作，这方面目前依然停滞不前。
5月应该可以进入填充资源阶段。当然，我说的是理想情况下。
最近这段时间也在帮忙表弟找工作的事情，可能会稍稍影响进度。
加油吧，大家！
我是老李，一个志在尽快做出这款独立游戏的游戏人。
我们下一期开发日志，再见吧！
