Use IMPULSE ENERGY HEALTH terminology

[ghost]

We need better terms for Impulse Damper and Damage Damper, they are problematic on many levels:

1. If your goal is to differentiate many abstract things from each other a common word like "Damper" is unnecessarily misleading.
2. One word is better than two.
3. Both "Damper" approaches ask the player to first build up a mental concept of a force and THEN applying a vague concept (dampening) to it. There is no need to derive a basic concept from even other basic concepts.
4. Using more generic and maybe less "accurate" words everywhere enables self-explanation, where otherwise you would need to do lots of explaining.

I started more or less from scratch and noticed that there is this element that makes either you, your enemy or disks GO FULL FLIPPER BOUNCY! And since you always have a reservoir of that flipperness at your disposal "Impulse" could be a good name. The other thing at your disposal is the stuff that either shields you or hurts others depending on how you use it. Who does not think "Energy" when hearing "shield" and "laser guns"? While maybe not the most stylish wording "Health" is a word that I have no complaints about. It is spot on.

The trinity Impulse | Energy | Health is exactly what I need to work on ways to make it click in peoples heads when they experience the game in the gameworld, the GUI, the HUD or the manual.

[fr1tz]

The mechanic that works like a shield (ie. shields you completely from damage until it is gone) is the damage buffer (it was called "shield" in later versions of ROTC), but the people in the IRC chat preferred "damage buffer" for TOL.
Energy by itself is fine, but also an unnecessary step, because it would have to power both weapons and the module that reduces damage, so why not simply have the module that reduces damage and have weapons drain power away from it directly. Besides, ROTC pretty much proved that nobody sees an "Energy" bar and thinks "I'm sure I'll take more damage if I have less energy".
Same goes for "Impulse": Would be perfectly fine if the push from weapons would not increase if you have less of it, but having less "Impulse" leading to an increased effect of impulse (the weapon property) on you doesn't make sense.
I'm not married to "x damper", but there are no established terms in the FPS world that describe that particular mechanic. What about renaming impulse (the weapon property) to something else? A lot of players seem to have no idea what is meant by "impulse" and then the bars on the HUD could be labeled something descriptive like "Damage Reduction"/"Knockback Reduction" or perhaps "Damage Protection"/"Knockback Protection" (as "reduction" might be interpreted as reducing the amount of damage/knockback you do rather than reducing the amount of damage/knockback you receive.

[fr1tz]

Mray, is there a misunderstanding here and you're suggesting to change those mechanics so that (using your terms here) the lower your "impulse" is the less impulse you inflict on enemies and the lower your "energy" is the less damage you inflict on enemies?

[ghost]

@damage buffer: This is a bit off topic but for me it is just a part of your health that heals by itself - not needing any explanation. It might get mentioned as a detail somewhere but needs no new terminology.

@Energy: You suggest having ONE device "mentally" coupled to a resource but then have ANOTHER device draining from the ONE. This creates a false hierarchy between offence and defence (one could as well drain from the other!) but more importantly it makes your mind care about a connection (draining) in the first place. Wich is bad: both drain from a THIRD thing, and that is what needs the attention.

@impulse: Same is true here: again we have one resource for related activies, only this time it is about movement, not offense vs. defence. You can spend the resource in enhancing your movement or keeping it on you as a shield.

@misuderstanding: No this is absolutely NOT what ever suggested. I DID suggest something else some time back though: weapons should draw their respective impulse just like the BOUNCE does! So you can spend impulse in carring it around as a protection vest against other impulse - or - throw it along with your shots against other players (which is very similar on how you "spent" it on yourself in form of etherboarding and jumping.) Imho this would be elegant since it adds interplay while removing complexity. (The perfection of the logic throughout the game would be to be able to use energy to heal yourself. But that is really OT here.)

[fr1tz]

What's more complicated?
a) Firing your weapons reduces your "damage protection".
b) Firing your weapons reduces your "energy" which in turn powers a device that reduces the damage you take based on how much "energy" you have.

Same goes for "impulse". Or how would you describe what "impulse" and "energy" are?

@Misunderstanding: I was asking because if you did less damage/impact based on how low the bars are, your terminology would make perfect sense.

[ghost]

a) forms the shorter sentence.
b) describes the less complicated concept.

_"Energy powers weapons or shields.
Impulse pushes or stabilizes."_

This is the simplest, most compact yet descriptive and illustrative way to put it.
Sir, I hereby challenge thou to form a shorter and simpler description of energy and impulse!

[fr1tz]

