From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21827 invoked by alias); 5 Jun 2004 13:10:43 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 21818 invoked from network); 5 Jun 2004 13:10:42 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 5 Jun 2004 13:10:42 -0000 Received: from [67.172.156.222] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc12) with SMTP id <2004060513104101400hrs9re>; Sat, 5 Jun 2004 13:10:41 +0000 Subject: Re: Consumption-per-fire? From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com In-Reply-To: References: <20040605033742.12312.qmail@web13123.mail.yahoo.com> <20040605033742.12312.qmail@web13123.mail.yahoo.com> Content-Type: text/plain Message-Id: <1086440869.1485.86.camel@localhost.localdomain> Mime-Version: 1.0 Date: Sat, 05 Jun 2004 13:10:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00474.txt.bz2 On Sat, 2004-06-05 at 02:08, Hans Ronne wrote: > >> I'd think if a designer was defining > >> this table, you'd think the hit-by would default to > >> true (Or 1 or whatever). Why would anyone go through > >> the trouble of defining a consumption-per-fire table > >> and then not want it to apply? > > > >I have thought that 1 would probably be a better default as well. > >However, I did not touch that table when applying the 'hit-by' > >multiplier logic; so, whatever was put in as the default, by whoever > >added that table, is what is still there. > > Defaulting to 1 is OK provided that game designers are aware of the > consequences. You would then have to explicitly disable hit-by for any > units that you don't want to be hit by a particular ammo. I'm not sure if > this is more logical (or less work) than enabling hit-by for units that can > be hit. I guess it comes down to a matter of how often someone is going to work on a game with more than 1 ammo type. In games where only 1 ammo type is available, I think the default of 1 makes much sense, since the designer (particularly a newbie) is probably not going to want to selectively disable it. Only in the (exceptional?) cases where multiple ammo types are used, would a designer generally want to selectively enable ammo on a per target type basis. One thing that I have noticed from working on a simple game (to test wrecking improvements that I made last weekend) is that Xconq tables are generally setup in such a way that if you don't touch them, they will do the most sane and expected thing in light of the designer not explicitly caring about the behaviors they control. I think 'hit-by' should follow that principle. Besides, if a designer wants to use multiple ammo types and selectively enable them (based on target unit type), then it is trivial for him/her to write: (u* m* 0) at the beginning of the 'hit-by' table definition, if we change the default. > >Personally, I think that: > >(a) There should be no built-in range restriction on capture-by-fire. > >Instead, both attack and fire should have enabling tables > >'capture-by-attack' and 'capture-by-fire', plus range restriction tables > >on these types of capture. > > This would certainly work, and somewhat extent the possibilities of game > design. However, I doubt these extra range tables would be of much use. The > reason why I put a range restriction of 1 on capture-by-fire (and I believe > I did that at some point) is that I thought that capture-at-a-distance was > inherently silly. Potential examples of capture at a distance include: (1) Spiderman throwing webs at criminals. (2) Starships firing tractor beams at other starships. (3) Swat teams throwing stun grenades into buildings. > To me, capture implies some kind of direct physical > control, which you cannot exert from a remote position. This also made the > capture-by-fire work the same way as capture-by-attack, which already is > limited to adjacent units by the attack code itself. Ooops. For some reason, I had thought that capture-by-attack was not limited to adjacent cells (if someone was using an 'attack-range' > 1). > >(b) Ammunition should also be able to be selectively consumed by > >attacks. > > It already is. That is what the consumption-per-attack table is for. I forgot that 'hit-by' is also checked in the case of attacks. I just looked at the code, and, yes, you're right. Let's forget about item (b); it's a non-issue. > >As far as failing over to an attack if a unit can no longer fire, this > >sounds like a worthy feature request that could be fairly easily dealt > >with in the attack/fire task logic. > > I'm not sure about this. Many units that can fire are specialized at that > and not very good at melee combat. Forcing them to attack when out of ammo > would therefore be a bad idea. As a game designer, I generally do not even allow firing units to attack the same unit types that they can fire upon. If someone does allow an attack by a firing unit (which can happen easily enough by just ignoring 'fire-hit-chance' and using 'hit-chance' instead), then he/she should suffer the consequences. 'fire-hit-chance' is there for a reason, and if an unit is not intended to attack, then its 'hit-chance' entries should be left at 0%. (Or, better still, its 'acp-to-attack' should be set to 0 against all units.) > Moreover, it's hard enough to get the AI to > use units that can fire properly (that is to fire at a distance and avoid > rushing into combat), as already discussed on this list. I think that I need to do some work with the 'hit-unit' task. The victim finder logic (at the planning level) already makes some decent attempts to determine whether firing or attacking should be used, but I never got around to ensuring that the task code honors such choices. > P.S. As a final note, some of the problems with consumption-per-fire are > due to the fact that you can use the fire-into action to fire at invisible > units. To avoid leaking info about unseen units back to the attacker, > check_fire_into_action therefore calls enough_ammo_to_fire_one_round which > does some kind of general check for ability to fire. However, I'm not sure > that this code, which bypasses the use of the hit-by table, works as > expected in all cases. This concern is sitting in the back of my mind as well. Eric