On Wed, 2006-04-05 at 20:29 +0200, Hansenet Mail wrote:
> Hi Rusty,
>
> first of all, thanks for your comments :-)
Hi Yogi,
Thanks for broaching it! I think that without centralized leadership
we need to have more kinds of discussion like this to form consensus and
programming norms.
> Lets make this more concrete: What is the responsibility of the AI code? IMO
> it is doing calculations of battles, identifying strategic points, placing
> the right units there, finding ways to maximize the damage done to the
> opponent. It is not its responsibility to synchronize with other network
> players (playturn.cpp seems to be a much more appropriate place for that).
> We could even argue if recording actions for replays belongs to its
> responsibilities but that would lead us too far away at this point.
>
> If we do not agree on this central paradigm, then it is useless to discuss
> ways to realize such a design. Please, don't take that as being bitter, it
> is not meant that way.
> If on the other hand we do, then we have to think about ways to get there
> and IMO events are one mechanism to accomplish that. If you have a different
> approach i would like to hear it because the current situation is far away
> from being optimal.
>
> One more thing i want to address here: Does the programmer of the ai code
> needs to know what happens when the event fires? I don't think so. He needs
> to know what the purpose of the event is in order to decide when it needs to
> be fired. So i agree with you that maybe renaming it to "fire_network_sync"
> would be better. But you don't actually need to know how this
> synchronization is done. Or how many synchronizations are done.
I wholeheartedly agree with your point about encapsulation, but I think
even this is too little encapsulation in this case. The AI programmer
shouldn't need to know that the network needs syncing: it's completely
independent AFAICT.
But "fire_network_sync" is not an event: you aren't telling the world
you synced the network! If sync_network needs to be called after every
move, recruit or attack, the events would be called
"fire_move_events()", "fire_recruit_events()" and
"fire_attack_events()". I don't know, since I don't know why
sync_network exists. It's an AI-specific thing: we don't do anything
(explicitly) like this after a human or WML event recruits. Why?
> Think of a button in a gui library. It provides a click-event that you can
> attach to. The library programmer has no idea what all those event handlers
> are doing because for the button code it is not important to know. Yes, this
> is a level of indirection and it is the price you have to pay for building
> independent components. IMO this is something desirable because the more
> dependencies there are, the more unexpected side effects we experience.
This problem seems intertwined with the fact that the AI has its own
code to deal with these cases, rather than sharing generic code. That's
bitten us in the past (the AI broke the rules wrt. skirmish and ambush,
for example).
I'm not saying that events are a bad idea: far from. But I don't think
they solve the ugliness of seemingly arbitrary network-related calls in
the middle of AI code.
Hope that clarifies,
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
