블루프린트 통신: 인터페이스, 이벤트 디스패처, 인터랙션

### 블루프린트 커뮤니케이션: 언리얼 엔진의 고급 기술
* 🔄 블루프린트 커뮤니케이션의 두 번째 파트에서는 번거로운 캐스팅 방식을 피하고 다양한 블루프린트 간에 직접 커뮤니케이션을 구축하는 방법으로서 **인터페이스를 자세히 살펴봅니다.**
* 💡 인터페이스는 구현 클래스가 특정 매개변수를 받아들이고 그에 따라 동작한다는 약속의 역할을 하며, **램프나 차고 문과 같이 동일한 상호작용 방식에도 불구하고 결과가 다른 객체와의 표준화된 상호작용**을 가능하게 합니다.
* 📊 BPI 인터랙트와 같은 블루프린트 인터페이스를 생성하면 **모든 구현 블루프린트가 갖춰야 하는 인터랙트 기능**을 정의하여 커뮤니케이션을 간소화하고 다중 캐스트의 복잡성을 줄일 수 있습니다.
* 🎮 실제 적용에서는 **BP 박스와 BP 구체 모두 이 인터페이스를 구현**하여 1인칭 캐릭터가 캐릭터 자체에 인터페이스를 구현할 필요 없이 한 번의 입력 동작으로 원활하게 상호작용할 수 있는 방법을 시연했습니다.
* 📏 또한 캐릭터에 근접 볼륨을 부착하여 **특정 영역에 겹치는 모든 액터와 상호작용**할 수 있도록 하여 한 번에 여러 오브젝트를 찾고 상호작용하는 프로세스를 간소화하는 방법도 모색했습니다.
* 🚪 또한 문을 열고 닫을 때 커스텀 이벤트를 사용하도록 문 블루프린트를 수정하여 **부울 변수로 상태를 관리하는 방법**과 **근접 볼륨을 사용하여 문과 상호 작용하는 방법**을 시연했습니다.
* 📰 마지막으로 이벤트 디스패처를 도입하여 오브젝트가 다른 오브젝트가 보내는 이벤트를 수신할 수 있는 **뉴스레터 구독 모델**에 비유하여 플레이어의 행동에 따라 역동적이고 반응적인 상호작용이 가능하도록 했습니다.
* 🔄 튜토리얼 내내 **깔끔한 코드의 중요성**과 더 이상 필요하지 않은 이벤트의 바인딩을 해제하여 게임 환경 내에서 효율적인 커뮤니케이션을 보장해야 한다는 점을 강조했습니다.

블루프린트 인터페이스는 언리얼 엔진의 다양한 오브젝트 간 통신을 간소화하여 코드 효율성을 높이고 복잡성을 줄여줍니다.

[Music] Welcome back to this, the second part about blueprint communication. We will be going into some further concepts and ways of establishing a direct communication between blueprints. In this episode, we will start off from where we ended last time and move in towards interfaces. Imagine that you have hundreds of objects, and you want to interact with them, and they are all very different, so they can't for some reason be inheriting and getting this functionality. But we have to actually call upon them individually. If that is the case, then this is a very poor method of communicating with them because we would have to cast or try to cast each and every single object that we want to create a connection with and then call an interaction with. Which means that if we had multiple different places where we could possibly also try and interact or some other way communicate with these items, then each time we add an item or remove an item, we would have to go to those different places, and we would have like these hundreds of casts in a long succession.

and it would just be a mess of code. So, what is the alternative to this? Well, for this specific scenario, interfaces would be a good solution. So, what is an interface? Well, an interface is a promise that if you implement an interface, you will accept certain parameters and then you will behave in a certain way. The promise is not about the behavior; the promise is that you will take the input and then you will behave in a certain way. So, if we take the example with the lamp and the garage door, you can say that you're interacting with both of them, and the result is very different. Either a light turns on or a door is opened. You are doing the same thing; you're interacting with them, but the result is very different based on the item that you're interacting with. So, let's demonstrate this to make it a little bit more clear in how it works in Unreal. So, we're gonna create a blueprint interface. So, we'll right-click, we'll go to blueprints, and you see that blueprint interface.

