I don't think it has to be that complicated.

At some point Josh will program the AI. The AI will create tasks. The amount of different tasks is finite. (go mine, go kill, go trade, go ...)
But these tasks can be given a bit more personality by scripting.

Examples:
Mining: The faction could ask you to mine in a specific contested region. if you successfully set a mining operation there, another faction gets a negative impact.
Trading : A (scripted) drought sets in on a planet, the AI creates trading missions to supply the planet with more water
Fighting: Two factions are at war with eachother. The player is tasked to take out a specific ship, because some super smart admiral is on there. If the player is successful, this faction gets a negative impact.

These would all be scripted events that can easily be generated in an existing universe without the need of having to spawn ships.

JabbleWok wrote:One way of doing it might be to make sure the steps would be achievable in any instance of a universe. For example, the initial quest could be made available through talking to an NPC in a station. It doesn't matter which station or NPC, it's just a device to give you the quest so the generator uses the next suitable one you enounter. 'Suitable' would be important, but it would likely mean any NPC that's not already part of another quest.

The first stage could be to carry out some actions that should be possible in any instance of a universe, e.g. collect 100 units of ubiquitium. Once you have done that, then you call the contact's number (or whetever is the LT equivalent) and receive the instructions for the next stage. You don't need to know where he is, i.e. he's not going to die because his station is blown up, though maybe he'll 'happen' to make an appearance at some station you go to. Or one of his contacts will.

And so it should be very possible to construct a story based on a sequence of actions that are possible in any universe, and the story agents would similarly be the sort of NPCs and objects that could be anywhere. That would rule out any sort of bespoke creatures and items, unless the generator could be made to specifically handle that. Maybe it would be legitimate to generate a temporary system in which key events occur, so that they don't affect the rest of the universe. An isolated room with your own unique way there and back. A bit like travelling by wardrobe to a mystical land to have an adventure, before returning to the normal world which hasn't been affected in any way by your actions. However it would probably not be legitimate (or at least advisable) for the quest generator to make significant changes to the mainstream universe. So if you destroy a (storyline-generated) pirate fleet single-handedly, there will be no repercussions for the mainstream universe apart from whatever changes it makes to your own character.

The story design would have to follow certain dos and don'ts so as to conform to that 'happen anywhere' approach. Even with those constraints, it should still be very possible to concoct clever and challenging storylines. In some ways they'd be far more immersive than some other games I won't mention, as you'd be an ordinary person pursuing some unpredictable adventure in a big universe, as distinct from 'the hero' following 'the story' of 'the game'.

All of this sounds exactly like the procedurally generated type of mission that Josh is going to implement anyway. As I said before, it has nothing to do anymore with the scripted missions this thread is about.

Commander McLane wrote:All of this sounds exactly like the procedurally generated type of mission that Josh is going to implement anyway. As I said before, it has nothing to do anymore with the scripted missions this thread is about.

Well, my suggestion was about how to use part of the procedural quest generator to run user-designed stories, without necessarily interfering with the normal run-forward of the game. Whether it's in the form of a script or something else would depend on how it's implemented e.g. it might be possible to have an API for creating quest stages, triggering responses and generating decisions. Maybe even creating places and objects i.e. new instances of standard game entities.

While LT won't be moddable i.e. adding user-created content, it still might be steerable, i.e. adding user-created quests that use standard in-game entities and actions.

JabbleWok wrote:

Commander McLane wrote:All of this sounds exactly like the procedurally generated type of mission that Josh is going to implement anyway. As I said before, it has nothing to do anymore with the scripted missions this thread is about.

Well, my suggestion was about how to use part of the procedural quest generator to run user-designed stories, without necessarily interfering with the normal run-forward of the game. Whether it's in the form of a script or something else would depend on how it's implemented e.g. it might be possible to have an API for creating quest stages, triggering responses and generating decisions. Maybe even creating places and objects i.e. new instances of standard game entities.

While LT won't be moddable i.e. adding user-created content, it still might be steerable, i.e. adding user-created quests that use standard in-game entities and actions.

Players should not be causing spawn of objects. Period. Everything in LT exists where it does for a reason and came in to being logically. Nothing is spawned for missions; the resources/NPCs/threat levels developed naturally in accordance with the algorithims used for procedural generation. There are no 'quest instances' or anything of that nature with a temporary lifespan coming in to existance just so you can interact with it for your mission objective.

