[CF-Devel] Scripting and such.

[Tom Barnes-Lawrence]

(Pretty stupid of me, main reason I joined the list was to try to
voice my own POVs on future CF ideas... and then I do something
else for a few days, V1 comes out, and I miss most of this
discussion :P
As my inbox is now bursting with new mail, I'm leaving the list
for at least a few days, so please CC any replies to me if poss)

Proposed change:NPC communication/scripting,+general scripting,
Details:
  RIGHT. When people have been talking about scripting, they
have been talking (1) about scripting map effects (haven't they?)
and (2) about improving the way NPC's talk.
Many people have said about using Guile or similar. I think
Scheme is a neat language for doing scripting, and makes much sense
in something like Gimp... but IMHO is waaaay overkill for CF.
So, I propose:
For NPC's, a variation on what there already is, but with
improvements to suit requirements (that I've seen at least), with
inspiration from Flex (which I enjoy mucking about with, it's neat..)
OLD NPC MESSAGE FORMAT:
   @trigger-word|alt-trigger-word
   NPC text
   @other-trigger-words
   other NPC text
....

NEW FUNKY NPC MESSAGE FORMAT:

(requirements line)    @NPC-STATES:[CONNECT]|trigger-word|alt-trigger
(optional effects line)>NEW-NPC-STATE [EFFECT]
(then NPC text, followed by other messages, as above)
....
EFFECT is either a number to represent a connection to push,
or ANGRY,CALM,SLEEP,CHARM,RETURN, which affect the NPC.
Trigger-words are all LOWER case.Anything NPC hears from player
is converted to lower case to avoid stupid stuff like
@hi|Hi|HI
  hello
@hI
  Ah, you know the password!
and so on.

Example of new style NPC message follows:
@INIT:hi|hello
>
     
     MET
     
     Hello there!
@INIT:*
>
     
     MET
     
     Sorry, I didn't notice you there. What were you saying again?
@!INIT:hi|hello
Yes, hello, I can hear you, you know.
Are you a bit slow or something?
@MET:door
>
     
     OPEN [2]
     
     Oh right, you want to go through?
OK, sorry-here you go.
@OPEN:door
It's open already!!!
@MET|OPEN:how are you
Well, thanks.
@*:[3]
>
     
     ANGRY [ANGRY]
     
     Hey, what're you doing with that lever???
@*:You suck
>
     
     ANGRY [ANGRY]
     
     I'll kick your arse!!

(NB-INIT is the state the NPC starts off with when player meets them.
states like ANGRY should be set by the NPC becoming hostile.
!INIT means any-state-but-INIT, if it's not clear.)


You get the idea.
If player charm's NPC, then (1)any connects that NPC has in message
script are removed; (2)NPC enters state PET. (3) effect [RETURN]
becomes valid, and causes the NPC to return to player-like the
stuff in crossfire.doc said would be done (but AFAIK never was).
The entry "NEW-NPC-STATE" can also have a value ".", meaning
keep the current state. That is only necessary if there is also
an [EFFECT] tag, so you then have >. [EFFECT]
rather than >[EFFECT]  -Insisting on a new-state entry should
make the parser a tiny bit faster and simpler(perhaps).
...
The fact that the NPC would now contain code for magic-ear and
mood floors *doesn't* make those obsolete, they still have uses.
But this opens up various funky possibilities.
Full scripting could prolly add more stuff, like NPC following
you to a specific different map, then after 10 seconds stopping
there... But I expect this format could prolly be expanded to do
most of those sort of things, or they could be done as it is, with
map-side machinery (more of which later...)

Pro's:It's dead good. It's pretty simple, and could be done with a
straight-forward lexer,IMO.It can do lots of stuff.
Con's:Each NPC needs to maintain state info for each player.
(each one it meets, anyway-shouldn't actually be big problem)
Allowing NPCs to trigger stuff and be triggered like that could
make for nasty code.
Issues arise if NPC becomes follower and so moves to different map.
------

As for the other aspects of scripting:


Proposed Change:More machinery (related to above)
Details:
  Many of the things that you could want scripts for could IMO
be done with better machinery types to put in the maps.
(1)Counter tile: Has fields:
Input-connection, Reset-at-count, Trigger-at-count,
Output-connection, Count (Internal)
Count starts at 0.
When Input-connection is triggered, if Count equals Reset-at-count,
reset Count to 0 again-otherwise, Count increments by 1.
If Count now equals Trigger-at-count, push Output-connection
(Trigger version should exist, plus button version that releases
when count moves on).
(There may be a better variation of that. I considered one that
could trigger at 2 points, but that could be done with 2 counters).
Actually, Something similar to this could be implemented with a
creator and an altar-trigger, but I think it could *only* reset
when it triggers.
(2)AND gate:Fields:Input-1, Input-2, Connected.
Self explanatory. I've had difficulty working out how to do a
useful AND-you can make various bad ones right now.
(3)Persistent connections:
Hard to explain.One of my maps, I tried to get it such that if
you pulled a lever, it registered on a unique item square before
activating what it did, and when the map reset later, the connect
would be repushed, as though that lever had just been pushed. It
didn't work. I tried this:
  Tile 1:                 Tile 2:
Creator:connect 1
Button: connect 2       Spikes:Connect 2
Floor: unique           Floor: not unique
..
So when you push connect 1, an object (in my case, a card), is placed
on the button, which pushes connect 2 and raises the spikes.
As the floor is unique, the card is still there when the map
reloads, but the button does not raise the spikes. I would find
this feature useful.
(4)Game-wide states variables
Think of a type like a cross between magic-mouth and marker,
but when you trigger it with a connection, it writes a global
variable (I *don't* mean an internal variable), that then can
trigger other types, that trigger or switch on/off connections.
Each would have fields: Connection, Variable,
var-writer and var-trigger would have State field,
(for var-writer, this is what it sets Variable to when it is
triggered. for var-trigger, this is the state of Variable that
triggers it)
var-switch would have State-on and State-off field.
(IE-var switch stays unset till it sees State-on in variable,
then set till it sees State-off.).
var-toggle could be a further option.
Variable names should be LONG to avoid namespace problems.
I could do lots with such a feature, eg-the main city I'm
working on is at war with another. At certain times an invasion
could occur, and it would effect any number of maps
simultaneously. This feature coupled with the proposals I made
for simple NPC scripting could do a lot of neat stuff.
Actually, this would be able to implement request (3) above.
Hurrah!
(5) New button type(s)
Detects living creature. Also, buttons can't detect players or
monsters that fly/levitate/jump over them. Does this include
setting fly-on/fly-off on them? I've tried to stick a button
*and* a pedestal(to detect players) on the same tile on one of
my maps, and it screws up, because it pushes items off the square,
then doesn't realise they're gone.
(6) Triggerable markers
Just like normal marker objects here, but mark a player when
they are triggered rather than when the player stands on them
for a length of time. Obviously, if no player, no marking. VERY
useful, messy to implement other ways.
(7) Separate magic-whisper and magic-shout
(or a flag on current magic-mouth)
If you trigger a magic-mouth that you're not standing on, you
can hear it no-matter where you are on the map. I've not found
if this is the case if someone *is* standing on the tile when
it is triggered.
Sometimes, it is necessary/useful/neater to be able to have a
magic-mouth that can be triggered, but only heard by a player
that is on it or next to it. Maybe just on it, in fact.
So lets say a flag on magic-mouth that enables that behaviour
as an alternative, if there isn't one already.
(I realise that there is already the walk-on behaviour when
that flag is on. Is that heard by others too?)
----
Pros: Maps could be soooo much better... I could get some of my
stuff done faster, not trying to figure out how to do complicated
stuff.
Cons: Some may be messy or difficult, or slow stuff down, or
maybe just unnecessary/already doable some other way.


--------------
Before I go, On stuff said recently:
(1)-I came to CF from the roguelike games, which I still like.
CF came pretty much from roguelike origins, and I'm not a fan
of moving it far from those. I like Iso graphics quite a lot,
but I don't much want to see them in CF. If that sounds odd,
then: I like ice-cream, I also like pepper. But not together.
Having said that, those actual-iso style tiles MichT linked
to a few days ago looked pretty good. But I'm still sure
there are other issues with rotating the view, like others said.

(2) I don't like the idea of pandering to people who won't
look twice at a game if it doesn't look amazingly slick. If
I'm ever going to play on a server with lots of people on it,
I'd rather it wasn't just people like that. I don't much want
in game movies or music, I'd rather stick a CD on. But better
sound in general would be good.Perhaps using MIDI for handling
multiple sounds instead of music, could that work???

(3) In a recent post, Mark said CF was a fast action game, but
I still see it more as a multiplayer RPG with roguelike bits.
As an actual *action* game, it doesn't compare too well to
something like XKobo, which excels at that- raw action and numb
fingers (by stage 42). I like doing stupid RPing things in CF,
like my ninja character pushing the priestess of gaea and then
running off and hiding... where else could you get such
deep fulfillment? ;) Anyway, *very* fast action makes little
sense on nasty slow internet-you can screw up too easily that
way.

(4)Unrelated:Death attacks with a slaying field- I'd assumed these
were like specialised deathstrikes, ie-they wouldn't hurt anything
else, but would be very deadly to whatever they slay. Looking
at the code, it is simply a normal death-attack to what they are
slaying. Adding a slaying field to such an attack (weapon or spell)
actually makes it purely weaker, and not stronger in any way.
IMHO, the slaying in deathstrikes should do something like
increase the effective level of the attacker, or otherwise allow
an attacker some chance to kill the specified creature that is
higher level.
(5)On subject of deathstrikes (should be new post, but too late),
ninjas should have skill "assasinate", a deathstrike that can be
used if player is hidden or target is unagressive/asleep. Not
implemented as a combat skill (IE, you can't select it then run at
someone), but attacks target with AT_DEATH, once. More appropriate
for a ninja than stealing.
----
RIGHT, THATS IT FOR NOW-I'm leaving the list for a bit, I'll
prolly work on my mapset, may do more on the random-quest-maps
proposal and eventually post that, but till then, BYE.
Tomble (Sorry it's such big post)
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
     
     http://www.hotmail.com.