5
\$\begingroup\$

In my text adventure I'm making, I store the story data in a hashtable (I'm using unity's javascript/unity script since I'm more comfortable with the syntax than C#).

The problem is, the way I structure the hashtable means that it gets incredibly bloated very quickly (I've used the same structure in all of my text adventures across multiple languages. It quickly grows to nearly 1k lines long) which makes it hard to edit in the future (especially if I need to go back to edit certain parts later on)

Here's the hashtable as it's currently structured:

public static var story = {
    "0":
    {
        "text":"",
        "choices":
        {
            "response1":
            {
                "text":"",
                "nextPart":"1"
            },
            "response2":
            {
                "text":"",
                "nextPart":"2"
            },
            "response3":
            {
                "text":"",
                "nextPart":"3"
            }

       }
    },
    "1":
    {
        "text":"",
        "lastPart":"0"
    },
    "2":
    {
        "text":"",
        "lastPart":"0"
    }
};

If anyone could help me optimize the structure of the hashtable that'll make it so it's more easier for me to edit it in the future, that would be great

Quick information for parts that may not be self-explanatory:

  • "lastPart" indicates to the hashtable parser that the player has died and the number refers to the part where they chose the response/choice.

  • "nextPart" refers to the part of the story the response leads to.

\$\endgroup\$
1
  • \$\begingroup\$ A simple yet useful addition to your format could be to allow "nextPart" to point to a different hashtable. That way you can organize your game into individual files. \$\endgroup\$
    – Philipp
    Commented Jul 16, 2017 at 23:03

1 Answer 1

Reset to default
2
\$\begingroup\$

I strongly recommend making your own file format that optimizes viewing and editing of the text parts.

Get rid of redundancy to reduce errors while editing.

You'll also want to get rid of numeric IDs and replace them with readable names.

And you'll want to allow splitting a single story into multiple files.

:Start: You're in a forest, bla bla...
>Start_Left: Move left.
>Start_Right: Move right.
>Tree: Hug a Tree.

:Start_Left: You fall into a spike trap and die
>Dead.

:Start_Right: You enter a clearing. What do you do?
>Victory: Take a nap.
>Tree: Hug a tree

:Tree: The tree is laced with poison. You die.
>Dead.

You then write a simple parser that populates your program data structure from the data in the file. The data structure in the program can thus be optimized for ease of use when accessing the structure.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I've just this month gone through exactly this process, defining an intuitive custom format for authoring narrative game content and developing a parser to digest it into an efficient runtime representation. While I adore the flexibility and power it has, I have to caution that it can be a very deep rabbit hole! Make sure you have a clearly defined and small (tiny! minimal!) scope, and plan it thoroughly, explicitly. When developing a domain-specific language like this, you'll hit tons of edge cases and temptations toward scope creep that threaten to extend the development interminably! ;) \$\endgroup\$
    – DMGregory ♦
    Commented Jul 16, 2017 at 23:00
  • \$\begingroup\$ @DMGregory Absolutely. Richtext support, images, placement of images, fade in settings, sound effects etc: Add them no sooner than when you need them. Or if you know you'll want most of the bells and whistles, google for an existing solution. \$\endgroup\$
    – Peter
    Commented Jul 17, 2017 at 6:30

Not the answer you're looking for? Browse other questions tagged .