On viscosity

[Kaya]

While I love the idea of viscosity, the way it's implemented is terrible. Not only from a gameplay perspective, but also when looking at it conceptually. As such I will propose a few fixes to integrate viscosity more with MD as well as to make it less destructive from a gameplay perspective.

 

Part 1 (Averaging out viscosity):

The first issue is the Viscosity Dead Trap. Basically when moving from one scene to another, you have no way to know how much taking that same step back will cost you. A scene with -80 viscosity can be followed up by a scene with 40 viscosity (and yes, that is very common, especially in MB) making it easy to leave, but hard to come back without any former warning. For an old player this isn't too much of an issue, but for a new player getting stuck in viscosity can be a reason to quit.

 

This exact same thing is also possibly the biggest conceptual issue with viscosity:

 

If md is seen as a "fluid", viscosity values placed on the map will turn it into piles of more or less stones, not a fluid anymore.

 

Part of the argument Mur gave against showing viscosity on the map was that it would make viscosit look more like a pile of rocks, then like a fluid. Sadly as it works at the moment viscosity is not even at the level of a pile of rocks. Instead it acts more like a magnet, pulling the player towards the centre of the scene.

 

Solution:

The solution to both above issues is very simple. For the viscosity on a link between 2 scenes, do not use the viscosity in the current scene, but the (weighted) average of the viscosity between those scenes.

 

As I believe this post is long enough as it is, I will leave it at this for now, but expect a part 2 soon.

[Chewett]

I considered this idea before actually, although the data structure in the database stops easily doing this. I was looking at building a graph of the scene mappings but was foiled by the large amount of faff formatting the database.

 

I like the idea and I think it makes sense. I was considering making the visc "flow" also.

[DARK DEMON]

While I love the idea of viscosity, the way it's implemented is terrible. Not only from a gameplay perspective, but also when looking at it conceptually. As such I will propose a few fixes to integrate viscosity more with MD as well as to make it less destructive from a gameplay perspective.

 

Part 1 (Averaging out viscosity):

The first issue is the Viscosity Dead Trap. Basically when moving from one scene to another, you have no way to know how much taking that same step back will cost you. A scene with -80 viscosity can be followed up by a scene with 40 viscosity (and yes, that is very common, especially in MB) making it easy to leave, but hard to come back without any former warning. For an old player this isn't too much of an issue, but for a new player getting stuck in viscosity can be a reason to quit.

 

This exact same thing is also possibly the biggest conceptual issue with viscosity:

 

 

Part of the argument Mur gave against showing viscosity on the map was that it would make viscosit look more like a pile of rocks, then like a fluid. Sadly as it works at the moment viscosity is not even at the level of a pile of rocks. Instead it acts more like a magnet, pulling the player towards the centre of the scene.

 

Solution:

The solution to both above issues is very simple. For the viscosity on a link between 2 scenes, do not use the viscosity in the current scene, but the (weighted) average of the viscosity between those scenes.

 

As I believe this post is long enough as it is, I will leave it at this for now, but expect a part 2 soon.

 

Though this would make going to places like inside MDA harder. If people work to lower visc outside the gates, the average visc of inside and outside would increase it still.

[Kyphis the Bard]

Well, not necessarily. Rather than think of it as viscocity being a single fluid, try thinking of it as two fluids - viscocity and void viscocity (or fluidity, haha).

If the average viscocity levels produced a bias due to flow, then in a location with max viscocity, when trying to reduce it you would see:

• A slow depletion as the local levels worked to balance out
• A steady leveling off in local scenes around the mid point (5-35 visc)
• A rapid reduction as the weight of void viscocity pushed back at the viscocity, causing it to heap in other scenes.

Although, like this there would still be unequal values on a link between two scenes, they would just remain fairly similar (SD on a relative bell curve surface)

[Ary Endleg]

When I was new, when I read about viscosity, at first for some reason I misunderstood it. I was thinking that viscosity make it harder for you to enter the scene with higher viscosity at that scene, not the scene you are at.

 

Meaning for example that if GoE has -80 visc, BW has +40 visc. If you are at GoE it would cost you 41 AP to enter BW because it would take into consideration only the viscosity of location you want to enter.

 

That simply was more natural and intuitive to me rather than how it actually is at the moment. You know, if you are walking the road it's harder to wander off it into the wilderness, but if you are coming from the wilderness towards civilization, that path is naturally easier. At least in my head.

 

Maybe this misunderstanding of mine can come in handy for your ideas.

[Chewett]

Sounds like a nice idea

[Kaya]

 

Though this would make going to places like inside MDA harder. If people work to lower visc outside the gates, the average visc of inside and outside would increase it still.

 

