You could load the sector and just have the AI duke it out.
Of course, points could be used for certain things. It'd be pretty unnecessary to load the sector in the event of a tiny pirate wandering into your massive border patrol fleet. But for actual combat between two large, PLAYERMADE forces? That shouldn't be sim combat.
Yeah there are far too many variables that numbers and math alone will not be enough. Turret arcs, point defence vs missiles, placement of key systems behind armor...
keep in mind guys,there can potentially be 100+ simulations of trading,escorting missions,battles,etc.. in a universe,and as it ets older and more gets explored,the number can explode. Do you really want a fully loaded sector for battles with all those other things,because 99% of PCs would like..die hahaha,dont get me started on multiplayer servers.
But I do agree that the background simulations need to be more detailed. dont know what things will be included in these ship scores. but I do hope there is enough variables for those simulations to be somewhat fair. we cant expect it to be 100% right,I mean take the note from star citizen,you just cant simulate everything even if you had a super server cluster that would TRY to do that,now scale tthat down to starmade universe and low/mid end PCs,exactly...
You guys are right in talking about the problems unloaded ship fights would have, it is a big deal, and if it doesn't take into account the nuances you guys have mentioned, it will be a failure. But some of you have hinted on a possible solution. The whole point of having unloaded battles is to reduce strain on the server whilst still having large fleets, so we can't exactly just actually have the AI duke it out in real time every time they encounter each-other. But you can do something similar.
Instead of actually running a real time AI fight when fleets come into contact in unmanned, unloaded sectors, run the battle with less ticks. In real time you would experience a fight in 60 server ticks per second (or what ever the server tick rate/ or game tick rate maximum is), however in this system, the AIs would duke it out for real (and thus you would need to load the ships, but not necisarily anything else that couldn't contribute to the fight) but at a much lower tick rate, for example, a mere
one tick per second. This would allow you to capture the nuances of the shape and placement of weapons on the ship as well as other things, with out actually causing the server to take a huge it on computational performance.
The damage, movement, etc, of a ship would be a function of the tick rate, so that the lower the tick rate you set for unmanned sector battles, the more the damage and movement scales to compensate. In a situation where you still have a lot of ship battles but you don't want to lower the tick rate to compensate, you treat these battles as a
job, a term used in Real Time Systems to describe a task that needs to be scheduled to be worked on. This job in particular we would describe as having a soft deadline, as in, we don't need to precisely complete this job when its scheduled to complete, we would just prefer that it does. In our situation, given that we chose a 1 tick per second period for the job (our unmanned sector fleet battle) if the server was under high load from multiple of these battles, we would defer the computation of these battle "ticks" until the next available time we can schedule it. It won't matter much to the player since the player isn't in the sector in the first place, and they can't even see the battle transpiring. I personally see it acceptable that the battle takes twice as long or more than it would otherwise to get the best of both the performance and accuracy of who would win in a real combat scenario here.
There still is a problem with this system however. How do we deal with the increased memory cost of this system? While we completely solve the computational issue, we don't solve how much RAM this will cost the server, depending on the fleet scale (we want to make this scalable don't we?). We can solve these issues as well.
First, when simulating the outcome of fleet battles, we don't necisarily need to load every single object in the sector, even if it would have provided some minor tactical advantage (IE an asteroid) but we should still be factoring in all ships and stations in the area. This would reduce the server load by a bit, you don't need to calculate what happens when a stray missile hits an asteroid, but you will still need to calculate when a missile hits a ship. This is not enough though
The biggest thing we can do is reduce the amount of blocks representing our ship that we use to actually carry out the battle. If we approximate the shape and location of entities on a ship by taking every i'th block and have it represent the area of the ship of the size i x i x i at the same location, we can get pretty good approximations of both the ship and the outcome. What this means is that we take samples of the blocks we find on the ship and have those represent the blocks used in the battle
but we still keep the stats in mind when calculating the energy, fire power and shields of the ship, even if our unmanned battle approximations of those ships don't have exactly proportion of shield blocks, we can still get good approximations of what the battle would look like, at a factor cost i^3 of memory.
I provide a more concrete example of what I'm talking about and how it actually helps with memory constraints. Lets say you have a cube ship, and it is 256 x 256 x 256. If we chose our i to be 4, when your ship battled in unmanned space, it would be using (256/4) x (256/4) x (256/4) blocks to represent it, or 64 x 64 x 64 blocks. To put that in perspective of the amount of memory saved, 256 x 256 x 256 = 256^3, or 16777216 blocks. The amount of blocks used to represent the ship in unmanned space is 262144 which is 1.56% the number of blocks as the original. You could fit 64 of the same ship in this approximated representation in the same space it would take to hold the data in RAM for the 256 x 256 x 256 ship.
If this was some how not enough, you could go even smaller, using a factor of 8 you end up with 32 x 32 x 32 or 32^3 = 32768, which is .195% of the number of blocks used in the original. In this version you could hold
512 of these ships in the same space as the original. Raising the factor to such a number would make the memory requirement for battles near trivial.
This method doesn't give as accurate result of battles as a straight up real AI battle would do, that is true, but it gives a good enough approximation based on the ship dimensions and placements that I'd argue it doesn't matter. It does however hurt small ships.
If your ship was even 15x15x15, this system might approximate your ship to be one block in the approximate battle space given an i value of 8. On super large ships this is totally a non issue, your ship is so large that such approximations will probably not even end up factoring into 1% of your ships represented volume, however it might harm very small ships. Given appropriate factor sizes, like i = 4, this ends up being a non issue for real fleet battles, as most ships in battle will over this size, but sometimes a larger factor scale size might be necessary for memory reasons and it is a valid concern to bring up.
I think that even in the factor size i = 8 case this doesn't matter because at such a scale your ship isn't going to have a lot of problems in terms of strategic placement of blocks being properly represented in your ship, and it ends up being no worse than the stat sim battle where no ship morphology is present.
An minor possible problem with the reduced fidelity approximation of the ship is the computational time required to create the representation of the ship. The actual time to do this is probably going to be minuscule, but in case this one time per battle performance hit is a problem, ships can start including this data in their ship schematic data, after a set time when you exit the build mode of the ship, or when you save it manually, it will also calculate this approximated ship representation, and store it along with the original ship data. in this way, the server need only retrieve this data when a battle occurs, rather than calculate it on the fly.
A final suggestion on reducing performance impact, but still trying to keep ship morphology fairness in unmanned sector fleet battles fair, would be to limit ship collisions (not weapon hit collisions necisarily) to single, or a fixed number of boxes fitted within the bounds of the ship. This would reduce collision checking needed, if every ship represented its collision area as a simple box, or three boxes during the unmanned fleet battle. Additionally it may be more beneficial to forgo object collisions altogether in the approximations, but this might end up causing behavior where ships can pile up giving an unrealistic advantage to missiles and area affect weapons.
To sum up the solution to this issue, you do need some actual ship to ship battle to solve this problem, but it doesn't necisarily have to be one to one or done on the server in real time. Unmanned sector battles don't need to take place on real server tick time, and can be calculated with a time fidelity of one time per second for example, saving server resources but still providing much better representations of the outcomes of real ship battles. The space for where these battles take place don't need to take into account the static/ non ship or station objects in the area with respect to ship collision or bullet collision, and ship collision can afford to lose a lot of accuracy with fewer boxes to check, or removed entirely. Finally to solve the problem the Ram needed by the server in the situations where many large ships are fighting in a fleet, the physical representation of the ship during the battle can be approximated by taking a sample of the real ship every ith blocks, where if i = 4, a 256 x 256 x 256 ship would be represented by a 64x64x64 ship in the unmanned fleet sector, which would only take up about 1.6% of memory needed to store the block information.
