Others Graph theory problem - need help

[toolkitxx]

I have been eating on this problem for a bit now and decided to ask here for input since i cant seem to find a decent solution - so hopefully someone has a good idea to remove the brickwall in front of my head

In a given social network the player is a central figure. The player belongs to a given social group at the beginning but is capable of changing that throughout the gameplay.
The problem i am trying to solve is as in the picture:

Spoiler: Situation

You don't have permission to view the spoiler content. Log in or register now.

The player calls a friend (node 1) and they exchange some juicy gossip about Node 6. Node 6 is an enemy of the player and not part of the same social group.

My current system works with weighted edges - those are the friends in the picture. Thus it was easy to spread information but the spread was unsatisfactory since it wouldnt spread outside of trusted/friendly nodes.
What i am trying to achieve is that the information 'leaks' further by some form of proper mechanism without just being random or fully along lines of people who just know each other.

Any ideas?

 

[Meaning Less]

Well if you want realism.
Do your game has a system that moves people around the map or something?
If so you could spread the gossip directly from one person to the next once they interact or are closeby, that way if they bump into an unknown person you can give it a chance of spreading gossip that will vary based on their friendship level and closeness.

 

[toolkitxx]

Well if you want realism.
Do your game has a system that moves people around the map or something?
If so you could spread the gossip directly from one person to the next once they interact or are closeby, that way if they bump into an unknown person you can give it a chance of spreading gossip that will vary based on their friendship level and closeness.

They indeed move around. The point is less that i dont have general ideas but trouble getting this into some proper algorithm in a graph. Rumours spread slowly unless it is something so outrageous or an emergency that would start a telephone chain. The direct spread between friends is what happens currently which means the function ends with that after it has reached the end of a friend/trust path.

Each node(character) has knowledge. In cases of friendship/trust the function sets this knowledge at the receiver/all receivers in a path that is at least trust/friend. Relations between characters can actually change meaning edge weight can change too. The lowest form in this case is the thin line (edge weight 1) meaning they just know each other or know of each other due to social grouping (colleagues for example). This is where things get tricky as rumours dont just spread in those cases like other information. Idea is that it first trickles throughout the same social group and in cases of bridges also can trickle into other groups but not with just 'simple' connections. Bridges have to be trust/friend relations to make that happen as there is usually a barrier between groups that prevent such flow. Example would be a work gossip not having any relevance for a group of people in the same gym club unless the receiver is either a colleague too or a friend.

Knowledge is basically just a card on a deck of things for a node(character). They either have it or not. So any rumours are treated like any other knowledge basically once on the deck. Knowledge doesnt spread automatically usually - only rumour stuff should. Which is why i need/prefer to have it in one algorithm.

But i am going to ponder about the interaction part a bit. My NPCs move around but real interaction is always connected to the player. So i might need to find some hack there.

 

[Tompte]

Here's something I'd try:

Create two list of nodes; an "open list" and a "closed list".
Add the friend's node to the closed list.
Add the remaining nodes to the open list and sort them by the shortest edge distance to the friend's node.
(Exclude the player node from the graph since they wouldn't be involved with spreading the rumor.)

For all nodes in the open list, ordered by shortest distance:

• For all edges connected to a node in the closed list:
  • If it's connected to a node with the rumor, use the edge weight as a probability and roll whether the current node learns the rumor or not.
  • If the rumor is learned, move the node from the open list to the closed list.
  • Also, if there are no connections to anyone who knows the rumor, move the node from the open list to the closed list.
• If all edges were checked (i.e. all neighboring nodes are in the closed list), move the node from the open list to the closed list, otherwise leave it in the open list.
• Loop until all nodes are in the closed list.

Edit: I updated the algorithm because I realized there were some graph configurations that would yield wrong results. It's basically the same method but with two lists instead of one to ensure the rumor could still spread through a longer path if it didn't spread via a shorter one.

 

[toolkitxx]

Here's something I'd try:

Add all nodes to a list and sort them by the shortest edge distance to the source of the rumor (i.e. the friend). Exclude the player node from the graph, since they wouldn't be involved with spreading the rumor.

Loop through the list, from shortest distance to longest distance:

• If the current node is not connected to anyone who knows the rumor; skip that node.
• If the current node is connected to one or more nodes with the rumor, use the edge weights as probabilities and roll whether they learn the rumor or not. Do that for each edge connected to someone with the rumor.

That's it. By the end of the loop, the rumor should have propagated through the graph by edge weight and distance.
I kind of just came up with this on the fly and I haven't tested or checked it but I think it might work.

The player is currently the only node that actively starts 'rumour' - which actually is all kinds of stuff not only actual rumours. Can also be lewd activity being observed by someone but it will use the same function.

But your idea can actually work. Once the function reaches the current end it will have found all directly connected trust/friend nodes. Then turning to your list idea to propagate further into connected nodes via your idea is actually a great idea. If i change my current edge weight to include an extra value for people in the same social group (so 1 for know the node, 2 for know a node and is same social group) this will actually take care of my bridge problem. Unless the 2 bridge nodes are friends the edge will only have weight 1 and the algorithm will not spread. But when they are friends the edge will be 2 or more and the information can spread.

Fantastic! I am going to test this right away

 

[Tompte]

I edited my post to fix some 'bugs' in my thinking. As with most of my ideas they get better after a few iterations. It's a little more complicated but not by a lot. The first version would still work most of the time I think.

The general idea is that by sorting the nodes by distance you can loop through the graph like layers of an onion. Knowing that, it gets a little easier and you can play around with different approaches.

 

[Saki_Sliz]

The point is less that i dont have general ideas but trouble getting this into some proper algorithm in a graph.

THIS. this is more or less my specialty (digital signal processing), so sorry for the coming wall of text. I was debating weather I should actually 'send' this since I don't know how much use it will actually be.

I've been working on a few things, and since this is the first time I'm reading this, right now I'm not fully grasping what it is you are trying to do.

As I hinted at, it sounds like you are working on a graph/node/network/system 'thing' and are working with information being spread/propagated, which as core to 'digital signal processing' which is one of my favorite subjects! Infact, I am designing my own neural network based on my own philosophies of digital signal processing. The issue with that is, I have my own set of terminology, and think of the problem in ways that may not match how you are currently handling things, so I may not be able to sync up 1:1 with what you are saying or trying to do.

So the player (and only the player) states a rumor. For me, I imagine this as starting out with a basic game mechanic to 'start' a rumor. Lets say this game mechanic starts with the player needing to 'learn' a bit of information (catches node 6 doing something), that 'unlocks' a new dialog option to have with node 1. the 'starting' of a rumor is simply clicking on the now available dialog option.

From that point on, its up to your 'algorithm' to distribute the rumor, and for the individual 'AIs' to dynamically react to the character (and rumor) based on that AI's understanding of the rumor.

I say it like this to break down the problem into two separate parts, 'the algorithm' which computes a number for every node (relative to each unique rumor or something), and 'AI' which is where we throw all the complex 'reactions' and deal with that part of the puzzle later.

From what I understand, you have two issues you want to solve:

1) It sounds like you have some basic way of modeling how the rumor 'spreads' however, the first issue is that

the spread was unsatisfactory since it wouldnt spread outside of trusted/friendly nodes.

and

The direct spread between friends is what happens currently which means the function ends with that after it has reached the end of a friend/trust path.

and you are looking for suggestions on how to 'design' your system to achieve a 'spread' that you like, as right now its not behaving how you would like it to.

2)

The point is less that i dont have general ideas but trouble getting this into some proper algorithm in a graph.

I not sure if you are using 'graph' to mean, designing how the nodes should behave and shown graphically, or if you literally mean a graph, showing you how data would propagate over time.

The reason I am jumping into this, with my wall of text, is this sounds like the kind of work I do irl. Digital signal processing, control theory, and control systems engineering is my field of interest and occupation, and pretty much work with similar node graphs. There is a lot to say and do. I bring up the warning about my particular vocabulary and problem solving techniques because If I just start throwing words at you, that probably wouldn't be the most useful. Simple questions like "what are you trying to do" have lots of ways of answering them based on what kind of mental 'frame' or perspective one has when asking and answering the question.

So, I'll first ask, what kind of output do you want? I'm not asking: how do you want information to spread? Lets skip that, that's getting too deep into the details when we haven't set up the basics yet.

Knowledge is basically just a card on a deck of things for a node(character). They either have it or not.