appear here. We'll call this BPI for Blueprint Interface Interact, and we'll open that up. Now, this looks very different from a normal blueprint because, first of all, the grid here is all grayed out, and you can see up here in the top right it says read-only. That is because this is just the promise of interface of how two different classes can interact with each other. It doesn't actually say anything about what the result of that interaction will be, but we can start off with we get a function created immediately, and we'll call this interact. So, this is a function that you promise that you have if you implement this interface. So, if we compile and save and we don't, you can have inputs, and you can have outputs to this just like any other function, basically. But for now, we'll go back to our BP Box, and we'll go to class settings, and you see that it opens up this interface grouping here, which says we have no interfaces. We'll add BPI Interact to this one, compile, save. We'll go to our BP Sphere, and we'll

do the same thing: class settings, interfaces, add bpi, interact, compile, save. So now both the sphere and the box have said that they're implementing these interfaces. Okay, what does that mean? Well, you can see here on the left among our functions and events. Now we have an interface grouping that has appeared that says interact with, which tells us that this is a function or event that you're getting from an interface that you should have available. So if we right-click on this and we choose the implement event, it will create a node that looks slightly different. This symbol up here represents that it's coming from an interface. So what we want to do now is, well, if we get interacted with, what do we want to do? Well, we want to use our interact function, which we have already created here, or rather event in this case. So we'll just drag off a connection here and type interact. Now when this event happens, it will say, Ah, I should use my interact functionality, which is this, which will tell us that the circle blueprint has been interacted with.

cool, so we'll compile and save. We'll go to the box. We'll do the same thing. We'll implement the event. We'll say interact function should be called compile save. Okay, so now we have both of the blueprint events implemented in both of the classes. How do we use this? Well, if we go back to our first-person character, and this is our logic for interacting with the world with the line trace channel, what we can do just to keep this separated. This is not good practice to have multiples of the same code, but I just want to keep them both available so you can see how they work and you can see the difference between them also. So now when we're pressing E, we're doing this exact same thing as before when it comes to the lane trade line trace, and then we have an object to interact with. So what we do is we drag out this actor, and we type interact with, and you see we get an interact with message. Now this class, the first-person character, does not implement

the interface. The sending blueprint doesn't need to have the interface; only the receiving blueprint needs to have the interface. So, what we're doing here is we're saying we got a hit on this line trace. We're going to send an interface message to this object. If this object has that interface implemented, then it will run whatever code it has there. If this object does not have an interface implemented of this type, then nothing will happen. There will be no negative consequences. It will just continue processing as normally. So, let's try this out. Go back to the map, click play, pressing E, nothing happens, nothing happens, nothing happens because we're at the distance. We'll walk up to the box, press E. Box has been interacted with, sphere or circle has been interacted with. Okay, so this particular scenario, we could get rid of this and possibly hundreds of other costs to this specific interface called instead much more handy in this specific scenario. This seems like a fire-and-forget kind of a call, and it sort of is, but you're not limited to having only an

input to an interface. Either you could actually have it return something for you, so you could be sending data to a class, and if it's implementing it, it will receive the information, do something, and possibly send some information back to you, saying like maybe this was successful or something of that nature. Or it could be something way more advanced than that as well, but for instances when this, when you need to check if you need to do something that is agnostically indifferent when it comes to, they don't have an inheritance that exists that allows you to have functionality shared between objects, but you have very different objects, but you need to do something very similar when it comes to communicating towards them, even if the result within them is very different than interfaces, is a very good way of dealing with that situation. Now let us dig into yet another way of how we are able to get references to interact with in some form or manner. Let's think back to our tutorial where we did the door that was opening. It had a collision volume around it, which allowed