Player-managed quests are not compatible with this environment, as they require scripting, spawning, or both to be unique. Seriously, what can a player offer to quest development without these two items that the AI isn't already going to be doing? Nothing.

Kayse wrote:Players should not be causing spawn of objects. Period. Everything in LT exists where it does for a reason and came in to being logically.

Surely that can't be right? If I go to a shipyard and commission a new ship, isn't that just an elaborate way of pressing a "spawn ship" button?

The new ship comes into existence because I made a decision; it would not exist without that decision. The player is capable of interacting with the game environment, and that means changing it, i.e. creating and destroying object instances due to deliberate choice. That's one of the reasons why a savegame will have to include persistant data, rather than just a seed from which the universe can be derived at any time. The player will cause the universe to be different from how it would be if only procedural generation were involved.

Nothing is spawned for missions; the resources/NPCs/threat levels developed naturally in accordance with the algorithims used for procedural generation.

If I accept a game-generated mission, at the very least that changes a boolean status flag. How can you be sure it will not do more than that, e.g. spawn additional objects relevant to that mission? Either at the time the player accepts it, or at subsequent stages of that mission?

What if a mission asks me to commission a new ship at a particular shipyard? If I do so, then my completion of that task spawns a new ship. Are you really saying that missions will never ask the player to do anything that results in the spawning of a new object, i.e. where the player's choice to follow the mission has a direct consequence of a new spawn?

There are no 'quest instances' or anything of that nature with a temporary lifespan coming in to existance just so you can interact with it for your mission objective.
Player-managed quests are not compatible with this environment, as they require scripting, spawning, or both to be unique. Seriously, what can a player offer to quest development without these two items that the AI isn't already going to be doing? Nothing.

OK, Maybe! It could be I've missed details already written, regarding the mechanics of how missions are generated and managed, and ruling out player-triggered spawning of mission-related objects. If so, could you point me towards them?

Josh has stated that missions will be available for the player and NPCs alike. The missions will be generated according to the need of a faction.

With spawning, I suppose you mean "created out of nothing", then yes, ships aren't spawned. Josh has also stated that creating ships will require materials. Shipyards might have these materials in stock, but you're paying for them. You can supply your own materials, making construction a bit cheaper.

I really doubt Josh will create missions manually. As such, it's also very hard to spawn mission-related ships. I'm guessing if a ship is needed for a mission, an existing NPC will be assigned to that role. But yes, it's still a guess.

Katorone wrote:With spawning, I suppose you mean "created out of nothing", then yes, ships aren't spawned.

No, I don't mean created out of nothing, or at least not necessarily so. Spawning is causing something to come into existence, irrespective of the conditions which lead to it. Whether it's a simple "yes/no" menu selecion or whether it requires 973 rare items to be fetched from the far corners of the galaxy first, that's besides the point. The point it that the player can deliberately provide input that directly or indirectly results in a spawn.


I see four issues here:

1) Is the game compatible with player directly or indirectly triggering objects to be spawned?

2) If 1) is true, then is the game likely to have spawning agents whereby the player can trigger objects to be spawned, either intentionally or not?

3) If 2) is true, then can generated missions instruct the player to carry out actions which cause spawning?

4) If 3) is true, then could the mission generator be extended to allow user-created elements (scripts or otherwise) to provide missions which may include such spawning?


1) As the game allows the player to change the universe, this must be true.

2) If the game includes shipyards, shops or any other "agents of spawn" which can cause new objects to exist (irrespective of conditions), and the player can trigger those agents to do so, then this is true.

3) I don't know for sure, but I don't see that it should be ruled out. For example, a mission could ask the player to eliminate a pirate, and the reward is that a new ship is commissioned for him. If any direct consequence of a mission is to spawn a new object of any kind, the answer must be true.

4) This is what this what this whole thread is about! We're speculating here if it's a) possible and b) a good idea. If 1)-3) are true, then it's a perfectly valid thing to speculate on.

JabbleWok wrote:Surely that can't be right? If I go to a shipyard and commission a new ship, isn't that just an elaborate way of pressing a "spawn ship" button?

Yes and no. The ship exists because a company dug up the scrap, sold it to be processed, then sold the sheet metal to the factory which then supplied the ship to the shipyard. Yes, when you clicked 'buy ship' you set the wheels in motion for demand which was eventually met. If you consider the "Press a button, get a cookie" type solution, yes, because you don't have to concern yourself with everything on the back end. No, because everything has a logical path to where it is now.

