Glitch and I have carefully made our way through your feedback, taken notes, and had long discussions about where to go from here! Thank you again for taking the time to delve into a beta version of Adventuring and provide us with extensive thoughtful feedback. Because of you, we have a lot of ideas about how to improve the system. Below outlines a summary and important points of the feedback along with commentary from glitch and me. After the feedback is summarized, we have a list of potential updates we’d like to do before the full launch!

The summary below should give you an idea of the wide array of feedback we received, but by no means does it cover everything. Anyone who wants to read the full feedback can do so by visiting the submission threads linked to in this thread. We tended to include feedback that was repeated by multiple testers in the summary below, and if your feedback wasn’t specifically mentioned in the summaries or the lists at the end, that doesn’t mean that we aren’t still considering it! By a similar token, a lot of the feedback went in many different directions and so didn’t lend itself well to being summarized, so you may find your feedback from one section moved to another, or simply included in our to-do list at the bottom.

Reminder of the components

• Adventure Building Tutorial: testers made their way through a short interactive tutorial built with the Adventuring System. The focus was on introducing some of the foundational terminology and mechanics.
• Quick Start Guide: testers were introduced to the mechanics of the Adventuring System by making their way through a step-by-step guide, creating an Adventure along the way. The focus was on having testers actually start using the builder to experience mechanics talked about in the Adventure Building Tutorial and build onto that knowledge.

Purpose of this section
The goal was to give testers a very guided introduction to the Adventure System. We picked out only the most important points and mechanics to teach in order to try keep the amount of information we were throwing to testers at a manageable level. The reason we did this is because we found less guidance or a more general guide to be very overwhelming to Closed Beta testers, and wanted to gather feedback on if a more guided approach would help hold onto more testers.

Feedback Summary
In their first impression of the Adventuring System, many testers felt intimidated and overwhelmed but excited. There were some testers who didn’t start out as intimidated because they had a bit of coding experience, had some experience with a system that had some semblance of similarity from elsewhere, or were familiar with Quest for the Icy Soul. Many testers gained confidence and didn’t feel as intimidated by the Adventuring System after they finished the tutorials. We noted that this section had the most respondents, and there was a good number that didn’t continue past the tutorials.

Most testers thought that the Quick Start Guide was more helpful than the Adventuring Building Tutorial. The Adventure Building Tutorial feedback was extensive and there were many good changes suggested, and a common theme was that the tutorial seemed too abstract to get a grasp on the mechanics, contained jargon that was hard to remember, and was a bit light on the details to be truly helpful.

The Quick Start Guide feedback was good as well! There were a few flaws that need to be corrected such as typos, outdated screenshots, and unexplained terminology. Some of the major issues were that it was too wordy and thus testers were relying on screenshots and that sometimes resulted in them just filling things in according to the screenshots but not knowing why. There was also issues with copy/pasting, causing errors in the JSON field due to comma or nesting errors. A few testers commented that this guide was anything but “quick” as the name implied! All in all, testers did think that the Quick Start Guide was a valuable and necessary resource.

Glitch and Myla’s thoughts
After reading through the feedback, we feel that the Adventure Building Tutorial needs an overhaul: its current state lacks clarity on whether it was designed to familiarize the person with adventuring or with the adventure builder. As a result it sort of missed by aiming between the two, having too many implementation details and too much terminology for an introduction to adventuring, but not nearly enough for an introduction to adventure building. As one tester mentioned, “this tutorial needs a purpose, and needs to stick with it.” Its intended focus was to gently introduce some of the terminology and mechanics without being weighed down by the complexity of the back-end, and while there were a good number of testers who found the tutorial helpful, we think on reflection that this style of tutorial would be better suited as an introduction to adventuring as a whole. Testers who had played through the Quest for the Icy Soul indicated that felt they had a leg up, and a tutorial adventure seems like an ideal mechanism to get everyone else up to that level. Thus, our goal will be to mold this tutorial to focus more on Adventuring from the roleplaying side of things!

Since most testers indicated that the Quick Start Guide was helpful, we’ll keep it around, making many of the suggested changes… including its name, being anything but “quick” ;). We’ll also focus on making it less overwhelming by better explaining jargon, augmenting explanations with bulleted summaries of each section, and refining it visually.

Reminder of the tasks

