In my original conception for having dialogue with the NPCs in my RPG:

There are two reavers - one scrolls through dialogue options, and the other confirms it (technically the latter could be replaced with something besides a reaver). When a player walks up to an NPC, a death counter is set to signify what conversation the player is in (each possible conversation would need it's own ID number). The player then builds a scarab in the first reaver, which will display the player's first response to the NPC; when the game detects the scarab, it then adds 1 to a different death counter (this death counter is used to prevent the message from being spammed). The player can continue building scarabs and seeing more responses until it reaches the end of the list, at which point the scarab count and the death counter is set back to 0. When the player finds a choice they are satisfied with, they build a scarab in the second reaver, and then the scarabs and death counters are cleared (and the NPC responds to what the player had said, possibly initiating a new conversation).

Pros: Takes up very little space.
The reavers can be hotkeyed, so that players can use them without having to move their screen.
Would be relatively unique and draw attention to the map.

Cons: Tedious for me to implement and may be difficult for the average b.net user to understand.
Requires that I make scarabs free.
Max of 8 response choices (will likely not be an issue).
Requires a death counter to keep track of it that I could be using for something else.
Scarabs seem to be only removable with the "Remove All" action ("Remove unit at location" doesn't work for some odd reason), which could interfere with any reavers the player may have in the playable areas.
Players have to scroll through each option to get to more choices (may annoy players who've gone through the conversation before).



I was originally going to go with this system, but due to the amount of negatives, I'm considering going with something a bit more conventional:

There is a unit (preferably a ground unit) in an isolated area. When a player initiates a conversation with an NPC, a death counter is set to a certain number to identify which conversation the player is in, just like in the above system. However, instead of scrolling through the response choices, the player simply moves the unit to a location to view various responses, and to choose one, kills a neutral unit at the location (which then respawns). (Essentially, this is like the shop interface in the map Astrogears, where a player moves their ghost to view item descriptions and prices, and kills a lurker to make a purchase.)

Pros: Much easier for me to implement than the previous system, and more likely to be understood by players.
Allows veteran players to choose their response immediately without having to scroll through each choice until they get to the one they want.

Cons: Would require more space than the reaver system, especially if each player had their own area for the purpose.
If the players all shared the response choosing area, then there would be a risk of players mistakenly having a response selected for them if their kill score matched whatever the kill score value of the neutral unit was (if each player had their own area, one could simply detect when the neutral unit was missing from the location).
Players would have to move their screen to the area to respond to an NPC.



Which system do you guys think is better?

You could accomplish the Reaver system with a building like a Barracks. Build a Firebat/Ghost to cycle through options (F and G are right next to each other, so it works nicely), and make another unit to confirm.

Another silly option would be to have the player hotkey several units, and then use EUD selection detection to check when they select a unit. In this system, you can put up a list of say 5 responses in a numbered list, and the player just presses the number they want to respond with. Since selection detection is shared, this would still work in a multi-player map, but it works almost as fluidly as key press detection. The drawback is getting the player to do all those hotkeys, and that it uses up hotkeys.

As far as the two options you provided go, I would favor the shop interface method.

I would go with the second. Building stuff out of 2 reavers for talking only is to much and I don't like cycling...

The thing about the Barracks method is that I'd have to make units available for production in barracks (which I probably won't do in case I have the player receive them at some point for a different purpose), and I'd have to make the ghosts and firebats free.
Besides that, that actually is a rather good idea... much better than the reaver idea, at any rate.


I think I'm going to go with the second system I described. I think I can compact it reasonably well so that making it for four players, and giving each 8 different responses maximum (probably more than I'll ever use), only takes about four times the amount of space the reaver method would take up.

Spiffy. Now maybe if I'm lucky, this will be the one I'm motivated to finish, just in time for the year-long RPG contest . (Even if not, I'll still have the best Open RPG around .)


EDIT: I has another idea, similar to #2:
Instead of having a unit move and kill for selection, what if I had a dark archon use mind control and feedback (one to view a response and the other to choose it)? It would be even better because the unit wouldn't have to move! The only drawback I can think of is that I would likely not be able to have player-owned dark archons elsewhere in the map, since being able to mind control other player's heroes would be rigged and possibly hard to prevent...

EDIT2: Er, in order to prevent the necessity of using 32 locations (one for each conversation option, of which there are eight per player), I'm making the units to be killed owned by all four neutral players and using different units, so that each player's area has a zergling for p9, p10, p11, and p12, as well as an scv for p9, p10, p11, and p12. I has a noob question: Will bring conditions work with these players? (That is, if I have a condition that says something like "Player 9 brings at most 0 zerglings to location," will it run or not?)
EDIT3: Gah, now that I think about it, I'll still need to use the locations for viewing the responses and making the units respawn... oh wells...
EDIT4: Actually, now that I think about it for another couple of seconds, I realize that I can center a location on the player's unit in the area, and detect what the neutral players bring in that location. Now I just need to solve the respawning problem... maybe if I had a burrowed defiler under each one, and cycled through them to check if the unit was missing, and replace it if it was...

Post has been edited 4 time(s), last time on Jul 30 2011, 3:55 am by Jesusfreak.

Why not use EUDs?

Hm...the reaver system seems better to me. A few improvements you can make:

- Instead of a second reaver to confirm the selection, just let the player move the reaver to confirm their selection.
- You can also replace the reaver system with a dropship system:
+ Give a dropship loaded with up to 8 different units to the player, each of the first 7 units corresponding to a different response (which means you have to label them accordingly). The player "selects" the desired option by unloading the unit corresponding to the choice they want, then either move the dropship to confirm, unload the 8th unit to view the selected option before submitting their choice, or unload another unit other than the 8th one to cancel the current selection and choose another.

Use eud to detect if player put hold position on the reaver which will be option 1 and scarab for option 2?

No, use EUDs to detect what key a player pushed. Display text is local, so you won't need to worry about desync.

That will work unless the end of the conversation results in something actually happening in the map.

If you have multiple players and have dialogues that result in things actually happening on the map, how about a system of ASCII buttons operated through selection detection EUDs? It's a very easy system for the player to use, because from his perspective, he just clicks a button and the appropriate result happens.

If you're wondering what such a system looks like, here are some screenshots of an example (I never finished the map that this system was used in, but the system itself was fully implemented and tested):

Collapsable Box

If, on the other hand, you only have one player or have dialogues where player choices do not affect the outcome, you could save yourself the hassle of lining up ASCII buttons and such and go with straightforward keypress detection, as Sacrieur suggested. It depends what your map calls for.

That UI looks awesome, FoxWolf.

The second option is cluttered and probably just as unintuitive as the first option, to be honest; you should probably go with one of the suggestions made from fellow SEN members.

If you're going to bother with a hotkey system, my suggestion is better than the Reaver system. Unless there's a drawback besides the hotkey consumption I mentioned, I don't see how this is a bad idea. It doesn't even require the player to look at a new area, and the UI is intuitive. It's like FoxWolf's suggestion, except instead of clicking, the player presses a number on their keyboard.
Is there a reason you wouldn't want to use this system?

It's a multiplayer rpg, so all I would be able to do with EUDs is text, wavs, and other things that didn't get shared among players (so that it wouldn't crash).

If I wanted the NPCs to be able to say, give the player items, affect alliance statuses, etc, it would be unworkable.


That, and I have no idea how to do EUDs .


I... have no idea how you did that O_O. What is ASCII?
I think I almost get the system, you have the little buttons drawn out with text, and click detection to determine which button was clicked. Brilliant! ... Too brilliant for someone with my mapmaking skills .


No, besides that I have no idea how to do EUDs .
(By the way, why is selection detection shared, but not text?)


The interface I have proposed already seems pretty simple to use to me, and most importantly, I can actually make it. IF I could learn how to do EUDs, I would consider using Roy's system, although I would have to ensure there wouldn't be need for the rest of the hotkeys (given that it is an rpg, there shouldn't be).

ASCII Is an acronym for "American Standard Code for Information Interchange." It basically means text.

You should learn sometime I was thinking about writing an extensive guide sometime soon.

Text can be shared. The text display is local, though, so the messages you see on your screen can different than what others see on their screen (i.e. a friend whispering you, or a Display Text Message action only given to you). Selection, on the other hand, has eight addresses in memory (one for each player). This information is global, since all players' SC clients have the information on what other players have selected. I believe it was set up this way for team melee games, where you can see what your ally has selected (dashed line selection rings).

EUDs do take a bit of time to learn, and if you're trying to push this map out as quickly as possible, you may have to either ignore them or get some help making them.

Post has been edited 1 time(s), last time on Jul 31 2011, 2:17 am by Roy.

Well, I want this done in time for the contest (not that that's going to happen in real life anyway, given my track record of never finishing anything), and I sort of like the system I have .


Well, I'll try and keep you guys updated on the map if you wish. I seem to get slightly closer to making a finished map each time I try, so maybe after 20 or 30 more abandoned projects, I'll have something to show for it!