JabbleWok wrote:The new ship comes into existence because I made a decision; it would not exist without that decision. The player is capable of interacting with the game environment, and that means changing it, i.e. creating and destroying object instances due to deliberate choice. That's one of the reasons why a savegame will have to include persistant data, rather than just a seed from which the universe can be derived at any time. The player will cause the universe to be different from how it would be if only procedural generation were involved.

Now it almost sounds like you're splitting hairs. The universe has to be able to exist and continue even if the concept of a 'player' doesn't exist; i.e. the universe is just a simulation that an observer can watch. But if you want to get that granular, then technically I'm just 'spawning boogers in my nose' right now.

JabbleWok wrote:If I accept a game-generated mission, at the very least that changes a boolean status flag. How can you be sure it will not do more than that, e.g. spawn additional objects relevant to that mission? Either at the time the player accepts it, or at subsequent stages of that mission?

What if a mission asks me to commission a new ship at a particular shipyard? If I do so, then my completion of that task spawns a new ship. Are you really saying that missions will never ask the player to do anything that results in the spawning of a new object, i.e. where the player's choice to follow the mission has a direct consequence of a new spawn?

If you accept an in-game mission it means an NPC didn't. If you didn't accept that mission, the outcome would still be the same because some NPC will do the job if you don't (as long as the pay is good and/or there is someone to take the mission). If you abide by the same idea I put forth at the beginning, then you still aren't just 'spawning' a ship, you're becoming a cog in an economical machine, nothing more. The credit flow should be identical whether it relays through you (and you get a percentage cut for completing the mission) or an NPC. It just matters who's pockets get padded at the end of the day. This is economy, nothing more.

As for the consequence? Maybe an NPC did it and hijacked the funds that then supplied a pirate faction. Butterfly effect. That little bit steamrolled into a faction wiping out a planet 20 jumps from here. Once again, it's all economy.

JabbleWok wrote:OK, Maybe! It could be I've missed details already written, regarding the mechanics of how missions are generated and managed, and ruling out player-triggered spawning of mission-related objects. If so, could you point me towards them?

What everything boils down to is that if you remove any and all aspects of 'game' to LT, you should be left with nothing but a simulation. That simulation should still have all these missions/quests and should still have all the same problems that would be there regardless. There will be traders trying to just make a quick buck and will never amount to much. There will be freighter pilots who just want to get home to see their family. There should burger flippers working at the local McAsteroid asking you if you want fries with that because they didn't get a good education.

The game should be nothing more than a procedurally generated initial universe that can continue on whether you live or die. If it can't, then not only does that break the immersion factor, but it also means the world doesn't revolve around you. You should feel like an insignificant cog, and even once you have your system-destroying fleet, you should still be humbled by the sheer number of systems out there.

Jabblewok, I'm not trying to bash you. All I'm saying is that if this is done well (and I believe it can with Josh's capability), then all those granular 'spawn' issues you have would be impossible to detect (also possible).

DWMagus wrote:If you consider the "Press a button, get a cookie" type solution, yes, because you don't have to concern yourself with everything on the back end. No, because everything has a logical path to where it is now.

If Non-player activity results in a spawn, that's not the argument here. If player activity does, then that is indeed a spawn irrespective of the conditions which allow it. It is still a spawn triggered by a player decision, not inevitable game activity or necessarily a "logical path". It was stated that "Players should not be causing spawn of objects. Period." and I'm pointing out that cannot be correct.

Now it almost sounds like you're splitting hairs. The universe has to be able to exist and continue even if the concept of a 'player' doesn't exist; i.e. the universe is just a simulation that an observer can watch. But if you want to get that granular, then technically I'm just 'spawning boogers in my nose' right now.

There is a very important point here, but I fear we're straying from the original aim of this thread. Yes, the universe must exist and continue irrepsective of player input. But no, the direction of continuation is no longer the same once the player makes changes.

The game universe on its own is entirely deterministic (assuming no quantum mechanical dongle causing change). Its state at any one point can be directly derived from any earlier state. However, when the player starts acting, then he introduces changes that are not deterministic; the player-altered universe cannot be directly derived from an earlier state.

A parallel (which I asked about here): in a deterministic universe, a group of balls is at the top of a hill, and they are set rolling downhill. Assuming full knowledge, at any one time their future state (velocity, position, etc) can be exactly predicted. At any one time, their current state is directly derived from every earlier state, right back to time=0. Now, introduce a player, who nudges the rolling balls. One or more balls changes velocity because of this. The nudged balls may collide with other balls, altering their course as well. Now, the current state is no longer directly drived from the initial state; the player has changed the universe for ever. On the grand scale of things, though, it's still just a bunch of balls rolling downhill.

Similarly, in a seed-based procedurally-driven universe, player interaction stops the future being the same as it would be without it. The player's decisions change the future so that it's no longer a direct descendent of that initial seed. However, that future is still a functioning universe.

On the other hand, that's probably a deviation from the point of this thread, which is that missions can be generated which can lead to the player causing objects to spawn. I don't disagree that missions picked up by NPCs also can cause objects to spawn - if anything that highlights the point that the mission generator directly or indirectly can cause items to spawn, as well as other changes.

If you accept an in-game mission it means an NPC didn't. If you didn't accept that mission, the outcome would still be the same because some NPC will do the job if you don't (as long as the pay is good and/or there is someone to take the mission).

Not necessarily - how can you guarantee that the outcomes and changes you cause will be exactly the same as an NPC would have done? If you can't, then the total outcome will almost certainly be different, whether by a minor or major degree. From the point of the mission generator being scriptable/steerable, though, that's pretty much irrelevant.

If you abide by the same idea I put forth at the beginning, then you still aren't just 'spawning' a ship, you're becoming a cog in an economical machine, nothing more. The credit flow should be identical whether it relays through you (and you get a percentage cut for completing the mission) or an NPC. It just matters who's pockets get padded at the end of the day. This is economy, nothing more.

You're still causing change that's different from what would happen if you weren't there. How this pans out on the broad scale is not really the point here; the point is you can cause objects to spawn, and so mission generation can potentially prompt you (and NPCs) to do so. I'm not particularly hung up on the idea of spawning, as distinct from other change, I'm just countering the claim that it's impossible and that that would be a reason to prevent player-created stories.

What everything boils down to is that if you remove any and all aspects of 'game' to LT, you should be left with nothing but a simulation. That simulation should still have all these missions/quests and should still have all the same problems that would be there regardless.

The only difference between LT being a simulation and a game is the player input and the changes it causes. Even then the grand scheme of things will almost certainly be the same, assuming sensible constraints on player actions. I'm not disagreeing with that - indeed we seem to have wandered far from what this thread is about.

The point I was trying to make was that if the mission generator can cause spawning and other effects, than that could potentially be made use of to enable user-created stories to be run as well as the normal procedurally generated ones. This is not doubting that Josh can produce a top-class mission generator that works well within the dynamism of the game, it's simply suggesting ways in which players can follow stories that are created by humans too.

Why? Because there seems to be a demand for it, and it allows human creativity to play a role. There's a reason we buy stories written by humans rather than computer generated; no matter how good our AI, we still value and appreciate that human creativity which depends so much on individual personality, and the stories that it can produce. I'm just suggesting we find a way to include that here, and postulating possible mechanisms to do so. Is that so bad?

Sounds like you are headed into "Spore Galaxys" teritory there...

JabbleWok wrote:The point I was trying to make was that if the mission generator can cause spawning and other effects, than that could potentially be made use of to enable user-created stories to be run as well as the normal procedurally generated ones. This is not doubting that Josh can produce a top-class mission generator that works well within the dynamism of the game, it's simply suggesting ways in which players can follow stories that are created by humans too.

Why? Because there seems to be a demand for it, and it allows human creativity to play a role. There's a reason we buy stories written by humans rather than computer generated; no matter how good our AI, we still value and appreciate that human creativity which depends so much on individual personality, and the stories that it can produce. I'm just suggesting we find a way to include that here, and postulating possible mechanisms to do so. Is that so bad?

Just because there is demand doesn't mean it needs to be heeded. Many of my PGC is derived from my time playing Dwarf Fortress, so I usually base any very in-depth cog-in-the-machine simulation-driven on that.

Let me try tackling this from another perspective.

Let's say I generate a mission, or a set of missions. I'm not going to be pinpoint specific for sake of the example, but it can be applied at a granular level.

I accept a mission that has me taking out a pirate patrol. The patrol is bit more well armored than I'm willing to risk going by myself. I go ahead and request help and recruit two wingmen. I fly to the patrol point and engage the enemy. Before any real damage is done, a third faction appears and wipes out everyone--I'm barely able to escape with my life. This new threat is one I need to concern myself with, because they either mis-associated me with the pirates, or (due to rep or whatever) were actually after me. Either way, I'm alive, and I need to be careful. I lost my wingmen, the guild they hail from blame me and have less rep with me because of it. The overall idea is that a third faction is making an attack on the patrol and I happened to be caught in the middle of it.

A fairly basic scenario all things considered, and I happen to like this, so I try to export the mission and provide it to a friend. He loads it up, but all of a sudden, there are many more variables that need to be recognized.

1) He flies in with something more powerful than what I had. He didn't need wingmen, and suddenly the outcome is vastly different. He is able to waste the patrol, and the one enemy doesn't appear, either because it is a higher risk to them (as my friend is flying something that could put a decent fight). He may have bad rep with the third faction, but they don't want to chance the encounter.

