Just a quick update on the game design aspect of Project Bonsai, things have been pretty wild for me IRL, so I haven't been able to post anything. Moreover, real life issues has delayed my work on it, but its still chugging along nicely now.

Currently, this is what it looks like in the Twine editor:

The Current flow is as follows:

Intro -> Encounter -> Area X -> Encounter x2 -> ... -> Final Area -> Final Encounter

Intro: Backstory and Character introduction/Customization(?)

Area: Description, Mad lib nouns for description, random buffs/debuffs

Encounter: Events(combat, trading, foraging) or NPC

And that's about it for now!

This is a cross post from my blog about the development of my current game project. To follow its progress further and maybe look at some other art, head over to my blog https://xuelder.com.​

​Today, I want to talk about Narrative Design. As I am making this game in Twine, this is actually a very important aspect of this game, as most of the mechanics need to either complement or enhance the game’s narrative. For this purpose, I decided to look at nonlinear narrative design for Project Bonsai.

There are primarily two schools of thought on nonlinear design for narrative game design, Parallel and Branching Narrative. Both have their advantages and disadvantages that I had to look at for this first game’s design. Parallel narrative has the illusion of a branching story line, with little decisions only affecting small aspects of the story line. However, the overall story still hits certain beats, no matter what decisions you make. The advantage here is obvious, if you want to write a narrative with a clear message, but still give the player some agency, this is the clear way to go.

Although great for a more linear-like experience, the parallel narrative method has some distinct disadvantages. Most notably, a parallel narrative has really low replay value, especially if the choices are only a “cosmetic” change to the game. In Telltale’s games, for example, a decision between two actions may change which character helps you, but doesn’t change the outcome of the action. No matter what choices you make, you are still going toward a certain ending, if only with certain characters still in your “party.” In branching narrative though, the player’s action goes like a decision tree, hitting certain points that change the story’s outcome. This gives the player more agency in the story, as well as giving a better reason to replay a game, to see a different path in the game’s narrative. Unfortunately, this either leads to a longer dev cycle to write a narrative as long as the parallel narrative, or a shorter one to save time on development. Moreover, if your intention is to write a distinct plot with a certain message in the narrative, this can muddy the waters and take a lot more creative effort to do so.

With these in mind, I decided for Project Bonsai to the former method, branching narrative. Due to the mechanics I want to create, as well as a general idea of what I like in narrative games, for this first project I want to make a more standalone title. For this purpose, I think branching narrative is the way to go. Granted, there will not be many branches, and most will result in silly little fail/death states, but they will be there. If I was a little more ambitious, I would use a combination of the two, but I want this game to be released as soon as possible for my next project, which is an ongoing narrative game that I want to release monthly. This project is more about getting my feet wet again in game, narrative, and art design for future projects, and I want to keep it as nice and simple as possible.​

I appreciate you all for reading this. If you want to support my game development, share this devlog on social media or give me a tip on Ko-fi​. For more day to day updates on the game, follow me on twitter @Xuelder, and have a great day.​

This is a cross post from my blog about the development of my current game project. To follow its progress further and maybe look at some other art, head over to https://xuelder.com. If you want to see the first Devlog, you can find it here: https://xuelder.com/post/176134308030/project-bonsai-devlog-1

When I took my first Game Dev Group Project class, I thought paper prototypes were dumb and unnecessary. Till I found out that a mechanic I was really attached would not work, and thankfully we realized it during that before any coding had occurred. However, I seemed to not learn from this lesson, because in previous solo projects before this current one I did did not do paper prototypes. Granted, I feel as if I half assed most of those projects, as they usually resulted in a spiral of feature creep and scoping issues. So I am doing this project “right,” and working on making sure the mechanics work before I actually start implementing them fully in my game.

To do this I needed supplies. However, the great thing about being a tabletop nerd is that I just have no shortage of tokens, dice, and notecards, supplies that are very useful for paper prototyping. If you don’t know how this works, there are various tutorials from GDC talks that go over this, my favorite is Raph Koster’s GDC talk called Practical Creativity[1], which is just full of advice on generating mechanics in general, as well as prototyping your game. Another favorite of mine is Jamie Antonisse’s GDC talk Building a Paper Prototype For Your Narrative Design[2]. So I used a D20 to act as the player character’s(PC’s) hit point counter, a D4 and a D6 to act as the enemy and PC hit die respectively, and I used note cards to write basic rules down on, as well as using them to hold certain events.  A token was used to keep the player’s progress in the narrative tree; depending on which side was up informs one to whether or not the PC had a status effect inflicted on them, which was kept track with a whiteboard. A good old fashion timer was used to test timed events, based on status effects as well as in game events.

All in all this led me to conclude that most of what I have already planned on doing would not be fairly complicated. Several changes I did make from the results of this prototype was the timed events were switched from their initial time of 5 seconds to 10 seconds, but this will probably need more testing once I see how this affects long passaged events. I also removed a paralysis effect that made it so you could only pick the first narrative choice, as it did not really feel fair to the player, and did not sit well with me. So with this in mind, I believe that I can go forward on scripting out the story treatment into a script, and applying this paper prototype into a narrative prototype over the next few days. I will post how that goes on my next dev log.  For more day to day updates on the game, follow me on twitter @Xuelder, and hope you have a good day.

[1] https://youtu.be/zyVTxGpEO30

[2] https://youtu.be/taxcb_5lEI8