• Story and Settings Basics - Testers created a simple, two node Adventure containing two locations with descriptions.
• Mechanics Basics - Testers created an Adventure containing a list of required mechanics.

Purpose of this section
The purpose of this section was for testers to start creating Adventures with less step-by-step guidance, relying on what they learned in the previous section and using the reference guide resource. The goal was also to stress that Adventures don’t need to be huge or complicated—Adventure Builders can make very light use of mechanics to spark roleplay among Adventurers. We found that in the closed beta, many testers created Adventures that were too much of a time sink in terms of the size of the Adventure and the complexity of the mechanics, and we wanted to see if going through these exercises would help prevent that in the next section, Creating a Tiny Adventure.

Feedback Summary
Testers noted that the Story Basics section was very simple compared to what they had just gone through with the Quick Start Guide. There was a suggestion to combine the Story Basics and Mechanics Basics sections, and another suggestion to introduce some other narrative tools here. Some said that creating this small setting sparked ideas on how to make it bigger and more complex down the road. The overall impression was that it was a good start, but on its own a bit lacking.

A few testers thought the Mechanics Basics section could use reorganization. One tester even took the time to outline a new organization scheme for it (thank you!). The details of this section were minimal, which meant that the screenshots that were included to help showed elements that weren’t explained, leaving some feeling confused. Others weren’t sure why certain mechanics were included or what their importance was, and indicated others (such as encounter pools) that they would have liked to learn more about.

Glitch and Myla’s thoughts
Both sections could use some work! We liked the suggestion to add some more narrative tools to the Story Basics section. It might also be helpful to add some information on how a builder can plan out their Adventure without getting in over their heads and some guidance on how to write flavor text to optimize roleplay potential for the Adventurers. It’s important to note that Story Basics and Mechanics Basics did not keep testers from accidentally making super time consuming “Tiny” Adventures in the next section, so coming up with solid ideas of how to guide people towards getting started with something tractable is still really important.

The mechanics section does need some major work. The reorganization that was suggested was excellent and we will likely use that as a starting point. We’d also like to re-evaluate what should be included, keeping our focus on foundational mechanics, and clearly explain why we include certain mechanics. In the Tiny Adventures section, we noted some distinct areas where Builders could use more guidance, and here might be a good place to do that!

Reminder of the task

• Create a small adventure using the tester’s original idea or an idea from a list of prompts. There was a small list of requirements that had to be met to be considered a tiny adventure.

Purpose of this section
The goal here was to let testers loose to create a very small Adventure of their own design with little to no guidance. We wanted to see if there were any trends in where testers had trouble and where they excelled so that we can make adjustments to the Adventure System accordingly when possible.

Feedback Summary
When getting started, scoping the adventure and keeping it manageable was difficult, and it was easy to get excited and start planning an intractable adventure. Keeping things organized was also difficult, especially for adventures that got larger than intended. A lot of people had difficulty with JSON, and a general guide to understanding its syntax would be very helpful. Several people also reported often wondering if there were perhaps a simpler way to create a given mechanic, and suggested having a way to import pre-built components (such as template items or enemies).

The general freedom and ability to construct complex interactions was very much enjoyed, and the reference guide and documentation helped a great deal. People particularly liked writing prose and descriptions to accompany the mechanics they were building. There was also a distinct group that would prefer that the technical portions get out of the way so that they could focus on writing.

There were many suggestions on how to improve the world builder interface. Chief among them was to rework the auto-collapsing sidebar, whose primary purpose was seemingly to make things harder to find and to increase the number of clicks necessary to get anything done ;). Other suggested improvements to the sidebar included the ability to group nodes together into logical clusters, and to generally support what ought to be simple actions (re-ordering or re-numbering elements, moving them between nodes, creating elements without invoking a page refresh, and so on). The “Deleted Elements” tool, while being very useful, also had the unintuitive habit of not freeing up the names of deleted elements and causing people to wonder why they couldn’t reuse the name of a command they had previously deleted.

Many people, when looking at the interface, saw a lot of bells and whistles that were poorly explained, if they were explained at all. For example, some concepts (like encounter pools, attack groups, and damage types) were only explained in passing deep within the reference guide, and were almost impossible not to miss. Other concepts (expression functions in particular) were difficult to conceptually fit into the bigger picture. This led to the very limiting feeling of not being able to use the tool to its potential, akin to using a complex machine as a door-stop. More in-depth examples of using some of the more complex mechanics would have gone a long way to helping overcome this limitation.

