Standardized data storage

[Prophet]

Branched from this thread.

I felt this topic deserved its own discussion.

The problems are:

1. It is difficult to represent characters across systems. For example, anything that happens to Kate in Rigel Aurelius should be reflected when you meet her in Heretic. Right now, this information is stored in global variables attached to a certain ship class, but there is no consistent way of doing this (e.g., Admiral Decker's status is stored in a different way).

Perhaps we need a way to track objects across systems in a consistent way. Every character in the game (Kate, Decker, etc.) could be represented as an object (generally a ship) and it would be possible to (e.g.) inquire about their status (dead, alive, etc.)

2. Another problem is state representation. At any point in time, Kate is in one of several states: alive and waiting for the player; mad at the player; dead; etc.

At each state, Kate should have different dialog with the player (and transitions to other states should depend on the current state). But today this state representation is spread out over multiple places. Sometimes it is at a station that the player docks at; sometimes it is at Kate's ships; etc.

It would be great if there were a single point at which one could program Kate's entire state-machine and all her responses and actions.

3. Ultimately, what I'd like to do is give characters more autonomy in how they respond to events. For example, right now the Kate storyline is entirely hard-coded. But what if we could program general goals and have the character attempt to accomplish those goals in whatever way possible. For example, if the player refuses to help Kate, perhaps she hires someone else.

This is extremely difficult to program correctly, but it might open up some very interesting interactions.

Personally, I use staticData quite often to store data because it will take virtually any code and is easily accessible anywhere. A ship type is preferable because of the number of events that can be associated with it and it can be queried with the typGet function.

If the data storage were to be standardized, I would like that a new attribute be created; +Plot would be fine, to be placed on the ships so that they can be easily filtered and queried.

[george moromisato]

Also, I'm thinking about Atarlost's suggestion of an NPC Type that contains all the script and logic for the character, no matter where the character is.

That implies that we need more events to control some of the docking screen logic.

For example, imagine that we want the player to encounter Kate when she is at (e.g.) the First Contact Monument (FCM). Rather than adding code to the FCM, we would add code to Kate's type. Something like:

Code: Select all

<Events>
   <OnPlayerDocked>
      (if (and 
            {player docked at FCM}
            {kate is not dead}
            {kate is friendly}
            )
         {show Kate's DockScreen}
         )
   </OnPlayerDocked>
</Events>

The above would bring up Kate's dock screen (defined in the NPC type) even though the player has docked at a completely different station.

Ideally, of course, any type could "inject" a dock screen on any other object. This would also help for stations that give missions (like the Fleet mission to deliver cargo).

I don't know if the syntax above is right or not--would love opinions.

[Prophet]

In that context a new type would be preferable so the events could listen for their trigger conditions rather than a ship or station that must be created and then register with objects via objRegisterForEvents.

Code: Select all

<PlotType UNID="ptKateMorgental"
  name="Kate Morgental plot thread"
  level="4"
  attributes="battleArena, Plot"
  >
  <InitialData>
    ;; run at game start to initialize variables
  </InitialData>

  <StaticData>
    ;; available for easy readability
  </StaticData>

  <Events>
    ;; POPULATED VARIABLES
    ;; gSource = object that called the event
    ;; gItem   = this plotType
    ;; other variables set as per event type ie: aDockTarget, aDestroyer etc.
  </Events>

  <Dockscreens>
    ;; for smaller plot threads keeping the dockscreen within this type may be better than a standalone.
  </Dockscreens>

</PlotType>

The level and attributes could be used for generic missions like miner rescue or simple escort missions where a station could query all +plot type items, filter by level and a specific attribute and generate a mission or plot encounter.

[Arisaya]

Why do you need a level for a plottype?

[digdug]

Prophet, isn't a virtual station able to provide what you just pseudo-coded ?
Unless I'm wrong and virtual stations are localized in the system. If so, the PlotType looks like a sort of global station, with the data available in any system.

[Prophet]

Virtual station can be used in the way that I've shown here, as can virtual ships, but in order to hook into events they must be created, ideally really far out or with a 1x1 pixel image. Creating the object also pins it to the system that you're in and the data must be stored on the type to be accessible in other systems.

For the new type, hopefully the events would be able to trigger without creating an object from the type.


The level isn't necessary but could be useful for generic missions. You wouldn't want a "save the borer from the scary centauri raiders" mission in Dantalion, and the level would be an easy way to filter.

[Atarlost]

If you're doing generic missions you don't want a level, you want a rarity curve like stations have.

[Arisaya]

Yeah, a rarity curve like "cuuv- -----" for your save borer example would be what you want

[Song]

'Save the Borer from the three phobos dreadnoughts" should appeal to Wolfy.