We need to think of criteria to look for when searching for bottlenecks. Here are some thoughts, please add your own:
-A "bottleneck" should be defined as a line with two sectors of open terrain on both sides. The line's endpoints must be impassible terrain. Should we require the terrain on one side to be bigger than the other (be funnel-shaped)?
-Should we limit the number of bottlenecks we can have in close proximity to each other? If so, based on what?
-Should there be boundaries (lower and/or upper limits) on the size of bottlenecks?
-Should we implement some kind of system to "rank" bottlenecks? How do we determine what makes one bottleneck "good" while another one "bad"?
I think we should attempt at making a bottle neck point based off of Distance between, what impassible is it (I believe 1/2, not sure if that makes much of a difference) OR how much of it is there, like a 4x4 block of a crater or a 2x9 block of a cliff-side. Along with weather or not there is a LEDGE above it. That way it might be able to double defend against the ledge.
...Not what I meant ECC. I was asking him about this:QuoteI think we should attempt at making a bottle neck point based off of Distance between, what impassible is it (I believe 1/2, not sure if that makes much of a difference) OR how much of it is there, like a 4x4 block of a crater or a 2x9 block of a cliff-side. Along with weather or not there is a LEDGE above it. That way it might be able to double defend against the ledge.
Now I'm defending using this by, A human would know that terrain is imassible, not nesicarily what TYPE the mapper uses, but they would know "cliff" from "crater" by looking at them.That's pretty much the only way we can do it, yeah.
For the distance between, if there is a HUGE gap between impassible tiles, ignore it.In most cases this is what we'll want to do, but if there are no other alternatives the AI needs to know where to draw the line and bunker down.
I can see this scenario clearly on something like the first mission form both story lines. That is a HUGE area, but the bottleneck would be pointless to defend, and It wouldn't even (most likely) get attacked through it! There are other maps, but that was just the first to came to mind, disregarding size restrictions here.QuoteFor the distance between, if there is a HUGE gap between impassible tiles, ignore it.In most cases this is what we'll want to do, but if there are no other alternatives the AI needs to know where to draw the line and bunker down.
I do have a quick question about flood-fill. When you say "search by similar passability" you mean simply "passable/impassable", right?Right.
Okay, time to split up and get to work.I COULD get to working on a maze map to test path finding WHEN you guys get to that point. other then that though and im useless
Who's willing to actually contribute?
Who's doing what?
I'll pick from whatever is left over.
Okay TH300. We won't go by deadlines, as long as people don't take that as an excuse to slack off. You're in charge of the Dijkstra pathfinding. This is supposed to find the "real" distance between points on the map AND figure out which parts of the map are unreachable, right?It will certainly do that. And it can possibly be extended to do more, like location of bottlenecks, base locations etc. For base locations I have an idea already (which is similar to what Hooman described), for bottlenecks I have no idea, yet.
ECC you better be ready :Psorry, but im having a lot of trouble in that area, so i'll list my ideas here. argue as you see fit
Since ECC is bailing, help JCJ.no, my time is limited again. i cant believe when i was IN school i had more time.... such cruel irony.
That's a bad idea, since there's nothing forcing the level designer to pay attention to that option's setting.Like in my current edit (not distributed, as its kinda buggy) of the 2 player map. I have disasters weather they are on or not, but then I have MORE if they ARE on.
That's a bad idea, since there's nothing forcing the level designer to pay attention to that option's setting.That is true. Nontheless I believe that knowledge of whether and when lava occurs on the map can be a huge advantage. We should add some interface to the ai api that allows the mission designer to make the ai aware of this.
Don't expect to get a rectangular spot for your base. Expect other shapes. Don't do exact calculations. They're too time consuming. Count the number of passable tiles and expect that they have a shape that supports a base (not taking into account terrain formations for defense). I might add a function for this or part of it to the pathfinding class that I am writing.well i expect that, but i want the bare minim, cause i know that all playable maps have a possibility of expansion. i assume that a functioning base(one that can survive without further reaserch) is a CC, SF, CS, 2 agris, nursery, university, VF, 2 tokimacks, 1 mine, 1 cargo truck, and 1 convec.
numbers, no.... but i can probably(mind you, i've got more important tasks at hand) get you some rough estimates based upon a couple of my modded maps and teks.
Edit: another question that I almost forgot: does someone have a list of movement speeds on different celltypes? Or know where to find those values in the exe or sheets or maps? I did measurements for some, but its too boring.
does someone have a list of movement speeds on different celltypes? Or know where to find those values in the exe or sheets or maps?
The costs used in the algorithm match the number of ticks that it actually takes a unit to move along the calculated paths. That means, vehicle turns are included in the calculations.Second one, not so much, but DEFINATELY day night... I'd hate to have something think that because this is CLOSER to a mining beacon, its faster, but I don't have a light beacon near or around one of the specific paths, making it actually slower to use for attacking/ mining/
Still missing:
- considering day/night for calculations
- doing everything for not a single vehicle, but for a group of (probably different) vehicles
- considering damage (this will clearly only change the outcome if more than one vehicle is moving)
Not sure if I'll ever find it necessary to add all of those.
// Extended map tile used in GetTileEx / SetTileEx
struct MapTile
{
unsigned int cellType :5; // Cell type of this tile
unsigned int tileIndex :11; // Mapping index (tile graphics to use)
unsigned int unitIndex :11; // Index of unit on this tile
unsigned int lava :1; // true if lava is on the tile
unsigned int lavaPossible :1; // true if lava can flow on the tile
unsigned int expand :1; // true if microbe is expanding to this tile
unsigned int microbe :1; // true if microbe is on the tile
unsigned int wallOrBuilding :1; // true if a wall or building is on the tile
};
Edit: Also, I remember something about blight growth always being affected by day/night, even if it's not enabled. That was a little strange.Yes... I remember this to..