Clive (yapman) wrote in ffproductions,

  • Mood:


It gets tricky when there's a stupidly long thread, and that's where this idea has come from, so I thought I'd give it a nice, visible place of it's own.

I (and apparently jimfer) like the idea of local reputations.

It's a simple concept, that may not be easy to explain, so bear with me if I'm not appearing to make sense.

Every community in the game, will have a reputation score for each player (yeah, I know, it's a damn big table). Actions players take will have an instantaneous effect on the score in their local community (breaking contracts, helping out caravans, supplying desperately needed foodstuffs, whatever). The complicated bit, is where we then have those reputations 'ripple' out from where they occurred. Basically, we then have another (large) table which determines the effect the reputation score in each location affects that in the others, which will be based on things like distance and ease of travel between them. This, then, gets applied at every (daily) update. Also, reputations will tend to decay back to 0 (neutral) over time.

What does this mean? Well, simply put, you can outrun a bad reputation. It should catch up with you eventually, unless of course, you perform good works to counteract it (or it just isn't very bad). Theoretically, depending upon the variables we use, it might be possible to run both a good reputation in one locale, and a bad one in another, although if we decide to allow this, it should be hard.

Now, obviously we have your reputation affect how NPCs interact with your character. The prices you get, the amount any law enforcement harass you, etc. Also, we let players check the local reputation of any players they are interacting with (and I mean the location of the player making the check), in order that they can decide how to react and whether to form contracts, and the like.

So, what do the rest of you think?
  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
Sounds interesting - if complicated. I guess you can have reputation linked to more than just locations - for example there might be a federation of merchants - and each of their hotspots became a beacon of good/bad reputation. But that in turn depends on IC communicaion methods.

Since basically, we have a network of nodes, with unique lines between them all, then we can define the effect along those lines on any basis that we want. We could even be particularly clever, and have them prove slightly dynamic (and automatic) by inflating the effect if there's a particularly high level of traffic between the nodes.

e.g. we could define the function r(x) = f(x) + t(y)
r(x) is the reputation spread from node A to B for player x
f(x) is the base effect between the two nodes based on the difference in reputation at A and B and their relationship
t(y) is a function based on the number of (player and NPC) trips y made between A and B
It might also be an idea for the different groups to have their own reputations with each other i.e. you have a great reputation with group A and a poor reputation with group B. However group B really likes group A meaning the think more of you and give you better terms, etc.

This means that you need to put more though into who you want to be friendly with as it might mean that you make enemies with the wrong people.
It would be lovely, but I suspect that given the effort required to persuade others that we can afford the sheer database size involved with the locational reputation, we might struggle to get this added as well.

Unless of course we took out the regional and added factional, but personally I prefer the regional.
Aargh... you do know what you mean by “big” tables don’t you?

There may have to be a tier or to lost from this scheme before the day is done (or it’s implemented).
Yes, I'm very aware.

one table of size (number of communities) * (number of players)

one table of either (NOC)^2 or (NOC)^2/2

and, if we're really trying to be clever, one other table (NOC)^2/2 for tracking the number of trips between the communities.

Anyway, I have databases that are 4 gigabytes downstairs, what are you worried about?
The daily “ooh, my database is so big, it’s gonna take me 2 months to copy” I get from you.

A 4G database full of pictures of cars (prolly 100k a piece) that no one updates is one thing. We’re talking a v. large database with 108s (I shit you not), of one integer entries. Which all have to be updated based on the state/location of a player. All records must be read/writ.

Size matters not, it’s what you have to do with it that counts.
When things go wrong and you need to shift 4 Gig to the States, it takes a long time, granted. However, my big databases don't have a single photo in them and are in an almost constant state of flux, through on the fly updates. That's the point of them, that the data is fresh, we applied 62 separate update files (each being up to about a meg of SQL code).

This can be done, and I am aware of the implications, but remember, you're only doing things to the whole table once per update cycle, every other time, your only reading/writing to one record.

I've never said this would be easy, but it has the potential to be the cool defining thing that makes us stand out from the others. You don't throw your USP away because it's going to be tricky to implement.
No hardship will hinder us.

Memory and disk can be thrown at the prob, it’s the whole O(N2) on the update that’s fretting me.

That is a lot of sums.

I’ll have another look at the proposition, and see if there is anything can be done.

/me has no printer that works at hand
It is one hell of a lot of sums, that's for sure. Still, the idea will be to make the actual sums very simple. Just think of it like a very big game of life on a board where every node is connected to every other node.
that's not life. it's the universe and everything