Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

My experience from using this tool

A topic by Dead Lizard Graphics created Sep 25, 2021 Views: 449 Replies: 6
Viewing posts 1 to 4
(+1)

As a user of this application to manage a project I am working on, I would like to give you some constructive criticism, this application has lots of potential, but ultimately falls short. After a few attempts, unfortunately I went back to using Notion for managing the project. I would like to start with the strengths:

  1. The dialog editor and the kanban board, by far, the most useful features. The visual scripting part of the dialog has lots of potential.
  2. Exporting to json and other friendly formats to game engines, and programming languages.
  3. The converter of the dialog into screenplay format, this has potential beyond videogame developing.

Now, here are the features that could use some work, or scrap them altogether:

  1. The database-centric collaboration. This feature is virtually useless to most because installing a server to keep the project stored in a database is too much hassle for the indie developers that are likely going to use this app. I think you should scrap or abandon this feature and simply let users create a folder for each project, that ultimately can be converted into a git repository. A file format easy to keep track of in git (json, per example), could be the file that stores all the project's data. Collaboration in git is easy, you can run a git server yourself, but most likely, users will upload the project in many of the git sites available out there.
  2. There are sections that are in the app, Quests, Items, Misc, that serve no purpose but text data entry, they are not different between one another, and if they are not going to be fleshed out further, they should be reduced to one single category. That will clean up the UI. Scripts and Dialogues could also benefit by being combined.
  3. The UI is not particularly intuitive. To start working on a dialog, per example, you create the dialog, click on it, unlock it (the switch button to save/unlock the file isn't very intuitive), create a new dialog entry in the visual scripting board, and only then you can start writing. Streamlining the workflow will save you a lot of time having to write it down in the documentation.
  4. Now, the documentation, to put it kindly, it needs work. Right now there are a couple of broken links to videos, and incomplete entries. For an app sold commercially, this does not give a good impression.

And finally, here's a feature suggestion, I think you will hit the jackpot if you consider:

  • You know which is the most-used videogame project management tool, but wasn't meant for that? Excel (or Google Sheets, etc.). This is because game localization have been standardized in spreadsheets for decades. If you implement a spreadsheet meant exclusively for localization, you will spare game developers of another tool to juggle with.

I hope this critique can steer you into some solutions, but most importantly, I want you to continue working on this tool. Please don't stop development, you have something special in your hands.

Developer (1 edit)

Hello @harrymfa, wow! thanks for the time for providing a very detailed feedback, I really appreciate it!

About the pain points:

The database-centric collaboration.

I agree 100% that there should be another method of collaboration that doesn’t involve setting up a server. Especially git. But I don’t want to be involved in conflict resolutions/merges etc. What I could provide is some sort of “work from file” setting that would let the user use a json file as database (essentially a backup) and concurrency/conflict resolutions should be handle by the user and would be out of the scope of the app. I’m open to suggestions of any type on this subject!

There are sections that are in the app, Quests, Items, Misc, that serve no purpose but text data entry.
Well, the main focus of the app is to provide different ways for data entry, it is not necesary to use them all or to split it as presented. I agree Misc and Items might be redundant. However, I’m planning to add an option to enable/disable modules so you could theoretically remove “misc” db from showing up if you want to.

Merging scripts with dialogues might not be a good idea as they serve different purposes. (a dialogue might have a script, a script might not be a dialogue)

The UI is not particularly intuitive.
YES! I can see a major pain point in the workflow you just described, and should be refined. It’s not much but here’s a tip. If you double click in a script for example it locks for editing.

**Now, the documentation, to put it kindly, it needs work. ** No need to put it kindly, the docs are lacking and are quite useless.

And finally, here’s a feature suggestion…
This is on my radar, and it will be definitely be spreadsheet based!. I just have some issues refining the process (how to keep a “linked” translated version that updates with the original)

Thank you very much for the feedack, it is really useful!

(+1)

I wanted to chime in in regards to some of things that could use some work:

1. The database-centric collaboration. I get that this might be a hassle to many, it took a few tries with me as you can see in the post history, at first I didn't even know what couchdb was, but as a Developer that has team members in different parts of the world, once I actually set it up, it just worked, no problem, me and my team were really excited once we started messing around with it and could see who was working on what. I get why he chose couchdb, though as a kind of less recognizable name for databases as other solutions, I was left scratching my head for a while, and asked myself why not have other options like SQL as people are more familiar with it. I don't think it's a hassle once you figure things out, and as an indie developer I would assume at least one person in your team would be tech savvy enough to figure it out in the end, because once you do, it is powerful. Sure if a better solution can be done, by all means, let's have them, maybe it's too much work, but having different ways to connect for team collaboration would be pretty cool.

2. I believe they are just meant to be a text database that you can pull from and keep an inventory of all items/quests in your game, I haven't touched it much, so I have to check it further to give you an honest opinion and feedback.

3. It is something we are getting used to yes, and I'm sure some improvements could be made. It is a design decision on baj's part, and I understand his reasoning, but we could polish this further

4. Documentation. I have to agree on this one, some videos are not working anymore on the documentation, it could really benefit from more  written explanations as well.

Your localization suggestion sounds like it would be helpful yes, it would be cool if we had some features with localization in mind.

I have another suggestion if I may, I am used to using keyboard shortcuts to do my data manipulation, so i didn't really notice this at first. But I have team members that are more used to the right click menu approach, so it would be cool, if we could have the option to have both keyboard shortcuts and right click menu functionality.

I disagree with running a database not being a hassle once you figure it out. Running a server for a database is not a small task, it takes time away from development, you have to constantly save backups, not counting leaving the server running all the time. To put it in perspective, small to mid-size enterprises wouldn't bother with it and simply hire a third party to do it, or as I do, pay a monthly fee to one of those live data services, like Notion.

The solution of creating a text-based format to share the project in git has plenty of benefits, you can run a git server -if you want- but 99.9% of the cases you would simply put your project in Github, Bitbucket or Gitlab, which have some free tiers for teams (plus their own project management/bug tracking tools). The additional advantage of git is that you can keep track of every single change made, so I am not clear why "conflicts" have to be such a big problem. One of the reasons my team went crazy over the Godot engine was that they created a text-based format, .tscn, that is perfect for git.

Developer

I’m 100% up to adding a git workflow support, but it will have some challenge to address first:

  • Conflicts: We cannot “lock” items in realtime, so users could potentially edit the same item at the same time and conflict resolution should be done outside the app. Same with merges, pull requests, etc.

  • File based database. To get the most of git diff, each item should be a single file otherwise, keeping a single JSON would trigger diffs on any changes over any item, and potentially bring trouble with no experienced git users (they might end commiting and pushing before syncing or they may need to learn how to stash, etc)

  • No Realtime support. We should have a “mini git client” to at least notify the user for updates.

PS: Thanks @zaizeku as well for your input!

(+1)

"Running a server for a database is not a small task, it takes time away from development"

Setting up a small server does take time away from development, but it's far from being complicated. An used Raspberry Pi does the trick (and to be honest any team should have at least one server available, be it to share heavy files that platforms like GitHub aren't meant to handle or other things like that). It takes half a day if you don't know anything about CouchDB and ultimately the gain is worth the hassle. Any other similar tools I know of need a server to function properly (Articy:Draft for instance requires an SVN server), though it's sometimes set-up automatically as a background thing.

(+2)

I prefer realtime database-centric collaboration more than git, though.

At least it's more intuitive to users.