DYNAMIC LISTS AND INDEXES

Dynamic Index/List in 2000/2003

Prerequisites: Understanding of the use of Switches.

Difficulty: Very Easy

Examples of Use: A bestiary that updates with new encounters. A list of important NPCs that updates as you meet new people. A quest journal that updates as you acquire and complete missions.

Dynamic - /dīˈnamik/ (of a process or system) characterized by constant change, activity, or progress.

I will be showing you how to make a dynamic list that the player can access at any point during the game. I will be teaching this system by explaining how I made a bestiary in my most recent game.

What you will need:

1. A sufficient number of switches to match the number of objects you want to list. I set aside two pages of switches for this and up to this point, have only used half of a page. If I continue development on this game, I expect to use most of the rest, and could go over.
2. An equivalent number of extra slots in the Actor menu to list the names of the objects.
3. One variable for the Key Input function.
4. Two common events.

Procedure:

Start by creating your main common event, the actual list you want the player to access. Set it to parallel process. You can decide whether or not to tie it to a switch. I didn't care when the player was able to access, so I didn't use a switch.

Set Key Input Processing and create a variable for it. You can set it to any key you want, but I recommend a key that the player doesn't use in normal gameplay. I chose the NUM1 key. In Key Input Processing, the numbers are assigned values of 10-19, with 10 being the NUM0 key, and 19 being the NUM9 key. So, NUM1 would be 11 in Key Input Processing. This is called by your variable.



Your common event should looks something like this.



I'm assuming that you have created all of the objects you want to list. In the case of the bestiary example being used here, that would be creatures in the enemies list of your database. In your Actor Menu, simply list all of these objects.

As follows:



Back in your main common event, create a conditional branch. Set that conventional branch to trigger on your Key Input variable. I set it to look for NUM1, so I set it to 11. Inside this conditional branch, you can handle the details however you like, however, here are the important details:

The player has to have a way to select specific entries. The easiest way is the “Show Choices” function, which is what I used. I made this manageable by assigning creatures to specific regions, so that there would be only three or four creatures to a region. This let me put the regions in their own “Show Choices” menu. In the show choices menu for the actual objects, don't list the object names directly. Instead list their Actor tags. So for choice one, based on my pictures, it would be \n[6], then for choice two, \n[7] and so on. This way, if the name changes in the database, it will also change in your list.

In each choice selection for the object, place a conditional branch set to trigger if your object switches are on. So if you've done a bestiary in the manner I've suggested, you'd have something like this.

Show Choices
Region 1
>Show Choices
>>\n[6]
>>>Condtional Branch
>>\n[7]
>>>Condtional Branch
>>\n[8]
>>>Condtional Branch
>>\n[9]
>>>Condtional Branch
Region 2
>Show Choices
>>\n[10]
>>>Condtional Branch
>>\n[11]
>>>Condtional Branch
>>\n[12]
>>>Condtional Branch
>>\n[13]
>>>Condtional Branch

Etc. etc.

To be clear: These are your list entries. Show Choice option>actor tag>conditional branch. Every time. Consistency and repetition is key, here. This is a list, after all.

Individual Entries:

With each object you add to the list, assign a switch to that specific object and include it in each of your conditional branches for the list entries.

Meets a new NPC – Trigger a switch specific to that NPC in the initial dialogue event.
Encounters a new enemy – In Troop Events, have an event set to turn 1 and trigger a switch specific to that enemy.

Each unique object must have its own switch, and you must turn that switch on during the initial encounter. In addition, whenever you turn on a switch, immediately after, use the Call Event command to call the second common event that we'll be creating below.

For each entry in your show choices list, create a conditional branch and provide details in that branch. Here's an example of an entry from my bestiary.



In this example, I checked to see if I had encountered an enemy, the Soma. If the switch is on, I show a picture (the creature's description), use the Key Input function to wait for the SHIFT key, display a second picture (the creature's stats), and wait for the shift key to completely end the process and let the player continue on their way. If the switch is not on, you get a message telling you the object is unknown.

Here is a screencap of mine where you can see one whole entry and most of a second.



Just rinse and repeat. For each show choice option, make sure it's name is an Actor tag, and just keep repeating these conditional branches.

This, on its own, is enough to create your list. You can simply add choices and entries to this common event as you need to. You're done with it. However, so far, there's no way to hide the names of your objects. This is why we did this with the Actor tab. Events contain a function to change actor names.

Create a second Common Event that updates your list. Name this whatever you want. I named mine “Animal Handling”. Whatever it is, just name this something that reminds you that you're using it to update your list. Set it to “none”. This is an event that gets called. In every instance where you turn on a switch for your list, immediately after, call this event.

1. Talk to new NPC>Switch on>Call Update Event
2. Encounter new enemy>Switch on>Call Update Event
3. Etc.
4. Etc.

In the Update Event, every entry, once again, gets its own conditional branch. Once again, it's waiting to see if you've turned that object switch on.

In that conditional branch, if the switch is on, change the name of the associated Actor to its correct name. Else, change the name of the associated Actor to “???”.



That's it. Every entry should look like that. Your update event is just a list of conditional branches that are checking to see if every switch is on and is changing the names. If you're using actor tags, this will be reflected in the list the player sees.

Except for names, your Update Event should look exactly like this.


And that is it. We're done. In action, it will look like this.