As briefly mentioned above, after going to the workshop, I was very curious to see how far I could take the engine. I personally enjoy RPG games, and so I thought that it would be quite fun to make my own turn-based game iteration of it.
What it does
How I built it
Going to twinery.org, I started getting to work on creating different passages and figuring out how to link my story. I spent a lot of time going through the "Harlowe 3.2.3 manual" as here I could learn about more features that we couldn't cover in the workshop (such as creating a method where if you stay too long in a certain passage, a forced-event can occur). With these extra features available, I tried to abstract certain things by creating sub-passages and then one main passage to display the appropriate information. A great example of that are the two battles which I implemented. There is an Interface that simply display a log and some action a player can take (if it's his turn). The log presents detailed information on how much damage the player did, did the monster dodge the attack, enemy's turn, etc.; while the action a player can take includes things like taking potions or choosing what item to attack with.
Challenges I ran into
There are a lot of things that I personally had to keep track off in my head due Twine's system and variable set-up. This wasn't too bad at the start, but the more variables I started to implement, especially when implementing the turn-based fights, the more complex I found things to be. Perhaps it would have been easier to use hooks that can change depending on certain events, but I didn't find the explanations on the manual intuitive (I understood the idea, but couldn't think of a way to implement them in my code). I found myself wishing that I could create functions that take a certain type of input, and perform some computation on them. Not only would this help me abstract my code and easier to read, but also from a debug perspective it would be tremendous. Not finding a way to accomplish that, I instead had to struggle through creating a "log" where players would get information about what happened in their turn, and the opponent's turn. Depending on a variable that had to be constantly updated, I would get different links available to the player to continue the battle mechanics. While doable, it was very time-consuming.
Accomplishments that I'm proud of
Getting the battle mechanics to be smooth is something I'm proud of. My game currently implements a system that doesn't determine damage strictly from stats (that would have been much easier). Instead, I wanted to involve mechanics like players and monsters being able to dodge (determined by agility, accuracy, and some RNG based system), as well as weapon damage having some element of variability (stats help increase base floor, but you can still "high roll" and "low roll" from a given range). I always thought that games which have some system of "high roll" and "low roll" damage output are great because it incentives the player to search for hidden items to get a higher "roll", but there is still an element of uncertainty when going into the fight.
What I learned
I learned how to quickly get adapted with a new interface I had never even heard off such as Twine. While Twine is very simple to get into (creating passages can be done in a click of the button), trying to find some of the more complicated elements of Twine was an interesting experience that lead me to a) try a lot of different ways to get something working and b) search the web efficiently.
What's next for Twinery RPG game with Turn-Based Mechanics
There are a couple things that can be done for my project:
- Firstly, to address the big cat in the room: Using some CSS to make my story have more exciting elements rather than a black screen; as well as align text instead of having off-centered text. Due to the time constraint and the challenges I ran into, there was simply no time as a solo-hacker to get to these things although I recognize they are very important. For example, having an inventory tab that details what a player currently has is pretty important detail. It would also provide an interface for the player to see the stats of the item. Currently I made it so each item has different accuracy levels, but this is not accessible to the player at this moment.
- Secondly, there are parts of the story that I have not completed. As might be guessed from the "Secretive Plotter" file name, I had plans to expand the storyline a lot more than what is currently showed (spoiler alert: The owner of the mysterious journal is actually a foe. The "final boss" is good. Depending on player action and who you end up trusting, you can get two different endings for the world the player was teleported to AND his original world....). There can be more npc's involvement as well (one of my plans was for the West side to be a place to obtain certain items that can be used by the player in an NPC quest).
- Refine the balance of battle in the game. As all games must do, finding a correct balance system is very important. The game can neither be too easy, nor can it be too hard. Spending more time and actually mapping out all the monsters that will be in my game, level-up mechanics, stats from items and monsters, and building formulas to create a healthy game-state is something important.