Forums » Suggestions
Request for Comments: Persistent Event "Missions"
To anyone unfamiliar, Vendetta Online's missions are made using a web-based mission editor, which is also available to any player who joins the Player Contribution Corps, or PCC, a sub-group of players who are interested in directly creating content for the game.
Players have created a great many missions, over the years, and there's a separate community and forum base where this process may be discussed.
Everything discussed below should now be available to all PCC members.
This announcement is about an Expansion of the Mission Editor
Basically, instead of having only linear missions available through the formal Mission System within the game, the concept was instead to be able to create Persistent Events, which could be spawned anywhere in the game, at any time. Players might choose to engage with this "persistent content", or might not, and the presence of the content in the game would not necessarily hinge on any particular player (as it does with actual Missions, whose state is scrubbed when a player logs off).
The basic "target" prototype for this concept was the "Unaligned Pirates", the aggressive NPCs who prowl around grayspace, attacking those who may pass through wormhole sectors. As experienced players will know: Destroying the "Unrats" is a bit of process.. you have to do enough damage to one of the pirates (but not kill them) so you can chase them back to their "base ship" and then destroy that base-ship. The pirates and their "base ship" will eventually respawn, after a few randomized hours, and re-appear in some other randomized sector. So on and so forth.
The Unrats were implemented in hand-written Lua, which while completely fine as a way of implementing gameplay, is not the most trivially accessible, or scalable, and does have some maintenance challenges that come with it. Missions, on the other hand, are a kind of cleverly "compiled" Lua code which can be easily changed, updated and removed, with creation and modification via the Mission Editor, which is generally more "accessible" to new people than learning Lua syntax.
What Are Persistent Events?
The overall concept here is simply to have "Game Content" that periodically appears, and does something. That "something" could have a lot of different examples, like those below, starting on the small side:
- A single Dentek collector is spawned in a wormhole sector, and mines an asteroid for an hour, and then leaves and vanishes. If that Dentek collector is destroyed by a player, a "distress call" is sent, and some angry Hive NPCs appear and attack whomever they find hostile in the sector. If those NPCs are destroyed, some valuable goods are dropped. This "test-event" is currently in production, in Odia.
..Or something that crosses multple sectors:
- A specialty "Ace NPC" that is extra tough could be spawned (the Mission Editor now allows a degree of NPC customization), who wanders around through several different sectors, before eventually vanishing if not attacked by a player. The specialty NPC has unusual and rare drops, but only if killed by a player.
..Or to something a bit more complex:
- A "disabled" Trident is spawned in a sector, and sends out a distress call system-wide asking for assistance in defending themselves from pirates. Player(s) may show up and help defend the Trident, or it might be destroyed, which might result in different outcomes.
..Or something more unexpected:
- A Hive "scouting party" is seen roaming around a system of grayspace, for a period of time. If the scouting party is not destroyed within X period of time, the Hive begins an aggressive invasion of that system, including launching attacks on multiple stations. Stopping the invasion "waves" requires locating and destroying the hive base ships in random sector locations in the system.
..Up to something much more complex:
- A capship belonging to "Corporation A" sends out a distress call, while in a sector claimed by a rival "Corporation B", who attacks them, accusing them of stealing mineral resources from their territory. Destruction of the "Corporation A" capship results in a major escalation between the two corporations, causing other Events to be started over the coming days and weeks, in which they each launch fleets to attack one another's convoys and even stations.
Basically, there are a lot of options for what one could create.
And keep in mind, this is a very "early" version of the system, it has only been functional for a week or two. There is a lot of functionality we're still working on adding, like the ability to "keep track of player participation", both for game-design reasons as well as dividing up Rewards and so on.
There's a great deal of potential for this to be a useful system for a lot of different cases, like combat-driven players who generate their own income without trading, who could respond to distress calls and other combative needs that periodically show up around the galaxy. These are not "solo-specific" Events, the way that Missions usually are, so there's no reason there can't be a dozen people participating (or frankly, hundreds), although scale would have to be considered in the Event design.
It's actually not that far-fetched for something like the entire Kourier-based "Hive" system to be re-created within the Persistent Event system, wherein Hives expand across space and conquer territory until they are pushed back, and decisions around "expansion" are made based on relative wins and losses by the respective Hive.
But, for now, one should Start Simple..
We've fixed a lot of bugs in the last few weeks, but I'm sure others are "waiting to be discovered", and there are plenty of challenges around limitations of the system, which have to be considered during design. Especially around things like "cleaning up the Event" and making sure things like stale NPCs are not left to wander to-and-fro (and potentially multiply, and then be a huge problem).
There are some unique capabilities that have been added to the system, like:
- Persistent Events may spawn other Events, by ID. Meaning that a tree-structure of different Events may form a large and complex whole.
- NPCs with unusual capabilities (like shields) may be created, and with semi-customized names.
- NPCs can now drop an item, to give a "general reward to whomever picks up the item". We don't yet have discrete player-participation or direct rewarding.
- Persistent Events have preset concurrency (defaults to 1 instance at a time).
- Persistent Events have a preset time limit (defaults to 4 hours), after which the Event is killed off and cleaned up.
- Objectives like "Destroy N in Group" can be completed outside of the Stage where they're originally defined.
- Objectives like "Destroy one ship.." now have "only players can kill" options, so Persistent content is not advanced by, say, a convoy escort killing a Dentek collector.
Accessing the Editor
If one looks at the bottom of the PCC "main page", where one sees the overall "status" of existing missions and those in development, there is a button near the bottom (right above the Examples) called "Create new mission", which lets one build a new mission from scratch. Next to that, now is another button called "Create new Event".
By way of an Example, any PCC member can look at the (one) Event currently in production, mission 3643 - "Face the Heavy Fennus R-18 Guardian and Friends".
Editor Mechanics and Functionality
These are the current (May 24th 2024) specifics of using the Editor. I imagine these will fluctuate soon, but in due course the documentation will be posted on PCC Forum, rather than here. This is only being shown as more of an announcement.
Instructions
Instead of Requirements, the events have a Schedule. If no schedule is added to the event, it doesn't run. It can be manually started with the /oper /startevent <eventid> command, explained later.
To create an event, click on the 'Create new Event' link at the bottom of the list of the missions you're working on. The name, description, and long description are not displayed to the user, so you can use them for notes.
Timers and NPCs will be automatically cleaned up when the mission ends or is aborted. If, for whatever reason, the NPCs are not cleaned up, you can /msg them go away to make them leave.
If an event is currently running when it is saved, the event will need to be manually aborted for the changes to be applied.
Scheduling
There are three schedule entries, and one event lifespan entry.
* Event Lifespan is how long the event runs before it is killed off (aborted). The format is HH:MM:SS.
* Event begin time (UTC): Defines when the event should be started.
- If the time is in the past and no periodicity is defined, it is started immediately.
- If the time is in the past and a periodicity is defined, then it calculates the next time from the start time using the period. For example, if the begin time is 01:00:00, the periodicity is 15 minutes, and the current time is 01:05:00, the event will be scheduled for 01:15:00.
* Concurrency: Defines how many of the event can be running at once. Setting it to 1 is the same as the "Run only one at a time" flag. The flag overrides the count.
- Defaults to no limit if it is not defined.
* Periodicity: Defines how much time before the event is restarted, and whether the time begins when the event ends or is started. The start time can be randomized up to the indicated length.
- Defaults to only running once if it is not defined.
If no schedule info is defined, the event can still be manually scheduled or started using /oper commands.
Oper Commands
There are a series of /oper commands that can be used to start, abort, schedule, cancel a scheduled event(s). The <event number> is the number of the event in the Mission/Event Editor. These commands are available to PCC members, on the Test Server.
/oper /runningevents
- Displays the running events, when they started, and how long ago that was, and displays scheduled events and when they are scheduled and how far from now.
- It also displays an <event id> of the running or scheduled event, so a single instance of an event can be aborted or cancelled.
/oper /startevent <event number>
- Immediately starts an event if it doesn't exceed the defined concurrency.
/oper /abortevent <event number>
- Aborts all running instances of the given event.
/oper /cancelevents <event number>
- Cancels all schedules of the given event.
/oper /cancelevent <event number> <event id>
- Cancels a single scheduled event. <event id> is displayed with the /runningevents command.
/oper /abortoneevent <event number> <event id>
- Aborts a single running instance of an event.
/oper /scheduleevent <event number> [+]HH:MM:SS
- Schedules an event for the given time in UTC (or from the current time if + is included) for the same day. If the time is in the past, it is moved to the next day. For example, if it is currently 05:00:00 UTC and you schedule an event for 01:00:00 UTC, it is scheduled for 01:00:00 UTC the next day (so 20 hours later). If you schedule it for 06:00:00 UTC, it will be scheduled to start in one hour.
- Two digits much be used for each value, so 00:00:00 would be midnight UTC.
Players have created a great many missions, over the years, and there's a separate community and forum base where this process may be discussed.
Everything discussed below should now be available to all PCC members.
This announcement is about an Expansion of the Mission Editor
Basically, instead of having only linear missions available through the formal Mission System within the game, the concept was instead to be able to create Persistent Events, which could be spawned anywhere in the game, at any time. Players might choose to engage with this "persistent content", or might not, and the presence of the content in the game would not necessarily hinge on any particular player (as it does with actual Missions, whose state is scrubbed when a player logs off).
The basic "target" prototype for this concept was the "Unaligned Pirates", the aggressive NPCs who prowl around grayspace, attacking those who may pass through wormhole sectors. As experienced players will know: Destroying the "Unrats" is a bit of process.. you have to do enough damage to one of the pirates (but not kill them) so you can chase them back to their "base ship" and then destroy that base-ship. The pirates and their "base ship" will eventually respawn, after a few randomized hours, and re-appear in some other randomized sector. So on and so forth.
The Unrats were implemented in hand-written Lua, which while completely fine as a way of implementing gameplay, is not the most trivially accessible, or scalable, and does have some maintenance challenges that come with it. Missions, on the other hand, are a kind of cleverly "compiled" Lua code which can be easily changed, updated and removed, with creation and modification via the Mission Editor, which is generally more "accessible" to new people than learning Lua syntax.
What Are Persistent Events?
The overall concept here is simply to have "Game Content" that periodically appears, and does something. That "something" could have a lot of different examples, like those below, starting on the small side:
- A single Dentek collector is spawned in a wormhole sector, and mines an asteroid for an hour, and then leaves and vanishes. If that Dentek collector is destroyed by a player, a "distress call" is sent, and some angry Hive NPCs appear and attack whomever they find hostile in the sector. If those NPCs are destroyed, some valuable goods are dropped. This "test-event" is currently in production, in Odia.
..Or something that crosses multple sectors:
- A specialty "Ace NPC" that is extra tough could be spawned (the Mission Editor now allows a degree of NPC customization), who wanders around through several different sectors, before eventually vanishing if not attacked by a player. The specialty NPC has unusual and rare drops, but only if killed by a player.
..Or to something a bit more complex:
- A "disabled" Trident is spawned in a sector, and sends out a distress call system-wide asking for assistance in defending themselves from pirates. Player(s) may show up and help defend the Trident, or it might be destroyed, which might result in different outcomes.
..Or something more unexpected:
- A Hive "scouting party" is seen roaming around a system of grayspace, for a period of time. If the scouting party is not destroyed within X period of time, the Hive begins an aggressive invasion of that system, including launching attacks on multiple stations. Stopping the invasion "waves" requires locating and destroying the hive base ships in random sector locations in the system.
..Up to something much more complex:
- A capship belonging to "Corporation A" sends out a distress call, while in a sector claimed by a rival "Corporation B", who attacks them, accusing them of stealing mineral resources from their territory. Destruction of the "Corporation A" capship results in a major escalation between the two corporations, causing other Events to be started over the coming days and weeks, in which they each launch fleets to attack one another's convoys and even stations.
Basically, there are a lot of options for what one could create.
And keep in mind, this is a very "early" version of the system, it has only been functional for a week or two. There is a lot of functionality we're still working on adding, like the ability to "keep track of player participation", both for game-design reasons as well as dividing up Rewards and so on.
There's a great deal of potential for this to be a useful system for a lot of different cases, like combat-driven players who generate their own income without trading, who could respond to distress calls and other combative needs that periodically show up around the galaxy. These are not "solo-specific" Events, the way that Missions usually are, so there's no reason there can't be a dozen people participating (or frankly, hundreds), although scale would have to be considered in the Event design.
It's actually not that far-fetched for something like the entire Kourier-based "Hive" system to be re-created within the Persistent Event system, wherein Hives expand across space and conquer territory until they are pushed back, and decisions around "expansion" are made based on relative wins and losses by the respective Hive.
But, for now, one should Start Simple..
We've fixed a lot of bugs in the last few weeks, but I'm sure others are "waiting to be discovered", and there are plenty of challenges around limitations of the system, which have to be considered during design. Especially around things like "cleaning up the Event" and making sure things like stale NPCs are not left to wander to-and-fro (and potentially multiply, and then be a huge problem).
There are some unique capabilities that have been added to the system, like:
- Persistent Events may spawn other Events, by ID. Meaning that a tree-structure of different Events may form a large and complex whole.
- NPCs with unusual capabilities (like shields) may be created, and with semi-customized names.
- NPCs can now drop an item, to give a "general reward to whomever picks up the item". We don't yet have discrete player-participation or direct rewarding.
- Persistent Events have preset concurrency (defaults to 1 instance at a time).
- Persistent Events have a preset time limit (defaults to 4 hours), after which the Event is killed off and cleaned up.
- Objectives like "Destroy N in Group" can be completed outside of the Stage where they're originally defined.
- Objectives like "Destroy one ship.." now have "only players can kill" options, so Persistent content is not advanced by, say, a convoy escort killing a Dentek collector.
Accessing the Editor
If one looks at the bottom of the PCC "main page", where one sees the overall "status" of existing missions and those in development, there is a button near the bottom (right above the Examples) called "Create new mission", which lets one build a new mission from scratch. Next to that, now is another button called "Create new Event".
By way of an Example, any PCC member can look at the (one) Event currently in production, mission 3643 - "Face the Heavy Fennus R-18 Guardian and Friends".
Editor Mechanics and Functionality
These are the current (May 24th 2024) specifics of using the Editor. I imagine these will fluctuate soon, but in due course the documentation will be posted on PCC Forum, rather than here. This is only being shown as more of an announcement.
Instructions
Instead of Requirements, the events have a Schedule. If no schedule is added to the event, it doesn't run. It can be manually started with the /oper /startevent <eventid> command, explained later.
To create an event, click on the 'Create new Event' link at the bottom of the list of the missions you're working on. The name, description, and long description are not displayed to the user, so you can use them for notes.
Timers and NPCs will be automatically cleaned up when the mission ends or is aborted. If, for whatever reason, the NPCs are not cleaned up, you can /msg them go away to make them leave.
If an event is currently running when it is saved, the event will need to be manually aborted for the changes to be applied.
Scheduling
There are three schedule entries, and one event lifespan entry.
* Event Lifespan is how long the event runs before it is killed off (aborted). The format is HH:MM:SS.
* Event begin time (UTC): Defines when the event should be started.
- If the time is in the past and no periodicity is defined, it is started immediately.
- If the time is in the past and a periodicity is defined, then it calculates the next time from the start time using the period. For example, if the begin time is 01:00:00, the periodicity is 15 minutes, and the current time is 01:05:00, the event will be scheduled for 01:15:00.
* Concurrency: Defines how many of the event can be running at once. Setting it to 1 is the same as the "Run only one at a time" flag. The flag overrides the count.
- Defaults to no limit if it is not defined.
* Periodicity: Defines how much time before the event is restarted, and whether the time begins when the event ends or is started. The start time can be randomized up to the indicated length.
- Defaults to only running once if it is not defined.
If no schedule info is defined, the event can still be manually scheduled or started using /oper commands.
Oper Commands
There are a series of /oper commands that can be used to start, abort, schedule, cancel a scheduled event(s). The <event number> is the number of the event in the Mission/Event Editor. These commands are available to PCC members, on the Test Server.
/oper /runningevents
- Displays the running events, when they started, and how long ago that was, and displays scheduled events and when they are scheduled and how far from now.
- It also displays an <event id> of the running or scheduled event, so a single instance of an event can be aborted or cancelled.
/oper /startevent <event number>
- Immediately starts an event if it doesn't exceed the defined concurrency.
/oper /abortevent <event number>
- Aborts all running instances of the given event.
/oper /cancelevents <event number>
- Cancels all schedules of the given event.
/oper /cancelevent <event number> <event id>
- Cancels a single scheduled event. <event id> is displayed with the /runningevents command.
/oper /abortoneevent <event number> <event id>
- Aborts a single running instance of an event.
/oper /scheduleevent <event number> [+]HH:MM:SS
- Schedules an event for the given time in UTC (or from the current time if + is included) for the same day. If the time is in the past, it is moved to the next day. For example, if it is currently 05:00:00 UTC and you schedule an event for 01:00:00 UTC, it is scheduled for 01:00:00 UTC the next day (so 20 hours later). If you schedule it for 06:00:00 UTC, it will be scheduled to start in one hour.
- Two digits much be used for each value, so 00:00:00 would be midnight UTC.
Is there a system in place to dynamically scale the missions, or would they be statically scaled? Looking at other MMOs, world events can spawn in more enemies or have more/less HP depending on the number of players participating, which allows events to be complete-able no matter what the participation is like. Not every mission should be solo-able, but if missions are statically scaled, there's the risk of missions being trivial with a group or capship, and unapproachable without a capship or group. Unrats already suffer from this a bit, where a solo pilot without a capship needs to be pretty skilled to not get overwhelmed by the fighters and have a chance to take down the base ship.
I could also see an argument the other way, for the sake of realism. The "enemies" are at the strength they're at, organize and figure out how to respond successfully.
I could also see an argument the other way, for the sake of realism. The "enemies" are at the strength they're at, organize and figure out how to respond successfully.
Is there a system in place to dynamically scale the missions, or would they be statically scaled?
Basically, we're building a "content-creation system" here. How the content is implemented is content-specific.
There are a lot of different ways of implementing what you're talking about, and some of them are really related to the particular design of the gameplay.
For instance, the current "Dentek in Odia" thing could be spread to more systems and spawned (instanced with the current design) x100 or x1000, and there would be random mining Denteks everywhere, all the time. If players attacked those Denteks, they would (each) create the related Heavy Guardian / Assault response. So, lots more people could technically be entertained by the same content, or 10 people could take on a single instance, together.
Because the content only expands on player engagement (triggered on NPC destruction), it only "scales" if more people are involved (obviously this is a super simplistic example, and there are lots of "design" edge-cases that are outside the scope of this discussion).
The Persistent Event system, as it stands right now, has no concept of "players" (from the mission's perspective), as I mentioned above. We're still adding those features.
But, when there is such a concept, it's reasonable to expect that one could choose to write an Event where more NPCs are spawned if more "player participants" are detected. But, that kind of scaling is not applicable to every type of scenario.
In particular, there are storyline-driven scenarios that don't really lend themselves well to suddenly adding 2x or 10x the number of NPCs.
Similarly, Unrats were never intended to be "trivially" solo-able. Frankly, some content should not be solo-able at all.
So, basically, while the system is still very early at the moment, the meaningful answer here is "it depends on what you make".
(There's a much bigger design discussion about "which method is better", which I think is also part of what you're asking: and the answer there is simply "everything has its place". Lots of MMORPGs, like WoW, have raids that come with a particular "minimum requirement" of player engagement (guild of 50 people at level XX). Other games may auto-scale based on availability or the "level mixture" of players who may be participating. Vendetta Online is a unique snowflake, because our game can scale 500 players into any sector, and our combat content is really "player-skill" based and not "level" based, which has its own set of benefits and challenges).
Basically, we're building a "content-creation system" here. How the content is implemented is content-specific.
There are a lot of different ways of implementing what you're talking about, and some of them are really related to the particular design of the gameplay.
For instance, the current "Dentek in Odia" thing could be spread to more systems and spawned (instanced with the current design) x100 or x1000, and there would be random mining Denteks everywhere, all the time. If players attacked those Denteks, they would (each) create the related Heavy Guardian / Assault response. So, lots more people could technically be entertained by the same content, or 10 people could take on a single instance, together.
Because the content only expands on player engagement (triggered on NPC destruction), it only "scales" if more people are involved (obviously this is a super simplistic example, and there are lots of "design" edge-cases that are outside the scope of this discussion).
The Persistent Event system, as it stands right now, has no concept of "players" (from the mission's perspective), as I mentioned above. We're still adding those features.
But, when there is such a concept, it's reasonable to expect that one could choose to write an Event where more NPCs are spawned if more "player participants" are detected. But, that kind of scaling is not applicable to every type of scenario.
In particular, there are storyline-driven scenarios that don't really lend themselves well to suddenly adding 2x or 10x the number of NPCs.
Similarly, Unrats were never intended to be "trivially" solo-able. Frankly, some content should not be solo-able at all.
So, basically, while the system is still very early at the moment, the meaningful answer here is "it depends on what you make".
(There's a much bigger design discussion about "which method is better", which I think is also part of what you're asking: and the answer there is simply "everything has its place". Lots of MMORPGs, like WoW, have raids that come with a particular "minimum requirement" of player engagement (guild of 50 people at level XX). Other games may auto-scale based on availability or the "level mixture" of players who may be participating. Vendetta Online is a unique snowflake, because our game can scale 500 players into any sector, and our combat content is really "player-skill" based and not "level" based, which has its own set of benefits and challenges).
That all sounds interesting. Some unpredictable events would be welcome, I think the game does need more surprise content.
Yup. It could be both predictable or unpredictable. For instance, I want to add the ability to see upcoming Events on the Nav map (or a list at login), with a timer countdown, for those that want to announce themselves.
But, for others, they'll be more randomized one-off occurrences.
But, for others, they'll be more randomized one-off occurrences.
Ok fine, you win, i'll make content again
This past week we updated the Persistent Event side of the Mission Editor with more features. This is really early and I haven't tested most of the new features myself, although they have been "smoke tested" internally.
There will eventually be more information made available on known-limitations and tradeoffs and such of certain features, but for starters, here is the overview:
- Added the ability to start Events with dynamic parameters.
Added actions:
- track/untrack player
- msg from npc to specific player(s)
- set navroute for specific player(s)
- set/remove/increment/decrement accomplishment
- give xp
- give money
- give faction standing
- give item
- drop private crate
Added events:
- player login
- player logout
- player warp out
- player died
- player killed npc
- player docked with specific/any station
- player launched from specific/any station
- player messaged a specific npc
- player gave a credit to a specific npc.
For these events, the player can be specified as 'Current player' to allow any player to trigger the event, even if they are not being tracked. This is to allow a player to join the Event by contacting an npc or giving it credits, or the player doing something.
Additionally, the 'All tracked players' option really means 'Any tracked player' for these triggered events.
There will eventually be more information made available on known-limitations and tradeoffs and such of certain features, but for starters, here is the overview:
- Added the ability to start Events with dynamic parameters.
Added actions:
- track/untrack player
- msg from npc to specific player(s)
- set navroute for specific player(s)
- set/remove/increment/decrement accomplishment
- give xp
- give money
- give faction standing
- give item
- drop private crate
Added events:
- player login
- player logout
- player warp out
- player died
- player killed npc
- player docked with specific/any station
- player launched from specific/any station
- player messaged a specific npc
- player gave a credit to a specific npc.
For these events, the player can be specified as 'Current player' to allow any player to trigger the event, even if they are not being tracked. This is to allow a player to join the Event by contacting an npc or giving it credits, or the player doing something.
Additionally, the 'All tracked players' option really means 'Any tracked player' for these triggered events.
As a heads-up, a more elaborate set of documentation around concepts like Custom Variables and Player Tagging is available to PCC members on the PCC Forum.