FreeOrion

I thought I give it a try and extend the shield regen implementation to work this way: 1/turn when actively involved in batte, otherwise full regen. As there isn't something for ships like LastTurnAttackedByShip for planets, I had to implement that first: I added m_last_turn_active_in_combat with the respective name accessor and mutator to the ship class, made the required additions to the constructors, Ship::Copy and the serialization code. That of course broke safegame compatibility, I hope that's not too much of an issue. Then I made the required modifications to Ship::NextTurnCurrentMeterValue and successfully run a test game. Worked like it should

I've attached the patch file. As I'm not quite sure if that's already necessary for a small contribution like that, I decided to be on the safe side and give the licence statement:

I release all my contributions (past, present and future) to the FreeOrion project under the Creative Commons Attribution-ShareAlike 3.0 and GNU GPL 2.0 licenses. Does that cover everything, or do I have to phrase that differently (I don't want to have to repeat that every time I make a contribution... )?

I committed a modified version of this with full recovery on turns without battles, and no recovery on turns with battles. It also used the boost serialization version functionality to (hopefully) maintain backwards compatibility of save files.

I also used the INVALID_GAME_TURN constant, which has a large negative value, instead of -1. The Planet constructors should probably be similarly changed.

This was how I originally intended to do it too, but then I realized that this would result in ships blockading a system not recovering their shields, although there isn't really any battle going on. However, as long as there are enemy planets in the system (as it's the case when blockading), combat is triggered, your ships attack the enemy planets and last_turn_active_in_combat get's updated. That's why I went with a regen rate of 1/turn while in combat, and full regen when not in combat. This way ships laying siege to a system can still slowly recover their shields.

So as long as it isn't specifically desired to have ships not regenerating shields at all in combat, even when they just blockade enemy planets, I'd suggest to have a regen of 1/turn for ships involved in combat - what do you think?


I already suspected that this could be done somehow (the "version" parameter hints very strongly at that), but couldn't figure out how to do it... Anyway, your modification seem to work, I've been able to load a savegame created prior to the introduction of m_last_turn_active_in_combat now, which I wasn't able to do before

Naively, I don't see why ships blockading should be recovering shields. If they don't, it gives the empire being blockaded the opportunity to wear down the blockader with multiple attacks. I'm actually inclined to make ship shield regen slower than full when out of battle, so a one-turn break in attacks isn't a huge setback due to instant regen it allows.

One issue might be the need for players to move ships in and out of a system to give them a turn of rest to regen, which would be annoying micromanagement.
A bit of googling quickly points to the tutorials for boost serialization.

Well, I think that depends on how the blockade is done. If the blockading player decides to actively attack/bombard the planets every turn, then I'm with you, that counts as actively being in combat and therefore shield regeneration should be treated accordingly. If however the blockading player decides to sit back and just lets his forces passively blockade the system (that is, his ships don't attack the enemy planets), then the ships aren't really actively involved in combat. Consequently shield regeneration should be handled accordingly too in this case.

As the current implementation of the combat system does not provide the possibility for different blockading strategies, this can't be done now. That's why I thought the 1/turn regen in combat and full regen out of combat solution would be the best for now. As that's not really a big issue, I've no problem sticking with only full regen out of combat of course


I totally agree with you here - but the way you describe this scenario, the defender is required to actually launch multiple attacks in order to wear the blockader down. If he does, he keeps the ships of the blockader "busy in battle", thus wearing them down by not allowing them to regenerate their shields. But he has to make use of this opportunity (and obviously also have the means to do so), otherwise there is no "wearing down" and the blockader's ships should be able to regenerate their shields.

The way it's now this isn't an "opportunity", as it happens automatically anyway, regardless of what the defender does. That's of course acceptable for the temporary implementation of the combat system we have now, but do you think that it should be that way even in the final implementation?


That actually boils down to the question of how to balance shields so they don't become too powerful. One way would be as you described: limiting the regen rate. The other one would be to make shield techs / shield ship parts sufficiently expensive. Or, if you want to look at it form another side, limiting max shield strength. You're obiously more inclined toward the first solution, personally I'd prefer the latter ones. But I think that's more a matter of taste, as I can see both systems work if well designed and properly balanced.


That's something I haven't considered, but that's actually a good point. On the other hand, if going with the solution to require the defender to continually launch some kind of attacks on the blockading forces you're stuck with the same annoying problem, just for the other side... but we are getting off topic here I think, should we move this discussion into brainstorming?


Yeah, you're right. Old habits die hard, I'm still often tempted to just trying to find out how things work by (like in this case) looking at source code or going by trial and error. "If everything else fails, try reading the manual" is a wise counsel I need to constantly be reminded of...