8 facet armor and shield - remove support

[royfalk]

The game has support for 8 facet armor and shield. Of the two, armor is fully implemented and used.
It was implemented as a diamond in two rows - top and bottom.
(a more sane approach would be as a square with two rows).

This has some major playability issue - displaying damage in the cockpit in 2d is problematic. The game displays values in the following form:
a b
x x
x x
x x
No one really knows, what each value represents. I know a is front left but not if it is top or bottom. During battle, I can't move my ship to protect the damaged armor.

Also, ship view shows all eight facets. As someone who is rewriting and testing this, I can't make heads or tails of it.

From a game development PoV, this has been a complete headache. Shields are 4 facets but are saved in 8 facet formats. So top-front-left is front and bottom-front-left is left.
Honestly, I just made this up. During actual work on this, I checked against the old code to make sure there are no mistakes.

I suggest we drop this support. I've been working on a PR for an hour to see if this is doable.

[evertvorster]

The most sane shield layout is most probably six facets: front, back, left (port) right(starboard), top and bottom.
Easy to wrap your head around, granular enough to make you turn your ship to a protected side, and should not be too difficult to display, with only top and bottom being tricky to show in a 2D hud.

How much tinkering in the game code this would take is anyone's guess, and then it still needs to be displayed on the GUI in a reasonable manner.

Some bases have only two shields, so there is some variation here too.

[BenjamenMeyer]

6 facets as you mentioned is probably correct:

• front
• back
• left (port)
• right (starboard)
• top
• bottom

This should describe a single defense layer.

[BenjamenMeyer]

actually, thinking this through more there needs to be one more facet - center; this would enable some ship to put life support at the center, or engines/reactors or something else there based on what the designer wanted to protect.

[royfalk]

This is supported in theory. When designing lib_damage, I took such scenarios into account. Any damage that hits the ship, goes through layers. First layer is shield (with 2 or 4 facets). Second is armor (8 down to 4 facets) and finally hull (1 facet).

Right now, this is hard coded. However, I think it can be made configurable. The real trick that this interacts with lib_component. You'd need to make the various layers generic and configurable (not a bad idea).

Honestly, if someone wants to spend time on this, I'm happy to assist. However, my main priorities are:

1. Get the game out the door. That's a big one, given that we don't actually have a campaign.
2. Update the 3d graphics to near modern level and utilize the GPU. No idea how to do that.

[evertvorster]

For point 1, if we manage to fix all the obvious bugs that would be a huge step in the right direction. The game has to be enjoyable to play first and foremost. Once that is achieved, then I strongly believe that someone with the necessary skills will help out expanding the storyline.

For point 2, this is a huge undertaking.
The ship models seem mostly fine, bases could use a little sprucing up, but are not terrible.
The worst parts of the game seems to be planets and the background. The higher resolutions available on computers these days do have a huge influence. While it was acceptable to have bitmaps way back when, they get logarithmically larger with higher resolutions, and are unsustainable in the long run.
The logical solution would be to procedurally generate both the backgrounds and planets. This would make for a much smaller Assets, too.

On the subject of procedural generation, I particularly enjoy watching the videos of Sebastian Leauge on Youtube. A good starting point is this one: https://www.youtube.com/watch?v=lctXaT9pxA0&t=1152s
He is pleasant to listen to, and shows code snippets as he goes along. I am not sure if he uses a game engine, he does not say.

[BenjamenMeyer]

So I'm guessing you're counting 8 facets by covering 2 layers of defenses: shields (4 assets, out most layer), armor (4 assets, inner most layer). If that's the case then we probably need to revisit this and create a layer structure.

Layers should probably be:

• [0] ship itself
• [1] armor
• [2] shields

For the ship itself, we probably should have some things defined like:

• where reactors are
• where the shield generator is
• where the jump drive is
• where cargo is
• passengers quarters (life support)

Some ships may want to have these placed in different places, yielding different termination profiles.

For example, assume the rear shields were breached and then the rear armor was destroyed; the ship would then be hit directly. The engines and reactors would likely take heavy damage for most ships at this point. OTOH, another ship may place the jump drive on the left and cargo on the right, and passengers in front - in that case, if the front shields were breached, the front armor was destroyed, then as the ship was destroyed life support would fail and if completely destroyed the ship might not self-destruct but the player would die nonetheless.

[royfalk]

So I'm guessing you're counting 8 facets by covering 2 layers of defenses: shields (4 assets, out most layer), armor (4 assets, inner most layer).

