Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+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.

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.