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]

Re: New Action: change-type


>I assumed you were suggesting uu_change_type_into for the
>acp-dependent action model, but perhaps you were suggesting it to
>do what I was proposing uu_auto_change_type for? The only reason I
>picked uu_auto_change_type was to more closely match the
>uu_auto_repair analogue I was partially following.

Correct. I see no problems in principle with multiple choices in the
acp-dependent case. Except, of course, that the corresponding ai code will
be more difficult to write. This is a problem right now, there are too many
features in the game that are not supported in the ai. This might become
another human-player only feature unless we make it easy to handle in the
ai.

>Well I was thinking in terms of the upgrade being triggered
>whenever a certain size or other criteria are met. I did make the
>erroneous assumption that a designer would, say, not pick the same
>size to allow two different upgrade options.

Never underestimate the ability of the game designer to mess up things :-).

>I assume that the auto-change-type mechanism would refer to the
>same criteria tables that the change-type mechanism would use. I
>would agree that multiple upgrade paths do not make much sense in
>the auto-change-type case, but can be perfectly legit in the
>manual change-type case.

Agreed.

>But I would consider a possible auto-downgrade as well, in which
>case you need to have 2 utype entries. Perhaps a whole table is
>not warranted, but it still might be fun to make it weighted and
>leave it as an option.

I'm not sure I follow you here. Why would downgrades require multiple
options? Not that it would be impossible to implement, but I see no
difference in principle between upgrades and downgrades.

>I use the material-to tables in Bellum for several reasons:
>(1) They sometimes result in better user feedback to check the
>material-to prereqs than to check the consumption.
>(2) I seem to remember either reading docs or code to the effect
>that an action can still occur even if there is not enough
>material to consume. This seems wrong, and I can't remember the
>exact source of information. But nonetheless, that impression
>drove me to implement the material-to guards at some point.

I didn't notice you had tried it out. I think the docs are somewhat
misleading. I believe that is why some game designers have used these
tables in the wrong way.

Hans





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]