After finishing yesterday’s post about generating images for user-combined substrate items I realized that I never really provided an explanation about how items work in general (or how they work for now, anyway).

We have a few different item-associated models in Gastropoda. They are (model followed by associated table in parinetheses)

  • ItemType (item_types)
  • ItemTemplate (item_templates)
  • ItemUserTemplate (item_user_templates)
  • ItemNutrition (item_nutrition)
  • ItemUserNutrition (item_user_nutrition)
  • Item (items)

Item types are very generic. Right now I have the following item types:

  • consumable
  • decorative
  • substrate
  • jar
  • breeding
  • terrain
  • training
  • misc

ItemTemplates are pregenerated item…templates that can exist in the world. Note that these are not the existing items in the world, they are just things that could be instantiated into in-world items. Each item template is associated with an item type. Right now they are (template name, item type):

  • Lettuce Leaf (consumable)
  • Medium Sweet Potato (consumable)
  • Spark (decorative)
  • Basic Small Jar (jar)
  • Enthusiast Small Jar (jar)
  • 7-Day Fertility Spray (breeding)
  • Grooved Glass 2mm (terrain)
  • Attractor (training)
  • Garden Dirt (substrate)
  • 1kg Pure Fine Sand (substrate)
  • 1kg Dry Oak Leaves (substrate)

ItemTemplates can have an associated nutrition template. All consumables and substrate items have their own entries in the item_nutrition table.

Items are the actual instances of these item templates existing in the world. They are usually created when stores are restocked or when users mix their own substrate. An item entry consists of basic information about the instance, like:

  • itemID
  • templateID
  • ownerID
  • jarID
  • bitesTaken
  • posX
  • posY
  • isUserTemplate

Which brings me to user templates. Any mixing of substrate creates a new item template, or rather an ItemUserTemplate, and saves it in the item_user_templates table. Substrate also gets its own nutrition entry, in item_user_nutrition. This allows us to easily distinguish user generated items from basic items in the simulation and treat them differently. Then on an instance of an item, if isUserTemplate is true, we know to look for associated templates in the user tables and not the regular tables.

That’s pretty much it. The most annoying part about this setup is that there are so many inter-table dependencies. An item without a template entry is a broken item. A consumable without a template that has an associated nutrition record is broken. Etc…