Writing parser detailed

A lot of people were asking about this, how writing is made.

The goal for this sort of stuff from the start was that I would have easy to use tools so regular people I commission to do writing and make content will be able to get their writing in game.
Like the first post, about how the maps can just be made in Photoshop or another program that can save PNGs with an alpha channel, creating NPCs is simple too.

First of all, it seems that most of these games, the programmer(s) of them to break up the text and code in the logic for when said text should show. Or some of them just don’t have text like that.
What I did is write a parser that would parse “psuedo-code”, as well as some simple string substitution. It works like (if variable comparer string){show the text between these brackets}.
Anyone who has written something in a programming language with a C Syntax would get this right away, and if you don’t it’s very simple to figure out.

  • (if just starts and contains it all, and marks the pointer where to look for the ending curling bracket.
  • Variable is a variable with the character stats. Such as their first set of genitals, second, breasts, str/wis/fort/crsm stats, gender, and what ever else may be added.
  • Comparer is ==, !=, >=, <= meaning equal to, not equal to, greater than or equal to, less than or equal to, respectively.
  • String is whatever text the writer wants to put there that could match what’s in one of those variables

So, for example. “A woman behind the counter stood up. (if gender == female){“Hey, miss!” she greets, seeming happy to see another female}” would show only that first sentence for everyone, and if the player character’s gender is female.
Something like “(if lust >= 50){…}” would show that text only if your characters lust was 50 or higher.

The other part of it %descriptions. These are separate from character stats, and they just output a string.
%removingBottoms for example gets replaced with “unzipping and pushing down your pants”. In the future, I’m going to make sure the first letter on these would be capitalized when they are the start of a sentence.
These %descriptions can also be an array of strings instead of one string, so that you don’t get the same description of your character’s naughty parts every single time.

%descriptions are considered “safe to hack”, and you can modify them on the client yourself. The server does not care about them.
Writing for a scene is also sent as one big chunk. These comparers and string replacements are parsed on the client. With a mod, you could view more than what your character stats allow, or feed them to a wiki, to see those parts of a scene.

However, scene options, and functions that happen upon running a scene, are parsed on the server. A dialog could require strength greater than 4, and that data won’t be sent to the client unless the server has verified their strength is high enough. Same goes for requiring a quest, or an item, for an option or event. This stops cheating, while just being able to see different text outputs are considered harmless.
I may change it to have the options displayed but greyed out based on player feedback, though it’s a little more complicated.

That’s the writing part, and the dialog options part, but there is much more that goes into an Event, as I call them.
An Event are those boxes that pop up, which could be more than an NPC encounter. It could be combat, or just a datapad to read.
Events contain an array of scenes. It can contain multiple arrays of those scenes as alternatives. And even each scene can be an array of scenes.
That’s difficult to explain. Maybe a picture would be better.
On the left is the Event object that is created on the server when it starts, or when a new one is written. On the right is the instance of it that is created personally for a player when it is needed.
This is important, because it allows an Event to be modified for any number of reasons, and when it’s instanced for the players instance of it to be created with those modifications.
There are arrays of scenes on the Event itself which allow switching states of it.

For example:
In the demo, the PRUDE officers at the end have an array of two sets of scenes. When one of them is defeated, they switch to the second set where they’re on the ground. This means that whoever else instances those Events after that point get the second set of scenes that deal with them being on the ground.
This can also be used to have just another set of one writing that is pulled when it’s instanced when, say, lots of people are using an NPC. A bar tender might give the 3rd person opening a dialog with them short responses, indicating how they are busy with the others.

In the future, there will be a tool to easily set these up without programming knowledge. A list of functions will be in drop downs. For a case of “giveQuest name”, when someone selects “giveQuest” in the scene creation tool it will supply a list of all the quests to fill in that name portion as well. While this tool is being made for staff, it is easy enough for anyone to use, so maybe down the line some others could make games on the engine, especially if I make it open source.

There are tons of possibilities.

Bookmark the permalink.