Shield facets design

[stephengtuggy]

So I'm thinking that we need to reconsider our design for shield facets. When we reduced the number of shield facets from 8 to 4, we broke a bunch of code all over the place. And for what? To make the Vega Strike engine less capable. That doesn't sit well with me. I find myself again questioning why we made that choice.

I don't think the shield facets should be stored in a fixed-length array. Instead, they should be stored in RAM in an std::map<std::string, float>. And stored in JSON, on disk, as child keys (e.g., "front", "back", "left", "right") under a single parent key ("shield_facets"). And I think we should go back to allowing at least 8.

We should then change all the places in the code that reference shield facets to use these new data structures. No more fixed-length arrays, and no more hard-coded facet names. Instead, we will enumerate through the items (key-value pairs) in the map.

What do you guys think?

[stephengtuggy]

Roy:

Well, as the person who made the original choice and refactored the code several times, I’m somewhat biased.
I am aware that the code has several bugs. I have a PR in the works that fixes those bugs as well.
I’ve been waiting for the CMake work to be done, as well as the OS changes.
As for your suggestion, you’d still come up against the code to select the facet based on the vector - that would be hard to store easily in a way that would translate to code.
Finally, the hud code isn’t flexible. You can’t just add 9 facets or six and not make changes to vdu.cpp.
Let’s move this to a discussion.

[stephengtuggy]

Not a vector. A map. And we store the number of facets separately, alongside the map, as we already do today. And then have a switch statement wherever we need one, that can handle two, four, perhaps six, or eight facets and figure out the behavior automatically based on the number of facets and what's in the map.

[royfalk]

You mean like:

int DamageableLayer::GetFacetIndex(const CoreVector &attack_vector) const {
    if (number_of_facets == 0) {
        return -1;
    }

    // Convenience Variables
    double i = attack_vector.i;
    // double j = attack_vector.j; not used
    double k = attack_vector.k;
    double a = i + k;
    double b = i - k;

    switch (number_of_facets) {
    case(1):
        return 0;
    case(2):
        if (k >= 0) {
            return 0;
        } else {
            return 1;
        }
    case(4):
        if (a >= 0 && b >= 0) {
            return 0;
        }

        if (a >= 0 && b < 0) {
            return 2;
        }

        if (a < 0 && b >= 0) {
            return 3;
        }

        if (a < 0 && b < 0) {
            return 1;
        }
    default:
        return 0;
    }
}

[stephengtuggy]

Yeah, something like that, I suppose.

[stephengtuggy]

Agreed -- we will need to make changes to vdu.cpp. And we won't allow an arbitrary number of facets, Just three or four possibilities -- 2, 4, 8, or perhaps 6 for a cube shape. (But probably not that last one.)

[royfalk]

Unfortunately, that's not how the engine currently works. The VDU part of things supports armor8 and shield4. This is a GUI issue. At the end, you are drawing the shield and armor on a cockpit. I'm not changing that at all. I'm hacking it so every two armor gauges move as one. Shield2 and potentially armor2 are a subset of shield4 and armor4. The unit part of the code will report Left/Right facets as 0. That's actually what it's doing now for shield2.

[stephengtuggy]

I see. Makes sense.

[stephengtuggy]

I am glad that we took a closer look at this aspect of the code. The shield stuff did need to change. It was too brittle, among other problems.

[stephengtuggy]

I created a draft PR: #1003 . Only the last commit is relevant to this discussion.

[royfalk]

OK, so I took a look at the PR. First, you are only talking about shields and about reading them. Removing support for 8 facets was primarily about armor and not shield.

I am something of an amateur archeologist. Based on my diggings, I think it's safe to say the game started with support for 4 facets only and they added armor and some shield support for 8 facets. That's why images.h has:

