PAC maps: theory and practical

[stewbasic]

Regarding the thumbnails, I'd recommend fully zooming in and moving the camera to the bottom of the map (so that the panels are below the map). This also minimizes the text on the spore towers.

I'll include this change in the next version. I assume the thumbnail rendering is otherwise independent of zoom level?

[stdout]

stewbasic, while I have you here, can I ask you a question?

I am currently working on an "epic" map that's gigantic and intended to force the player to have to go around the edges and build up a powerful network of spores and emitters before finally taking the way over-powered central area. My map is basically done and I think it's one of my best, but it is crazy slow. There's so many things going on that even at 4x speed, it is playing at less than real time.

Are there any features that you think I can disable to make it go faster? One thought that I had was to turn off the nullifier building code, but I'm not even sure if that'll make a big difference.

So do you have any ideas of where the actual bottlenecks in the code might be so I can optimize around them?

Edited to add: I changed Abraxis.crpl to only check 1 unit per frame instead of 10 and that seems to have a pretty good impact on speed. I'm not sure if there's anything else I can do.

[Hubs]

Reducing the number of abraxis units could help so the game doesn't have to process as much each frame. So instead of having a field of 40 reactors just put 4 on PZs. Same would go for a bunch of beams: 10 regular could just be 2 or 3 on PZs. the rest of the scripts they don't really do much each frame - just a couple of simple checks. Maybe the Bertha boost could run less often?

[stdout]

Good advice, thanks Hubs!

[Hubs]

Another way you could speed up gameplay is to make emitters product more creeper and the spore towers fire faster. Then give Abraxis some upgrades to fire rate, build speed, and packet speed. Then to make the creeper flow faster use SetCreeperFlowRate and SetCreeperFlowRateOnDigitalis.

[stewbasic]

Mainly reducing the number of Abraxis units as Hubs said. At some point on my first map (when I had ~60% of the map covered by units) I turned off all the scripts and found that an excessive number of units caused a significant slow down without any CRPL (at least on my computer). Figuring out how costly each script is and optimizing is on my TODO list...

[stdout]

Great info. Thanks to you both.

[J]

How about changing the default number of units to check each frame to something like 4? On small maps you don't need each unit to be checked multiple times every second and on big maps 10 might slow it down too much (as any optimisation is helpful).

[stewbasic]

OK, here is the version with multiple unit selection. I took a closer look at how vanilla units behave and tried for more consistency (especially between berthas and spore towers). I think these are all the changes I made:
* Shift+click to add/remove unit to/from selection.
* Double click to select nearby units of same type.
* Drag box to select units in rectangle (hold shift if units are already selected).
* 'O' to expand selection to all units of the same type.
* Setting emitter support or spore tower target deselects unit.
* Rather than cycling, 'E' sets emitter/tower to normal/autotarget, 'R' sets to burst/wait (does not deselect unit).
* 'T' and 'Y' controls removed as they are obviated by 'O'.
* Spore target icon and line mimic berthas with two exceptions:
  - if multiple towers target 1 cell, selecting by target will select all of them instead of just 1 (I think this makes more sense)
  - line to target doesn't show on mouseover (too much trouble)
* Per J's suggestion, activating PAC mode zooms in on the bottom of the map.

I tried to eek out all the corner cases, but please let me know if I missed any and some bug pops up.

[stdout]

Would it work to just copy all the .crpl scripts from this new map over into the scripts directory of the one I was working on? (Tested and the answer seems to be yes.)

I love the new controls. The in-game help needs to be re-written to explain the new controls. This will represent a learning curve to the hundreds of fans of the PAC games. They are used to the old controls. I have a map I want to finish and publish to CS in the next day or so. If you are planning further large changes, though, I'll wait until we have a fairly finished rewrite before I proceed.

[Asbestos]

How do you change the help screen? I can't find it anywhere in the scripts.

[stdout]

The ingame help is in Builder.crpl.

[Hubs]

It's also in DigitalisBuilder and FieldBuilder for those 2 buttons.

Here's my thoughts on controls:

Would it hurt to leave T and Y in? These are super useful and although they would now be redundant I think they would still be faster than the new controls. Plus players are very used to them so it would keep some consistency between old and new PAC maps.

Does it allow selection of emitters and towers at the same time? Sry haven't been able to test the file yet. If so how do controls work then?

Can you still put spore towers in delay mode with the changes to E and R?

For  selection of towers by the target, will it only select the towers that show a red target or any targeting the same cell?

How about making the number of units checked by a abraxis dynamic so that large maps with many units check less units and smaller maps check more? That way map makers don't have to worry about optimization issues.

I like the changes so far! I'm going to hold off on my PAC series until this is done so all the maps can be consistent.

[stewbasic]

Good point about the help text. I'm updating that now.

Would it hurt to leave T and Y in? These are super useful and although they would now be redundant I think they would still be faster than the new controls. Plus players are very used to them so it would keep some consistency between old and new PAC maps.

Secretly I had in mind to free those keys up for some other use :P. Those are good points though... I'll have a go at adding them back.

Edit: What should 'T' do if multiple emitters are selected?

Does it allow selection of emitters and towers at the same time? Sry haven't been able to test the file yet. If so how do controls work then?

Yes. Then 'O' selects all units (same as vanilla). 'E' and 'R' set each tower to its respective mode. Clicking on an emitter will target selected spore towers there and set selected emitters to support. It's also set up to allow more unit types (*cough* runner nest *cough*).

Can you still put spore towers in delay mode with the changes to E and R?

That's what 'R' does.

Speaking of which, there is one thing you could do before which is less convenient now. If you want to synchronize a bunch of spore towers to hit the same spot at the same time, before you could target them all, pause them all, then switch them back to target mode at the right time. Now pausing the tower forgets the target, so you have to select the target again when you want them unpaused. I was thinking about using 'T' for "switch back to target mode, using the last set target".

Another change I was considering (I think someone suggested it a while ago) was to allow spore towers to support each other. Maybe spore health could be proportional to number of supporters, removing the need to synchronize towers. Would that be overpowered?

For  selection of towers by the target, will it only select the towers that show a red target or any targeting the same cell?

This changed a little. A spore tower now always shows its target as long as a target is set (but in autotarget it doesn't set a target until 80% charged). The target is white if the tower is unselected, otherwise red. This is all consistent with how berthas behave.

To answer your question, all towers targeting that cell are selected regardless of their charge amount.

How about making the number of units checked by a abraxis dynamic so that large maps with many units check less units and smaller maps check more? That way map makers don't have to worry about optimization issues.

I'll probably do something like this, but I want to look more closely at where the time is being spent. I suggest not to hold off on a map waiting for this change.

[stdout]

I updated the in-game help in Builder.crpl. The updated file is attached if you want to use it.