There were also a few good suggestions that are regrettably not feasible. One that came up repeatedly was for inserting new actions at the cursor’s location (rather than at the end of the action list) which would greatly streamline branching actions like if-checks and attribute-checks. Unfortunately, the fancy JSON Editor does not make this possible, and foregoing the editor in favor of a plain text-input (like forum posts) would not be worth the trade-off.

Glitch and Myla’s thoughts
Writing a quick “Intro to JSON” guide, in particular for how it pertains to adventure building, is a fantastic idea and will be added to the knowledge-base in the near future. The ideas for improving the builder interface also make a lot of sense, because it is absolutely rough around the edges — it’s miles better than what the Closed Beta had to deal with, and light-years better than what we had for Quest for the Icy Soul, but “less bad than terrible” is not the same thing as “good”!

A longer-term goal we have is to replace the JSON editor for actions entirely with an interface that allows you to construct your command in a more guided fashion. This is a very large undertaking and is not something that is feasible in the imminent short-term, but would ultimately be worth the effort due to the number of people to whom it would make adventure building accessible.

Reminder of the task

• Testers roleplay through tiny adventures Adventures they or other testers created.

Purpose of this section
The goal was to get testers thinking about not only how to make an Adventure they enjoyed building, but one that would be satisfying to roleplay as well. We also wanted to see how the interface worked with a variety of Adventure types and group sizes.

Feedback Summary
Most testers roleplayed solo Adventures from the third person perspective, and thought the Adventure worked well as a solo Adventure. The few who did play in a group noted it worked pretty well, though there were occasional hiccups. Most Builders design and test adventures with one adventurer in mind, in part because it is harder to think about designing an Adventure for multiple players and hard to test an Adventure for use for multiple players as well.

The main trends where testers ran into issues with roleplaying other’s Adventure were: in some cases the writing was unclear with directions or inconsistent with itself, some layouts or RNG battle encounters caused a tedious amount of adventurer writing, and sometimes the writing assumed thoughts/actions of the Adventurer which made it hard for the Adventurer to add roleplay to or in some cases conflicted with what the character actually did or thought.

There were many suggestions for interface improvements, and some of the ones that stuck out were displaying the Adventure Builder’s name in the thread, choosing the avatar backgrounds of your pets individually, implementing a wider selection of NPCs to do the auto-posts besides the Bone Monster or to being able to customize the auto-poster, listing completed Adventures somewhere, making the item display more intuitive/informative, displaying recent posts before the text field and displaying more posts than we currently do, changing to different stats than the current ones we are using, explaining the point system for stats better, being able to customize stats, remembering character stats from Adventure to Adventure, referring to character stats/stat modifications more easily, embarking on Adventures with more than one of your own characters, upgrading the Adventure search, and being more explicit about how the dropdown action list is organized.

Glitch and Myla’s thoughts
There were many of great thoughts and ideas, some which will be easy to implement and some extremely difficult. Notably, not being able to easily test Adventures that allow multiple players is clearly having a negative effect—being able to embark on an Adventure with more than one of your own characters would likely help to mitigate this issue (with the added benefit of more flexibility in the roleplay itself), and something we’ve discussed implementing since Quest for the Icy Soul. The reason it still isn’t possible is due to the scale of the undertaking, as the assumption of “one participant per account” is so deeply ingrained into adventures’ backing data-structure that quite literally every single function that uses adventure state (which is all of them) will need to be fixed to accommodate the change. That said, given the various benefits — in particular to testing multiplayer adventures — it sounds like we’ll probably need to do it.

The stat system was another area that was heavily commented on. The stat page was something we implemented very shortly before Open Beta launch and thus our Closed Beta testers had not gotten a chance to give us feedback, and so it was unsurprising that there is still some work for us to do in this area and we’ll be taking a good look at it before the full launch!

Reminder of the task

• Testers could pick from a number of different testing options such as creating more adventures, roleplaying adventures, creating complex mechanics, and answering help thread questions.

Purpose of this section
The goal was to add some flexibility in the Open Beta structure by encouraging testers to do more of what they found enjoyable and to be able to give us some more feedback on whatever stood out to them.

