Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits) (+1)

Hello, first of all, thanks for taking the time to test and leave very useful feedback! Really appreciated, I’ll try to reply below on some of your topics.

  • Team License: everyone on the team can try the demo, which is fully functional, for as long as they want without issues until you decide if it fits your workflow or not.
  • Timelines: Honestly, I’m considering removing timelines for v2 as they are poorly implemented and might be redundant with the node based dialogue tree. (which is far more powerful), alternatively I’m also peeking at some libraries like this or this
  • Improved Markdown editor: This will be the new editor in v2 which I think will cover most of the writing needs. I also added better image support and internal document linking. However v2 is taking a bit of time…
  • Sortable list of projects: Good idea! Added to the backlog.
  • Backup: You can backup the whole database of a project as a json file with the “Backup database” action, or just the game content with “Export game content”. The whole app data lives inside %appdata%/drafft or ~/.config/drafft folder. Although there is no supported or easy way to use that folder as a backup. Its better to use the previously named options. There is also the “Auto Export Project Backup “ to save a fresh db backup when loading a project. You can also get a db-dump via the basic API
  • Version control: this is tricky, as the database lives in the ‘browser’ as an in-memory database (not file based). However I have an idea on how to make a ‘semi portable’ version. this will DISABLE the real time editing benefits of course.
  • Better Task management: Big fan of ClickUp here! As much as I’d love to see a full featured task management with @mentions @assignees, notifications and the usual goodies we should expect from it, I’m afraid it would be a big effort to implement correctly, especially in this “self hosted” approach. What I will consider is to add a “list-based” basic task manager (emphasis on BASIC) to complement the Kanban view.
  • Streaming/recording: go for it! Also, if you have useful clips to share I would love to watch/link them on the site.

Also thanks for the support and recommendation!

(+1)

thanks for the reply, The software is great. looking forward to seeing v2. ill try out the team. i had a think about the real time edit/database vs git /file based approach. i have an idea.

keeping the database is a good idea. but its mainly the documents that i think need the version control instead this could be of use.

when a document is open it could load a file, apon saving that file it could save that file as an auto export to word document in a specified path. While its open it could use a lock file or copy the existing “text based document” into memory allowing multi user still but the file save option will export the file.

still keeping the ability to live edit. but at the same time not locking it away some where and it cant be version controled. Essentially what im getting at is this :

[Server / Software] -> Settings {Set various file path for docs and other files} ––> server / software loads and reads the documents in said file path. {open document} -> initiate get (copy) into mem and add lock file… —> users save it checks and saves over the top or as a separate version and moves old version to a versioned folder.

Because its getting and saving it can be directed to a git controlled folder and be under version control and you dont actually need to change much in terms of software frame work. Plus the auto back up sent to a back up folder in that version control and the whole thing just works under git but keeps the server/software running entirely on its own.

This will help in times of disaster recovery as well as files are accessible fast and easily. as long as the software doesnt care that a change has occurred such as changed meta data to the existing file then git modifications from teams will work. also it will give you more freedom to develop services that matter as if there is a problem with git. thats gits problem. and restoring files is then just a matter of add the directory trees back and it sees the files and makes them available to the user. this will also give studios the ability to distribute the files consistently, know who makes a changes to the repo and when and prevents a complete breakdown if one person makes a mistake.

some things to think about at least. Hope that helps