Things people want to know about your new system

[Hidnook]

We have had a huge influx of new platforms released recently, and a lot of questions have come up over and over. With that in mind, please consider these questions and ideally answer the relevant ones in your announcement post. Not all of them will be relevant to your platform.

First things first, though: make sure it’s in Technical Development > Development Systems with the new-platform tag.

Development

Where is the documentation for creating a game?
Is there documentation for how a programmer could extend the system?
Is there built-in support for managing extensions/modules/libraries?
How easy is it to pick up and use?
What does the syntax look like?

Environment

Is development and hosting on the website only or is there a separate IDE?
Can you save projects locally?
Offline editing?
If you have a WYSIWYG/no-code editor, can you switch between that and some sort of programming language/pseudocode?
Does it support spell check?

Exporting/publishing

Are games exportable as playable websites?
Can you download/play games outside the platform?
Can you share the resulting game freely?
What license do games made with your platform have?
Can people play without an account?

Logic/mechanics

Are there ways to get complicated mechanics made (e.g. variables, functions)?
How complex can the logic be?
Random number generation?
Text input?
Random cycling text variation?
Repeatable choices?
World model support?
Can you make relatively linear storylines easily?

UI/UX

Is it easy to style your stories, without elaborate knowledge of CSS?
Are there alternative color schemes for the site interface?

Platform comparison

What does it do that other well-known IF platforms struggle with?
What does it struggle with that those platforms do well?

AI

Was AI involved in the making of this system?
Is AI a part of the features?
(If the answer to these questions is “yes”, please add the ai tag!)

Business model

Is it paid or free to play/write/use?
If paid, how do you intend to attract paying readers?
How does the monetization model compare to something like Itch?

Proof of concept

(Most people choose an IF platform by playing a great game from it first.)
Is there an example game written using the system?
Which examples do you think best demonstrate its strengths?

Accessibility

Support for languages other than English (possibly diacritics and non-Latin alphabets)?
Screen-reader friendly?
Can any timed text/quicktime events be altered by the reader?

[gfaregan]

Also - what is the long term plan? One recent post said something like “I’m going to charge $10 because otherwise I wouldn’t be interested in doing it” which sounds both like they aren’t very interested in doing it and that it will quickly get dropped in the likely future where it doesn’t make any money, which is nice to know if you’re deciding whether to commit time (and money apparently) to it. On the other hand, if you have a compelling reason why you are creating your system, you should talk about it.

[zarf (Andrew Plotkin)]

@Hidnook

Is it paid or free to play/write/use?

If paid, pay to write, pay to play, or both?

Also: open-source or not?

(This is not the same question. Free tools are not always open-source. Pay-to-use systems are usually proprietary, but occasionally you see an open-source tool associated with a paid service, on the grounds of “You can run it from source if you want, but it’s a pain in the ass so you’ll be happier using our server.”)

[Draconis (Daniel Stelzer)]

And at the very top: what is the key selling point of your system? Why should people want to use it? I suspect people on this forum are willing to read quite a lot more text than on other social media sites, but you should still put this front and center. That’s how you get people excited and interested enough to keep reading!

A couple recent ones who did a good job of this:

• Atrament’s key selling point is “like Ink but more versatile”, with feature lists, screenshots, and example games showing off that versatility.
• ChronicleHub’s key selling point is “StoryNexus is shutting down, this does the same things”, and its documentation includes various examples of “here’s how to make it work like Fallen London”, “here’s how to make it work like CyberpunkDreams”, and so on.
• Bardic’s key selling point is “we have basic Ink choice flows and Twine nodegraphs, but also you can include arbitrary Python code”, showing that it has a low skill floor (it doesn’t take much effort to get started and make basic choices) and a high skill ceiling (you can do basically anything with Python).

All three of these have the hook of “here’s how it’s like a popular existing system” (showing that they’re familiar with the community, and drawing interest from people who like that system), combined with “here’s what it can do that the other system can’t” (Ink has very limited styling, StoryNexus is shutting down, Ink is very bad at data processing that Python can do easily). In my opinion, that tends to be a winning combination!

[dfabulich (Dan Fabulich)]

I worry that folks who are inclined to procrastinate on writing a great game will use this list of questions as a checklist of “things I have to do before I start writing a great game myself,” which would be a big mistake.

We don’t really need the answers to most of these questions. People do kinda sorta want to know all of these things, but I think the vast majority of these questions are just idle curiosities. It’s not like a bunch of people are suddenly going to show up and build a bunch of great games in a novel system if the framework answers 100% of these questions.

