Construction Overwork

Feature Requests have moved to http://glob2.uservoice.com
This section is read only for reference.
Locked
Cchampion
Worker
Worker
Posts: 15
Joined: Wed Jul 19, 2006 7:21 am

Construction Overwork

Post by Cchampion » Wed Jul 19, 2006 7:37 am

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

User avatar
Giszmo
Warrior
Warrior
Posts: 261
Joined: Sat Nov 26, 2005 10:23 pm
Location: Germany
Contact:

Post by Giszmo » Wed Jul 19, 2006 10:13 am

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.

Cchampion
Worker
Worker
Posts: 15
Joined: Wed Jul 19, 2006 7:21 am

Post by Cchampion » Wed Jul 19, 2006 4:53 pm

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.

Elvish Pillager
Warrior
Warrior
Posts: 55
Joined: Thu Dec 22, 2005 11:39 pm

Post by Elvish Pillager » Wed Jul 19, 2006 4:55 pm

Yes, we always appreciate algorithm improvements; have a look at the code and you'll see what we have to deal with. :P
To feed good generals, you need good food. To grow good food, you need good pastures. To capture good pastures, you need good generals.

User avatar
Giszmo
Warrior
Warrior
Posts: 261
Joined: Sat Nov 26, 2005 10:23 pm
Location: Germany
Contact:

Post by Giszmo » Wed Jul 19, 2006 11:05 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.

Cchampion
Worker
Worker
Posts: 15
Joined: Wed Jul 19, 2006 7:21 am

Post by Cchampion » Thu Jul 20, 2006 6:55 pm

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?

User avatar
Giszmo
Warrior
Warrior
Posts: 261
Joined: Sat Nov 26, 2005 10:23 pm
Location: Germany
Contact:

Post by Giszmo » Thu Jul 20, 2006 11:12 pm

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.

Cchampion
Worker
Worker
Posts: 15
Joined: Wed Jul 19, 2006 7:21 am

Post by Cchampion » Sat Jul 22, 2006 5:52 am

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. :)

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.

User avatar
Giszmo
Warrior
Warrior
Posts: 261
Joined: Sat Nov 26, 2005 10:23 pm
Location: Germany
Contact:

Post by Giszmo » Sat Jul 22, 2006 12:09 pm

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:

Code: Select all

54321W1234
5432111234
5432222234
4433333334
4333333333
3222222222
2211111111
111wwwwwww
wwwwwwwwww
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

Cchampion
Worker
Worker
Posts: 15
Joined: Wed Jul 19, 2006 7:21 am

Post by Cchampion » Sat Jul 22, 2006 11:55 pm

So you are telling me the wavefront algorithm is generating the glob's path on the fly, instead of pre-planning it? Hmm...

In that case, reserving the resources ahead of time is definitely not plausible...

TRRRombone
Posts: 1
Joined: Mon Sep 18, 2006 4:37 am

Post by TRRRombone » Mon Sep 18, 2006 4:41 am

Each glob must know which resource is its ultimate target, however. Because it can draw a line to it.

Also, map.cpp is hurting my head.

User avatar
Giszmo
Warrior
Warrior
Posts: 261
Joined: Sat Nov 26, 2005 10:23 pm
Location: Germany
Contact:

Post by Giszmo » Mon Sep 18, 2006 9:43 am

Hi TRRRombone

Actually this line is hacked into the GUI rather than anything accurate. In high traffic situations globs normally end at different places than the line was pointing to originally.

Greetings, Giszmo

MrLenin
Posts: 1
Joined: Mon Jan 22, 2007 5:52 pm

Post by MrLenin » Mon Jan 22, 2007 6:37 pm

Not so easy to investigate, yeh?

Locked