2) He flies in solo, and has incredible skill. He is able to take out a few of the enemy before the third faction appears. He has less cannon fodder between him and the threat (his wingmen and/or enemy pirates) and thus it is actually much harder to try and flee, and in turn, he may not be able to.

3) The enemy that appears is weaker than what I encountered, thus either the pirates destroy them or my friend destroys them. Completely different side of the spectrum and is yet another outcome.

These three don't even address the 'why' portion of the different enemies being there.

Now, in order for this to be possible, you'd need a few more things to happen. Let's take it a step back to the point where I hand my friend a the mission file. Here's everything the engine would need to be able to do in order to have something happen similar to what I experienced;

1) Find a pirate faction that has patrols. Those patrols may or may not have to be in scale with what the player is flying/using. A patrol too weak would mean nothing to the player, while one too strong would completely decimate the player. Once the game locates said patrol, generate a mission within the same guidelines that are put forth so that an NPC doesn't suddenly hate this faction and put out a random mission for assassination/clear the area.

2) Find a pirate faction to be able to interrupt the dogfight. They must be in strong enough force they don't get destroyed, and not strong enough where they don't completely obliterate the player within the first seconds of them arriving.

3) The faction that interrupts needs a reason to be there in the first place. While when I played, it may have been completely coincidence, now we're trying to make that scenario happen.

Even if we take out the idea of strength and strength scaling of the other two factions to whatever the player is flying/using, there is still the 'why' that needs to be fully addressed. The player arriving right before an attack by another faction. Did that other faction wait for the player to show up? Why did they specifically show up only AFTER the player. Does this meant that had the player not shown up, the patrol would never have been destroyed? If that's the case, then why was the third faction there in the first place since they weren't after me?

The only feasible way I can see this being solved is if the universe AI can influence the conflux of events, so that overtime, slight nudges here and there eventually lead to a mission SIMILAR to what I experienced, but nothing more. I tried to convey that on the first page when I mentioned the universe evolving towards that mission/scenario. If the universe doesn't, then the only way to make scenarios happen is move assets from one location to another without a valid 'why' and to throw half of the game's AI logic out the window (risk, reward, reputation with all involved parties).

Not to mention this only gets compounded even more once you start chaining missions since you require certain outcomes in order to come true (i.e. if the following mission was to hunt down the third faction only can happen if you weren't completely destroyed or the other faction wasn't destroyed).

DWMagus wrote:Just because there is demand doesn't mean it needs to be heeded.

No indeed. On the other hand it is a valid reason to look into the possibility.

Let's say I generate a mission, or a set of missions. I'm not going to be pinpoint specific for sake of the example, but it can be applied at a granular level.

What do you mean you generate a mission? Do you mean you script one, that you pick up a normal game-generated one, or that you actually have a distinct mission generator that you can run?

A fairly basic scenario all things considered, and I happen to like this, so I try to export the mission and provide it to a friend. He loads it up, but all of a sudden, there are many more variables that need to be recognized.

What do you mean "export" the mission? Do you mean somehow create a reusable mission script from within the game itself?

Now, in order for this to be possible, you'd need a few more things to happen.

