Re: scorekeeping and materials

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Sat, 2004-05-08 at 13:42, mskala@ansuz.sooke.bc.ca wrote:

> Ideally, yes.  The combat hit might or might not also result in loss of HP
> to the losing unit (which might then in turn result in it wrecking or
> vanishing), but the main effect would be for some material from the loser
> to be transferred to the winner.  Moe hits Calvin and steals his lunch
> money.

Or Hobbes attacks Moe and retrieves Calvin's lunch money. :-)
The present combat system already allows dice specs to specify damage,
and the dice rolls are 0-based, IIRC. So, if you say:
  (table damage add
    (moe calvin 1d4)
  )
there is a chance that 0 damage will have been done (with 3 HP of damage
being the max), but yet a hit will have been registered.

> If the thing being transferred is a single object (Gollum bites Frodo and
> steals the Ring) then I think I can do it by having the thing be a unit
> and setting up the combat so that it gets captured.  That's less good if
> there are lots of them, though.

I agree. The idea of materials capture is interesting. At some point, I
intend to add defender materials attrition due to attacks (currently,
only the attacker loses material while attacking). It seems that I could
handle your request fairly easily alongside my planned feature addition.

> Well, I might switch to wrecking if that's the best implemented way to do
> it, but the effect I'd prefer is that when you crash a bus through a
> fence, you can still use it afterward, but it doesn't work quite as well,
> and if you do that too many times, it eventually stops running completely.  
> Losing HP seemed like the natural way to do that.  I think if I did it
> with wrecking, I'd have to have five or six levels of "slightly dented
> bus", "bus with lots of broken windows", "bus with exhaust system dragging
> on the ground", on up to "smoking skeleton of bus with one flaming wheel
> rolling slowly away".  That might actually be sort of cool, but it isn't
> what I first thought I wanted.

There is another game under development by one of the Xconq game
developers which handles this exactly as you have stated above. But,
yes, it does lead to a lot more unit types.

> It occurs to me that many of my issues stem from the fact that I'm
> interested in low-level tactical games; attrition due to merely being in
> terrain might be more of a strategic effect ("don't camp your army there,
> the soldiers will get malaria" - duration of exposure is key and movement
> only secondary) and I think Xconq is more intended for strategic-level
> games.

Well, strategy at one scale is tactics at another. I haven't really
viewed it as a strategic focus versus a tactical focus, but you may be
right....

> (*) Falling off cliffs brings up another low-priority "wishlist" type of
> item, because of course you can only do it in one direction, so it would
> presumably require a new kind of terrain subtype, like a border but with
> direction.  Alternatively, it could be tied into elevation somehow,
> although that doesn't address other reasons a directional border might be 
> nice.

Unfortunately, elevation is something that is largely ignored as far as
movement goes. Some of the necessary infrastructure is already there to
handle elevation-related things, but it has not been developed upon
lately.

> I don't have a stack trace; could generate one if you tell me just how to
> do it. 

Depends on the platform. If you are on a Unix-like platform (say Linux),
make sure you have gdb installed. Then run Xconq in gdb, reproduce the
crash, and then do a "bt" at the gdb prompt. That will display a
backtrace of the call stack (the value of which varies somewhat with
where execution was at the time of the crash; if it was doing something
in the Tcl interpreter, then it is not as valuable as if it was doing
something in the Xconq code proper).

>  A file demonstrating the problem is attached to this message; hope
> the mailing list software doesn't mind.  I attempted to make it minimal
> for triggering the problem.  In so doing, I found that the line "(set
> see-terrain-always false)" seems to be a necessary condition for the
> crash, so that might be a clue to what's wrong.  The existence of a border
> terrain type is also necessary - regardless of whether any terrain of that
> type actually exists.

If someone else doesn't beat me to it, I'll take a look at it.

> If I start a game from this file and then try to save, I reliably get the
> message "Warning: Should not be calling xmalloc (requested 34 bytes)  
> This is not fatal, but may cause more serious problems later on.  Do you
> want to continue playing this game?" and assuming I choose "continue"
> that's followed by the same message with 36 bytes, then a segmentation
> fault.  Also, if I load this file and then just play for a while without
> saving, I eventually get "xconq: actions.c:3211: check_change_type_action:
> Assertion `((u3) >= 0 && (u3) < numutypes)' failed. Aborted"

Interesting. Thanks.

> Maybe once I get more familiar with the insides of Xconq... I'm still at
> the stage where I don't know whether "My file doesn't do what I wanted!"
> is caused by my not understanding the intended behaviour of GDL, or Xconq
> not implementing the intended behaviour.

I understand completely. I went through the same thing not so long ago.
This time round, however, I know the kernel code well enough that I am
investigating and fixing anything that I find amiss. I let dodgy game
engine documentation partially derail my first game development effort,
and I'm not going to let it happen again. And, I don't want to see it
derail your effort, so please keep reporting any bugs (or suspected
bugs) that you find.

  Regards,
    Eric