Dealing with changes to game model/JSON scheme

[interrogator]

Today we found out that isAbsolute key is unused, so it was removed from JSON. That's good. Because of this, the time key format became redundant. Time is now specified like this:

{"time": {"time": int}}

Ideally, the nested object is simply replaced by an int. @christian-bernet however says that such a change is difficult to make. So, this issue is both the specific (i.e. making it simply "time": int) and the general (i.e. making it as simple as possible to update the model.

Game creators need the JSON format to be as concise and unambiguous as possible. It is already a lot of work building a game. Eventually, there will need to be a document explaining how to write your own game, and that document is going to have to explain that time is written in this redundant way. If even small changes like this can't be easily updated now (when we have few games and no users), I worry that maintenance will be super difficult later.

Can we get, at least, a few written instructions about How to update the model --- which files need to be touched, etc.. I can't imagine this part of the codebase was developed without considering the fact that the format may undergo revision in the future??

[martindusinberre]

Thanks, Danny, good point. @christian-bernet This isn't a priority for this particular sprint but please bear in mind that such information/documentation will be a key part of your handing the whole product over to us in March 2020 so that we can run it ourselves once the contract ends.

[christian-bernet]

The point here is, that these json files are directly connected to the graph model we have in the application. These means, that if we change something in the json files we touch the business logic of the application. If the business logic works with a certain attribute it is not only to change the model you also have to change the business logic.

So now we can ask, why you connect these json directly to the model. This is because, we search for a quick solution for Martin to build his content him self. Because originally it was planned that a developer adds the content to the database directly. But in the project we realized that there will be a lot of revision loops to get to the final content. So this was the quickest solution.

And for the future the idea of developing a content management system for the authors of marugoto. And in my opinion this is where the direction we should go and invest our energy. So this means in my opinion that the importer is just a temporary solution.

But about the documentation
The json structure or in other words the topic models are document in the graph model of the topic in marugoto-model-topic-entities.pdf. The model marugoto-models.xml can be edited with https://www.draw.io/.

Is that enough or do you need more documentation?

[martindusinberre]

Thanks, @christian-bernet
@interrogator Is this good enough for you? If so, please close the issue. Or let Christian know if you need more documentation.