So that means, it's boolean. Characters can either 'act' on information or 'knowledge' or they can't 'act' on something because they don't know it yet. Are you sure that's all you want to do? Do you need to worry about 'where' they got information from? I say worry, but really I mean, do you want. Is this like where the NPC's 'say' where they heard something from? Similarly, do you need to worry about when, do characters react different depending on how recent the information is and does it matter how long ago since they initially heard the rumor? You say they (NPCs) know or don't know, but do you need to generate any other data that NPC's will use for certain behavers?

Lets say, worst case scenario, you want the following type of data than NPC AI could work with:

• Rumor Heard from 0 to 100% (aka analog rather than binary/digital) (AI reaction may change depending on how much they know)
• Rumor Confidence 0 to 100% (AI reaction may change depending on how much they believe the rumor)
• Rumor Source Ratio (who did they learn 'what' from)
• Rumor delay (how long did it take for the rumor to reach them)
• Rumor relevance (how old is this rumor relative to 'now')

It also sounds like rumors have 'sub properties' which also affect both the AI and how data is distributed through the 'network'

unless it is something so outrageous or an emergency that would start a telephone chain.

Even with all that 'listed out' we still wouldn't be ready to talk about how to model the network yet, because there are still some nuances that are important in designing the network. You already know them, but I don't, things related to gameplay. You said that characters will be walking (moving in some way) around in the world, which may or may not affect things, maybe in teh future you want a mechanism where relationships could change, and then you also seem to highlight a concept of 'time' as with the key word 'trickle'

Idea is that it first trickles throughout the same social group and in cases of bridges also can trickle into other groups but not with just 'simple' connections. Bridges have to be trust/friend relations to make that happen as there is usually a barrier between groups that prevent such flow. Example would be a work gossip not having any relevance for a group of people in the same gym club unless the receiver is either a colleague too or a friend.

The reason i bring up game mechanics, is to figure out how would we measure things? What do NPC's do, this is why I bring up the concept of 'acting' on information/knowledge. knowing how npc's are affected by the 'rumor' is how we will measure things. Lets say, the simplest case is boolean, maybe you have it writen such that, characters will interact one way with the player, and interact another way when the npc hear the rumor. Since it is boolean, this measurement is simple, we check to see how the NPC interacts with the play. That's when we can get into the complex concept of 'time' and gameplay. What kind of gameplay is core to the game, what is it players are doing? are they doing fetch quests and each quest takes about 20 minutes? The reason gameplay matters is to know how often players will be interacting with NPCs. knowing how often is the same as knowing how many measurement will be taken in a play session. So when it comes to the question about time, we can actually frame it relative to what kind of experience you want the players to have. Slow and grand, as playres will only intereact with NPC's very infrequently, as they travel the world. Or does the players interact with the NPC's a lot and doing so allows them to feel the world 'shifting' as they start to notice everyone starting to react to the rumor within one play session. The reason I give the worst case senario, with an analog version of rumor rather than boolean, is to hint at just how detailed and complex this can be, as reactions to the rumor could increase in intensity and tone.

so lets say that's all figure out:

• Rumor starting mechanic
• NPC's reactions (behavior) to rumors
• Game play and pacing
• the type of effect rumor 'spread' (aka delay, and the how important 'confidence' is)

And lets say, we use your image as a template for how character's know each other and feel about each other. with all that, is when its times to start building a network and designing it.

When it comes to the network, we would need to develop ways to talk about it and measure it. Here's the simplest solution: a simulation.

Have a graph of rumor vs time. The graph has multiple colored lines. each line represents one of the nodes. the height of the line can be used to measure different effect, such as Rumor % heard (or anything else). Time, gets tricky, which is why we frame the topic with regards to how often players will be interacting with NPC's. Trying to talk about time introduces a new tricky concept, and that is 'when' does data 'propagate?'

A lot of the time, 'when' is dependent on 'how' you want data to propigate. But isn't the 'how' the whole thing we are trying to solve? No, in this case, when I say 'how' I talking about, how do you want players to perceive 'how' rumors spread. While effects like having NPC's being able to say 'who' they heard 'what' from is neat, that's a bit too literal. From my initial read, this is the vibe I got. The rumor spreads in the background, out of sight from the player, but it does spread, and it does spread 'eventually.' I actually want to use the term 'evenly' but I worry that would get confused with the concept of everyone 'equally' knowing a rumor, which is a bit different and part of the nuance of my personal terminology that could get in the way.

anyways, the reason I bring this up is because its much simpler to just 'spread' or 'propagate' data by modeling a network than it is trying to actually have NPC's literally 'give' data to one another. Again, this may be a bit confusing due to the terms I'm using and the ideas i'm stealing from digital signal processing. Think of it like this. If you were actually trying to simulate 1:1, you would have to deal with the issue that code can (for all intents and purposes) only execute 1 instruction at a time. So data would spread through the network one branch at a time, and you can get stange situations where maybe 2 friends can't meet each other in a while so are never able to talk, but learn the rumors off handed. This is fine if the rumor is a boolean. But if there is any analog (ie some percentage), what you'll get as a network with resonance that feeds data back into itself and can cause strange oscillations. While this can be modeled and simulated and even equations writen, its probably nothing you need.

What it sounds like you want is rather than data spread one branch at a time, you want it to spread one node at a time. simpler to work with, simpler to model, simpler to make, and simpler to have repeatable and predictable results. Right now, this sounds like what you are doing, with weighted connections, and it sounds like you are working on the mechanism inside each node to get a 'spread' behavior you want. Such a system, better lends itself to the concept of a rumor 'spreading' in the background (hidden from players) and is able to be rather even with how it distributes data, with no data being 'feed' back into the system, thus no unstable behavior such as oscillations.

Tompte's suggestion is basically a node focused form of Boolean propagation, hence why you are considering having more 'virtual' connections as a means of influencing the rate and speed of rumor spread.

Because I am used to analog systems (or float type variables in code), my suggestion would be a bit different. Lets keep the weighted connection idea. In a node focused spreading technique, data propagates on 'ticks.' At the start of a 'tick,' every node that has data to share 'sends' data out, and the end of ever 'tock' every node evaluates and remembers what it hears. This is how most complex systems are modeled, with the tick being input data, and the tock being output data, and then the next tick you just set the previous output as the new input and recalculate the output. This is how circuits are simulated, how neural networks are built, and how digital audio filters work. The network, is just a neat matrix that represents the 'system' or the network, and the input and outputs are just 'state vectors.'

This is why I say this is my thing, because that's how I'd model it and I may be able to help if you are using this technique (assuming I can get python and matlab working again to generate some graphs).

anyways, here's how the process works for a 'node focus' type of spread.

Say each node has a variable called "rumor heard" which equals a % between 0 to 100%
The player tells node 1 a rumor, lets assume that this is 100% on the first try.
So the algoithm is just dealing with the NPC's and we'll ignore the player node.

So now we 'start' the algorithm.
The algothim starts with a 'current' state vector, lets say [1.00, 0.00, 0.00, 0.00]
where node 1 knows 100%, and node 2 3 and 4 know nothing
On the tick, every node 'broadcast' how much it knows (sending the previous output to be the new input into the 'matrix' or algothith)
on the tock, ever node computes what it hears
lets say 2 and 3 both connect to 1, and 4 connects to 2 and 3
both 2 and 3 started with 0.00, so 4 doesn't learn anything new from either.
However, at the same time, nodes 2 and 3 both learn something from node 1
Remember, everyone already 'broadcasted' so we avoid the issue where they start with nothing but at the same time are learning something

here's what could happen, and what I'm guessing you are trying, every node basically 'adds up' what they hear. lets say that they don't hear 100% lets say that the weights you are using can be used to describe how fast information spread. so between 1 and 2, lets say they are friends and call it 50% (aka 0.5 not 1.0 like with what you are starting with), so on the first 'broadcast' node 2 learns a lot (but not all). However lets say 3 is only a classmate, and only overhears 10% (0.1 weight)
so at the end, this is what the output looks like (what nodes now know)
[1.00, 0.5, 0.1, 0] = state vector

technically, all connections are 2 way, in this over simplified model, so technically 2 was also talking to 1, but since 2 started with nothing, its not like 1 could learn anything from 2.