any character or player entering the volume to interact with that door by having it opened. Well, that works for each individual object that you would have in the world that would have functionality like that. So, you would have to have a volume around each object. You can do this in a similar but different way, which is this is our character that we're playing with. It can itself have a volume attached to it. So, if we type in box call, we get our box collision. We'll call it proximity volume. Let's see here. It is. I'm just closing down some of the hierarchy to see which level this in. This is under the capsule component. Now, that is good. So, what we can do is we can move this box forward a bit so it represents a head of the character. We'll scale it up a bit, make it a bit wider, maybe even make it further out like so. This gives us approximately the same size as our character but ahead of us, meaning that anything in this volume here is something that we could potentially

interact with, so we'll compile and save, and we'll do something fun with this. So, we'll go back out into the map, and we'll get our door that we made before in the previous tutorial, and we'll right-click on this, and we'll make a duplicate out of it just for this particular example. We don't want to mess up the old logic; we just want to play around with some new logic. So, we'll call this um bp interact door, and we'll open it up. And you remember how we have this proximity volume on this door here, which allows a player to enter it, and then we open up the door here. What we instead want to do now is we want to cut out these two events that are generated from leaving and entering the volume. So, we'll delete those. We will delete the proximity volume. We will then right-click and create a custom event, and we'll call it open door. So, this custom event called open door, it's gonna start doing the door opening there. So, we'll remove this cast.

because we don't need it. So, if anyone was to call this event called open door on this blueprint, then it would start opening the door, and it would run the animation that we did in the last episode. We'll remove this other cast as well, and we'll create another custom event called closed door, and we'll put that in the reverse over here. So, the same functionality as before, but it is triggered differently now. So, how can we make use of this in a nice way? Well, we can say we can make a variable. We can call this, let's call this open, okay? So, by default, this boolean variable called, let's actually rename it to is open, so it's more clear, called is open, is defaulted to false by the checkbox and not being checked in. We can use this as our sort of directionality when it comes to what are we supposed to do with the store. So, let's make a custom event, call this our interacts to be sort of like consistent. So, we expect this to be called at some point, and we want to say that if the door is

opened or closed, we want to behave differently and call these events, so we'll branch on this our if statement. Connect the node, so we'll say if the door is open, then we want to close it, so we'll call close door equally. If the opposite is true, we want to open our door, okay? So now we have that set. Let us go back to our first-person character again, go back to the event graph, and we'll move this interact input that we haven't disconnected because we're just going to show a different interaction now. So what we want to do is if someone or something is in this sphere or sphere, this box volume that we created, the one that we put ahead of the player here, and we press E, we want to interact with it. We don't want to make a line trace towards it; we want to find everything in the box instead, okay? How do we do that? Well, we have our proximity volume. We'll drag it out so we have our reference. We get overlapped, get overlapping actors.

this will, when we press the e key, get us a result of overlapping actors of a certain type. Now, this isn't very good for us because, in the example we talked about with our box and our sphere, those two classes we imagined didn't have a very clear inheritance to them, which made it so that we could inherit functionality instead. So, what we want to do here is something of a little bit of a wide net instead. We wanted to say we want to pick a class here which is encompassed by both of these objects, and we know that all objects in the world are of the type actor. So, let's see, is it by default actor? No, there we go. Okay, so we say anything that is of the type actor in this volume we want to pick up. Okay, what do we want to do with it? Well, we want to go through every object and say interact with it. Okay, how do we do that? Well, we have this array, we drag off on connection and type loop, we get a for each loop, we connect it up with our event.

So this will go through our event, our array of results, which could be zero, it could be hundreds. Regardless of what it is, this isn't something we need to check like before. We need to check if a result was valid with the getting of a certain index, because if this loop contains zero results, it won't loop in the body, and it won't actually calculate on it. It will just go completed, which means that it's a bit safer in that regard. But what we want to do here is we want to interact with each of these elements in here, okay? So let's go and say interact with message, and then we can type a print string here just to say interaction completed, meaning that we have gone through all of the results. And we'll see if we have an empty result. We will just get this printed. If we have more than zero results, it will interact with all of them, and then it will print. So let's go try this out. We go back into the map, click play, we walk up to the box.