b) just hides the concepts behind vague/potentially confusing words. The damage reduction mechanic is not a "shield". In FPS games "shield" refers to something that takes damage in lieu of the player's health until it's completely depleted.
"Impulse pushes or stabilizes" is like saying "Gravity pulls or pushes", which one is it? Using the same word for something that has two opposing meanings is very confusing. Besides, "impulse" stabilizing things is about as intuitive as "damage" healing things.

[ghost]

b) is phrased complicated (not by me!) and is neither a vague nor a confusing concept - please do have a look at my way to put it: "Energy powers weapons or shields."

I don't share your concern of a slight deviation of a shield compared to other FPS btw. TOL can differ in details as long as our shield shields! We certainly don't need to copy mainstream mechanics in detail.

@ "Gravity pulls or pushes"
There is no point in asking _"What is A?" if all you know is _"A can be x or y."__.
The correct question is: "How does it get decided?"
The answer is of course: "It depends on you!" - and understanding your choices is understanding the concept. Your options are clear and simple:

• EITHER spend it in protecting you from enemy weapon push,
• OR use it to push yourself up (jump) or forward (etherboard).

Short: "Impulse pushes or stabilizes".

@ impulse + stabilize contradict:
impulse doesn't necessarily need to result in motion (like the middle balls), but lets not get too hooked up on actual physics

I'm also not married to "impulse" as a the only word. "push", "splash", "momentum", "acceleration" or other things might work as well. Also "stabilize" can be "stiffen", "decelerate" or whatever...

I still see no shorter or simpler way to explain the mechanics via Impulse Damper and Damage Damper.

[fr1tz]

Impulse/Damage reduction are mechanics that are not obvious to the player. The easiest way to make the player aware of them is via the HUD: If you have a bar labeled "Damage Protection" that goes from 0% to 50% and a bar labeled "Impulse Protection" that goes from 0% to 75% it's somewhat obvious what's going on when you fire weapons and see your "Damage Protection" bar decrease or when you use your Etherboard and see your "Impulse Protection" decrease. On the other hand if you see your "impulse" bar decrease you'll have no idea what that means. Does it mean you'll move slower or is it simply there to put a limit on your usage of the Etherboard/XJump? Labeling it "acceleration", "push" or "momentum" is even more confusing. You use your Etherboard to gain speed but see your "acceleration" or "momentum" decrease? - Where's the logic in that?

[ghost]

On the other hand if you see your "impulse" bar decrease you'll have no idea what that means.

Of course you do! If the bar decreases you have less impulse, meaning you can push less or stabilize less. But how do you read how much less you can jump or board around while looking at some % labels? Obviously we can't expect the GUI to explain everything, so what good comes from judging an approach by how it explains one specific detail? As long as the resources/bars have multiple meanings there is no point in just labelling one on the expense of the other. It always obscures the other counterpart, no matter what. Hence the labelling of the very resource instead, while making its multiple purposes obvious.

That is why we need to establish meaningful 3-part models like:
energy: offence <--> defence
impulse: agility <--> stability

Again I challenge you to top this:

"Energy powers weapons or shields.
Impulse pushes or stabilizes."

[fr1tz]

If the bar decreases you have less impulse, meaning you can push less or stabilize less.

• Could also mean your weapons impart less impulse
• How is Etherboarding or XJumping "pushing"?
• Okay, let's say I have full "impulse", how do I use the "impulse" resource to stabilize?

Hence the labelling of the very resource instead, while making its multiple purposes obvious. That is why we need to establish meaningful 3-part models

No we don't, that's my whole point. ROTC used that approach with "anchoring"/"energy" and most players didn't get it. It doesn't matter what you call those resources ("impulse" just being a particularly confusing word imo). The idea is exactly to not present them as resources, but simply as important properties of a CAT (just like "Health"). The fact that they effectively also serve as resources for your weapons/etherboard/xjump might be obscured on the HUD, but becomes immediately obvious to the player during gameplay. The HUD is the only potentially effective way I see to alert the player to the presence of two unusual properties (amount of impulse/damage reduction when being hit) without having to read the manual (which almost nobody does).

tl;dr: ROTC showed that three part models don't work for these mechanics.

Again I challenge you to top this:
"Energy powers weapons or shields.
Impulse pushes or stabilizes."

"Damage Protection"
"Knockback Protection"
self explanatory.

Besides, I don't think a player can read

"Energy powers weapons or shields.
Impulse pushes or stabilizes."

And then actually understands what's going on. Those two sentences raise more questions than they answer imo.

Edit: I think you're trying too hard to create an elegant model rather than one that's simple to understand and can be communicated somewhat effectively through the game itself.

[LeoVerto]

I honestly prefer mray's model, it is more elegant and quite easy to understand. Even after being involved in the game for quite a while, I haven't fully understood the current system, which seems utterly confusing to someone new to the game.