enum GAUGES {
        //Image-based gauges
        ARMORF,
        ARMORB,
        ARMORR,
        ARMORL,
        ARMOR4,
        ARMOR5,
        ARMOR6,
        ARMOR7,
        FUEL,
        SHIELDF,
        SHIELDR,
        SHIELDL,
        SHIELDB,
        SHIELD4,
        SHIELD5,
        SHIELD6,
        SHIELD7,

[stephengtuggy]

something of an amateur archeologist -- LOL!

Looks like you're correct here.

[royfalk]

So I'm thinking that we need to reconsider our design for shield facets. When we reduced the number of shield facets from 8 to 4, we broke a bunch of code all over the place. And for what? To make the Vega Strike engine less capable. That doesn't sit well with me. I find myself again questioning why we made that choice.

Well, for shield "I am glad that we took a closer look at this aspect of the code. The shield stuff did need to change. It was too brittle, among other problems." which I also said, since I had to slog through the code when I refactored it.

For armor, my argument was marginal utility against playability. 8 facets sound cool but they implemented it wrong (IMO). The implemented a two layered diamond. The current VDU can't show that. Instead it can show this form:
..a..b..
c.......e
d...... f
..g..h..
What does b stand for? Top-front-right? Bottom-front-right? Who knows? It's just bad design from the start and fixing the GUI side of things requires willing to draw new cockpits. Not impossible but certainly not the highest priority.

But the most important argument was - it's marginal utility. Yes, we can write 8 facet armor. We can implement 32 facets. Should we?! Will that make the engine really better?

I don't think the shield facets should be stored in a fixed-length array. Instead, they should be stored in RAM in an std::map<std::string, float>.

Agreed. Damageable_layer.h:

int number_of_facets;    // How many facets. e.g. dual shield (front and rear).
std::vector<Resource<double>> facets;    // The facets container

The version you have is probably

unsigned int number_of_facets;    // How many facets. e.g. dual shield (front and back).
std::vector<Health> facets;    // The facets container

And stored in JSON, on disk, as child keys (e.g., "front", "back", "left", "right") under a single parent key ("shield_facets"). And I think we should go back to allowing at least 8.

Again, strongly agree. Take a look at #877. I was waiting for the upgrade to boost::json to also start implementing this.
Though I would point out that instead of storing units in memory as
static std::map<std::string, std::map<std::string, std::string>> units;
we can now store them as
static std::map<std::string, boost::json::object>> units;

Then shield would be:

shield: {
   facets: 2,
   front: 50,
   back: 30,
   regen: 5
}

You would pass this sub-object to the shield component, cleaning up the code even more.
However, this is again marginal utility. This part of the code is not bad and polishing it to perfection comes at the cost of something else.

We should then change all the places in the code that reference shield facets to use these new data structures. No more fixed-length arrays, and no more hard-coded facet names. Instead, we will enumerate through the items (key-value pairs) in the map.

I'm working on that.

[stephengtuggy]

OK, sounds good.

[evertvorster]

Hi there.
On the shields discussion, it would appear to me that only small ships are being discussed.

Ships like a Mule, Clydesdale or even my lovely Goddard has shields that do not extend all around in a bubble like with the smaller ships. Instead, it is shaped to the contours of the ship. There are even bigger ships out there, and Vega Strike supports any size of ship, so in theory there could be a Death Star replica...

Now, while designing shields and armor and things, it might just be a good idea to have an arbitrary large number of armor plate and shields.

The reason that I am saying this is that this would allow us to map shields in a sort of honeycomb on these large capital ships... We could also then display a 3D view of the ship, with the shield or armor that is taking damage being highlighted and fading... or glowing in the case of armor. Yes, this will be a lot of work to implement, but it will be a lot easier if it is already possible to have an arbitrary number of armor and shields.

When re-doing the shield and armor displays on the hud, it would also be a good idea to keep in mind that these arbitrarily large ships exit, and would also need their armor and shields displayed. Which is why I was thinking of moving away from a diagram of the ship, and rather have a wireframe of the ship displayed and the shields extending out from that in some sort of mathematical model. This would look super cool on small ships, and scale nicely to larger ones.

Just something to keep in mind.

[royfalk]

Ships like a Mule, Clydesdale or even my lovely Goddard has shields that do not extend all around in a bubble like with the smaller ships.

There's a setting for that. Probably "Shield_Mesh": "clydesdale-shield.bfxm"

Now, while designing shields and armor and things, it might just be a good idea to have an arbitrary large number of armor plate and shields. The reason that I am saying this is that this would allow us to map shields in a sort of honeycomb on these large capital ships

That is possible by splitting a ship into multiple sub-components. These are typically turrets but don't have to be. This is supported now, but it requires work on the assets to make it work well for a ship.

We could also then display a 3D view of the ship, with the shield or armor that is taking damage being highlighted and fading... or glowing in the case of armor. Yes, this will be a lot of work to implement, but it will be a lot easier if it is already possible to have an arbitrary number of armor and shields.

So I was totally against this because I thought this is extremely hard to do and a lot of work. I still don't think it's easy or a good idea (I'll get to that), but it's not that hard. The game already displays a 3d representation of the ship. Stripping the texture from the mesh shouldn't be too hard and mapping the hit to the appropriate area is also feasible. Again, not something I'd like to do ever, but possible.
The real issue for me is it's cool but bad UI principle. Cars have dials for a reason. People glance at the fuel or speed gauge and can immediately understand it. That's why digital speed gauges are so unpopular and bad ( https://ux.stackexchange.com/a/74704).
A glance at the current vdu tells me how my shields and armor are doing and should I attack, keep my distance for a while to regenerate shields or run away. I want to keep the UI of the ships functional.

[evertvorster]

Hmm, you do touch on a good point there.

Having numbers as a read-out of information is hard for the human brain to process, because it takes several steps to turn it into information that your brain can use. First, it has to do pattern recognition, then map the pattern on to a number, and if there are multiple digits, turn that into a number, then it has to compare that number to a memory of a high number or low number, and finally decide if it is dangerously close to one of those extremes.
This takes a long time with our slow brains, and when you are in a situation where you rely on your reflexes, this is not a good thing.

The linked article hints towards that.

If you have just one variable to display, a dial is great.
However, as the number of variables you display increases, dials become bewildering, and again you end up mapping which read-out maps to which variable, slowing you down. This leads to the same situation as with numbers.

What I am suggesting is something the human brain is incredibly good and fast at, pattern recognition.
If you have a model of the ship displayed, with the part that is taking damage oriented to you, and some other default orientation of the model for when there is no damage, then just the movement of the model re-orienting to show you damage in progress is already enough to draw your eye to that part of the GUI.

Color and/or intensity conveys information in very much the same way as a bar graph does, but you can squeeze more information into the same space.

So, if you have the shields say a nice strong blue color, and as the shield depletes it becomes a lighter blue and more transparent, you know at a glance that your shield is being depleted.

Armor could start as that part of the model as white, and then going through yellow, orange and brown to finally dark grey and your ship explodes.

And yes, it would look cool. :)

Unfortunately, as you state this is a lot of work. But, bringing this up early does make it stay in the back of your head, influencing decisions you make now about how to implement various parts of shields and armor to ensure you don't have to touch the same code again in the future. :)

[evertvorster]

Oh, and if you are wondering if there is a formula for carving up a sphere into an arbitrary number of equally sized segments:
https://academic.oup.com/jcde/article/9/2/826/6573579

Far beyond the scope of this discussion, though. I suppose the most practical way would be to imagine each shield generator's shield extends around it in a sort of bubble. So, in a dual shield, the forward shield is a bubble around the front of the ship, and the back shield is a bubble around the back of the ship, and if the radius of these bubbles are big enough, they would start intersecting. So, any shield inside an intersection just does not count.

So, now if we want a quad generator, have four shield generator points, each "projecting" it's own bubble. Again the bubbles would intersect, and anything inside an intersection does not count.

So, to then take a capship that might have 30 shield generators, each projecting its own bubble of shield, you would get a form-fitting almost honeycomb shape of shields around the ship.

With this sort of model you could do collision detection on the shied spheres?

But this is all pie in the sky thinking, something to do when all the bugs have been sorted out and you guys are looking for new features to add. :)