Dev Blog : February 17th 2016

    Joined
    Sep 10, 2014
    Messages
    226
    Reaction score
    398
    • Supporter
    • Master Builder Bronze
    • Competition Winner - Small Fleets
    I´m so happy to finally read this. This is exactly what i wanted and it will be epic.

    Now to the topic of combat simulation:

    Of course the simulation won´t work perfectly. Of course people can exploit the simulation if they know how to do it. But do you guys think that an AI fight will be so much better? Will the AI turn on your docked reactors? Will the AI use the max potential of the ship? I don´t know about this and as long as the AI is like the current one i bet the simulation combat will be better than the actual AI combat.

    A lot of you also underestimate the power of math. There can be a lot of stats taken into account as well as the blueprint data of the ships. A good simulation can detect docked reactors and if enough power is available to use the full potential of the ship. How fast the ship can go to add a simulated dodge chance or to make it impossible for some weapons to hit at all. The number of PD turrets, etc. If someone plays a lot diablo 3 you can easily tell how unimportant the shown offensive and defensive stats really are if they aren´t used to actually calculate the simulation. Getting a simulation like this right isn´t easy and will probably be bad at the beginning. But since it´s just some kind of math going on in the background it can easily be tweaked until it´s good enough.

    Suggestion for the simulation:

    I would like the simulation to take some kind of countdown time until it starts and that the players involved gets a notification. This enables players to join the fight if they are nearby or send additional ships.

    It would also be neat to get some kind of communication system for ships to enable them to send the notification. Of course enemy ships should have a way to jam the communication and delay the combat notification which can easily win a battle.

    Overall i´m really excited for this update.

    Edit: Thx Megacrafter to give an example how extensive a simulation could be. I know why i voted for you in the council election. :D
     
    Last edited:

    Ithirahad

    Arana'Aethi
    Joined
    Nov 14, 2013
    Messages
    4,150
    Reaction score
    1,330
    • Purchased!
    • Top Forum Contributor
    • Legacy Citizen 8
    What many don't seem to consider, is that fleet battles currently are also just purely numerical[if one excludes player pilots' piloting].
    However, unloaded battles do not need to be fully nuanced, as player pilots can be excluded. Let me elaborate.
    When 2 fleets engage, in the very first moments they have a certain distance from another, let's initialize this variable with the distance of 2 opposite sector borders. The distances of individual ships from one-another depend on formation. If formation won't be implemented, assume it to be the same for all ships in the beginning.
    In the beginning of a battle one can also assume, that energy capacitors and shield-capacitors are full.
    Both fleets also have a maximum movement velocity, which can be determined from the maximum movement velocity of each ship. Directional thrust should be ignored here, for simplicity. This velocity will be important later.
    For weapons with a cooldown of less than a second, average out damage and energy consumption into 2 second batches[include how many shots would be fired per batch as a constant floating point].
    Any other weapon with a cooldown of less than 2 seconds, put 2 shots together in a batch like above.

    Now, follow these rules:
    • Calculate when each ship will come into the reach of which weapon system of an enemy ship, and queue fire-events up based on how long it would take to come into range, and wait until the first event in the queue takes place. This uses the movement velocities of the fleets(and if applicable formation)
    • On any timed event: Calculate the amount of power and shields each ship would have regenerated in the time between this event and the last event. Also, allow each ship to change its orientation and course freely. Note how long it would take for every ship to exit their enemy's range on their current course(every course is assumed to be a straight line). If no event occurs between this event and that time, the battle will end after this event.
    • On a fire-event: The ship this event applies to fires its weapon(s) at an enemy ship in range of the AI's choice, provided the ship has enough power. If the ship lacks the power to fire the weapon, queue up another fire-event for this weapon/batch when the ship would have regenerated enough power, assuming constant regeneration.

      Calculate the likelyhood of a hit depending on AI-accuracy, the dimensions, block-count and distance of the enemy ship. If the weapon in question is fired in batches use the floating point to spread the RNG out over the shots in the batch, and calculate the total damage done by all shots in this batch combined, and queue up a hit event on the targeted enemy ship. The hit event will occur in the time it takes the projectiles to travel the distance.[0 in case of hitscan] Do not queue up a hit-event if the shot(/all shots in the batch) miss.

      Also queue up another fire-event when the cooldown of this weapon(or this batch) would have passed.
    • On a hit-event: Deal the damage noted in the event to the ship this event applies to. If the shields do not completely soak up the damage, estimate which block would have been hit by randomly selecting a side of the bounding-box[depending on the position of this ship relative to the firing ship], and randomly selecting a block facing this side. If the chosen column of blocks is fully empty, repeat with all other columns. If all columns are empty, remove this ship from the calculations , it has to be dead. Do not process the block damage that would be done by the hit, just note down the blocks, damage, type and direction. The damage will be calculated after the battle.
      Apply any new penalties due to the structure-HP to the ship, or remove it from the calculations, if the ship would overheat.

      Edit: in case of missiles and point-defense. Calculate the chance of the missiles being hit by point defense depending on their travel distance, velocity, PD-cooldown and AI-accuracy.

    • When all ships in one fleet are overheating, or after both fleets have left each other's range again, end the battle, and begin calculating the damage done to the individual blocks using the notes from the hit-events. this process will be sped up if the sector is loaded. This fleet will not be able to engage with other AI-fleets until the damage is calculated, however, it also won't move while the damage is being calculated, but it will however immedeatly move to whichever sector it would be in, had it moved with its new velocity, after damage calculations[if any thrusters were destroyed].
    The only real downside to this, that I see, would be that thrust does not consume power, however the impact of that should be minimal. The solution for docked reactors could be to just add the overflow of energy generation of every docked weaponless entity to the entity it is docked to.
    Wouldn't hundreds of those things running weigh things down quite a bit? I guess this could only apply for player factions fighting; NPC factions can use a more simplified algorithm I suppose.
     

    Winterhome

    Way gayer than originally thought.
    Joined
    Jun 29, 2013
    Messages
    1,929
    Reaction score
    636
    For taking docked reactors into account:

    Perhaps the game could keep track of the average amount of energy per second supplied to a ship from individual docked entities, and the average amount of energy per second spent on fueling those docked entities, then add that stat to a line in a blueprint file when saved?
     

    Ithirahad

    Arana'Aethi
    Joined
    Nov 14, 2013
    Messages
    4,150
    Reaction score
    1,330
    • Purchased!
    • Top Forum Contributor
    • Legacy Citizen 8
    ...Come to think of it, perhaps we could just let it be for now, seeing as Schine evidently has plans for a much less jury-riggy mechanic for reactors.
     
    Joined
    Jul 24, 2013
    Messages
    1,326
    Reaction score
    2,096
    • Master Builder Gold
    • Councillor 2 Gold
    • Video Genius
    indeed!
    Yes,people who build docked power generators did some pretty amazing stuff.
    But you have to admit that this was an exploit that grew into current game meta.

    So keep in mind,power reactors as they are right now,might not, or should not exist in the future,and something far simpler and more streamlined will come to replace that. So immediately you have one problem less with these simulations.
    Also,ships with support equipment will actually have a purpose
     
    Joined
    Jul 21, 2013
    Messages
    2,932
    Reaction score
    460
    • Hardware Store
    Wouldn't hundreds of those things running weigh things down quite a bit? I guess this could only apply for player factions fighting; NPC factions can use a more simplified algorithm I suppose.
    I don't think so, as the calculations are quite simple, and the highest possible event frequency per battle is 2 seconds[any weapon below 1s cooldown is batched to 2 seconds, and every weapon between 1s and 2s cooldown is batched to 2s to 4s cooldown with 2 shots.
    Even if we are pessimistic and say every fire-hit-event[excluding waiting time] takes 0.1 seconds to process, we could still run 20 battles simultaniously without lag on a single core.
     
    • Like
    Reactions: Lecic
    Joined
    Jul 15, 2014
    Messages
    506
    Reaction score
    111
    indeed!
    Yes,people who build docked power generators did some pretty amazing stuff.
    But you have to admit that this was an exploit that grew into current game meta.

    So keep in mind,power reactors as they are right now,might not, or should not exist in the future,and something far simpler and more streamlined will come to replace that. So immediately you have one problem less with these simulations.
    Also,ships with support equipment will actually have a purpose
    That's two contradictory points to be honest. Docked reactors is a pretty big example of a support tool working how it should. If there's any softcaps in the future (which there should definitely be) getting by them to some extent is going to be the best use for support tools. Otherwise why bother? Why put your shield or power generation in the hands of another vessel when you can just integrate it into your ship?

    It's not like docked reactors are game breaking either. They allow bigger ships to handle more firepower than they otherwise would, but it's still less than the equivalent mass in smaller ships. Other diminishing returns also mean that extra power is likely to get eaten up pretty quickly. Bigger ships without docked reactors are also not worthless, they may not be as competitive in pvp, but they're still going to hit harder then a smaller vessel would. And you always have the option of just going for capacity based rather than sustained fire (ie for missile cruisers).

    The only real downside to the current system is that the player isn't really told how it works in game, it's dependent on outside resources and tutorials. All we need is a few NPCs who might give you some friendly advice on how power works (or a tutorial mission etc) and it's sorted. Even letting players know docked reactors are an option is as simple as one NPC in a TG station bar or w/e saying "So I heard some people get by the power limit by docking a ship made almost entirely of power inside, then using power supply beams. Crazy, huh?" (hopefully worded better than that) and then there's an in game source telling them it's an option.
     
    Joined
    Jun 14, 2013
    Messages
    60
    Reaction score
    30
    • Community Content - Bronze 1
    • Legacy Citizen 2
    • Legacy Citizen
    An update so close I can taste it. And it tastes so good I want to strip off all of my clothes and roll around naked in a puddle of it.
    Nice work guys, you are an amizing team of hard working and creative indiviuals with innovative ideas! Never forget that :D
    This combined with upcoming random generated crew members in AI ships and the game has a complete new and fresh feel to it which we all wanted so bad!
     
    • Like
    Reactions: nightrune
    Joined
    Nov 30, 2015
    Messages
    855
    Reaction score
    75
    #Don't shoot the messenger(I still accept tips though!)
    I wasn't aware the points system had any sort of capability to detect things like "armor placement" or "docked reactors" or even things as simple as how certain effects, weapons, and building techniques (spaced armor, etc) work and how they function in combat, or that it will ever be able to detect that kind of thing without just flat out having some AI fight it out.
    Just wanted to point out, all your asking for is a more memory intensive simulation. doesn't make you wrong, I just think the terms of the argument are a little silly. Anyway, yes, any simulation done ought to be more intensive than a simple "which has a higher score?" and yes, the scoring system should be overhauled (you know, like they said they were going to do) but surely we can meet somewhere in the middle without loading in all these engagements that no person is invested enough in to actually take part in.

    Also, yes, designs that favor functionality to the exclusion of form tend to be, well, functional. As for ship shape, that is a good point, the system may have to be adjusted for that. I'm not convinced it needs to run the full AI simulation instead of a partial one.

    In summary: I appreciate your concerns, but I don't share them.
    No, that... sounds pretty horrible in every sense of the word. It's incredibly insulting to engineers to simplify their designs down to "who's got the best scores" and turn a doom cube designed around SCORES rather than actual system quality into the ultimate defensive ship.
    and oh boy, those unloaded sector simulations. Im getting flashbacks to the X series's out of sector mechanics. please schine, whatever you do don't make me have to baby sit my fleets. I've lost too many hard won ships to OOS fights that they would've easily won if I was in sector.
    I completly agree.
    This whole post sounds awesome.... but you can't really... simulate complex ship entities accuratly with a couple of numbers, no matter how hard you try.... not to mention that someone will figure out how to exploit these scores.

    Its a complex issue to work around and I hope we can find a solutions.
    That being said just using a couple of numbers to do this gave me a knee-jerk reaction, and it isnt the sorta direction I would like to see SM go.
    So yeah. I would like how I build my ships to MATTER, instead I could just make a bunch of giant doom cubes that have insanely high atack scores.... on that note how would it take into account power regen and storage??? Would it even be used in the calculations???
    Otherwise Im just gonna fill my doom cube to the brim with weapon modulus and forget about power.
    In reply to these things are a bunch of solutions:

    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.
    I like this one for keeping lag down, but it would also work well a a LOD system. The small ship issue could be a factor, you could simply make the i of smaller ships be smaller than the i of bigger ships.

    What many don't seem to consider, is that fleet battles currently are also just purely numerical[if one excludes player pilots' piloting].
    However, unloaded battles do not need to be fully nuanced, as player pilots can be excluded. Let me elaborate.
    When 2 fleets engage, in the very first moments they have a certain distance from another, let's initialize this variable with the distance of 2 opposite sector borders. The distances of individual ships from one-another depend on formation. If formation won't be implemented, assume it to be the same for all ships in the beginning.
    In the beginning of a battle one can also assume, that energy capacitors and shield-capacitors are full.
    Both fleets also have a maximum movement velocity, which can be determined from the maximum movement velocity of each ship. Directional thrust should be ignored here, for simplicity. This velocity will be important later.
    For weapons with a cooldown of less than a second, average out damage and energy consumption into 2 second batches[include how many shots would be fired per batch as a constant floating point].
    Any other weapon with a cooldown of less than 2 seconds, put 2 shots together in a batch like above.

    Now, follow these rules:
    • Calculate when each ship will come into the reach of which weapon system of an enemy ship, and queue fire-events up based on how long it would take to come into range, and wait until the first event in the queue takes place. This uses the movement velocities of the fleets(and if applicable formation)
    • On any timed event: Calculate the amount of power and shields each ship would have regenerated in the time between this event and the last event. Also, allow each ship to change its orientation and course freely. Note how long it would take for every ship to exit their enemy's range on their current course(every course is assumed to be a straight line). If no event occurs between this event and that time, the battle will end after this event.
    • On a fire-event: The ship this event applies to fires its weapon(s) at an enemy ship in range of the AI's choice, provided the ship has enough power. If the ship lacks the power to fire the weapon, queue up another fire-event for this weapon/batch when the ship would have regenerated enough power, assuming constant regeneration.

      Calculate the likelyhood of a hit depending on AI-accuracy, the dimensions, block-count and distance of the enemy ship. If the weapon in question is fired in batches use the floating point to spread the RNG out over the shots in the batch, and calculate the total damage done by all shots in this batch combined, and queue up a hit event on the targeted enemy ship. The hit event will occur in the time it takes the projectiles to travel the distance.[0 in case of hitscan] Do not queue up a hit-event if the shot(/all shots in the batch) miss.

      Also queue up another fire-event when the cooldown of this weapon(or this batch) would have passed.
    • On a hit-event: Deal the damage noted in the event to the ship this event applies to. If the shields do not completely soak up the damage, estimate which block would have been hit by randomly selecting a side of the bounding-box[depending on the position of this ship relative to the firing ship], and randomly selecting a block facing this side. If the chosen column of blocks is fully empty, repeat with all other columns. If all columns are empty, remove this ship from the calculations , it has to be dead. Do not process the block damage that would be done by the hit, just note down the blocks, damage, type and direction. The damage will be calculated after the battle.
      Apply any new penalties due to the structure-HP to the ship, or remove it from the calculations, if the ship would overheat.

      Edit: in case of missiles and point-defense. Calculate the chance of the missiles being hit by point defense depending on their travel distance, velocity, PD-cooldown and AI-accuracy.

    • When all ships in one fleet are overheating, or after both fleets have left each other's range again, end the battle, and begin calculating the damage done to the individual blocks using the notes from the hit-events. this process will be sped up if the sector is loaded. This fleet will not be able to engage with other AI-fleets until the damage is calculated, however, it also won't move while the damage is being calculated, but it will however immedeatly move to whichever sector it would be in, had it moved with its new velocity, after damage calculations[if any thrusters were destroyed].
    The only real downside to this, that I see, would be that thrust does not consume power, however the impact of that should be minimal. The solution for docked reactors could be to just add the overflow of energy generation of every docked weaponless entity to the entity it is docked to.
    I really like this with sim battles, it would work well with a lot of issues, it might take a bit of work to cut out at first, but would work really well


    If no ones on the server then the ships could do normal combat, but if people are on then do an alert to everyone on contributing factions, as well as an option to spectate the battle(look through the cameras and turrets of the leader of their own fleet). No participation, but you can watch the carnage with popcorn and butter to make up for the lags. If it's 2 megafactions but none of the members are on(but some other people are messing with turrets or something) then... You could make it normal combat, but only if the battle was small enough, or only spawn a certain amount of each side's ships(give a use for having your best ships up front on the command line?)-based on block count, no one wants their 5 of 200 drones facing the enemy's dreadnauts. As ships are destroyed more ships can spawn in to fight to keep the lag down. If to many fights are going on at once, you could make them be sim battles, or make them start once the other ones finished(I know, that might be bad for getting things done for everyone else, but still...).
    [DOUBLEPOST=1455674876,1455674631][/DOUBLEPOST]3 minutes between posts... This may be a record for this thread!
    (Yes this is my own, I still wanted to mention it)
    This idea would allow more events/battles be done in game and keep with things like docked reactors and ship shapes.

    I hope the devs read this, a bunch of diverse ideas here.
    [DOUBLEPOST=1455726394][/DOUBLEPOST]There's probably more, and I missed a lot, just giving some samples.
     
    Joined
    Jul 24, 2013
    Messages
    1,326
    Reaction score
    2,096
    • Master Builder Gold
    • Councillor 2 Gold
    • Video Genius
    That's two contradictory points to be honest. Docked reactors is a pretty big example of a support tool working how it should. If there's any softcaps in the future (which there should definitely be) getting by them to some extent is going to be the best use for support tools. Otherwise why bother? Why put your shield or power generation in the hands of another vessel when you can just integrate it into your ship?

    It's not like docked reactors are game breaking either. They allow bigger ships to handle more firepower than they otherwise would, but it's still less than the equivalent mass in smaller ships. Other diminishing returns also mean that extra power is likely to get eaten up pretty quickly. Bigger ships without docked reactors are also not worthless, they may not be as competitive in pvp, but they're still going to hit harder then a smaller vessel would. And you always have the option of just going for capacity based rather than sustained fire (ie for missile cruisers).

    The only real downside to the current system is that the player isn't really told how it works in game, it's dependent on outside resources and tutorials. All we need is a few NPCs who might give you some friendly advice on how power works (or a tutorial mission etc) and it's sorted. Even letting players know docked reactors are an option is as simple as one NPC in a TG station bar or w/e saying "So I heard some people get by the power limit by docking a ship made almost entirely of power inside, then using power supply beams. Crazy, huh?" (hopefully worded better than that) and then there's an in game source telling them it's an option.
    the point is.... it was NOT an intended feature for it to work like that. what would be the purpose of support ships in the future,if you can cramp everything in one ship protected beneath layers of armor and mothership shields. all it does is ecouraging building jack of all trades motherships.

    before you start defending. Yes.. we have many guys here who love their reactors,but I think we would all love if more ACTUAL strategic elements were introduced to battles. And removing reactors in favor of having support ships would do that. battles would be way more interesting,and fleet commanders would have more stuff to work with to outwit the enemy.
     
    Last edited:

    Master_Artificer

    Press F to pay respects
    Joined
    Feb 17, 2015
    Messages
    1,588
    Reaction score
    612
    • Top Forum Contributor
    • Legacy Citizen 2
    • Thinking Positive
    Schine will need to, at the very least, get a rock-paper-scissors system down for this instead of "ship has better score, so it wins".
    Pistol beats sniper, sniper beats shotgun, shotgun beats pistol (halo balance).
    Sure you can brute force your shotguns to beat the sniper, but you'll take disproportionate losses comparatively.

    If it just is a "better score = wins" or even something along those lines, then we might have a boring game on our hands :O


    Now, if the schine team still has it so it is based on score systems, then lets flesh out these score systems!
    We will need many categories, and sub categories for those categories.
    We will need things like
    • Offensive
    • Defensive
    • Maneuverability
    • Other
    ... Kinda like what we have already! :P

    Now I can tell you already that we will need to split offensive down into many different sub categories, like range bands, DPS or Aplha damage, and whether or not a weapon uses increments or an all or nothing. (A missile+pulse+pierce on the weapons panel has impressive stats even for DPS, but if the weapon misses or is shot down, its DPS for that "turn" is effectively 0 as it has the longest reload ever. Where-as a Cannon+cannon+punch, if it misses half of it's shots for the turn, still has dealt some damage.

    I have just now realized that we also have to take into account weapon speed. If you watched the 2nd B&S, you see that all types of missiles generally took quite a long time to reach their targets. Using missiles would be akin to putting damage "in the que" and you wait a few turns until it starts being applied. (and it will be applied, because it is lock-on!)


    I think we should spend more time determining what sub categories we need and how a rock paper scissors could/would/(or should) effect this, and what each category will represent and how it will impact the sim battle.
     
    • Like
    Reactions: SkylordLuke

    Ithirahad

    Arana'Aethi
    Joined
    Nov 14, 2013
    Messages
    4,150
    Reaction score
    1,330
    • Purchased!
    • Top Forum Contributor
    • Legacy Citizen 8
    Eh, for now I think the algorithms can just use a balanced version of the current ship ratings + ship stats + sanity checks for power consumption vs power availability + thrust configuration + the Great Triangle of PewPew (Range/Fire Rate/Damage). Yes, it isn't optimal, and yes, there will be exploits, but the alternative is that we spend months trying to get this damned thing right :P
     
    Joined
    Jul 15, 2014
    Messages
    506
    Reaction score
    111
    the point is.... it was NOT an intended feature for it to work like that. what would be the purpose of support ships in the future,if you can cramp everything in one ship protected beneath layers of armor and mothership shields. all it does is ecouraging building jack of all trades motherships.
    Tbh I'd say just building a bigger ship and brute forcing your power generation would be a preferable option to relying on an outside vessel. Between ships moving around, the risk of the smaller ships being destroyed etc it just doesn't seem like it will ever be worth it. The only real way it would ever be worthwhile is if the soft cap becomes a hard cap, and you stop docked support tools from hitting their parent ship. In this case I'd speculate you'll see bigger ships become basically one time use super weapons, and any actual capital esque combat would become functionally not worth it. You may also see bigger ships become pure carriers, but given how effective drones are (and that this looks like it's going to become more true with fleets) the game doesn't need to give the player more incentive to just build drone swarms and nothing else.

    We already have limiting factors for jack of all trade motherships, namely lack of manoeuvrability, diminishing returns on most stats/weapons (can be gotten around with docked reactors to an extent, but there's still a substantial efficiency loss, that gets bigger as the ship grows). And it's not like docked reactors are inconsistent, there's an actual in game feature for doing something similar with docks.
     

    Criss

    Social Media Director
    Joined
    Jun 25, 2013
    Messages
    2,187
    Reaction score
    1,772
    • Master Builder Bronze
    • Video Genius
    • Competition Winner - Stations
    If I said we were going to real space I have a feeling we could collectively discuss the merits on how each Schine member was going to get there and actually make it a reality. :p So much speculation.
     
    • Like
    Reactions: SkylordLuke

    nightrune

    Wizard/Developer/Project Manager
    Joined
    May 11, 2015
    Messages
    1,324
    Reaction score
    577
    • Schine
    • Top Forum Contributor
    • Thinking Positive
    but the alternative is that we spend months trying to get this damned thing right :p
    Worth it, but start at the numbers and see if we can build something that works well there.
     
    Joined
    Oct 24, 2014
    Messages
    226
    Reaction score
    97
    • Legacy Citizen
    • Purchased!
    To paraphrase WWII American General George S Patton:

    A good plan now is better than a perfect plan later.

    PS: No offense to those of Germanic heritage
     

    Exozen

    C-D SOLDIER
    Joined
    Jul 7, 2013
    Messages
    151
    Reaction score
    230
    • Purchased!
    • Competition Winner - Small Fleets
    • Legacy Citizen 4
    Suggestion for docking:
    Instead of a full track of these invisible rails (lets call them Pathway blocks), use C+V and link a 'pathway' for the ship to follow. This pathway will look like the logic connection tube, but will be invisible outside build mode.

    Docking: The path starts at the trigger area(?) and follows the (normally) invisible glowing line, ending at the rail.
    Undocking: Process above but reversed.

    The pathway can vary from a simple line to far more complex shapes; it requires much less docking path blocks to be placed than a track, and allows angled movement into more complex structures- something I feel is important for Starmade.

    [t]
    |
    |
    [x]-----[x]
    - - - - - \
    - - - - - - \
    - - - - - - [>]

    [t]: Trigger area
    | : Pathway
    [x]: Pathway block
    [>]: Rail
     
    Joined
    Jun 22, 2013
    Messages
    196
    Reaction score
    157
    • Purchased!
    • Legacy Citizen 8
    I'm very impressed by this system. Some of it is common sense or has been discussed before, but I wasn't expecting the unloaded fleet battles- I'm willing to accept the compromises the necessary abstraction will bring, because being able to send off a fleet to do your bidding and not even having to go with them is just plain awesome. This first-person space RTS/4X Starmade is becoming is pretty much my dream game.
     
    Joined
    Nov 30, 2015
    Messages
    855
    Reaction score
    75
    Suggestion for docking:
    Instead of a full track of these invisible rails (lets call them Pathway blocks), use C+V and link a 'pathway' for the ship to follow. This pathway will look like the logic connection tube, but will be invisible outside build mode.

    Docking: The path starts at the trigger area(?) and follows the (normally) invisible glowing line, ending at the rail.
    Undocking: Process above but reversed.

    The pathway can vary from a simple line to far more complex shapes; it requires much less docking path blocks to be placed than a track, and allows angled movement into more complex structures- something I feel is important for Starmade.

    [t]
    |
    |
    [x]-----[x]
    - - - - - \
    - - - - - - \
    - - - - - - [>]

    [t]: Trigger area
    | : Pathway
    [x]: Pathway block
    [>]: Rail
    Meh... I think it would be easier to make cargo blocks that act like rails, all rail blocks called "pathways" that had all the same blocks as rails, except for turrets and dockers. Regular rail dockers would dock to pathways.
    To paraphrase WWII American General George S Patton:

    A good plan now is better than a perfect plan later.

    PS: No offense to those of Germanic heritage
    Definately, get the update out and clean it up later. Make sure you get it done eventually(within 2-3months I would expect a mediocre system, but unless the starting system is terrible, I'm sure people could deal with first generation fleets for a while.
     
    • Like
    Reactions: Ithirahad