Create Your Own Choose-Your-Own Adventures!
Create Your Own Choose-Your-Own Adventures!
Like us (if you like us)
Hello, and welcome to Create Your Own Choose-Your-Own-Adventures!
Here, you may browse literally tens of exciting adventures, or register and create your very own!
Greetings one and all! April is upon us, and with it a bunch of people and websites who believe they can trick you. We have not partaken of that particular ritual this year, and I hope you all appreciate it.
Before going any further, let's quickly discuss the update from February to support registration for children under the age of 13. This was posted as a minor update, but it seems like a good idea to mention it here too: anyone younger than 13 may not sign up for the site without parental permission. They will need to email admin@cyocyoa.com to provide this consent. In conjunction with that change, the Privacy Policy has also been updated to address users under 13.
In any case, what's been going on with the site this month? Well, apart from the Design Post from a couple weeks ago, work has been progressing on the visual editor. The "Connect To..." and "Disconnect From..." functionality is now fully implemented, and the actual Screen Editor (where you can change the text of the screens) is now in progress, beginning with a slick animation:
In addition, the loading animations have been tightened up and navigation throughout the site feels a lot smoother. With the "macro" portion of the Visual Editor (where you create and move around screens) feature-complete, and the "micro" portion (where you edit their contents) relatively straightforward, we are getting noticeably closer to launching this monster of a project! Thanks, as always, for bearing with me and remaining patient!
Hello, and welcome to the second Design Post! This month, I'll be discussing the new Choosology "achievements" system, Degrees and Elements.
While there's still some design work to be done, the basics of this system are as follows: Each user will be able to view their own personal "Periodic Table of Achievements." Much like the Periodic Table of Elements, the PToA is organized such that each column contains achievements related to each other. For example, the first column will contain the "Membership" achievements, ranging from just having signed up (Registerium) to being a user for three years (Triannium). Users will automatically "discover" these elements for themselves when the conditions are met. Other columns will include achievements related to writing adventures (or "experiments"), being rated highly, having an experiment published, working with others, and other such activities. There would also be room to expand the table for new permanent achievements or the occasional temporary special achievement (maybe a "week of mysteries" where users are encouraged to submit a new experiment with a mystery theme).
Once a user has discovered every element in a column, a Degree will be conferred unto them. These will be something like medals; users can display them on their profile and can even choose one as an icon next to their username when it appears anywhere on the site. A Degree will be quite meaningful; to get one may require many years or an intense amount of work, much like in real life. Currently there aren't any plans to allow Degrees to unlock new functionality, but it wouldn't be out of the question. Primarily, though, they're just meant to give users something to work towards, and maybe show off a little.
That's pretty much the extent of what Degrees and Elements will look like. If you have any questions or ideas for good Degrees, please share them in the comments!
Until next time... may all your choices lead you to the best possible ending!
Hey, everyone! Our shortest month is over, and finally it doesn't feel like it's just dark all the time...
This past month has been busy indeed! I've been working with a graphics-savvy colleague (the one who designed the Choosology logo and backgrounds you've seen) to try to tighten up the design of the new site before it gets too far gone in one ugly direction. We've been working on improving the colors, adding some new foreground-background flair (it'll make sense when you see it), and adding smoother/faster loading animations. Plus I added the ability to connect two pre-existing screens in the visual editor as well.
Unfortunately, everything is in a bit of an in-between stage right now, so I don't have much of a screenshot for you. Next time!
As well, I hope you saw the Design Post from the middle of the month. This month, I'll delve into a new topic: Degrees! Degrees are basically the achievements of Choosology, and I'll tell you all about them somewhere around the Ides of March (beware!).
Goodbye for now, and may your choices always lead to the end screen with the most exclamation points!
PS: I realize the month labels on these things stopped being about the last month and started being about the just-started one. Well, it's too late to turn back now! Also, it's a lot easier to make fun titles with the spring months...
Hi, everyone!
As mentioned in a previous news posting, I'd like to talk a bit about plans for the future, focusing on individual features that are currently planned. With any luck, this should help you understand the direction the site is taking and let you give some feedback or suggestions about anything in particular you might notice.
This first post is about Inventory, Attributes, and Variables.
A common request (and one which I'd love to use myself) is the ability to remember certain information about a reader's choices in a particular run-through of an adventure. I'm talking about three different systems here, but at their most basic level, these all derive from the same core functionality--remembering the path which resulted in the current screen being shown. Authors could theoretically already curate their readers' experiences with a complex web of screens, but that would lead to an exponentially complex adventure for the purpose of fast-diminishing gains in quality.
For example, say you're several screens into an adventure and you want to show a different screen based on whether the user picked up a book or a sword back at the beginning. It doesn't matter for a while, but suddenly, this choice comes into play. Perhaps you enter a hut and if the oracle in that hut sees the book, she sends you on a different adventure than if you'd picked up the sword.
Right now, there are two ways to accomplish this:
First, you could create duplicate screens of all the screens in between, changing only the endpoint screen to reflect the different reaction of the oracle. This would mean copy-pasting several screens (and trying to remember to copy any updates you make to them later), and potentially having to do the same for any other branches from those screens. Obviously this is not ideal--it takes more time, takes more database space and loading/saving time, artificially inflates your word count, causes more errors in your intended reading experience, and will most likely just convince you not to do it as much as you'd like, meaning a lower-quality adventure is produced. That's not good for any of us!
The other option I've seen used is to simply ask the reader "Did you pick up the book or the sword back at the beginning?" and treat it as a normal choice from there. This has its own problems; it's clunky, adding an extra choice where there really didn't need to be one, relying on the reader's honesty (or memory), and making the program feel flawed and cheap. Still not good for any of us! All anyone really wants is for a particular choice to be remembered for later. How this manifests itself will differ, however, which leads to the three separate concepts.
Inventory fits best for the example I gave above. An Inventory system would allow the author to set up several potential Items, including their name and optional icon and description, and then attach them to particular screens. So at the beginning of the adventure described above, choosing the "Pick up book" path would lead to a screen that describes you picking it up, along with a special Action box that says
"You've gained an item: Book."
The user would also be able to see the items in their Inventory on the margins of the page, and click on them to view their descriptions (where the author might hide clues about their potential uses). Later, the author would attach a Condition to choices or blocks of text on other screens. In the screen where you can enter the oracle's hut, the author would actually set up two separate choices that both say "Enter hut." One would be attached to the condition that you currently have the book in your inventory, and the other would check that you have the sword. The two seemingly-similar choices lead to different screens, and the adventure then branches off from there into the different major paths it can take.
Alternatively, an item could just be a red herring, or something included only for humorous purposes. In that case, an author might not be interested in vast structural issues being dependent on the Inventory, but would want to include a short extra paragraph at the end of the adventure if the reader managed to find a particular item along the way. In this case, the author would simply mark a block of text in the final screen with a Condition referring to the item in question.
Inventory is important, therefore, because it allows:
- Better immersion in the story (and less immersion-breaking workarounds to the current lack of an Inventory)
- More options for authors to complicate their stories without too much work involved
- Improved reader experience as they watch their Inventory fill up with reminders of the choices they've made along the way
Attributes are similar to Inventory (as these all are truly just different sides of the same three-sided coin), but represent qualities of the reader's character rather than physical items. Take our story with the oracle and the book, for instance. Perhaps you want there to be more involved in the oracle's decision than just whether the reader is holding a book or a sword. If the book represents knowledge and the necklace represents strength, then perhaps you want to reward readers who chose to take the book and subsequently made knowledge-seeking choices before meeting the oracle. Then, once she sees your book, she first tests your knowledge before deciding to send you on the TRUE knowledge quest instead of just the normal one.
You could accomplish this with Attributes. The author would again have to set them all up beforehand--let's say there's an "Intelligence" Attribute as well as a "Strength" Attribute. Each of these would have an optional description and icon as well as a starting numeric or text value. The reader would see these Attributes near their Inventory (if they have both).
The author would then attach gains or losses in the Attributes to different choices. If the reader chooses "Ask homeless man about this area" instead of "Push homeless man out of the way," they would gain Intelligence points, or Strength points otherwise. Once the reader got outside the oracle's hut, the author would attach another couple of Conditions to handle which item the reader picked up AND what their Attribute levels are. So now there would be four possible choices:
- Got book, has good Intelligence;
- Got book, doesn't have good Intelligence;
- Got sword, has good Strength;
- Got sword, doesn't have good Strength.
So while the author would still have to make four branching paths from here, they wouldn't have to have weaved a tangled web of semi-copied screens just to get to that point.
Attributes are important, therefore, because they allow:
- Even better immersion options
- More ways for readers to see their choices have a direct effect on the story (when they see "+5 to Intelligence," for example)
- A granular way to track choice tendencies rather than just reflecting a single choice along the way
- Interplay with Inventory in exciting ways (like in the oracle story above; or maybe the reader can only use an item with enough Skill Points; or maybe the reader only gets to pick up the item at all with enough Perception)
Variables, the final system, are really just hidden and more flexible Attributes. A Variable wouldn't need to be set up like an Attribute beforehand, but could be created at any time, and also be altered by the reader's input. The author of our oracle story could insert a text box at the beginning of their adventure asking the reader for their name. Later, the author would use that name Variable to allow
the wizard to say "Hello, [name]! Come into my hut... I have a task for you!"
An author could ask for several words of different sorts during the course of the adventure and end up with a fun Mad-Lib-style ending. Alternatively, the Variable might just be called Points, and silently track the reader's actions in order to provide them with an ending screen reporting their "Final Score."
Plus, of course, the Variables could be used in Conditions like Inventory and Attributes to control whether certain choices or blocks of text are shown.
Variables are important, therefore, because they allow:
- Better immersion through personalized stories
- More options for replayability
- Tracking of values hidden from the reader
And that concludes today's discussion! I hope it all makes sense. Please let me know if you have any thoughts or ideas, or if something could be better explained. At the moment, I'm undecided about whether this will exist at the launch of Choosology.com, but it would certainly be my first post-launch project if not.
Happy February! I hope your local weather is not currently attempting to murder you or your loved ones.
January was a fun month, and rather productive! The visual editor now has two of its main functions implemented.
Create Child is back and better than ever!
As you can see in this fancy animated GIF, creating a child now has a satisfying animation associated with it.
And as you can see in THIS fancy animated GIF, the child will place itself wherever it can find a reasonable spot. This is a step up from the current method of picking a location based on how many connections exist already, regardless of where they might be positioned.
Deletion is back and... pretty much the same.
Here you can see that deleting a node will warn you first; if you confirm the deletion, all connections are severed and the node is greyed out. After a few moments (when the adventure auto-saves), that ghost of a screen will disappear, but you will be able to resurrect deleted screens in a future feature.
Next up: Connecting two existing screens, removing the connection between two existing screens, and then, finally, the actual screen editing.
Also: Soon (perhaps next week) I'll post a discussion of my vision about "inventory," "attributes," and "variables." Hopefully this will be the first of a recurring series about upcoming features, where I can get your opinions and suggestions.
Home 
Browse 
About 
Help 
Register