Author Topic: Assorted constructor feature requests  (Read 7216 times)

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Assorted constructor feature requests
« on: June 15, 2009, 09:53:40 pm »
With the new production added to constructor's group, I thought of few more (it did start at 2, honest) things which would make life much easier for controlling all this goodness

1) hotkeys alt-0 to alt-9 (or some other combination) to select only constructors in a control group

2) if multiple constructors of the same type are selected, permit queue ops on all of them at the same time, with perhaps a button to clear/reset queues if different to begin with, perhaps requiring it to be pressed to start multi-constructor ops.  That way I could tell the group, stop making fighers, make bombers now! without having to go through 4 or 6 space docks.  I can see this one being pain to implement, but maybe not :)

3) For crystal/metal harvesters, permit a right clicking or (shift click or toggle) on the harvester icon to build a harvester at the next available spot.  I'd rather right click 7 times, then have to hunt for 7 metal spots.  Ya, I know I can hit M, but I'm lazy.   :P   Oh, and grey out the button when all harvester spots are occupied. (Blatantly stolen from Sins of a Solar Empire :) )

4) Overzoom - extend the zoom out so that the entire planet space is on screen, perhaps with black bars on left/right.

5) "Self-preservation" Targeting - this one is more difficult to do I think.  It would be nice if ships that are given a "safe" target to attack (say forcefield or warpgate or train station or ... ) and are happily going at it, when attacked by another ship in range of their guns, would temporarily switch their fire to remove the threat.  Dragging in some of  their squadronmates would be a bonus.  Right now, they blissfully ignore such interlopers, and given enough time without the human realizing what is happening, their numbers can dwindle significantly.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Assorted constructor feature requests
« Reply #1 on: June 15, 2009, 10:22:10 pm »
With the new production added to constructor's group, I thought of few more (it did start at 2, honest) things which would make life much easier for controlling all this goodness

Ha, no worries.  Thanks for the suggestions!

1) hotkeys alt-0 to alt-9 (or some other combination) to select only constructors in a control group

Hmm, I don't want to use Alt because that would get confusing on the galaxy map, I think.  Or, that would only work in the main view and not in the galaxy view, one or the other.  I'm kind of running out of hotkeys, but X never does anything that isn't paired with a mouse click or something.  So, we could do maybe X+0-9 to do this sort of selection.  Added to my list.

2) if multiple constructors of the same type are selected, permit queue ops on all of them at the same time, with perhaps a button to clear/reset queues if different to begin with, perhaps requiring it to be pressed to start multi-constructor ops.  That way I could tell the group, stop making fighers, make bombers now! without having to go through 4 or 6 space docks.  I can see this one being pain to implement, but maybe not :)

Yeah, I remember seeing this in I think AoEIII.  I don't really remember how they did it precisely, though.  I can see the appeal of this, but I think that the queue management itself would have to be blind -- in other words you have the controls for all of them, and can issue commands (including the loop and pause buttons).  That way you could just Ctrl+Right-click fighters (which removes all fighters), and then click bombers a few times to add bombers into all of the queues.  I think that's the best I can do for now, but hopefully that would work for what you are looking for.

3) For crystal/metal harvesters, permit a right clicking or (shift click or toggle) on the harvester icon to build a harvester at the next available spot.  I'd rather right click 7 times, then have to hunt for 7 metal spots.  Ya, I know I can hit M, but I'm lazy.   :P   Oh, and grey out the button when all harvester spots are occupied. (Blatantly stolen from Sins of a Solar Empire :) )

Already have the auto-build thing thanks to player requests (was new in 1.005, I think).  Just Ctrl+click the button and it will build all of them at the current planet.  So just one click per resource type, not even 7!  It notes this hotkey in a little tip on the hovertext for the harvesters, but you might have missed that if that was added after you were already familiar with the game.

Good idea about the harvester spots being overused and then making the button gray (in my case, I tend to do red to indicate that something can't be built).  I'll definitely do that.

4) Overzoom - extend the zoom out so that the entire planet space is on screen, perhaps with black bars on left/right.

