This sprint, I started by implementing alternate success conditions for certain scenarios. This means that for some scenarios, there will be multiple different stat checks that can lead to different outcomes, and potentially different scenarios down the line.
Two different outcomes of the scholar’s exam scenario. One for high intelligence, and one for high charm!
This was an interesting programming challenge, as I had to figure out how to associate these alternate conditions with the data table that is currently holding all the scenario information. The interesting thing about these alternative outcomes is that they function as almost half a scenario. They have no intro dialogue, but they do have a unique stat check, outcome dialogue, and list of scenarios to unlock on success. Because of this, I decided that I would copy the current scenario into a new struct. That way, I could “swap out” certain pieces of data at runtime without having to fill my data table with duplicate information. Next, I created a new data table based on a smaller version of the scenario struct that only contained the necessary information for each alt conditions. Now, each scenario in the main table could have as many alternate conditions as they needed. After a stat check is failed, the scenario handler checks to see if there are any remaining alternate conditions. If so, that condition is removed from the list, and its information is plugged into the current scenario, which is reset back to the stat check.
The next thing I worked on this sprint were the Action dialogue and Effect dialogue. I wanted to make the scenarios more engaging by telling the players what happened during them, as well as revealing to them the potion they used. To achieve this, I added a new piece of dialogue to each scenario as well as each potion. The new scenario text is called the “Action Dialogue”, which describes the moment that the character drinks the potion.
My intent with this new piece of text is to further immerse the player in the scene, as well as add some drama to the reveal of what potion the player used. In this case, the potion of Gigantification!
After the Action Dialogue, the potion’s Effect Dialogue is shown. This describes the effects of the potion to the player, and is meant to make the potions feel like they are more than just a collection of buffs and debuffs.
The next item I completed this sprint was icons to represent each of the different stats, to reduce the amount of information that needs to be shown on screen at a given time
.
These took many iterations to get right! I spent a lot of time trying to figure out what would best convey the concept of each stat, as well as making it readable. The charm icon in particular took many many different tries!
With these I was able to make the stat check dialogue look much nicer!
The final thing I worked on this sprint was a typewriter effect for the text box. This would type the text out letter by letter instead of just showing it all at once when the player pressed continue. My first approach to this was to set the widget text from within the scenario handler letter by letter, but I later decided it would make more sense to have that functionality just be inside of the widget itself, with some functions exposed to start the typewriter and set the whole text.
This wasn’t too difficult, until I started using rich text styles and images to insert the stat icons and have colored text. The way you use rich text styles is with tags like <These>”Example Text”</>. The first tag contains the name of the style, and the second one with the backslash tells unreal to return back to the default style. If i typed this out letter by letter, it would also type out the tags until it reached the end of the closing tag. In order to solve this problem, I did some research on youtube before coming up with my own modified solution.
My MVP node
By switching on the next character that’s going to be added to the text, I can execute different logic for the opening bracket of a tag. What I do here is jump to the next closing bracket, and then toggle a bool that will append a closing bracket to the end of the text. When I then encounter the real closing bracket, the appended one is taken out and the real one is added.
Rich Text Images also use these style tags, except they don’t use a closing tag. Their tags look like <img id=”Something”>. In this case, if I append a closing tag, it won’t have any corresponding tag to close and will show up in the final text. In order to get around this, I check for an image tag specifically when I encounter an opening bracket.
In this scenario, I simply jump to the next closing bracket and do not tell the typewriter to append a closing tag. Now my typewriter functions smoothly with rich text styles and images!
Here you can see the typewriter effect working with images and different text styles (the colored text)
Comments
Post a Comment