Improbable Icon

Structuring the Game World

v10-1-0

#1

I’m hoping to get some feedback on how to structure/architect a mystery based RPG.

The player starts in a village with multiple NPCs, think Skyrim, and has the opportunity to take on quests that require to be generated by complex AI algorithm as the player explores the world. The player can invite other players, friends, to help and join them in the quest. Think grouping like in Neverwinter.

  1. My initial thought is to generate quests, via a quest creator, similar to the architecture of forming terrain using the Spatial OS architecture.
  2. Quest creator is a single centralised agent for each player, i.e. it is initiated when the player first logs on and then its state is persisted somewhere and reinitialised when the player next logs on
  3. Other players should be able to participate in the quests. Soo store the quests in some manner that can be accessed by other players, and I think there is probably excellent support for that outside SOS, but I’m not familiar with that.
  4. Quest creator propagates new quests to relevant NPCs.
  5. Quest creator may need to instantiate new NPCs for a quest.

So as you can tell by above, the Quest Creators needs to be rather robust and independent and to have some privileges to create new NPCs etc.


#3

Hey @Vimes, sounds really interesting I’d like to help. A few clarification questions:

a. What game engine are you using?
b. Is your game a full MMO or do players have their own instances of the world that friends temporarily join in to help?
c. Do the quests you are referring to take part in a shared MMO world? (By this, I mean quests that structurally function like we see in most modern MMOs but with more depth and nuance added from your question generation algorithm)
d. When you say generate a quest, could you go into a little more detail for me as to what processes would be involved? From what I can tell, certain objectives need to be determined and presented to the player, certain NPCs need to be spawned, existing NPCs might have their behaviors altered for the duration of the quest (how will this effect other players not participating in the quest?), and maybe some items or other objects will need to be spawned into the world. In addition to this, do you need to generate additional terrain, or other stuff that I’m missing?


#4

I’m also interested about quests topic. How this could be make?
Quest manager could be entity started with worker on start world or maybe is better if this will be Player component I think.
Creating one manager for all player could be problematic I think but I don’t think about all aspects of the quest system. Maybe player could only store quests progress
Also how can I use snapshot to store information about what quest was finished, accepted just questID is variable to store and Quest Manager in player entity send for this information and also this must be information about this player not other player


#5

One possible question management system I can envision would be to create a QuestManager entity for each quest, which would be either be positioned at the location the quest takes place, or move along with the main player heading up the quest. This entity would contain all of the relevant information about the quest as it takes place, and be the central point for controlling any behaviors that need to take place in the quest.

As for your question about snapshots, they aren’t quite used in this way. Snapshots allow you to persist the store the state of a deployment, even if it is offline. Most commonly, they are used to set up the start of what a world will look like when a deployment is launched. They can also be used to store the current state of a deployment if it needs to be taken down so it can be restored.

For storing information about previous quests that have been completed, each player entity could have a quest history component that stores this information. An alternative could be to use an external database to store long term data.


#6

@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!

:1st_place_medal:
Your questions:
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 :blush: 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 :slight_smile:

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

  1. 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.
  2. 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.
  3. Manage validation and integrity, i.e. cheating prevention and similar.
  4. 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.

  1. 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.
  2. 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.
  3. The DM will also when required give the NPC additional knowledge when directing it in the course of the quest.
  4. 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:

  1. 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.
  2. 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.


#7

Hi @Vimes, sorry for the delay in getting you a response on this. This stuff sounds really awesome and it’s great to see how much thought you’ve put into designing this system. For the design there is only one significant change I’d make for the time being.

I am concerned by the one worker per quest or player paradigms you suggested. The latter seems preferable of the two to my eyes, but unless your DM algorithm is incredibly computationally expensive or is interacting with a lot of entities, assigning a single worker to run a single DM would probably be overkill. Furthermore, even if it wasn’t overkill, this might make scaling more of a challenged because you are locked into a rigid paradigm of one DM worker per player (or something of that sort).
Instead, I would really recommend considering a way to think about a DM as an entity, rather than a worker itself. This entity, via it’s components, would contain all of the information necessary about the various pieces of the ongoing quest (or quests) relevant to a specific player. Then you would have many DM workers which would be authoritative over the DM entities, and on each entity they would run the same logic you described before. However, because the DM information relevant to each DM is stored on individual entities, this would allow a single DM worker to have authority over multiple DM entities at any given time, allowing the SpatialOS loadbalancer to balance the workload between all of these workers.

Beyond this, I think you should be good to go with what you have. There are obviously a lot of smaller SpatialOS related challenges you will have to come across in building this system into your game, but for those feel free to drop us a specific line when you come across them. For instance, I believe there are multiple potentially correct answers for how to structure the schema that enables communication between your DMs, NPCs, Players, etc.

Super awesome that you’ve gone through the rigor of doing all of this design work up front. I’m excited to follow as you make progress. And if anything I’ve said here doesn’t make sense, please let me know so I can be of more help.


#8

Thanks @Kevin, That is a different perspective that may greatly improve the design and make it more applicable to the Spatial OS architecture.

I will look at that over a few days and come back to you.


#9

I have been looking at this based on your feedback @Kevin.

This is a very good observation, and I see I have been looking at it from the more conventional object-oriented view where each entity handles all its functions decoupled from rest of the application and have been thinking of the workers in that manner which really is not the architecture of Spatial OS.

Excellent suggestion, you are absolutely spot on in that the DM and the QG both have very light processing and they are only reactive to NPCs and Player actions. Moreover, they share many of the same functions and attributes and it makes more sense to have them in a single worker implementation handling any DM and QG tasks for multiple players and NPCs and have it loadbalanced by Spatial OS.

I’m currently working on this initial impl as that worker will start of the NPCs with roles and simple initial AI to navigate their town etc.

Thanks! Yes, there are a lot of questions that I have and will have more, I’m starting with first things first. :slight_smile:
I will raise separate topics for specific questions on Spatial OS or the Improbable SDK.

Thanks! The reason I lay out a structured draft to solicit feedback at the start is because I’m a senior dev and worked on many large systems using a number of programming languages and it is my humble experience that to set off to do something as large, complex and ambitious as the intentions are for this game without a good initial architecture will cause an incredible amount of difficulties in terms of maintenance, additions, performance, resource handling, etc. down the line and at the worst possible moments.
So while it is exciting and tempting to just hack away, rather than spend a lot of time designing a quality architecture, it is not going to help in getting a functional end product :slight_smile:

I’m also learning the Spatial OS architecture and how to use it effectively and understand this new perspective which I find really exciting!