It should be within our volume that we have in front of us now. So, if we press the E key, you can see the box has been interacted with, and the interaction completes. Go up to the sphere, we do the same thing, sphere blueprint interacted with, and completed. Okay, so now why does this work? Well, the only thing we did was we chose to use a volume around the character or in front of the character to determine which objects were interesting for us. From those objects, we decided to send the interact message with. So, all of them that have the interface interact with will be actually interacted with. So, the thing we replaced is the actual line traces. So, this is a matter of what kind of preference do you want to have, how do you want to gather the references of the objects that you want to interact with, but the actual interaction part is the same. There are pros and cons with this. This, for example, with the line trace would be more precise. It would be something like the middle of the screen, and you can aim for something and say

you want to interact with that specific thing while this thing would actually interact with everything in a certain area. Meaning, if we go back to the map and we go and move our sphere to be just next to where the box is, and we play and we walk up to them, so we have like sort of both of them where the volume is most likely gonna be, and press e, we'll see both of them appear here. So let us use the door that we modified slightly. We'll put it into the world, but we do know that, excuse me, that we can't actually use this door right as it is right now because nobody's actually calling this interact event. And our functionality currently is that we need to interact with objects that actually have the interface available. So we need to start with adding the interface to this class by clicking class, class, class of things, adding it under interfaces, interacts, and then we compile and save. And then we'll open up the interface over here. We'll implement event. Then we say if someone interacts with us.

We want to run our interact function, which now that I look at it, also has an error in it. Because a door that is opened and we start closing should also be changed to not being opened afterwards. So what we'll do is we'll drag out this is open and we click set and we'll set this to what we can do is we can take is open, get a reference to that, drag off a connector, and type in not boolean. What this means is whatever it is set us currently here, it will take the opposite. And then we can put the inset here. And since this is supposed to happen for both of these executions, we can actually connect them like so. So that means if the door is open, we go here, we start closing the door, and then we set it to the opposite of open, which is closed. So then if we get interacted with again, we go in here and says it's open, it's false. It goes in here, it opens the door, it sets is open to the opposite of false, which is true. So it is opened.

compile save hope that made sense. Let's try it out. So, we walk up to the door. We should be within range now, and we press the interact key. It opens. Now you can see that it said interaction completed despite not saying anything else, and that's because this door is actually only reacting by opening the door. It doesn't print like the other ones. You can also see that you get an interaction completed, and then the door closes long afterwards. And if we go and look at the door opening, it is most likely yes, the length of this timeline is we have an animation running from two seconds four to two seconds from zero to two, but the actual length of the timeline is five. If we change this to b2 so it better matches our animation and go back, this should be more responsive now. It's opening, and we can close it midway, and open, close, and open, close however we want to do it. The very last part we're going to talk about today when it comes to blueprint communication is something called event dispatchers. Event dispatchers could most easily be

be exemplified by a newsletter. If you subscribe to a newsletter for something, I don't know, a movie company or something like that. What you do is they are the senders. They are sending out the newsletters. You are the receiver of the newsletter. They are sending this newsletter regardless of who, how many, or how few are actually interested in it, basically. So, what you do is you say you want to be added to a mailing list. So, when this mail gets sent out, it sends to everybody who has assigned themselves as interested in knowing about this newsletter event. Dispatchers work the same way. You have something that executes some functionality, and it creates, it dispatches an event, and everybody who has said that they're interested in knowing when this event happens can then have their own event available, which will trigger each time the sender's event is called. So, they have a reactionary event, sort of similar to how interfaces have the same interaction, can work in very different ways depending on the different objects, these other objects that are interested in knowing this.

