Seeking architectural feedback on a multiplayer social reputation prototype

Sounds good. That's quite similar to what I had in mind, too.

I would store a personal psyche per NPC and a collective psyche per city, which is the general sentiment of all NPCs in that city. And then per region, etc., in multiple layers. Actions can either affect individuals at a fine level of detail, or can directly affect a node up higher in the hierarchy, and then the NPCs have to bend to that change in the higher level. That way, you can have local consequences propagate upwards, but you can also impose a coherent state via top-down measures. Forcing changes at a high level can mean retroactively coming up with a cause. I wrote about that kind of stuff a lot in prior threads, one of them being Critique of MUDs, RPGs, DnD, MMORPGs, and immersive interactive adventures.

Anyway, the important part for scaling it is that you must be able to statistically collapse a lower level's nodes into the higher level node, and then only when required, restore the lower level nodes. That lets you have massive worlds that most of the time need no computation, and only when a player is there, have their details fleshed out.

Though in my design, I did not include player reputation. But it can be extended to that. Although in an MMO, that can cause additional problems due to the large player count. Also, you shouldn't try to suggest that NPCs are actual characters with any depth. As soon as that expectation is created in the player, he will inevitably be disappointed, and that can break the entire game for him. Never arouse expectations that you cannot deliver on, even if it means delivering something “worse” than you could have.

First the elephant hiding in the corner:

Implement anything. Your game is not going to be the next Minecraft, Roblox, WoW, Rust, EVE Online, or other widely-played game. You are unlikely to release anything as a hobby developer, even more as a student rather than industry veteran, and even if you do it is statistically going to fail commercially. The value is going to be that you learn and practice and experiment and increase your own skills. In that regard, there is no right or wrong, there is only experimenting and learning and growing in your own right. ANYTHING that you implement will improve your knowledge and skill, so implement anything.

On to the thoughts about the implementation.

I'm a little confused about the data kept with the player and what data is kept with the towns and NPC.

To make sure I understand it, when a player does something townies "know about it". As you're thinking about a larger multiplayer game, quests and actions are repeatable between players and players aren't necessarily at the same point. When you have large, more permanent situations in an RPG the various NPC go from "A dragon is pillaging the countryside" to "thank you for slaying the dragon". The dragon slaying is done and complete in the single player game. But in a game like an MMORPG, every player has the ability to raid the dragon's horde and usually to complete the quest multiple times. The dragon is never really gone. So what you describe is different than a single player experience, more along a "player was here a while ago, and I remember".

When a player does a lot in a region, there would be echo of rumors, which I interpret as other NPCs getting an effect of other NPCs. But they have to have a way to communicate, so that's something. And they know about it in the near term, with an open method of how it is technically implemented regardless of how it is implemented in the story of the game.

I'm not sure if that's a perfect match, but that's how I understand what you described.

So I'd start with what the player does in games today. In a single player game with once-and-done quests, there's one entry per quest indicating it is done or not. Player completes a quest, the bit is flipped, and you can change text as a result. If lookup on quest 2942 is false, "A dragon is pillaging the countryside", if it is true "thank you for slaying the dragon". NPC's don't have any knowledge of it, they're only checking player game state. In a larger game like an MMORPG, that information is kept in a database entry as a quest log as a row, player 833145 completed quest 2942 at {time}. There can be multiple columns, like "did the task" and "collected the reward", but it's still ultimately a table entry. NPCs can still know about it, a query of the form "what is the last time player X completed quest Y" lets NPC's "know" it happened. The NPC still looks up quest 2942. Staleness is known, if the quest can be repeated once per day or once per week, quest 2942 was done at {time}, subtract {now} from {time} and you can see staleness. If it's been more than {cooldown_for_quest} the NPC has completely "forgotten" about the first time. If there is still cooldown remaining, they have decaying knowledge based on how long remains on the cooldown.

In current games that have a memory effect, it generally isn't that the NPC's know what the player did, instead it is that they have knowledge of the quest log items from other regions. Quest 2942 may be in the Gray Hills but that doesn't mean someone in Capitol City can't query about quest 2942, or can't query from a collection of many quests. Maybe the Captain of the Royal Guard knows about all the major quests and can query for all the recent entries, something like a parameterized version of SELECT * FROM questlog WHERE player_id = 833145 AND quest_id IN ( {list of major quests} ) AND completed_date > month_ago Now it feels to the player like the Royal Guard know all about the player's reputation, which they are by virtue of the game's database, but the data is stored with the player not with the royal guard.

So comparing that with what you wrote.

You have the TOWN maintaining the "narrative state" for each player. I suspect you've got that backward. It doesn't really make sense to me for the town to maintain data on millions of players, many may never have visited the town. It makes more sense to me if the town queries the player data, and the players can track what they've actually done. Only players who have actually visited the town need database entries.

