#i want to make a template that looks like ChoiceScript now...
Explore tagged Tumblr posts
Note
Hello Manon hope you're well! I was wanting to ask for a little bit of coding advice if at all possible? I don't know if you know of Brushmen's code collection to make Twine look like Choice script. I was hoping you would know a way to do something similar in the sense of wrapping the choices in boxes the way they did (similar to how choicescript does.)
Hiya Anon,
Of course! Happy to help.
Yes, I'm familiar with the template, thought I hadn't noticed the update... It is now meant for more intermediate users, it seems.
The source code does provide what is needed to make it happen (which is essentially a custom macro in JavaScript, with some extra CSS to make it pretty). You will need to download the projectfiles.zip from the page, extract it, find the choices.js and choices.css files inside the src folder, and add the code to your project. You can also find examples of how the "<< choice_shown >>" macro is used in the story folder.
However, if you just want to make it look more like ChoiceScript as in rather than
you want
You will need to choose another SugarCube macro: << radiobutton >>. Essentially, code your radiobuttons for the choices (and wrap each of them in a < label> for accessibility), and wrap the whole in a < div> for the styling. Don't forget the button for confirmation!
< div class="choices"> < label><< radiobutton "$choice" "value" autocheck>> Value 1< /label> < label><< radiobutton "$choice" "value2" autocheck>> Value 2< /label> < label><< radiobutton "$choice" "value3" autocheck>> Value 3< /label> < /div> << button [[Next]]>> /* More code if necessary */ << /button>>
You will need to remove the spaces... Tumblr otherwise eats the code...
Then we move on to the StyleSheet:
.choices label { padding: 11px 8px 12px; display: block; border-color: #a9acaf; border-style: solid; border-width: 1px 1px 0px 1px; } .choices label:first-child { border-top-width: 1px; border-top-right-radius: 8px; border-top-left-radius: 8px; } .choices label:last-child { border-bottom-width: 1px; border-bottom-right-radius: 8px; border-bottom-left-radius: 8px; }
That's for the radio button. We target the label, because it's the easiest and it takes into account the whole option block (radiobutton and text). The second and third code is to round the borders.
And if you want the button:
.macro-button { clear: both; display: block; width: 100%; font-size: 1.5em; font-weight: bolder; font-family: -apple-system, sans-serif; margin: 1em auto; color: #f7f4f1; background-color: #626160; border: none; border-radius: 0.5em; padding: 6px; }
And so you get:
#coding support#sugarcube#twine#coding in twine#interactive fiction#i want to make a template that looks like ChoiceScript now...
14 notes
·
View notes
Text
Small preview of the new interface we'll have in the Week One update.
This template by Becky gives me Choicescript vibes. I love how the menu is accessible right at the top bar. I've added a background with a subtle twinkle effect. Light mode has a gradient background. Honestly I think a lot of people will want to play light mode now, it looks so pretty. Also, as I mentioned in a previous post, fantasy terms will be toggle-able, like so:
Dark mode is also twinkly:
I'm going to focus on writing for the next couple days and stop playing with the code. This weekend I'll make a post with the official changes coming to the rework. I approached it with a focus on cutting out a lot of the religious angst (in a manner that doesn't do a disservice to the MC's character growth) and instead focusing on the MC adapting to her new life/body and having more quality time/relationship building with Serax & Valdricht. We'll also have new tendencies and a new system for tracking them, a dedicated MF story line with a unique plot for Nightborn players, a feature to amp up the dark thematic elements, and some light tweaks to Serax--you'll have to needle him a bit harder to bring out his immature side.
Looking forward to sharing the changes with you!
#bride of shadows if#interactive romance#twine wip#twine interactive fiction#update#week one update#vampire romance
85 notes
·
View notes
Note
I don't understand this trend of moving IF games to Twine and persuading authors to do so. Maybe Twine is so great, but for authors and I have the impression that some people don't think about the reader (comfort of reading should probably be more important than aesthetics?). I noticed that versions of some games after moving to Twine were becoming worse to read for me (I mean page - underdeveloped and unintuitive design, no mobile version etc. ) so ofter I just gave up reading ���♀️
I'm sorry Shai for writing here, but nobody seems to notice the issue in this community and I had to express my frustration 😩
I mean, I do have friends who opted to use Twine instead for various reasons, one of those being the issues in CoG itself (which, you know, I have to agree with), and they ended up happy with that decision so I really have no qualms in supporting them the way I can.
That doesn't mean, of course, that you have no right to feel upset about the fact that readability has become a prevalent issue. I guess I can kinda relate? Like I said, I have problems with my vision, and reading in choicescript never hurt my eyes as much as they did when I started reading IFs made with twine, aside for a few, so I could never spend a long time when it comes to the latter. I also know some folks who've been having difficulties using their screen readers because of the formatting--though certain templates are now allowing for that possibility.
However, Twine is also a great opportunity for authors to be creative with the stories they make. For a lot of them, writing IFs remains to be a hobby (with some also preferring to proceed with an independent publication), and if they're having more fun designing their games the way they are doing it, no one can honestly tell them to stop doing that. Plus, some UIs end up looking pretty cool while maintaining the readability, so there's still a chance that may apply to the others, too, given time.
Anyway, while we all have our opinions on the matter, at the end of the day, it's still up to the author, isn't it? They made the decision to switch knowing that there are readers who will leave them, and if they're satisfied with it, then I can at least respect that and keep supporting them. Every reader has different preferences, too; there are some who prefer the ease that choicescript offers, but there are also those who hate how bland it looks--these tend to prefer the appearance of Twine formatted games instead.
What some people may hate, others may love.
I can wholeheartedly say that it’s valid for you to avoid them, though! Just do keep in mind that it’s also just as valid for authors to choose the platform they want to use. There’s nothing wrong with either of those. I say this as kindly as I can, since I do understand the frustrations due to my condition, so let’s also try to see the reasons why several authors felt the need to make the switch and attempt to acknowledge those. It's still their work, after all.
#i have no time to proofread this right now so I hope it makes some sense#just currently taking care of some stuff
30 notes
·
View notes
Note
hi, I was wondering, and please ignore if you want, if you've heard of or considered using twine/sugarcube
I just know your theme would be amazing and twine/sugarcube may give you more liberty with mechanics
also if you are afraid of not knowing how to make the game pretty, there are some free templates that you can download and mess around with
Working with twine/sugarcube might seem difficult and it may be at first but there are many work arounds and a good community that can help you and who have answered a lot of questions that you may have
oh! and some have also provided mechanics that can really enhance your game!!! like HiEv and Chapel
you can check out interact-if or idrellegames here on tumblr for some info on twine
anywho I really enjoy the game and look forward to what you write later on!! sending lots of energy 😊 💕
lol I hope I didn't sound like an ad
Edit: I’m still using CS for now since it’s the one I master more than Twine and I don’t want to lose the momentum of my writing and I’m also still planning on publishing through HG. But I also really want to try out Twine on the side to test myself and it’s always good not have to be fully dependent on CS only.
I’m really interested in trying out Twine 😄 And what a coincidence that I saw your ask now because I actually have just watched some beginner’s tutorials yesterday 😆
I really want to try porting at least the Prologue of Vendetta in Twine just to try it out once I have the chance. It is harder than CS by quite a lot… But the creative things we can do with it really intrigues me and makes me think it’ll be worth it to at least try.
I would really love to be able to use the red, black, and white color themes for Vendetta’s demo in Twine, and being able to change font sizes and colors to add to the dramatization and emphasis (the most I can do on ChoiceScript is using Bold and Italics and putting the sentences on the Next button).
Also, adding images and sound effects! Oh my, I can’t wait to add some little sound effects for immersion 😩 For example, in the Prologue, it’ll be so cool to be able to add a gunshot sound effect when Viktor first open fire on the incoming enemies. Really add to the surprise MC felt too.
Also, for this anon, do you know where I’ll be able to discuss and ask for help regarding Twine, just in case I ran into problems? If you know, please let me know through another ask (and maybe you can send one without going anon? So I can try to contact you?)
But thank you for telling me about more about where to get resources regarding Twine! 🙏 Really appreciate it!
48 notes
·
View notes
Note
Hi, sorry if this is an obvious question but I downloaded your Twine II template (as well as the pamphlet pdf) and find myself completely stumped on the stat pages. They don't seem to actually be recorded stats in twine? I'm very new to twine so I may be completely wrong. How exactly do you use the stat bars?
Hi! No worries. As I've said before, there are no dumb questions here.
The stat pages are built and styled with CSS in the template, but they are not populated with functional variables. I think I've mentioned this before, but Twine doesn't come with stat bar functionality the way, for example, ChoiceScript does, nor does it really come with stats in general. Basically, in Twine, you have to build everything yourself, so the functionality of the stat bars is something you have to code manually in JavaScript, and stats are something you have to create on your own by using variables.
In the template I've simply built the stat bars' html for you, and styled them to make them pretty, but not added the functionality to make them "change" according to whatever variable they are representing.
Now, I thought about coding the JavaScript for the stat bars and including it in the template, but I think it would be difficult for people to use it unless they actually understood how it was done and how it works? Because the number of stat bars and other stats will depend entirely on you and what your story entails, so it's not really something that can be provided in a general template like this. The possibilities for stats are... literally endless, because you are the one creating them.
And the stat pages provided are just examples of a stat page, because most stories have their own stat pages depending on what you, the writer, want to display and showcase. I just thought I would provide an example with styled elements that you can play around with to create your own stat page. You don't even have to use stat bars to display your stats, if you don't want to. There are other ways.
With that being said, @innerdemons-if provided a wonderful explanation of how to code the functionality of stat bars here, so that's worth looking at ✨
Twine is definitely a little more complex to use compared to ChoiceScript, but in return the possibilities with what you can create in Twine are endless. I hope this made it a little clearer for you though!
26 notes
·
View notes
Text
Recruiting Beta Testers!
Hello! Now that the game is starting to get into a more advanced stage of its development, I’m looking to expand my beta testing team. :D Please read on if you would like to help test and edit the game!
Benefits I’m offering beta testers:
For obvious reasons, beta testers will gain access to new updates roughly 3-5 days before it is released to anyone else.
Access to an exclusive channel in the AMR discord where I post WIPs of the game’s art assets as I receive them, and sometimes blabber about plots and plans I have for upcoming updates.
Special merch that will be mailed to your doorstep sometime after Book I’s release, with my compliments!
Details under the cut. :D
What I’m looking for from beta testers is feedback on the build before it goes out to patrons. In descending order of priority (though all are important):
Game-breaking bugs (most of which should be cleared via Quicktest, but just in case!)
Continuity errors (i.e. pronouns, the game showing you a limp-exclusive passage when your injury is something different, mentions of Nyx when your phantasma is Satiel; you get the idea)
Misdirection (a *goto-*label error, which makes the text repeat/look disjointed)
Sensitivity reading (Am I portraying discrimination insensitively? Am I propagating harmful stereotypes? etc.)
Grammar & spelling issues
High-level feedback (plot, pacing, character development, dialogue). Ex: 'I was confused how everyone found out about the mage's innocence', 'I found x character unsympathetic and unlikeable because x y z, I think it would improve their character if they a b c'
Choice suggestions ('I wanted to say x at y scene, but the option wasn't available)
Weird stat adds ('I thought this option would add +Emotional, but instead I got +Charming)
Writing style and diction
As a general rule, I welcome any and all actionable and elaborated feedback, no matter the nature. It just so happens that I won't act on them all the time, either because I don't agree with the feedback, or most likely because there are time/energy constraints.
If you are interested in applying, please note that:
You will be expected to submit beta testing reports on a regular, per-release basis. Beta testers who do not submit their reports on two builds without prior notice ahead of time will lose their beta tester status*.
You must have a discord account, or agree to set one up.
You must be willing to submit your feedback in the required format, via Google Sheets, with the following template (which will be made available to you upon becoming a beta tester):
(Filling out the file and line fields is optional, but appreciated. Special thanks to the amazing @devilbydaylight for coming up with this format!)
This should go without saying, but please keep exclusive information (like the beta build’s contents and stuff in the private beta testing channel) to yourself.
*At each beta-test build release, I will denote a 'deadline of feedback submission' in the build's opening screen. This is not a hard deadline, and submissions beyond that point are still useful! It just signifies the time I'd need the feedback to be received by in order for it to be implemented in the Patreon build. It is most likely a couple of days after the beta release, and one day before the Patreon demo release.
Application:
I am receiving applications via email, at [email protected]. If you wish to apply, please send me an email, with details as follows:
***
EMAIL SUBJECT: AMR Beta Tester Application - [Where You Found This Post (Tumblr / COG Forums)] - [Tumblr / Forum Username]
Paste this form into the email’s body:
What you would like me to address you as:
Pronouns:
Please list or mention, if any: writing and/or programming experience, your relevant experience in beta-testing other choice games, Choicescript familiarity, writing/programming your own IFs, and any other information you think may be relevant to your aptitude as a beta-tester.
Please list or mention, if you are comfortable disclosing it: your nationality, age (just major/minor is fine too), minority groups you belong to/identify as (for sensitivity reading purposes). It is okay to leave this field blank--your application will still be processed.
***
I already have four incredible beta testers working with me at the moment, and am presently looking for an additional four-five people, to prevent myself from getting overwhelmed. Deadline for application is 21st of April, 2021, at 11.59 GMT +7.
Thank you very much for your interest!
85 notes
·
View notes
Note
when i transferred over, it took me a long time to port everything, like i want to say like 2 months; i started moving after i finished my prologue and chapter 1 in choicescript, and it was not a fun time 💀 but i had a lot of content, like 400k words, and cs was also my first experience with coding Ever, so it was definitely a hard learning curve for me personally.
i had coded my variables in a way that worked really well in cs, but not so well in twine, and i still sometimes find random bugs in ch1 because of it, versus ch2, which was all written for and coded in twine from the start. most of the issues i've had in ch2 have just been me making silly mistakes or typoes.
i definitely think it depends how much you end up having to port over, and how complex your code is. it can be a lot of work, and very tedious when it comes to copy-pasting and changing the variables.
i also second Fiddles when it comes to the UI elements; while the transferring was boring and tedious, setting up a UI was the actual hard part, especially because again, i was someone with 0 coding knowledge. luckily there are a lot of templates that walk you through it now (like the one i use which is by nyehilism) and there's also a lot of coding advice floating around on tumblr, too, so don't feel too intimidated. and of course sugarcube does come with its own basic theme, like Fiddles said, so even if you aren't sure how you want your game to look yet, you can still get started and worry about it later. though i know it's hard when you want your game to look sexy right away.....
my honest advice is that if you know you want to move to twine, then you should start the move before you get too far in cs. obviously i don't know what your wordcount looks like or what kind of branching you have planned, but with tnp being so big it was really time-consuming and frustrating once i started porting. but ultimately it's up to you, and what you think will work best for you, i just wanted to share a slightly different perspective.
i'll repeat what Fiddles said which is that the most important thing is having a strong base to work with. you can't do anything if you don't have anything written down. try not to get too caught up in the UI and aesthetics right away, and focus more on the writing and coding for the story.
good luck! :-)
Perhaps you've answered this so far, but how easy is it to transfer a game from the COG system to twine? I'm working on my WIP in the COG system right now (it is the coding system I'm familiar with, and I honestly find COG's simple UI much easier to read than the more intricate twine ones), but do not want to release it on that platform. I intend to put it on twine at some point. But the more I write, the more I get worried that I'm just creating more work for myself.
Personally, I think it depends on how much design work you want to do! Transferring all your variables and text from CS to Twine is kid stuff. I found that actually making the game look good was the hard part, because I had to blitz-learn CSS (and am still learning. I have a whole clone of Greenwarden in my Twine files that's just for testing cleaner code) to make it look nice, which is entirely optional. There are also plenty of Twine templates you can use!
Twine has several different versions built in that are good for different things. I use Sugarcube2, which comes with its own customizable UI, and so does @northern-passage. @heart-forge uses Harlowe. There's also Ren'Py, but that's a completely different beast and is mostly for visual novels. There's also Inform, which is a modern version of the coding language classic IF games like Zork and Planetfall were written in!
For that cleaner, classic CoG Ui, I might recommend Twine's Chapbook language! I haven't personally used it, but you might find it familiar and easy to read.
TL;DR: Not that hard, especially if you've already got a strong base to work with.
111 notes
·
View notes
Note
How do you do the planning to create an interactive fiction game? I have the general idea for an interactive fiction story but I'm a complete mess when it comes to organizing and planning. Where do I even start?
Hi Anon!
I was waiting for this question to appear at some point, lol :P I spent all day on this....
Create your Interactive Fiction Game
Last February, I detailed my process when working on CRWL. You can read that post here. It is not a perfect (or even good) template to use, since it is specific to that project in particular. I also have a list of programs I am using/have used when creating my projects here!
But, yes, organisation and planning is VERY important when you want to tell a story, no matter if it is in a game or novel. But unlike a novel-like story, you need to add coding on top of it. I would say these are the two big components of IF.
Disclaimer: I am not the Voice of Knowledge when it comes to creating IF, takes this information with a grain of salt and do some research too! :)
Long post, so breaking the post. Here's a Table of Content
1- Gameplay/Visual (aka Choosing your Coding Program) 2- Planning your Story (or Why it is better to start small at first) ~ ~ A- Game Pattern ~ ~ B- From Pattern to Outline ~ ~ C- From Outline to Writing ~ ~ D- Writing Tips 3- Coding the whole thing ~ ~ A- You are stuck ~ ~ B- Test everything ~ ~ C- UI Customisation 4- Publishing and Marketing ~ ~ A- Publishing your game ~ ~ B- Regarding marketing ~ ~ C- Scheduling Updates and expectations
1- Gameplay/Visual (aka Choosing your Coding Program)
Though the story is very important (obviously), it is important to know what kind of gameplay and visual you want for your game because it will dictate what kind of program you should use:
Do you want to make a Visual Novel? Then you might want to look into programs like Ren'Py.
Are you gravitating towards parsers (player entering words/sentences to advance the story)? Inform might be what you need.
Do you just want to give players choices? Twine formats and ChoiceScript seem to be the most popular ones on Tumblr.
Note: There are waaaayyyy more programs that those four, and you may be able push the possibility of what a program can/is supposed to do with enough coding knowledge.
Even in each category, some programs will be more complicated to learn than others. For the Choice-base games for example, ChoiceScript is considered one of the easiest to code in terms of logic and formatting of code. In the same vein, the availability of tutorials/community* to help will make a huge difference in learning the program. And finally, some programs may require some knowledge of other languages (ex: HTML/CSS) for further use/customisation.
Note: While most may be in English, there may be even tutorials/communities in your language! (if you are ESL)
And finally, you may want to think about the visual aspect. Some programs/formats will allow you more customisation than other, whether it be text formatting to complete customisation of the base UI (how the page looks). For example, in Twine (SugarCube/Snowman especially) , you are only limited by your knowledge of HTML, CSS and JavaScript.
P.S.: Some programs, like ChoiceScript, are not open-source.
A good way to know what kind of program you want to use is to look at tutorials online and test it yourself too.
2- Planning your Story (or Why it is better to Start small at first)
Now that you've settled on a coding program, it is time to work on a story.
If it is your first time, the best advice I can give you is to start with a small and contained stories. The learning curve can be daunting when starting, more so if the project is complicate and long. Starting short and easy won't feel too overwhelming, you will learn what works best (or doesn't work) for your creating process AND it makes it easier to learn coding in your chosen program. Starting with a full-blown RPG with extensive Combat Mechanics and hundreds of long-ass quests is not a good idea if you've just begun with the program.
You can even take advantage of Jams to test your skills/ideas or request feedback on IF Discords Communities or in the IF Forum.
But whether your story is large or small, the planning part should be very similar.
A- Game Pattern
So you have an idea for your IF, great! Now let's think about patterns, or how will the story be told. Do you have a linear story in mind leading to one important finally choice? or do you want a lot of branching with many endings? Or even a lot of choices culminating in one final event?
Knowing about pattern will help you plan the story and define important events to happen. It will also make you think of variations to take into account and what kind of action you'd need to reach a certain part of the story. Obviously, you don't have to stick to one pattern (as you work more on the story), but it helps.
I really like this blog post detailing the different patterns of CYOA games. [I used it when creating MtP]
B- From Pattern to Outline
With that general idea of how the story should pan out, we can start fleshing it out a bit more. I often use the "Funnel Technique" when I create my stories (big picture to small details), but it may work more for linear stories rather than very branching ones. It goes something like this:
Start with your general idea: genre, theme, world, time period, etc... But stay general. You don't need to go into too much details at first.
List your big events and make a timeline: what is the conflict to push the story forward? why does it happen? what does character should learn from it? what can they do to resolve it? etc...
Do the same with other smaller plots (if you have them!): every plot needs a reason for it to happen.
Combine the timelines: not only some beats will need to happen before others (especially if they are the catalyst of the next one), this will help you to know when to introduce a certain character/lore/etc...
Delimit your chapters: with your timeline, you can now break it off into smaller chapters (you can include what important action/information each chapter should have).
And here is your outline!
During this process, it is a good idea to keep note of everything you can think of: characters background/personality, important lore of your world, etc...
It is also then where you may want to think of aspects to track (relationship, choices, etc...) and give it a name.
While you don't have to research things at this stage, it may help you if you are working with a topic/setting you are not familiar with.
C- From Outline to Writing
Now that you have your outline and your timeline, you are closer to writing :D You could decide to write away, or you could plan your chapter a bit further.
I usually do the later, as it helps me think of possible places to include choices or variation for the player. [This is also where the graph comes into place] I even go a bit further and plan each passage (text screen), making notes of what the player will see (dialog, action, description...) and if there is variation to include. This last part is very much detailing work, and helps me with writing.
After all this, it's time to write!
D- Writing Tips
Here are some stuff that I do to help me not get overwhelmed when I write and help me to be organised when I code:
The "one page per screen" technique, where you add breaks between each screen/passage, can be helpful to demarcate each part of the chapter/scene you are writing. Headers or links with a table of content can also be helpful !
While it matters little at the beginning, tracking choices and consequences of those choices and important variables will help with continuity and variation. For example, if you give the player the choice to set their height, you should take this into account if the MC goes into tight spaces. Similarly, if the player chooses to confront someone, the next page should probably not have a romantic tone.
Use colour code, comments or formatting when writing to separate choices (link list or cycling options, etc...) or variation for a tracked variable (ex: tone of voice, physical change, etc...) from the rest of the text. This will help when coding.
While writing, if you get ideas to include further into the story (ex: new choice, mechanic, sub plot, etc...), write it down on a separate page and only come back to it when you are do writing the part/passage/scene/chapter. A sudden idea might seem fitting but may push you towards a dead-end.
Edit Edit Edit! 1st drafts are awesome, but it can always be improved [Cough cough, not calling myself out at all, Cough cough]. Using Grammar Checks is immensely helpful (more than one, since none will focus on the same aspect of writing). And Beta/Sensitivity readers are godsent!
3- Coding the whole thing
When your story is ready (or part of it you are ready to release), you will need to code it.
The best advice I have for this is to code your story first and make sure it works. It can be tempting to deep dive into the formatting of the page (especially if the program you chose enables you to customise it extensively). An IF can look amazing, but if it breaks everywhere, it is not going to be fun to play.
A- You are stuck
And don't worry, it happens to every one! Coding can be a difficult puzzle to solve, even with the solution right under your nose.
The most important advice I can give is to always refer to the official documentation or look for tutorials online (other may have come across the same issue before you).
If nothing helps, there are often coding communities (that focuses on the format/program you are using) where you can ask for help (Discord/Forum, etc...). Do not be afraid to ask for help!
B- Test Everything
And when you are done, test again. Testing/Playing (whether by yourself or with Beta Readers) is the only way to catch errors.
Similarly, if you want to add some custom code to your project or use a built-in functionality, but don't know if it works, the best way to find out it to try it out! Read the documentation, play with the code and test it.
C- UI Customisation
This part will be highly dependent on which program/format you are using. While CSS/HTML is the same anywhere, it's implementation can differ greatly. Be sure to check the official documentation about the matter.
If the program allows you for customisation, this can be loads to fun to edit your UI to make it look however you want. Like the previous point, this can need a lot of testing too.
If you are just starting, having the basic UI is just fine :) You can always change it down the road. But if you want to zhuzh it up, here are some elements you can consider when editing:
Colour palette fitting your story. Steer away from bright colours if your story is dark, and vice versa.
Image in the background can make text hard to read. Having a block of colour between the text and the image will make reading much easier.
Colour contrast is IMPORTANT. Readability is easy to mess with when having multiple colours, use this website.
Simple is usually better. A complicated or busy page will be distracting. Stick to simple.
Use a template. This is more of a SugarCube comment, but if a template is available (and you like the vibe), use it. It will make editing your UI easier (tag or link to the creator in your game page/post).
If you can: remember to make your project as accessible as you can (with your knowledge). Colour contrast (maybe dark/light mode), Font change (font, size, etc...), limit or toggle animated text/images, etc...
4- Publishing and Marketing
A- Publishing your game
There are many places on the internet where you can publish your IF projects. Different formats will congregate towards different websites. For example: Dashingdon hosts only ChoiceScript, Itch has anything and everything, Steam will require a fee to publish there. You can also host your projects on other platforms or your personal website (ex: Neocities allows it), though you might want to stick to places where there is an established readership. In any case, follow the selected website's instructions for publication.
If you have a working and published demo (or finished game), I'm nudging you to create a page for it on the IFDB. There, people can leave long reviews and rate your games! You can also Archive your project to preserve it. [SAY NO TO LOST HISTORY]
B - Regarding marketing,
If you are lucky, the algorithm god will pick up your game and show it to everyone. You'll get thousands of readers and hundreds of ratings. You'll always be on everyone's top page and you will go viral.
But if you are not (like most of us), you can start building a readership on social media. Tumblr had a substantial community for IF, Twitter has quite a lot of game developer, Mastodon is a thing I think?, and there are a handful of Discords and Forums dedicated to Interactive Fiction. Having a presence and be reachable is unfortunately important.
Some random points:
Announce your project before you publish it, but be close to be ready to put it online when you do so!
Do not "sell" your project on something you are not sure you can achieve (ex: game mechanic, complicated romance, etc...), just to set expectation.
Have an introductory post with a synopsis and links to the game/demo (if available) and important known aspects (genre/theme/TW). Depending on the genre, you may want to include short intro of some characters.
Make pretty pictures for your posts/game page (Canva is free-ish)
For ChoiceScript: having a CoG Forum page seem to be important for reader interaction and getting feedback.
On Tumblr: submit your project to directories like @interact-if, follow and interact with other IF authors, answer asks, do Tumblr stuff...
On Itch, consider introducing your published project in the Community section, write devlog for updates or discussion, answer comments, review other IF games...
Discord: some IF/Coding discord allows you to promote your projects there, take advantage of that.
Be upfront about your boundaries and keep them! (less marketing, more of a social media interaction thing)
C- Scheduling Updates and expectations
Unfortunately (and I say this as someone who is really bad at it), having a regular update schedule may be the best thing you can have for your project, especially if it is a long WIP. This can help keep your readers engaged with your content. If you have longer breaks between updates, writing prompts can be a nice substitute.
If regular is not possible (which is totes super fine! don't burnout on something fun), have clear communication about the state of the project. Set specific upload dates (ex: 12-Oct-22) when you are close to release it, have vague ones (ex: end of the year) when you are in the early stages. This will help with expectations and disappointment.
Do not promise more than you can do. That's pretty self-explanatory. And fix bugs you receive as soon as you can.
AND! And I can't stress this enough. IRL should always come before updating your WIP/publishing content. You should never force/push yourself to do so if you are not enjoying it. Do not be like me and hurt yourself. No amount of notes/readers is worth the hurt!
TLDR: Do not be like me, be better.
Right. I think that's it.
105 notes
·
View notes