Game Setup Suggestions

Question

Using Twine 2.2.1 and SugarCube 2.21.0.

 

I am new to html, css, and javascript in regards to Twine. I have used some basic html and css in the past. I recently brushed up on some you tube videos to refresh my memory and become more familiar with Twine.

I have a few questions:

1) Is it best to have an idea of all game mechanics that I want before beginning or is it best to build the storyline and then come back to fill out the mechanics?

What I want for my game is for there to be different professions and that as the character progresses they become better at it (gain experience/levels) for each profession they use.

Profession examples: Soldier, blacksmith, herbalist, farmer... etc. They can hold multiple professions (not sure how to structure that) and their professions allow them to explore different parts of the storyline. So I could start out the storyline from the perspective of one profession and follow it to the possible 'endings'. Profession combinations would be a blur of two or more professions. But there would be an ending from only one profession, determined by which ever one they completed first/actions they took.

 

2) For NPCs and Monsters, is it best to have a passage designated to individual NPCs and Monster Types?

So if in a city shop they want to talk to the NPC at that Location, the name would show up as a link to enage into a conversation. Then all the if elseif else statement would be there to determine the flow of the conversation. side note: how could one leave the conversation while keeping all the choices? would if be for specific choices a type of 'key' is given. like $tickedJohnOff or $MadeJohnSmile, so then next time the character might say, "There she is!" or "Hey, my buddy.".

 

3)UI Bar

Is it possible to add a character page, inventory, and equipment to the UI bar? I have not figured out how to design that system yet. On the character page I am going to add the basic stuff which I think I have figured out from other threads (name, gender, age, haircolor, eyecolor, and hair style).

 

4)With character inventory, I plan to have creatures and stuff that they can get but I do not know how to make the system give a different key for same items. Like a character finds one iron ore and find another iron ore later, how would I keep it from overwriting itself and just endup showing that they only have 1 iron ore. Would it be like <<if>> have $ironore then $ironore is $ironore + 1>>

 

I know I am jumping all over the place. If there is something I can describe in more detail let me know. We can also work on one thing at a time. This is not going to be something that I can get running any time soon. So I will probably work piece by piece, I just do not know... how or what piece to work on first. I have an idea how I want the story to run and all the professions I want and the possible story interactions. But all the mechanics parts will take me a while to get down.  By the way, character level is determined by the combined profession levels. The character has basic fighting skills, but it ultimately is based on what profession they start out in. Right now there are four professions that I want the character to start with. Later those paths can lead to other profession classes.

Answer 1

1) Is it best to have an idea of all game mechanics that I want before beginning or is it best to build the storyline and then come back to fill out the mechanics?

I'd say it's always best to have things figured out ahead of time.  So, it's important to decide which is the master: the story or the mechanics?

If the mechanics serve the story, figure out the story first and then build the mechanics to suit it.  If the story is built around the mechanics, make sure you have a firm grasp on how you want the mechanics to work before you put too much of it into the story.

If they're separate, and there is no master, I'd say build a good base of code first, since that makes it easier to build the story around that later and then to test how it works as you go.  You can always pre-release a partial story with functioning mechanics, and then update as you go.  However, it's just frustrating to try to play a game with a good story but non-functional mechanics.

2) For NPCs and Monsters, is it best to have a passage designated to individual NPCs and Monster Types? 

That depends on the game.  If detailed information is important to the story and interesting to read, then possibly.  However, in most cases it's better to show, and not tell.  Having the players feel the icy chill and see their breath as they draw closer to the ice dragon's lair is generally far more interesting than saying that ice dragons make the area around them freezing cold.

how could one leave the conversation while keeping all the choices?

You will need to create a variable or variables that you can set "flags" on, to indicate when certain things have happened.  For example, I use the following:

In the StoryInit passage I initialize the $Flags variable as an empty object:

<<set $Flags = {}>>

Then I create a "Global Widgets" passage (you could call it anything though) and set the "widget" and "nobr" tags on it, with this code inside:

/*  SetFlag : Set Flag X to value Y (Y defaults to True).  Flags are not case sensitive.  */
/*  EXAMPLE: <<SetFlag "Mentor" "Harmony">>  */
/*  EXAMPLE: <<SetFlag "TrialMed">>  = sets TrialMed flag to True  */
<<widget "SetFlag">>
    <<set _Fnam = $args[0].toLowerCase()>>
    <<if def $args[1]>>
        <<if $args[1] == false>>
            <<if def $Flags[_Fnam]>>
                <<run delete $Flags[_Fnam]>>
            <</if>>
        <<else>>
            <<set $Flags[_Fnam] = $args[1]>>
        <</if>>
    <<else>>
        <<set $Flags[_Fnam] = true>>
    <</if>>
/* Event flags: */
/* keep track of your event flags here */
<</widget>>

Finally, I put this in the JavaScript section:

/*  Flag : If flag exists then return its value, else return false.    */
/*  EXAMPLE: <<if Flag("Mentor") == "Harmony">>Hello, Harmony.<</if>>  */
/*  EXAMPLE: <<if Flag("TrialMed")>>You're taking the meds.<</if>>     */
window.Flag = function (Fnam) {
    if (State.variables.Flags[Fnam.toLowerCase()] !== undefined) {
        return State.variables.Flags[Fnam.toLowerCase()];
    }
    return false;
};

Now I can easily set and check flags as shown in the "EXAMPLE" comments above.  If you test Flag() for a flag that doesn't exist, then it will return false.

3) UI Bar - Is it possible to add a character page, inventory, and equipment to the UI bar?

Yes, the StoryCaption passage is where this is commonly done.

4) With character inventory, I plan to have creatures and stuff that they can get but I do not know how to make the system give a different key for same items.

For something like this it's better to use objects, like $Flags does above.

You can have an object called $inventory, and then add other objects to it which each have their own properties.  A simple example:

<<nobr>>
/* Create an empty inventory. */
<<set $inventory = {}>>
/* Add 5 pieces of iron ore worth 20 gold each to the inventory. */
<<set $inventory.IronOre = { name: "iron ore", quantity: 5, value: 20 }>>
/* Add 5 more. */
<<set $inventory.IronOre.quantity += 5>>
/* Check to see if you have copper ore. */
<<if def $inventory.CopperOre>>
	You have $inventory.CopperOre.quantity $inventory.CopperOre.name.<br>
<<else>>
	You have no copper ore.<br>
<</if>>
/* Add 1 piece of steel worth 50 gold each to the inventory. */
<<set $inventory.Steel = { name: "steel", quantity: 1, value: 50 }>>
/* Display the inventory. */
<<for _key range $inventory>>
	_key.quantity _key.name worth _key.value gold each.<br>
<</for>>
/* Three different ways to show the same value. */
<<set _temp = "IronOre">>
$inventory.IronOre.quantity = $inventory["IronOre"].quantity = $inventory[_temp].quantity<br>
/* Get an array of all inventory keys and display it. */
<<set _keys = Object.keys($inventory)>>_keys
/* Get rid of the steel. */
<<run delete $inventory.Steel>>
<</nobr>>

So, that's a basic rundown of the methods you'd need to know to manipulate an inventory like that.  You don't have to use "name", "quantity", or "value", and you can have as many other properties as you want (though less is better, since that means it takes up less memory, which may be a limited resource), each with whatever values you want.  To keep things simple, don't start property names with a number and don't put spaces in them.   (Also, see the <<for>> macro for details on how it lists through objects.)

If you're interested, I'm working on a Twine 2/SugarCube 2 inventory "plugin" to make working with inventories simpler.  It's called the "Universal Inventory System", or "UInv" for short.  It's still in pre-release (so the full release may break pre-release code), but you can check out the UInv help file online if you'd like to take a look at it.  Or you can download UInv v0.9.5 from this temporary link (link expires 8/15/'18).

Hope that helps!