Twine Prototype


To get a better understanding of the narrative flow I decided to make a Twine (text-based) version of the game. My goals for this prototype are:

  • Create a clear prologue
  • Understand how narrative moves with dialogue, especially when there are dialogue options
  • How to apply my game loops effectively

After the initial prologue, I wanted to do something unique with the dialogue options by having a third option appear only after the first two were chosen. This is when I found out that Twine has its own programming language called Harlowe, which wasn’t too different to Python, a language I was already very familiar with, the only staggering difference being the syntax. This opened so many more doorways for what I could do with the game.

First Realm (Denial)

Denial passage sequence

The first region I started developing was Denial, I went with the process of designing three events the player must experience before their final encounter (the Boss fight). Two of the three events are typically connected and can circle back to one another. At first I didn’t want to do anything big but as I tested every option it just felt like a lot of reading and not a lot of action – essentially there was no high risk factor, no drive to pick a certain action over the other. So I implemented the idea that some paths/options can either reward the player (by giving them Shards or progress faster) or impact them negatively (send them back or damage them).

Doing this however meant introducing global variables like health and a counter to keep track of the players items.

Denial will serve as the foundation for the other realms and I will follow the same formula. Three main events -> Boss encounter and fight -> Limbo.

Hub Area (Limbo) and Tree of Sorrow

At first Limbo was simply just where the player would start their journey and choose which realm they would like to go to. After I completed the passages in Denial I wanted to add a function that would cross off the region if the player had finished it, which resulted in this horrifying bit of code which I’m sure could be optimised.

Then I added the option to interact with the tree, where it would then incorporate the meta loop where the player will trade in their Shards and Soul to upgrade the tree, this system is described in the Tree of Sorrow section of development.

The logic being, if the player has no shards – tell them to go back to the core/normal game loop. If they do have shards the tree will offer them a trade, however the trade option will only appear if they have the correct quantity of items, otherwise they will be urged to leave and go back to Limbo. The logic works but it isn’t very effective, or optimal for that matter, since it doesn’t account for players that only have Terra Shards and no Souls.

At this point in time, there aren’t any actual upgrades the player can get. Some will be harder to implement than others or impossible altogether, for example the speed bonus wouldn’t be transferable because the player has no concept of speed Twine since there is no movement involved.

The idea was that there is another counter that keeps track of the tree level progress (Tree_Level), since the player can only level up the tree after they’ve gained a Terra Soul (from defeating a boss) then the tree needs to reach level 4 to finish the game.

Player Death

This should have been really easy and quick to implement but I kept facing bugs and issues with the way I wanted to do it – have a separate function that gets called whenever the player death gets to 0 or falls below it that sends the player to a death messsage screen, resetting their health and putting them back in Limbo. I tried all sorts of different ways to get it to work but it kept sending me to a black screen and overloading the console test passage counter. The same logic was applied except this time I overcomplicated it by having the function call any time the player would be in a situation where they would take damage.

The function: (if:$Health <= 0)[(goto:”died”)]

Death Screen

Here is what the player will see when they die.

The code behind the death screen.

I wanted the tree to interact with the player with a message that was relevant to their death, make it appear more omnipresent and all-knowing, showing that there is a bond between the player and the NPC.

Code behind the tree’s death message.

This code doesn’t work as intended, but I plan to come back to it once all realms have been made.

What I’ve Learned:

  • Hack and slash roguelite mechanics are hard to translate in a text-based game so I did what I could with RPG turn-based-esque gameplay.
  • The idea of dying not being a total and complete setback or waste of time translates really well in Twine – even if you do die you know what not to do next time and it allows you to explore different paths.
  • It’s okay if an idea doesn’t work as intended or at all, try something else and it might end up actually being better
  • I now have a much better understanding of the structure of my game and I know how I want the logic behind it to work.

Leave a Reply

Your email address will not be published. Required fields are marked *