event being dispatched can themselves react in completely different ways to this information as well. Now, to be able to sign up to a newsletter like this, you need to be aware of this fictitious company that is sending the newsletter, right? So, the sender has nothing to do with setting anything up; it just sends the newsletter. It's up to everyone else who's interested in it to sign up to it. So, the receivers are the ones who need to get the reference to the sender to get this to work, and there's a multitude of ways to do this as well. You can either, at the start of a creation of an object potentially, you might have a reference to it, and then you can say, Oh my, I also want to be listening to this event dispatcher that this object has, or it can be created dynamically in runtime. [Music] Let us create an example that creates this in runtime so you can see what it looks like. So, to do this, let's do some changes and build upon what we have already done.

um, let's do this. We'll open up the interface interacting, and we will add an input to this, which will be of the type player interactor. We can name it, and we'll make this of the type first-person character object reference. So, what this means is we'll say that this interface, now that is sent to all of these objects that are interactable, will also get this parameter sent to them. Now, this is a parameter that we send into the interface. So, the sphere, for example, here, now you can see, has a player interactor available here, but it doesn't need to use this information if it doesn't want to. So, for the sphere in the box, we might still want to just like type the information that we had before, circuit blueprint interactive with them and such, and everything will be fine. The important parts to keep in mind here are where we're sending this information. So, if we were to do this, we press E here, we get everything in our volume, we go through everything, and then we send our interact message through the

interface here. Some of them might not want to use player interactor, but some of them might. So, it's important that we make sure to send the information so that those objects that want to use this information actually have this information. So, this is a type of reference to the object of this blueprint that we're in now, the first-person character. So, what we can do is we can drag off from the player interactor. We can just type in self, so this will send a reference to this interface that we are the ones who interacted with. You. That will compile and save. We should do this in all these cases now since we have altered the interface. Those were all the ones we had just to make sure that we don't have a situation where we try using this and then all of a sudden we don't have the information being sent in and things break down. Okay, so now we're sending the information. So, now we want to use this information somehow. Well, let's go to the door. No, let's start off with creating our.

event dispatcher. Our player first-person character is the one that will be acting as the company in our scenario, that's sending the mail newsletters. So, we'll go here to event dispatcher, we'll click, and we call this jump performance, and then we compile and save. So now we have the event dispatcher available here. So, we want to sign up for this event now somewhere. So, we go back to our door, go to our event graph, and we'll say when someone interacts with us through this interface here, then we want to say that this person is of interest to us now. We're gonna start listening to its newsletter. So, we'll take its player interactor here and type jump performed, and we'll get a bunch of different options available to us here. So, the one that's interesting for the receiver here now, which is the door, is that it wants to have bind events to. So, what it says that it will first do the interact part, and we'll do the binding from this player reference that we have here. We'll create a custom event.

this will be a jump has been performed. So, this is our event that we want to have trigger when a jump has been performed. So, we'll hook that up here. So, that means that when we get interacted with, we bind to its newsletter and we say that this is the event that will trigger whenever that newsletter is being sent. So, what we say here is we're gonna say the player that opened me has jumped. Exclamation mark. Compile. Save. So, theoretically, now if the player jumps after having interacted with this door, this event should trigger and it should tell the whole world that the player that opened it has jumped now. So, now we have the actual receiving part done. Now we need to do the transmission or descending part. So, we'll go back to first-person character and we need to hook into the fact that we're jumping, which we can find over here. We'll drag this whole node away so we have it where it's interesting for us. Okay, so when the input action jump happens, it has a press and it has a

