Bombardment Ideas

For updates and discussion of Terra Invicta, a grand-strategy alien invasion simulator
Post Reply
Nentrinax
Posts: 5
Joined: Thu Oct 20, 2022 12:47 am

Bombardment Ideas

Post by Nentrinax »

I have been following the back and forth on bombardment and the updates via patches and discussions.

From what I have read (and experienced some of):
First counter-fire was backed up in a queue, resulting that single ships did outsized damage before being destroyed.
In the validation patches (0.4x) this was attempted to be solved via numerically increasing the strength of the base/defense platforms.
Now bases are functional death stars with tens of thousands of combat rating, requiring large fleets to even scratch.

I am going to put forth some more radical ideas, given my suspicion that simply balancing numbers will not come out right.

First idea would be that when a bombardment starts, run it in a separate Thread, actually performing the computations for the battle (attack, counter-fire, point-defense, etc), much as if the AI fleet fought an AI orbital hab, but without the "quick resolve" that tries to compare two number sums.

By using a thread, multiple bombardments could be occurring simultaneously (against different targets), and still allow the UI to be responsive in the main thread. (Instead of trying to put it in the main thread's computation queues/cycles).

During this time the fleet and the base would locked (not producing resources, since you wouldn't anyways, not able to build/change hab module states).

Some considerations would be the thread would need some interrupt catch if a fleet intercepts the bombardment and interrupts it, or the player wishes to cancel a bombardment they have started, or the player pauses the game (possibly to send an intercept).

The thread would then update bases/ships to the state at that point. It may be resumable if the player simply un-pauses without affecting the bombardment.

If the thread cannot keep pace with the current game speed, it may require forcing the game speed lower until the bombardment has been finished.

I recognize threads are more complicated to avoid multiple from acting on objects, and would necessitate locks on them (and saving the game may not be possible during that time).

So the second idea would be to pause the whole game and deal with the bombardment like a space combat is dealt with (the rest of the game goes on hold). In this a popup dialog could be displayed showing the bombardment progress (things destroyed, etc), while it calculates the actual combat (instead of summing numbers).

This dialog may have a pause button to allow the player to send an intercept (or break off their attack if they are the one bombarding), and would also need am interrupt if an intercepting fleet should reach it during the process.

During the bombardment, resources are not produced, and all other popups/events wait for it to be complete (this would also essentially serialize bombardments with other events and each other).

The downside of this approach is that I don't know how it would deal with bombarding things on Earth (like invading alien armies), which can take up to two weeks. In my experience those are much different, compared to a space/hab bombardment that is over (win or lose) within a few hours.

The long and the short of both these ideas is that I don't believe it is possible to reduce the bombardment to a mathematical value (or apparently a queue), since as others have noticed, the Auto-Resolve of the ship battle results in vastly different outcomes that simply starting the battle and letting the ships auto-fight.

I believe the bombardment will/currently suffers from the same effect, which makes it very difficult to balance what should happen versus what does. I believe the only in-the-end practical solution is to actually "fight it out" in actions.

Thank you for your time.
All suggestions included, it is a very enjoyable game.
Post Reply