This is something that I can't really do at present.  The way that I am drawing the bounding box of blackness just isn't compatible with doing this sort of thing, and I can't think of any way around it given the technical limitations of that style of DirectX drawing...

5) "Self-preservation" Targeting - this one is more difficult to do I think.  It would be nice if ships that are given a "safe" target to attack (say forcefield or warpgate or train station or ... ) and are happily going at it, when attacked by another ship in range of their guns, would temporarily switch their fire to remove the threat.  Dragging in some of  their squadronmates would be a bonus.  Right now, they blissfully ignore such interlopers, and given enough time without the human realizing what is happening, their numbers can dwindle significantly.

Ah, that's just making the game play itself for you. ;)  This is an offensive-only sort of issue, and I'm not really inclined to automate this; I don't know of any other games that automate that.  If they are getting shot up, that means that either 1) you need to have set up some protector type ships in advance (something further back so that it is not shooting at the safe target, but that is in range of shooting at whatever might shoot your ships), or 2) you need to be watching them more carefully and draw them off the forcefield yourself (just right click anywhere, and they'll retarget the local hostiles most likely).

I'm all for automating certain things about the economy and defenses, because those need to be left unattended, but when it comes to offense I think that tactical maneuvering is an important part of this genre and not something that I want to automate out of relevancy.  Let me know what you think, though. :)
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Assorted constructor feature requests
« Reply #2 on: June 15, 2009, 10:45:47 pm »
2) if multiple constructors of the same type are selected, permit queue ops on all of them at the same time, with perhaps a button to clear/reset queues if different to begin with, perhaps requiring it to be pressed to start multi-constructor ops.  That way I could tell the group, stop making fighers, make bombers now! without having to go through 4 or 6 space docks.  I can see this one being pain to implement, but maybe not :)

Yeah, I remember seeing this in I think AoEIII.  I don't really remember how they did it precisely, though.  I can see the appeal of this, but I think that the queue management itself would have to be blind -- in other words you have the controls for all of them, and can issue commands (including the loop and pause buttons).  That way you could just Ctrl+Right-click fighters (which removes all fighters), and then click bombers a few times to add bombers into all of the queues.  I think that's the best I can do for now, but hopefully that would work for what you are looking for.

What I was thinking is that there should be an indicator that the constructors possibly have different queue contents, but ya, once change is made, any previous settings would be overridden.

3) For crystal/metal harvesters, permit a right clicking or (shift click or toggle) on the harvester icon to build a harvester at the next available spot.  I'd rather right click 7 times, then have to hunt for 7 metal spots.  Ya, I know I can hit M, but I'm lazy.   :P   Oh, and grey out the button when all harvester spots are occupied. (Blatantly stolen from Sins of a Solar Empire :) )

Already have the auto-build thing thanks to player requests (was new in 1.005, I think).  Just Ctrl+click the button and it will build all of them at the current planet.  So just one click per resource type, not even 7!  It notes this hotkey in a little tip on the hovertext for the harvesters, but you might have missed that if that was added after you were already familiar with the game.

Good idea about the harvester spots being overused and then making the button gray (in my case, I tend to do red to indicate that something can't be built).  I'll definitely do that.

Missed that one, thanks!

4) Overzoom - extend the zoom out so that the entire planet space is on screen, perhaps with black bars on left/right.

This is something that I can't really do at present.  The way that I am drawing the bounding box of blackness just isn't compatible with doing this sort of thing, and I can't think of any way around it given the technical limitations of that style of DirectX drawing...

Hmmm... if you could pre-allocate blank space outside of the map (since you know the screen ratio, so you now how much extra space you need).   Then just prevent the user from panning past the map limits, unless it is in full zoom out mode, when you show the extra dead space.

5) "Self-preservation" Targeting - this one is more difficult to do I think.  It would be nice if ships that are given a "safe" target to attack (say forcefield or warpgate or train station or ... ) and are happily going at it, when attacked by another ship in range of their guns, would temporarily switch their fire to remove the threat.  Dragging in some of  their squadronmates would be a bonus.  Right now, they blissfully ignore such interlopers, and given enough time without the human realizing what is happening, their numbers can dwindle significantly.

