efficiency of dragon's teeth on biters

[BlakeMW]

Personally I just make a ridiculously long double concrete wall with lasers and the strategies in this thread never crossed my mind. Maybe that's why I'm bad at the tower defense genre.

I do that too when playing normally, though I play Marathon Deathworld, sometimes with enhanced biter settings. Big Biters evolve very quickly relative to your tech level, you probably can get laser turrets before bigs evolve (just barely), but you probably won't be able to mass produce them in time. The most accessible solution for penetrating their physical resist is the flamethrower turret which is available for much less science packs, and a funneling-wall setup allows just 1 Flamethrower turret flanked by a couple of turrets for cleanup to destroy entire swarms, this is a much more cost effective solution for border security than lasers. You also don't even need oil refining to deploy them since you can feed them on just raw crude, or on heavy/light while stockpiling petroleum for later use.

[nevniv]

I tried a Deathworld for the first time a couple of months ago. It did not feel like a Deathworld to me, but I've also got 200-300 hours so I could also build quick enough to defend myself. I had a giant ammo belt around my entire base, probably could have skipped lasers. So tedious though, one day I will go for the flamethrowers...maybe

And if I do a Deathworld again I'll enhance the biters

[cpy]

How about using multithreaded A*?
What about JPS?
Vector field pathfinding?

Man making games is hard and complex!

[ratchetfreak]

How about using multithreaded A*?
What about JPS?
Vector field pathfinding?

Man making games is hard and complex!

Multi threading will jeopardize determinism. Either by changing at which frame the path becomes known or which path from several equal cost paths are taken. Not to mention that multithreading A* isn't trivial. you have to have a synchronized priority queue and most of the processing in A* is actually updating that queue, everything else is very simple math.

If you don't share the open set then you run the risk of repeated work. You can have each thread do batches of nodes at a time explore those and then merge the result back into the global queue and pull out the next batch. Managing the closed list is now suddenly a lot more complicated.

Jump Point searching is orthogonal to that and only affects how the neighbours are generated, it will speed up traveling across open desert but will do nothing for forest navigation.

Vector field requires that you update the entire map (or most of it) whenever the player builds something or pollution updates.

So yeah making games is hard and complex!

[cpy]

I feared that vector field might eat ram like chrome on steroids.
Damn deterministic kraken, screwing up our multiplayer games.

[ratchetfreak]

I feared that vector field might eat ram like chrome on steroids.
Damn deterministic kraken, screwing up our multiplayer games.

Not really it's a float per tile or chunk, noticeable but not all that much, however the entire map needs to be kept up to date which is the true cost of that technique.

[evopwr]

Cant say I ever have a problem with biters, and any improvements in pathfinding wont affect me at all either.
I just use a single concrete wall, and every ~16 tiles I have a flame thrower, and a laser. In addition the entire perimeter has a train track.
So, the entire base is ringed like this, including arms going off to remote resource fields. I never ever have a breach.
(Blueprint ftw)

In addition, every ~50? tiles I have a "smart roboport + train stop". These roboports DONT overlap logistically, but do ensure the entire perimeter wall is covered by construction.
All of these train stops are called "Repair", with a single train and carriage supply ALL of these roboports.
The train stop becomes active when the number of constructions robots <5, or the number of repair packs is <5.

The ensures completely automated repair of the entire perimeter wall - but without having construction bots travelling from the centre of my base to a remote outpost, and getting killed on the way. Instead the bots are localised. This has been the best design out of everything I've tried. IMHO

[sthalik]

What's the max size for getting biters through a 1-tile spacing? 1/2? Note that big biters are too big, but have size of only 4/5ths of a tile. Behemoths are of the same size.

From testing I can already tell you that making biters too big interferes with attacking them on their own territory. They'll get stuck on trees that are easy to pass for a human. OTOH making the bounding boxes very small doesn't solve the problem of more involved labyrinths. It works great for dragon's teeth, they just pass like a human does.

Spitters are different though. They randomly find places outside turret range. At least till the player makes the place full of laser turrets and flamethrowers.

Wish I was able to make a separate collision box for walls and other biters. That doesn't make sense from game perspective though.

[mrvn]

How about using multithreaded A*?
What about JPS?
Vector field pathfinding?

Man making games is hard and complex!

You have 1000 biters. Why use 8 threads for A* for each biter in sequence if you could simply handle ~125 biters per thread?

[bobucles]

How about using multithreaded A*?
What about JPS?
Vector field pathfinding?

Man making games is hard and complex!

You have 1000 biters. Why use 8 threads for A* for each biter in sequence if you could simply handle ~125 biters per thread?

Biters are not a perfectly distributed gas in a spherical sealed container in 0G.

[m44v]

I'm not against any improvements to pathfinding, but do you have any examples of where pathfinding is an issue that doesn't involve cheesy dragon's teeth?

well, trees. It upsets me that bitters are so clumsy in navigating the forests of their native planet. Though you could solve that without resorting to smarter pathfinding: make it so smaller bitters don't collide with trees while bigger bitters would just topple them without stopping like the bloody tanks they are, make it their racial trait.

[Oktokolo]

I normaly don't use dragon's teeth or labyrinths - but i really would expect that to confuse the biters if i would do it. Biters aren't meant to do complex calculations whether their followers would have a less hard time reaching a turret if they would start chewing at the wall in front of them instead of just going around it. And as no biters are comming back - how could the ones following them know, that the path right through that massive concrete wall is faster than going around it?

Pathfinding near walls is okay as it is. It makes sense, that biters try to use gaps in your walls. It also makes sense, that they do not anticipate, that this gaps are better secured than the remainder of the wall.
But maybe, biters could try to avoid passing that huge piles of dead biters that are their comrades from the earlier waves. This would not make them more efficient against a properly defended wall. But they would at some time stop storming the same spot where millions of them died before. Avoiding the known death traps might be implemented with a scent map, where for each N tiles a number is stored that just indicates, how much this group of tiles stinks of death biters. The resulting value is easy to add to tile costs in the pathfinding algorithm. It could also be used to lessen the likelyhood of selection of nearby structures as a target.

P.S.: I dream of biters that flee the battlefield to regroup with reinforcements and try to flank me on my way to a new outpost afterwards - that would be improved biter behaviour...

[mrvn]

I normaly don't use dragon's teeth or labyrinths - but i really would expect that to confuse the biters if i would do it. Biters aren't meant to do complex calculations whether their followers would have a less hard time reaching a turret if they would start chewing at the wall in front of them instead of just going around it. And as no biters are comming back - how could the ones following them know, that the path right through that massive concrete wall is faster than going around it?

Pathfinding near walls is okay as it is. It makes sense, that biters try to use gaps in your walls. It also makes sense, that they do not anticipate, that this gaps are better secured than the remainder of the wall.
But maybe, biters could try to avoid passing that huge piles of dead biters that are their comrades from the earlier waves. This would not make them more efficient against a properly defended wall. But they would at some time stop storming the same spot where millions of them died before. Avoiding the known death traps might be implemented with a scent map, where for each N tiles a number is stored that just indicates, how much this group of tiles stinks of death biters. The resulting value is easy to add to tile costs in the pathfinding algorithm. It could also be used to lessen the likelyhood of selection of nearby structures as a target.

P.S.: I dream of biters that flee the battlefield to regroup with reinforcements and try to flank me on my way to a new outpost afterwards - that would be improved biter behaviour...

Having them chew on anything within reach when being stuck behind another alien should clean up dragon teeth over time and should be easy to implement.