At the request of forum member @Ocasoblack, I’ve created a tutorial detailing how to create a basic blueprint-based Text Box and Dialogue System (I’ll show you an example of what we’re creating in Part 1).
I know you’re all very curious as to why I grouped a Text Box and a Dialogue System together. This was simply done because both are ways to communicate things to the player and that stuff you’ll learn while creating a Text Box will help you while creating the Dialogue System.
This tutorial consists of four parts (excluding the Introduction and two closing sections) and deals with several topics.
Frequently you might see a…
NOTE: Which appears like this and gives some more detail on the topic we are dealing with.
You may also see an…
Information Drop**:** Which will give some outside information that deals with a wide range of things from programming terms to Stephen King.
Now, without delaying any further we may as well just get to it.
Part 1 - What’s Going on Here?
Before we begin, I’d like to show you what it is we’ll be creating and how it works in-game.
Figure 1.1: Here we see the player approaching a corner that houses a Trigger Box. When they enter this Trigger, a text box will appear.
Figure 1.2: The player has entered the Trigger, causing the in-game **Text Box **blueprint to appear. When the player walks out of the Trigger, the Text Box will disappear.
NPC and Dialogue System:
Figure 1.3: The player is now about to enter another Trigger. This one is centered around a NPC Blueprint Actor. When the player enters the Trigger Dialogue will be initiated, the mouse cursor will be shown, and Player Input will be disabled (i.e. moving the mouse cursor will NOT move the player’s camera, pressing the
WASD keys will NOT move the player, etc.).
Figure 1.4: The NPC’s dialogue (represented by a green background behind the text) plays when the player steps into the Trigger.
Figure 1.5: A click of the Left-Mouse Button removes the NPC’s dialogue and calls the player’s dialogue (represented by a blue background) options to the viewport.
Figure 1.6: If the player clicks Option 1, the NPC will respond accordingly.
Figure 1.7: Another click of the Left-Mouse Button will end the dialogue and Enable Player Input, allowing the player to walk out of the trigger.
Part 2 - Preliminary Steps and Information
Step 0: Create a room or multiple rooms depending on your preference; it doesn’t have to be as elaborate (or beautiful) as my rooms are. I have it setup so that the room to the right houses the Text Box, while the one to the left has the NPC in it.
Create the map as you see fit.
Before we begin here are some things to take note of:
- At the time of this tutorial’s creation, I was using version 4.12.5 of the engine. If you are running a earlier version (or if you’re coming from the future a later version) this tutorial should, for the most part still work. The only thing you’ll need to be wary of is whether or not Blueprint nodes changed names or if other nodes
were added and have the functionality of a node that used to do something else. For the ones I’m aware of, I’ll make sure to put in a note when they appear in this tutorial.
- Considering we are creating two things, one of which (the Dialogue System) is fairly complex (not amazingly so, but you can get lost easily if you aren’t paying attention) this is a LONG tutorial. For reference its eighty images (well seventy-two really if you count the ones from above), each of which has a description
attached to them. Take your time, and go through this slowly.
This tutorial, like all my tutorials, assumes you’re new to Blueprints. I’ll be explaining as much as I can in as much detail that is needed, so don’t fret if you don’t know much…or anything about Blueprints. We’ll brave this together.
Good luck and have some fun! We’re creating stuff for games after all!
Part 3 - Appearing Boxes
In this part, we will focus on creating the Text Box that was displayed in Figures 1.1 to 1.2.
Step 1: Navigate to the left side of the screen and right click on the Content Browser. Choose Blueprint Class.
Step 2: Select Actor. We’re using an Actor because this Blueprint will not be controlled by the player and will instead be an object in the world a player can interact with. Name the Blueprint whatever you wish to name it (I named it “Tut_TextBox” for simplicity’s sake).
Step 3: Double-click the Blueprint that is created go to the left side and click the Add Component tab. Choose Static Mesh. If you can’t find it type “Static Mesh” in the search box.
Step 4: Name the Static Mesh “Background” and hit ENTER on your keyboard. Then look to your right and under the Static Mesh tab, click on the drop down menu and search for a Wall mesh. Choose the** 400x200 Wall** (or whatever mesh you feel comfortable with).
The Static Mesh we just created will act as a backdrop for our Text Box. This step simply had you customize the name and what mesh you want to use.
Step 5: Select the Wall, either by clicking on it in the viewport or clicking on “Background” under the Components List on the left side of the screen, and Scale it down to a reasonable size.
If you were creating a game, you’d of course want to optimize this well, but for this tutorial you can just eye-ball the size.
Step 6: Next, add another component. Rather than a Static Mesh, add a Text Render Actor. This will act as the text for our Text Box.
Step 7: Rename the Text Render Actor “Text” (if you’d like) and look to the right side. Under the **Text **tab, change the Text to “Hello World!” (or whatever you’d rather have).
Step 8: Translate and Rotate the Text Actor so that it is positioned in front of the Static Mesh. Then select the Text Actor, navigate to the Text tab again and go to Text Render Color. Choose a color that can be shown on the Static Mesh (I just chose black to match the color of my heart, but choose whatever you’d like).
Step 9: Your Actor should look something like this. Don’t worry, we aren’t done yet (we haven’t even touched the programming segment of this)!
Step 10: Add another Component. This time make it a Box Collision; name it “Trigger”. This Box Collision will act as a Trigger Box. When the Player enters the collision area, the visibility of the Text Box will change.
Step 11: Scale and resize the Trigger so that it encompasses the Text Box. Move the Text Box to the back of the Trigger and ensure it is raised up quite a bit. We want to give the player ample room to enter the Collision Area as well as have the Text Box be at [roughly] eye level (relative to the player).
Step 12: Navigate to the Event Graph and under the Components tab on the bottom left-hand side, click on the Trigger.
Step 13: With the Trigger highlighted, look to the right and click on the Plus Sign next to OnComponentBeginOverlap.
Step 14: Repeat the process, but this time choose OnComponentEndOverlap. I just want to pause for a second and explain the two nodes that we createdThe OnComponentBeginOverlap node states that whatever it is attached to (say an Open Level node, which loads another map) will only execute if the player overlaps
the Component (simply speaking: if the player enters the Trigger’s Collision Area which we set up around the Text Box). So for example, if an Open Level node is connected to a OnComponentBeginOverlap node a new level will only be loaded once a player enters into the Trigger Area. If the player stays away from it, or
moves around it, nothing will happen. The OnComponentEndOverlap node is an opposite of the OnComponentBeginOverlap node. When the player enters a Collision Area, the OnComponentBeginOverlap node fires and when the player steps out of a Collision Area, the OnComponentEndOverlap node fires. Let’s discuss (in a
one-sided manner, admittedly) another example. If an OnComponentBeginOverlap and an OnComponentEndOvelap node are connected to two [separate] Toggle Visibility node (something we’ll actually be using in a bit) for a Point Light (a simple light source placed in a map) that, by default is set to visible, when the
player enter the Collision Area of a Trigger, the OnComponentBeginOverlap node will fire and execute the Toggle Visibility node turning the Point Light off. When the player walks out of the Collision Area of the Trigger, the OnComponentEndOverlap node fires and executes its own Toggle Visibility node which will turn the light
back on. Not too difficult to understand, right?
Step 15: Drag out from the OnActorBeginOverlap node and search for a Toggle Visibility node, ensure the one you choose has “Background” in parenthesis next to it. Then drag out from the Toggle Visibility (Background) node and create another, this time choose the one with “Text” in parenthesis.
Step 16: Select both Toggle Visibility nodes and hit CTRL+C to copy them and then CTRL+V to paste them. Attache the OnComponentEndOverlap node to the set of Toggle Visibility nodes that you pasted.
All we’ve done in these two steps is have the Text Box appear when the player steps into the Trigger (OnComponentBeginOverlap -> Toggle Visibility (Background) -> Toggle Visibility (Text) ) and then have the Text Box disappear when the player walks out of the Collision Area
(OnComponentBeginOverlap -> Toggle Visibility (Background) -> Toggle Visibility (Text) ).
NOTE: It has come to my attention that I haven’t really given a definition of what it is I mean by “Collision Area”. If you haven’t already figured it out, this is just simply the extent to which our Box Collision (“Trigger”) goes.
If that seemed a bit more confusing than what you already had in mind then just think of it as the area that the Trigger [in our Actor Blueprint] surrounds…
I should have just said that to begin with.
Step 17: Alright now that’s all done, right? Well not exactly. If you test it in game, you’ll notice the system works…with one major flaw: the Text Box starts out visible and then turns invisible. We want it to be the other way around. In order to do this, go back into the Text Box Blueprint and navigate to the Viewport.
Select the Background Static Mesh and look at the right hand side of the screen and navigate down to Rendering tab; uncheck the box next to “Visible”. Do the same for the Text.
Congratulations! You’ve officially created your first Blueprint based Text Box!
Drag-and-drop it in your map and spawn in (ensure there is a Player Start) to check it out!
**Part 4 - “Hello World!”
In this part, we will create the a Dialogue System similar to that seen in Figures 1.3 - 1.7 of Part 1.
Step 18: Begin by going to the Content Browser, right click and hover your mouse cursor over User Interface. Choose Widget Blueprint and name this Blueprint “Tut_Dialogue01” (I know I usually say the name doesn’t matter, but for this part I suggest you use the names I’ve chosen or something similar because I’ll
be referring to certain widgets by name).
Step 19: Open the Tut_Dialogue01 blueprint and before we do anything look at the top right and click Screen Size. Choose the screen size you feel comfortable with; for this tutorial I just used the max resolution of my monitor (which in my case is 3840x2160).
NOTE**:** If you were creating a game, this is something you’d probably want to optimize well and choose after careful deliberation; for the sake of this tutorial we don’t need to do that though and choosing your monitor’s native resolution is perfectly fine.
Information Drop: In case you’re unaware what “native resolution” means, it’s just whatever resolution your monitor is rated for; it’s the fixed resolution it has. So, a 4k monitor has a native resolution of 3840x2160; even if it can go down to 1080p it will default to 4k (normally).
Continue by looking at the left side of the screen and dragging out a Text block from the Palette.
**NOTE: **DO NOT use a Text Box! A Text or Text Block is a string of text that will appear on the screen; the player has no way of interacting with it directly. A Text Box allows interaction from the player. So, for example, if you were creating a text parser you’d use a Text Box because players can type in it and have the
string they type out execute a command. I won’t get into too much detail though; that’s for another tutorial.
**Information Drop: **Consider I’ve been mentioned a **String **a few times, I figured I’d take a second to explain it. A string is a programming term that simply refers to text that is communicated to the viewer/player/reader by printing, or showing, it on screen. Strings usually don’t have any direct interaction attached to them;
so a player will never click on/change a string. Strings can, however, be printed by the player; the Text Box is a perfect example of this.
Alright, back to the actual tutorial.
Step 20: Look to the right-hand side of the screen and under the Content tab, change the Text to whatever you’d like our NPC to say when the player walks up to him/her/it (I simply used “Hello World!”). Hit ENTER on your keyboard.
Information Drop**:** “Hello World!” is a programming…for lack of a better word…term. Many times when someone creates their very first applications, it’s a Hello World Command Prompt; usually these will simply be a Windows Command prompt that comes up and prints the string “Hello World!”.
Hello World programs are a great start point as these programs can be created in whatever language and help teach the basic such as printing a string, setting up an executable file, compiling and debugging, etc.
Step 21: Resize the Text Block by dragging out from the white diamonds or changing the X Size and Y Size under the Slot tab on the right side of the blueprint. You can change some setting under the Appearance tab if you wish; in the picture above I increased the font size from 24 to 32.
Step 22: Once you’re done changing the Text to an appearance you like, navigate to the left side of the screen and drag out an Image from the Palette. This image will act as a background for the Text Block; it will have a distinct color to represent the NPC (green) while the background for player dialogue choices will have
its own color (dark blue).
Step 23: Place the image over the Text Block. This is probably a good time to tell you to center both the Text Block and the Image; you can CRTL Click them from the Hierarchy tab and drag them into the middel (eye-ball this, we’ll make it accurate in a bit).
Information Drop**: **A “CRTL Click” (or “Control Click” if you prefer) is a method used to select multiple files, objects, etc. on a computer. It consists of holding down the CRTL key and clicking on all of the things you’d like to select. CRTL Clicking is NOT a UE4 specific command; it can be done in Windows Explorer, Firefox,
your Desktop, etc.
For those of you that know about CRTL Clicking you’re probably wondering why I even took the time to explain this, but I’ll fully admit it wasn’t until I got into game development that I figured out about it so if anyone new to development is reading this I bet you ten bucks they had no idea about it (more than likely anyway).
Step 24: Navigate back to theHeirarchy tab and click on the Image. In the Heirarchy tab, drag the Image above the Text Block (or drag the Text Block below the Image if you prefer).
Step 25: Now select the Image and look to the right side of the screen. Click on Color and Opacity under the Appearance tab and change the color to some form of green; this color will act as a designation. Any text with a green background is a line of dialogue from out NPC, while any with the color blue is a line of
Step 26: Go to the Palette and select a Button, drag it out. A button is a simple widget that allows that, when clicked (or hovered over) will execute a command (I’ll go into this more in a bit, when we start using it).
Step 27: Resize the button to fit the entire widget area. We want this to be accurate, so don’t drag out using the white diamonds; instead change the X and Y size in the Slot tab. You want the size to match your screen size UNLESS your screen size is set to 3840x2160; if it is, set your size to X Size to 1920 and Y Size to
NOTE: If your screen size is 1920x1080 then change the size of the button to 1920 and 1080; you don’t need to go lower. The reason a screen size of 4K requires a lower Button size is because it’s still registered as a 1920x1080 space.
Step 28: Navigate to the right side of the screen under the Appearance tab and drop down the Background Color tab. Change the A value to 0. This makes the button invisible. The reason we want it to be invisible is simply because we want the player to be able to see the NPC they are “talking” to; if the button was not
invisible, it would fill up the player’s viewport and block their sight.
Information Drop**: **Change the button’s A value, isn’t some strange option. “A” refers to an Alpha Composition (this really refers to images, but it can be used for anything); to put it simply the Alpha Composition, or Alpha Channel, determines whether the image we are referring to is transparent, translucent, or opaque.
Alpha Channels should not be confused with Opacity, which may seem the same, but are slightly different. Basically Opacity, most of the time, affect children of an image while Alpha just affects the parent.
If you’re not getting this, don’t worry about it. It doesn’t have any baring on this particular tutorial.
Step 29: With the Alpha value set to 0 (just as a side-note, changing the Opacity doesn’t make the button opaque which is why the Alpha channel is used), you can see the button is now opaque or see-through.
Step 30: Now go to the Heirarchy tab, and select everything once (CRTL Click). Then look to the right and click on the Anchor****s tab, select the Anchor that represents the middle (column #2, row #2). This anchor will ensure that everything is centered to the screen when the widget is called to the player’s viewport.
Step 31: You should see the anchor (the white star thing) move to the center. Next select the button and navigate to the right side of the screen where it says “Button_XXX” (each X represents a number…get your mind out of the gutter). Highlight the current name and replace it with “Button01”. You don’t necessarily need
to rename the button, but it will help us out to keep this simple (and personal).
Step 32: Alright now we’re going to start some visual scripting (well, not really that’ll come later, but we’ll set our graph up…kind of). Navigate to the Graph (upper right corner) and click on Button01 from the Variable****s tab on the left side of the Blueprint.Then look at the bottom left side, under the Events tab and click
the green plus next to On Clicked.
Step 33: You should get a node that looks this. What this node does is execute the nodes that will be connected to it, when the player clicks the button (which in out case is anywhere around the Text/Image combination).
Step 34: Exit the Blueprint and create a new Blueprint Class.
Step 35: Make it an Actor (remember, we’re using an actor because the NPC is something the player will interact with, but will not control) and name the new Blueprint “Tut_NPC”.
Step 36: Add a Cylinder Static Mesh, the same way we created the background for the Text Box (Add Component -> Static Mesh -> Right Side -> Static Mesh Drop Down Menu -> Search for Cylinder). Resize the cylinder to whatever size you desire it to be.
Step 37: Create a Box Collision component (rename it to “Trigger”) and make sure it engulfs the NPC model; unlike with the Text Box, however, do not place the Cylinder at the back of the Trigger, instead keep it in the middle. The reason we’re not pushing our NPC to the back, is because we want to allow the player to iniate
conversation no matter which direction they come from.
Step 38: Now go to the Graph and click on the Trigger under the Components tab on the left side; create a OnActorBeginOverlap by clicking the green plus sign on the right side of the screen once you have the Trigger selected. Drag out from the newly created node and search for a Create Widget node.
[HR][/HR]**NOTE: **They’re won’t be explanations attached to each step, instead I’ll explain what we did/used and why after the setup is complete. There’s a lot to do and it’s easier to just get it done rather than risk getting lost as we go through this.
Step 39: Click on the dropdown menu next to Class and choose Tut_Dialogue01.
Step 40: Drag out from the Return Value of the Create Widget node search for an Add to Viewport node.
Step 41: Right click on the Graph and search for Get Player Controller.
Step 42: Select the Get Player Contoller node, copy (CRTL+C) and paste (CRTL+V) it.
Step 43: Drag out the Return Value from one of the Get Player Controller nodes and search for a Disable Input node.
Step 44: Right click where it says Target on the Diable Input node and select Break All Links.
Step 45: Attach the Get Player Contoller’s Return Value to the Player Controller section of the Disable Input node. Then drag out from the Target of the Diable Input node and search for a Get Player Character node.
Step 46: Next got to your other Get Player Controller and drag out from the Return Value. Search for a Set Show Mouse Cursor Node.
Step 47: On the Set Show Mouse Cursor Node, check the box next to Show Mouse Cursor.
Step 48.1: Connect the OnBeginActorOverlap node to the Show Mouse Cursor Node. Then connect the Show Mouse Cursor Node to the Disable Input node which should lead into the Create Widget node which should be connected to the Add to Viewport node.
Alright so that was a lot of steps, with very little explanations; I figured it would be easier to see the finished product of this Blueprint and then explain it from there as it’s rather simple (long, but simple).
Basically, all we’ve done here is have the “Hello World” dialogue widget we created be shown on the player’s viewport when the player walks into the Trigger area. Let’s just take a minute and go through the nodes individually, shall we…
a) BeginActorOverlap: This node we used previously with the Text Box; it executes the nodes that are attached to it once the player walks into the Box Collision (which we named “Trigger”) in our map (well your map, well our map…).
b) Set Show Mouse Cursor: The Set Show Mouse Cursor node will draw the mouse cursor to the player’s screen once they step in the Trigger area. We want the mouse cursor shown so that the player can click through dialogue and select dialogue from the choices presented to them.
There are two things to you should take note of: the first is that this node is communicating with the Player Controller, the second is that there was also a Get Show Mouse Cursor node yet we picked Set instead, and the third is that the node has a red hue to it (alright so I lied, there were three things).
The reason this node “speaks” to the Player Controller is because the Player Controller is…well what controllers everything the player does (not to be confused with the Player Character which is basically the player as an entity). In a sense the Player Controller is in charge of the player’s wants; with this setup
we’re telling the Player Controller that the player needs the mouse cursor shown and it obliges (I know this explanation seems overly simplified and that’s really because…there’s nothing more to it). If you ever find yourself in a situation where you need something to happen to the player, but you’re missing a piece of
the puzzle…chances are you need to communicate with the Player Controller.
As I previously mentioned, we did not use the Get Show Mouse Cursor node. This is because we didn’t want to simply communicate with the Mouse Cursor, but rather we wanted to force it to do something (we wanted to “set” the state it is in rather than “get” the state it is already in).
The red hue, indicates that the node is a variable…specifically a Boolean. A boolean is a programming term referring to a True/False variable. In this case, by checking the box we set the node to “True” meaning that the Mouse Cursor will be shown when the node is fired.
c) Disable Input: This node makes it so the player cannot move or move the camera while the dialogue is going on. The reason we needed to disable input is because the player will be moving the mouse to move the mouse cursor, if we didn’t do this the entire camera would move when the player tries to select dialogue.
Just like with the Set Show Mouse Cursor node, we need something to happen to the player so we commincate with the Player Controller through the Get Player Controller node. In this case, however, we set the Target to Player Character. The Player Character is basically the Player as a Blueprint in the world; it contains
all the information needed to allow movement for and interaction by the player. When we make the Target the Player Character, we’re basically telling the node to disable everything within the Player Character blueprint (i.e. the ability to jump, look around, etc.).
d) Create Widget/Add to Viewport: Pretty self explanatory; this node will create whatever widget we choose when it is fired. It has to have an Add to Viewport node attached to it, otherwise the widget wouldn’t appear anywhere.
Step 48.2: These next two sub-steps are optional, but I recommend you do them as they’re simple and a good thing to have in you’re pocket.
Right click and search for a Comment.
Step 48.3: Name the Comment whatever you like, just make sure it explains what the Blueprint system is for (I chose to name mine “Trigger Mouse Cursor and Widget Creation”). Then extend the Comment so that it engulfs all the nodes.
Congratulations! You’ve successfully used your first Comment!
Comments are a good way to keep large, complex Blueprint systems organized and if someone other than yourself looks at the Blueprint at least they won’t have to ask what each part does.
Step 49: Now create a new Widget Blueprint and name it “Tut_Dialogue02”. Set up the blueprint like I have, with an Image behind two Buttons, each of which have a Text Block on top of them; anchor everything to the center. This widget will act as dialogue choices for the player.
Considering we previously setup a Widget Blueprint no too disimilar, I won’t go through every step. You can rename things as you wish (I renamed my buttons “Button01” and “Button02”).
Step 50: Create an OnClicked node for each button (remember, select the button under the Variable tab on the left side of the screen and then look at the bottom left side and click the green plus next to “On Clicked”).
Step 51: Exit out of that Blueprint and create a new Blueprint Widget; call it “Tut_Dialogue03”. Create an Image with a Text Block ontop of it and create an opaque button that it behind both the Image and the Text Block; anchor everything to the center.
This widget is the result of the player picking the first dialogue option.
**Information Drop: **“Lond days and pleasant nights.” (Tut_Dialogue02 choice #1) and the response “May you have twice the number.” (Tut_Dialogue03) is a reference to Stephen King’s The Dark Tower series of novels. It’s a greeting that is used often in Mid-World, where the series takes place, and is said by many
characters including the protagonist, Roland Deschain.
Step 52: Exit out of Tut_Dialogue03 and create a new Blueprint Widget; name it “Tut_Dialogue04”. It’s basically the same setup as Tut_Dialogue03, just change the text in the Text Block.
This widget is the result of picking the second dialogue option.
Step 53: Now, exit the Tut_Dialogue04 blueprint and go back to Tut_Dialogue01. If you didn’t already create an OnClicked node for the button in Tut_Dialogue01, do so now.
Then, drag out from the OnClicked node and search for a Remove All Widgets node.
NOTE: If you’re running an earlier version of the engine, you may have to use a Remove from Parent node instead.
Step 54: Drag out from the Remove All Widgets node and search for a Create Widget node. In the Class dropdown menu, choose Tut_Dialogue02; make sure you attach an Add to Viewport node to the Create Widget node.
All we did here is tell the blueprint that when the player clicks the button (anywhere in the viewport since our button encompasses the entire widget area), the dialogue will continue. Before that, however, all widgets currently on the screen (Tut_Dialogue 01) will be destroyed to make room for a
new widget (Tut_Dialogue02).
Step 55: Now go to the Graph in Tut_Dialogue02 and create a similar setup. For the first OnClicked node (referencing Button01) choose Tut_Dialogue03 in the Class dropdown menu of the Create Widget node. Choose Tut_Dialogue04 for the Create Widget node attached to the second OnClicked node.
This setup simply draws a widget to the screen depending on which dialogue choice the player chooses (if the player clicks Button01, Tut_Dialogue03 is shown; if the player click Button02, Tut_Dialogue04 is shown).
Step 56: Go to the Graph of Tut_Dialogue03 and create an OnClicked node. Drag out and create a Remove All Widgets node, then drag out from there and create a Cast to NPC node.
Alright, we need to pause here for a second. Cast nodes are rather…complex and can easily get a newcommer lost/apprehensive if they don’t really know much about them. Back when I started, there were a lot of things I couldn’t do simply because I had no idea what Cast nodes were for, let alone how to use them.
But don’t fret, I’m going to give you the simplest possible explanation.
The best way to think of Cast node is to look at is as a telephone. A Cast node is a way to communicate with other blueprints. It’s as simple as that.
Now, why exactly would we want to communicate with an entirely different blueprint that has nothing to do with what we’re doing? Well, think back to when we started this. Remember when we disabled player input using the Disable Input node?
Considering that the Tut_Dialogue03 is going to lead to the end of the conversation, we need to enable player input again…but there’s a problem: there is no Enable Input node in Widget Blueprints!
That’s where a Cast node comes in; we can Cast to the NPC blueprint and then we’ll be able to use nodes that are specific to the NPC blueprint…such as an Enable Input node.
And that’s about it for Cast nodes; they’re not as confusing as they may sound. If you ever find yourself in a situation where you’re working on a Blueprint and you need a node that isn’t in the Blueprint you’re working on, chances are you can Cast to another blueprint and gain access to the node you want.
Step 57: Once you get the Cast to NPC node, drag out from there and search for an Enable Input node.
Step 58: Just like with the Disable Input node, attach a Player Character node to the Enable Input node’s Target and a Get Player Controller node to the Player Controller section of the Enable Input node.
Step 59: Because we don’t have an Object to attach to the Cast to NPC node, we’re going to delete it entirely and just keep the Enable Input node (otherwise we’d get an error).
This setup is pretty simple. When the player clicks the left mouse button while the NPC’s response to the player’s dialogue is onscreen, all widgets will be removed from the screen and the player can walk around again (allowing them to get out of the Trigger area).
Step 60: The last thing we need to do is add a Set Show Mouse Cursor node to the end of our node lineup; this is so that the mouse cursor disappears when the dialogue ends.
Step 61: Drop the Blueprint Actor into your map to test it out.
Figure 4.1: Here the player is approaching the Trigger Box.
Information Drop**: **“Trigger Box” is technically an improper term, I really should say “Box Collision” or “Trigger” (which is what we named the Box Collision). “Trigger Box” is the name of triggers that are placeable with a map, rather than within a blueprint.
“Trigger Box” was also used frequently in UDK.
Figure 4.2: When the player enters the Trigger, the NPC’s initial dialogue appears.
Figure 4.3: The player clicks the left-mouse button prompting player dialogue choices.
Figure 4.4: Picking the first choice, prompts the NPC to respond.
Figure 4.5: The player can then click the left mouse button, ending the dialogue.
Figure 4.6: Then are now free to move around.
**Part 5: With All That Said…
Alright so now that all of that is over with there’s just a few things left to say.
First off Congratulations! You’ve officially completed the tutorial and have now made your very first Text Box and Dialogue System!
Keep in mind that this tutorial showed you a good starting point, with a bit of time that Text Box can have some cool effects put to it and the Dialogue System can include audio.
As with all my tutorials, be sure to leave me some feedback, and if you want me to add anything please just ask. Likewise, if you have and suggestions for future tutorials (or if you just want to say “hi”) Private Message me on here (or Reddit) or leave a comment on here (…or Reddit).
Part 6: …Now It’s Time to Say Goodbye
I just want to say a few things as you go on you’re way.
Remember, that no matter what, patience and determination will always get you further than you think it can. You may not have understood I word I said in this tutorial, but that doesn’t matter. What matters is you tried; now keep trying until you get it.
I’m always here to help as well, so if you ever need anything don’t hesitate to contact me.
Also, this tutorial may have been about visual scripting, but always try and know all parts of game development whether you’re going into programming or not; it’s best to know what your colleagues are doing.
Well that’s about it.
I hope you learned something today, and that this tutorial helped you out.
I’ll see you around, good luck in the meantime.
Long days and pleasant nights.