In StoryDev, you will be able to create Journals, which are effectively an indication of your progress in the story. This can help player's understand where they left off or work out what to do when they get stuck.
Currently, there is no Journal system actually implemented in StoryDev yet, and in this article we will both discuss the design and implementation details in the form of a tutorial, which is more of a thought process than any actual programming.
Here, we have options for adding data to each Journal entry we add into the game. Name is obvious, but then we get to the
Part of the Main Story, which is an option telling us that this Journal progresses the main story and is not a side-quest or mission.
There was much thought over how chapter progress should be implemented, and it seemed necessary to always show Chapter and Progress options regardless of whether this checkbox is checked. Except, it will do something different depending on whether it is part of the main story or not.
Here is now the redesign for the Journal system.
What is interesting is having writing these articles there comes further understanding of how it should be implemented. A curious but exciting prospect that should be forever expanded.
Now that this has been changed, I required adding the respective fields inside
public string UntilStoryChapter; public int UntilStoryProgress;
Yes, I use fields not properties. There are no need for properties when you get and set the value exactly as is. This is one of the features of object-oriented programming that has become overused needlessly and serves no practical purpose. There are reasons for using properties in certain circumstances, like when you want to set a variable only within the class it is defined but have it accessible outside the class to retrieve the value, that's fine. But no doubt there will be many programmers who argue against this "inconsistency", but that's besides the point.
In programming, it is good practice to only use features when you need to rather than when you want to for pure convenience rather than for a practical benefit.
Nevertheless, rant over. We press on.
Now to explain what we have above.
How should story progress work?
Now we have two of the same options, but doing different things.
The first of the two Chapter and Progress options is doing one of two things:
Part of Main Storyis checked, then these options indicate in what chapter this Journal entry is a part of and what progress we need to have made within the chapter to make this Journal entry available to the player.
- If it is not checked, then these options indicate the REQUIREMENTS for when they become available; i.e. the Chapter and Story progress required to be made before this Journal entry becomes available. Unlike the above, if this is not checked, this Journal entry is not automatically added to the player's Journal and must be discovered manually by exploration. We will talk about Maps later.
Now, we also have the
Available Until options at our disposal if this Journal entry is not part of the main story, meaning that this entry no longer becomes available to the player past a certain Chapter and Progress value. In practice, what we also want to do is be able to notify the player if they are about to progress the story beyond the point when any active side mission becomes unavailable. This would give player's a chance to finish off any loose ends before continuing the story, or give them the option to abandon their progress.
Another thing to note about the Progress value is that if more than one Journal entry that is part of the main story has the same chapter and progress selected, all of those entries become automatically available to the player. It may be ideal to add scripting requirements in addition to progress.
Our final design looks like this:
This is good. When you consider all possibilities you are constantly going through your mind all the feasible scenarios in which things should appear in the game. Thinking these things through in detail is important. Most programmers may start with an engine first, before creating an editor, however.
The editor-first approach is more error-prone as you may not necessarily know what you are looking for in your video game. However, believe me when I say this, I have attempted making this video game TWICE so far, and have started over for this time as well. Sometimes, that is how video game development goes.
So, to clarify, a Journal entry will by default be automatically retrieved depending on if it is part of the main story and meets the specified requirements. If a main story Journal entry shares the same requirements as another, then by checking
Accessed via Script implies we don't retrieve this automatically, but is still required to progress the story.
Journal entries that are not part of the main story may not be available for long, and we have
Available Until options to set this up.
Which brings us onto the final part of the Journal system, the Pages.
This I have left until last because there is not much to say about this. We have a variety of pages that we can add or remove at will. You would not be able to delete the first page if it happens to be the only page available. There must be at least one page in the Journal for it to appear to the player, because this is where we place our information and describe to the player what is happening, where to go, etc.
However, there will be some interesting things that will be parsed from the Journal pages into the game. See the following example:
In Old Town, [[there is a man who claims to have received information about |Vars.ManClaims]] [[there is a someone who may know something about|!Vars.ManClaims]] [[the crystal you speak of|Vars.CrystalKnown]] [[some crystal, although we're not sure what|!Vars.CrystalKnown]]. ``` GOLD 15
]] indicate opening and closing brackets holding a sentence to display when a certain condition is met, which happens to be on the right-hand side of the pipe character in the middle of these two brackets.
Another thing too, is that the back-tick character written thrice indicates that everything below it should be transformed into a series of displayable rewards, tooltips or additional information formatted differently from the rest of the page. How this is indicated should be up to the developer and not us, the engine itself.
We will likely supply the engine the information we need but we would implement the graphics ourselves.
How we implement this into the engine is best discussed later in a tutorial when we actually start making the game itself.
In the next article, we will go into detail with the Places of Interest system, activities that take place there and how that interacts with both the Journal system and our Character Traits discussed in the previous article. Until then, there is much programming to be done.