Messages

I considered something like this before, but didn't do anything with the idea. Conversations could be built on the fly. When a regular conversation is entered, the game puts together a list of all the things the NPC might have to say- this could include permanent features of the NPC (such as a shopkeeper's shop), plot-related stuff (such as a mission offer), stuff related to other plots (if a mission requires you to round up three other pilots, this option would appear for any pilots you meet), stuff related to local events (such as asking info about the mecha bandits), or even general knowledge stuff (who are the Silver Knights?).

Once all the options are there, the game can select a greeting from the list of possible greetings that'll lead to each of the available paths. This will require having some kind of descriptive context for each of the "destinations", but that can be worked out. Returning to the "base state" will be handled just like the greeting, except that the message will be "Is there anything else you want to ask?" or whatnot.

Not all nodes need be enterable from the base state- maybe, every state will generate its own destinations, not just the first one.

If an NPC initiates conversation, the code for that could start the conversation at a specific point rather than doing a greeting. This would be important for such things as combat challenges.

Maybe some nodes could be marked as optional: In a given combat challenge, there's an optional surrender node where the NPC runs away, but this will only get added to the conversation if it somehow makes sense.

Just thinking out loud. I'm going to think about this some more.

I've written up conversations in the design doc. You can see it here:

https://docs.google.com/document/d/1dOmdtn0t9Et5emZxqSVC3sYMyTjq-C4NUfpXWE4ENd8/edit#heading=h.h1wopdhvonfe

The big issue I see in implementing this in Python is that there's a huge number of functions that need to be embedded in the structure. You could do this by making "exchange" a class and the functions its methods, but then almost every instance would need to be a new subclass.  Which is not a problem per se, of course, but I'm wondering how to structure things so that the code for a conversation is relatively easy to write and comprehend.

I've taken a look through Ren'Py, and what they've done is to add a scripting layer on top of Python which handles the messy bits. Their situation isn't exactly the same as GearHead's, though- the "conversations" there are actually the execution flow of the program, and they don't need to be serialized since there's no random element to their structure.

I've started writing a conversation module for use in the random story generation test program.

Check out the thread on GearHeadPrime, and also check the design doc every once in a while. Things are progressing, we just don't have much to show for it yet.

I started writing this description today. It probably needs a lot of work, but hopefully will give some idea of how the random story generation system functions.

https://docs.google.com/document/d/1dOmdtn0t9Et5emZxqSVC3sYMyTjq-C4NUfpXWE4ENd8/edit


Plots
    The GearHead world is dynamic- things change, new events and missions come up all the time. These events are handled with Plots. A Plot is basically a collection of scripts and locations that get added to the world temporarily, then when they’re finished get taken away again.
    Just as the gear is the basis for all physical objects, the plot is the basis for all narrative content. Typically a plot represents a single beat in a larger story. Plots have the following characteristics:

    A plot can request elements, which are things from the game world which are needed to carry out the plot.
        Characters. A character may be involved in only one plotline at a time.
        Scenes.
        Factions.
        Items.
    A plot can request child plots. A child will either be part of the same plotline, or the beginning of a new plotline. The tree formed is called a Story; see below for more details.
    A plot may create new characters or items, or may optionally have these things created automatically if an element search fails.
    Upon initialization, a plot may move any of its elements within the game world. When the plot terminates the element will be moved back to its original home.
    A plot has a scope, which may be global (encompassing the entire adventure) or local (encompassing a single city and its subscenes, or even a single scene)
    Within the plot’s scope, the plot can have scripts for all of the normal triggers (team movement, time steps, entering or leaving a scene, etc).
    A plot can define personas for any character it has as an element.
    A plot can define temporary scenes. When the plot terminates, these scenes are also deleted and any contents are returned to their original scenes.
    A plot can have both subplots
    A plot can be active or inactive. Only one plot of a given plotline can be active at once.

Story
    A story is a tree of interconnected plotlines. When created, the root plot is activated and is thereafter responsible for activating its children. Only one plot of a given plotline can be active at once, so if a plot activates a child which is within the same plotline it will be deactivated itself.
    A plot which is deactivated gets removed from the game. Any active child plots it has are moved to root. Any inactive child plots it has are eliminated. Temporary scenes and other resources it has are cleaned up.

Here is an example of a simple mecha combat mission:



There are two plotlines. The mission offer is activated first; this plot has a mission-giving NPC as an element. If the PC talks to the NPC, and accepts the mission, the combat subplot is activated. Once the combat is completed (either through a win, loss, or timeout) the Mission Offer plot will activate either the Victory or Loss subplots, as appropriate. As these are part of the same (red) plotline, the Mission Offer plot will then be eliminated.