OK, already I see we're far apart on our conceptions of how this could work. I certainly don't foresee any explicit "mission generator" that you can call up, nor any ability to "export" a mission already within the game. What I did have in mind is writing a set of instructions in an editor which would be fed into the game, with the result that a mission now exists in the game. The mission-defining code would need to access certain game variables (including instance/persistence variables) and be able to create mission stages, and applying it would result in an internal game structure that's unique to that game. Likely some sort of basic API would be needed, or at least a means of issuing conditional instructions based on local state. Hence any idea of "export" would not be practical.

A parallel would be a software installation script that takes into account the state of your local machine, and so installs a uniquely configured version of the software. You can't then "export" that to plonk into a different unique machine, as the script processing must take into account local state. Hence only the source script could be transferrable.

There would need to be various constraints and good practices, and it would not be possible to script a mission that's guaranteed to be completable, as local in-game developments can always destroy required assets. However, that would be part of the skill of good mission scripting - creating a mission whose completion is likely to be possible, as well as being interesting/appealling.

The only feasible way I can see this being solved is if the universe AI can influence the conflux of events, so that overtime, slight nudges here and there eventually lead to a mission SIMILAR to what I experienced, but nothing more.

The game AI will always be running, so any scripted mission must take that into account. That's why I say that local instance variables would be important so as to "install" the mission into into the unique state of the player's game, and that the mission stages would need to be written so that any required assets are likely to continue to exist.

A simple example; you install a script and play the game. Next time you are in a station, you get a PDA message that a Mr. King would like to meet you in the bar. You go to the bar and find him, initiating conversation. He tells you he wants you to wipe out some pirates in a system, and the payoff is he'll commission you a new ship.

Scriptwise: at this stage the script must spawn Mr. King in that bar, or else use a "background" NPC that's already part of the bar population. It must be able to send a message to the player, and issue the instruction at the meeting. The script must have access to local game variables that either determine the whereabouts of a pirate fleet (nearest or otherwise), or of a system where pirates are likely to be found. The system name must be embedded into Mr. King's instructions, and this must link to any in-game player journal.

Now, you fly off to the sector and look for pirates. Maybe you find them and kill them. Maybe you find them and fail to kill them. Maybe you fail to find them at all. By the time you leave that system alive (if you do), you'll have either succeeded or failed. To finish the mission you must contact Mr. King, whereupon the ship will be commissioned or not.

Scriptwise: The script must include a trigger that recognises when the player enters that system, and another one for killing a pirate/all current pirates in that system. It must also be able to find a shipyard and issue a commission instruction to it, as well as meet the conditions needed for commissioning. That could get complicated as it could involve chartering freighters to bring in required materials, but again, that would be part of the script-writing skill. Cash would be a simpler and more reliable payoff.

As the AI runs the game, it may cause changes that prevent mission completion. AI NPCs could eliminate all pirates there before you get the chance. The shipyard building your reward might get destroyed. You could get killed! So like any game-generated mission, a scripted mission would still be subject to the slings and arrows of outrageous fortune within the runtime game engine. The main benefit is that a human can provide a unique style of story that's appealling to the player.

Now, I don't suggest this would be trivial to implement, nor necessarily a good idea, but I do think it's worth looking into the possibilities. Significantly, I do think I've countered some suggestions as to why it would be impossible, but there may well be more as we look further. I suggest we do look, though.

Okay, now we're getting into the good stuff.

When I mentioned generating a mission, I meant by any means inside or outside the game. Hence the reason why I said I wasn't going to be specific. The methods of how that mission came to be are independent of the concept of recreating the mission in another game instance. Same thing with exporting the mission. The basis is that the mission needs to get from one instance of the game to another, regardless of the methodology.

But after your next explanation, that point is actually moot.

Scriptwise: at this stage the script must spawn Mr. King in that bar, or else use a "background" NPC that's already part of the bar population. It must be able to send a message to the player, and issue the instruction at the meeting. The script must have access to local game variables that either determine the whereabouts of a pirate fleet (nearest or otherwise), or of a system where pirates are likely to be found. The system name must be embedded into Mr. King's instructions, and this must link to any in-game player journal.

