Looks like i'm going to need a function that returns the amount of terrain cells currently covered by creep. Just counting the creep emitters won't work in my case, and checking each cell each time on a big map is going to make it unplayable. Any other ideas?
how about a search algo starting at an emitter for all emitters.
emitter counts 1, then go left right top and down and have a look if there is creep and add 1 if there is one and check again top left right down. etc
A bit better, but there's a problem: how to separate creep which belongs to different emitters?
The idea behind this was to make players spread creep by rewarding them proportionally to the covered area size.
i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
btw sounds interesting will this be a multiplayer map?
>> i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
>> Count it just near active creep emitters.
Let's imagine a player got the idea how the creep is counted. Then he'll just place a lot of tumors in a safe place as close to each other as possible and the balance will be screwed up.
>> btw sounds interesting will this be a multiplayer map?
Hopefully
i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
>> Count it just near active creep emitters.
Let's imagine a player got the idea how the creep is counted. Then he'll just place a lot of tumors in a safe place as close to each other as possible and the balance will be screwed up.
btw sounds interesting will this be a multiplayer map?
Hopefully
i don't get that last part, you would still count the fields and not the number of emitters, stuffing them all at one place wouldn't bring much
Maybe i'm not getting your idea. If I make a loop through all emitters and count their creep, the result will be the same as if I just counted the emitters. To get past this i'll need to prevent one cell from being counted twice, the question is how to do it.
ok you have a unitgroup of all emmitters. then start with emitter 1 and count all connected creep fields. if you meet an emitter, remove it from the unitgroup. go on with the next emitter.
And this way we'll either lose at least a half of creep or get the same result as above, depending on how this loop works (it can copy the unit group or work with the original).
Ok heres an algo i came up with:
1). Take an emitter;
2). Check how many other emitters are in its spreading radius and the distance to them;
3). Use geometry to find the size of the figure made from a chord on which the other emitter lies and the arc of that horde;
4). Deduct it from the emitter's spreading area.
>_<
Problem is - that algo won't work for intersections of more than 2 zones of influence. And it's already too damn complicated to cause lag. #lifeispain
here you are.
Short explanation: it first goes up, checks all fields to the left and right, goes up one more, checks again left and right, so on and on, same with going down.
might not be 100% exact if emitters intersect in a special way, but feel free to change it (means to continue with the search with a offset from the current position if an emitter is removed (tricky stuff and i don't get paid for this here)
btw: i don't think checking 256*256 points for creep will cause any lag. just use a grid and move 1 step starting with (0,0). anyway the attached map should do better.
btw btw your problem is a search problem, you might google for that and find the best algorithm for it
>> btw: i don't think checking 256*256 points for creep will cause any lag.
Maybe it won't, but I'll need some way to store the value for each point. And 256^2 = 65536. That's just crazy. The limit for an array lies much, much lower. That's not how the things should be done.
Oh wait, stupid me. Ofc I don't need to save it... sorry. Just got scared of the number :D
Btw, can't figure out what does the "next" param of "CheckForCreep" function mean?
Looks like i'm going to need a function that returns the amount of terrain cells currently covered by creep. Just counting the creep emitters won't work in my case, and checking each cell each time on a big map is going to make it unplayable. Any other ideas?
@FunBotan: Go
how about a search algo starting at an emitter for all emitters.
emitter counts 1, then go left right top and down and have a look if there is creep and add 1 if there is one and check again top left right down. etc
@FunkyUserName:
A bit better, but there's a problem: how to separate creep which belongs to different emitters?
The idea behind this was to make players spread creep by rewarding them proportionally to the covered area size.
@FunBotan: Go
i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
btw sounds interesting will this be a multiplayer map?
Count it just near active creep emitters.
>> i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
>> Count it just near active creep emitters.
Let's imagine a player got the idea how the creep is counted. Then he'll just place a lot of tumors in a safe place as close to each other as possible and the balance will be screwed up.
>> btw sounds interesting will this be a multiplayer map?
Hopefully
i don't get that last part, you would still count the fields and not the number of emitters, stuffing them all at one place wouldn't bring much
@FunkyUserName:
Maybe i'm not getting your idea. If I make a loop through all emitters and count their creep, the result will be the same as if I just counted the emitters. To get past this i'll need to prevent one cell from being counted twice, the question is how to do it.
@FunBotan: Go
ok you have a unitgroup of all emmitters. then start with emitter 1 and count all connected creep fields. if you meet an emitter, remove it from the unitgroup. go on with the next emitter.
And lets define active creep emitter - emitter, that is currently spreading creep.
@FunkyUserName:
And this way we'll either lose at least a half of creep or get the same result as above, depending on how this loop works (it can copy the unit group or work with the original).
Ok heres an algo i came up with:
1). Take an emitter;
2). Check how many other emitters are in its spreading radius and the distance to them;
3). Use geometry to find the size of the figure made from a chord on which the other emitter lies and the arc of that horde;
4). Deduct it from the emitter's spreading area.
>_<
Problem is - that algo won't work for intersections of more than 2 zones of influence. And it's already too damn complicated to cause lag. #lifeispain
here you are.
Short explanation: it first goes up, checks all fields to the left and right, goes up one more, checks again left and right, so on and on, same with going down. might not be 100% exact if emitters intersect in a special way, but feel free to change it (means to continue with the search with a offset from the current position if an emitter is removed (tricky stuff and i don't get paid for this here)
btw: i don't think checking 256*256 points for creep will cause any lag. just use a grid and move 1 step starting with (0,0). anyway the attached map should do better.
btw btw your problem is a search problem, you might google for that and find the best algorithm for it
>> btw: i don't think checking 256*256 points for creep will cause any lag.
Maybe it won't, but I'll need some way to store the value for each point. And 256^2 = 65536. That's just crazy. The limit for an array lies much, much lower. That's not how the things should be done.
@FunBotan: Go
you never said anything about saving informations about all points (how would you do that anyway)
@FunkyUserName:
Oh wait, stupid me. Ofc I don't need to save it... sorry. Just got scared of the number :D
Btw, can't figure out what does the "next" param of "CheckForCreep" function mean?
@FunBotan: Go
next tells the function what to do, go further up, only left, only right etc.
Hmm, i'm not yet sure how this algo works, but looks like... it really does work. Thanks!