@Kevin , thanks, excellent questions.
In fact, the reason I’m so delayed in replying is that I realised I couldn’t really give a clear picture so I have spent the time formalising the goals and reading the Spatial OS docs which are excellent by the way.
You guys have really been putting quality efforts into improving them and I find them now to be really comprehensive, concise and clearly written and accessible for beginners in Spatial OS like myself!
a. Unity 5.6.0, we update it along with which version Spatial OS supports best.
b, c. The basic idea is a full-on MMO, with players seeing lots of other players and can interact and such so we are designing with that in mind.
Although we are starting with just setting up for one player per instance in order to get the basic gameplay working first before adding on the complexity of player-player interaction. So I’m asking in terms of having multiple players per instance.
d. You are absolutely spot on:
“certain objectives need to be determined and presented to the player, certain NPCs need to be spawned, existing NPCs might have their behaviours altered for the duration of the quest”
Adding the detail, this is a long read we have a complex AI engine, a product of an Academic research, that generates quests that are in the form of mysteries or drama and it is heavily based on dialogue and player NPC interaction.
In many cases there isn’t necessarily a correct or optimal path to take although solving the mysteries is the main goal of the game and being able to solve them with friends/other players.
I expect it sounds as if having just one instance per player and be able to invite other players to that instance sounds more appropriate which is a valid argument/opinion.
We do have the vision though that being able to interact with multiple other players and form alliances etc is such a fun element that it would really enrich the gameplay.
There will be multiple quests active for each player if they choose to accept them all
The decisions that the player makes will dramatically affect the course and outcome of the drama these quests are built on prior actions of the player and state of the world and are bespoke per player. They should still work similar to what you see in most MMOs. Players can interact with the same NPC but are not working on the same quest unless they shared it with each other.
We will be using C++ managed workers for the AI because the libraries used are in C++.
There are four specific agents in the AI algorithm; Quest generator, Dungeon Master, NPC, Player:
Quest generator (QG): This algorithm does not require to send any communication to other algorithms or NPCs in order to generate the quest. It just needs a current state of the world relevant to where the player is and it will generate the blueprint of the quest which it then sends to the DM.
so the Quest generator can be a separate worker entirely.
We will have this as a C++ managed worker.
Dungeon Master(DM): Has a very complex task ahead
- Set up the quest and providing any NPC that is required with the quest details regarding their role, context etc. The NPCs will need to manage adding it to their existing roles if any. If they are unable to accommodate the role, perhaps because of other roles for the player or other players, they will reject the new role and the DM will need to find someone else to fill the role. If failing to do so it will send the fail signal to the quest generator.
- Structure and direct the path of the quest or drama in a similar manner as a DM would in D&D. This means sending a number of messages to the NPCs and Player and due to the added issue of multiple players that have quests that may share the same NPC the DM will need to be able to accommodate an NPC taking very unexpected actions. This should hopefully make the experience really novel and be engaging for the player while at the same time it is technically challenging.
- Manage validation and integrity, i.e. cheating prevention and similar.
- Manage experience points and rewards.
a. One way is a single DM as a C++ managed worker per active quest. The DM should not know of other quests or attempt to manage them.
That would mean the volume of workers is C++ managed worker * players * quests.
I’m aware that this is an exponential growth which concerns me. Although it is doubtful that the player would have a huge number of quests active and it can be easily limited anyway.
b. An alternative in order to limit the number of workers is one C++ managed worker per player that runs multiple DMs if required. This could be load balanced if needed.
NPC: They also have complex AI algorithm, they are what we call deep agents and are autonomous. They have possibly an even greater task than the DM.
- They decide on the fly how to respond to the player given their knowledge base of the world with their AI algorithm. The knowledge base is extencive and will include their basic role such as blacksmith will know about being a blacksmith, their current quests roles have additional knowledge that is given at the start and accumulates as the player engages in the quest etc. It can be quickly reconstructed from certain key parameters and so can be stored in the components similarily to inventory and should be simple to store between games in PlayFab or similar.
- The NPC uses the knowledge base with the AI algorithm to interact with the player both reactively and proactively, i.e it responds to the player and will also address the player directly as part of the role it is playing.
- The DM will also when required give the NPC additional knowledge when directing it in the course of the quest.
- The NPC will have the most current view and logistics on its worldview and which quests and roles it has and will reject instructions from the DM if they are unable to accommodate them.
They will also use C++ managed worker and here is what we are currently thinking of as a structure for the NPC:
- Initially a number of load balanced workers similar to the wizard demo that handles NPCs that have not been added to any quest and are doing very simple shallow day to day life.
- When a NPC is added to a quest it is also given a different worker that handles the more resource heavy computation possible one per NPC but as with the DM, they may be able to share workers.
In this consideration there is the added complexity of the player leaving the area and the NPC not being engaged in the current quest the player is working on etc and so it would be optimal to be able to decommission any worker and delete the entities etc that are not currently in use and just reinitiate when the player starts to interact again.
Player similar to the NPC will receive instructions and msgs from the DM and there will be a current knowledgebase maintained and AI algorithm just as with the NPCs in order to give the player all the relevant options and actions for the game and current quests.
At some point, we also need to think about terrain spawning and such but I will leave that for later.
Any recommendation, advice, input, feedback on above would be really appreciated!?
It is really good to get a solid flexible structure right from the start.