Nope. Armor has front/back, left/right and top/bottom. That's why when your armor is hit from all sides, it creates a sort of jagged look as top and bottom record different hits. Given that the engine has diamond shaped armor and displays it in a square, even I can't tell you what each of the eight levels in the hud translates to in the engine. I'd have to check the code.

Layers should probably be:
[0] ship itself
[1] armor
[2] shields

Yep.

For the ship itself, we probably should have some things defined like:

We could but won't. It's hard coded and low priority. That's two man months for something that's really marginal. I want the next release or the one following to show a jump in actual resolution.

[evertvorster]

I was just talking about shields.

If we are talking about changing how shields work, how the shield projects and if it projects a shield at all should be down to the type of shield installed on the ship.

The very cheapest and simple shield can just be a single shield, projecting in all directions, but a hit anywhere diminishes the entire shield. Displaying this shield in the HUD can be very simple, just have a ring around the ship where the thickness depicts the charge status of the shield.

A Dual shield should project in two directions independently, fore and aft. A hit on the fore shield diminishes the fore shield without affecting the aft shield, and vice versa.

Quad shields do fore, aft, port and starboard in a similar fashion.

All of these layouts are quite easy to represent on a 2d display in the hud. If we decide to have more complicated shields that also have top and bottom facets, this becomes a little more tricky to display on a 2D hud.

Once a shield is depleted, then the armor starts taking damage. How the armor is laid out should be a function of the ship model if we want to be intricate about it. Or, we can just assume that all armor have similar orientations. Similar to the quad layout here?

In any case, this is a balance between complexity and accuracy. For one thing, a capital ship should in reality have very many shield projectors, each covering a patch on the ship all around. However displaying that on the HUD and implementing it in game code might be a daunting task.

One way out of this quandary is to have a 3D display of your ship and shields in the HUD. Computer hardware is now powerful enough to be able to draw your ship in the HUD display, and draw shield projections over it. It would be really nice to have it rotate so that the segment with the heaviest damage is oriented towards the player.
This approach would free us from the constraints of a 2D hud, and make the game engine more flexible at the same time.
If we go that way, we could essentially have these captial ship shield layouts that could honeycomb over the whole thing, just like I imagine it would have been if we were able to build ships like these in real life.

[royfalk]

See below.

[royfalk]

Bringing this discussion back to where it started - The game has support for 8 facet armor and shield. Of the two, armor is fully implemented and used. I want to remove the support in the quickest way possible without breaking something that can't be fixed in the assets.

I want to do this for two reasons:

1. Game - it's really impossible to improve 8 facets without touching cockpit graphics and perhaps teaching the players about it.
2. Engine - it's hard to parse this. Loading units, saving units. Send a float[8] with 4 facets. What does array index 2 holds? Left, right, front?

I don't want more ideas for development. (I actually do but not here) I want permission to remove a major piece of the engine that would simplify it.

[evertvorster]

It seems to be a good idea to simplify things.

If you were to drop this support for 8 facets of shields and armor, what do you propose to replace it with?

[royfalk]

For shields, nothing. There aren't actual 8 facet shields in either VS or WC.
For armor, 4 facet armor.

[evertvorster]

OK, if I read this right, shield facets should just be a function of the shield generator installed in the ship, and not saved in the save file?

Since the shields regenerate anyways, this does make sense.

For armor, four facets seem to make sense, especially if it is extensible.
Since saved files are being moved to json, it should be possible to label the facets properly, ie: front, aft, port and starboard.

[royfalk]

OK, if I read this right, shield facets should just be a function of the shield generator installed in the ship, and not saved in the save file?

No. Both armor and shield record damage. Armor records simple damage - you hit it, it gets damaged.

Shield record two types - damage to the shield and damage to the generator. We record damage to the generator.
Example, you start with some shield:

"shield_x": {
   "facets": 4,
   "front": "30/50",
   "front": "47/50",
   "front": "13/50",
   "front": "28/50",
   "recharge": "5/8"
}

We see that the shield generator itself is damaged. This is reflected in temporary maximum shield strengths that are lower than the max (50). Same for recharge.

Part of what I've been working on was something called the Resource class. This is a game value that has a minimum value, maximum value, damaged maximum value and current value. The class won't let you go above damaged max value or below min value. You can raise/lower max damage value through damage and repair classes.

In most cases, lib_component relies heavily on Resource to record damage to certain attributes. It's more complicated, but it's written once and is pretty opaque.

[BenjamenMeyer]

@royfalk if we can simplify things to help things move forward I'm all for it. We can build up a record of ideas for what to bring back and how to improve it when the time is right. Simplifying things is usually the right call.

[royfalk]

With management's approval, I'm closing this discussion.