release when it's pressed. It starts the jump function, and it's released when it. Then it's the stop jumping appears. What happens so what we want to do is every time it is pressed. The jump is pressed, then we want to call our event dispatcher saying the newsletter is being sent out. And everybody who's listening, you're now getting it. So what we will do is we will drag a note out here and say jump performed, which is the one we see in the bottom left here. And we want to do a call. There we go. So this is the point where we say send newsletter of jump performed. And everybody is interested will get their ping saying ah the newsletter is out. And then they can act however they want. Compile and save. Let's try this out now. We go to the map, click play. So if I were to press e now, nothing happens because I'm out the range of the door. If I press jump, I jump. We get no message. We go up to the door. We press e to interact with it.

interaction is complete. Now the binding should have occurred that it's now interested in this character's event of jumping. So, if we move away, we press jump again. The player has opened me as jumped. So, every time I press space, which is the jump key, the door is telling the world the player that opened me has jumped. This is how events dispatchers work. Now, we don't want to have objects sitting around listening all the time to different things. So, what we want to do is at some point, we most of the time come to the conclusion we're now no longer interested in listening to a specific object. So, if we hear on the interact door gets the interact with call saying we opened or closed the door, and then we bind the event to jump, and then we when we get a jump, we print the string. This might be something that we're just interested in once, for example. So, what we can do then is once we have gotten our very first ping of the player having jumped, we also unassigned to this newsletter.

making sure that we don't take into consideration it in the future on the player reference again. Jump performed and unbind event from jump performed. This became a little bit messy. Let's learn some new things. If you double-click on a connection string, you'll get this happening. The yellow outline, which means that it's currently marked, allows you to drag the node around. This is called a reroute node. Double-click again. I'll make another one. This way, you can clean up your connection nodes a little bit. There, it looks a bit tidier. So, we get interacted with. We do the opening or closing. We bind the event. When the event happens, we react to it. We print. Once we have printed, we say we're no longer interested in listening to this newsletter anymore, and it should never be triggering this again. So, compile, save, go back to the map, play. We jump. Nothing happens. We go up to the door. We interact with it. We go away. We jump. It notices the jump. We jump again. Nothing happens. We go up here again. We interact.

it should have bound it again. We jump. It should have unbound. Now we jump. Nothing's happening. So that's how you keep things clean, so that you don't have everything listening to everything at all times. You just kill off the connections as you deem it necessary and when they're no longer needed anymore for your purposes. So let's take a moment to reflect over what we have done so far. So in the first part, we found actors by class and then we tried to communicate with them on functions and events that they had on that class. After that, we moved on to interfaces, showing how they can be useful in different situations when we have similar functions that need to be called upon different objects that don't have a clear, coherent inheritance structure for them. After that, we went into line tracing and managed to grab objects by sending out our line traces in the world and then acting upon them. After that, next, we moved on to making a collision box for our player, which allowed us to find everything within that box and interact with.

objects in that way, and lastly, we finished off with event dispatchers, making these newsletters which other actors couldn't listen into and then react to accordingly. Well done if you made it so far, hopefully found this video helpful. If you liked the video, leave a like. If you did not like it, leave a dislike. Leave any suggestions or comments down below. Subscribe if you want to see more videos like this in the future. In the next video, we will be looking into user interfaces. That is all for now. Keep on learning. Take care.

Beginners tutorial #6 - Blueprint communication part 2 - Unreal engine 4

LeafBranchGames

블루프린트 통신을 위한 인터페이스 사용

인터페이스는 언리얼에서 여러 가지 다양한 오브젝트와 통신할 수 있는 솔루션을 제공하여 수많은 개별 캐스트가 필요하지 않습니다.

인터페이스를 구현하면 오브젝트가 특정 파라미터를 받아들이고 특정 방식으로 작동하도록 약속하여 일관된 상호작용을 할 수 있습니다.

이 튜토리얼에서는 블루프린트 인터페이스를 생성하고, 이를 다른 블루프린트에 추가하고, 인터랙션 이벤트를 구현하여 오브젝트 간 통신을 간소화하는 방법을 보여줍니다.

인터페이스 및 콜리전 볼륨과의 상호작용 구현하기