There you go, spawning an NPC. Keep in mind that if a mission exists, it's because there's reason for it to exist. This is also what I meant when I said it could get complicated fast--The script has access to local variables that determine the whereabouts of a pirate fleet. It wouldn't stop there. In order for the game to make sure nothing is spawned just for the sake of the mission, the script would then need to also be able to find the Mr. King (or Mr. X, name is irrelevant) that would want someone to carry out this mission. Each variable that is a requirement for the mission to take place needs to be sought out, from the ship that will be commissioned (you wouldn't go halfway across the universe to a specific shipyard, would you?--poor example probably), to the entities you interact with.

However, you did bring up a VERY valid and VERY interesting point when you referenced that software installs based on the current configuration of a machine. Unless it is a basic installation script (which let's face it, if it was a basic install script it wouldn't need to analyze your system before it installs), most of those scripts compile sub-scripts on the fly which are then the real script that is ran to install your software. Oracle for example used to compile some files at install time and did many of the things you described.

Then, thinking of that, we circle back to one more important piece. I'm going to go out on a limb here, so bare with me and let me know whether I'm on target or way off base:

The idea behind adding in a parser or interpreter so you can load your own missions is because you want control that the mission generator (mission generator as in whatever Josh codes to create the missions) doesn't have, or more depth than what the generator can come up with. This would also stand to reason that the mission generator is capable of at least some of the more basic missions (take out the patrol here, deliver the goods here, etc). So then we want to script a mission that is outside that box. Anything other than a fairly basic mission, i.e. one that the generator can come up with on its own, eventually starts getting compounded into something where the script interpreter may be searching for quite a few variables and the right instance of them in different sectors in order for the mission to even exist. It works great in simple scenarios, but once you start getting beyond the realm of what can be made by the AI, then you're needing much more. Besides, if you were just going to use it for the simple stuff, then that would either mean the in-game generator is crap (which I doubt it will be), or you're just wanting to recreate the wheel that is already supplied in-game.

The explanation you provided actually does a good job conveying what you mean though.

DWMagus wrote:The basis is that the mission needs to get from one instance of the game to another, regardless of the methodology.
But after your next explanation, that point is actually moot.

I'd go so far as to say that getting a mission from one game instance to another would be nigh on impossible, or at least far more problematic than it's worth. Far easier to apply a single externally-created source script to two different game instances, as the resultant mission instances will almost certainly be different. The story source will need to be "hooked" to the local game state.

There you go, spawning an NPC. Keep in mind that if a mission exists, it's because there's reason for it to exist. This is also what I meant when I said it could get complicated fast--The script has access to local variables that determine the whereabouts of a pirate fleet. It wouldn't stop there.

I think it would be hard to apply missions without spawning at least some gamespace objects, though it may sometimes be possible to apply it only to existing reusable objects such as background NPCs in bars. The whole point about writing missions is to create one that doesn't exist in the game by AI generation, so as to provide a human-created story.

However, that's where the issues of good practice and skillfull storytelling become relevant; good practice would involve creating a minimal gamespace footprint, e.g. only adding a few NPCs in stations whose presence is unlikely to have any significant impact on the rest of the game. Bad practice would be to do the opposite, e.g. spawn a giant battlefleet in the middle of a core system. For any game that allows any sort of user creation, this is always an issue; nevertheless excellent creations do get made and are valued. I suggest no different here.

I also suggested the idea of creating a temporary "system room" to allow spawning of story-specific objects if they're of the large footprint type, so that they would still not interfere with the rest of the dynamic universe. If the player has unique access, then the only resultant gameworld changes made will be to the player. At the end of the mission, the room is simply deleted.

Then, thinking of that, we circle back to one more important piece. I'm going to go out on a limb here, so bare with me and let me know whether I'm on target or way off base:

The idea behind adding in a parser or interpreter so you can load your own missions is because you want control that the mission generator (mission generator as in whatever Josh codes to create the missions) doesn't have, or more depth than what the generator can come up with. This would also stand to reason that the mission generator is capable of at least some of the more basic missions (take out the patrol here, deliver the goods here, etc). So then we want to script a mission that is outside that box. Anything other than a fairly basic mission, i.e. one that the generator can come up with on its own, eventually starts getting compounded into something where the script interpreter may be searching for quite a few variables and the right instance of them in different sectors in order for the mission to even exist. It works great in simple scenarios, but once you start getting beyond the realm of what can be made by the AI, then you're needing much more. Besides, if you were just going to use it for the simple stuff, then that would either mean the in-game generator is crap (which I doubt it will be), or you're just wanting to recreate the wheel that is already supplied in-game.