anyways, that ends one single unit of time, you have to decide when there should be another tick tock.
next time this is what happens. we take the state vector, and use it as the input (thus the state vector acts as memory for all the nodes, you can have 1 state vector for each rumor, this way you can simulate any number of rumors without having to worry about managing data) (using it as an input is the 'broadcasting' )
so this time, node 2 says I know 50%, and 3 says 10% to node 4
again, the connections have weights, so maybe 3 is friends with 4, but 2 is a classmate, so 10% with 2, and 50% with 3
thus 4 learns 2's 50% * 0.1 weight = 5%, and 3's 10% * 0.5 = 5%
5+5 = 4 learns 10% total this round.
2 learn the next 50% and adds it to their existing 50% to learn 100% now all together, while 3 only learns another 10% to be at 20% total

Next tick tock
4 learns 2's 100% * 0.1 = 10%
and 3's 20% * 0.5 = 10%
10 + 10 + the previous 10% = 30% now
But remember, at the same time, all connections are 2 directional, so technically 3 will learn something from 4 (even if that deosn't make sense)
4 was 10%, with a weight of 0.5, so 3 learns 5% from 4, while also still learning 10% directly from 1
so 5 + 10 + the previous 20% = 35%

next tick tock, 4 will only learn 10% more from 2 (never learning any faster)
but from 3, its 17.5% now (growing!)

anyways, with this technique something happens. because of data feeding back between nodes, and adding up (even though that doesn't make sense and 2 people can't learn more about the rumor if they are just talking back and forth), it does generate an interesting effect you might like. 1 and 2 are like a group, and 3 and 4 are like another group, once the rumor reached the second group (by node 3 first), it will rapidly grow between friends, so what you will see in a simulation is one group will quickly learn a rumor, it will be slow to reach another group, but onec it does, it grows quickly.

This is a bi-directional integral system, basically, very predictable, and at the end everyone will be at 100%, so you don't have to worry about wierd things like resonance and the flow of data (aka this is how to simulate fire). You can do tricks like, maybe nodes don't prodcast until they learn enough about a rumor (so a delay effect), also because it only ever adds, you might want really small weights (0.001, and doing more loops to make things spread more evenly, even if the player only interacts with NPCs every 20 loops, it will let you get a perspective on how to look at time). With this, you could make a graph to know who learns what when depending on who learns the rumor first. Can NPC's Act on a knowledge (aka that Boolean effect) at 50% awareness, 90%, or do they need to be at 100% before players will notice? And what if knowledge isn't going two directions, what if its not a conversation, but rather, one direction (one AI overhearing another in class), well the system can simulate that, you just need to know how to model it.

If this interest you at all, I'll be happy to talk about it further (I've talked enough as it is, sorry about that), and sorry if I wasn't all that clear on the first try.

 

[toolkitxx]

THIS. this is more or less my specialty (digital signal processing), so sorry for the coming wall of text. I was debating weather I should actually 'send' this since I don't know how much use it will actually be.

I've been working on a few things, and since this is the first time I'm reading this, right now I'm not fully grasping what it is you are trying to do.

As I hinted at, it sounds like you are working on a graph/node/network/system 'thing' and are working with information being spread/propagated, which as core to 'digital signal processing' which is one of my favorite subjects! Infact, I am designing my own neural network based on my own philosophies of digital signal processing. The issue with that is, I have my own set of terminology, and think of the problem in ways that may not match how you are currently handling things, so I may not be able to sync up 1:1 with what you are saying or trying to do.

So the player (and only the player) states a rumor. For me, I imagine this as starting out with a basic game mechanic to 'start' a rumor. Lets say this game mechanic starts with the player needing to 'learn' a bit of information (catches node 6 doing something), that 'unlocks' a new dialog option to have with node 1. the 'starting' of a rumor is simply clicking on the now available dialog option.

From that point on, its up to your 'algorithm' to distribute the rumor, and for the individual 'AIs' to dynamically react to the character (and rumor) based on that AI's understanding of the rumor.

I say it like this to break down the problem into two separate parts, 'the algorithm' which computes a number for every node (relative to each unique rumor or something), and 'AI' which is where we throw all the complex 'reactions' and deal with that part of the puzzle later.

From what I understand, you have two issues you want to solve:

1) It sounds like you have some basic way of modeling how the rumor 'spreads' however, the first issue is that

and

and you are looking for suggestions on how to 'design' your system to achieve a 'spread' that you like, as right now its not behaving how you would like it to.

2)
Correct about the design part and the unsatisfactory spread.
I not sure if you are using 'graph' to mean, designing how the nodes should behave and shown graphically, or if you literally mean a graph, showing you how data would propagate over time.
Literally graph as in nodes and edges
The reason I am jumping into this, with my wall of text, is this sounds like the kind of work I do irl. Digital signal processing, control theory, and control systems engineering is my field of interest and occupation, and pretty much work with similar node graphs. There is a lot to say and do. I bring up the warning about my particular vocabulary and problem solving techniques because If I just start throwing words at you, that probably wouldn't be the most useful. Simple questions like "what are you trying to do" have lots of ways of answering them based on what kind of mental 'frame' or perspective one has when asking and answering the question.
In my particular case it wouldnt be a problem - engineer myself but for the sake of history and understanding for others i kept wording simplified
So, I'll first ask, what kind of output do you want? I'm not asking: how do you want information to spread? Lets skip that, that's getting too deep into the details when we haven't set up the basics yet.

The output i want is basically something that will be based on this information being available or not. I stick to 'knowledge' for the time being to avoid confusion. I use a simplified model for the nodes where each node has an array attached to them called 'knowledge'. New knowledge is simply a new entry on top of this stack.

So that means, it's boolean. Characters can either 'act' on information or 'knowledge' or they can't 'act' on something because they don't know it yet. Are you sure that's all you want to do? Do you need to worry about 'where' they got information from? I say worry, but really I mean, do you want. Is this like where the NPC's 'say' where they heard something from? Similarly, do you need to worry about when, do characters react different depending on how recent the information is and does it matter how long ago since they initially heard the rumor? You say they (NPCs) know or don't know, but do you need to generate any other data that NPC's will use for certain behavers?
Yes and no. Knowledge is in fact boolean - it is either there or it is not. But for this particular part i dont want to add too much difficulty or complexity as knowledge is basically the gateway for other functions to work through the network at other times. So knowledge does not get any attributes itself. In terms of narrative (where this is also used for) the text is kept general enough to avoid any possible specifics to break logic etc. So the how, who, why etc are not a concern because that would require far too much handling down the road. In this simplified system the player will fill the gaps themselves in terms of 'the info spread but how specifically and by whom is not important to make decisions. I (the player) know now that certain info can spread without me actively doing something for it'. In narative and gaemplay functions there are simple checks for certain knowledge and will determine what to do from there or how to further the narrative.

Lets say, worst case scenario, you want the following type of data than NPC AI could work with:

• Rumor Heard from 0 to 100% (aka analog rather than binary/digital) (AI reaction may change depending on how much they know)
• Rumor Confidence 0 to 100% (AI reaction may change depending on how much they believe the rumor)
• Rumor Source Ratio (who did they learn 'what' from)
• Rumor delay (how long did it take for the rumor to reach them)
• Rumor relevance (how old is this rumor relative to 'now')

It also sounds like rumors have 'sub properties' which also affect both the AI and how data is distributed through the 'network'
I handle this before the actual graph problem. The function will not trigger unless certain conditions are fulfilled which means i can work with a simplified model.

Even with all that 'listed out' we still wouldn't be ready to talk about how to model the network yet, because there are still some nuances that are important in designing the network. You already know them, but I don't, things related to gameplay. You said that characters will be walking (moving in some way) around in the world, which may or may not affect things, maybe in teh future you want a mechanism where relationships could change, and then you also seem to highlight a concept of 'time' as with the key word 'trickle'
Time is a part of the gameplay and also provides a challenge for certain things to be 'realistic'. Time advances while the player interacts with the world but i can define certain aspects with a bit of freedom in this regard. Worst case explanation is like a 'auto-share' info between people due to modern devices etc So ignore this for now


The reason i bring up game mechanics, is to figure out how would we measure things? What do NPC's do, this is why I bring up the concept of 'acting' on information/knowledge. knowing how npc's are affected by the 'rumor' is how we will measure things. Lets say, the simplest case is boolean, maybe you have it writen such that, characters will interact one way with the player, and interact another way when the npc hear the rumor. Since it is boolean, this measurement is simple, we check to see how the NPC interacts with the play. That's when we can get into the complex concept of 'time' and gameplay. What kind of gameplay is core to the game, what is it players are doing? are they doing fetch quests and each quest takes about 20 minutes? The reason gameplay matters is to know how often players will be interacting with NPCs. knowing how often is the same as knowing how many measurement will be taken in a play session. So when it comes to the question about time, we can actually frame it relative to what kind of experience you want the players to have. Slow and grand, as playres will only intereact with NPC's very infrequently, as they travel the world. Or does the players interact with the NPC's a lot and doing so allows them to feel the world 'shifting' as they start to notice everyone starting to react to the rumor within one play session. The reason I give the worst case senario, with an analog version of rumor rather than boolean, is to hint at just how detailed and complex this can be, as reactions to the rumor could increase in intensity and tone.