Feedback Summary
The feedback was very widespread and there wasn’t a lot of repeated observations given the variety of options for this section. Roleplayer testers tended to give feedback on the specific Adventure they embarked on. Tiny Adventure creators and mechanics creators gave a lot of very specific mechanics suggestions.

Glitch and Myla’s thoughts
A couple of suggestions sparked conversation between us!

One tester suggested having a way for an adventurer to provide some kind of input from the forum post to a command. For example, maybe an Adventurer were to run the command “open the lock” with a forum post that said something like “Alice attempts to open the lock using the combination [1234].” and then make it possible for the command to behave differently depending on whether “1234” was the correct combination or not. A mechanism like this would make a lot of riddle-style adventure mechanics possible, and make a combination lock mechanic possible using a single command. We love this idea, and are in the process of deciding how to best support it.

Another idea that came up periodically was to have a way of attaching variables to items, instead of just to adventurers or the party as a whole. This would be useful for implementing things like wands with a set number of charges, which is currently not possible to do in an adventure where more than one of the item might exist. This idea has come up before, but was always shelved because it would require completely re-structuring how items are represented. Still, based on the feedback it sounds like it would probably be worth the effort.

Tedium was also brought up as a common detractor, in particular in situations that required running the same randomized command a bunch of times while hoping for a different outcome. Examples of this included miscalibrated (or unexpectedly lengthy) battles that draw on forever (there’s only so many ways to roleplay swinging a sword and missing before you start to go stir-crazy), and repeatedly trying to accomplish some high-difficulty task. The latter case can be approached from an adventure design perspective by having the adventure author consider avoiding commands which either succeed or invite a retry. With battles, on the other hand, that kind of approach may not be possible, and battles are very easy to miscalibrate. Someone suggested building a battle simulator where a Builder can throw in stats and have it do a bunch of runs and output an average number of posts to resolution, which is a very intriguing idea that is worth exploring.

An interesting feeling that was expressed was one of apprehension when editing an already complex adventure — what if you break something and just want it back the way it was? One suggestion was to implement the ability to duplicate an adventure, so that you can work on the duplicate instead and keep the original safe. While we feel that this would detract from the overall system by inevitably resulting in a large quantity of similar adventures with only superficial differences, the issue it hopes to solve is a real one. To that end, we can definitely do better with version control: controls to accomplish tasks like “remove all unpublished changes” and “restore things to the way they were in version X”, diagnostics like “see the differences between the current state and my last published state” or even “see the differences between version X and version Y”, would all be very helpful to alleviate the fear of breaking things.

The topic of adventure deletion came up once or twice as well. While locking an adventure has the same outward appearance, there was a common thread of not wanting to have to see your own mistakes or false starts. We agree with the sentiment, and will be making it possible to completely delete an Adventure that hasn’t yet been published. Once published, however, things get more complicated: we feel that it would be an anti-feature to make it possible that an adventure that you are currently RPing suddenly disappear due to its author deleting it. We will continue to consider how to best accommodate both sides of this.

Given the feedback, we have a rough idea of the updates we’d like to do! Many of the updates will be made before the full launch, but there may be some we do after the launch!

Note: Bullet points that start with “consider” means we’d like to implement it but need to think more about how to do so and if it is workable. Thus, these bullets are a bit more wibbly-wobbly in what the end result will be and if we can implement it! Bullet points that have “(tentative)” at the end means it will be very difficult and time consuming to implement, so we may not be able to do it. Bullet points that have “(long term goal)” at the end means it’ll likely be implemented after the full launch.

• Revamp to an Adventure Roleplaying Tutorial
• Instruct on how to use the dropdown
• Include general roleplaying/reply tips
• Instruct on how to move through an encounter
• Instruct on how to interact with items
• Include information about dice rolls and the purpose of dice rolls
• Go through the process of ending an Adventure

• Rename
• Fix errors
• Reduce/explain jargon
• Add JSON copy/pasting tips
• Add bullet point summaries
• Visually refine

• Add in more narrative tools
• Add tips on how to organize your Adventure
• Add tips on to write flavor text to encourage roleplay

• Reorganize flow
• Visually refine
• Reconsider mechanics to include
• Add in more explanation/support

• Create a Basic JSON guide
• Add some more examples/links to examples in Reference Guide
• Create various repositories (mechanics, enemies, items) for Builders to import/export to
• Put information about tags somewhere, add more tags
• Consider mini-guides for various elements (e.g. how to create an enemy)
• Consider prompt/tutorial Adventures
• Battle simulator for battle calibration (tentative)