The idea is indeed that (viscosity wise) moving into viscous territory is equally hard as moving out of it, making passing gates harder, but preventing people to get surprised by a sudden gulf of viscosity and allowing one to leave any viscous area with more ease.

 

 

I considered this idea before actually, although the data structure in the database stops easily doing this. I was looking at building a graph of the scene mappings but was foiled by the large amount of faff formatting the database.

 

I like the idea and I think it makes sense. I was considering making the visc "flow" also.

 

Having viscosity flow along the heat veins was actually one of the things I was going to suggest, but I wanted to look into it some more before actually writing out a full suggestion for it. (I assume this->connection[x]->other->viscosity wouldn't do the trick, would it?)

 

 

When I was new, when I read about viscosity, at first for some reason I misunderstood it. I was thinking that viscosity make it harder for you to enter the scene with higher viscosity at that scene, not the scene you are at.

 

I think that is similar to the understanding most of us had when we first heard of viscosity and I agree that would already feel a lot more natural/intuitive than the way it works right now. Problem is that as DD mentioned averaging them out makes it harder to lower viscosity in order to enter a scene, but using the other scene makes it impossible without having someone on the other side of the gate. A second reason I prefere averaging over taking either side is because it makes MD seem more like a continues space, rather than a number of strictly separated scenes.

[No one]

 

I think that is similar to the understanding most of us had when we first heard of viscosity and I agree that would already feel a lot more natural/intuitive than the way it works right now. Problem is that as DD mentioned averaging them out makes it harder to lower viscosity in order to enter a scene, but using the other scene makes it impossible without having someone on the other side of the gate. A second reason I prefere averaging over taking either side is because it makes MD seem more like a continues space, rather than a number of strictly separated scenes.

What do you mean that averaging is making harder to enter a scene ?

If in scene A you have -80 viscosity and in scene B you have +40 ... you'll have it averaged at -20. You just need a large crowd to get first scene under -40 viscosity.

 

Did I missed something ?

 

My question about averaging viscosity .... how would it affect the volition ?

Edited November 12, 2014 by No one

[Ary Endleg]

Well if scene is 666+visc then this new averaging system would make it harder to enter it. :p

 

It affects all scenes that have AP requirement higher than 20, such as gates and east.

[No one]

hmm, it seems there is a small misunderstanding.

 

I am talking about viscosity, not about the Ap requirement to pass a gate.

666 is nothing compared to the 2x1k and 2k gates from LotE. That gate requirement is not to be affected by this averaging of viscosity.

[Rophs]

We can have earthquakes...

 

What happens during an earthquake? The ground shakes in a way so that the viscosity becomes evenly distributed about the realm! Add up the visc in all of the scenes (except for ones in NML), divide by number of scenes (except ones in NML) and then set the visc at every scene to that amount. Why ignore NML? Because visc there can't be above 0 so it would artificially skew the global results.

[Kyphis the Bard]

What do you mean that averaging is making harder to enter a scene ?

If in scene A you have -80 viscosity and in scene B you have +40 ... you'll have it averaged at -20. You just need a large crowd to get first scene under -40 viscosity.

 

Did I missed something ?

 

My question about averaging viscosity .... how would it affect the volition ?

 

 

Actually, that is an interesting point. Rather than anything complicated with Viscocity flows, you could just keep viscocity increase/decrease as it already does, and average the value between the two connected locations... so (([a]+[b])/2)+[regular AP]=[total AP cost]

[Maebius]

I considered this idea before actually, although the data structure in the database stops easily doing this. I was looking at building a graph of the scene mappings but was foiled by the large amount of faff formatting the database.

 

I like the idea and I think it makes sense. I was considering making the visc "flow" also.

 

Yep, first thing I thought of was the Heat Vein calculations somehow tying in or referencing the Viscosity.  Probably WAY more of a system/database hit to process all that, but conceptually, it makes sense. 

Otherwise, I always envisioned Viscosity how others seem to:   Namely,  it factors in the Receiving scene somehow.   

But I understand from a coding point, that creates a whole mess of inter-connections that are simplified by merely checking "current scene".

 

I wouldn't average them, though,   I'd keep the current system, but when it increases, High Viscosity flows/bleeds/crystalizes along the veins to the adjacent scene closer to centre. 

Yes, this means that the center would accumulate faster but also is where people gather now and reduce it quickly, so might not be too much trouble. 

The fringes would stay "maxed/isolated" based on the current method of slow increase-over-time.      

 

However, it also means that an extended effort of the community on "the fringes" would lower viscosity along the heat-veins as well, making the whole "path" potentially a bit easier to walk.   

And thus, a rather interesting compromise?

[Chewett]

I like these ideas, still.