so lets say that's all figure out:

• Rumor starting mechanic
• NPC's reactions (behavior) to rumors
• Game play and pacing
• the type of effect rumor 'spread' (aka delay, and the how important 'confidence' is)

As in the answer before: This is taken care of. All the mechanics you list are depending on a foundation to work. This can be done by a shitload of flags etc or by a model i am going for. Think in terms of one giant state machine where each character (npc and player) has a stack of 'knowledge' about all kinds of stuff on a single stack. Functions check this stack for certain knowledge and decide what to do then. If the knowledge doesnt exist do one thing or nothing , if it exists do another thing. Along those lines.
And lets say, we use your image as a template for how character's know each other and feel about each other. with all that, is when its times to start building a network and designing it.

When it comes to the network, we would need to develop ways to talk about it and measure it. Here's the simplest solution: a simulation.

Have a graph of rumor vs time. The graph has multiple colored lines. each line represents one of the nodes. the height of the line can be used to measure different effect, such as Rumor % heard (or anything else). Time, gets tricky, which is why we frame the topic with regards to how often players will be interacting with NPC's. Trying to talk about time introduces a new tricky concept, and that is 'when' does data 'propagate?'

A lot of the time, 'when' is dependent on 'how' you want data to propigate. But isn't the 'how' the whole thing we are trying to solve? No, in this case, when I say 'how' I talking about, how do you want players to perceive 'how' rumors spread. While effects like having NPC's being able to say 'who' they heard 'what' from is neat, that's a bit too literal. From my initial read, this is the vibe I got. The rumor spreads in the background, out of sight from the player, but it does spread, and it does spread 'eventually.' I actually want to use the term 'evenly' but I worry that would get confused with the concept of everyone 'equally' knowing a rumor, which is a bit different and part of the nuance of my personal terminology that could get in the way.

anyways, the reason I bring this up is because its much simpler to just 'spread' or 'propagate' data by modeling a network than it is trying to actually have NPC's literally 'give' data to one another. Again, this may be a bit confusing due to the terms I'm using and the ideas i'm stealing from digital signal processing. Think of it like this. If you were actually trying to simulate 1:1, you would have to deal with the issue that code can (for all intents and purposes) only execute 1 instruction at a time. So data would spread through the network one branch at a time, and you can get stange situations where maybe 2 friends can't meet each other in a while so are never able to talk, but learn the rumors off handed. This is fine if the rumor is a boolean. But if there is any analog (ie some percentage), what you'll get as a network with resonance that feeds data back into itself and can cause strange oscillations. While this can be modeled and simulated and even equations writen, its probably nothing you need.
No worries - i am still with you on this and this is the reason why i posted it here. Certain models simply dont pop up for me when i am looking for a solution to a problem. Signal processing is roughly what i was looking for as it looks like a proper simple model that could work.

What it sounds like you want is rather than data spread one branch at a time, you want it to spread one node at a time. simpler to work with, simpler to model, simpler to make, and simpler to have repeatable and predictable results. Right now, this sounds like what you are doing, with weighted connections, and it sounds like you are working on the mechanism inside each node to get a 'spread' behavior you want. Such a system, better lends itself to the concept of a rumor 'spreading' in the background (hidden from players) and is able to be rather even with how it distributes data, with no data being 'feed' back into the system, thus no unstable behavior such as oscillations.

Tompte's suggestion is basically a node focused form of Boolean propagation, hence why you are considering having more 'virtual' connections as a means of influencing the rate and speed of rumor spread.

Because I am used to analog systems (or float type variables in code), my suggestion would be a bit different. Lets keep the weighted connection idea. In a node focused spreading technique, data propagates on 'ticks.' At the start of a 'tick,' every node that has data to share 'sends' data out, and the end of ever 'tock' every node evaluates and remembers what it hears. This is how most complex systems are modeled, with the tick being input data, and the tock being output data, and then the next tick you just set the previous output as the new input and recalculate the output. This is how circuits are simulated, how neural networks are built, and how digital audio filters work. The network, is just a neat matrix that represents the 'system' or the network, and the input and outputs are just 'state vectors.'

This is why I say this is my thing, because that's how I'd model it and I may be able to help if you are using this technique (assuming I can get python and matlab working again to generate some graphs).

anyways, here's how the process works for a 'node focus' type of spread.

Say each node has a variable called "rumor heard" which equals a % between 0 to 100%
The player tells node 1 a rumor, lets assume that this is 100% on the first try.
So the algoithm is just dealing with the NPC's and we'll ignore the player node.

So now we 'start' the algorithm.
The algothim starts with a 'current' state vector, lets say [1.00, 0.00, 0.00, 0.00]
where node 1 knows 100%, and node 2 3 and 4 know nothing
On the tick, every node 'broadcast' how much it knows (sending the previous output to be the new input into the 'matrix' or algothith)
on the tock, ever node computes what it hears
lets say 2 and 3 both connect to 1, and 4 connects to 2 and 3
both 2 and 3 started with 0.00, so 4 doesn't learn anything new from either.
However, at the same time, nodes 2 and 3 both learn something from node 1
Remember, everyone already 'broadcasted' so we avoid the issue where they start with nothing but at the same time are learning something

here's what could happen, and what I'm guessing you are trying, every node basically 'adds up' what they hear. lets say that they don't hear 100% lets say that the weights you are using can be used to describe how fast information spread. so between 1 and 2, lets say they are friends and call it 50% (aka 0.5 not 1.0 like with what you are starting with), so on the first 'broadcast' node 2 learns a lot (but not all). However lets say 3 is only a classmate, and only overhears 10% (0.1 weight)
so at the end, this is what the output looks like (what nodes now know)
[1.00, 0.5, 0.1, 0] = state vector

technically, all connections are 2 way, in this over simplified model, so technically 2 was also talking to 1, but since 2 started with nothing, its not like 1 could learn anything from 2.

anyways, that ends one single unit of time, you have to decide when there should be another tick tock.
next time this is what happens. we take the state vector, and use it as the input (thus the state vector acts as memory for all the nodes, you can have 1 state vector for each rumor, this way you can simulate any number of rumors without having to worry about managing data) (using it as an input is the 'broadcasting' )
so this time, node 2 says I know 50%, and 3 says 10% to node 4
again, the connections have weights, so maybe 3 is friends with 4, but 2 is a classmate, so 10% with 2, and 50% with 3
thus 4 learns 2's 50% * 0.1 weight = 5%, and 3's 10% * 0.5 = 5%
5+5 = 4 learns 10% total this round.
2 learn the next 50% and adds it to their existing 50% to learn 100% now all together, while 3 only learns another 10% to be at 20% total

Next tick tock
4 learns 2's 100% * 0.1 = 10%
and 3's 20% * 0.5 = 10%
10 + 10 + the previous 10% = 30% now
But remember, at the same time, all connections are 2 directional, so technically 3 will learn something from 4 (even if that deosn't make sense)
4 was 10%, with a weight of 0.5, so 3 learns 5% from 4, while also still learning 10% directly from 1
so 5 + 10 + the previous 20% = 35%

next tick tock, 4 will only learn 10% more from 2 (never learning any faster)
but from 3, its 17.5% now (growing!)

anyways, with this technique something happens. because of data feeding back between nodes, and adding up (even though that doesn't make sense and 2 people can't learn more about the rumor if they are just talking back and forth), it does generate an interesting effect you might like. 1 and 2 are like a group, and 3 and 4 are like another group, once the rumor reached the second group (by node 3 first), it will rapidly grow between friends, so what you will see in a simulation is one group will quickly learn a rumor, it will be slow to reach another group, but onec it does, it grows quickly.

This is a bi-directional integral system, basically, very predictable, and at the end everyone will be at 100%, so you don't have to worry about wierd things like resonance and the flow of data (aka this is how to simulate fire). You can do tricks like, maybe nodes don't prodcast until they learn enough about a rumor (so a delay effect), also because it only ever adds, you might want really small weights (0.001, and doing more loops to make things spread more evenly, even if the player only interacts with NPCs every 20 loops, it will let you get a perspective on how to look at time). With this, you could make a graph to know who learns what when depending on who learns the rumor first. Can NPC's Act on a knowledge (aka that Boolean effect) at 50% awareness, 90%, or do they need to be at 100% before players will notice? And what if knowledge isn't going two directions, what if its not a conversation, but rather, one direction (one AI overhearing another in class), well the system can simulate that, you just need to know how to model it.
This is actually an interesting method i could make use of on an extra layer. I wouldnt mind weird resonances actually as this is supposed to be a social network and not a technical network. Thus weird stuff would make certain things more natural aka unpredictable. As of now things are already kind of unpredictale since the user's actions can and will change relations between themselves and nodes. So even if the player never interacts with a certain group the 'rumour' system would still cause knowledge to trickle into other groups and cause consequences. The groups are only partially 'static' and the user's interaction with the world can actually change the composition of those groups thus also knowledge flow.
If this interest you at all, I'll be happy to talk about it further (I've talked enough as it is, sorry about that), and sorry if I wasn't all that clear on the first try.

