View Format: Multi-Page Single Page

Simple Enemy Forge

Generate Complete Enemy Databases, Squads, Spawn Tables, and More in Minutes.

Simple Item Forge Integration

Simple Enemy Forge has optional integration with Simple Item Forge (SIF), sold separately. When both packages are installed in the same project, the Enemy Forge automatically detects SIF and unlocks loot table linking on enemies. No manual configuration is required — just import both packages and the features appear.

Completely optional. Simple Enemy Forge works perfectly on its own. The SIF integration adds loot table references, but all core functionality (enemies, squads, spawn tables, scaling, waves, behaviors, factions, schema export, custom editors) works without SIF installed. You can add or remove SIF at any time with zero compilation errors.
Loot tables belong to SIF. Simple Item Forge defines loot tables via its Loot Forge wizard. Simple Enemy Forge does not create loot tables — it only references them by code. Each enemy can be linked to a SIF loot table code so your game logic knows which drop table to roll when the enemy is defeated.

Features Enabled by SIF

When SIF is detected, two additional fields appear on each enemy:

Loot Table Code

A string field with a dropdown populated from your SIF loot database. Select which loot table this enemy should use for drops. Example: GOBLIN_LOOT, BOSS_DRAGON_LOOT. The code is stored as a plain string, so it remains valid even if SIF is removed.

Loot Table Reference

A direct ScriptableObject reference to the SIF loot table asset. Drag the loot table .asset file directly from your project. This gives your game code direct access to the loot table object at runtime without needing to look it up by code.

Where SIF Features Appear

Location What Changes
Enemy Forge — Step 1 (Setup) A “Simple Item Forge Integration” section appears, confirming SIF is detected. An ObjectField lets you assign your SIF Loot Database, which populates the loot table code dropdown in Step 3.
Enemy Forge — Step 3 (Enemies) Each enemy gets a Loot Table section with two fields: a dropdown for loot table code (populated from the linked SIF database) and an ObjectField for direct loot table asset reference.
Generated Custom Editors The generated Inspector editor shows loot table fields for each enemy. The code field uses a dropdown when SIF is available; the ObjectField uses runtime Type.GetType() to filter the picker to SIF loot data source assets, automatically adapting when SIF is installed or uninstalled without requiring regeneration.

Detection Lifecycle

SIF detection follows the same automatic pattern as SAF detection. An [InitializeOnLoad] detector runs on every domain reload and uses reflection only — no hard assembly references.

Installing SIF

1 Import the SIF package
Import Simple Item Forge into your project (Asset Store or .unitypackage). Unity detects new scripts and triggers compilation.
2 Domain reload → Detector fires
After compilation, Unity performs a domain reload. The [InitializeOnLoad] attribute on ItemForgeDetector causes it to run automatically. It calls Type.GetType("SimpleItemForge.ISimpleLootDataSource, SimpleItemForge.Runtime") to probe for SIF’s loot types.
3 Define symbol added
SIF types are found. The detector adds SIMPLE_ITEM_FORGE to Player Settings → Scripting Define Symbols. It also populates SIFBridge with the resolved LootDataSourceType, ItemDataSourceType, and reflection-built delegates for GetLootTableCodes and GetItemCodes.
4 Recompilation → SIF features appear
The new define triggers another compilation. Editor code gated behind SIFBridge.IsAvailable checks now activates. The loot table fields appear in the Enemy Forge wizard and generated editors.

Removing SIF

1 Delete the SIF package
Remove Simple Item Forge from your project. Unity detects the missing scripts and triggers compilation.
2 Domain reload → Detector fires again
The same [InitializeOnLoad] detector runs. This time, Type.GetType() returns null — SIF types are no longer present.
3 Define symbol removed
The detector removes SIMPLE_ITEM_FORGE from the scripting defines. It also clears all SIFBridge properties (sets types and delegates to null).
4 Recompilation → Zero errors
The removed define causes another compilation. All SIF-gated editor code is excluded. The loot table sections disappear from the wizard. No compilation errors occur because the runtime fields use plain types (see below).

The SIFBridge Pattern

Simple Enemy Forge never has a hard assembly reference to Simple Item Forge. Instead, all editor code accesses SIF through a static bridge class:

Component Role
ItemForgeDetector [InitializeOnLoad] class that probes for SIF types via Type.GetType(). If found, populates SIFBridge with resolved types and reflection-built delegates. If not found, clears everything. Also manages the SIMPLE_ITEM_FORGE define symbol.
SIFBridge Static class with properties: LootDataSourceType (System.Type), ItemDataSourceType (System.Type), GetLootTableCodes (delegate that returns string[] of loot table codes from a loot database SO), GetItemCodes (delegate that returns string[] of item codes), and IsAvailable (bool). All wizard and editor code checks SIFBridge.IsAvailable before showing loot table UI.

This pattern means:

  • No using SimpleItemForge; statements in the main editor code
  • No assembly definition references to SIF assemblies
  • No conditional assemblies that might fail to recompile
  • Clean compilation in both directions (install and remove)

Runtime Fields

The SimpleEnemyDefinition struct always includes these loot-related fields, regardless of whether SIF is installed:

Field Type Purpose
lootTableCode string The code identifying which loot table to use (e.g., "GOBLIN_LOOT"). Plain string — always compiles.
lootTable ScriptableObject Direct reference to the SIF loot table asset. Stored as a generic ScriptableObject — always compiles.

Because both fields use plain Unity types (string and ScriptableObject), the generated database class always compiles regardless of whether SIF is present. This is what makes the install/remove cycle error-free.

Runtime access: Your game code can always read enemy.lootTableCode (a string) and enemy.lootTable (a ScriptableObject). If SIF is installed, you can cast enemy.lootTable to ISimpleLootDataSource for full loot table API access. If SIF is not installed, the string is still available for your own loot system to interpret.

Generated Database Behavior

Understanding how generated databases behave across SIF install/remove cycles:

Generated With SIF Installed

When you generate an Enemy Database while SIF is available and loot tables are assigned:

  • Each enemy’s lootTableCode is set to the selected code string
  • Each enemy’s lootTable holds a reference to the SIF loot table .asset file
  • The generated custom editor shows a dropdown for code selection and an ObjectField for direct reference

After Removing SIF

  • The generated database still compiles — both fields are plain Unity types
  • Loot table codes are preserved — strings survive regardless of SIF status
  • Loot table asset references are preserved if the .asset files still exist
  • The custom editor hides loot table UI — the dropdown and ObjectField disappear, but the data remains in the serialized asset
  • Asset references become null if the loot table .asset files were removed along with SIF

Regenerating Without SIF

If you open the Enemy Forge wizard and regenerate without SIF installed:

  • The wizard has no loot table UI, so no loot table codes or references can be assigned
  • Generated enemies will have empty lootTableCode and null lootTable
  • The previous .asset data is overwritten
  • If you want to preserve loot table data, do not regenerate after removing SIF
Safe round-trip: Install SIF → link loot tables → remove SIF → everything compiles → reinstall SIF → data still in the asset. As long as you don’t regenerate while SIF is absent, your loot table data survives the round-trip.

Troubleshooting

SIF features not appearing after import

  • Check installation — Ensure Simple Item Forge is imported in the same project (not a different project or a Package Manager reference to a missing path)
  • Check the define symbol — Open Player Settings → Scripting Define Symbols and verify SIMPLE_ITEM_FORGE is listed. If not, the detector may not have run yet.
  • Force a recompile — Try Assets → Reimport All or make a trivial edit to any script to trigger compilation and a domain reload.
  • Check the Console — If SIF itself has compilation errors, the detector cannot find its types. Fix any SIF errors first.

Loot table dropdown is empty

  • Assign the loot database — In Enemy Forge Step 1, the SIF Integration section has an ObjectField for your loot database. Assign a generated SIF loot database asset. The dropdown in Step 3 is populated from this linked database.
  • Generate the SIF loot database first — The SIF Loot Forge wizard must have been used to generate at least one loot database with loot table entries before the dropdown can be populated.

SIF features not disappearing after removal

  • Check the define symbol — If SIMPLE_ITEM_FORGE is still in Scripting Define Symbols after deleting SIF, remove it manually and recompile.
  • Force a domain reload — The detector runs on domain reload. If Unity didn’t trigger one, reimport a script or restart Unity.

Compilation errors after removing SIF

This should never happen if Simple Enemy Forge is the only package using SIF. If you see errors:

  • Check that SIMPLE_ITEM_FORGE was removed from Scripting Define Symbols
  • Check for other packages or custom scripts that may have hard references to SIF types
  • Ensure you deleted the entire SIF package, not just parts of it (partial deletion can leave broken assembly definitions)