If the mission-giving NPC dies the red plotline may be terminated immediately. If this happens before Combat is activated, then that plotline just gets disposed of. If it happens after Combat is activated, the PC will still be able to go and fight the combat, but there will be no-one to give a reward afterward.

From what you describe in your earlier post, all the things that are relevant to context are already available from the Gear object itself, so I don't think it makes sense for Gears to have string attributes encoding this same information. But you may be right that it makes sense to have a special way to specify requests.

You're right; looking over my post, I think I explained that part poorly. In Pascal GH, context requests are stored as strings, while gear contexts are generated from the gear's characteristics as they're needed. There's no need to store them as strings within a gear, and in fact that would be a very bad thing since a gear's context can change very often depending on its state.

That said, my inclination would be to keep the context stuff as simple as possible until the simple scheme gets too cumbersome. Hard to get simpler than if statements, and it's not hard to write if statements that can handle weighted preferences.

I'd be inclined to say, let's put together a random-plot builder and ultra-simple Adventure-style game that lets players walk through it. GearHead, after all, is that plus a giant-robot-fighting system that you have to get through to get to the next plot nodes. So if whatever scheme works in this simple context, it's probably fine.

OK.

Does it maybe make sense to develop such a thing on github, so that folks here can test out our own ideas against the game skeleton?

That's a great idea. I built a similar program when prototyping the GH2 plot system, but made the mistake of not making it interactive- the first plots all looked fine as stories but were far too linear/rigid when played as a game.

I've been playing around with a plot tester myself. My idea was that there'd be just a text console and a menu- or, a menu in the text console. No need to make a fancy UI. The game contains a simple world made up of three types: scenes (which act as containers for everything else), characters, and props (which model everything else).

Using the menu you can either move to a connected scene or interact with any character or prop in the same scene. Characters and props are pretty much the same thing, aside from having different contexts- you select their menu entry and they do something.

I will try to do a complete writeup of the plot system this afternoon, but basically: Plots are temporary additions to an adventure. Plots may request "elements"- characters, props, or scenes which are searched for and then associated with this plot. A character or prop associated with a plot will have its normal behavior redefined by the plot. Plots may spawn additional plots, resulting in plot branching.

Personally I think that context matching is such a common and important thing in GH that it's okay to have a special system to describe it, despite the learning curve. Of course writing the criteria as Python code is more powerful

One problem with doing context matching as an "if ...and...and...and" statement is that the context matcher should return a weighted value rather than a simple yes or no. I know this doesn't make the "if..." form impossible, but if we decide later to change the weighting scheme it does mean that everything needs to be individually altered.

I'll find some examples of context searches tomorrow.

I'm not sure how somethings like alignment and faction would be apropriate for eg. scene gears. Maybe 'creatures' or 'entities' would be an appropriate sub-category under which these things fall?

Cities typically belong to a government faction, and buildings can belong to factions as well- bases, factories, and so forth.

Ooh shiny. What is a development event? Something like a barrier before the next "phase" of a plot?

It's one of the special plots that involves a lancemate- for instance, the one where a junior LM asks the PC for advice, or the one where the LM finds a mission for the PC, or the one where a villainous LM's past enemies show up to enact revenge.

Generally these plots will advance the LM's personal story (as modeled by attitude, motivation, and personality traits) and provide the LM with a new talent or skill. They only occur once every 15 to 20 renown bumps, in order to more evenly distribute the events in time/among lancemates.