Dont worry about wall of text - I am a boomer and love reading
The rest of my answers directly in the quote!

 

[toolkitxx]

I edited my post to fix some 'bugs' in my thinking. As with most of my ideas they get better after a few iterations. It's a little more complicated but not by a lot. The first version would still work most of the time I think.

The general idea is that by sorting the nodes by distance you can loop through the graph like layers of an onion. Knowing that, it gets a little easier and you can play around with different approaches.

Iterate away - that is the only way things get working
I am going to try this out actually. Looks pretty solid already. Thanks!

Sidenote: Dont change your original posts as it eliminates the iteration which could prove useful down the road. Often it is very helpful if one can go back in a process and check how the result actually became the result - including the failed attempts. Reply to your own post, strike-out text as needed and add new text - pretty much like on a note. Nobody gets judged by their train of thought in the end but it can be very helpful to understand it in case of specific wording etc.

 

[Tompte]

Sidenote: Dont change your original posts as it eliminates the iteration which could prove useful down the road. Often it is very helpful if one can go back in a process and check how the result actually became the result - including the failed attempts.

Yeah, you're right. Thankfully your quote contains the original post.

 

[toolkitxx]

Oh well - turns out that I probably have to change my implementation of this. While playing with a first version of the suggested algorithm i found quickly that working with a directed graph (since the edges are basically relations) makes a lot more sense. Which actually saves me a lot of other code - hurray. Will update soon again

P.S. You know that you are finally getting old when you notice that your copy from

You must be registered to see the links

is from 1996

 

[Saki_Sliz]

The rest of my answers directly in the quote!

I have never seen that done before, that's actually pretty clever! Also glad to hear you are an engineer as well, so I'll try not to keep things too simple, but I'll still try to practice clear communication. I'll stick everything in a quote to keep the reply compact.

I still worry about confusion over terms and language, but it sounds like if I thow up some examples, they shouldn't be too confusing

To tackle a project like this, or this particular problem, I see that there are 3 frames of mind we could be in when talking about things, I'll list them out just so I'm not making any unspoken assumptions.

1. Surface level concept and perception (talking about the game and the experience)
2. Code implementation (talking about how data will be handled)
3. algorithm behavior (talking how information will be handled and represented)

I specifically outline this to bring up point #2.

I spent some time getting some working code showing different simulations and how you can visualize data. This code is made using python simply because its quick and dirty. However, this is not how I would 'design' the solution. In this case I mean 'design' in a Frame of Mind (FoM) #2, where I'm not talking about how the game is designed, I'm talking how the code is designed. I code using C#, and I would make a custom API or DLL (or in reality, I'll just make a special class and not bother with any fancy exporting cuz i'm lazy), so in this context (FoM #2) I'm talking about how the code would work, which is seprate from how the game would work (FoM #1). Talking about FoM #2 is totally different and this code isn't a good example of how I think you should approach the problem, but I'll hold of on getting caught up in the details of the programming langage.

So I want to focus on FoM 1 and 3

So you want a rumor to spread in a certain pattern, or a certain order, filling 1 group first before another, but 'eventually' spreading. I would say this is FoM 1 'design target'

The algorithm is FoM 3, and needs to match FoM 1, and then you just fill the middle FoM 2 depending on your language (that can be saved for another conversation).

So nothing about any of this should be new, I just wanted to frame the conversation (I'm just doing a test on ways of clearly communicating, this is me experimenting with an idea, sorry for being so wordy but glad to hear it isn't too off-putting). So before I get into the details of a reply, let me show you the first image, a simulation of your inital post using my technique

Simulating:

Where weights 'types' are:

1. 'dontknow' = No Connection
2. 'weak' = basic connection
3. 'sameGroup' = stronger connection but in the same group of friends
4. 'friends' = friends/high trust
5. 'selfmemory' = you can ignore this, but it simplifies the code, keeps it concise as it basically allows for an inbuilt connection to the 'self' that allows it to 'remember' what it knows, rather than having to write more code to handle this effect.

(nothing for hate, also player node will be omitted)

Using an node focused algorithm of Ax = y
where x and y are state vectors
x = current knowledge level
y = new knowledge level
A = a matrix representing the simulation

