Solved: Narrator appears as player

[Cerno]

Hello all.

I have a beginner problem with dialogs.
What I want to do is something like this:

@S
Character1: "blah, blah"
Character2: "la-ti-da"
narrator: *A bell tolls*

Now when I implement this in the dialog system, the first two lines appear correctly, but the narrator line just appears as if the player character would be saying it (positioned over the player's head in the player's text color). This is independent from who was talking before the narrator.

Also if I understand the manual correctly, the implementation above should display a text box with the narrated text in it. If that is correct, I find it it aesthetically quite unpleasant.

Is there a way of having these narrator texts appear like normal dialog text in a separate color but centered at the top of the screen? I read something about creating an invisible narrator character, but while I think it won't be a lot of trouble to implement, I find it rather clunky and was hoping there was a cleaner way to get this effect.

From my point of view this seems to be quite the natural way to have a narrator who is both well-integrated into the dialog system as well as aesthetically pleasing, so I was wondering why this is not in the system (or maybe it is?)

Thanks for your input.

PS: I know that the best way to do it would be using a sound effect, but in a barrier-free game, I'd need the subtitles anyway.

[zabnat]

Game options in General settings:

Always display text as speech - if you select this option, then all normal text in the game will be displayed above the main character's head as speech text, much like the way the Lucasarts games worked. If this option is not checked, then normal text appears in a pop-up message box, like the way that the Sierra games worked.

You can also customize that pop-up message box (check manual for "Editing the GUIs"), but I can't remember if you can change the behaviour of it (I think you need to dismiss it with a click).

Personally for sound effects I would go with the invisible character(s). That way you can position the text where you want and use a font color that will tie it better to the thing that makes the sound.

[Khris]

I personally am not surprised that AGS doesn't cater to what a single arbitrary person finds aesthetically pleasant. But that's just me.

To do what you want, create a Character and set its Script Name to "cNarr".
Then open GlobalScript.asc, and add this:

Code: ags

  // add these two lines anywhere in game_start
  cNarr.Transparency = 100;
  cNarr.y = 100;  // adjust this to move text up or down

  // add these at the top of repeatedly_execute
  cNarr.x = System.ViewportWidth/2 + GetViewportX();
  if (cNarr.Room != player.Room) cNarr.ChangeRoom(player.Room);

Now you can use narr: in Dialog scripts.

[Cerno]

Thanks to both of you. That answers my question.

@Khris: No offense meant, but wouldn't you agree that having a "narrator" option in the dialog system that behaves exactly as if the main character talks a bit counter-intuitive? I am sorry if I appeared to be arrogant about this but I still think my suggestion would be quite elegant in that regard, don't you think?

Anyway, you have my thanks for answering my question and especially for providing this code snippet that avoids the pitfall of manually having to move the narrator around all the time (which was my main concern for this solution).

Cheers.

Edit: Since the cutscene I am trying to write is the game intro, I had to put the repeatedly_execute code in repeatedly_execute_always since apparently the cutscene is blocking the repeatedly_execute function.

What was kind of weird to me was that while the line cNarr.y = 100; in the game_start was executed successfully (checked by debugging), it did not do anything during the intro (the text was center/center, even though I used the value 20 instead of 100) . Any of these things made it work:

1) Switch off the cutscene and execute the dialog manually (not an option since I need the intro)
2) Move the cNarr.y = 100; to the repeatedly_execute_always function (this works for me).

I guess I'll have some learning to do with respect to the thread system in AGS 

[Khris]

Like zabnat already explained, narrator text usually appears using the default Display() look: black text in a white box with a black border.
The option he mentioned overrides that behavior though, and the result you got isn't what was intended by CJ when he implemented the narrator.
Turn off the "display all text as speech" option and try using the built-in narrator again.

Having centered narrator text that looks and behaves exactly like spoken text could also be confusing; players might assume at first that there's an actual character which is concealed from view by a door or something like that. I don't think it's particularly elegant, sorry

Regarding rep_ex:
Yes, just like is explained in the comments inside the function, blocking events prevent rep_ex from being called.

You can move the command to rep_ex_always, or you can call Wait(1); before starting the intro.
This is unnoticeable to the player, but will advance the game engine by one frame and should also call rep_ex once.

Regarding the initial position: that the text was center/center was due to the starting position of the newly created cNarrator character and their view. The character is transparent, but in order to position the spoken text, AGS still uses the height of the character's current frame, which is the standing frame of the down loop of the default view (#1, unless you were to change it). Basically, upper_text_y is character's y position (feet) - frame's height - fixed margin - font height * lines.

[Cerno]

Khris, I guess we agree to disagree then? I was just a bit confused about the narrator behaving like the main character.

Anyway, adding a wait cycle does not work, unfortunately. Maybe I put it in the wrong place? I placed it in the first line of my room_AfterFadeIn function, which is the first game room and therefore to my knowledge the first possible place to put a Wait. By the way, the intro itself has numerous waits by itself, the largest being a Wait(100). But isn't the Wait function a blocker in itself, so that calling it would specifically not allow the repeatedly_execute to work?

