Narrat Editor discussions - What kind of features do you want?

Engine Development
1

There is an early preview of the new Narrat Editor available, which you can download here. For now it’s very basic and probably not very useful, but it can open your game project and let you edit it.

I have a lot of ideas for things to do next, but I’m also curious if anyone has ideas of useful workflows that having a desktop editor could enable?

Things I have in mind for now:

  • Add ways to create/update/build projects from the editor to avoid the terminal
  • Add a way to pop-out the game window into a separate window
  • Tabs, keyboard shortcuts etc for the text editor
  • More autocompletion/suggestions of narrat commands in the editor

Other things that would be cool but harder to make:

  • Screen editor where it’s possible to drag and drop buttons etc to place them visually
  • Config files editor, where a yaml file can be opened in a visual editor that knows about the possible config values and makes it easy to add config options without needing to look them up
  • Some kind of visual scripting editor showing labels as flowcharts
2 Likes
2

Separate window for the game is a must! Apart from that, drag&drop buttons wouldn’t be super useful to me, but a way to read cursor coordinates really would help position both buttons and sprites :slight_smile:

1 Like
3

It would be nice if there was a feature for critical successes and failures to bypass checks if certain numbers are rolled. For instance how Disco Elysium does its 2D6 Midnight = auto success and Snake eyes = Auto fail.

4

Hey! Just discovered Narrat today and got very excited before realising that, despite how it’s described, the tool isn’t very user-friendly for non-programmers. Even just having to use powershell is a huge turnoff for the majority of people who would otherwise be interested in the tool.

I don’t know what my feedback is worth, but I feel that a dedicated software that can be downloaded through a wizard and an interface that can be used to write and run the game would be the difference between this being a viable and non-viable product for me.

1 Like
5

The first thing here is narrat isn’t a product, no one is paying for it. You can’t expect the support and polish of a commercial product on a hobbyist engine, and a VN engine is likely never going to make money in any meaningful form that would enable a team of paid people to work on it.

Then for more specific details on this:

Game Editor

Making and then maintaining an entire editor for a niche game engine is a lot of work, and once it’s there it has to be supported on an ongoing basis. I did start working on a the editor which I have some plans for, but there wasn’t that much interest in it so I’ve paused it for now.

While it would be a fun thing to have, it is a lot of work, but more importantly as soon as I make a super easy download-this-exe way of using narrat, there will likely be a whole new category of users who are lazier and are more likely to ask repetitive tedious questions, which then create more support work for me. Without mentioning that the editor itself could cause its own entire category of support questions and bugs to fix.

Barrier to entry

Having a slight barrier to entry acts as a bit of a filter on how much people are willing to make an effort and do some research when using narrat.

While it’s nice to make the engine easier and more accessible to use, the more I do that the more I will get users who ask free work of me (in the form of help, support, feature requests, etc) while they themselves give up at the first hurdle.

I’ve seen over the years many people ask for complex feature requests, only to not actually make a game with narrat. I think a lot of people like to make complex plans but don’t like doing the actual work.

So then the question becomes, what do I prioritise with my free time? People who can’t be bothered to learn to type a terminal command? Or people who are actively using the engine and tinkering with it?

In my experience, the kind of people who can’t be bothered to get their hands at least a little bit dirty in game development tend to be unable to actually finish a project. This is for the simple reason that game development is inherently very technical, and while you may try to abstract technical details, you can never fully stop the technical details from leaking. If you do want to make a game all the way to release, you should expect having to do the uncomfortable work of doing new/scary/difficult things.

5 Likes