15 Apr, 2009, Tyche wrote in the 21st comment:
Votes: 0
Scandum said:
KaVir said:
alias knee: strike bubba @ lunges forward and drives his knee into your groin

You'd need a true false syntax in case the attack misses:

alias knee: strike bubba @ lunges forward and drives his knee into your groin|lunges forward and drives his knee upward toward your groin

And probably some syntactical sugar so the engine knows how to parse the message properly.


It's a nice idea, but assuming a non-rp hns environment, I was thinking I might falsify the messages:
alias knee: strike bubba @ smiles and waves happily at you
15 Apr, 2009, Scandum wrote in the 22nd comment:
Votes: 0
Tyche said:
It's a nice idea, but assuming a non-rp hns environment, I was thinking I might falsify the messages:
alias knee: strike bubba @ smiles and waves happily at you

For a h&s mud I think a double dragons simulator would work best.

http://www.youtube.com/watch?v=S0-2xhQAO...

Movement and positioning is the biggest problem, but this could be solved by taking aspects from streetfighter.
15 Apr, 2009, Tyche wrote in the 23rd comment:
Votes: 0
Scandum said:
Movement and positioning is the biggest problem, but this could be solved by taking aspects from streetfighter.


Well that's a whole 'nother thread. ;-)

I'd point out that an interesting alternative approach taken on mushes where users can build their own attributes, commands and functions to do fancy emoting, chain of commands or descriptions on themselves.