1인칭 캐릭터의 상호작용 로직은 라인 트레이스를 사용하여 객체를 식별하고, 인터페이스가 구현된 경우 해당 객체에 인터페이스 메시지를 보냅니다.

이 접근 방식을 사용하면 공유 상속 없이도 서로 다른 오브젝트 간에 유연한 통신이 가능합니다.

또한 박스 콜리전 볼륨을 캐릭터에 부착하여 주변 오브젝트와 상호작용하는 방법을 제공하므로 각 오브젝트 주변에 개별 볼륨이 필요하지 않습니다.

블루프린트에서 커스텀 도어 인터랙션 구현하기

새 로직을 테스트하기 위해 원래 문 청사진의 복제본이 생성됩니다.

근접 볼륨 및 관련 이벤트는 제거되고, 문 기능을 처리하기 위해 "문 열기" 및 "문 닫기" 두 개의 커스텀 이벤트가 생성됩니다.

문 상태를 결정하기 위해 "is open" 부울 변수가 추가되고, 지정된 볼륨에서 겹치는 액터를 기반으로 문이 열리고 닫히도록 플레이어의 상호작용이 트리거되도록 설정됩니다.

게임 내 오브젝트와 상호작용하기

이벤트 루프는 유효한 결과를 확인하고 각 요소와 상호 작용하여 결과가 0인 경우에도 안전하게 실행되도록 보장합니다.

인터랙션은 캐릭터 주변의 볼륨에 의해 결정되므로 라인 트레이스가 필요하지 않습니다.

문의 상호작용 기능은 반대 부울 값을 사용하여 상호작용할 때 열림/닫힘 상태를 토글하도록 수정되었습니다.

블루프린트 통신 및 이벤트 디스패처

도어의 상호작용은 애니메이션 타임라인에 의해 트리거되어 반응형으로 열고 닫을 수 있습니다.

이벤트 디스패처는 발신자가 이벤트를 브로드캐스트하고 관심 있는 수신자가 이에 반응하는 뉴스레터 시스템에 비유할 수 있습니다.

수신자는 이벤트에 등록하기 위해 발신자에 대한 참조가 필요하며, 이는 객체 생성 시 또는 런타임에 동적으로 수행할 수 있습니다.

게임에서 플레이어 상호작용 구현하기

상호작용 가능한 모든 오브젝트에 플레이어 인터랙터 파라미터를 전송하는 인터페이스가 생성됩니다.

플레이어 인터랙터는 이 정보를 사용하도록 선택할 수 있으므로 유연한 인터랙션 시스템을 구축할 수 있습니다.

플레이어 캐릭터에 이벤트 디스패처가 설정되어 알림을 보내고, 문 오브젝트는 이러한 이벤트를 수신하여 플레이어의 인터랙션에 바인딩하고 응답합니다.

점프 액션으로 이벤트 트리거하기

플레이어가 문과 상호작용한 후 점프할 때 이벤트가 트리거되도록 설정합니다.

1인칭 캐릭터의 점프 동작은 이벤트 디스패처를 호출하여 다른 오브젝트에 점프를 알리는 '뉴스레터'를 전송하도록 연결됩니다.

이 시스템에는 첫 번째 알림 이후 이벤트에서 바인딩을 해제하여 오브젝트가 무한정 수신하지 못하도록 하는 기능도 포함되어 있습니다.

게임 개발에서 이벤트 연결 정리

라우팅 노드는 게임 개발에서 연결 문자열을 정리하는 데 사용할 수 있습니다.

이벤트가 트리거된 후 바인딩을 해제하면 시스템을 깔끔하게 유지하고 불필요한 리스닝을 방지하는 데 도움이 됩니다.

이 튜토리얼에서는 액터 찾기, 인터페이스, 라인 트레이싱, 콜리전 박스, 이벤트 디스패처를 사용하여 오브젝트 간 효과적인 통신과 상호작용을 하는 방법을 다뤘습니다.