Ah, that's just making the game play itself for you. ;)  This is an offensive-only sort of issue, and I'm not really inclined to automate this; I don't know of any other games that automate that.  If they are getting shot up, that means that either 1) you need to have set up some protector type ships in advance (something further back so that it is not shooting at the safe target, but that is in range of shooting at whatever might shoot your ships), or 2) you need to be watching them more carefully and draw them off the forcefield yourself (just right click anywhere, and they'll retarget the local hostiles most likely).

I'm all for automating certain things about the economy and defenses, because those need to be left unattended, but when it comes to offense I think that tactical maneuvering is an important part of this genre and not something that I want to automate out of relevancy.  Let me know what you think, though. :)

Well, almost.  I do find it aggravating sometimes that units in RTS games will blissfully ignore threats and just carry out their order.  Happily in AI War, at least the units will attack on their own, without us having to provide them with a rules of engagement (in triplicate) and a certified note from their mommy.  Still, I would ask that there be a tiny bit of logic which says: If I am currently firing  (due to right click order) at a target which cannot damage me, and I am then attacked by something which can, I will change targets.  Perhaps doing it on squadron level is bit too much automation, but I still think that units should have at least a shred of self-preservation, even if the player would like to say "stop fighting back and just blow up the shield, the escort is on the way."  They are manned ships after all, right?  Except maybe the Kamikaze...  ;D

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Assorted constructor feature requests
« Reply #3 on: June 15, 2009, 11:02:06 pm »
What I was thinking is that there should be an indicator that the constructors possibly have different queue contents, but ya, once change is made, any previous settings would be overridden.

Well, I can't think of a good way to really show that indicator.  I guess potentially I could have a button per selected constructor up there (up to a max of 8), and hovering over them shows the queues in each.  I think I'm going to start with the simpler approach, though, and see how that looks before going too far with that.

Missed that one, thanks!

No problem!  That's one of the (many) recent additions, so it's easy to overlook if you were already immersed.

Hmmm... if you could pre-allocate blank space outside of the map (since you know the screen ratio, so you now how much extra space you need).   Then just prevent the user from panning past the map limits, unless it is in full zoom out mode, when you show the extra dead space.

Well, the problem is really the background for the stars.  Having a semi-transparent background out there is problematic when trying to put something out there in the dead space, and I'm concerned that it will mess with the feeling of being out in space if I change that too much.  I guess I could fairly easily make a solid black "dead space" as you call it, but I'd prefer to have the stars be somewhat visible.  I'll experiment around with those, and do the solid black if nothing else works.  You're not the first to ask for this feature, and I did appreciate it in Supcom, too.

Well, almost.  I do find it aggravating sometimes that units in RTS games will blissfully ignore threats and just carry out their order.  Happily in AI War, at least the units will attack on their own, without us having to provide them with a rules of engagement (in triplicate) and a certified note from their mommy.  Still, I would ask that there be a tiny bit of logic which says: If I am currently firing  (due to right click order) at a target which cannot damage me, and I am then attacked by something which can, I will change targets.  Perhaps doing it on squadron level is bit too much automation, but I still think that units should have at least a shred of self-preservation, even if the player would like to say "stop fighting back and just blow up the shield, the escort is on the way."  They are manned ships after all, right?  Except maybe the Kamikaze...  ;D

I've been thinking of most of the ships as being robotic, but either way.  I can see your point, but also there's a lot of times when you want to attack some big target and take it out despite whatever is attacking you.  To me, that's what the explicit selection (right clicking) means.  However, I would be willing to concede that it makes sense for ships that are being shot to switch targets if you didn't explicitly right-click the force field, but rather just put them in the vicinity of it and told them to attack whatever (leading them to probably attack the force field).  So the logic would be:  If I am currently firing  (NOT due to right click order) at a target which cannot damage me, and I am then attacked by something which can (and which I can damage to a reasonable degree), I will change targets.  Thoughts?
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Assorted constructor feature requests
« Reply #4 on: June 16, 2009, 09:09:23 am »
What I was thinking is that there should be an indicator that the constructors possibly have different queue contents, but ya, once change is made, any previous settings would be overridden.

