Hello once again! I've been working hard adding in new features, and it's that time of the week to highlight them.
This section will be technical. Sorry, but I don't know how to write about this in detail any other way. So to my non-technical readers, I'll put it into an analogy. It's like having a light switch connect to as many lights as you want through wiring. Except the light switch can be a button or lever on the ground, the light can be anything object in the game level, and the wiring is the sensor that checks the player to make sure he has the required item, skill level, or whatever else the sensor is asking for.
For my technical readers, I'll break it down further. All map objects derive from a class called "GameObject". In this, the most important variables are the "ID" integer, and the "isActive" bool. To take from the analogy above, any class that derives from this is a 'light'. It is what gets manipulated by the map sensors and logic gates. The ID integer is assigned manually in the map file, and should usually be unique. The isActive bool is used for determining if the object is being turned 'on' or 'off' by a sensor or gate. Default is always on.
Next, I have a class called "TriggerObject", which derives from "GameObject". The most important variables are the "isOn" bool, and other "TriggerID" or "OutputID" variables. Any class that derives from this is a "wire" or "switch". Currently, I have three classes that derive from TriggerObject: BaseSwitch, BaseSensor, and BaseLogic. The "BaseSwitch" is what checks for entity interaction with buttons, levers, etc. The sensor checks for certain statements, such as if the entity's health level > 30, or if the entity has X item. BaseLogic is the only way to output these values to a GameObject. It can have AND logic gates(up to 5 target sensors or triggers), OR logic gates, etc. If the AND logic gate bool values all equal true, then the outputID's (GameObject ID) "isActive" bool is set to true.
When the map is loaded, the sensor and logic gates are given a list<T> of all TriggerObjects and GameObjects, then it is iterated through to find an ID matching the "TriggerID" or "OutputID", then the local 'trigger' variable get the matching trigger reference. The best part is since all of these derive from TriggerObject, they can be mixed and matched to create infinite chains of sensors and logic gates, in any order. The only limitation is that the BaseSwitch has to be the very first in the chain, for entity interaction.
The best way to show this one is through a picture, so here it is. The shorter meters below are the current player's companions. Note that this is not completely finished. I'll fill in the diamond section when I have ideas what to put in there. I was thinking a current faction symbol and experience bar, but I'll have to think on that a little more.
Side-note: Companions can have companions that have companions that have companions [...]. Infinite companions. Unintentional, but it's a feature now. I'll definitely restrict it eventually, but it's fine at the moment.