I can't say anything about these particular two games, because they aren't open source and I wasn't involved in their development.
But usually when you have game mechanics with a large number of entities each doing relatively simple computations, then you usually use an Entity - Component - System architecture.
The basic gist is this:
You divide the data ...
Doom is divided into two components:
The game engine.
The game data.
Of these, the source code which was released is for the game engine only, and as the readme notes, only for the Linux version, as id Software had used third-party sound code for the DOS version, which they were unable to open-source.
The game data is contained in WAD files and includes ...
You need the doom.wad file that came with it. Alternatively, you can find total conversion mods for free various places online and then you don’t need anything. Although in that case you are looking at an entirely different game, just running on the same engine.
Myself, I'd let the InventoryUI script own the interaction with the inventory.
When a player opens the InventoryUI, you call something like InventoryUI.ShowInventoryFor(PlayerCharacter character).
This procedure handles any initial setup of the menu (populating the slots, etc.) and caches the character it was given as its currentUser member variable.
so ... I can probably speak to your example, since I'm the primary author of the Jackbox Games multiplayer server, which as it turns out ... is written entirely in Go!
Since there's no simulation to run, there's no need for a tick since the game state does not update without user action. I do have a ticker for some other thing. You want to keep all of this ...