Construction Overwork
Construction Overwork
I just gave Glob2 a shot, and am actually quite pleased. The open-source community is actively working on a worthwhile RTS. WOOT!!!
I have one quick suggestion. If it seems to gain any momentum, I might even take a look at Glob's source and see if I can implement it myself (alas, us highschool kids get real bored during summer Very Happy).
Here it is: When you are working on a construction project, you can end up with more globs working on it than resources you need. This seems silly, as one or more of them are wasting their time. It seems more sensible to have the game decide that if only x resources are required, it will only allow x workers to be assigned to the project, thus freeing up an extra glob or two for other tasks.
It may seem minor, but I think its a worthwhile change to throw in. Any opinions? Suggestions?
The only problem I foresee is that the globs that get de-assigned as more resources are accumulated will be the ones that are almost back, thus wasting time and resources. I suppose it would have to search for globs who aren't carrying anything to find out which one should be ditched, eh? Ideally, it would eliminate the one that dropped off the resource that removed the need for a worker, but I'm not sure how difficult that would be to implement in the code.
Cheers all!
Chris
I have one quick suggestion. If it seems to gain any momentum, I might even take a look at Glob's source and see if I can implement it myself (alas, us highschool kids get real bored during summer Very Happy).
Here it is: When you are working on a construction project, you can end up with more globs working on it than resources you need. This seems silly, as one or more of them are wasting their time. It seems more sensible to have the game decide that if only x resources are required, it will only allow x workers to be assigned to the project, thus freeing up an extra glob or two for other tasks.
It may seem minor, but I think its a worthwhile change to throw in. Any opinions? Suggestions?
The only problem I foresee is that the globs that get de-assigned as more resources are accumulated will be the ones that are almost back, thus wasting time and resources. I suppose it would have to search for globs who aren't carrying anything to find out which one should be ditched, eh? Ideally, it would eliminate the one that dropped off the resource that removed the need for a worker, but I'm not sure how difficult that would be to implement in the code.
Cheers all!
Chris
actually that is wanted behaviour. the limit now is [ressources needed]x2 and i guess that makes sence as globs get hungry at work, get hurt and have to do vital suply-jobs (towers, inns, swarms and later maybe market).
but you are warmly welcome to contribute anyways ;)
if there's a better estimator for the success of eyh suply-action this factor 2 could maybe pushed towards 1.2 or so.
but you are warmly welcome to contribute anyways ;)
if there's a better estimator for the success of eyh suply-action this factor 2 could maybe pushed towards 1.2 or so.
Maybe the system should estimate whether or not the glob will be able to make it to the construction site with the resources before it sets out each time. It would be pretty simple to have a formula that calculates how much food it will have left when it makes it back (i'm assuming the code for finding the paths is already in place). If it discovers that it will be below the constant for hunger, it will move on to another quicker job or just go eat.
-
- Warrior
- Posts: 55
- Joined: Thu Dec 22, 2005 11:39 pm
when the glob takes the job it knows how far it is to the wood. it does not know if it will turn hungry walking there because it has no traffic radio. it also doesn't know how far it is to the construction site afterwards. at this point pathfinding is greedy. go to closest wood first. then go to the building. there's no minimization of the overall path. that would be a major change in the code as wavefront is not what helps finding A-B-C paths.
However, even without a minimized A-B-C path, you can still predict what the pathfinder is going to do. All I'm saying is you can use the total distance it will have to travel, calculate how much food it will have at the end, compare it to the (hunger constant)*(fudge factor for any complications on the way). Right?
within the wave front system you know distances from every spot to for example closest wheat. but you don't know where that closest wheat would be and if it still will be there when you reach it.
so as long as there is no one-way automatism in place like i proposed at http://globulation2.org/wiki/Wishlist#I ... athfinding you can estimate the distance A-B-C by taking the upper boundary [2AB+AC] plus some 20% for traffic and if that results in a distance you wouldn't be able to do due to hungryness, you could still calculate the distance the way you proposed it. but that still doesn't guarantee that B will be at where you first ended up when messuring the distance.
so as long as there is no one-way automatism in place like i proposed at http://globulation2.org/wiki/Wishlist#I ... athfinding you can estimate the distance A-B-C by taking the upper boundary [2AB+AC] plus some 20% for traffic and if that results in a distance you wouldn't be able to do due to hungryness, you could still calculate the distance the way you proposed it. but that still doesn't guarantee that B will be at where you first ended up when messuring the distance.
I like your ideas on the pathfinding. I've found I just wall off all the one-way areas in my base to stop all the massive traffic jams/starving globs. On anther note, maybe we should fix the whole bit about B not being there anymore. Here's the idea:
Add a flag to each unit of resource (an integer, for resources that have more than one unit per square). This way, workers can make sure that the resource they want is not taken by another glob. We would have to make sure that they do get desassigned properly though, or bad things could happen.![Smile :)](./images/smilies/icon_smile.gif)
In the ressource.h file, all that would need to be done is declare a new Uint8 called amountreserved or something like that. As far as the modifications to unit.cpp, I'm trying to understand the handleActivity subroutine. Hahaha.
Add a flag to each unit of resource (an integer, for resources that have more than one unit per square). This way, workers can make sure that the resource they want is not taken by another glob. We would have to make sure that they do get desassigned properly though, or bad things could happen.
![Smile :)](./images/smilies/icon_smile.gif)
In the ressource.h file, all that would need to be done is declare a new Uint8 called amountreserved or something like that. As far as the modifications to unit.cpp, I'm trying to understand the handleActivity subroutine. Hahaha.
it's not as easy as that. in the wavefront-algo globs are navigating to wheat by walking down on a globally defined mountain whereas water-level is wheat by definition. little example:
So in order to have your algo implemented we would not need 8bit per wheat (what would be bad enough). We would need [map width]x[map height]x8bit more as we'd need an individual heightmap per piece of wheat.
some proposed to use 16bit instead of 8 bit in this wavefront and even that is too much for others. but i guess it will be done sooner or later as 8bit means that targets further away than 255 steps can never be reached. On maps 512x512 that can be a problem as soon as units are able to not starve on such a distance.
But keep asking ;)
Leo Wandersleb
Code: Select all
54321W1234
5432111234
5432222234
4433333334
4333333333
3222222222
2211111111
111wwwwwww
wwwwwwwwww
some proposed to use 16bit instead of 8 bit in this wavefront and even that is too much for others. but i guess it will be done sooner or later as 8bit means that targets further away than 255 steps can never be reached. On maps 512x512 that can be a problem as soon as units are able to not starve on such a distance.
But keep asking ;)
Leo Wandersleb
-
- Posts: 1
- Joined: Mon Sep 18, 2006 4:37 am