Second: define the custom methods inside the plot subclass (as static methods). Let the plot's initiation code create the Computer and fill its trigger function variables with references to those static methods of the plot class. In serial format, the Computer instance contains the typename/unique identifier of the plot class that contains the custom functions, each function's name, and the action that triggers each of those functions. It wouldn't matter if there is more than one instance of a plot running, since the special functions are static methods, and state information are all contained in the specific instances of plot and Computer.
I think this is the better solution- after all, we want to make it easier for people to add content, and splitting things up between files would be a pain (not to mention a maintenance nightmare).
Are there any UI extensions for PyGame? That might be a good thing to look for, especially if it also included text entry boxes and other knick-knacks. Then again, maybe the game could be written with a widget toolkit like GTK or whatever the one that comes with Python by default is called. It's not like we're using high-end graphics here.
I typed up the context system at the GearHead Prime design doc. Here's a copy of that:Context
Every gear has a list of attributes which may be relevant for content selection; these attributes are the gear’s context. These tags include the following information:
The existence or nonexistence of the gear in question.
The gear’s faction, or lack thereof. Also, whether the gear belongs to the same faction as the PC or not.
The gear’s alignment with regards to the PC: enemy, ally, or neutral.
The type of the gear: scene, character, monster, item, faction...
For NPCs, there are additional attributes:
The job type of the NPC: Adventurer, Academic, Corporate, etc.
The NPC’s attitude and motivation.
The NPC’s personality traits: Extraverted or Intraverted, Cheerful or Grim, Aggressive or Passive.
The NPC’s governing virtue: Justice, Peace, Fellowship, Duty, or Glory.
The NPC’s personal relationship with the PC: friend, lancemate, or nemesis.
Whether the NPC is a Major or Minor NPC.
Whether the NPC is Ready to be featured in a plot.
Whether the NPC is currently a member of the PC’s lance.
Whether a lancemate NPC is ready for a development event.
For Factions, there are additional attributes:
The faction’s type: Corporate, Military, Criminal, etc...
The faction’s governing virtues.
For Scenes, there are additional attributes:
The scene’s type: City, Building, Dungeon, etc...
The scene’s environment: Mountains, Forest, Wasteland, Deep Space, etc...
The scene’s terrain: Space, Ground, or Underwater.
The scene’s world: Earth, L5, L4, Luna, Mars...
To generate content, it will usually be necessary to examine the context of several gears at once. For instance, to generate a new subplot we need to examine the context of the city where the plot will take place, the PC’s faction, any characters or factions involved in the parent plot... to keep everything straight each context attribute should be connected to an identifier telling which gear it belongs to.
In classic GH this was handled by making the identifiers single chars and the attributes five char strings, separated by a colon. So the context “P:L5LAW P:POLIC P:PCFAC P:ALLY_ P:++ E:REDMA E:CRIME E:++ E:ENEMY” would tell us about the PC’s faction (P) and the enemy faction (E).
In new GH, it doesn’t really matter how this is implemented as long as the functionality remains. It would probably be best to make the identifiers more readable.Context Search
Often we will need to check the context to make sure it matches some condition we’ve set. For instance, a certain plot might only load while the player is on Earth, or if the enemy faction is Criminal.
When we have a list of options to choose from, not all of them are given equal weight. The more context tags that match the more likely a plot is to be chosen. This is because a context search with a lot of tags is much more specific than one with few tags, and so the situation is likely to come up less often.
There are three options for each attribute in the context search:
Must Have: This tag must exist in the target context, or the search fails.
Must Not Have: This tag must not exist in the target context, or the search fails.
Good to Have: If this tag exists in the target context, the likelihood of selecting this content is increased. If this tag doesn’t exist there is no effect.
For instance, a plot which requires "S:EARTH ~S:FEDER -S:IPSHIL" could only occur on Earth (Must Have), is more likely to happen within the Federation (Good to Have), but will never happen in Ipshil (Must Not Have).Edit-
Here is the link to the design doc, in progress:https://docs.google.com/document/d/1dOmdtn0t9Et5emZxqSVC3sYMyTjq-C4NUfpXWE4ENd8/edit