Well, I can't think of a good way to really show that indicator.  I guess potentially I could have a button per selected constructor up there (up to a max of 8), and hovering over them shows the queues in each.  I think I'm going to start with the simpler approach, though, and see how that looks before going too far with that.

One idea I had was that if the queues were the same, then the standard interface would be shown.  If the queues were different, then only one button would be shown: "Clear/sync queues".  If it was pressed, then all queues would be cleared, and the standard queue interface would be then shown.


Well, almost.  I do find it aggravating sometimes that units in RTS games will blissfully ignore threats and just carry out their order.  Happily in AI War, at least the units will attack on their own, without us having to provide them with a rules of engagement (in triplicate) and a certified note from their mommy.  Still, I would ask that there be a tiny bit of logic which says: If I am currently firing  (due to right click order) at a target which cannot damage me, and I am then attacked by something which can, I will change targets.  Perhaps doing it on squadron level is bit too much automation, but I still think that units should have at least a shred of self-preservation, even if the player would like to say "stop fighting back and just blow up the shield, the escort is on the way."  They are manned ships after all, right?  Except maybe the Kamikaze...  ;D

I've been thinking of most of the ships as being robotic, but either way.  I can see your point, but also there's a lot of times when you want to attack some big target and take it out despite whatever is attacking you.  To me, that's what the explicit selection (right clicking) means.  However, I would be willing to concede that it makes sense for ships that are being shot to switch targets if you didn't explicitly right-click the force field, but rather just put them in the vicinity of it and told them to attack whatever (leading them to probably attack the force field).  So the logic would be:  If I am currently firing  (NOT due to right click order) at a target which cannot damage me, and I am then attacked by something which can (and which I can damage to a reasonable degree), I will change targets.  Thoughts?

For ships not on forced attack (right-click), this should really never come up, as the targeting priority would take care of such threats.  Now I'm getting really torn on the forced attack ones.  On one hand, I'd like my ships to not be blind automatons, on another hand, I want units to blindly follow my orders, yet on another hand, I almost want the ships to "rebel" if their existence is at stake, and take matters in their own hands.   Almost something like this, if a unit is on forced attack of a safe target, and it is attacked by something else, and that something else is not currently targeted by anything else, it will switch target.  But ya, I can see how this would be a quite slippery slope.

Anyone else have thoughts or comments on this?

Coincidently, once a target is auto-selected by a unit, does it keep re-checking periodically for better targets/bigger threats?

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Assorted constructor feature requests
« Reply #5 on: June 16, 2009, 09:24:04 am »
One idea I had was that if the queues were the same, then the standard interface would be shown.  If the queues were different, then only one button would be shown: "Clear/sync queues".  If it was pressed, then all queues would be cleared, and the standard queue interface would be then shown.

Hmm, I think I like that.  The main thing is that I wouldn't be able to show the progress of the individual first thing, since that will commonly be slightly off unless all of them have identical engineers assisting and have all been managed through the central interface.

For ships not on forced attack (right-click), this should really never come up, as the targeting priority would take care of such threats.  Now I'm getting really torn on the forced attack ones.  On one hand, I'd like my ships to not be blind automatons, on another hand, I want units to blindly follow my orders, yet on another hand, I almost want the ships to "rebel" if their existence is at stake, and take matters in their own hands.   Almost something like this, if a unit is on forced attack of a safe target, and it is attacked by something else, and that something else is not currently targeted by anything else, it will switch target.  But ya, I can see how this would be a quite slippery slope.

Anyone else have thoughts or comments on this?

Coincidently, once a target is auto-selected by a unit, does it keep re-checking periodically for better targets/bigger threats?