Quick thought: Perhaps this can be generalized into a real-valued weight score? Along with must and must-not haves: good to have → +1, bad to have → -1. Some plots trigger at certain renown levels, right? Handling renown as part of the weight score could make them more or less likely to trigger at higher renown. (thinking of it though, perhaps that's better done with a bell-curve-like probability match + a single renown value for the plot that represents both the point of highest probability of getting loaded and the average reward scaler to limit renown-explosion)

The context match score in GH2 is calculated multiplicatively- IIRC, every match doubles the weight.

A plot request includes a renown rating. There are five context tags corresponding to five renown levels: Green, Regular, Veteran, Elite, and Ace. These can be factored into the plot requirements like other context tags- a rat killing mission might require Green level, for instance, while a major assault might only occur at Veteran or above.

Currently the renown level for plots is based on the PC's renown, while the renown rating for quests is set when the adventure is generated. One example of this is in the mecha arenas, where different NPCs only show up at specific renown levels. Tama, for instance, is always either a Green or a Regular pilot. Vanda, on the other hand, will always be either Elite or Ace.

Edit- I just realized I left out one very important thing from the context documentation: it's possible to include an "or-list", a list of items for which one thing must be true. For instance, a plot might request renown level Green or Regular.

I don't remember who did the sprite, but you're right it doesn't match the monster. If you could make a lovecraftian monstrosity sprite that'd be great; otherwise, I guess the monster itself could be altered to fit the sprite.

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

The problem isn't the stats so much as the methods.

Imagine that a plot requires a door which doesn't open when used- instead it starts a conversation with the NPC behind the door, but then after talking the NPC unlocks the door and it functions normally from that point on. Or suppose it has a combination or puzzle lock. Or suppose a NPC has sent the PC to open a stuck door, and the PC can try a number of different tactics- use repair on it, beat it down, etc. These things would be very hard to generalize. Even worse, consider a computer terminal- in GH1 and GH2 just about every computer terminal has its own unique behavior, and this behavior only makes sense in the context of the plot/scene/whatever that spawned it.

I'll post a more thorough description of the context tags tomorrow. I'm not sure that anything I post tonight would make sense.

Silly nitpick: ooh, one module indented with tabs, and one with spaces. Equality for all? Personally I root for the tab indent side. I hope it wins.

Oops, I thought I had them both converted to spaces now... I'll fix that.

Some logic revolves around Gear.max_HP being positive, negative or zero. ... The gears.py code could be simplified a little by replacing a few for-loops with more 'pythonic' alternatives.

You're right. I was pretty much running on automatic there, translating from Pascal to Python. That shouldn't be hard to change.

(as much as I'm a curses fan) Wait, whut? So this is not for GH Prime? Cause weren't we going to abandon the idea of a text mode interface for GH Prime? I actually put some tileset code in my github to do (among others) something vaguely similiar to ToME's "ASCII" implementation.

It's just for trying stuff out now at the beginning, not for the final game.

Wasn't it a bit of a problem last time the interface of GH SDL version (which I think most users use) got constrained because of the way the curses code is written?

Not that I remember... the main issue with the ASCII interface was elevation levels, if I remember correctly.

Well, when it comes to an engine written in something like Python, significantly blurring the lines between scripting and the engine is a very viable way to do it.

Yes. I just want to know exactly what shape this is going to take. Let me get into some specific examples...

- There should be a list of content. When new content (a plot) is to be added to the game world, an appropriate choice is selected and matched to the adventure. My first thought was to make each plot a subclass of the basic plot type and then instantiate it to add it to the world. Problem #1: Plot insertion often fails, if the plot can't allocate the resources (characters, scenes) it needs. Instantiation doesn't normally fail. Problem #2: Plots can contain their own content, such as the proverbial customized door. If this content gets defined as a class (inheriting from some other class) then it can't be properly contained by the plot class or else it won't be properly serializable. I guess this isn't that great a problem, but it is kind of ugly.

- A common task of the story generator is to search for things based on context. In GH:Pascal, the context is a string containing lots of descriptions. Each description is of the form [gear identifier]:[context tag], where "gear identifier" somehow identifies the thing this context belongs to and "context tag" tells us something about it. For instance, "@:ADVEN" would tell the story generator that the part currently being examined is an adventurer. Instead of using strings for context lists, in Python it would make sense to use a set. However, how to construct the individual context descriptions? They could be strings, as in GH:Pascal, but this seems inelegant and it is definitely prone to errors.

I put together the start of a Gears module in Python, and Peridot went ahead and improved/expanded it. I've also translated the GH menus to Python with Curses; this must be the fourth or fifth language rpgmenus has been translated into (AMOS, PCQ Pascal, some kind of Amiga BASIC, FreePascal... I think there have been others). Both files have been attached. Let me know what you think.

The thing I'm worried about, though, is scripting. The two things that REALLY worry me are 1) I don't yet know how it's going to work, and 2) I don't know if adding content is going to be any easier than with GHLua.

So, my next Python project will be to create a random plot/scripting system. Before I have a game for it. Because that makes perfect sense.

I'll be sticking to the GearHead specifications (which means that I first have to fully define those specifications), so with any luck it should be easy to just drop these modules into the game with little modification.

The test program will have three types of objects: scenes, characters, and props. Using the menu system you will be able to navigate through the scenes and interact with the characters/props, just like the world's most primitive visual novel (without visuals). After the world is generated additional Plots can be loaded; these alter the behavior of scenes, characters, and props currently in the world, or may add additional ones to the world.

Automatically pruning the users list didn't seem to work, so I manually deleted all the members who haven't yet posted.

I've locked registration following a spam explosion. If anybody wants to register before this gets fixed, send an email to me- you can find my address at the GearHeadRPG page as well as AtaraxiaTheatre.

Nice!