A medium-scale poll/experiment on which system is easier to grasp for people without any knowledge of the game would be the perfect solution to solve this problem; unfortunately that'd be really hard to conduct in reality.

[ghost]

Could also mean your weapons impart less impulse

No solution can remove all doubt, there will always be room for misinterpretation.

How is Etherboarding or XJumping "pushing"?

Higher jumping is a push up, etherboard gives a constant push forward.

Okay, let's say I have full "impulse", how do I use the "impulse" resource to stabilize?

Don't spend it. (keeping it on the player where you let it do its thing)

ROTC used that approach with "anchoring"/"energy" ...

But it did not suffer from being a three part concept, there were many different aspects that failed to promote the idea successfully. I suggest we don't need to treat ROTCs faults here anymore. Time to look forward.

The HUD is the only potentially effective way I see to alert the player to the presence of two unusual properties...

Illustrating a rule by showing the unusual strikes me as a rather unintuitive way to make a point. Also I don't see how one part or the other is more important or unusual, they are two sides of the same coin. But even if there was, you still fail to address the whole mechanic and focus on only one part that does not explain the underling rule, rendering the one info you do provide almost useless. (unless you know TOL in and out aleady anyway)

tl;dr: ROTC showed that three part models don't work for these mechanics.

I don't follow how you can deduce that specific insight.

"Damage Protection"
"Knockback Protection"
self explanatory
This is no explanation.
These names explain themselves, but neither the mechanic they are part of, nor their counterparts.
My approach does all of that.

Those two sentences [my explanation] raise more questions than they answer imo.

Like what? (They certainly explain more than your approach.)

Edit: I think you're trying too hard to create an elegant model rather than one that's simple to understand and can be communicated somewhat effectively through the game itself

True, a simple to understand and easy to communicate is the elegance we are after here. Spending too much time on that seems almost impossible to me.

[fr1tz]

No solution can remove all doubt, there will always be room for misinterpretation.

I think terms like "Knockback Protection"/"Damage Protection" leave much less room for misinterpretation than something like "impulse" or "energy".

Higher jumping is a push up, etherboard gives a constant push forward.

While you could argue that xjumping pushes yourself, the amount of push is not reduced based on how much Impulse Damper you have. Also Etherboarding does not give a constant push forward.

But it did not suffer from being a three part concept, there were many different aspects that failed to promote the idea successfully. I suggest we don't need to treat ROTCs faults here anymore. Time to look forward.

Humor me and explain to me how your model is different from ROTC's. Because to me it looks exactly the same (except using the word "impulse" instead of "anchoring").

Illustrating a rule by showing the unusual strikes me as a rather unintuitive way to make a point.

That's because it's not illustrating a rule by showing the unusual, it's using the HUD to illustrate an unusual rule that would otherwise remain invisible to the player.

Also I don't see how one part or the other is more important or unusual, they are two sides of the same coin. But even if there was, you still fail to address the whole mechanic and focus on only one part that does not explain the underling rule, rendering the one info you do provide almost useless. (unless you know TOL in and out aleady anyway)

What? Please explain the underlying rules to me.

I don't follow how you can deduce that specific insight.

By developing and playing ROTC for a long time and chatting with a lot of newbies.

Like what? (They certainly explain more than your approach.)

• How do I switch between energy powering my shield or my weapons?
• Do my weapons do less damage if I have low energy?
• How do I switch between impulse pushing or stabilizing?
• How can I push enemies using my "impulse" resource?
• Can I use "impulse" to stabilize other CATs?

A medium-scale poll/experiment on which system is easier to grasp for people without any knowledge of the game would be the perfect solution to solve this problem; unfortunately that'd be really hard to conduct in reality.

I'd argue that such a poll has been done and it was called ROTC: Ethernet. The result was that "100% of people that never read the manual" I talked to did not even realize that there were damage/impulse reduction mechanics at play. And I fail to see how mray's model is different (aside from changing the word "anchoring" to "impulse") than the one presented in the ROTC manual.

[LeoVerto]

I'd argue that such a poll has been done and it was called ROTC: Ethernet. The result was that "100% of people that never read the manual" I talked to did not even realize that there were damage/impulse reduction mechanics at play. And I fail to see how mray's model is different (aside from changing the word "anchoring" to "impulse") than the one presented in the ROTC manual.

Isn't this whole discussion mostly about terminology? If most players don't these game mechanics, why not give them simple (maybe physically not correct, but understandable) names and explain them in a minimalistic manual and/or an in-game tutorial?

The current names try to be self-explanatory but I'd argue they utterly fail to do so. The best solution to this seems to me to give them simple names and explain them briefly.

