Java 游戏库存系统结构？

我正在为我的小RPG游戏开发一个库存系统。它是为多人游戏设计的。 到目前为止，我有一个工作设置，但我很不满意它，并希望从新开始。我主要谈论的是模型，而不是视图

一个用户有多个库存。不同的存货包括饮料、一些特殊物品、垃圾等

库存最多可容纳n个项目，以插槽表示。x，y不是固定的，用户可以根据其设备进行更改

物品可以堆叠，也可以不堆叠。如果无法堆叠，则可以配备

适用于不同的移动/桌面设备

我的问题主要是它变得过于依赖对方。我有一个Item和一个ItemStack类。如果该项目是可堆叠的，则该项目将以一定的金额添加到itemstack中。两者都继承自AbstractItem——虽然Itemstack不是一个项目，但我当时不知道如何添加它。这导致了这样一个事实：我必须在抽象类/接口中添加方法，才能正确地处理这两个类。就像向抽象类中添加currentCount一样，它只对ItemStack有用，但Item也有它，尽管它永远不会需要它。此外，Inventory保留InventorySlot，它只有一个ItemStack或Item以及一个用于该插槽位置的变量。 通过简单地检查Itemtype和enum，可以实现不同的库存

视图将只查找库存。检查非空插槽并读取Item类中的纹理-或ItemStack中项目中的纹理~

我就是这么想的，但这似乎是狗屎

---

您建议如何构建这样一个简单但易于升级和维护的系统？区分每个枚举的项目类型和库存是否更好，或者仅仅为其创建一个自己的类，或者为消耗品、装备等创建一个接口更好？

这是一个困难的主题，因为它取决于您的游戏或库存设计

我可以建议：

您可以将所有项目作为json存储在SQLite中 [{item1:{name:x，attr:x，atk:5，agi:-3，lbl:equipment}， 等 …等}]

---

有了它，您可以为每个项目提供更灵活的结构，即使您可以使用GSON将每个json对象转换为特定的java对象，如果您不想让自己变得复杂，那么您的插槽数量有限，或者可能只有一个大的库存网格，你可以把所有不同的物品都放在那里

好吧，我想了解一下设计库存的技巧。如果我没有一个项目的外观和蓝图，那么考虑存储就有点太早了，顺便说一句，我使用hibernate。此外，您的示例仅适用于Equipms之类的固定项目，但是那些可堆叠的项目又有什么用呢？尽管我可以看到如何使用JSON？我不明白你的最后一句话，我有什么不让自己复杂化的呢？如果你在谈论不同的库存：我不认为这会是一个大问题，只是如何正确地制作它们才是问题。正确地制作库存取决于你对游戏的需求，或者你希望玩家如何使用库存，如果是面向对象的，那么每个对象都可以有不同的属性：名称、数量、描述、属性，类型，如果您使用的是hibernate，那么我假设您使用的是DAO模式，我建议添加函数来了解项目数量和项目类型，我可以认为您的问题比游戏设计更面向数据库