If you really want shared knowledge between players, there are a few approaches I'd use depending on the scale of the game. One might be a MRU (Most Recently Used) list of players that visited, maybe maintain the last 100 players to visit the town. Player enters the town there's a single update that puts their player_id at the top of the list. If they were already on the list they're removed and put on the top, otherwise they're put at the top and the ID at the bottom drops off. Now the town knows about the latest 100 players. If it isn't a fixed number, maybe a list of the last time each player_id visited the town, and it becomes a database query as well: SELECT TOP 20 * FROM location_visit_dates WHERE location_id = {town's ID} ORDER BY visit_date, now you know the last 20 players who visited without storing anything in the town's data. Most likely the last visited table is an upsert, updating the last visited date each time you return. That naturally has a falloff as well, you can search by date whether that is the last week, month, or some other time period, and NPC's can naturally know that nobody has visited in a year simply with the query's last visited date being so far back.

You have a lot of data about tracking the player's feeling of reputation, but with the database queries, it's more about a simple query of who has done stuff recently. To the implementation it's a query of the last X times people have done something, taken randomly from the list. Player 833145 shows up in 29 of the last 50 entries in the quest list, so if we pick one randomly they've got a 58% chance of being the player mentioned. To the player it looks like Player 833145 is popular, even though to the implementation they're just picking anyone randomly from the last 50 entries. They are popular because they show up so often in the most recent entries, and they'll naturally fade from memory as more players visit the location and complete quests.

This is true of all real-world 'popularity' systems, too. Popularity is naturally the fallout of the frequency something happens. A news story being popular means that it shows up frequently. It's one of the top 5 news stories so people talk about it, and as people talk about it it remains a top news story because it is frequently mentioned. When people start talking about something else it stops showing up frequently, other stuff is frequently mentioned, so that other stuff dominates the most recently discussed list, therefore popular. The social consciousness has an extremely short memory, there is a reason they are called "15 minutes of fame".

You have information about pricing changes, and manipulating economies in games like this a VERY hard design problem. There need to be both sources and sinks of money. If money is added every time a player completes a quest or kills a monster, you need something that removes money at a similar rate to avoid game-wide inflation. Durability and breaking items, single-use consumables, travel fees, auction houses with fees, and assorted in-game taxes are annoying to players but they are methods to control in-game inflation. If belief about players is a variable in pricing in the world, that will have a profound effect on the in-game economy. You see it in single player games where starting out you struggle to get enough money to buy health potions, but when you're about 80% through the game you've capped out at 999,999 gold and you can't spend it fast enough. In MMO's there is an incredibly long list of games where in-game economies ended up breaking due to inflation and players adopting a secondary economy based on things that are actually valuable and rare in game. By all means implement it in your project however you want, just understand managing the economy of an MMO is often harder than implementing the MMO, and needs to be monitored and managed the entire lifetime of the game.

As for when to update, it definitely would not be tick-based because there is nothing that is changing that rapidly. Most of the items you described only have new events added to the list where the world "knows" about it after perhaps hours of gameplay, some maybe at a half hour, others maybe 20+ hours, but still nothing that happens as often as a tick. Database queries would be on an as-needed basis. The game rarely needs the data, and it isn't needed at a regular basis like a scheduled 5-minute data sweep or something. If you decide to tie the data to the towns or to the NPCs, I would do what you could to make it so they never actually need to update, and if there is anything that needs updates it should only be updated on actual use because it is a rare task.

@frob Thanks for the detailed response — especially the storage/database framing. That genuinely helped.

I think I described the system in a more town-centric way than I intended. Initially I was leaning toward per-player per-town narrative state, but your point about scalability makes a player-centric event log approach much cleaner. Actions generate structured event entries (tag, location, timestamp, weight), and towns would derive perception dynamically by querying relevant recent events instead of persisting long-lived narrative state.

