general purpose journal plugin (includes a description of the data structure)

[Andar]

The biggest problem for creating a general purpose journal/encyclopedia script or plugin has always been the question of how to enter and organise independent data.
It is easy to make an encyclopedia based on an existing database tab like items or enemies, but encyclopedias for independent world lore like town- or NPC lists have been difficult to enter without programming knowledge to place the data into the code itself.
And for that reason even the existing journal scripts for the makers (MV, Ace and olders) are rarely used.

This plugin is to change this by using a pseudo-map and events as a way to enter that data by the editor, details on that will follow. I'll describe the entire logic structure as I think it should be possible, but lack the time and RMMV-knowledge to implement it myself.


List of needed plugin commands and script functions
All parts described below needs to be able to do by plugin commands (for easy eventing) and by script function (for connecting with other plugins) both

1) set title description
A command to change a plugin property that holds a sentence to describe the active journal.
This sentence will be displayed in the title window of the journal screen.
The game developer needs to be able to change it before calling the screen to allow for different journals to be used

Example:
Plugincommand setjournaltitle "The Library of Skytown - which book do you want to read?"
Script setjournaltitle("The Library of Skytown - which book do you want to read?");


2) Open Journal with single map ID
A command to open a three-element screen based on the data of a single map.
The three elements are a title element (on top, static, contains the journal title and optional the map title), a list element (left side, one line per event on the map) and a content element (main part right, to display details and texts of the entry).
The function to open this needs to be written in a way that allows inclusion in for example a menu manager to call this screen from the main menu.

Example
Plugincommand opensinglejournal 127
Script opensinglejournal(127);



3) Open Journal with multiple map IDs for categories
A command to open a four-element screen based on the data of multiple maps.
Three of the elements are identical to the description above. The fourth element is a category list below the title element but above the list/main elements.
The category list will display the map names as categories from left to right to be able to be selected before the list element is displayed.

Example
Plugincommand opencatjournal 128 129 135 141
Script opencatjournal([128,129,135,141]);

4) set "unknown" default text
The plugin needs an default text that is used when an entry is still inactive and the player cannot know what it is.
Default should be set as plugin property to something like "?????", but the developer should be able to change that based on what kind of journal he wants.

Example
Plugincommand setinactivetext "unreadable booktitle"
Script setinactivetext("unreadable booktitle");

5) choose to display IDs
Some encyclopedias are better to read with an ID-Number for the entry, and in other cases a journal would work better without, for example with a diary where the text of each entry is its date.
So the developer needs a way to activate or deactivate the ID display based on the journal called

Example
Plugincommand displayjournalID false
Script displayjournalID(false);

6)?
Whatever the plugin writer thinks might be good to add



Controls on the journal screen

For the single journal screen, ESC should leave the screen and up-down should scroll the curser through the list element. On each up/down, the main element should update to the content of that specific entry (requiring an enter for updating would be suboptimal but might be neccessary to prevent lag - programmers choice, or give option as plugin property).

For the screen with multiple categories there should be a two-level control.
First level should be category selection - left and right for selecting a category, action button to confirm selection, ESC to close menu.
Second level should be entry selection - after the category is confirmed, the list element will be filled with those entries and the regular up-down selection will be working like the single screen. ESC will bring the player back to cat selection instead of closing.



How to store and read the journal entries
The plugin needs a modified copy of the regular mapload function. This modified function must NOT replace the current gamemap, but instead place the data loaded into the journal data structure.
I don't know if that should be done at the moment of the journal opening (which would have the advantage of versality and less memory use at the price of delay while loading) or if all journals should be loaded at "new game" (which would mean only startup lag and no delays on opening, but require a way to tell the plugin which maps are journals and requires more RAM).

And here is how the data of that map should be converted (which also explains how the developer will enter the data):
The display name of the map will become the category name to be used on the multicat-screen or (optional) the journal title to be used on the single journal screen
The tiles of the map will be completely ignored (although some developers might use that for themselves to help sorting).
Each event will become a single entry in the list element, with the eventID being identical to the entry ID if those IDs will be displayed.

If the event has no active page (no conditions fulfilled) then the element will use the "unkown" default and not count the event.
If the event has an active page (no matter if that is because of no conditions or because the conditions have been fulfilled), then the element will use the event name as the displayed text in the element list and count the event for itself.
At the bottom of the list element, it will display the counter as "active event count/total event count" (this might become an optional display).


When any of the entries in the list element are selected, the plugin will update the main content element using the data from the corresponding map event.
If that map event is inactive, the main element will be emptied (or perhaps display the unknown default again).
If that map event has an active page, the content and event commands on the active page will be used to create the contents of the main journal element.


