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

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?

Logged

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

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?

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.

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.

Logged

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

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.

Logged

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

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

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.

Logged

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

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.

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.

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.

Logged

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

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 waveif 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