Combined with the hierarchy suggestion above (by RmbRT (individual NPC bias → town aggregation → higher summaries), I’m starting to see this less as “towns remembering players” and more as layered interpretation over raw player events.

Your point about event-driven processing also makes sense — nothing here really needs constant ticking if aggregation happens on interaction or entry. (Maybe I was little off in the head while asking this, I'm joking but appreciate it)

I’m still evaluating whether separating short-term recency impact and longer-term persistence via different decay curves is worth the added complexity, or if a single recency-weighted aggregation is cleaner for MVP. Would be interested in your take on that.

Appreciate the push — this is exactly the kind of structural feedback I was hoping for. Really.

@RmbRT Thanks for the layered breakdown — the individual NPC psyche → town-level aggregation → higher summary structure really clicked for me.

I was originally thinking in more direct “town stores narrative state” terms, but your hierarchy framing makes it feel a lot cleaner and bounded. It helps shift the idea from interconnected rumor webs to layered interpretation over structured data.

Appreciate the structural perspective — it definitely made me rethink how to contain complexity instead of letting it sprawl. And for days to come I'll keep this in mind.

You can track player actions sort-of like an achievement system. Killing miners would stop the ore production in a mine, and induce fear and unrest in the surrounding region, and lower the safety score of the region overall, and especially the mine, meaning merchants maybe have more guards, and the mine will be heavily guarded. And the player can be given outlaw points, which accumulate as he does more misdeeds. Once he reaches a threshold, maybe he can officially be classified as a bandit, and that may open up mechanical interactions, such as subjugating other small-fry bandits and becoming the leader of the local bandits or something. And then you can accumulate more points until you get regional control, etc.. And the higher your banditry level, the stronger and more frequent the dispatched subjugation forces would be that are after your head. And you can also do the opposite and open up a priest route that is achievement-based. Or a pacifist route, where you get something for never attacking, or maybe a paladin route where you can only attack heretics or something. Or hunting bandits can lead to a route that opens up interactions towards being a knight of justice or something, maybe letting you become a leader of the town militia or something. All this would be pretty straightforward, as you would just have to be able to catch those events and accumulate their worth towards separate counters. The player does not necessarily have to be able to inspect this achievement system and its counters.

Also, what @frob pointed out is exactly what I criticised in the linked thread, somewhere, about how in an MMO, everyone is playing in the same world, but getting a single player story experience, and the world has been saved thousands of times before, but you get to save it again yourself. This means all story is just flavour text because everyone lives in a shared world. So plot could never affect the landscape or something like that, or maybe only in per-player level instances.

I am completely against fixed storytelling in an MMO, because it creates this sense of discrepancy. MMOs are actually just single player or co-op games, but with a social hub in each town. In my envisioning of the genre, there exists only one dragon in that region, and only one party can slay it, and then it's dead, until something else shows up. Maybe a lich with its undead army rises up and threatens the region next time. In return, you can up the realism and make it so that slaying the dragon is actually hard and notable enough so that not just the NPCs will talk about it, but also other players would find it noteworthy.

Disclaimer: I only read the original post and haven't followed the entire conversation.

It sounds like you have some interesting ideas, but it sounds still fairly vague in terms of what sort of actions will exist and how recording those specifics will become gameplay.

If the rumors boil down to gameplay only based on some stress level, well that still sounds a whole lot like a reputation system to me?

As far as having a sort of “interaction history” log for town members, or maybe just with the player, it depends if we're talking about 100s or 1000s of these. If you're going to be searching these a lot, I can imagine you'll end up spending a bit of effort optimizing it to run fast.

@rmbrt Thanks for the breakdown — the way you framed it as structured point accumulation tied to thresholds made it easier to follow through.

That lines up pretty closely with the direction I’m narrowing it down to for MVP. Instead of trying to simulate full rumor diffusion right away, I’m leaning toward event logs that aggregate into tag-based scores, then applying town-level baselines and NPC personality modifiers on top. Once certain thresholds are crossed, reactions change (and later those could open alternative paths — something like infamy routes depending on what kind of behavior accumulated).

For now I’m trying to keep it contained and implementable before layering more interpretation mechanics on top. Your comment helped with that reframing, so appreciate it.

If you notice any obvious pitfalls with that structure at smaller scale, I’d definitely be interested to hear them.

please don't use AI to flatter me, thank you.

@rmbrt Lol, I can assure you that it's not AI, It's a project that I'm trying to take seriously for once. So for that I'm trying to be as clear as i can with my intentions on what I'm trying to implement and what can be its pros and cons

As I mentioned, I'm still in learning stage when it comes implementing such complex tasks, so I thought feedback from professionals would be better instead of working alone on it.

But no worries, I can see why it'd sound like it's AI-generated and I apologise if it came across that way, thanks for the structural feedback up so far, really appreciate it as a newbie

I'm not against using the em-dash (—), but the use of that symbol together with low-key flattery makes me think your posts are written by AI. Also the fact that you don't use this site's formatted lists feature in your posts. It is a prominent button in the text field. So I assume you let an AI write your post, and then copy-pasted it into the text field.

RmbRT wrote:

I'm not against using the em-dash (—), but the use of that symbol together with low-key flattery makes me think your posts are written by AI. Also the fact that you don't use this site's formatted lists feature in your posts. It is a prominent button in the text field. So I assume you let an AI write your post, and then copy-pasted it into the text field.

Apologies for the late reply, I had my final this week. And yea, got it, I'm not saying that it wasn't flattery but I wanted to show gratitude right where it's due, and the em dashes, in my opinion makes it kinda professional? But now I know, no. So will be just more casual than before now. Hope you wouldn't mind it.

And about the formatting, I'm not very familiar with forum formatting, as I usually draft my rough replies in my notes and tailor them accordingly to the mechanics and help I need, so it is copy-pasted, but just from my notes.