Enhanced Completed-Occ Functionality
Brought to you by:
elijah_meeks,
matthewskala
Menu
▾
▴
#129 Enhanced Completed-Occ Functionality
open
nobody
3
2005-06-19
2005-06-15
No
For complete and incomplete occupants it would be
useful if:
They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.
The specific occupants being built affect the cost of
the transport being built. In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.
Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself. This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.
Logged In: YES
user_id=1158352
I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.
I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....
Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.
As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)
Logged In: YES
user_id=1158352
It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....
I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.
Logged In: YES
user_id=1158352
OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.
As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.
Logged In: YES
user_id=586338
As I see it, there are two different situations that would
need to be covered here:
1) The total cost of a unit being produced from the
standpoint of a modern game. It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles. It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.
2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games. You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields. But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).
I think the solution is rather simple, though I might have
missed something:
Always charge for any occupant units on the
occs-on-completion table. This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).
On the other hand, alt-occs-on-completion are free. Since
it's perfectly reasonable to have:
(table alt-occs-on-completion
(hover-tank heavy-laser 1)
)
A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.
Logged In: YES
user_id=1158352
I originally suggested occs-on-completion to FOS in the
Xconq.org fora to address the issue of not saddling the
player with the burden of filling out a transport with occs
(I had SF Battles construction in mind) and because I
thought that was what he was getting at anyway. It turned
out that he had some other possibly fancier ideas he was
thinking about. I still haven't heard what those ideas are,
but no matter.... The main reason I chose to service this
feature request was to allow automatic implicit creation of
occs upon the completion of an unit. This is is essentially
addressed (and it is the second situation which you mention
below).
However, what we need to think about now is the first
situation that you mention. Handling this had not been part
of my original idea or implementation plan. Indeed, it is
going to prove somewhat interesting to handle, if we choose
to handle it.
To reiterate something I said earlier, we need to decide
WHEN is the best time to charge for the occs. One
possibility is to integrate the cost into the per-build cost
while the transport is being built. This increases the
compelxity of the construction logic, and must be a
predetermined cost. Being a predetermined cost is both a
plus and a minus. It is a plus because a straightforward
answer can be given about how much it will cost to build
something. It is a minus because it cannot account for
variable numbers of occs being created on completion.
The other possibility is to add a completion barrier
(perhaps in the form of a 'complete' action). This would
prevent an unit from being complete until its number of
occs-on-completion is determined and fully paid for. This is
a plus because it accounts for variable numbers of occs on
completion. It is a minus because you will not know how much
something will cost until it is about to be completed;
additionally, this may cause some concern about whether
completion could ever actually occur, if the determined
number of occs could not be paid for.
This is the dilemma I was hinting at in my earlier post to
this tracker thread.
Logged In: YES
user_id=586338
My understanding was that completed-occs-on-completion was a
straight value and not a dice roll. If it's subject to
random amounts, then my solution wouldn't work so well,
though I still like it for its simplicity. If
completed-occs-on-completion was charged to the cost of the
transport, it would be transport-cost plus all available
occupants (Meaning no occupants that are off-limits due to
obsolesence or not having the current advance). In the case
of multiple occupants, it could be the cost of the average
number of occupants (So, assuming an archer starts with 2d6
arrows, you're charged for the archer plus 7 arrows).
With alt-completed-occs-on-completion available, then a
designer such as myself, who wanted to have units built for
just the cost of the unit and not charged for occupants, I
could set it up in the alt- tables. I would then use
completed-occs-on-completion for a game like Cast Iron Life
(Wherein I wanted to simulate the cost of equiping units)
and alt-completed-occs-on-completion for SF Battles (Where I
just want to charge for a ship, even if later I want to give
the player the ability to build individual systems).
Logged In: YES
user_id=1158352
Well, the 'alt-*-occs-on-completion' tables certainly cause
the dilemma, but so do the "non-alternate" tables, even
though it is less severe. '*-occs-on-completion' tables are
not straight integers; they can have a fractional
probability for one additional unit. 4.45 means 4 guaranteed
units and a 45% chance of a 5th unit.
Logged In: YES
user_id=586338
I'd be willing to write this off to designer responsibility.
If they know how these tables work, they'll simply need to
write the tables accordingly. In the case of the additional
unit in the completed-occs-on-completion table--in a
situation where the designer charges a
consumption-on-completion cost for the occupant in
question--I'd say charge them for it if it's created and if
the builder can't afford the full cost but can afford the
base cost, then give them only the base amount. In other
words, if you've got:
completed-occs-on-completion
soldier grenades 4.45
And
consumption-on-creation
soldier dinero 100
grenade dinero 5
And your builder has 120 dinero, then it can build the
soldier and if the probability indicates 5 grenades instead
of 4, then tough luck, your soldier only gets 4 because
that's all you can afford. Alternately, the additional
possible occupant could be free. Either way, you're simply
placing the burden of game balance on the designer, which is
perfectly acceptable.
Logged In: YES
user_id=1158352
I've been thinking more about when to charge for
occs-on-completion. There is too much state that must be
preserved if charging is done on a per-build basis. I think
that the charging for occs-on-completion must be done during
completion. I also think that the only occs-on-completion
that one gets are the ones that can be paid for. If one asks
for 4.45 grenades, and only can pay for 3, then that is all
that are gained. Similarly, if one asks for 4d10+5 arrows on
completion of an archer, is determined to get 35, and can
only pay for 20, then 20 is all that one gets with the archer.
I also think that charging for occs should NOT be the
default behavior of the regular or the supplemental
complete-occs-on-completion table. To enable charging, I
think one will need to set a new boolean TableUU,
'charge-for-occs-on-completion', which has a default value
of false.