EDIT 10/22/14:
I'm going to continue to edit this post as I have more ideas and thoughts on the topic, as well as when discussions happen that produce more information.
Bounty type ideas 2014-10-22
Some types of bounties lend themselves to this type of system more than others. In discussions, escort and defend type have been rather vehemently opposed as "not fun". However, this type does offer a more diverse set of jobs as opposed to only deliver and kill types.
Types of bounties proposed:
-
Find N of item X
-
Go to location Y, find N of item X
-
Go to location Y and clear dungeon/area
-
Deliver item X to location Y
-
Go to location Y, get item X, and deliver to location Z
-
Go to location Y, get item X from person A
-
Rescue/Free hostage at location Y
-
Scout location Y
-
Defend location Y (this would be a town based defend for places like Arefu)
-
Find and kill person A (optionally enslave)
Most of these I feel would be fairly easy to implement, perhaps with the exception of defend types.
[collapsed title=Implementation Ideas - 2014-10-19]
Possible. I've considered several methods of implementing this since Skyrim introduced Radiant quests. The best I can come up with is a set of quests with a ton of various markers and objectives that are all conditioned to appear one at a time (per quest type, probably set up and duplicate the quests once finished for faster setup of more).
Going into a bit of implementation detail, since that's mostly what I've thought about.
You'd set up a quest for say, package delivery. Create however many pickup locations and drop-off locations you want to have. Probably a minimum of 10 each, though obviously more would be a lot better. All the locations of one type would be conditioned on the same quest variable, which would be set randomly on quest add. This would then determine the locations for pickup and drop-off, enable the markers to the objects (probably should be containers, activators, or NPCs for persistence reasons), and set any location specific quest objectives as enabled. The player would then follow the quest, where various stages and other conditions, perhaps even other higher level tracker quests might handle events such as an ambush or NPC encounter (conversation) etc.
Attack quests would be similar, and this could even be expanded out to escort and other types of more intricate tasks, so long as additional spawn locations are accounted for (top level tracker quest would come in handy here).
A few issues with this that I don't know how to solve. Once the quest is given, I don't believe it's possible to remove it from the Pip-Boy. So whenever it's added, that's where it'll stay. Completing a quest will drop it down into the inactive/complete section, and I think activating it again will bring it back up to the active quests section, but I think it will stay at the bottom. This is honestly a fairly minor graphical issue, BUT, it will also remove the past quest from the Pip-Boy. Probably a good thing really to prevent clutter by just reusing the same few quests over and over.
Extensibility would be fairly simple by making it a system that can accept additional quests added to a list. The guts would need working out, but there are many different ways to add them that would work, and be fairly easy to add onto by making a template that people could use to quickly make fetch and deliver quests.
A custom UI for the boards would be slick, and I've actually got a couple of layouts that would be fairly easy to make use of and would allow for easy display of lists of quests as well as a description for it.
[/collapsed]
[collapsed title=Implementation Ideas - 2014-10-22]
I brought up in chat that I think the core mod should handle as much of the data as possible, so that any mod can be added to make use of it. This includes things such as lists of: Locations and Cells, NPCs, Items, Markers.
Locations and Cells: These are places where things can be found. They should be split into various types of locations, such as raider dens, factories, military bases, residential, office, sewer, metro, etc. As fine grained as we can think of to do things. Some form of differentiation should be made between exterior and interior locations. Find quests are much more difficult if you have to drudge through a dungeon to get the items. Kill quests probably wouldn't matter as much, unless the person is running around the wasteland.
NPCs: Again breaking it down as finely as possible is key. Needs lists of random NPCs that can be placed as hostages, kill targets, item turn in targets, item receive targets, etc. In those there should also be options for raiders, break down by race if desired, and several other categories I thought of and forgot :\ The NPC system is the part I'm least sure about, as I've not worked with NPCs and AI much. This is going to need someone like sesom to consult and help with getting set up and working.
Items: Lists of items that can be used in find quests. Not limited to Misc, weapons, food, and others should be in here. This could potentially be loaded from a list of loaded mods, though that could be problematic as to which items should and shouldn't be used. This category should be broken down into junk items, valuable items, food (drink and not), weapons, armor. While finding items in the world would be cool, they should probably be spawned into containers simply due to the fact that not all items are centered correctly and of course not the same size.
A significant amount of work will probably need to be done to place markers both for quest objectives markers as well as for where NPCs should go in assault/defend types, deliver quests, and item finds. Object based stuff can be handled in game, moving markers around to wherever a quest needs to be. Item locations and NPC placement will need to be determined before, to ensure there is room for things to spawn.
In many locations, the cell can be reset to have NPCs respawn (or disappear) and the spawn points can be reset to make them respawn or used to spawn new creatures in.
In all instances of location, item, NPCs, etc, any job should be able use its own lists instead of the default ones.
[/collapsed]
