Made Branch json-db-0.1. Does this workflow work?

[MadeofTin]

So, if the schema of the json-db works for you in the branch json-db-0.1 I will only make changes that add to the current definition. Like more riddles and levels basically, but nothing else, or change the background image. It is just random un-purchased stock art at the moment so yeah....

See if this work flow makes sense. Or, if there is an easier way to do this.

1. If I make a branch from json-db-0.1 called json-db-0.2.
2. I add new items to the schema in json-db-0.2. For example a new setting or sound recording for the riddles I have made.
3. Then I add some riddles using the db0.1 schema.
4. If I sync do I get the new riddles in db0.2 from db0.1?

If so then

1. I can make db0.2 until it is complete and validates all tests.
2. You can change your importer into parse to account for the new db changes (either you, or the import script your write when you write one).
3. If that works on your end then we can deprecate/delete json-db-0.1 and branch db0.3 from db0.2.
4. db0.2 is the now supported version and db0.3 is the development version.
5. Then we continue the cycle till we hit the v1 release milestone.

Basically, your importer(either you or your script) would always work consistently for the master supported db version. So you can just follow the same workflow you do for that version. I mean there will be bugs, but they will be regulated to a certain schema which will make it easier to squash since there isn't any BIG changes. I'll make a list of changes the import statements should account for, like changing riddle order, or changing the value of the points you get for a riddle.

When I make edits to db0.1 I will merge them into the master branch. So, I can add riddles as I write them, and make changes that don't break schema. Like add more levels, or change the riddles around for balance. Or make edits to riddles. (I saw a couple weak ones that need some work and spelling I am sure is bad)

But, I can also work on the next iteration of the db like a setting we need for a certain feature or adding support for custom fonts, or audio files for the riddles. Any out of schema changes would be made in the dev branch of the db (now db0.2) until tests past on my end, you update the importer, then we make db0.2 the master supported version and I develop on db0.3.

Is that over complicated? Or would this make it easier on you? What would you recommend?

[pcardune]

I think this is overcomplicated for now. I wasn't planning on writing an import script for parse but rather just loading the json files directly in javascript. In parse I will just store the ids of the levels/modes/riddles that you have completed or made progress against, but not the riddles themselves. This has one very important consequence which is that the IDs you use in the json-db should be consistent across all versions of the db. r1 should always be the same riddle no matter what so that if someone completes riddle r1 in the first version, when we upgrade them to the second version we can still give them credit for completing riddle r1... even if it ends up being in a different level or mode or what not.

How does that sound?

[MadeofTin]

That sounds way better. I wasn't sure how parse would handle it.

Exactly what I was thinking. I have the Riddle IDs so hardcoded they are on the paper I wrote them. Haha. (I like writing on paper when I write.) R60

As I have been testing with my friends I am leaning towards a more open world format than a linear progression format. So each difficulty will just get bigger and bigger riddle lists (means I have to write a lot more riddles, but I am okay with that). Users than balance the game themselves since they can choose which difficulty to work on and go till they're frustrated then work on another. Difficulties get unlocked based on your score. You get points each time you solve a riddle times the difficulty multiplier(will make more sense as I write the full v1 v2 milestones). But, the way I intend to monetise it is for the people that just want a casual game experience they can buy a difficulty reducer. They can only reduce a level difficulty not increase it. This would be v2 so just keep it in mind.

Somehow we would need to track when they change a difficulty of a level, so I think level IDs would need to remain consistent as well. If I needed to change a levels riddles I would just move the riddles around inside it. If I change riddles around and I change one into a level they have reduced it would give them the reduced number of points when they solve it.

On your end you would also need to track the difficulty the riddle was solved to correctly give them their score when you mark them as having solved a riddle.

Those are about the only things I think you would need to track on the apps end. Everything else could just be generated from the json files.