Event Systems

ruticker 04.03.2025 15:24:48

Recognized text from YouScriptor channel Timothy Cain

Recognized from a YouTube video by YouScriptor.com, For more details, follow the link Event Systems

# Event Systems Hi everyone, it's me, Tim. Today, I want to talk about **Event Systems**. These are some that I mentioned a while back in a video on NPC reactions, which I'll link below. Last Friday, I even mentioned NPCs triggering off each other, which talks about Event Systems as well. The first video, **LED Lemmings 19**, asked: *Would you be interested in doing a video focused on events, how they're triggered, how they're handled, how they work, exist in single-player versus multiplayer games like WildStar, caveats, issues, problems, technical or otherwise, and whatever else you think is worth talking about?* Sure! This is going to be probably aimed at programmers. I'm not going to give you implementation details, but any programmer who's had more than one data structures class will know what I'm talking about when I say, *Hey, you need to make a list of events.* Maybe you want an array, maybe you want a linked list, maybe you want a doubly linked list, maybe you want a stack, and you probably don't want a stack. Anyway, you might want a hash. ## What are Event Systems? Event Systems are basically a programmer's general event system, which is a list of things—events—to check to see if they should fire. There are systems that can put stuff into the event queue, and then other things that listen for an event to fire. They can listen to them by any kind of thing they want: by event type, by who caused the event, or by who the event is triggering on. I try to think about how this would vary in single versus multiplayer games, and the only thing I can think of is that most events have conditions under which they should fire. As long as one of those conditions is testing to see if the player is present for it—like if you want someone to react to a player who did something—they're only going to react if the player is present. So, in a multiplayer game, if another player goes by that NPC, it's not going to trigger because the other player isn't present. That's probably sufficient; otherwise, the Event Systems might be pretty similar. ## How Event Systems Work So, let's talk about how these Event Systems generally work. The event system is a queue of events. These events can be placed into the queue from anywhere in the game. Combat might do it, the skill system might do it, the dialogue system might do it. What kind of events do they put in there? They might put in, *Hey, something just died,* and the event includes its type, a timestamp, and a location. It almost always includes who caused the event—in which case, it's the thing that died. Based on what event type it is, it may include other data, like who killed me and did I see anything else around me at the time. All that can just get bundled up in the event data and stuck in the queue. You might also want to queue up if a skill was used successfully. For example, if someone picked a lock, you might queue that event. You also may want to record if it was unsuccessful—someone tried to pick a lock and failed—throw that in the event system. It may even be something as simple as the player sold an item. They went to an NPC who has a shop and sold an item; throw that in the event queue. All of this depends on your design. You want to be thinking about what you want the game, the NPCs, creatures, narrator, and anything in the game to react to. If you want it to react to something later, you probably need an event queue. One of the things here that your programmers are going to have to figure out with the designers is how exactly what event you need. For example, if you make the entire game and the only thing that you think needs an event when it dies are *cyy pigs*—because you're going to have a companion that gets really mad if you kill too many cyy pigs—you need to throw an event every time a cyy pig is killed, and it adds to some counter. When it gets high enough, the companion with you might say, *I can't believe you killed a dozen cyy pigs! You're a murderer!* If that's all you need, you probably just need an event: *cyy pig died*. However, if the design calls for reacting to different things dying—maybe it's a cyy pig, maybe it's this particular NPC who's the boss of a gang, and maybe there's another place where you need to count how many times a wolf is killed—then you probably need a general event, which is just *creature died*, and then part of its event data is what creature died and what type it is. The way Event Systems work is the event queue is checked every update. It receives an update, which, you know, in Unity is every frame. In Arcanum, it was a heartbeat that we kept on the... you know, and so things got a heartbeat, which could be anywhere from every 2 seconds to every 10th of a second. Events can be queued to happen immediately, and I'll tell you in a minute why you would still want to queue it even if it's going to trigger immediately. Others have times they should happen, like 5 minutes from now, or every Tuesday at midnight, trigger this event. This means the event, when it triggers, says, *Oh, I'm every Tuesday at midnight,* and after it triggers itself, it reasserts itself in the queue to happen again. Some events can do that; they can reinsert themselves. But some events will have conditions, like *I'm in the queue, and you should only fire me when the player camps* or *when the player enters this particular town, I want this event to fire.* So, there might be a time queue for events, a location queue for an event, and maybe even a camp queue if that's something that can happen anywhere and at any time. The location queue is checked every time the player enters a new location: *Is there any event waiting in the location queue waiting to fire?* And then when the player camps, it checks the camp queue. You don't necessarily need to do that, though; you can just have a general queue, and those sit at the near the front. Whenever the player camps, it goes, *Hey, is there any camping queue in here?* This is an optimization thing, which I'll talk about in a minute. Effectively, when a condition fires and an event meets its condition, it fires and is reported to every listener. That's the cool thing: events can have listeners register themselves when a system starts up in your game. It can say, *Hey, I want to be notified when an event in the queue meets this condition.* It might be, *I want to know when anyone dies,* or it might be, *I just want to be told when a cyy pig dies.* Depending on how you implement it, it may just have to be told whenever anyone dies, and then it looks itself to see if it was a cyy pig, or it may be able to register, *Hey, I want to know when this event meets this condition.* That way, the event system only calls the listeners for events that trigger their condition. It's up to your programmer how to do that, and it depends again on your design. The cool thing is one event can have multiple listeners that trigger for it, which means you can have one event in the queue, and it's like, *Oh, I need to call these three different systems that all cared about someone dying.* They can now be called for a certain event type or event specifics. You may want to register something saying, *Let me know whenever the player does something,* so the player is marked as the initiating event. Or it may be, *Call me whenever the player is responsible for something,* so the player is the one—it's not the event happening to the player, like someone died, but the player is the reason the event's happening. So, people might register listening for all kinds of things. The listener decides whether it wants to respond, and because maybe it was something it didn't care about, or maybe the reason it cared about it no longer exists—maybe it wanted to report it to an NPC who's dead now. If they want to respond, they can either respond immediately, or their response can be their own event, and this event might go back in the general queue, or it might go on their own event queue. ## Why Use Multiple Event Queues? This means we should probably talk about why you might want multiple event queues. You might have that public general event queue, and I talked about it; it might break up into a public location queue and a public camping queue, which is accessible to anybody. But there's also private event queues. These are queues that exist on a particular NPC, one of your companions, a boss, or a creature. There may even be ones in locations just for a location, so it's private to that location. The event can only update if that creature is currently loaded and active, or you're entering that location, and that means the NPC is probably near the player or is a companion in the player's party. You don't need to implement private event queues; you can have a general event queue that handles all of this. That way, you have a centralized clearinghouse of all events in your game, but it might be more efficient to have private queues. Again, this depends on your design. If you have lots and lots of events, and many of them are tied to a particular creature or a particular location, you might want to go with private event queues. This is an optimization that your programmer will have to decide to make after they see your design. See the video I have on how to do optimization, and designers, this is why you need to be as specific as possible when you make your design docs. If you give a half-completed design doc to a programmer and they look at it and go, *I don't see any need to have private event queues, so I'm making a general one,* and then later you're like, *Oh, by the way, I need all the NPCs, and especially bosses, to be able to respond to specific events,* and that tanks your game's performance, and then you get mad at the programmer for not foreseeing something you didn't ask for—that's on you. So, everybody should watch that optimization video. ## Benefits of Event Queues Let me tell you the two biggest reasons I like using event queues in my game. One, the designer will care about one, and the programmer will care about the design. One is event queues let you delay an event until a time or condition occurs. This is really great; designers will love this because it lets you do things like zombies spawn in this cemetery at midnight, or once the player has wielded this amulet, and as long as he's wearing it, these assassins will spawn occasionally as random encounters to attack him and try to get the amulet back. Designers love this kind of thing because it lets them have the game react but not immediately. Programmers like event queues because it helps with something called scope, where systems don't have to know about each other to work with the event system. For example, your skill system may know nothing about your AI system, but an AI may want to know, *Hey, let me know if a lockpick was successful,* because I need to tell nearby guards if they saw it. Now, the skill doesn't know anything about the AI system, so it doesn't want to call in every time you successfully pick a lock. It doesn't want to have to know, *I have to call this AI routine on guards; maybe I have to collect every guard in the area and call this routine on them to see if they care about this lock being picked.* They don't have to know anything about that. All they have to do is go, *Oh, the player successfully picked this lock. I'm going to put this event, this location, this time, this lock, this player, and they were successful at lockpicking. Boom, it goes on the queue.* Maybe it's set for immediate processing, and it calls listeners, and the nearby guards have set themselves to be listeners for that event. They're watching out for successful lockpicks. If that event comes in, every guard gets it, and they're like, *If I can see the player, if I'm aimed towards the player, and he's within range and he's not using stealth or whatever, boom, that triggers, and I can say, *Hey, what are you doing over there on that lock?* What's great about that is the skill system just posted in the event system, and the AI system had just registered itself in the event system. They both see the event system, and they know nothing about each other, and they don't care anything about each other. What's great about this is later, when the designers are like, *Oops, I forgot I wanted to add another skill to the game called disarm trap,* and I also want that to have an event pended for it, you can do it. The skill system can just... you can already talk to the event system; you just make a new event, throw it in there, and then whoever wants to listen to it can listen to it. This is why I love Event Systems. This is a very high-level description of how to make an event system. I've been using these for decades in my games. It really helps you create not just NPC reactivity but general game reactivity. Designers like it, programmers like it, and my guess is artists like it too. Even if they don't know about it, they like it. So, I hope this answered your question, Lemmings 19.

Назад

Залогинтесь, что бы оставить свой комментарий