• Improve organizational abilities for the side menu
  • Moving
  • Copying/Duplicating
  • Grouping
  • Renumbering
• Remove autocollapse on side menu
• Consider options to make creating a new command less buried
• Replace symbols with images
• Consider options for Builder notes
• Consider how to prevent name conflicts with deleted elements
• Rename Metadata, potentially relocate it
• Make a reset option for instance editor
• Consider places where we can add in more tooltips
• Implement changes to stats (stats universal across Adventures but unique to MC, or a system customizable by Builder, or a combination?)
• An an option to permanently delete an unpublished Adventure
• Consider option to permanently hide published Adventure from Builder’s Adventure listings + change author name to Anonymous
• Consider adding more controls for search display of Builder Adventures and eliciting feedback (option to keep Adventure from the listing/search perhaps and a toggle for enabling/disabling Adventurer feedback)
• Add another Builder to an Adventure (collaborating on Adventure builds)
• Consider changing/adding to NPC options for the auto-posts (let Builder set from a list that includes a generic/blank option or just change Bone Monster to something more generic)
• Make viewing mechanics link more clear (viewers can see mechanics but can’t edit Adventure)
• Make testing unpublished adventure options more clear (can invite other players to test Adventures with you)
• Revert to previous version option for published Adventures
• Hide test posts from Builder’s recent posts and post count
• Embark with other player permission confirmation checkbox only appears if another player’s pet is added
• Perform validation on a command on its “edit command” page, rather only seeing errors on the publish page
• Determine which (if any) things have been edited since last publish
• When viewing a node’s page, link to and display any “post text"s attached to commands that can bring you to the node
• Fix enemy vulnerability / resistance dropdowns, which do not include damage types that aren’t attached to a weapon
• Reduce screen refreshing when building elements
• Consider a way to mass rename a variable
• Add information about how Adventurers see order of options in their dropdown
• Add a mechanic to allow text input from Adventurer
• Add an expression function to determine whether a command is masked
• Add an expression function to determine the current adventurer’s HP
• Add an expression function to determine the current enemy’s HP (if any)
• Add an expression function to determine an enemy’s AC (as a companion for damage_enemy)
• Support “undroppable” items (i.e. for keys, etc)
• Consider expanding weapon properties to use expressions instead of just a numeric bonus and a roll
• Consider expanding usable items to have required conditions on their use
• Consider default unarmed attacks to be “bludgeoning” instead of “slashing”, or make it configurable
• Test adventures with multiple of the Builder’s pets (tentative)
• Add variables to items (tentative)
• Make JSON editor into pure interface (long term goal)

A few Adventure Builder mechanics that were requested that we can’t implement

• Variables containing things other than numbers:
  Many people suggested that variables would be more flexible if they could contain things other than numbers. Unfortunately, doing so would make it impossible to verify the correctness of expressions (in which variables are used). Right now, an expression is valid as long as its syntax is correct — for example {var:keys} - {var:locks} > 0 is always verifiably correct. If variables represented a maybe-number-maybe-something-else, you wouldn’t be able to determine whether an expression is correct (what is “3 minus potato”?) until the moment an adventurer tries to evaluate it.

• Built-in references to other adventurers:
  Currently, you can refer to the active adventurer’s name within text areas via {player}, and can access the active adventurer’s stats etc. via expression functions. A few people suggested being able to refer to those of other players as well (e.g. {player2}). This is not feasible because there is no concept of a secondary adventurer, and because an adventure cannot know ahead of time how many adventurers will embark until the adventure has begun. For example, a reference to {player2} would not make sense if the adventure was being played solo.

• Make a way to “jump” to specific points in an adventure:
  Many players felt that testing larger adventures was difficult, because it was tedious to “jump” to a certain place in the adventure. The Instance Editor can of course be used to quickly set the current node, but because an adventure’s state often consists of a lot more information, players felt that setting all of these values was tedious. Unfortunately, no tool we could make would be able to automatically get you to “chapter 3” of your adventure as though you had played it, since it would be impossible to infer what it means to your adventure to be in chapter 3.

