Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit)

Hey - good questions.

The exe wrapper is because we don't have access to a unix system for testing, and wanted to make sure that it was as simple as possible for at least the platform we knew it was working on. In the long term, we'll be wrapping it in native apps for Windows/Mac/Linux bundled with the jre so it Just Works, but we didn't want to spend too much time on deployment at this early stage.

The key field is used for indexing because ultimately (at least as the design is envisioned right now) it will be a composite key, something like "001-01" for encounterNumber&"-"&sceneNumber, and the order of the array will be essentially arbitrary.

You might want to use an object (JSON object, in Java they're called hashmaps, I think) instead of an array for better performance, lookups in arrays are a bit slow. The left part of a JSON object is usually called a key, so I think it fits the purpose. The file would look like this:

{
    "script":{
        "001-01":{"scriptLines": ["encounter 1, scene 1", "hi"]},
        "001-02":{"scriptLines": ["encounter 1, scene 2"]},
        "002-01":{"scriptLines": ["encounter 2, scene 1"]}
    }
}

An alternative option would be using nested arrays, i.e.

{
    "script":[
        [
            {"scriptLines": ["encounter 1, scene 1", "hi"]},
            {"scriptLines": ["encounter 1, scene 2"]}
        ],
        [
            {"scriptLines": ["encounter 2, scene 1"]}
        ]
    ]
}

This approach might be better because you don't need to order the scenes manually and accessing array elements directly (when not having to loop through the whole array) is faster than using objects. The downside would be having to stick with numbers as encounter IDs, which could be a bit annoying with a larger amount of different enemies.

Sorry if I'm being obnoxious, I'll just shut up if you don't want that kind of feedback.

No, this is really good - I use JSON all the time, but I usually just let the tail wag the dog and structure the JSON based on what I want it to deserialize as. I'm using libgdx, which has its own json wrapper for dealing with serialization and deserialization, and also its own map implementations - and currently, the way that it's working is I deserialize that array, then iterate through it and build a map out of it with key -> scriptLines. Your first way makes perfect sense if I created a POJO for that to deserialize into, but I'd like to deserialize it directly into a libgdx ObjectMap for consistency. I'll give it some thought - we're not quite at the performance optimization stage, but this is good to think about now. I definitely wasn't married to that JSON structure, it was just a quick means to an end. If you spot anything else that raises an eyebrow, I'd love to hear it - dev feedback is really helpful.