Taking the work() out of the Workers

[GoogleCodeExporter]

After moving more and more of the Monster code out of Monster.work and into 
Monster.update and Monster.parse, I'm beginning to think that the .work 
functions in general could be removed.  The thinking is done in .upgrade, and 
the looking is done in .parse.  All that's left that the worker does is equip a 
general (maybe) and then go to a certain page and/or click a button there.

Maybe we could replace the Worker specific work() functions with a generic 
work(general,page,button) function that would do that basic work.

Does that make sense?  Is there something else that work functions do that is 
best done there?

Original issue reported on code.google.com by 0Artifi...@gmail.com on 2 Jan 2011 at 7:11

[GoogleCodeExporter]

Something like that could probably work, but it might be a little more complex 
than calling that work(general, page, button) function once and having the 
magic happen. Between each action parses will happen, updates will happen, and 
the arguments to that work function will change, or the sequence may become 
invalidated before the final action is executed. That work function will have 
to accept those work requests, queue them up, and execute the first step of the 
highest priority request, as per the worker ordering in Queue. Parses happen, 
updates happen, and it repeats until nothing calls that work() method again. 
Then the whole process waits for the next event that causes some worker's 
update() method to want to call that work() again, and the whole cycle repeats.

Likely that generic work method lives in Queue, which knows about the worker 
sequencing. Maybe there is even a priority argument that helps Queue determine 
which task sequences are overall more important than others, above and beyond 
the simple worker order list in Queue. That way if a given worker has something 
really important and/or time sensitive to do (say using at/over cap resources 
before there is resource loss, or collecting hourly income), or it has 
something really low priority and/or slow to do, it can have one preferred 
execution slot in the worker order list, but the list order would simply act as 
the tie breaker on similar priority collisions and not force all priority and 
duration of actions to happen before or after all other workers, simply because 
of a basic preference for Monster before Battle and Quest, Arena before Battle, 
Army before Idle (for the general), etc.

I'm not sure if it would simplify things much if at all, but it would likely 
allow event responses to be a little faster. You'd still need to ensure the 
update() backlog had drained somewhat before allowing Queue to execute any 
actions, to make sure you had enough information available on which workers had 
action sequences to execute or you'd end up with thrashing as the update 
backlog cleared and actions started to undo other actions. Maybe waiting a 
second or so to make a decision on the priority before executing the best 
action step would be sufficient.

Original comment by lur...@hotmail.com on 2 Jan 2011 at 8:58

[GoogleCodeExporter]

On a purely technical note, both parse() and work() (and probably all the other 
"specific" functions) could be folded into update() with different event.type 
values...

But I'm against it:

1. Code readability - even if they were folded in, I'd still be using a 
separate function that update() would be calling, with the number of different 
event types already it's getting towards that.

2. Debug worker - profiling and error() logging both show the functions, and 
folding work() etc into update loses the profiling info and the debugging info 
becomes slightly less useful.

3. Design - currently any system workers that call another worker do so by a 
custom function name, only Worker itself is in charge of the update() function.

4. Most important too really - If there's enough call for it a work-less 
version of Golem then people might not be happy enough with a simple 
"Disable/Remove Queue" version - keeping all work() stuff in that one function 
makes it a lot easier to remove easily. If it is enough, then the profiling 
would prove it's not being called.

I don't have a closed mind here, just give me strong enough arguments why it 
needs to change ;-)

Regarding the Generals while working - got something tickling my brains in how 
to improve it (ie, stop generals thrashing, if all workers that might be doing 
anything before the Idle worker don't want any specific general, then swap back 
to the Idle general immediately and carry on).

Work() is meant to be the simplest function - originally it was called every 
couple of seconds, but if option._sleep is used in update() then it might not 
get called at all (ie, remove the "can I work?" check from work() and put it in 
update()). Only a couple of workers use the new format so far, but there's no 
hurry on it.

Original comment by RycochetTM on 2 Jan 2011 at 1:04

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by RycochetTM on 8 Jan 2011 at 7:08

• Changed state: Discussion

[GoogleCodeExporter]

Due to the changes in CA/FB Golem is going to have to be split into layers, 
work() is going to be on the App layer, so needs to remain.

Saying that - how it's being used could be improved, making sure that as much 
of the processing as possible is removed from it, so it doesn't actually need 
to do much beyond going to pages and clicking buttons...

Original comment by RycochetTM on 1 Jun 2011 at 3:52

• Changed state: WontFix