[fr1tz]

@LeoVerto: Imagine seeing this on your HUD:

Health: 100%
Damage Protection: 50%
Knockback Protection: 75%

What would you think someone new to the game would think these numbers mean?

[LeoVerto]

What would you think someone new to the game would think these numbers mean?
Well, those are already a lot clearer than the "Damper" ones.
They do however only describe the passive, defensive usage of the resources. Why would shooting reduce my damage protection? And jumping my knockback one?

I would prefer exposing the resource amounts to the player and teaching them what exactly they power in the manual.

Grasping all the data and using it as a basic for decisions during fast-paced gameplay is pretty much impossible for new players. Advanced ones should at least have played the tutorial.

[fr1tz]

Why would shooting reduce my damage protection? And jumping my knockback one?

Why would someone design a combat unit where the same resource powers both a defensive property and the unit's weapons? - No one would in the real world ;)
The answer in case of a game like TOL is simply "because the designer thinks it makes the combat more interesting", but the "why?" doesn't really matter, all that matters is that the player knows that there's a property that reduces incoming damage ("damage protection" being prominently featured on the HUD) and that the value of the property decreases if the player fires weapons (obvious because the player can see the value go down).

I would prefer exposing the resource amounts to the player and teaching them what exactly they power in the manual.

Not acceptable because no-one reads the manual.

Grasping all the data and using it as a basic for decisions during fast-paced gameplay is pretty much impossible for new players. Advanced ones should at least have played the tutorial.

Like I mentioned in IRC: I want to move the "firing weapons reduces damage protection", "using etherboard/xjump reduces knockback protection" and "damaging enemies restores your health" out of the basic game into separate mutators and a collection of those three mutators into something that's probably going to be called "advanced" or "1337" mode.

That way players will be aware of the "damage protection"/"knockback protection" stats but won't have to worry about them in the basic game, and when they join an "advanced" server the loading screen can prominently alert them to the fact that on this server, firing your weapons reduces your "damage protection", etc.

[ghost]

Etherboarding does not give a constant push forward.

This is nitpicking.

Illustrating a rule by showing the unusual strikes me as a rather unintuitive way to make a point.

That's because it's not illustrating a rule by showing the unusual, it's using the HUD to illustrate an unusual rule that would otherwise remain invisible to the player.

I think we are getting closer to our problem. If I get it right you don't have any plans to actively establish a general rule at all! Instead you really want to leave it to the player to figure out the general principle, and only help with the parts that are too hard to guess.
Did I get that right? Please do correct me when I phrased it wrong.

What? Please explain the underlying rules to me.

"Energy powers weapons or shields.
Impulse pushes or stabilizes."

How do I switch between energy powering my shield or my weapons?
Do my weapons do less damage if I have low energy?
How do I switch between impulse pushing or stabilizing?
How can I push enemies using my "impulse" resource?
Can I use "impulse" to stabilize other CATs?

Those questions aim at details - not the general mechanics; best answered in a complete manual.
They also imply an understanding of the general principle.
Your explanation does not even provide starting points for those questions.

Not acceptable because no-one reads the manual.

Your position is hardly constructive. People certainly did read the manual in ROTC, when they got no clue during gameplay. Unfortunately the manual was lending itself for adding to the confusion.
But I'm working on those flaws in ROTC and TOL: a catchy manual introducing an easy concept. Please don't tell me that all I did was in vein.

[fr1tz]

"Energy powers weapons or shields.
Impulse pushes or stabilizes."

But these are not the underlying rules. The underlying rules would go something like this:

• CATs have two Energy slots that constantly recharge up to a maximum of 100.
• Most weapons consume energy from slot 0 while using the Etherboard or XJump consumes energy from slot 1.
• If something (for example a projectile) tries to apply a certain value of damage to a CAT, that value
  is reduced based on the value of the CATs energy slot 0 like this:
  (see https://github.com/fr1tz/terminal-overload/blob/master/My%20Projects/main/game/notc/base/shapeBase.cs#L272)
  actual_damage_value = original_damage_value - original_damage_value * energy_slot_0_value_in_percent * damper
  Where damage_damper is 0.5 if the CAT is outfitted with a damage damper module and 0 otherwise.
• If something (for example a projectile) tries to apply a certain value of impulse to a CAT, that value
  is reduced based on the value of the CATs energy slot 1. See https://github.com/fr1tz/terminal-overload/blob/master/My%20Projects/main/game/notc/base/shapeBase.cs#L343 because I don't feel like typing more pseudo-code, but in the end it works similar to the damage reduction.

So

"Energy powers weapons or shields.
Impulse pushes or stabilizes."

are not the underlying rules but an attempt to create player- and manual-friendly versions of the abstract rules that govern TOL's fictional universe, right?
I'm assuming 'yes' to that question and my problem with those two "simplified" rules is that they're reductionist to the point of being meaningless unless you're already intimately familiar with TOL's rules. To me it looks like Maslow's hammer is at work here and you've chosen "impulse" to be your hammer, which is why I think you consider my complaint about etherboarding not giving you constant push forward to be nitpicky.

I think we are getting closer to our problem. If I get it right you don't have any plans to actively establish a general rule at all! Instead you really want to leave it to the player to figure out the general principle, and only help with the parts that are too hard to guess.
Did I get that right? Please do correct me when I phrased it wrong.

Depends on what exactly you mean by "a general rule" and "the general principle". Could you (for clarity's sake) please give definitions of those two terms in the context of this discussion?

People certainly did read the manual in ROTC

Technically you are right, the 2-3 lifeforms that actually read the ROTC manual are indeed people ;)
My point is that the vast majority of players did not read the manual, that I learned that the general rule is that most players don't read the manual and thus that you can't rely on the manual to explain important stuff.

Please don't tell me that all I did was in vein.

Don't know because I've not yet seen anything of what you did in regards to a manual. I didn't even know you were working on a manual (your public todo list was last updated about a month ago and contains the line "put forth a very basic manual").

[fr1tz]

Btw, a reason why I want to move the "weirder" rules like "firing weapons reduces damage protection" into mutators is that it eliminates the need to explain how they work (just like UT's "vampire" mutator does not explain how damaging enemies increases your health), but you could get pretty creative if you want to explain them. For example you could argue that using your weapons reduces the amount of computing cycles your CAT can allocate to its defensive sub-systems.

[ghost]

Depends on what exactly you mean by "a general rule" and "the general principle". Could you (for clarity's sake) please give definitions of those two terms in the context of this discussion?

My definition of "general rule", "general principle", "general mechanics", "basic concept" etc. (actually we need to settle with a term for this, too):

IT IS :

• a simple explanation of how the game mechanics work.
• a collection of terminology and design hooks like color-coding, icons, visual and sound effects.
• a collective effort through manual, tutorials, online help, GUI, HUD... to establish a narrative helping players to explain the game to others and themselves.
• more than "energy, impulse and health"; disks & locking are missing (that is something for later).
• subject to interpretation or intelligent guessing to some degree.

IT IS NOT:

• a mere label for things and behaviours.
• a "manual" in the sense of an extensive resource explaining the entire game in all its details.

[fr1tz]

Alright, do you have a suggestion how to proceed with working this out?

[ghost]

Issue #17 shows the current state of online help (need to upload the changes still). If that would reflect the actual game we could put up some usable info on the homepage to send people to. Additionally the materials used there could be re-used in in-game help or manual sections.

Issue #63 shows my ideas on how HUD and GUI could look like in that context.

Working out a catchy description & terminology for locking part of the mechanics might be a good idea, too. I would like to make sure everything fits together as soon as possible. But that could really wait.

[fr1tz]

Sorry, but I'm not going to change the game to reflect the infographic from #17 (neither in terms of the HUD nor the Impulse/Energy terminology).

[ghost]

Do you have any interest at all in something like I defined? In case you do - what is your suggestion to get this done?

[fr1tz]

Updated my public TODO. An explicit visual coding for impulse (the projectile/explosion property) is not on it because I consider that unnecessary/confusing visual noise (no other FPS does it) and because in most cases it exactly overlaps with the visuals for damage (currently the yellow geometric shapes).

[fr1tz]

Btw, in terms of the HUD I'd be perfectly happy to allow the player to choose between default and alternative HUDs, but you'd have to implement your suggestion yourself or find someone else to do it.

[ghost]

I don't see how you are addressing my initial question. Can you please be more specific?

[fr1tz]

Do you have any interest at all in something like I defined? In case you do - what is your suggestion to get this done?

Of course I have an interest in something like that, I'm working on it. To be more specific:

a simple explanation of how the game mechanics work.

In the form of an infographic like #17? Don't know if it makes sense to put effort into something like that now when terminology & HUD is going to be quite different in next release.

a collection of terminology and design hooks like color-coding, icons, visual and sound effects.

I've already created all this. Sure some things need to be improved considerably, but I'm always working on it, just takes a lot of time.

a collective effort through manual, tutorials, online help, GUI, HUD... to establish a narrative helping players to explain the game to others and themselves.

I've written a basic manual for 0.5.0 and finally implementing a decent HUD is something I'm going to tackle now. Something like an in-game tutorial is a lot of work which is why I personally would wait until 1.0 to do one (otherwise it's a lot of work for virtually nothing because things might already be drastically different in the next release). Something like a video tutorial would require much less effort but it also requires a machine capable of recording decent quality video, which I don't have (all my hardware is quite old).

more than "energy, impulse and health"; disks & locking are missing (that is something for later).

I think there's a section on discs in the 0.5.0 manual.

subject to interpretation or intelligent guessing to some degree.

Next version with the weirder mechanics moved into mutators, a new HUD and some tweaked visuals might already improve that aspect considerably.

[ghost]

a collection of terminology and design hooks like color-coding, icons, visual and sound effects.

I've already created all this.

Show me what you created, I don't see what you mean.

Sure some things need to be improved considerably, but I'm always working on it, just takes a lot of time.

I really know that it does take a buttload of time. I'm guessing you talk about particular thoughts that you put into action inside the game. What of those things mentioned (terminology sets, design hooks like color-coding, icons, visual and sound effects) do you refer to exactly?

I've written a basic manual for 0.5.0 and finally implementing a decent HUD is something I'm going to tackle now.

I see that the manual is still under work, but currently it looks more like an indexed reference book for everything without any means to highlight anything in a special way. It is more a general "manual" - which IS NOT what I defined.

@ HUD: are there any screenshots of those - or some kind of documentation that shows a connection to what I defined?

[fr1tz]

Show me what you created, I don't see what you mean.

What of those things mentioned (terminology sets, design hooks like color-coding, icons, visual and sound effects) do you refer to exactly?

Color coding:

• Obvious but: CATs, zones, flags, etc of the same team being the same color
• Damage buffer: White "shield" effect if you hit an enemy but only do buffer damage
• Health: Yellow "explosion" effect if you damage and enemy which then emits a number of yellow sparks that represent how much health the enemy hast lost.

Weapon visuals:
(these are not yet entirely consistent)

• The amount of debris that a projectile impacting the ground produces reflects how much impulse the projectile imparts.
• The decal a projectile leaves also indicates how much impulse the projectile applies (projectiles that impart very little impulse only manage to "crack" the ground's surface somewhat while high-impulse projectile create holes in the ground
• Should be intuitive from the explosion effect if the projectile does splash damage and how big the splash radius is.

Sound effects:

• Still recycled from rotc, do an acceptable job of communicating what something does

Icons:

• Not much there yet, a few crappy weapon icons (but it doesn't make much sense to put much effort into those until the weapon models are finalized).

@ HUD: are there any screenshots of those - or some kind of documentation that shows a connection to what I defined?

Nope, not yet. I should be able to get started on a "proper" HUD within a few days.

[ghost]

Color coding:

• Obvious but: CATs, zones, flags, etc of the same team being the same color

You're right. This is more to make sure we don't end up in total chaos, so we shouldn't praise ourselves over this.

• Damage buffer: White "shield" effect if you hit an enemy but only do buffer damage

This effect isn't that strong to begin with, it is barely visible during battle, and even harder to know whether you missed or there was no damage buffering happening. Apart from that - and more importantly - white is used in many separate places (e.g. both bars in the HUD). There is no color coding at work here. That use of white doesn't particularly help any concept.

Off topic: I claim that "damage buffer" is actually health; for the player it is almost completely undistinguishable from a "self healing" part of health and should not justify the extra concept and terminology around it. But I see that this has nothing to do with color coding.

• Health: Yellow "explosion" effect if you damage and enemy which then emits a number of yellow sparks that represent how much health the enemy hast lost.

Again there is nothing associated with that color. It has no meaning anywhere else in the game, this is just a rule that says "blood is yellow". It does not explain or connect to anything about general mechanics at all. That was is our goal though!

Weapon visuals:
(these are not yet entirely consistent)

• The amount of debris that a projectile impacting the ground produces reflects how much impulse the projectile imparts.

Using mere quantity of debris as indicator has a big flaw: it adds lots of clutter literally and is hard to read (also true for the indication of health loss via "blood spills").
But apart from that general flaw I see no connection to impulse - design wise. I'm thinking along the lines of "Impulse smacks stuff into bits" or "Impulse disintegrates matter" or... - whatever catchy phrase that could serve as context to make the phenomena plausible or easier to grasp! But lets assume the observant player notices the variation of amount of debris; it could be caused by weapon damage as well! Getting down to the right answer is far from self explaining. We aren't getting any closer to a general take on visualizing a concept via debris amount either.

• The decal a projectile leaves also indicates how much impulse the projectile applies (projectiles that impart very little impulse only manage to "crack" the ground's surface somewhat while high-impulse projectile create holes in the ground

I just learned that now. This suffers from the identical fundamental problems as mentioned above and does not get us closer either.

• Should be intuitive from the explosion effect if the projectile does splash damage and how big the splash radius is.

Reading the splash radius is a usability concern, and frankly I don't think we score that well even in this example. The explosion effect would benefit from cleaner borders and a three dimensional impression to be really informative. But usability in reading the splash radius is not helping to grasp a general concept - we are still no step further in that respect!

Sound effects:

• Still recycled from rotc, do an acceptable job of communicating what something does

You are missing my point. I'm vehemently trying to make clear that stuff needs to do more than just communicating what it does, it is about having dots to connect and about showing a system behind the individual aspects. It is not enough for a sound to just do its job and convey the concept of an explosion: "Does damage." - even if that is 100% correct. We need to work on creating systems like: "The deeper the humming of an explosion - the more impulse there is" - or "The more 'distorted' nature of a sound the more damage there is", ... or whatever!! I haven't wrapped my head around how sound fits to the rest. We need to assign properties of sound to elements in our general narrative. So even this example does not promote an underlying concept.

---

This is how I see where we are in the discussion now:
We agree on what needs to be addressed.
I propose a new system, you reject it because
you claim a system is in place, I refute it.

Given that there is nothing you could bring up (so far) - how can that be better than my approach?

[fr1tz]

Disclosure: I've had very little sleep the last few days and am very tired. So this post might not make as much sense as I think it does.

This effect isn't that strong to begin with, it is barely visible during battle, and even harder to know whether you missed or there was no damage buffering happening.

See 3d4ef05 and from my TODO:

• Use bleeds for damage visuals (keep white for buffer damage, keep yellow for health damage, try red for disc target aquired)
• Different sounds for damage buffer damage / health damage / disc target aquired sound notifications

white is used in many separate places (e.g. both bars in the HUD). There is no color coding at work here. That use of white doesn't particularly help any concept.

Context matters. In case of communicating whether an enemy is losing health or just damage buffer white is perfectly fine because its purpose is simply to differentiate between health and damage buffer, it doesn't need to be completely unique. Same goes for the HUD: Nobody is confused about what the stuff on UT's HUD means just because it all uses the same colors (with the exception of the small ammo bars, which I expect is because of its small size they went with a complementary color to help make it stand out).
I mentioned a couple of times that I'd like to go with a mainly monochromatic HUD, ultimately giving the player choice of its color (based on team, health, damage protection, etc or simply a custom color).

Off topic: I claim that "damage buffer" is actually health; for the player it is almost completely undistinguishable from a "self healing" part of health and should not justify the extra concept and terminology around it.

Except for the part where certain weapons by-pass the damage buffer and always affect health, which is why its justified as a separate concept. As far as terminology goes I've stated numerous times that since it behaves like the "shields" found in tons of games (Examples from the FPS genre: Tribes and Halo), it could easily be labeled as such, but people in IRC told me they preferred "damage buffer".

Again there is nothing associated with that color. It has no meaning anywhere else in the game, this is just a rule that says "blood is yellow".

Are you serious? "there is nothing associated with that color" and in the next sentence "blood is yellow". So yellow is associated with blood. And since when is nothing associated with blood? Usually people associate "danger", "harm" and "death" with blood. And because blood needs to stand out the color yellow is not used anywhere else in the game (while your "It has no meaning anywhere else in the game" implies that it is present elsewhere but has no meaning).

It does not explain or connect to anything about general mechanics at all.

You mean the general mechanic of "you shoot stuff (which makes it bleed) until it dies"? Yeah that one really needs an explanation, someone should make a series of videos explaining it or perhaps a 10 part in-game tutorial.

That was is our goal though!

That was is true false!

Using mere quantity of debris as indicator has a big flaw: it adds lots of clutter literally and is hard to read (also true for the indication of health loss via "blood spills").
But apart from that general flaw I see no connection to impulse - design wise. I'm thinking along the lines of "Impulse smacks stuff into bits" or "Impulse disintegrates matter" or... - whatever catchy phrase that could serve as context to make the phenomena plausible or easier to grasp! But lets assume the observant player notices the variation of amount of debris; it could be caused by weapon damage as well! Getting down to the right answer is far from self explaining. We aren't getting any closer to a general take on visualizing a concept via debris amount either.

Can you point to a game that exemplifies what you're talking about? A game is not a still picture, things move and make noise. If you can't guess the amount of knockpack a certain weapon's projectile imparts based on its visuals, you'll find out as soon as you hit someone with it or get hit.

And talking about "clutter": This is an art, not a science. Finding the right amount of cool-looking big explosions, bits and pieces flying around and camera effects to make gameplay exciting without making it confusing can't be done on a chalkboard. At least not in my experience.

I just learned that now. This suffers from the identical fundamental problems as mentioned above and does not get us closer either.

The fundamental problem of working in the same way as in the real world? How is that particular example not intuitive?

Reading the splash radius is a usability concern, and frankly I don't think we score that well even in this example. The explosion effect would benefit from cleaner borders and a three dimensional impression to be really informative.

In terms of communicating the splash damage radius I think the effects do a pretty decent job. I've experimented a bit with showing the exact borders but found that it obscures the exciting part while not actually being much more informative. Not against using it in a few cases (the grenade comes to mind), but applying it to all explosions makes things kinda dull and (paradoxically) more confusing (at least that's what I found).

It is not enough for a sound to just do its job and convey the concept of an explosion: "Does damage." - even if that is 100% correct. We need to work on creating systems like: "The deeper the humming of an explosion - the more impulse there is" - or "The more 'distorted' nature of a sound the more damage there is"

By "work" do you mean conceptually or implementation? Either way, I need to work on other stuff right now. And while this is certainly an interesting idea, it is also inappropriate for TOL because it's counter-productive in terms of communicating game status and boring in terms of kinaesthetics.

The second point is fairly obvious: Using just the two examples you've given would require every explosion sound to have humm and distortion, which also requires the sound to be long enough that you can actually hear those properties.
So with only those two properties you're already incredibly limited in terms of variety and you'll end up with a game where everything sounds the same, which is boring.

And for the first point: TOL already asks a lot of players by providing lots of nuances in its visuals. Processing nuances in sound is generally even harder and downright impossible in a fast-paced game like this. The idea of being able to tell an explosion's damage/impulse properties just by listening to it sounds good on paper but is completely unworkable in practice. In theory you're communicating more information, but in practice it's actually less because you're communicating impossible-to-recognize nuances of a universal rule rather than an easily recognizeable example of a specific rule (kinda similar to the splash damage radius borders example above):
"this explosion creates x amount of splash damage and y amounts of knockback"
vs
"this is the MGL proximity explosion, it creates 60 points of splash damage and zero knockback"

This is how I see where we are in the discussion now:
We agree on what needs to be addressed.
I propose a new system, you reject it because
you claim a system is in place, I refute it.
Given that there is nothing you could bring up (so far) - how can that be better than my approach?

I disagree with pretty much everything in that statement. But instead of writing why and how I disagree, I'm simply going to write something similar. So this is how I see where we are in the discussion now:

Nowhere. You make a bunch of vague suggestions that are supposed to amount to some kind of coherent system. I have no clue what you're talking about because you mostly talk about what the system is supposed to do rather than actually describing the system. You mention that the game needs a collection of terminology, color-coding, icons, visual and sound effects. Because what you mentioned is an essential part of a game, and TOL is a game, I mention those things are already part of TOL. You say you disagree, ask me to provide examples. I provide examples. You state your reasons why you don't think they qualify and call it a refutation. Then you go ahead and ask me a question based on the assumption that it's a fact to which I have to agree that you've sucessfully made your points and refuted mine.

We're going nowhere here and the tone of our non-discussion is getting increasingly condescending (this post included).
It's been ovious for a long time that our visions how TOL should look, sound (and even play) are quite different and maybe we've reached the point where it becomes obvious that they can't be merged into one game, even though I'd quite like to see your vision realized. It's just not going to be me who implements it, at least not now.

I'm not going to close this issue but I'm probably not going to post anymore in this thread.

[ghost]

Disclosure: I've had very little sleep the last few days and am very tired. So this post might not make as much sense as I think it does.

Let's not make it about something other than the search for what I defined earlier.
Please take your time to read and answer.
Only a well-rested, more constructive exchange of ideas makes sense.

[ghost]

I feel there is a misunderstanding here, so let my clarify; the reason why I don't consider white and yellow as "color coding" is: Color coding works when related parts in a system and especially a system with multiple relations share the same color. TOL has a complex structure of relations and needs color coding but lacks thereof. Blood being yellow assigns a color to a single element. That is not color coding. White could be regarded to be color coding but is used just too often without color code context.
Everything else mentioned in this lengthy issue either irrelevant, off-topic or something we agree on already.

I disagree with pretty much everything in that statement.

Please explain your disagreements with my statement.
I summarized to enable a more focused discourse of the topic!

[ghost]

It is really a pitty how you let this end up; one very sloppy, irrational, emotional and long (but obviously serious) post seems to be your way out of the debate, but also the means to let me know you're not really interested in my input any more.

Spare this to any other future contributor and clarify exactly what kind of influence you do expect and approve.