Well, I'm not the OP here, I just got intrigued by the idea so threw in some suggestions as to how it might be possible.

The "story compiler" (for want of a better term) would indeed have to be able to access certain game state variables, so as to plug itself in. Maybe more like a linker, actually. However, I'd guess the AI is going to have to do something like that anyway, e.g. create NPCs with story arcs which depend on interaction with other objects which may or may not yet exist. Information about these other objects would have to be known i.e. there would have to be a game "database" of objects that can be accessed, including their state. Inserting objects (i.e. spawning) would have to be an option, as well as modification (e.g. adding a story script to an existing NPC). So in some ways it's like a database handling exercise; search for certain objects you want to use, modify them appropriately, maybe insert a few too. Plus enough bizlogic to handle the progression of the story. That's why I suggested an API might be the way to go.

As for the reasons, you're partly hitting the nail on the head. I reckon the AI will provide a rich background of "everyday life in a tough, detailed universe", where the missions will reflect what's going on. I'm actually pretty excited about that, as I think this has the potential to go far beyond what any other game has done, and Josh's abilities and enthusiasm clearly inspire great confidence in us.

However, even in a rich, detailed, immersive world, (including the real one!) we love stories, and value the personalities that create them. Basically, we love human-made stories, and most of them involve the sort of escapism, fantasy or deviation from everyday life that catches our attention. So, in LT, I like the idea that such human-created stories could also be possible. Whether I'm a station-side PI and some dame walks into my office, or a hat-wearing adventurer who hears a rumour of a lost treasure on a wandering space rock, the value of human-crafted stories should not be disregarded. I think it could add further richness to an already rich game. However, I'm also aware it may be totally impractical - hence the value of brainstorming the possibilities.

JabbleWok wrote:I think it would be hard to apply missions without spawning at least some gamespace objects, though it may sometimes be possible to apply it only to existing reusable objects such as background NPCs in bars. The whole point about writing missions is to create one that doesn't exist in the game by AI generation, so as to provide a human-created story.

When it comes to NPCs, here's what I'm imagining;

Back when I played Roller Coaster Tycoon 1 and 2, each guest that entered the park had unique information (sure, it was randomly generated, but still unique). You could have thousands of guests in your park at once, and the game didn't slow down. This means that every 1,000 guests would be riding a ride, walking around, purchasing food/souvenirs or sitting and taking a break. Each game entity had a name, an amount of money, a hunger level, entertainment level, as well as an inventory.

Now, if this was able to be done with hardware from 10+ years ago, I believe it stands to reason that at the time of universe creation, we can generate thousands of NPCs without issue, and we should be able to generate enough that we shouldn't need to spawn them for mission generation. Maybe 5k unique NPCs that can be interacted with in some way, and then plenty of 'extras' that can't be interacted with spawning and despawning at will. This is kind of what I meant when I said that if it is done well, the player shouldn't notice. As long as the number of 'usable' NPCs are larger (at least by a single magnitude, if not more) than one's Monkey Sphere, it shouldn't be a problem.

JabbleWok wrote:The "story compiler" (for want of a better term) would indeed have to be able to access certain game state variables, so as to plug itself in. Maybe more like a linker, actually. However, I'd guess the AI is going to have to do something like that anyway, e.g. create NPCs with story arcs which depend on interaction with other objects which may or may not yet exist. Information about these other objects would have to be known i.e. there would have to be a game "database" of objects that can be accessed, including their state. Inserting objects (i.e. spawning) would have to be an option, as well as modification (e.g. adding a story script to an existing NPC). So in some ways it's like a database handling exercise; search for certain objects you want to use, modify them appropriately, maybe insert a few too. Plus enough bizlogic to handle the progression of the story. That's why I suggested an API might be the way to go.

Comparing to a database is probably the best analogy. If that is the case, then it would be a lot easier. If you had every entity as an entry in SQL for example, then being able to do a single select statement to pull out the right one would be easy. So in that instance, yeah it works.

But then the issue still at hand, is what happens if the mission you have scripted, if the engine doesn't have the correct entities or layouts needed for the mission? Would you just go to a part of the universe that hasn't been explored (i.e. generated) and generate those variables there? That's good and all, but after a few loaded missions, your universe is now orders of magnitude larger in order to compensate.

If this is to be done, there needs to be an elegant, yet simple way to achieve it.