• Play with post text/post history display
• Upgrade Adventure search interface
• Make a way for characters selected have unique avatar backgrounds, or keep the set background from displaying on the characters
• Link to the character’s profile
• Consider ways to make the item display and interaction more intuitive
• Add more information about stat system
• Have the Adventure System remember character stats from Adventure to Adventure (If we go with universal and not adventure-specific stats)
• Create an easy way to access character’s stats
• Make it easier to find who the Builder is in the Adventure itself
• Create a standardized way to report an bug/error to Builder
• After Adventure is finished, a general feedback form for Adventurers to optionally fill out for Builders who have feedback enabled
• After the Adventure is finished, a way to give applause/kudos to an Adventure
• Embark on Adventures with multiple of the same Adventurer’s tests (tentative)

Our to-do list is very long, but we are excited to get started! Thanks again for your help! If any of you have questions or comments about the feedback or our implementation plans, post here and we will do our best to clear up any points of confusion.

“Many players felt that testing larger adventures was difficult, because it was tedious to “jump” to a certain place in the adventure. The Instance Editor can of course be used to quickly set the current node, but because an adventure’s state often consists of a lot more information, players felt that setting all of these values was tedious. Unfortunately, no tool we could make would be able to automatically get you to “chapter 3” of your adventure as though you had played it, since it would be impossible to infer what it means to your adventure to be in chapter 3.”

Regarding this bit (and I know I def suggested being able to jump around at some point), maybe a kind of tool that automatically pops all the vars into the editing field and you can just fill them in for testing purposes? This also might make it easier to troubleshoot specific vars~

Note: I’ve only read the section on features the team can’t implement. But I wanted to leave some workarounds for these two out of the three in particular that can be done with the current tools we have.

1. Built-in references to other adventurers:
   Currently, you can refer to the active adventurer’s name within text areas via {player}, and can access the active adventurer’s stats etc. via expression functions. A few people suggested being able to refer to those of other players as well (e.g. {player2}). This is not feasible because there is no concept of a secondary adventurer, and because an adventure cannot know ahead of time how many adventurers will embark until the adventure has begun. For example, a reference to {player2} would not make sense if the adventure was being played solo.

2. Make a way to “jump” to specific points in an adventure:
   Many players felt that testing larger adventures was difficult, because it was tedious to “jump” to a certain place in the adventure. The Instance Editor can of course be used to quickly set the current node, but because an adventure’s state often consists of a lot more information, players felt that setting all of these values was tedious. Unfortunately, no tool we could make would be able to automatically get you to “chapter 3” of your adventure as though you had played it, since it would be impossible to infer what it means to your adventure to be in chapter 3.

1) If you want to add in a reference a second player’s stats, you can. You can also tell which adventurer is player 1 vs player 2 etc, and I use such in quite a few of my adventures. Unfortunately, you can’t save a character’s name doing this unless the character’s name is 3-4 letters long. (I’ve done quite a bit of testing for a high score board that proves it impractical to encode/decode the whole alphabet to let people pick out names.) Even then, the name won’t be particularly visually pleasing.

For stats and which player is which, you can create a pre-adventure node where each player has to run a command exactly once in order for the whole group to progress, similar to the shop from the Icy Soul event. In this command, you set two variables. One is a global variable that is incremented regardless of who uses the command, and the second variable is an individual variable that is set to the global variable when the player uses the command. Whenever you want to know which player it is, just reference their individual variable.

Stats are a bit more variable-heavy, as you’d need a different variable for each stat for each player in your adventure, and set them at the same time as setting which number player is which. Alternately, if you’re only using it to determine the highest stat value for team-based skill checks, all you have to do is create one variable for each stat and check if the current player’s stat is higher than the team’s global stat variable when setting up which player is which, and set it to the higher value if so. Then use that team stat in any team skill checks you have in your adventure.

2) I highly recommend you create a ‘Utility’ or ‘Debug’ node for your adventure. Fill this node with different commands that set your variables, stats, or position in the adventure as needed for testing purposes. Then create a command in the starting node that moves you to the debug node. You can also have entering debug mode set a variable called ‘Debug’ to 1. Then you can create more debug commands in your other nodes with the required condition of ‘Debug = 1’ to hide them from the public. That way you can do simple things like undo certain choices in an adventure or skip around in longer adventures without having to mess with the instance editor. Just remember to remove the command at the very beginning of your adventure that turns debug mode on before you publish it. Do that, and all those debug commands automatically become inaccessible to anyone trying to play normally due to the now-impossible required condition. If you want to be extra secure, you can forego the command that turns debug mode on and just turn it on (or off) manually using the instance editor.

