Level JSON structure

[grady404]

So I thought about the two different versions of the wiring system for a while, and realized that if you have a lot of inputs/outputs in the same area (for example, if you wanted to make a level that was a maze of doors) it would be impossible to do so using the grid-based wiring system. For this reason I really think you should use the Starbound-esque wiring system, as it would allow for much greater flexibility when creating compact wiring systems. And because of that, I think you should keep the JSON files in a format similar to what they are now, so that you can set the start and end points of wires right next to each other, and wouldn't have to use wire IDs or something weird like that to connect the two points. No, this doesn't go against the entire overhaul, I think the way the objects are stored in-game is fine, but as far as the way objects are saved to the JSON files, I think it should be more similar to how it is currently. So forget the example JSON I AirDropped to you in class; I'll make a new example JSON, and upload it here as soon as I can.

[grady404]

So I assume all you need to do is get the inner workings of the game to interface with the visuals?

[cooperuser]

Yep, that's pretty much it

[grady404]

I feel like an idiot... it just dawned on me that I can sum up my entire argument about the color attribute and the wildcard blocks (see above) in one word: "interchangeable". If we were to make wildcard blocks a separate class rather than the same class with "color": 0, all of the different block colors would be interchangeable. That's what I was trying to say about the "behavior being the same", I now realize that was an awful way to phrase that.

[cooperuser]

Interchangeable? What do you mean by that?

[grady404]

So what I proposed is that for blocks, plates and switches, "color": 0 corresponds to blue, "color": 1 corresponds to red, "color": 2 corresponds to green, and "color": 3 corresponds to orange. Wildcard blocks/plates/switches are their own classes entirely. Using this method, if you created a level using "color": 0 blocks and "color": 3 blocks, you could easily switch it to utilize "color": 1 and "color": 2, and the level would work exactly the same. So in a sense all of the colors "work the same", they just don't work the same when you put them together. I don't know if this is a good metaphor for what I'm trying to say, but suppose I say that the north and south ends of a magnet work the same. They don't really work the same, since north attracts to south but not to another north, but they are interchangeable. If you change all norths to souths and vice versa in a system of magnets, that system of magnets would behave the exact same way.

With your system, where "color": 0 denotes a wildcard, the wildcard color is quite clearly not interchangeable with the other four colors. If you have a color with blue and orange blocks, and you change the colors so that they are now red and wildcard blocks, the level will work differently. Hopefully all this makes sense.

[cooperuser]

Yeah, that is what I thought you meant, but after we discussed earlier that we would use "color": -1 for it that sort of changes this, because it is clear that -1 is different from 0 to 3

[grady404]

Yeah, that's why I like wildcard being its own class, that makes sense anyway since it will utilize different code

[cooperuser]

But by using my method it will require less code, and keep the JSON neater.

[grady404]

How will it keep the JSON neater? My solution would take up less space in the JSON.

Yours: {"class": "Standard", "position": [0, 0], "attributes": {"color": 0}} Mine: {"class": "Wildcard", "position": [0, 0]}

[grady404]

And I see where you're coming from with it using less code, but you shouldn't cut code size at the expense of clarity and organization. If you could, you might as well write the entire program in one line.

[cooperuser]

Well I guess that "neater" isn't the right word. What I was trying to say is that it would require less things to memorize and understand if the user were to open the JSON. And also, what if we later add a new block type that acts differently from normal ones, but we want it to be able to have its own "wildcard" alternative, the only reasonable solution is to make it a color.

[grady404]

Block.WhateverTheNewBlockTypeIs.Wildcard

[cooperuser]

But how is that different from Block.WhateverTheNewBlockTypeIs.Green

[grady404]

And it would be harder for the user to understand the "color": 0 being the wildcard just from looking at the JSON. It's not intuitive, whereas Block.Wildcard is explicit and it's instantly obvious what it is.

[grady404]

Well anyway, even if you were to have wildcard as a color, I think that color would be best off as -1, so I would suggest you just make 0-3 the colors for now and decide how to implement wildcard later

[cooperuser]

"color": -1 is wildcard, "color": 0 is blue

[cooperuser]

That is already how it is

[grady404]

Alright, we can ask Brad or someone for a third opinion on this, there are obviously pros and cons to each approach

[cooperuser]

Yeah I guess so. Hahaha this is usually how all our debates end up