This last part has to be done by a modified copy of the game interpreter. Most event commands here would be useless and should be ignored, but a few need to be available, especially:
show picture to place a picture into the background of the main element
show scrolling text to place the text inside the main element (it doesn't need to scroll, but the texts here are usually longer and would not fit into a single show text

In case of logical event commands (conditional branch, control variable, jump to label) this would need to be tested - these options would help, but if they create too much lag then they can be ignored)
Event commands for map or battle should be removed or ignored as they don't have a purpose here - although sometimes game developers might have ideas for them like an arena list that asks to fight against the displayed enemy or a magic teleport list to the town listed and so on.


---------------------------
That is basically the structure I thought of. I don't have the time or javascript knowledge to implement it myself (at my university time, Pascal and C/C++ were the current languages and I even programmed in assembler, but javascript was developed later when I no longer programmed things).

This structure should work however and allow the developer to use regular methods like "control switch NPC XY met ON" or "control variable herb knowledge = 7" to show the different entries into the journal by controlling which pages of the events on the pseudo-maps are active. Up to using hidden items to trigger those conditions if you don't want to use up variales.
This would also allow changing entries by multipage events, like an NPC getting a nice description until the story variable is high enough to reveal that he was the traitor.

And as I wrote in another topic https://forums.rpgmakerweb.com/index.php?threads/rmmv-codex.105082/
this plugin is not intended for myself at the moment, but for the community.
I only ask whatever plugin writer makes this to include in the comments something like "idea by Andar" with a link to my profile here or something like that.

 

[MushroomCake28]

Holy damn, this is actually a great idea and a great way of implementing it. It will however take a lot more time to develop compared to the regular menu data plugin. In theory this should be very versatile and fill most needs, although there will be a learning curve for people who want to use it.

Honestly I think all journal should be loaded at the start of the game, which of course means more RAM. But I don't think RAM is much of an issue, except if you're deploying for mobile. I always prioritize game speed when possible.

I don't think I'll be coding that system anytime soon, so if someone wants to do it, please do it. Otherwise when I have time I might consider maybe doing it (please note all the conditional words I used).

 

[gstv87]

just for clarification:

A command to open a four-element screen based on the data of multiple maps.

A command to open a three-element screen based on the data of a single map.

you mean *map*, THE *map*? the table with XY coordinates that the editor can access?

why would you use a map for that when you can code a scene?
from a developing point of view, anyone would choose to build something by code, rather than *code* something that can be accessed via a GUI only to use it to run *code* again.
if the module is well designed, the commands can also be designed to be user-friendly.

 

[Andar]

why would you use a map for that when you can code a scene?

Because 99% of all RM-Users can't code.
The entire purpose of this method of data transfer is to make people able to input data with the editor and without any coding knowledge.

This assumption of yours (that all people who make games can and should code) is something that you displayed in a lot of other posts and answers, but it is not the only option or completely correct. The RPG-Makers have always been targeted at people who cannot code and to allow them to make games without learning more than basic eventing logic, and this plugin is targeted to that group of people and NOT toward plugin writers and programmers that can modify the code to contain all data they want.

 

[gstv87]

Because 99% of all RM-Users can't code.

but they wouldn't need to code anything!
the coding involved would be comparable to adding a script call or a note tag: an ID of instruction, the instruction itself, and the operand (in this case, a string of text)
the difference being, they'd have to do it in a separate file or plugin slot instead of the database.... but the actual coding would be minimal.
and, the complexity of the resulting product would be much higher when compared to a plain map.

module database
 #user's side
  data = {
  [ID, title, value],
  [ID2, title2, value2],
  [ID3, title3, value3],
...
 }
end

class database_manager
 #programmer's side
end

if the database manager is correctly structured (and, the scene that makes use of it), the end-user doesn't have to change anything from it, only the information *IT* deals with.





a note tag doesn't have to be *the* intended tag.
you can set it so that the note tag goes back to the database and pulls "whatever is written in the database"... and if you do it correctly, you don't even need the note tag at all.

(but you have to code the manager to account for that: user input based on a module, and the module separate from the plugin itself.)

 

[MushroomCake28]

@gstv87 It's a lot more visual and easy to see the big picture with the event system on a map in my opinion. But yeah, the method you describe is what I use in my public plugins.

 

[Andar]

but they wouldn't need to code anything!