And having so many questions makes the whole process seem really overwhelming, especially if many of the answers are going to be “no.”

“No, programmers can’t extend the system. No, you can’t save/edit projects offline. No, it doesn’t support spell check. No, you can’t export to Itch. … I guess my new system isn’t worth anything after all.”

But, truly, you don’t really need much/any of that stuff. “All you need” is a great game. I admit, that’s actually quite a tall order, but it also eliminates a lot of unnecessary busy work.

I think it’s especially important to hammer home the “great game” point (as I’ve been doing, over and over) because the vast majority of people who create systems like these first started making a game, got frustrated, and said, “ah, you know what, I’m a better programmer than I am a writer, and all the existing platforms kinda annoy me… instead of writing a great game, why don’t I just build a better IF platform? Then someone else will write great games for me, and I can stick to doing what I’m good at.”

It seems like I keep saying it and the people I say it to kinda can’t accept it. They say, “ah, he’s probably right, I do have to write/fund a great game…” but they just can’t seem to get started on that game. Building an IF platform was their way of procrastinating writing an actual game.

And some people really can’t accept that having a great game is all you need. “No way! I put all that time and effort into polishing these features. And none of the features matter?! Well, that can’t be right. I’m just going to work on one or two more features and then people are going to really love my new system.”

I think this is especially true for systems that allow (or require) authors to develop in a “real” programming language. Those never seem to get popular. Anyone capable of writing IF in your Python-based IF framework can write their own Python-based IF framework, and they’ll probably prefer to do so, precisely because “real programmers” struggle to force themselves to write a great game in any existing IF platform.

[Warrigal (Garry Francis)]

Here, here.

Just out of curiosity, what came first @dfabulich, ChoiceScript or a great game? If it was the latter, what game was it? I’m only asking because I’m a choice-based game ignoramus.

[Encorm (N. Cormier)]

I don’t necessarily disagree, but I think the list is useful as an alternative path. It could be presented more as: “Do you have a complete, good game written in your system? If not, here’s the questions people will ask: […]” If nothing else, the length will do a great job of pushing people towards making a game!

I think it’s also worth saying that this list IMHO is at least in part a reaction to the number of new systems developed by people who seem to be not only unfamiliar with this community, but with text gaming in general. I think people are getting tired of it (I certainly am!) and at this point I’d rather link people to this list than explain some of these points for the hundredth time.

[zarf (Andrew Plotkin)]

It’s not a checklist because you’re never going to answer “yes” to every point. And that might turn out fine. (Look how long it took before Inform was open source.)

But you do have to think about why you’ve made the choices you’ve made. And these are all choices. The answer may be “That wasn’t a priority so I didn’t focus on it,” but people will ask.

[jkj_yuio]

I have a problem with your “great game” hypothesis. I think it’s necessary but not sufficient. And even the “necessary” part I think applies only to having a “good” game as opposed to a “great” or “admirable” game. Because the sufficiency part does involve having something new in the system.

I think the existence of a great game only proves you are a great author. And a great author could probably write a great game in pretty much any system going. That’s unless it is really poor indeed.

So a great game is more of a reflection of the author than the system, in my view.

Having said that, the existence of a great, good or any game, does mean a system functions enough to build it. And that’s well worth demonstrating nevertheless. Which is why i think it’s necessary.

On the subject of IF and “real” programming languages, Ren’Py is a massive counter example to your claim. It has a huge following. But despite that, i do agree that there are problems with this route. I see systems where people are basically chucking in either various derivatives of JavaScript, Lua, Python or whatever fancy language they happen to like a lot.

For me, I still like the DSL approach to IF, and it isn’t because i have a problem with “real” programming languages, it’s because I want the right tool for the job. Or, at least, a tool designed for the job as opposed to a general purpose.

It’s my view that modern systems need expedience as opposed to features. A good game is necessary, but, “How hard was it to write that game?” That’s the question I want to ask.

I want building a good game to be easy, not just possible.

[averyhiebert]

I think I’m on the same page. You need a game that proves you can make something good in the system, and you also need a selling point where people can see why your system makes it easy and/or pleasant to build that kind of game, not just technically possible.

The lack of a game casts doubt on the system (“if it’s such a nice system to use, then why can’t you clear the bar of making a game in it?”), but you still need people to be able to look at the tutorial or docs or whatever and think “oh, yes, I can see why this system would be a natural way of making that type of game.”