This assume that the algorithm is being implemented in a way that knowledge slowly increases over time, where we 'compute' (run the equation) for every unity of delta_t. (the details about delta_t gets into the whole conversation about the perception of time and understanding how to see the difference between literal time (an FoM 3 concept) and 'game time' (the player perception, an FoM 1 concept, I've added comments in my code to help point out these two differences... hopefully).

If you wanted to simulate it (such as when making a line graph over time), it would be something like a for loop

x from 0 to 100
    compute Ax = y each loop
    save y to memory
    save x to now equal y, to update the 'current state' for the next loop
   
plot a graph

Node's are model as
k_x,1 = Node x's starting knowledge (at the start of each loop)
k_x,2 = Node x's new knowledge (at the end of each loop)
Σ = sum across all incoming nodes
n = incoming node index (from 1 to 7, ignoring node 0 the player node)
a = a connection's weight (determined by type)
a_x,n = the connection weight between node n, to the current computing node, node x

Weighted Summation Model (for node x)
k_x,2 = Σ all n (from 1 to 7) for (k_n,1*a_x,n)

( this assumes analog, I am omitting important things like capping knowledge at 100%, causing a boolean trigger)

loop x from 1 to 7 to simulate everyone

Scaling the weights small means needing more loops to get the numbers to increase, but this is what I generated.



Observations:

• Node 1 knows immediately, which is to be expected since the player tells them the rumor directly
• Node 2 learns next, followed by node 3
• With Nodes 3 and 4 being friends, node 4 quickly learns
• group 2 takes a while do to the slow passing of info directly from 2 to 4, but once node 4 knows, the rest of group 2 catches up
• Node 5 ad 6 are identical (they have all the same connections, and are close friends, connections to the player have been ignored in this simulation)
• Node 7 is the last to learn, having the weakest 'path' to the rumor's source (and no serious friend to talk with)

This, I believe, should be the behavior you were looking for.

The top graph shows 'computation steps' or how many 'loops' it took. this is FoM 3

on the bottom, I changed the axis to 'player interactions' with 'major ticks' every 10 interactions (where we can expect players to have interacted with everyone and gotten a feel for the state of the world). This is an FoM 1 concept. it just takes a bit of math and abstraction to translate between the two types of time (FoM3 type and FoM1 type). I only bring this up so that its possible to talk about the two without getting confused over the technical detail of how fast the code should compute.

I made two examples, a simple one, and then a direct simulation. In the code I add lots of comments talking about how to represent data (FoM 3) and hopefully the code makes sense. I use the Numpy library for python to do matrix multiplication, but you can use what ever works for you (a FoM #2).

Spoiler: 4 node Intro Example

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Your System Coded

You don't have permission to view the spoiler content. Log in or register now.

Now, back to the whole FoM language talk.

FoM2 Warning!

I used the above code to talk about the algorithem, However, I would not use the code. It is great for simulating, but this isn't how I would implement it in code (ignoring the fact that I prefer C#). From the start, one of the things that caught my eye was, you want things to behave different now and then, such as if the gossip is too juicy, or an emergency. I don't know what language you are using or your familiarity with various OOP programming techniques, but this is how I'd apporach the problem (although it sounds like you have arealdy made your own different implementaiton)

I see 2 data types:

1. Rumor
2. Spread Type

Both of these would be objects or classes, containing information, and the API I would develop would just handle all the interconnections

If you want to have rumors spread in different ways, such as juicy gossip or an emergancy, what I would do is make a second 'system.' The default system is your example graph. The 'quick' system would be another graph that gets used 'instead' of the default. With the technique I used above, that just means making e second matrix. So the point of the 'spread type' data type is to allow for the creation of multiple spread types. Maybe you even want different behaviors depending on unique rumors. Spread type would be a sub field inside of the 'rumor' data type.

I have the 'rumor' type, because I assume you would like the flexibility to start any rumor at any time, and for them to all spread independently of each other (meaning that once an AI 'learns' a rumor or 'knows' it, it gets on the stack of cards, and if two rumors are started with two different nodes, say 6 learns a rumor, 6 will probably stack the second rumor first before ever learning about the first rumor told to node 1). Rumors, besides knowing what type of 'spread' to use, should also contain the 'state vector' so that the object/class representing a rumor is responnible for the current world state of 'who knows what'.

at the end of your game loop, you can do RumorAPI.computeNextTick()
and the API will handle the rest, fetching rumors that exist and doing needed calculations. How this works depends on how you want to code it. While creating Rumor and spread types would be something at the start of teh game (not in the main loop). I love clean nice looking code, so there is probably 2 commands I would still need to make.

RumorAPI.start("Rumor Name") // this would be used inside the player code or the UI code or however you handle your project

RumorAPI.connectRumorEvent("X") += this_npc.doSomethingWhenI_Know_RumorX; // this is how it would look in C#, not sure about events in python or what ever flag technique you are using. but basically the API will call your special function and you can have your code handle putting a 'knowledge' card on the 'stack' of cards, and allow the AI to handle the stack seprate from the rumor API.

anyways, that's most of my suggestion. From what it sounds like, it seems like your graph is ok, and you have right starting idea, your just having issues with the FoM2 implementation, hopefully the matrix idea gives you a direction to test. Other than that, I guess I could get into the actual code of how you are implementing your project (aka FoM2 talk).

 

[toolkitxx]

There are a few misunderstandings I can answer right away that unfortunately cascade throughout your ideas and kill a majority of them

My original question was worded intentionally. I took a small sample of a bigger problem as the solution for that will work on either level. We are basically talking about information dissipation in a social network here. The picture provides basically the minimum information needed and does not reflect any real sizes, node names etc. It is a simplified abstract of the problem at hand.

The word 'rumour' was specifically used to enable others to easily understand what is supposed to happen. The concept of rumour is what people generally connect with information dissipation. In this entire context it is just information - doesnt matter for the solution what kind. Same goes for 'knowledge' This has nothing to do with a knowledge base at all. It means in this context that something is known which is binary - one knows or does not. So these 2 aspects eliminate the entire part of partial knowledge etc - this is not what this is about. I just stated earlier that the concept might be interesting on a different layer at some other time.

About the overall 'mindset' - this is purely a design aspect as stated in the question. Thinking in terms of code or even worse a specific language is totally the wrong aspect. Any algorithm can be written down in pseudo-code and will work in any language needed later on. I am not asking to write an actual algorithm in any language as this is taken care of. There is a framework that uses all this or is going to use it in case i need to redesign some parts according to suggestions or solutions. The framework needs to be stable architecture-wise to support certain major aspects that are major gameplay elements. This is why this is purely a design question as it could lead to changes in the current architecture.

 

[Saki_Sliz]

So just design, and just working with 'information dissipation'

no 'particular' information, such as a game with rumors 1 2 and 3 slowly spreading, you just want to focus on a system that allows for 'information dissipation.'

I do think the term 'rumor' may have confused me, triggering my programmer aspect, hence the whole talk about needing to deal with data types near the end there. But if I understand, right now you just want to stick with the top level, which right now you are playing with weighted connections.

when you say 'information' that is triggering another part of my brain (hence the issue with language and terminology), the digital signal processing, because the abstraction of 'information' in my background is just represented as 'signal.' The reason I treat the 'rumor' as analog, is because its the only real way by above methods work. However, if you are working with true boolean, other than my example of doing a comparison check with an anolog value, it sounds like you would need to work with something like stochastics (fancy probabilities), but that could be my mind just shooting off to another tangent.

actually re reading, you say it has nothing to do with actual 'knowledge' only weather on not data is known or not know. it sounds the focus is 'exist' or 'doesn't exist.' A bit of word play, but this changes my frame of mind to another concept. Right now I am working on my own personal project for AI and neural networks, where I am working on a network that dynamically handles the flow of data by reconnecting subnetworks together as needed to generate any needed complex ideas on the fly. This system, the code, has to know a lot of things 'about' the data, in order to make the right connection, whit out actually unknowing what the data is. Mainly, it has to know if it 'exists' or not. How something exists, depends on how I code things and design the philosophy of knowledge one implements. With your emphasis on the Boolean aspect of have or don't have, I am assuming you mean quite literally, you want to work with a Boolean variable (or maybe a class pointer that is either null, or points to the card as available on the stack). In any case, it is something that is anonoumus (knowledge, but we don't need to know what the knowledge literally is), and either exist or does not exist (known or not known).

Assuming I am following you still.

Here's what I got caught up on in your original post

What i am trying to achieve is that the information 'leaks' further by some form of proper mechanism without just being random or fully along lines of people who just know each other.

Because you showed a node graph, and you said you wanted the information to spread, I mind thought of the above graphs I made with python. That is because with your example image, using my technique (based on digital signal processing), the fact that all the nodes were connected to 'something' meant that data would always propagate to them, at some point.

However, you specifically say not "fully along lines."

This is what is confusing me.

First: It sounds like, because you are treating the knowledge as a Boolean, it sounds like (to me) that the way you are thinking about the problem is that it can only be spoken/said/spread once (aka only to the people who know each other). Is what you are thinking along the liness that node 1 will only share the secret with their friends/group once, and tell them not to tell anyone? Basically, only allowing single 'tick tock' or cycle, and those who talk get 100% the knowledge, because knowledge is only a boolean because it only exist or doesn't.

Second, However: you still want the information to spread in some way (possibly indirectly, like background information, so that those with no connections could still ... 'acquire' the knowledge), without the same mechanism, but an alternative mechanism

Third, this is probably what I got caught on: you describe the connections with the idea of 'weighted edges' (thus tickling my DSP mindset)

My question is, why? What is it you are trying to achieve here by using the concept of weighted edges?

Are you:
- using the weights so you have something easy to look at and talk about
- while one program/mechanism uses them for decision making (such as who an NPC will talk to)?

- Or, are you using the weights (an actual number), in a literal way (such as how my code computed)?

If you are dealing with sending data, and not just simulating it with a number or variable, then I could see why you are framing things as Boolean, because data to send does or doesn't exist, and it is sent as a whole package. Which is why I ask, what is it you are using the weights for, is it more a tool for your self to visualize and talk about the problem, or are you literally using the weights as weights are used? If you are using the weights more as a tool, then I can understand how you could talk about things in a boolean way, because you can run an if statement and have code do different operations depending on the 'type' of connection nodes have. Where 'type' is what I would use instead of 'weight' just because for me, I would use 'weight' literally.

Which if you are doing things based on connection 'type' then I can understand why it sounds like your question

by some form of proper mechanism without just being random

sounds like you are asking for a 'second' mechanism which complements the 'initial' mechanism (where friends talk, and thus, the issue you mentioned of a rumor not spreading).

if you are asking for a second mechanism, where rumors spread in the background 'somehow.' Then I'll go back to questions regarding design and your intention. If the above graph is just a small sub sample of something much bigger, I assume you mean more groups, possible groups with subgroups that overlap in various ways. How do you want the information to 'disperse' ? Is there a particular pattern you want? like one group at a time, or more or less even? deciding a 'behavior' may give suggestions on mechasims types.

Since you gave the example of not wanting things to just randomly, happen, it sounds like you are starting in a vacuum and could add any code you want, so I'm trying to figure out what 'mechanism' means to you. Do you want a mechanism that models something? like a certain social behavior (assuming that the nodes still repreent npc's and you weren't just using that as a term to keep the example simple), and thus need an 'algorithm.' Or are you trying to distribute data over a network, or over a million virtualized game objects, where you are trying to achieve a certain function (like how my modular neural network distributes modules around and connects them) and thus need a 'mechanism.'

An algorithm can design a mechanism, but a mechanism can also design an algorithm.

You want to start with an algorithm if you want a certain behavior with regards to controlling the flow of information (aka 'when' hence me making the graphs, something to talk about with regards to time and sequence).

You want to start with a mechanism if you want a certain behavior with regards to controlling information flow (aka the 'how' aka the weighted edges and repeated loops, so data only travels through the edges like signals in a circuit)

anyways, words play, a tricky beast!

 

[toolkitxx]

So just design, and just working with 'information dissipation'

no 'particular' information, such as a game with rumors 1 2 and 3 slowly spreading, you just want to focus on a system that allows for 'information dissipation.'
On design level one always uses the most abstract possible form. Information, data, knowledge - all just words in the end that are placeholders for some part of the overall solution. Neither an actual function nor a algorithm cares what kind of information it deals with - it just does some math on something and creates a result.

I do think the term 'rumor' may have confused me, triggering my programmer aspect, hence the whole talk about needing to deal with data types near the end there. But if I understand, right now you just want to stick with the top level, which right now you are playing with weighted connections.
This happens to too many coders . They dive too quickly into coding reflexes.

when you say 'information' that is triggering another part of my brain (hence the issue with language and terminology), the digital signal processing, because the abstraction of 'information' in my background is just represented as 'signal.' The reason I treat the 'rumor' as analog, is because its the only real way by above methods work. However, if you are working with true boolean, other than my example of doing a comparison check with an anolog value, it sounds like you would need to work with something like stochastics (fancy probabilities), but that could be my mind just shooting off to another tangent.
This is not a data network, it is a social network.

actually re reading, you say it has nothing to do with actual 'knowledge' only weather on not data is known or not know. it sounds the focus is 'exist' or 'doesn't exist.' A bit of word play, but this changes my frame of mind to another concept. Right now I am working on my own personal project for AI and neural networks, where I am working on a network that dynamically handles the flow of data by reconnecting subnetworks together as needed to generate any needed complex ideas on the fly. This system, the code, has to know a lot of things 'about' the data, in order to make the right connection, whit out actually unknowing what the data is. Mainly, it has to know if it 'exists' or not. How something exists, depends on how I code things and design the philosophy of knowledge one implements. With your emphasis on the Boolean aspect of have or don't have, I am assuming you mean quite literally, you want to work with a Boolean variable (or maybe a class pointer that is either null, or points to the card as available on the stack). In any case, it is something that is anonoumus (knowledge, but we don't need to know what the knowledge literally is), and either exist or does not exist (known or not known).
This is your coder brain again. Pointers etc exist in specific languages. Knowledge is what is on the stack. By being on a stack that is connected to a person information is knowledge in this model. Information only exists on the stack or it isnt. There is no in between, no gradiant of it. The stack has all kinds of information like 'met Person A', 'washed my face', 'pranked Person B', 'heard Person C is a slut' and so on. It is simply a central point for all kinds of functions to pick out choices or make checks.

Assuming I am following you still.

Here's what I got caught up on in your original post

Because you showed a node graph, and you said you wanted the information to spread, I mind thought of the above graphs I made with python. That is because with your example image, using my technique (based on digital signal processing), the fact that all the nodes were connected to 'something' meant that data would always propagate to them, at some point.

However, you specifically say not "fully along lines."

This is what is confusing me.

First: It sounds like, because you are treating the knowledge as a Boolean, it sounds like (to me) that the way you are thinking about the problem is that it can only be spoken/said/spread once (aka only to the people who know each other). Is what you are thinking along the liness that node 1 will only share the secret with their friends/group once, and tell them not to tell anyone? Basically, only allowing single 'tick tock' or cycle, and those who talk get 100% the knowledge, because knowledge is only a boolean because it only exist or doesn't.
The basic problem requires only a single execution - actually in social networks this is connected to a cascade model. If there is only one or several cascades is irrelevant for the basic solution. Once the base solution works it could theoretically be applied multiple times - but this is outside of the scope of my original question. And I already posted that after i tested a first version of the idea i realized that i either have to change my graph type to directed (it is currently undirected) or a mixed form.

Second, However: you still want the information to spread in some way (possibly indirectly, like background information, so that those with no connections could still ... 'acquire' the knowledge), without the same mechanism, but an alternative mechanism

Third, this is probably what I got caught on: you describe the connections with the idea of 'weighted edges' (thus tickling my DSP mindset)

My question is, why? What is it you are trying to achieve here by using the concept of weighted edges?

Are you:
- using the weights so you have something easy to look at and talk about
- while one program/mechanism uses them for decision making (such as who an NPC will talk to)?

- Or, are you using the weights (an actual number), in a literal way (such as how my code computed)?
Weighted edges is simply a common tool to solve problems like the one i started with. By applying a weight to an edge you get more control opportunities, more meaning overall. It is pretty much a basic of graph theory.

If you are dealing with sending data, and not just simulating it with a number or variable, then I could see why you are framing things as Boolean, because data to send does or doesn't exist, and it is sent as a whole package. Which is why I ask, what is it you are using the weights for, is it more a tool for your self to visualize and talk about the problem, or are you literally using the weights as weights are used? If you are using the weights more as a tool, then I can understand how you could talk about things in a boolean way, because you can run an if statement and have code do different operations depending on the 'type' of connection nodes have. Where 'type' is what I would use instead of 'weight' just because for me, I would use 'weight' literally.
Since this is a social network and not a data network it simply requires weighted edges to simulate relations between nodes. Since relations are not binary but complex working with weighted edges is pretty much default for any social network.

Which if you are doing things based on connection 'type' then I can understand why it sounds like your question

sounds like you are asking for a 'second' mechanism which complements the 'initial' mechanism (where friends talk, and thus, the issue you mentioned of a rumor not spreading).
Exactly this is not what i asked. 1 mechanism that dissipates information is the mechanism. there are no multiples in this but a variation of behaviour depending on relations between nodes.
if you are asking for a second mechanism, where rumors spread in the background 'somehow.' Then I'll go back to questions regarding design and your intention. If the above graph is just a small sub sample of something much bigger, I assume you mean more groups, possible groups with subgroups that overlap in various ways. How do you want the information to 'disperse' ? Is there a particular pattern you want? like one group at a time, or more or less even? deciding a 'behavior' may give suggestions on mechasims types.
An architecture requires a solid foundation. Groups and people are dynamic and the player has ability to influence certain aspects by interaction. This problem is the exact same on an abstract level for 1 or many groups , 1 or many people and so on. If done properly it scales basically by itself.

Since you gave the example of not wanting things to just randomly, happen, it sounds like you are starting in a vacuum and could add any code you want, so I'm trying to figure out what 'mechanism' means to you. Do you want a mechanism that models something? like a certain social behavior (assuming that the nodes still repreent npc's and you weren't just using that as a term to keep the example simple), and thus need an 'algorithm.' Or are you trying to distribute data over a network, or over a million virtualized game objects, where you are trying to achieve a certain function (like how my modular neural network distributes modules around and connects them) and thus need a 'mechanism.'
Can only repeat myself here - dissipation of information is the technical wording. Flow of information with respect to principles of rumours just a different wording. It is really simple actually since the actual process is not what the player sees or deals with but the results. If the results seem to be accaptable (logical) for the player he/she doesnt care how the result was created. But if the result is off or seems too much based on pure randomness a player will not accept those results or wont use the mechanic in a strategic sense. So when the player can call a buddy and tell them about the slutty girl next door and that information ends up with her friends it creates consequences. Those are visible to the player and he/she recalls the phone call to the buddy. aha. Mechanic spotted. Lets try this again. Calls buddy again but this time talking shit about the dude he really hates deeply. Hoping this will end up in his circles and create some trouble for him. Player uses mechanic as a strategic element. Basic game design.

An algorithm can design a mechanism, but a mechanism can also design an algorithm.

You want to start with an algorithm if you want a certain behavior with regards to controlling the flow of information (aka 'when' hence me making the graphs, something to talk about with regards to time and sequence).

You want to start with a mechanism if you want a certain behavior with regards to controlling information flow (aka the 'how' aka the weighted edges and repeated loops, so data only travels through the edges like signals in a circuit)

anyways, words play, a tricky beast!

 

[Saki_Sliz]

It seems like I don't understand what it is you are trying to do.

Exactly this is not what i asked. 1 mechanism that dissipates information is the mechanism. there are no multiples in this but a variation of behaviour depending on relations between nodes.

ok, so good.
- so we are talking about a 'single' mechanism, no other game systems,
- and there is a way that this mechanism's behavior can change.



you are using

By applying a weight to an edge you get more control opportunities, more meaning overall. It is pretty much a basic of graph theory.

as the means by which you will affect the mechanism' behavior.



I then assume, when you want to change the mechanics behavior, you mean changing the weights as desired, for X reason.

You emphasize 'social network', and say its not a 'data network', I assume by

Groups and people are dynamic and the player has ability to influence certain aspects by interaction.

what you think differentiates between a 'social network' and a 'data network' is a data network is fixed, never changing shape, but with your mention about the ability for the player to influence 'aspects' and you use the term 'dynamic' makes me think you are talking about, how at any moment, relationships could change, there could be physical blockers or open opportunities, aka the weights are changing as needed, control by 'something' be it other game mechanics, nuances about the rumor itself, etc.

if that is true, then to me, it is still a data network distributing information, it is just 'dynamic' which is fine to talk about at a high level, but as what ever kind of programmer I am, for me, I can't talk about this aspect without gets into code talk again.

Calls buddy again but this time talking shit about the dude he really hates deeply. Hoping this will end up in his circles and create some trouble for him. Player uses mechanic as a strategic element. Basic game design.

Sound about what I thought, cool idea, and

the actual process is not what the player sees or deals with but the results.

which sounds about on pair. Does the NPC hear the rumor (which if they do, generates the results the player wants)

here's what caught my eye this round (thanks for being patient with me), the player only deals with the results, and the system is being used in some strategic way, even if the player don't know about the system. the keyword is "hoping."

When you say 'hoping' there's two ways I think you could be using the term (assuming it's not just part of your day to day vernacular and you were strategically using the word to deliver a particular point or meaning, and I'm not just reading too much into things). Why is the player hoping? is it:
- A) Simply because they don't know that much about how the game works, they don't know if the dialog option 'counts' as a rumor (aka players are working with a lack of information)
- B) players do know enough to understand that spreading rumors is a possibility (the dialog box could make this clear by saying [Start Rumor] to indicate that players are initializing a game mechanic), and the 'hope' is because it is possible (by some probability mechanism) that the rumor has no effect (the NPC you hate does not get in trouble). So in this case, the strategic element would be a boolean, yes/no it works, but only on chance (based on your mechanism)

Talking about the concept as 'strategic' changes the type of project (game) that I think you are trying to do. Where as before I was assuming a complete open world, with lots of NPC interactions like some sort of Virtual Novel and the players are only 'feeling' the world, by saying that the players 'hope' an npc gets in trouble, it sounds the player will be seeing things more directly, be it a strategy game (managing resources) or simplified mechanism (like an RPG game but you can't get into a door way because that NPC you hate is in the way, and you are trying to find someway to get them removed, and so every now and then you check to see if they left yet). The difference between the two is, with the open world, data always expands and grow, but with stratigic elements, there is more of a focus on linearity (aka maybe player can only give off rumors in a certain order to get the results they want) and chance (possibility of it not taking affect), with the key being, there is no 'looping' that allows the 'knowledge' to eventually spread to all, but that at some point the spread 'will' stop, some npc's won't get the knowledge (or at least that what it sounds like you want).

If that is so, then it sounds like a stochastics problem instead.

 

[toolkitxx]

The pl

It seems like I don't understand what it is you are trying to do.





ok, so good.
- so we are talking about a 'single' mechanism, no other game systems,
- and there is a way that this mechanism's behavior can change.



you are using

as the means by which you will affect the mechanism' behavior.



I then assume, when you want to change the mechanics behavior, you mean changing the weights as desired, for X reason.

You emphasize 'social network', and say its not a 'data network', I assume by

what you think differentiates between a 'social network' and a 'data network' is a data network is fixed, never changing shape, but with your mention about the ability for the player to influence 'aspects' and you use the term 'dynamic' makes me think you are talking about, how at any moment, relationships could change, there could be physical blockers or open opportunities, aka the weights are changing as needed, control by 'something' be it other game mechanics, nuances about the rumor itself, etc.

if that is true, then to me, it is still a data network distributing information, it is just 'dynamic' which is fine to talk about at a high level, but as what ever kind of programmer I am, for me, I can't talk about this aspect without gets into code talk again.


Sound about what I thought, cool idea, and

which sounds about on pair. Does the NPC hear the rumor (which if they do, generates the results the player wants)

here's what caught my eye this round (thanks for being patient with me), the player only deals with the results, and the system is being used in some strategic way, even if the player don't know about the system. the keyword is "hoping."

When you say 'hoping' there's two ways I think you could be using the term (assuming it's not just part of your day to day vernacular and you were strategically using the word to deliver a particular point or meaning, and I'm not just reading too much into things). Why is the player hoping? is it:
- A) Simply because they don't know that much about how the game works, they don't know if the dialog option 'counts' as a rumor (aka players are working with a lack of information)
- B) players do know enough to understand that spreading rumors is a possibility (the dialog box could make this clear by saying [Start Rumor] to indicate that players are initializing a game mechanic), and the 'hope' is because it is possible (by some probability mechanism) that the rumor has no effect (the NPC you hate does not get in trouble). So in this case, the strategic element would be a boolean, yes/no it works, but only on chance (based on your mechanism)

Talking about the concept as 'strategic' changes the type of project (game) that I think you are trying to do. Where as before I was assuming a complete open world, with lots of NPC interactions like some sort of Virtual Novel and the players are only 'feeling' the world, by saying that the players 'hope' an npc gets in trouble, it sounds the player will be seeing things more directly, be it a strategy game (managing resources) or simplified mechanism (like an RPG game but you can't get into a door way because that NPC you hate is in the way, and you are trying to find someway to get them removed, and so every now and then you check to see if they left yet). The difference between the two is, with the open world, data always expands and grow, but with stratigic elements, there is more of a focus on linearity (aka maybe player can only give off rumors in a certain order to get the results they want) and chance (possibility of it not taking affect), with the key being, there is no 'looping' that allows the 'knowledge' to eventually spread to all, but that at some point the spread 'will' stop, some npc's won't get the knowledge (or at least that what it sounds like you want).

If that is so, then it sounds like a stochastics problem instead.

The player is hoping because it is the first time he/she uses what seems to be a mechanic. There are clear defintions in game design what a mechanic is and result is one of them Until the result actually appears this is just a longshot for the player but becomes a visible and usable mechanic once the result is as expected. That is how mechanics are often discovered by players unintentionally or because the mechanic is deliberately designed that way. And i wholeheartetly disagree with your assumption about linear. It is a design choice and not a given. Everything actually is a design choice but often certain aspects are given more room than others. Especially in commercial products certain design choices are not very popular either for cost reasons or the lack of technology/knowledge.

My project is heavily centered around social interactions and relationships thus the foundation is a social network in a dynamic world where many things are not predictable in terms of outcome for me as dev as the player has certain freedoms.
In general: I appreciate you getting involved but you should start reading things first in context before drifting off when certain words appear. You constantly try to draw back into a data model which i explained is the wrong assumption. My wording is precise enough for the question i asked to get a result or input/ideas. This thread is not meant to explain all kinds of mechanics and features of the game but to solve the original problem.

 

[Saki_Sliz]

Sounds good, it may just be me, but it just keeps sounding like you are stuck on a fundamental data distribution problem, but the concepts don't sync up with how you've learned to think. The terms and concepts that I've been bringing up don't sync with how you use them or want to handle the problem, which is why I was testing the FoM concept.

Like Linearity, I'm not talkning about linear game design, where 'game design' is one type of FoM and 'linear' is a key term. I'm referring to, it takes more than 1 rumor to get to a certain point or state in the game (such as getting the photo of a npc the player likes), and that it requires a sequence, an order, state 1 2 and 3.

But then, I'm also struggling to try to keep everything simple, because to my programmer brain, even tho you are trying to keep things high level and abstract, describing it as one mechanism, I can see where oversimplification would lead to pitfalls in code implementation, and that a better way to implement the model is to break it down into certain pieces, which is a conversation I was holding off on given I've invented my own language for that based on 'orders of complexity' developed around Conway's game of life.

Good luck with your project, was fun talking with you! I know I like talking with others because even if not much happens, trying to talk about it can help one develop a better understanding of their own idea.

 

[toolkitxx]

Turns out that my problem is not that uncommon and if one just applies some decent search-foo there is actually a vast pool of material been written on this stuff. For anyone dealing with a similar problem I can highly recommend this wonderful

You must be registered to see the links

from Stanford University - made at least me a bit smarter by now.

Tompte Have been playing with your idea and so far i am actually pretty happy how it works . Thx again for the spark