They still need to open the javascript file in a text editor and write into the code.
And there are too many RM-Users that are simply afraid of doing that.
And as an example just check VXA's Quest Journal by Modern Algebra - that did exactly what you describe, and as a result was (and is) considered to be among the most difficult to use scripts of VXA with dozens of help-topics where nothing works exactly because the people were unable to keep the array structure needed to make the code work.

Now add to that the fact that using the entile multipage and condition structure to control which part of the entry is displayed, and your data entry into the code would be much more complex than a simple crafting script line as you've given in your example.
Just think about that level of complexity - some journal entries would be activated by a control switch (NPC met), others would be controlled by a value (if herb lore is 1, display simple text 1, if herb lore is 5, display text 2, if herb lore is 12, display text 3 with additional hints), or entries controlled by hidden items (condition if item exists) and a lot more.
getting THAT into a code structure would be a mess of its own, but the code to select the active page already exists for events and would only have to be modified.

 

[gstv87]

They still need to open the javascript file in a text editor and write into the code.

but not the code pertaining to the actual plugin!
if you do it this way, there's no way anyone would be afraid of damaging anything from the plugin.
that's one capability of JS (and, Lua,.. and Ruby) that you can add things to the code without adding them *to* the code, but rather *on top* of it.

nothing works exactly because the people were unable to keep the array structure needed to make the code work.

that's the coder's fault, not the user's.
if the maker didn't make the plugin thinking about the simplest way for the user to work with it, that's the coder's own fault, not the user's and certainly not the plugin's (provided IT works as intended once the correct structure is used)
if the plugin works as intended, then the user side can be modified to allow for more flexibility, but if the plugin itself doesn't work or the users don't consider it adequate for their games, modifying the user end it's not going to make the difference.
and, therein lays the matter: the map/event implementation doesn't have the flexibility to receive user input as plain code does, especially when it comes to string objects, which is what you're trying to move when dealing with a *journal* object.
if you use a module, you can write the hole Bible in it, and it'll still be one single string.

 

[Andar]

if you use a module, you can write the hole Bible in it, and it'll still be one single string.

Why should the developer bother with that distinction? If you read what I wrote about using the scrolling text command then you see that even with events it is a single large textbox entry to be used.

Additionally, why do you focus on static entries and static entries only? One additional advantage of this method is that it will have dynamic entries that change on event conditions. I already asked you in my first answer to you above to try to do that in a code-based data structure, and all you answered with is "but I can write static strings of any length".
But connecting those strings with the entire set of possible conditions in a text-based entry instead of the event-based entry I proposed will break that "easy input" that you think of with your text lists, not to mention that it will allow the engine itself to check for correct conditions and direct control by event commands.

 

[gstv87]

One additional advantage of this method is that it will have dynamic entries that change on event conditions

each individual string is always static.
whether or not *it* gets picked by the system, will depend on the system itself, and the events of the game... but you still have to write down all possible combinations, for the odd case where the player will unlock all possible combinations.
and when it comes to writing strings, the in-editor tool is much more limited than direct code!

it all works down to what you want to display, and how the end user will load that information into the displaying frame.
if it is *strings*, then use the tool that'll allow you the most flexibility, and upon *displaying* time, go with the system that both manages those strings more easily, and also allows for more complexity of the design, on the coder's side: a *map* doesn't allow you that.
it allows you for more flexibility *on the user side* regarding the display, but it also takes off flexibility *on the user side* regarding the management of strings, which is what the whole thing is about.

 

[Andar]

@gstv87 you still don't understand.
This plugin is NOT about handling strings. It is about handling a data structure that contains much more than strings.

whether or not *it* gets picked by the system, will depend on the system itself, and the events of the game

THAT is what this plugin is about - to automate that system that handles what is being displayed.

This is the most important aspect of the entire idea - to handle the selection what is being displayed when and where, without dozens of different script functions to activate or deactivate different strings.
If you want you can simply use an external text plugin to redirect the text entries to external text files - that wouldn't matter here.
What matters here (and what you have completely ignored several times now) is NOT the content of the strings, but how to manage their display conditions from the game/editor level.

And it is a fact that it is almost impossible to get that number of different conditions and their checks if they are correct within the game context into a simple text-based structure.

 

[gstv87]

but how to manage their display conditions from the game/editor level.

that's why I asked why you would want a map to manage the validations.

one thing is clear: upon a correct validation, one specific string will be displayed (or, multiple.... but 'multiple' is just an iteration of 'one', so if 'one' works, 'multiple' will as well)
-you still have to load ALL possible strings, because you can't know what path the player will take.
-you can build a more complex display for that final presentation through code, as opposed to through eventing.
and most importantly: -you don't need the event system to handle all that, all you need is the event system to output a value that you will then pick up with the plugin, and process, with the plugin, and display, with the plugin.

