With the size of game development teams it really depends on what you're working on (And I'd speculate, that less people work on engines than on game systems). Only the really big studios roll their own engines. Looking at something like Watchdogs, there are also people involved in writing Quest and Dialogue systems etc. for the game designers and these things are quite mundane.
> Quest and Dialogue systems etc. for the game designers and these things are quite mundane.
Depends what you want from them. I've written a small quest and dialog system for my indie game (never finished, as most of my side projects :( ), and it was quite involved.
I used a graph programming library ( https://github.com/ajuc/pefjs ) to create graphs of nodes where each edge is a blocking condition (is the $MONSTER alive? is player near $NPC?) and each node is next step in a quest (with some actions if needed).
Then there was a in-memory database allowing to record arbitrary metadata that quests might require. Stuff like "have the player killed that monster", "does the player have the quest item equipped", "have the player talked with one of these 4 people about X", "has any NPC seen the player near the $PLACE during $EVENT".
I briefly considered adding gossips - if $NPC1 seen player commit murder and $NPC2 meets $NPC1 - then $NPC2 remembers that too, and remember who told them. But then I calculated how much memory that would need and it's staggering. And players won't notice anyway most likely. But it would be so cool.
Once you start recording data about data (does $NPC2 know about the fact that $NPC1 seen player commit murder?) it's hard to know where to stop.
Anyway, even without these - there's lots of that stuff and it needs indexing and filtering. I considered using some in-memory SQL database or datalog, but eventually just rolled my own with basic hashmap indexing.
Then there was dialog system and I wanted more variety than the same responses every time, so I created sets of possible greetings and goodbyes, confirmations, negations, reaction to repeatedly asking the same question, etc. Then the system chooses randomly from the list (each "kind" of NPC has separate list - one for working class characters, one for strangers, one for scholarly types, and special lists for important NPCs).
You can also parametrize dialogs with data from quest database - so you can for example ask the player about his new $COLOR $BRAND vehicle when he comes to see the NPC the first time after the purchase.
There's lots of interesting stuff to do there, even if it's not visual.
If you want to record a ton of boolean values you should look into sparse bitsets like roaring bitmaps. You can encode a ton of information that way and serdes is trivial.
My best idea was to assign "importance" to each event, and only record when each NPCs met and for how long.
Then when I check if NPC x knows about EVENT y I check who he met between time of the event and now and look at importance (witnessed murder would be high) and if there's a path for the information to pass - then he knows.
But it's too much work to do in every "tick" of the quest process. It should only be checked when something changed (someone who knows meets someone else).
It became too complicated system for just a few usages and some background gossip. But I think for a big RPG it could be great. Would allow more reactive world and more interesting quest design.
I think the main reason AAA games don't do this is voice overs. If we had good emotional speech synthesis a lot of new possibilities would open. So indies have an advantage here because text-only is still accepted.
That kind of lookup seems like a great use case for a graph database. These kinds of queries are trivial and reasonably fast there.
I think where such a system would shine is in background banter. The player has to observe the NPCs telling each other these facts so he can appreciate it. That also opens the door for the player stepping in to prevent the spread of information. With the right setting that could be a major game mechanic
> I briefly considered adding gossips - if $NPC1 seen player commit murder and $NPC2 meets $NPC1 - then $NPC2 remembers that too, and remember who told them.
I think we are getting here with natural language understanding.
Rather having to write statements and handle the logic on a per-agent basis. We could keep a database of events with a brief description of what occurred, and use some NLU engine to use that description to form statements and opinions on the subject at hand.
It could even incorporate sentiment by having favorably weights between groups. So let's say, elves hate dwarves, and an event occurred where "Belegost (dwarven city) was razed (terrible action) by armies of Gondolin(elven city." The event name would run though a NLP system to which would make elven characters see the event more favorable than dwarven ones.
I'm not saying these are cool and impressive engineering projects. I've studied games engineering and also worked on small scale games, but there is an enormous difference between optimized graphics/game engine code and what you and I did.
I did 3d graphics too even some shaders for commercial projects (not games - enhanced vision devices for partially blind people). I did some basic (archais by now) 3d rendering techniques (BSP trees, portals, quadtrees) in my hobby games.
I don't think one is inherently harder or more cool than the other.
You can look at Dwarf Fortress for gameplay/quest/dialogs and Cyberpunk 2077 for graphic, and it would be as cool and hard as each other IMHO.