Your last comment there is a good one -- no, ships do not keep rechecking for new targets once they have autotargeted on an existing one.  In normal battle this is no issue, but near something huge like a force field or a fortress or something, it can require you to keep a closer eye on them.  The target selection checking is one of the most CPU-intensive aspects of the game, so I have to limit this to a certain extent to keep the system requirements reasonable.

For the direct targeting, I really don't want ships to do anything except what I tell them, and I think most other RTS players tend to agree based on what feedback I've had from people on cutlasses and vampires, which previously were a lot more "rebellious" than they are now.  People found that really frustrating, and so I had to change it so that those ships would ignore all targets while moving to a player-initiated destination, rather than attacking whatever they passed (attack-move mode being the exception, naturally).

If we put in the "rebellious" logic as described, that would also be also be the end of gate-raiding, since the raiding ships would tend to get distracted and lost along the way, completely missing their goal.  It's kind of a catch 22 with stuff like this, because people want intelligence in the units they command, but they also want utter obedience in most cases.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Assorted constructor feature requests
« Reply #6 on: June 16, 2009, 09:40:56 am »
One idea I had was that if the queues were the same, then the standard interface would be shown.  If the queues were different, then only one button would be shown: "Clear/sync queues".  If it was pressed, then all queues would be cleared, and the standard queue interface would be then shown.

Hmm, I think I like that.  The main thing is that I wouldn't be able to show the progress of the individual first thing, since that will commonly be slightly off unless all of them have identical engineers assisting and have all been managed through the central interface.

I'd say that not showing the individual progress is minor issue.  If I want to see the progress, I'll just click the particular factories.  And I think we should treat 5/20 and 15/20 fighters as the same queue for purposes of the reset button.

Of course you could steal another page from SupCom, and add factory assist option.  So if I set a rally point of a factory A to factory B, it will then be performing the factory B's queue (with proper queue updating, so 10 fighter queue will cause each factory to produce 5 in this case).

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Target selection logic discussion
« Reply #7 on: June 16, 2009, 09:46:07 am »

Coincidently, once a target is auto-selected by a unit, does it keep re-checking periodically for better targets/bigger threats?

Your last comment there is a good one -- no, ships do not keep rechecking for new targets once they have autotargeted on an existing one.  In normal battle this is no issue, but near something huge like a force field or a fortress or something, it can require you to keep a closer eye on them.  The target selection checking is one of the most CPU-intensive aspects of the game, so I have to limit this to a certain extent to keep the system requirements reasonable.

Ah, in this case, maybe rescan targets on attack might be a good idea, when attacking something "safe" anyway.  Hmmm... wonder if there is a way to implement "distress calls" to roaming defenders, on a low CPU cost budget.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Target selection logic discussion
« Reply #8 on: June 16, 2009, 09:50:34 am »
Ah, in this case, maybe rescan targets on attack might be a good idea, when attacking something "safe" anyway.  Hmmm... wonder if there is a way to implement "distress calls" to roaming defenders, on a low CPU cost budget.

I like the idea of having them respond to attacks that hit them when they are not in forced-targeting mode.  That's a pretty low-CPU-cost way to make them reactive.  The main thing about all of this is just the scale, the logic that works when you have 10 units beating on a forcefield in a planet with 500 enemies also has to work when you and 8 allies bring 4,000 units into a planet with 2,000 enemy ships.  But I might be able to work something out with the rescans, even... I'll have to take a look in there and see what I can do.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Target selection logic discussion
« Reply #9 on: June 16, 2009, 10:07:08 am »
Ah, in this case, maybe rescan targets on attack might be a good idea, when attacking something "safe" anyway.  Hmmm... wonder if there is a way to implement "distress calls" to roaming defenders, on a low CPU cost budget.

I like the idea of having them respond to attacks that hit them when they are not in forced-targeting mode.  That's a pretty low-CPU-cost way to make them reactive.  The main thing about all of this is just the scale, the logic that works when you have 10 units beating on a forcefield in a planet with 500 enemies also has to work when you and 8 allies bring 4,000 units into a planet with 2,000 enemy ships.  But I might be able to work something out with the rescans, even... I'll have to take a look in there and see what I can do.