the eventing system, the only thing it should be used for, is for relaying instructions to the plugin.
it's up to the maker of that plugin to learn which kind of instructions the end user might want to invoke, and program the plugin to accept those, in a way that they will come in as a result of an output by the eventing system.
you don't use *the eventing system* to process the logic!

you can also design the plugin in a way that it will be customizable by the user: it's messy, it requires a lot more control structures to prevent the user from making a mistake, and it will still fail, because the users WILL make mistakes.
but when it comes to comparing the capabilities of tailor-made code, and generic eventing that will have to consider inputs they were never designed to take, .... I'll take code, any day, even if it is more work, why? because *the code can be changed*.
if you end up having to modify a specific control of the GUI to output the data you need, you won't be able to, because the GUI design is proprietary!

 

[Andar]

that's why I asked why you would want a map to manage the validations.

That is because the event structure already contains all the options for validations.

Just as an example, how would you enter and code the following things:

- if switch "NPC 123 met" is true, display string NPC_123_text, otherwise display "????"
- if variable "herblore" < 3 display string herb234A
- if variable "herblore" >=3 and <7 display string herb234B
- if variable "herblore">=7 display string herb234C
- if party has item47, display string portal47known, otherwise display "????"

Every other journal or encyclopedia script or plugin out there (those that aren't book-types from the database but for free entries) always has only script commands for activating or deactivating an entry, but never one to make that entry linked to specific conditions.
As a result the developer had to scatter his game with script commands to activate the entries when found, and had to create the event code for checking those conditions without any support structure at all - which is one of the main reasons why almost no RM-user has real world-lore encyclopedias inside their games.

With the structure described here, 90% of that event code is concentrated into one map for each list of lore-entries, and the editor itself contains several ways to test for integrity.
- journal entries based on variable values are directly assigned to them
- when basing a journal entry on switches or variables, you can directly compare the name of the switch or variable (with a code-based approach you either have no name access at all in VXA and older or would have to make a complex cross-check with the name storage of switches in MV)
- you can use hidden items to trigger the display of journal entries automatically (especially usefull if you have for example magic portals that need those items to trigger their activation anyway)
- the game developer doesn't need any script command to manage the content of the journals - he only needs to activate them and can use regular event commands for everything else (or even no commands at all if the conditions are part of his other event structures).

ANY try to get these conditional structures into code directly will always result in a much more complex array structure that is impossible to handle by most RM-Users, exactly because it will need at least basic coding knowledge. And that text would then never be cross-checked by the engine while using the event structure a simple cross-check by displaayed names instead of ID-numbers is automatic.

most importantly: -you don't need the event system to handle all that, all you need is the event system to output a value that you will then pick up with the plugin, and process, with the plugin, and display, with the plugin.

And that is exactly what my approach no longer needs directly.
As described above in my approach there is no longer a need for the developer to place the script command that creates this output and think on where or when that command is placed.
It will be mostly automated (in case of conditions that check for item possession or values that are used by the game ("herblore"), and completely event-based with name-checks (in case of activating the entries by switches or similiar variants).

 

[Aloe Guvner]

Interesting idea.

Is my understanding of the following example correct?

Spoiler: Example

Mock-up of output on the journal page

Assume that:
switch 3 = true
variable 40 = 11
variable Career Path = 1

I'm slightly uncertain on the format when multiple maps are used. Could you make a mockup / wireframe of a possible screen configuration in that case?

Is there a use case for the map hierarchy?

I'm almost wondering if it's easier to build a WYSIWYG HTML-based tool that integrates with MV, but this is certainly an interesting idea. Certain parts, like Show Picture positioning and text wrapping could be easier with such an editor, but the other parts such as conditional branches would be harder.

 

[Andar]

@Aloe Guvner 100% correct
Different maps would either be different journals (with single category journals) or different categories inside a journal (similiar to the switch between weapon/armor/item/hidden item in inventory).

And depending on what event commands the journal interpreter can handle in addition to show text or conditional branches, even more options could be asked. For example if it can handle control variable and change item, the journal could be a recipe book where the page asks if you want to create the displayed recipe. Or if it could handle battle processing it could be an arena list where it asks if you want to train against that specific enemy.

And so on - there is a reason why I named it "general purpose" and put a lot of thought into it.
Yes, it will be quite the task to get that journal scene with a modified load and modified event interpreter working - but then you'll have one plugin for everything instead of one enemy book plugin, one item book plugin, one crafting plugin, one lore-type plugin and more.