Daimonin MMORPG
Project => Daimonin project => Suggestions => Topic started by: Anchakor on 29, July 2007, 16:33:07
-
Split from here (http://www.daimonin.net/index.php?name=PNphpBB2&file=viewtopic&t=5568) -- Smacky
I though it would be like this:
(http://img504.imageshack.us/img504/8540/questguiay5.jpg)
In case of the accept/decline for example when taking quest accept would be num 7 and decline num 9...
It would be definitely faster than tab+enter+chars
Imagine binding /talk to 0 on numpad and you could do talking in game with other hand free to eat pizza/drink coffee whatever... :)
Also it would be better if hypertext was not used as it is... so instead of highlited Jahrlen in block of text a "[1] Who is Jahrlen?" on the end would be better... also this would mean players not jumping on other topics during conversation...
Definitely it would be nice if home and end keys worked in the conversation window...
And sorry I didnt have time to check out SENTInce yet, because Im not mapmaking yet... :)
EDIT: since this was split from the original topic I have to point to my previous post as a reference:
http://www.daimonin.net/index.php?name=PNphpBB2&file=viewtopic&p=55206#55206
http://www.daimonin.net/index.php?name=PNphpBB2&file=viewtopic&p=55260#55260
-
Hmm, maby. but pizza/coffee? Bad combo.
Well heres my thoughts...
A'ccept/D'ecline
Talking about : Accept; Talking about : Decline
Click Accept/Decline
Hit 1 for Accept, 2 for Decline
-
Gotta say that's horrible. :P
But practically it's problematic too. The numbering you have takes up 4 characters. Space is a valuable commodity in an interface. Links do not wrap so you have one line to play with (what's that? about 40-50 chars in this font?) and buttons are even worse, where the limit is 10 or 11.
Now I could maybe accept hardcoding (in the client) 1-9 (or maybe just KP1-KP9) to automatically select the first 9 links and, say, - and + (or KP- and KP+) to do the buttons. But this would not be visually represented. The interface would look just the same as it does now but there'd be these extra shortcuts for ingame snackers. :)
Home and end don't work? No, they don't. I agree, they should.
Also it would be better if hypertext was not used as it is... so instead of highlited Jahrlen in block of text a "[1] Who is Jahrlen?" on the end would be better... also this would mean players not jumping on other topics during conversation...
I disagree completely here. The current system (in-text keywords) works well as long as the scripter takes a little care in how he places his keywords and a sensible conversation navigation system is used so you can return easily from tangents (both things are sorted by SENTInce). IMO a general Back button is not the way to do it which is why SENTInce uses an action button.
-
Now I could maybe accept hardcoding (in the client) 1-9 (or maybe just KP1-KP9) to automatically select the first 9 links and, say, - and + (or KP- and KP+) to do the buttons. But this would not be visually represented. The interface would look just the same as it does now but there'd be these extra shortcuts for ingame snackers. Smile
Thats all I want :)
@Hypertext:
I have played for a long time a game which used similar system like here, well it was even more hypertext-like... Im talking about TES3: Morrowind, and I must say that the hypertext pretty much screwed the dialogs... It from talking it made broswing... hypertext just takes away what I find important - feeling of real conversation... with hypertext it isnt possible to have more ways of saying one thing - each time with different emotion... I like how for example Black Isle games did it...
maybe hypertext looks elegant... but not from a storytelling, atmosphere point of view...
-
hypertext just takes away what I find important - feeling of real conversation...
LOL That's exactly my feeling about a list of links at the end of a dialog.
Although there is a place for links, just as there is a place for hypertext. It's when you rely on one or other too much that you run into problems.
This 'feeling of real conversation' is a big reason why SENTInce emphasises typing more than current interfaces (well, at all would be more :)) -- although you can point and click as well.
-
Smacky:
LMAO Feeling of conversation IMHO partly relies on option to say one thing in different way - with different emotion. So for example this:
Sorry, but you cant go further. My boss would tear me apart if I let you [looks intimidated]
1. Ok, no probelem [you walk away]
2. But I have talk to your boss! Its urgent!
3. [surely] I have a meeting with your boss, so get out of way. [lie]
4. [furiously] Get out of way or it will be ME who will be tearing you apart!
There is no way you could do this with hypertext... it would be like:
Sorry, but you cant [link]go further[/link]. My boss would tear me apart if I let you [looks intimidated]
1. [end conversation]
-
Yes. This is the Monkey Island approach (although you can argue it ultimately comes from CYOA books).
The problem (not a major major problem admittedly) with transferring this approach to a MMORPG is that the scripter should avoid putting words into the player's mouth -- that's one thing where the player takes on the specific persona of Guybrush Threepwood but another where the character's persona is up to the player (ie, the RP bit (I say should because there's a balance between freedom of expression and story).
So yes, that's an option in specific circumstances, but should not be considered the way. And no, hypertext can't do it, only links (or free typing) can -- that's no reason to get rid of hypertext. Just use the appropriate method for the specific situation.
-
I saw that approach used in games where it was up to you to decide what type of character your avatar was... this is not only matter of adventures where you usually have characterized avatar...
Of course there is no way you would be able to make all options available like in real conversation, but I think its more of a step forward than backward...
I am not saying we should get rid of hypertext... I just think it has more potential to suck you into the story and makes the conversation more human-like - less formal. I am rather convincing scripters to use this approach...
-
Now I could maybe accept hardcoding (in the client) 1-9 (or maybe just KP1-KP9) to automatically select the first 9 links and, say, - and + (or KP- and KP+) to do the buttons. But this would not be visually represented. The interface would look just the same as it does now but there'd be these extra shortcuts for ingame snackers. Smile
Thats all I want :)
OK, I just had a quick look at the client source. I'm tired now, but I'll patch it Iand post diffs to devlist) either tomoorow evening or the next day.
It looks as if this wouldn't cause conflict (either doing the main keys or the KP keys or both) because while the initial character of either button is always uppercased (if a letter) and emphasised (interface.c), only the letter keys are actually checked for being pressed (event.c). So perhaps also interface.c should be patched to not emphasise non-letter buttons (and the ib docs should inform scripters not to use non-letters, if they don't already). Anyway, - and + hardcoded to the buttons should be an easy patch to event.c and 1-9 hardcoded to the first 9 links should also be an easy patch to event.c. I can't immediately think of any drawbacks.
-
Patches posted to devlist. The email should be archived here (http://sourceforge.net/mailarchive/forum.php?forum_name=daimonin-devel&max_rows=25&style=ultimate&viewmonth=200708) soon enough.
-
My comment in Skype: would it be more intuitive to have KP+ mean accept and KP- decline, rather than the other way around?
-
Aww, you got my hopes up posting to the SENTInce thread. Anyway I moved your post here but to really confuse people I've added some client changes, including this one, to SENTInce. Heh heh, soon no-one will have the faintest idea what I'm doing. :twisted:
Anyway, I thought so too, but unfortunately - is on the left and + on the right on the main keyboard. My thought was that it would be confusing to swap the keys round on the keypad.
-
Smacky: My original idea was that the controls would be all on numpad for reasons I already stated... so - and + as yes and no is not ideal :) now thinking of it wouldnt 0 as yes and . as no be better?
-
I put it on the main keyb as well as it seems to me it's better to have a convenience, well, as convenient as possible. For example people with laptops don't really have numpads so shortcuts accessible from the main keyb makes sense.
Given that, it also makes sense to keep the shortcuts grouped near each other and bearing some relation to their function.
1-9, minus, and plus are all on the top row. 1-9 are numbered (that's their relationship), and minus and plus are related by their sidedness.
All these keys translate to the KP too, with a minor problem in that minus and plus are now vertically arranged.
Hm, I'll add KP0 and KP. as alternatives to KP- and KP+, not replacements. Best of both worlds.
-
yeah thats really good... laptop users definitely shouldnt be overlooked...
I will rebuild my client soon...
will it work OK on both servers with the SENTInce patches?
-
I'm pretty sure the SENTInce stuff won't make any difference, except that you'll get the full benefit of SENTInce scripts (on test) and a few conveniences, like these shortcuts. That's a big goal of SENTInce, backwards compatibility. So any problems can be reported (here or SENTInce thread) as bugs and I'll fix them quickly.
EDIT: KP0/KP. as alts to KP-/KP+ added.
-
Would these shortcuts be available to change to whatever you want (F11?), similar to movement/commands. I use 1-9 as my misc. macros, and play on a laptop, so I have no numpad :D
-
No, they're hardcoded. To make them bindable would involve making some new commands. A much bigger change than is warranted.
OTOH these shortcuts will only work while an NPC GUI is open (but not while the textfield is open) and keybinding will not work while an NPC GUI is open. So there is no conflict.
Specifically, for you 1-9 in an NPC GUI will select the links and not shout a macro, while 1-9 during gameplay will shout a macro.
-
oh good, ty :)
excuse the nooby question on my part as a lack of knowledge as to how these things work ;)
You said that EDIT: KP0/KP. as alts to KP-/KP+ added.
Does this mean that we choose which one we want to use, or that either work?
-
EDIT: KP0/KP. as alts to KP-/KP+ added.
Does this mean that we choose which one we want to use, or that either work?
Either/both (that should annoy Grommit, whichever is correct :twisted:) work.
-
You know smacky, i'm still not sure why this would annoy grommit, because both, i mean, either would be correct, as seen in the multitude of examples i've graciously provided...
:: pokes grommit ::
on the other hand, i have played many games, and it seems like alot of them have the space bar as a general "accept" command, and if all there is is a "escape" or "close" or "back" command remaining (no accept option) then the space bar does that job. I think that would be nice, but you might have some trouble implementing that.
Just my input =)
-
The 'trouble' with that, sensible as it is, is that by convention accept is the lhs button and decline is the rhs button. But SENTInce has a thing called the action button. This is the RHS button with the LHS button always being 'Goodbye'.
So SENTInce is at fault?
No. this apparent inconsistency is because of the clients failsafe behaviour. The client can display 0, 1, or 2 buttons. If only 1 it will always be the LHS button.
This is why SENTInce makes the LHS button the 'Goodbye' button (and therefore why the RHS button must be the action button).
A while ago I was convinced (by Grommit no less) that it is always (except where we have Accept/Decline) necessary to show a Goodbye button (apparently no self respecting mouse jockey would be caught dead pressing ESCAPE).
Given that it is only sensible to have Goodbye in a consistent place -- which must be the LHS.
So therefore SPACE = LHS button would mean it is sometimes Accept but usually Goodbye which are conceptually opposite. This is not a problem when the keys have a sidedness relationship to the buttons (ie, - and =) but it a problem when the relationship is to do with the nominal 'meaning' of the key.