Common Events And (Not)Battle Events
- meetthemeese
- Feb 17, 2021
- 8 min read
Updated: Oct 6, 2022
[WARNING: Image-heavy post]
I am back with another tutorial! Took a break because I got caught up making the demo game, and now I'm taking a break from making the game, so.
Speaking of said game, I'm going to have to overhaul everything I'd planned for the demo and make it much, much shorter (like, with 4 to 6 maps at the maximum), otherwise these tutorials will never happen. I'll keep getting distracted by the frankenplot. So from here on, I will be building a new demo from scratch as I write these tutorials.
The premise of the story remains, though- Chester is out searching for his missing friend.
With all that out of the way, let's move on to the penultimate (probably) post on events!
Common Events
In the last post, I'd mentioned how common events could be used to spruce up our Dragonheart Dust item usage thing. In this post, that's exactly what we'll do.
But first, what are common events?
So far, we've only set up events directly from the map, by double-clicking on a map tile while in the events layer. This implies that effectively, all the events we've made so far are all part of the map. If you move out of that map, none of the events run anymore (until you return to the same map).
Common events, on the other hand, are not scoped to single maps. They are common to all maps (much like the switches and variables we've covered). That's the key difference between common events and any other events we've covered so far.
They're really useful for triggering events and features that we want to be available anywhere on the map. A good example of this is a quest log of some kind, or a choose-your-team feature. Basically, whenever an event needs to be triggered (trigger-able?) 'from anywhere in your game', try common events.
Today, we'll build a very basic quest log using common events, and additionally, we'll see how we can improve on our Dragonheart Dust use scenario by adding some text and sound effects once Chester uses it.
The QUEST For jUsTiCe
(lies ignored in an old, smelly book)
Ideally, you'll want the quest log to be accessible from anywhere in your game. And in order to cover the 'from anywhere in your game' requirement, we'll use common events.
1. Open up your game database and head over the last tab- 'Common Events'. Aside from the list of events-to-be on the left side, for each event, we see veeery few options - Name => a name for your event; Trigger => only 2 types of triggers are available for such events - autorun and parallel process: since they're common to all maps, common events are not actually present as a clickable tile or item on any map for your hero to interact with - thus only parallel and autorun make sense as triggers here; Switch => this makes up for the missing trigger types, and indicates that the event will run only if a specified switch is ON. Then of course, we have the big white space where we'll put our event commands in.
We'll need to think of how we want the log to be accessible. Is it an item? Or a spell? Maybe a menu item? The last one is too complex for a beginner's tutorial (and I also don't know how to do it lel), but the first two options are very common in RPGs.
We'll make it a spell. So let's switch to the 'Skills' tab in the database for now. Let's set up the skill, before I go over how I'm going to implement it.
2. Add a new spell to the list - let's call it 'View Quest Log'. Let's change the skill type to 'Switch' and set the AP cost to 0 (this means the hero does not use any of his MP/AP/Mana to cast this "spell"). The rest of the fields are self-explanatory. We don't really need any usage message or sound effect here, but we do need to choose the 'Occasion' as 'Field', and select a switch in the 'Switch Toggle ON/OFF'.
Click on the 3 dots next to this option and create your switch as usual to select it. Hit apply, and we're done!
3. Now. What is this skill going to do, exactly? There's a couple of different, easy things we can do here.
i. if you don't have very many quests, or if you just want to keep a track of where your hero is at in the main quest, simply display a message box with the right text! You can even use the 'Show Choices' command (tab 1, column 1) to list out all your quests, keeping one option as a 'Next Page' kind of button, and one option to exit the log book (i.e., end the event). Theoretically, you can have any number of quests listed this way, but it'll get cumbersome when the list is large.
ii. even though this is a demo game with 0 sidequests, I'm going to walk you through another more fun, yet just as simple, way to set up your quest log. Once the player uses the skill, we will transport them to another map, and allow them to click on NPCs or similar events to get an update on the quest. Not only is such a page easier to maintain and navigate, it's also easier to make quest logs visible/invisible depending on whether the player has started the quest or not.
With that said, let's move on to setting up this new map of ours. Make it up as you want to, however large you want to, and place 2 events there for now - one which will have info about our main quest, and one which will allow the player to exit the "log". Here's what I've set up. I highly encourage you to make your Quest Log map look less like an actual map, and more like a book or page or scroll or similar. For reasons of abject lack of creativity on my part, mine looks like a normal location map.
The thing marked 1 is the NPC that is going to update Chester on his main quest, depending on where in the story he is at that point. 2 is the "exit" button that'll return Chester to where he was before he chose the Quest Log skill.
Let's set these up one by one.
4. First - the NPC. This is pretty straightforward, once Chester clicks on it, we'll show a message box with some text about his ongoing search for his friend. This is a perfect place to both remind the player what their objective is/how much of the quest they've finished, as well as drop hints to the player.
Not those kinds of hints. Hints about where they should ideally look next.
Yes, I know that was a bad attempt at a terrible joke. I'm low on vitreous humour in my eyeballs today, they feel parched. So, bear with me.
Yes that's right, another bad pun that may as well have flown over your head.
That's it. That's the NPC.
Typically you would be setting different switches and variables to control other aspects of your game as your story moves along. You can use the same switches in a 'Fork condition/conditional branch' command (tab 3, column 2) to switch between appropriate dialogs here too. We'll see that when we get to such a 'turning point' in our story.
5. Now the exit. We need to ensure that on interacting with the exit event, our hero goes back to where they were. But where's that, you ask? That's where a couple of nifty commands come in play - 'Get Player Location' and 'Move to Variable Location' (tab 2, column 1).
Whenever the player uses the skill, we will first save the player's location into 3 variables (one for the Map ID, one for the player's current X co-ordinate on the map, and one for their current Y co-ordinate). Only then will we transfer the player to our Quest map.
On exit, we'll use 'Move to Variable Location' to transfer our player to the Map and tile we just saved.
The first part will be in the common event. Let's work on the second part now.
Add a 'Move to...' command and create your variables in this dialog itself. Remember their names as we'll need to use them in the common event later on.
Aaaaaand that's it really. That part is done. I've added a few graphic- and sound-related commands as well before the player gets transferred because my exit event is an actual physical switch on the map.
Now we just have the common event left.
6. Go back to the DB and switch to the 'Common Events' tab. Give your event an appropriate name and set the trigger to 'Parallel Process'. Now we select the switch condition that will trigger this event. And the switch is - you guessed it - the same switch we set up our 'View Quest Log' skill as!
Now let's add in the commands we want to trigger whenever the player uses this skill - i.e. i) save player's current location with 'Get Player Location' (tab 2, column 1) - using the variables we set up in the previous point, and; ii) transfer to new map ('Transfer Player', tab 2, column 1). You can even add in some visual effects or sounds before you transfer, if you want.
The very important thing here is that you must turn the triggering switch OFF in the common event itself. Otherwise the common event will always run in parallel for as long as the trigger switch is ON, and you'll be stuck in an endless teleportation loop.
7. The last thing we need to do is make sure our hero knows this skill at the beginning of the game itself. Go to the 'Actors' tab in the database and add this new skill to the hero at Level 1.
And it's done!
We can now test this with a test play and see if it works. Try calling it from any map (you have added more maps by now, right?), and you should be able to land up on your Quest map correctly.
BONUS: Sprucing up the Dragonheart Dust event.
From what we set up in the previous posts, when the player uses up the Dragonheart Dust, nothing happens. No sound effects, no messages, no flashing lights or growling thunder, nothing. Not until the player interacts with the thcief again (and said thcief runs off). It would be much less confusing if, on using the item, some indication was given that the player has successfully consumed the item. It could even be a simple sound effect.
Let's do this with another common event then (since the player can be on any map in the game when they decide to use it).
By now, you would've probably figured out that we can set this event up exactly as we did with the Quest Log common event above. The main difference here will be the trigger switch for the event. In this scenario, whichever switch we have set up the Dragonheart Dust item as, is going to be what triggers the event.
In my case, in this new demo, it would be a switch called 'duped'. If you've forgotten what you used, just head back to the Items tab in the database and see what the switch is named.
Once you set that up, put in your sound effects and what-not and turn off the switch at the end.
There's a little catch though. Remember how I'd mentioned above that you need to turn off the trigger switch at the end of the common event itself? Well if we do that here, then the page on the Thcief event that depends on this switch will no longer work, and our Thcief will simply break.
So set up a new switch that you will replace the original item-switch with inside your Thcief event, and modify the Thcief event to now use this new switch. It only needs changing in 1 place, if you've been following this tutorial exactly.
Now revisit your Dust common event, and ensure you turn ON this new switch before the event ends.
Tada! Mission accomplished!
Here's what I set up. I've changed the event type to 'autorun' so that the player (and any other NPCs/events) will not be able to move around while the messages are playing, but you can stick to parallel process as before if you want.
Next post, we'll take a quick look at battle events, just for completeness. We'll look into battles in more detail in a later post.
L8ter, h8trzz,
- Moose In The Midst Of An Existential Crisis
Comments