Author Topic: Improving Wave Options  (Read 524 times)

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,347
Re: Improving Wave Options
« Reply #15 on: November 13, 2017, 09:21:10 PM »
So it looks like a planet can legitimately have Index 0, but calling GetPlanetByIndex(0) gets "null".
Planets are deserialized after Factions, so you'll just have to hold onto the index. In your case the planet list is empty at that point in time.

For this reason sometimes I only keep the index even during the game, and just look it up in any functions that need it. GetPlanetByIndex() is inexpensive.

Or you can keep a reference and populate it at some point after deserialization.

Make sense?
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #16 on: November 13, 2017, 09:25:09 PM »
Yup, I can work around that easily enough.

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #17 on: November 14, 2017, 01:28:17 AM »
   I am attaching here a patch that implements a rework of Wave Sending logic. It allows a lot more flexibility with things like
  • Sending multiple types of ships
  • Warning the player when a wave is incoming
  • Allowing "how much advance warning the player gets of an incoming wave" to be tunable

This patch re-implements the current behaviour. The only changes apparent to the player are a tooltip to show when and where the AI waves are incoming, that AI waves now default to 2 different types of ships (this done primarily to illustrate the capability. Currently hardcoded but easily tunable), and that the player gets a max of 5 minutes warning for the incoming wave (again hardcoded, done to illustrate the capability, but easily tunable)
   
The code as written seems to work okay for me, both the regular Wave path and the Hacking paths. Submitting this patch for review/critique. You are welcome to incorporate it as is, but I suspect you might prefer to send it back for some changes (be they only tidying/rationalization of variable names).

Future work includes flagging a planet with an incoming wave in the Galaxy Map (maybe by changign the planet colour?). Also explicitly allowing the player to choose between
  • Direct Waves (current behaviour, wave spawns on your planet)
  • Cross Planet Waves (Wave spawns at a Warp Gate then flies to your planet)
  • Threat Waves (waves spawn and join the Threat immediately. Note this is Cross Planet Waves from AIWC)
  • Allow homogenous/non-homogenous nature of the waves to be changable; maybe based on AIP, maybe based on AI difficulty (maybe an AI type/plot)
  • Allow waves to analyze your defenses and choose either a particularly strong wave (high difficulty) or one that's countered already by your defenses (low difficulty)

Note for anything using this that the first wave will now appear 20 minutes into the game, so you will see a warning 15 minutes in (see the discussion about the first wave time earlier in this thread)
« Last Edit: November 14, 2017, 09:22:57 AM by BadgerBadger »

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,347
Re: Improving Wave Options
« Reply #18 on: November 14, 2017, 09:53:38 AM »
Thanks very much :)

A few observations from testing:

1) The timer comes up about the time I would expect, and the tooltip tells me how many squads of what types will come, and it sounds reasonable, but when the timer is done the units don't spawn on my planet, but on a neighboring one. I mention it because I thought you said "Direct Waves" was the current behavior? Or did you mean something else?

2) After that wave launches, the timer remains (starting at 10 minutes), but the tooltip does not describe the contents. Later on it did describe them; I don't know if that was just a later stage of the same timer or a timer-after-that-timer. It's as if it's showing the time until the next announcement, or until the next wave, but the wave itself hasn't been planned yet. I have no idea.

Is this the behavior you intended?
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #19 on: November 14, 2017, 10:04:09 AM »
Neither of those behaviours sounds desirable. Looks like I haven't ironed out all the bugs yet; ah the joys of late night coding. I'll take another look tonight and hopefully make things happier.

I do have a question about what I call "Cross Planet Waves", where the ships should spawn on a remote Warp Gate then fly to the target system. If I spawn the units during PerSimStep then I need to control those units explicitly during the DoLongRangePlanning step and say "Go to your target". The obvious way to do that is to attach some ExternalData (the planet idx of the target, I expect) to those entities so I can check that in DoLongRangePlanning. Is that an approach you would recommend?

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #20 on: November 14, 2017, 11:01:27 AM »
Okay, both of the things you complained about are resolved thanks to two one-liner fixes. (in one case I picked the wrong end of the wormhole, in the other case I failed to reset a variable at the beginning of the "detect any valid incoming waves" loop). Give it another try.