In this case, the fire-hose style attacks are a benefit, because there will be generally a limited number of ships that will be under attack at any one time.  I can see ships having a flag, I'm_attacking_a_(mostly)_harmless_target, and only have those qualify for rescan.  Or possibly, have a list of ships with the flag, and every 10-15 sec run new target selection cycle on those (this might be less CPU intensive, especially if a lot of ships are in a furball, because otherwise you would have to do a flag check on each attack,) and a side benefit, this would make groups of ships notice the fate of their squadron mates.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Target selection logic discussion
« Reply #10 on: June 16, 2009, 10:15:55 am »
Or possibly, have a list of ships with the flag, and every 10-15 sec run new target selection cycle on those (this might be less CPU intensive, especially if a lot of ships are in a furball, because otherwise you would have to do a flag check on each attack,) and a side benefit, this would make groups of ships notice the fate of their squadron mates.

Yep, that's pretty much what I was thinking -- of course, that's only for when the targets are not directly assigned by players.  But yeah, I think that would be a solid improvement.

EDIT:  Although, I was thinking of leaving off the "soft target" part, and instead just having a counter that says "I've been attacking this same target for 15 seconds now.  Is there anything better out there?"  That way when ships are attacking something that they are being relatively ineffective against -- but that the player did not explicitly assign them to -- they will at least look around for other targets every 15 seconds or so.
« Last Edit: June 16, 2009, 10:18:00 am by x4000 »
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Assorted constructor feature requests
« Reply #11 on: June 16, 2009, 10:21:54 am »
Agreed!

Now, perhaps we need an escort/guard mode, so that we could assign "fighters" to stick to bombers doing base assault.  ;D

EDIT: Hmm... the "soft target" flag would definitely cut down on CPU load, but having all-unit counter is a good idea.  Especially since odds are the counters will be out of sync, and so the targeting calculations will be spread out.  You might be even able to look at the current CPU load, and dynamically change how often to do the re-scan.
« Last Edit: June 16, 2009, 10:25:21 am by netWilk »

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Assorted constructor feature requests
« Reply #12 on: June 16, 2009, 10:26:06 am »
Now, perhaps we need an escort/guard mode, so that we could assign "fighters" to stick to bombers doing base assault.  ;D

Already there, in the form of "group move!"  Just hold down G while giving movement orders, and they will all move at the speed of the slowest non-engine-damaged member.  Or if you want to make a permanent toggle, there's a button at the bottom. :)
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline netWilk

  • Newbie Mark III
  • *
  • Posts: 29
Re: Assorted constructor feature requests
« Reply #13 on: June 16, 2009, 10:28:30 am »
Now, perhaps we need an escort/guard mode, so that we could assign "fighters" to stick to bombers doing base assault.  ;D

Already there, in the form of "group move!"  Just hold down G while giving movement orders, and they will all move at the speed of the slowest non-engine-damaged member.  Or if you want to make a permanent toggle, there's a button at the bottom. :)

I guess that works, but have to remember to re-target either the bombers or escorts when the group gets to the target (don't want escorts to be on forced attack.)

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Assorted constructor feature requests
« Reply #14 on: June 16, 2009, 10:30:47 am »
EDIT: Hmm... the "soft target" flag would definitely cut down on CPU load, but having all-unit counter is a good idea.  Especially since odds are the counters will be out of sync, and so the targeting calculations will be spread out.  You might be even able to look at the current CPU load, and dynamically change how often to do the re-scan.

I also spread out the targeting logic automatically -- it is only allowed to run a certain number per second, period, so that performance bogs down.  So really, at this stage with my other optimizations already there, this change won't cause an increase in CPU load at all, instead what it might cause is more of a delay before other ships do any targeting at all.  It processes 1,100 ships per second per player, across all planets, so this logic should work okay with no serious ill effects...
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!