[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[palito-dev] repair/resources
From: |
zed |
Subject: |
[palito-dev] repair/resources |
Date: |
Thu, 06 Mar 2003 15:36:57 -0200 |
the barrett's approach
barrett were uneasy with the way a unit would use
the values of energy and metal it were used on
its build to allow it to have its hitpoints repaired.
his initial idea were that the repairer would give
N% of the energy necessary to build the unit to repair
N% of the hitpoints, but the unit is composed of metal
either. and how would be measured the resistence, and
repair cost, of a wall that holds no energy.
to repair a wall would be instantaneous in this case.
how to measure the metal expend and the energy expend
on damage, therefore, necessary to repair? how much metal
stays when the unit is wrecked? how much a unit explodes
when damaged badly, and there least a wreckage in this case?
no hitpoints
i figured that the hitpoints were a conflicting information
with what we already had: metal and energy.
then i tried to define something that would create some ties
on the whole world structure and the use of the resources.
the problems of what i did:
* the unit designer must figure the energy/metal expent on
construction to fit the his ideas of resistance and action.
* there should be less variations on the unit types, less
possibility of game unbalance, since there is a very strict
basement on the creation of all units. (like there were
no different technologies on how to use the metal to
make shields to the unit, no way to expend more energy
at build to make it more resistent with less metal, but
it can be fixed with a per unit metal_armor_protection,
but i prefer to keep it uniform, and so the game balance)
* there is no support to more than 2 resources types,
this method is strongly tied to the energy/metal duality.
(but barrett already gave up on the N-resource approach)
metal as an armor
the energy should represent the functionalities of the unity,
something like the entropy of the unit, and the metal should work
as an armor to keep the inner "energy-structures" safe.
this way, a hit would have to pass the metal to reach the energy
interior (metal_armor_protection), and little by little the metal
protection would wear out (external_armor_decay).
it should work just like quake armor, what makes
the destruction non-linear, and this is cool.
but, the armor thing were not enough to fulfill the condition
of a wall being cheap and strong (the example proposed were:
a tank e2000/m100 would be destroyed berofe a wall e0/m50),
and to prevent incoherences, like a unit existing without metal.
2 new concepts
to explain how the tank would be destroyed first i made
a kind of internal damage, the more energy the unit have
the more it decay the armor when hit (internal_metal_decay),
that should get rid of the tank's metal armor much faster
than the wall, and represents the weakness of the internal
structure of the tank compared to the wall.
if the energy hits zero before the metal, the unit stop
working at all, it means there is no more functional structures
inside the unit, its just a lump of metal. but what if the
metal gets to zero before the energy? to avoid this energy-
-unit problem i made another constant, so if energy/metal ratio
is bigger than energy_metal_stability the unit explodes,
causing its atual energy of blast damage, including to the metal
that leasts on itself (this probably will let no wreckage left).
representation
without hitpoints we should display under the unit the energy
and metal expend on its construction, may be a bar of fixed size
with a most intense (saturated) color for bigger amounts.
(it can also show the unit's action battery, should be cool)
anyway, the energy/metal instability should be displayed by
a waving glow of green around the unit; and the lack of energy
would be displayed graying it out, like a wreckage.
less arbitrary states to define things
wreckage is a no-energy structure, it cannot be selected
cos' it cant perform any function. but it can be reconstructed
by the appropriate constructors. (the less % of energy,
the less % of functionalities, also: movement, rate of fire)
building is characterized by the energy/metal instability glow,
of course the constructors must respect this limit so the unit
dont explode during construction, and the unit must stay still
while being built, even after receiving some functionality...
(this is not a problem, because the unit should stay still while
being repaired, so this should be a nice code to the unit anyway)
barrett's comment on how badly damage a unit can be reconstructed
may depend on the constructor type, seems very interesting...
i think a unit, even after completely halt may be put back to work,
like a car that you send to the mechanic and it get moving again.
but after some damage may be impossible for a constructor to restore
the unit, but possible to other more advanced constructor.
this may, appropriatelly, explain why a low-level constructor,
cant make a high-level construction from scratch.
simulations
http://zed.9hells.org/temp/palito/
this one http://zed.9hells.org/temp/palito/damage.sim2.txt
shows a very interesting result, on the first simulation,
the shot-10 exploded the tank, while the 100/1000 let wreckage.
interesting the weaker shot cause an explosion after a long time
and the stronger one wrecked it soon, with no energy-explosion.
i liked this result...
this one http://zed.9hells.org/temp/palito/damage.sim1.txt
we have more examples of wrecking and explosions.
the simulations show the constants on the top and each line is
a round of shot-damage inflict on both units: tank and wall.
[shot-damage] <unit> <energy>e(<energy-dam>) <metal>m(<metal-dam>)
'blow releasing 1000 energy', means that there were and explosion;
'blow releasing 0 energy', means that the unit vanished quietly.
conclusion
barrett should be much more uneasy now, i'm afraid.
sorry. i'm only sharing my visions, pick what seems useful.
just thought that a world coherence like that would be nice
to make all things more balanced, but i cant grantee it is
the ideal parameters, all must be tested in-game.
- [palito-dev] repair/resources,
zed <=