Each Sector starts with 4 players randomly placed in corner rooms. A large sector is made up of 4 sectors, 16 people.

Can't leave your sector /or enter another( can then use highways still to get around their sector) sector until you are the only one left alive in your sector. Other players who get killed in sectors respawn with other players randomly again( new sector not opened till 16 players are in que so doesn’t give anyone advantage) with now a maybe less dangerous neighbor as all these have been vanquished.

The 'winner' of the sector is now free to invade the other 3 sectors of the big sector, hopefully this will put similar skilled players together after a bit shuffling. This could be done by opening 3 portals in the centre room which leads to other sectors.

4 Big sectors could be combined to then find the winner etc if there's time but not needed as overall winner could be decided by score.

Scoring could be done by holding corner rooms of each sector, maybe having them claimed will allow a ticking score to accumulate. It would be important to then conquer the corner rooms of your sector and then the others as quickly as you could as this will increase your overall score. Corner rooms cannot be occupied, only claimed but maybe you could have some sore of booster building that you fed with a resource to increase base score.

Also best to stay alive in your first sector as you are accumulating score, if you purposefully respawn you could be waiting in a que for a time and not scoring. Others could harass your corner rooms and kill claimer that would stop you accumulating score and would thus need guarding. I would imagine that the rooms bordering the central room with the portal(cant build in portal room) would have defensive measures built ideally to stop others portalling in and rushing to unclaim/claim your corner rooms, lots fights would happen in the centre of the sectors.

I've just started investigating and using paths a bit more in my code to cut down on cpu usage. At present I am auto generating and storing needed/predicted paths in memory once rather that generating paths when they need to get A-B which is still itself still more efficient than creep.moveTo() but not optimal. Issues like you describe I have encountered. In truth not many creeps need to be using the same path as the colony progress's(Maybe haulers/repairers and moving into position creeps) but I'm trying to get everything as fully automated and cpu light as I can from the start even though I think that this issue only really effect the start-up colonies in their initial growth mostly.

I'm NO expert but have a number of workarounds to test.

I plan to give a creep that's harvesting/in-range to a source or travelling a path or in-range to the problem area a memory tag that other creeps could see and know. They could then go elsewhere or stop for a duration/detour if on the path and wait till the other creep drops its memory tag, meaning it's all clear. This might be a little cpu intensive though as each creep will have to either search all creeps memory so this could be bad. Maybe global memory could be used and when each creep on a specific path they could update this with their present movements, meaning path free/not…Cpu testing needed.

….or, and I think might be the best cpu usage…any creep that’s likely to be using that path could have its own memory changed by the creep that’s starting on that path, so the creep only has to check its own memory to see if another has allocated that resource/path for themselves. If this works ok then it might be possible to drop the 'using path tag' prior to actually coming off the path dependant on how far away the other creep is from the problem area. But which creep gets priority then of being the path controller??

I'm sure there's a much more elegant approach someone knows and hopefully will tell