Thanks for the extensive write-up and all the work going through everyone’s feedback.

I think it might be inevitable that people’s imaginations are bigger than their time/skill, especially at first (I know I was). I think that might calm down one there are more examples of playable, fun, small-scale adventures.

I look forward to seeing the changes and people’s new stuff :)
(and who knows, maybe try my hand again after I graduate)

I’m extremely excited to announce that the Adventure System’s “action editor” is now live!

One of the most significant themes throughout the open beta’s feedback was that setting up commands was just too hard for a lot of people. JSON is a pain to write, inserting actions into if_check and attribute_check success/failure lists was a pain in the tookus, and debugging syntax errors due to stray commas and the like was just straight up awful. It was clear that for a lot of people, editing JSON was just not going to cut it.

The new system presents you with a simplified interface for creating your actions, lets you drag and drop them into place as needed, and brings in the documentation / explanations for every option without having to consult the knowledgebase.

We’ll continue to tweak the layout / construction of the action editor as needed, but functionally speaking it should all be there. Note that the legacy editor (which lets you edit the actions as JSON) is still available for now, because the guides all still refer to it — both editors update each other in real-time, so feel free to switch them back and forth as needed :)

Please let me know if you run into any problems with the new action editor.

Screenshot

I’m one of those rare, peculiar people that actually likes JSON editing, so I’ll probably stick to the legacy editor while it’s available _{please be nice and let that be forever} but I’m always happy to see things becoming more accessible, and I think it’s really neat the way you’ve translated the editor into a more streamlined process. The hover tooltips are also really helpful — it’s no longer necessary to keep the reference guide open in a separate tab to figure out what each of the fields does for every action you input.

Edit so not to double post

glitch Is there any reason saving changes in commands is restricted to the new editor? I’m aware it’s probably a minor annoyance to me and me alone, but I’m just curious as to why.

Hyasynthetic Yep! It prevents submission when you have syntax errors or other un-parseable actions, which is one of the benefits of the new system.

With regards to keeping the JSON editor around, I’m maintaining both systems for now to ease the transition, but don’t have the resources to maintain the two separate interfaces long term. I can’t say for how long the legacy interface will continue to be supported, but I will try to keep it around for a reasonable transition period.

So.. I am not sure if something is actually broken at the moment or if I am just not finding it, but it appears that there’s no way to add new nodes or edit the beginning node in the adventure editor…? <.< Also encounters seem to have disappeared completely, and instead there’s just add enemies, which I guess my boulder obstacle could be an enemy but does make it kind of confusing. >.>;

Edit-
..It seems the only way to get to the beginning node edit screen or make new nodes is by saving the adventure description, which takes you there instead of letting you see what you just saved. >_>;

Edit2-
So apparently the only way to edit nodes now is from the main adventure page, rather than their actual node pages, which is super clunky/frustrating. Could we get back the ability to edit nodes from their actual page? x.x If you have more than a few nodes, all that scrolling and trying to keep track of what does what is going to get incredibly confusing if it’s all lumped in a single page.

Ashlar
You can reach your introductory text (which I assume is what you mean by beginning node?) using the [0] Start command under Global Commands, add new encounters using the new encounter boxes at the bottom of each node’s box on the Adventure’s main page, and add new nodes by scrolling to the bottom of the Adventure’s main page and using the new node box.

If you need to get back to the Adventure’s main page, then you’ll need to click on its name in the bar that’s along the top of the screen (the one that reads Adventures >> Manage Adventures >> [Adventure Name] >> [etc])

I meant the node that’s originally titled Beginning when you first create an adventure - it took me like an hour just to figure out how to edit it, because for some reason all the encounters and commands are lumped into one page now. I eventually figured it out by asking a friend, but having to go back to the main adventure page and then having to scroll through a list of nodes and commands to find the one you want seems like it would add a lot of extra frustration - I’m not sure why the ability to edit a node from its actual own page was removed, but it makes trying to create a large adventure (or really any adventure) that much more confusing. Especially now that we have to scroll away from what we were working on to an entire separate page rather than being able to work on each node separately. I’d much prefer to be able to add commands to each node from its own page, just so I could know what was where rather than having to constantly scroll down a huge list.