This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, 10 May 2004, Eric McDonald wrote: > other. The wake conditions included things such as: enemy seen, enemy > encountered, new land, adjacent to land, etc.... The player could even > set these wake conditions on a per unit basis in a running game > instance. In the long term, it would be nice for Xconq to acquire a > similar capability. It does seem like, strictly speaking, the issue I have is something that should be controlled by the *player* rather than the *designer*. What I really want, as a player, is to be able to order a unit "stay sleeping, no, really, until I explicitly wake you". I have attached a patch (against the current CVS) that implements a different approach. I'm not sure that this should actually be used, because it *is* a designer-controlled solution to something that should really be player-controlled, and it's something of a blunt instrument that could likely have unintended consequences. I don't know how expensive it is to add a table; maybe too expensive. However, it seems to work pretty well in my testing, and it's very simple. The patch creates a "can-recursively-wake" UU table of boolean flags defaulting to true. If the flag for u1 u2 is set, that means that a recursive wake on a transport of type u1 can wake an occupant of type u2. If the flag is false, the recursive wake on u1 doesn't propagate into the occupant u2 (nor its occupants, etc.). I say "(table can-recursively-wake (u* cow-patty false))" and get behaviour I like with minimal fuss. One problem, though, is that this shuts down *all* recursive wakes regardless of cause - so the "wake all" user command no longer works. That would be really annoying for the user if the designer's idea of when recursive wakes were appropriate disagreed with the user's. In my particular game I think it should reduce user annoyance by a lot (that's the point of doing it), but it does look like it gives the designer enough rope to hang himself. Also, I wonder if this might have bizarre consequences for the AI. I don't know if the AI pays attention to when units do or don't wake up, but if it does pay attention to that, it could be confused. (Or this flag, judiciously used, could steer the AI to *better* behaviour... hard to predict.) > modifications. Perhaps, only wake occupants, if enemy attacks transport > or if enemy is within move-range of transport? If enemy seen, then do > not wake occupants? I think waking on enemy-seen is usually the right thing to do (of course, the REALLY right thing is to let the user choose), but maybe only the units that actually see the enemy should wake up. I think that occupants are given the opportunity to see enemies (subject to the transport's effect on vision) and so if they want to wake up, they generally can. If the wake on enemy-seen were made non-recursive (by changing the flags on lines 2427 and 2438 of side.c to FALSE, note that those are already commented as being not really the right behaviour), I think that would cause generally nicer behaviour. Maybe a solution better than the one in my patch would be to make *that* a per-unit-type designer-chosen flag - "should units of this type wake their occupants on enemy seen?". A slight drawback is that for my own situation, it's really the occupant type that is special (cow patties should not wake up on transport-sees-enemy regardless of the type of the transport) rather than something special about the transport type. So I'd end up turning the flag on for many transport types and possibly having unintended consequences. Since the user can wake units at any time for free, I think it's okay to not wake all units that the user might want to wake, as long as some unit in the hex gets waked, and the user doesn't generally have to spend a lot of time waking and putting to sleep units that aren't in the state desired. > I think that the usage of 'acp-occupant-effect' could be modified in the > 'compute_acp' function so that a transport's effect on an occupant could > be considered and not just an occ's effect on its transport. The table That might help with loading units (making them stop popping up asking for orders once loaded, because they have no ACP) but how would I unload the units without them having any ACP? -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/
Attachment:
crw.patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |