Hmn. Perhaps I’m dim, but it sounds as though you have Enemy Armor (in the example) changing value…how are you changing the value? If it’s through a card, it sounds like you already have an individual storylet for every instance where Enemy Armor would be different. Not knowing the mechanics of your system, I’m not sure if perhaps there might be a better way to structure the test.
Similarly…how are you presenting the character with a height challenge? I would think you’d need individual story lets for “A daunting iron fence” (height = 10) and “A modest curb near the sidewalk” (height = 1).
Is it possible you may be subdividing your difficulty trials into too fine a grain? It seems as though you could use “Acrobatic Ability” against a difficulty challenge of 10 on the iron fence card, and against a challenge of 1 on the curb card and not worry about height at all. Unless you’ve got a really tricky system, “Acrobatic Ability” should pretty much sum up your chance of getting over a ten foot wall versus a 1 foot wall regardless of what the height you write into the story is.
I mean - think of Acrobatic Ability" as the height the player can easily scale.
Alternately, you could have two difficulty tests in the same branch…one against Acrobatic Ability and a second against “Player’s Jumping Ability”…they would both have to pass to succeed the storylet.
Again, forgive me if I misunderstand, but every situation like this would have a height, and should have a number to scale it against the player’s Ability. And not that I think your suggestion is invalid. I’m sure there’s lots of nifty tricks that could be done by comparing two in-hand qualities, but I think the way StoryNexus works is you compare in-hand qualities with numbers on the cards.
Maybe it isn’t immediately apparent in the isolated examples I gave, and maybe it’s just a quirk of the way I design my games, but the biggest advantage you will have from being able to compare quality values is the fact that you can set all the difficulties in a single storylet rather than divide them into multiple individually hand-coded storylets. It’s a small thing when it’s just one or two variables, but imagine something where you have ten or more possible variables.
Case in point: the combat system in Knightly Tales. When you enter combat, there’s a storylet that sets a whole range of variables, ranging from Enemy Health to Enemy Skill, Enemy Resources and a handful of traits that determine if the monster is capable of stoneskin, petrification, sneaking away etc etc. I do not hand-code the storylets for every single possible combat situation: rather, I simply code an “engine” and let the variables I set in the “entering combat” storylet determine what the engine throws at the player.
Every time I write a new monster, because the engine is already in place, the only thing I need to write is: a new “entering combat” storylet that sets all the variables for this new monster, the few special attack cards that the new monster can perform (e.g. Basilisk has poison breath, Forest Bandits can shoot arrows), and a customised loot card that determines what sort of loot it drops. It’s a system that works, but I’m unable to greatly vary Enemy Skill. Ideally, Enemy Skill should simply be a reflection of exactly how difficult it would be to score a critical hit against a particular monster, but because I’m unable to set the tests to compare directly against the value of Enemy Skill, I’m stuck just using a small range of Enemy Skills - from 1 to 5 - that raises the static difficulty by a large amount each time.
Let’s talk about an example outside of Knightly Tales though. Let’s say you have a cyberpunk game and there’s a Menace called “Inhuman” - which rises depending on how many cyber modifications your character has installed - and a BasicAbility called Empathy, which is a skill reflecting how well your character can deal with other humans. The Inhuman Menace serves as a barrier to the Empathy skill and is therefore always the difficulty the skill is compared against whenever the character wishes to use Empathy. As things stand now, you will have to code a single storylet for every possible value of Inhuman so that you can set a static difficulty equal to that of the current value of Inhuman.
[quote=PostalElf]
Let’s talk about an example outside of Knightly Tales though. Let’s say you have a cyberpunk game and there’s a Menace called “Inhuman” - which rises depending on how many cyber modifications your character has installed - and a BasicAbility called Empathy, which is a skill reflecting how well your character can deal with other humans. The Inhuman Menace serves as a barrier to the Empathy skill and is therefore always the difficulty the skill is compared against whenever the character wishes to use Empathy. As things stand now, you will have to code a single storylet for every possible value of Inhuman so that you can set a static difficulty equal to that of the current value of Inhuman.[/quote]
Okay, cool. I enjoyed the overview of your engine. I have the same sort of idea for my game although nowhere nearly as complex; a battle setting which takes variables from the inciting card - in my case it’s basically going to be “Opponent Name” and “Hit Points”. But then the battle toggles on hopefully what is about six cards for each monster’s attacks and defends, combined with the player’s pinned special abilities and spells. The difference I think is I’m not intending so much depth in the combat – my game is weird and quirky with very specific story-driven battles. My game is also Cardpalooza. Cardopalypse. You’ve probably seen we’re about neck and neck in deck size. I’m guessing the bulk of your cards are in the combat - mine are plot mechanics. Is the player upstairs, downstairs, in private, in the city, inside, outside, does he have a fear of heights, a fear of water, does the King hate him and banish him from the room…etc. These circumstances control what cards can be drawn from t he central deck.
In your cyberpunk example: Couldn’t you just combine Empathy and Inhuman in the same quality? As you describe they’re basically opposite poles of the same trait. I’d call the skill “Human Empathy” which could be trained, then let equitable “inhuman” items decrease it. I wouldn’t use a skill vs. a menace.
I do understand your concept though. I’ve had a couple of times where I’ve wanted to write “Change Skill A by 1 if Skill B is <=10” or somesuch. I usually end up wrting a lot of branches that only appear if Skill B is <=10 that increments Skill A, then the second nearly identical branch shows if Skill B is >10 it doesn’t increment Skill A and explains why if necessary.
That is actually a pretty good idea, and one that I haven’t considered before. =)
However, it would still only be viable up to a certain point. For instance, what if you wanted to use the Inhuman value for something else: the ability of a hacker to affect the character (the more cybered out you are, the easier it is for you to be hacked), perhaps, or how easy it is for your character to pass for a completely inhuman android. It would be fine if every single variable was only paired up against another in an opposing fashion, but I feel that allowing us to use other quality values in tests for either difficulties or comparisons would really open a lot of new design possibilities.
Another example, using the cyberpunk world again. Suppose I have an item that adds the trait, “Maximum Magazine Capacity +30”, signifying that this weapon can hold 30 shots. Every time I reload the weapon, the system should ideally do this: “Ammo” (controls how much ammo the gun has) = “Maximum Magazine Capacity”, “Bullets” -= “Maximum Magazine Capacity”. If I want to be extra fancy I can even customise how many shots the weapon fires per attack by adding a “Burst” quality that controls that, and do “Ammo” -= “Burst” whenever an attack is performed.
The possibilities! Think of the possibilities! salivates
[color=#009900]@firky - the thing about a Show Once quality is that it would, behind the scenes, be quality-driven anyway. If you think adding 74 qualities is a faff, think about the faff of trying to work out which of the cards have been seen and which haven’t, to switch one back to unseen, to realise that was the wrong one and mark it seen again, without the ability to view and change the variables which drive it. I think we’d be better off adding features that improve the quality admin stuff.[/color]
[color=#009900]
[/color]
[color=#009900]@gordon - that’s a ‘nice to have’ on our feature list at the mo. EDIT: and in fact it’s easier than I thought, so should make it into the next release.[/color]
[color=#009900]
[/color]
[color=#009900]re: action refresh costs - there was in fact a bug where the refresh cost could be displayed as e.g. 50 if the action pool was 50 (though the cost charged was right). We’ve fixed this.[/color]
[color=#009900]
[/color]
[color=#009900]re: dynamic quality requirement and effect levels - this is something I’ve wanted for a long time, actually, but it never quite makes it over the priority horizon. It will, though.[/color] edited by Alexis on 1/23/2013
I would like a way to force a player to equip or unequip a slot. For example when I throw a player in jail, they should not have armor and weapons readied.
If thrown in the asylum I want to force them into a strait jacket.
I know this can be done with a must card and tricky quality manipulation and a locked branch and explanation text to refresh the browser window after the required equip set is met…but this is rather clumsy.
I tried doing this with a breakable training sword by setting the sword quality to zero…the sword went away but the player still had the bonus!
Perhaps to accomplish this, an equippable quality or slot can have a force-equip-on-level value the author could choose…so if I set Restrictive Manacles to 2 they are equipped and not unequippable. When the player finds the key I set the manacles to 1 which means they are unlocked and can be equipped at will.
Similarly, a force-unequip level would allow an Expensive Necklace to be set to 3 after the tussle in the garden which transforms it into an unequippable Handful of Pearls. edited by HanonO on 1/23/2013
I read through this entire post, wanted to make sure that my suggestions weren’t already discussed. Do forgive me too, I’ve been using the Creator tool only for yesterday and today, but I feel there’s a bit lacking to allow us to make the best possible world imaginable.
I know it had been asked to delete a character, and the reply was to use the GAME_END_EFFECT - But don’t forget, you now allow Persistent Qualities! So for debugging purposes, could we have the ability to Reset a character? Perhaps a modified GAME_END_EFFECT that ignores persistence?[/li][li]Custom Action Bank size and refresh rates with the ability to modify them in game? (Example, AB of 10 but a successful Storylet increases it to 12 for that character; Or an ailment causes the refresh rate to be slower until another Storylet fixes it.) - I can see how this may be a technical limitation as it is likely stored World wide rather than Character…[/li][li]Copying Branch’s within a Storylet would be very useful![/li][li]Setting a Storylet’s valid Setting/Area should allow multiples. Sometimes I don’t want (Any) and perhaps I don’t want it in a specific area either. Having to make multiples of the Storylet is a workaround, though if something needs to be changed, it needs to be changed multiple times…[/li][li]Setting or Area should be conditions, if you are or are not there. Especially useful if your Storylet is set in (Any) for say, travelling as an example. Put all the areas as Branches but hide their current area with an Area Condition.[/li][li]Hidden requirements; some Qualities may not make sense to the player and showing them as a requirements can make things weird. You could give the Quality text, but then your requirement looks even more out of place when it describes every state possible. A great example of this being odd is in Fallen London:
Rolling counts! You have Sequential (1, 2, 3, 4, 5…) and Pyramid (1 for 1, 2 for 2, 3 for 3…) but what about Rolling? Set the state to have a maximum possible value and when reached, roll over. (Example, you have a ‘Weekday’ state with max 7. Currently it’s 6 and you’re adding 1, so now it’s 7. Now you add another 1, making it 1 instead of 8.)
Feedback is of course requested and encouraged! edited by Zebulan on 1/24/2013
FBG has talked pretty expensively about why SN doesn’t do hidden qualities.
I believe there’s something about how SN handles action banks that makes it incumbent that they be multiples of 10.
We uses to be able to copy branches, but I think – don’t quote me – that they were disabled due to catastrophic bugginess.
Rollover qualities would be cool. Of course you can hack it already by having two branches for whatever: one if Day is <= 5, one if = 6, and have the former tick up while the latter resets.
Having a CHARACTER_NUKE_EFFECT would also be handy, though also replicable with current tech except in very odd worlds with tons of persistent qualities and replay value.
I’ll have to look around for this, must be in another thread…
(EDIT: I found this and I very much understand. For debugging it would be a total pain to have hidden requirements, and also frustrating for the player if the Storylet is crafted wrong. Perhaps an alternative then of being able to rename the requirement? Yes, I’m aware you can rename the Quality Level Descriptions, but true to my screenshot it looks very very weird. Being able to set the requirement and changing the description to “You need to be on a case!” would avoid the need to hide the quality while being able to customize what is displayed to the character (Rather than what the screenshot shows of every possible quality level.))
Major bummer. I would love to copy Branches, and I’ll explain in a second…
This is why I felt coping Branches would be useful, for this work around… If an event takes 1 day, then I could have two Branches - One for <= 6 and one for =7. But as soon as I decide that I want something to take additional days, then I need to make an extra Branch for each day. If something takes 3 days, I now need four Branches. <=4, =5, =6 and =7. On the flip side, if I could instead Rollover a Quality at the value of 7, then a single Branch would work and copying Branches would reduce in appeal (But would still ultimately be useful!)
(EDIT: Actually after some pondering there’s another option. The use of a “MUST” Storylet. Set a Days Pending Quality to a value, and if Days Pending is greater than 0, MUST go to a Storylet that has two Branches. One that is Day is <= 6, add 1 to Day and subtract 1 from Days Pending. The other Branch where Day is =7, reset Day to 1 and subtract 1 from Days Pending. The Storylet will loop until the Days Pending is 0, and it’ll also end up being a great fix since then I can make any event take a variable amount of days, without needing to recreate branches galore…!)
Yes my current setup is to GAME_END_EFFECT in addition to removing persistent qualities. But I’m admittedly lazy :) edited by Zebulan on 1/25/2013
@Anthony: the downside of using a MUST storylet to reset the counter is that Too Many Clicks is the bane of SN games. Adding a purely mechanical reset-this-quality card would probably annoy your players to no end.
So very true. You’ve crushed my hopes and dreams! Ha, well, then I guess I must think of something else…
To put into perspective, my intent was to have a 7 day week and each day 6 (Friday), charge the player “rent” or something. Trying to brain storm some work-arounds… Rolling the Weekday quality from 7 to 1 is a lot of work on each Storylet without using the Must process I theorized… And I can’t simply have it count upwards and say on day 6, 13, 20, 27, 34, etc… have something happen, because math isn’t possible.
So ultimately my suggestions still stand until I can think of something creative to solve this dilemma…
A rolling count or copying Branches would be uber-useful for what I’m trying to do. The alternative of course is “what I’m trying to do is just over ambitious for the scope of SN.”
I’m not going to overtake the suggestions thread with my problem though, so if you happen to have any ideas, Gordon, I’m all ears - do send me a message. For now, I’m just going to keep doodling out my story until a solution hits me in the head.
Anthony: I have a time mechanic in Stepchild that uses three sometimes cards that force the player to advance the time of day when they get all three and can’t discard them. It works if you don’t mind the time progression being erratic.
A simpler option: make a “spending time” quality and throw a must card to change the time of day when it hits a certain amount. That way you van just have any card that should take time increment this quality which is a bit easier than building complex time mechanic branches on every card… edited by HanonO on 1/25/2013
Thanks for the idea, Hanon. If I understand you correctly, that’s exactly what I proposed ;) - Have a “Days Pending” quality with the number of days that must elapse, and have a Must Storylet count that value down while modifying the Weekday quality. Gordon had made an excellent point that this would annoy the player - they’d end up seeing this Storylet all the time, and sometimes many times in a row, just to continue the game.
However, I’ve thought hard and I’m going to scrap the idea of multiple days advancing. If I decide an action is going to take multiple days, instead of advancing time by that many days, I’m going to let the player continue to play how they wish - then just reduce a quality for the action taking multiple days and once it reaches 1, it’s done!
Ie: If building a shed takes 3 days I’ll set Quality “Building a Shed” to 4. The player will end the day themselves, and the Default Success will decrease “Building a Shed” by 1 if greater than 1. Once “Building a Shed” reaches 1, either an Always Storylet or a Must Storylet will be available to scream “It’s done!” and set “Building a Shed” to 10 (Which will be described as “Complete”). This way, I can add all my qualities to the ‘End Day’ Storylet and they’ll only reduce if Min 1 (Max 9), so if it’s 0 or 10 nothing will happen to that Quality.
The “End Day” Storylet will have the two Branches, one for <= 6 (Add 1 Weekday), and one for =7 (Reset Weekday to 1).
I think this is the best possible solution after careful consideration, sleep and coffee. Gordon’s feedback on annoying the player was priceless, so thanks Gordon for the heads up I was heading in the wrong way. I hope you agree this proposal is better! But now, I’m done spamming the Suggestions thread :)
Sorry if I reiterated - I was reading on my phone and sometimes will skip stuff. My bad. Thing is, (with all respect to Gordon) this doesn’t have to be boring if you do it correctly. If you refresh a resource or give the player something cool…but then again, I have this type of card in my deck. Must cards (I think) don’t cost actions, so if it just says “The day has ended” that doesn’t mean it will necessarily bore the player.
I read on the FB blogs that for Fallen London they write their text to be interesting but skimmable when they intend for sections to repeat. I mean, when you play Magic the Gathering you’re not like "Oh my god, I’m so tired of this Forest card that keeps coming up.
In fact, I play a game called Elder Sign on my phone, and it has exactly this mechanic. Every four turns the clock ticks to “Midnight” and it displays a card and things happen (usually the monsters get meaner). It’s more of an exciting “here we go again” reaction. edited by HanonO on 1/25/2013
Minor suggestion: When we use Godlike Powers to tweak someone in response to a fix, would it be annoying or useful for them to get an automatic inbox message that it happened? “A WorldCreator adjusted your Gold: It is now 10.”
Now that we’ve got a quality Cap, what about a quality Floor? “Once above this value, this quality can’t sink below it.”
The use I’m thinking of: for long-term spectrum qualities. E.g. an alignment quality that starts at 5 and runs from 1-11. You never want the player to use it but you’re often moving it up and down.
Yes please. If only for this one specific use case: BasicAbility qualities have the curious (but I think intentional) property that if they’re zero, they don’t increase when you test them. Which means that if you ever penalise a BasicAbility, you have to worry about letting it drop to zero and breaking things.
It’s manageable using “If >=” on individual branches, but a global “never less than 1” setting would be less error-prone.