With respect to the initial position, I think I understood the process by which the text is placed. What I did not understand is that cGameNarrator.y = 20; was executed in the game_start (I placed a breakpoint), but it did not change anything. I was assuming that by the time it was executed, the default position of the character would be overridden. Another confusing thing: I changed the starting position of that character in the GUI to y = 20 and still it had no effect. It seems to me that the blocking context of the cutscene somehow prevents this change from happening until everything is processed. When the player gains control, the change is in effect.

[Khris]

CJ's implementation of narration mimicks early Sierra games, just like the rest of the default game.

Spoiler

[close]

The narrator doesn't behave like the main character, if properly used.
So let's agree that you expected a feature to do something else and leave it at that, especially given how trivial it is to work around it.

I haven't tested using Wait(1); myself before posting that, but you're right of course, it's just as blocking as other functions and prevents rep_exe from being called.

If have tested what you describe and I can confirm this.
I put this

Code: ags

  Display("%d", cNarr.y);
  cNarr.Say("Test");

In AfterFadein, and it displays 40, then shows the text at the center of the screen. It's pretty much a bug in the engine, since .Say should always use the current coordinates.

[Cerno]

Thanks for all the effort.

I have learned since yesterday that the narrator was thought out for and implemented for the Sierra style.

To my defense, the manual is quite brief about this, so properly used is not easy to make out for the beginner:

You can also use the special character name "narrator", which displays the text in the pop-up message box instead of as speech text; and the alias "player", which will say it as the current player character - useful if you don't know which character the player will be controlling when they speak the conversation.

This is what I expected, but since I was using the LucasArts style (which is not mentioned in that part of the manual at all), it was not what I got. I agree that the narrator behaves correctly for Sierra style, but the LucasArts behavior seems to be a bit off, like I said previously. Unless there is something else I also missed, in which case I'd be happy to get clarification on this

So about the bug, would you post it to the bug tracker or should I?

[Crimson Wizard]

Well, regarding narrator thing - AGS has many features implemented in a "formal", basic way, while giving developer a freedom to customize them as he/she see fit.

So about the bug, would you post it to the bug tracker or should I?

Feel free to post bugs you found in the cases like this (when it is clear there's one); in the worst case admins will just close the incorrect reports.

[Snarky]

Almost every built-in AGS feature implements Sierra-style behavior. That was the original template for the engine. For other models, you generally have to turn off or override the default behavior and implement your own. That's why there's a LucasArts UI module, but not a Sierra one.

Character speech/conversation is the one major exception (I can think of), where LucasArts-style comes as a built-in alternative.

LucasArts games didn't have a narrator, so how could AGS implement a "LucasArts-style narrator"?

[Cerno]

To close this topic, I guess my main concern was the incomplete documentation, as I just described here: http://www.adventuregamestudio.co.uk/forums/index.php?issue=385.0.
I learned a lot from the forums so far and I would be very happy if more of the knowledge inside people's heads would find its way into the manual.

Thanks to everyone for contributing.

[Cerno]

Sorry for bumping this, but I learned something from the discussion in the bug tracker forum which I would like to share here.

Apparently the problem occurs only when the narrator is not in the current room.

So what happens is this:
- room_AfterFadeIn() does some cutscene work (using blocking functions)
- repeatedly_execute(), which contains the narrator room switch, is not called
- when the narrator is used in the cutscene, it is still in the other room and the default behaviour for out-of-room characters occurs (centered text)
- after the cutscene finishes, repeatedly_execute() is fired and the narrator is updated
- after that, if the narrator is used from the same room, the position should be correct.

So to sum it up: Khris's solution works nicely, but I would use repeatedly_execute_always() instead of repeatedly_execute() to make the narrator room change work together with cutscenes fired from room_AfterFadeIn().

[Crimson Wizard]

I've been very lazy and haven't read everything in here, I just pointed that out to Cerno in bug tracker, and want to note here, just in case, that AGS makes Lucas-Arts style speech appear always in the center of the screen if character is not in the current room. I saw this behavior from early AGS 3.0. Don't know if that may be considered a bug; I think it's rather what's called "undefined behavior".
I guess that's something not very well thought through in AGS design: although the characters are not rightly room-related objects, most of their actions still need to be performed relative to room. Speech is one of such actions that is rather screen-related, not room-related. Still, according to LA-style, speech lines should be displayed with regard to character coordinates.

[Cerno]

As mentioned earlier in this thread, when using the "narrator" keyword in dialogs in LucasArts speech style, the text appears as if the current player said it. Would this be counted towards "undefined behavior" as well? After a little back and forth I now understand why the narrator is not well supported in LA speech, being a beginner I just tripped over the issue since I thought that it was.