I pulled the following off a WORA post. It's sets up one's description to randomly change over time like if one were playing a changeling.
Quote
&FN-DESC-CHANGE me=[if(gte(timefmt($M),add(v(CURR-DESC-TICK),%1)),u(DO-DESC-CHANGE,%0),v(CURR-DESC-%0))]
&DO-DESC-CHANGE me=[pickrand(v(DATA-LIST-%0),|)]
@adesc me=@desc me=His hair is [u(FN-DESC-CHANGE,HAIR,15], his eyes are [u(FN-DESC=CHANGE,EYES,10)] above a nose that is [u(FN-DESC-CHANGE,NOSE,15)] and a mouth that is [u(FN-DESC-CHANGE,MOUTH,5)];&CURR-DESC-TICK me=[timefmt($M)]
&DATA-LIST-HAIR me=black|red|blonde|brown
&DATA-LIST-EYES me=blue|grey|brown|green|hazel
&DATA-LIST-NOSE me=straight|crooked
&DATA-LIST-MOUTH me=thin|full


I think that dynamic description techniques like these ought to be available to players as well as builders. The only problem I see is it is not necessarily philosophically compatible with HnS game designs as messages for actions are hardcoded and players overriding them would be considered spoofing.
15 Apr, 2009, Idealiad wrote in the 24th comment:
Votes: 0
I could see a place for player-controlled dynamic descriptions in the context of fighting or spellcasting styles. A player could design a custom fighting style for their character that included not only the game actions, like slashing or lunging, but the adjectives and exclamations they would make while doing so. It might get a little silly but it basically would be a combat emote style system mixed with a semi-diegetic command system.
15 Apr, 2009, David Haley wrote in the 25th comment:
Votes: 0
Well, the main problem is, as several of us have mentioned, that the opponents really, really need to know what actually happened in this kind of combat scenario. So although it might be nice to have customization, how do you prevent somebody from emoting a kick as a sword swing? I could imagine something like this:

[Grey] Ragnar lunges at you, shouting a battle-cry and swinging his battle-axe!
[White] Ragnar attacks you with his battle-axe.

Somewhat unwieldy (no pun intended) but, well, it would work. (Assuming people have color-enabled clients, and can actually see said colors.)
You could optionally disable the custom messages if you didn't feel like seeing them, or you could disable the standard messages if you generally trust people to say the right things.
15 Apr, 2009, Tyche wrote in the 26th comment:
Votes: 0
David Haley said:
Quote
emote hands *sword to >petite, hilt first.
The short, auburn-haired lass hands your long sword to the petite, raven-haired lass, hilt first.

Hey, that's kind of cool. Is that actually encoding some kind of command in the emote so that the emote causes something to happen?

Iota said:
Yeah, you can do several things with a combination of tokens, like picking stuff up or dropping it, taking/putting stuff into containers, giving stuff to people, or looking at objects/people.

The MUD I'm writing a knock-off of lets you do those things with "pre-emotes" and "post-emotes" that add emotes onto the normal, fixed echo of certain commands.


Does anyone find the 'give' command a problem? What if you don't want the item?
Anyone consider implementing an offer/accept/refuse protocol instead like the emote above implies?
15 Apr, 2009, Scandum wrote in the 27th comment:
Votes: 0
Tyche said:
The only problem I see is it is not necessarily philosophically compatible with HnS game designs as messages for actions are hardcoded and players overriding them would be considered spoofing.

I'd say it's not compatible with "game" design in general. While interesting as a programming challenge I think it would be an utter failure as a game concept.


Tyche said:
Does anyone find the 'give' command a problem? What if you don't want the item?
Anyone consider implementing an offer/accept/refuse protocol instead like the emote above implies?

I've seen a couple of MUDs do this, most notably WoW.
15 Apr, 2009, David Haley wrote in the 28th comment:
Votes: 0
Scandum said:
I'd say it's not compatible with "game" design in general. While interesting as a programming challenge I think it would be an utter failure as a game concept.

It would work very well in pure-RP environments where combat is cooperative to begin with. In this sense, there is no notion of "spoofing" in the first place – what people see is what actually "happened" as far as the players are concerned.
15 Apr, 2009, KaVir wrote in the 29th comment:
Votes: 0
Grimble said:
I like the idea, but isn't there still the problem of needing text for each grammatical person?

I already support that with my emote command. It's not 100% perfect, but it's close enough for my purposes - and on the rare occasions where it messes up the grammar, it only does so for the player who performs the emote.

Note that I start the emote (from the emoter's perspective) with "Your character", so "get" vs "gets" isn't an issue.

Scandum said:
You'd need a true false syntax in case the attack misses:

True, unless you just had a generic boring "You miss" message. Another option would be to rule that the combat messages shouldn't mention impact - so you could describe throwing a punch at someone, and the mud would then add another line indicating whether or not your blow connected (much like David Haley's Ragnar example).

Tyche said:
It's a nice idea, but assuming a non-rp hns environment, I was thinking I might falsify the messages:
alias knee: strike bubba @ smiles and waves happily at you

Well yes, I was really thinking of the sort of RP-heavy environment where you get beaten with a stick for bad roleplaying. However you could do a less freeform version in a HnS game, by allowing players to create their own combat aliases with custom messages - but require an admin to approve the messages before the aliases function.

I use something similar for clan names. A clan founder can set a name for their clan, but it's not visible until an admin has authorised it - and authorising it locks it, so they can't change it again. The 'authorise' command without arguments lists all pending clan names, so that admin can see at a glance if any need authorisation.

Obviously people don't set a clan name very often, so I'm not sure how well the concept would scale, but perhaps you could cut down the workload by allowing players to exchange custom combat aliases with each other. Maybe it could even be expanded into some sort of teacher/student training system.

Tyche said:
Does anyone find the 'give' command a problem? What if you don't want the item? Anyone consider implementing an offer/accept/refuse protocol instead like the emote above implies?

Yes, I have an "accept" command which you can use if someone offers to give you something (although you can also choose to always autoaccept, via a config option). I also have "sell" and "buy" commands which work much the same way. There is no explicit "refuse", instead the offer runs out after 30 seconds.
15 Apr, 2009, elanthis wrote in the 30th comment:
Votes: 0
Tyche said:
Does anyone find the 'give' command a problem? What if you don't want the item? Anyone consider implementing an offer/accept/refuse protocol instead like the emote above implies?


Ayup. It's been in other MUDs before, too. Basic idea is to give both parties a list of offers, and both parties must accept. Any change in offer resets the accept state for both players. e.g.

# say I'll give you this sword and a dagger for 500 silver falcons and a healing drought
You say, "I'll give you this sword and a dagger for 500 silver falcons and a healing drought."
# trade Tyche sword
You offer your longsword to Tyche.
#
Tyche offers you 500 silver falcons. Type 'accept' to accept the exchange or 'trade' to see the terms.
# trade tyche dagger
You offer your dagger to Tyche.
# trade
You are bartering with Tyche. You will give him your longsword and your dagger. He will give you 500 silver falcons.
# accept
You agree to the exchange with Tyche. Tyche must now accept the exchange.
# trade kavir magic cape
You are currently bartering with Tyche. Type 'decline' to exit negotiations before bartering with another person.
#
Tyche says, "Oh, I better not forget the healing drought!"
#
Tyche offers you 500 silver falcons and his healing drought. The terms of exchange have changed. Type 'accept' to accept the exchange or 'trade' to see the terms.
#
Tyche agrees to the exchange. Type 'accept' to accept the exchange or 'trade' to see the terms.
# accept
You and Tyche agree to the exchange.
You give him your longsword and your dagger. He gives you 500 silver falcons and his healing drought.

KaVir said:
Yes, I have an "accept" command which you can use if someone offers to give you something (although you can also choose to always autoaccept, via a config option). I also have "sell" and "buy" commands which work much the same way. There is no explicit "refuse", instead the offer runs out after 30 seconds.


Out of curiosity, what happens if two people offer you something at the same time?

If the most recent offer supercedes older ones, players could accidentally accept the wrong item if someone offers them a different item just before accepting. If you only allow a single offer at a time (like the trade stuff above) then an annoying play could spam the give command and lock the target player from receiving anything without some kind of timeout on declines or a way to autodecline trades with a single player. Or you need to trade offers from multiple other players and allow the receiving player to specify which he is accepting.

I'm not sure what the best approach is for solving that, so any thoughts on the matter would be appreciated. :)
16 Apr, 2009, KaVir wrote in the 31st comment:
Votes: 0
elanthis said:
Out of curiosity, what happens if two people offer you something at the same time?

It doesn't matter, as the offer is stored on the item itself. Player X could offer you a sword and a dagger, player Y could offer you a chainmail shirt and player Z could offer you five separate potions, and you could accept any or all of them (as long as you did so within 30 seconds of the offer being made).

There's also a 'view' command which allows you to see the item's stats before you accept or buy it.

elanthis said:
If the most recent offer supercedes older ones, players could accidentally accept the wrong item if someone offers them a different item just before accepting.

Yes, I had that exact problem. As a result you can now no longer accept an offer within 3 seconds of it being made.
20.0/31