Edit: also some minor code tidying. The number of different incoming ship types is now a random number between 1 and 3. Waves will sometimes spawn actually at a warp gate, then travel in regular space to the target planet; this style of wave will produce a different  tooltip message explaining the behaviour.
« Last Edit: November 15, 2017, 12:02:54 AM by BadgerBadger »

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,347
Re: Improving Wave Options
« Reply #21 on: November 14, 2017, 12:18:31 PM »
I do have a question about what I call "Cross Planet Waves", where the ships should spawn on a remote Warp Gate then fly to the target system. If I spawn the units during PerSimStep then I need to control those units explicitly during the DoLongRangePlanning step and say "Go to your target".
It depends on what you want them to do. In AIWC CPWs basically just spawned as threat. If that's all you want here then set their Behavior to Attacker and you're done.

If you want them to path to a specific planet, or otherwise pursue a purpose beyond normal threat logic, you'll need to do something else.

Quote
The obvious way to do that is to attach some ExternalData (the planet idx of the target, I expect) to those entities so I can check that in DoLongRangePlanning. Is that an approach you would recommend?
I don't see why you'd need to do that; you can just queue up orders on the entities right as you spawn them and they'll generally follow those orders. If you find that the threat logic is "fighting" you by overriding those orders then let me know and we can sort out a mechanism whereby you can give non-overridable orders or something like that.

Thanks for the fixes, I'll look at those later today.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #22 on: November 14, 2017, 12:51:25 PM »
You can't send orders without an ArcenLongTermPlanningContext, can you? And the code doesn't seem to have one of those in the PerSimStep logic.

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,347
Re: Improving Wave Options
« Reply #23 on: November 14, 2017, 01:29:19 PM »
You can't send orders without an ArcenLongTermPlanningContext, can you? And the code doesn't seem to have one of those in the PerSimStep logic.
I don't mean send the orders, I mean queue the orders, like:

Code: [Select]
entity.EntitySpecificOrders.QueuedOrders.Add( EntityOrder.Create_Wormhole( 2, false ) );
Speaking more generally, in a PerSimStep situation you can modify the gamestate (that isn't flagged for use by some other thread) with a great degree of freedom as long as you stick to stuff that is synchronized between machines in MP (so don't base your modifications on what planet the player is looking at, because that's different between machines, and make sure you use the context-object's random generator for any random rolls you need, etc).

And EntityOrder objects are just gamestate. You don't need to deal with GameCommand objects there.

LongTermPlanning exists mainly so that cpu-intensive decision making can happen on a thread that doesn't need to complete before the end of the current sim step.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #24 on: November 14, 2017, 06:20:12 PM »
I updated my previous patch to include support for allowing the ships to spawn on a remote planet then travel through normal space to the target. Looks like the ships tend not to actually go through the wormhole and attack. I'm not sure if this is a bug in my code or because the AI threat algorithm thinks I'm too much of a threat. You can see what I did at the end of the SpawnWave() function

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,347
Re: Improving Wave Options
« Reply #25 on: November 14, 2017, 07:37:16 PM »
I updated my previous patch to include support for allowing the ships to spawn on a remote planet then travel through normal space to the target. Looks like the ships tend not to actually go through the wormhole and attack. I'm not sure if this is a bug in my code or because the AI threat algorithm thinks I'm too much of a threat. You can see what I did at the end of the SpawnWave() function
That's the normal waiting logic. Through the eyes of roaming threat ships, the Ark is perceived mainly as "A Big Pile 'O Pain", so they usually won't go after it until they have a fairly sizeable force waiting against it (that can come from multiple different entry points).

If you want something that ignores waiting logic that's doable, it's just something to be deliberate about in the design, because it's basically telling those particular ships to be terminally stupid.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #26 on: November 14, 2017, 07:54:02 PM »
I thought Waves were always intended to be "Periodically the AI sends a kamikaze attack", which is a distinct behaviour from Threat ships (unless you specifically ask for the Waves to join Threat, like with Cross Planet Waves as implemented in AIWC).

So to my mind, anything spawned as a Wave should just kamikaze into defenses. I'd like the AI to have the choice between spawning those waves directly on the planet and spawning them at a nearby warp gate, then sending them to you. But either way, I think they should attack without delay, then press that attack home with some vigor (even if most of them die). One nice thing about this behaviour is sometimes the player overreacts and weakens their defenses elsewhere.

If you have a different conception of what Waves should be then that's fine (you are the Designer of the game, after all).  But I still think my preferred behaviour should be saved as an option, since it's basically what AIWC did.

Edit: there's also a gameplay issue with the Retreat code in LongRangePlanning for the Threat Fleet. When it's choosing to retreat from a planet due to suddenly arrived human reinforcements, it seems to choose an AI planet at random to retreat to. In one example caused the Threat fleet to walk right past my arrived reinforcements and all die, instead of flying directly away from my reinforcements to a wormhole to a different AI planet. I think this code needs to be aware of where the forces on the planet are (or at least privilege the closest wormhole to retreat to, if figuring out where the human forces are in relation to the AI ships is too much effort for now). I opened this as https://bugtracker.arcengames.com/view.php?id=19296 to make sure it's not forgotten; it's one of those little things that makes the AI look smart.

Also, the AI threat fleet has a nasty tendency to camp your wormholes, which makes it in many ways less threatening; you can always provoke a fight and try to whittle it down. I think having it lurk a planet or two away might make it much more scary to deal with.
« Last Edit: November 15, 2017, 12:20:05 AM by BadgerBadger »

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #27 on: November 29, 2017, 08:38:46 PM »
What's the desired behaviour of a wave when there are no warp gates immediately adjoining human space? I don't think my initial implementation handled this case as well as I wanted. I propose to have the wave spawn on the AI Master Controller and join the Threat Fleet (and possibly get something like 5% bonus strength because the AI doesn't like being unable to attack you directly), but I'm open to other suggestions.

Offline keith.lamothe

  • Arcen Games Staff
  • Administrator
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,347
Re: Improving Wave Options
« Reply #28 on: November 29, 2017, 08:51:55 PM »
What's the desired behaviour of a wave when there are no warp gates immediately adjoining human space? I don't think my initial implementation handled this case as well as I wanted. I propose to have the wave spawn on the AI Master Controller and join the Threat Fleet (and possibly get something like 5% bonus strength because the AI doesn't like being unable to attack you directly), but I'm open to other suggestions.
The AIWC behavior was to pick a random warp gate (and iirc it had to be one of the ones closest to human space; so no picking a 3-hopper if there are any 2-hoppers) and spawn it there as threat.

I think that's probably a good behavior to start with, though it's easier to spawn at the MC. I wouldn't assign a strength boost; it's enough of an advantage to the AI that it gets the full "credit" of threat without running it through the human grinder first.

It's ironic, but in many ways the wave mechanic is a situation where the AI periodically gets reinforcements to its threat force, but they always get ambushed by the human's defenses before they can join the main force.

Unless AIP gets really high, or there's a ton of other bad stuff happening to the human at the same time. Then the waves can contribute to a real danger.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Online BadgerBadger

  • Hero Member
  • *****
  • Posts: 693
  • BadgerBadgerBadgerBadger
Re: Improving Wave Options
« Reply #29 on: November 30, 2017, 11:23:03 AM »
How do you feel about allowing humans to cancel an incoming wave by destroying the warp gate that's going to be used, at <some cost>? I feel like it would add a fun sense of agency/strategy, and it always seemed really weird to me in AIWC that destroying the Warp Gate wouldn't stop the wave.

There are a three obvious things the AI can do once a wave is blocked.
One is to try to pick a new suitable warp gate/target.
Another is to spawn the wave as threat.
The third is to "refund" the wave (ie Cancel it, but add its strength to the next wave)

Proposed behaviour:
Humans destroy warp gate AI intends to use for a wave
if Player Has Not Been Warned About Wave
   attempt to pick a new suitable warp gate/target, else spawn wave as threat
       This way a player can't be penalized for interfering with a wave they don't know about

If player has been warned about the wave
    Refund the wave with a 5% strength bonus for interfering with the AI. So you can postpone a wave, but at a cost