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.

[cooperuser]

But do you think that having 0 instead of blue is a good idea?

[cooperuser]

(even if we do that I think that 0 should be white)

[grady404]

There is no white...?

Are you thinking of hollow blocks?

[grady404]

And the reason I think colors should be numbers is that different themes might map the colors differently

[cooperuser]

Oh I consider wildcard as you call it to be white

[grady404]

Wildcard should be a completely separate thing.

{"class": "Standard", "position": [0, 0]} {"class": "Wildcard", "position": [0, 0]}

[cooperuser]

What? no... a completely separate thing?

[grady404]

The reason is that wildcard blocks actually behave differently from the other blocks. All Standard blocks have the same fundamental behavior, it's just that they have different numbers that correspond to which plates they can activate. It would be weird if it were like this:

0 blocks can activate plates that are 0, 1, 2, 3, 4, etc. 1 blocks can activate plates that are 1 2 blocks can activate plates that are 2 3 blocks can activate plates that are 3 4 blocks can activate plates that are 4

^^^ Spot the inconsistency

[cooperuser]

I though there were gonna be colors, then a white one that goes on all

[grady404]

Wildcards aren't actually going to be white, I don't think. I think they should kind of look like the Windows logo (best thing I could think of as an example), with each of the four corners a different color so the player kind of intuitively knows what they do from looking at them.

[cooperuser]

eh....

[cooperuser]

but what if we integrate the light block, which could have different colors, and wouldnt that have its own wildcard?

[grady404]

Trust me, code-wise it will be easier if Wildcards are their own thing.

if (block.color == plate.color) (Wildcards separate) if (block.color == plate.color or block.color == 0 or plate.color == 0) (Wildcards = 0)

[grady404]

Lightweight blocks shouldn't be able to activate plates at all.

[grady404]

If they do, we can have a Block.Lightweight.Wildcard in addition to Block.Standard.Wildcard

[cooperuser]

But what if we do integrate some sort of block that can go on plates, and can be colored, and can have a wildcard... I think that it would be more intuitive if it works with all types of blocks

[grady404]

I found a loophole. If lightweight blocks can activate plates, and we thus want different colors of lightweight blocks, and wildcard lightweight blocks... won't we want lightweight hollow blocks too? Then we'd need a color for hollow also... I think this would be easier:

Block.Standard Block.Standard.Wildcard Block.Standard.Hollow Block.Lightweight Block.Lightweight.Wildcard Block.Lightweight.Hollow

[grady404]

I just realized how dumb this whole "Standard" thing is anyway. Why not just make Block the class for standard blocks?

Block Block.Wildcard Block.Hollow Block.Lightweight Block.Lightweight.Wildcard Block.Lightweight.Hollow

[cooperuser]

Because then we would have the superclass in the game, and that is not good

[grady404]

But if we're going to be using Block.Standard.Wildcard alongside Block.Standard (subclass/superclass), why not just use Block.Wildcard and Block?

[cooperuser]

I do not think that there should be a Block.Standard.Wildcard I think that everything that does not have a color, is wildcard, which is default to white, or 0

[grady404]

Or else, we'd have to do it like this:

Block.Standard.Standard Block.Standard.Wildcard Block.Standard.Hollow Block.Lightweight.Standard Block.Lightweight.Wildcard Block.Lightweight.Hollow

[grady404]

I definitely don't think that wildcard should be a color, because the block actually has different behavior when it's a wildcard.

[cooperuser]

What kind of different behavior? all it does thats different is it activates all other colors

[grady404]

"A block of color n can activate all plates and switches of color n, and nothing else."

If color 0 denotes a wildcard, it breaks that rule.

[cooperuser]

The O blood type is considered the donor blood type because it can be used by all other types, but that doesn't make it something that isn't a blood type?

[cooperuser]

But what set that rule in the first place?

[grady404]

Your code will set that rule, and besides it's better to have things consistent.

[grady404]

Besides, if wildcard is a color, why isn't hollow a color? They both relate to which plates and switches the block can and can't press...

[cooperuser]

No, hollow is its own block subclass, completely separate from all colors, and it doesnt interact with colors in any way, the "wildcard" as you called it would be a color because it has the ability to fit all colors.

[grady404]

The other problem is it might be confusing for people editing the JSON. Again, "explicit is better than implicit", to quote the Zen of Python. It makes intuitive sense that 0, 1, 2, and 3 would correspond to the four main colors within the game.

[cooperuser]

I think that to people who do not know programming, that 1-4 are the main colors and that 0 is the outlier that acts differently

[grady404]

Besides, I really don't think Lightweight blocks should be able to activate plates. Lightweight blocks are meant to be pushed and shoved around to reach other places. It kind of ruins the challenge of Lightweight blocks if they're the ones that are supposed to be pressing the plates, not the ones that get shoved around in the process.

[grady404]

Oh but we're already using 0, 1, 2, and 3 for rotation, and 0 and 1 for enabled/disabled. If all the other attributes begin at zero, it makes perfect sense that this one would too.

[cooperuser]

Okay, disregard what I said about lightweight blocks

[cooperuser]

But that makes sense because it is 0 for no rotation, and 0 for no color, or white

[grady404]

Hmm... I don't know. It just seems to make more sense that in most levels, all of the blocks would have color 0. Blue pretty much is no color, since it's the default, and all other colors are basically variations that only appear in a few specific levels.

[cooperuser]

Then why not have 0 as the default color, either make all blocks be white in those levels, or have a scan to see if there are any other colors, and if not, make 0 blue

[grady404]

You know, we could always use -1 for wildcard later, which would make more sense than 0. Think about it, in Python's .find() string function for instance, it returns -1 if it doesn't find the character. So -1 is more of a "nonexistent" value than zero is, and it would make more sense that the default color (blue) is 0 rather than 1.

[cooperuser]

But python uses -1 because if it said 0 that would mean the first index in the character list, and about your argument earlier about having the colors be 0-3, in this case it would just be 0-4

[grady404]

And like I said, I think wildcards should have all four colors displayed on them, so it's clear what they are. Like the wildcard in the game UNO for instance

[grady404]

And no, the colors would be -1 to 3.

• -1: wildcard
• 0: blue
• 1: red
• 2: green
• 3: orange

[grady404]

That way, in all the levels that only have one color of block (probably around 80-90 percent of levels) all the blocks would have color 0, which makes perfect sense.

[cooperuser]

Okay, that is a valid argument. However, we have to continue this another time because I have to go somewhere now, I might be able to continue on my phone though.

[grady404]

Alright, I kind of wish we had a third person's input to help us decide... whatever though. I would suggest just setting it so that 0 is blue for now, since we won't be adding wildcard blocks for a good while anyway. If need be, we can change it.

[cooperuser]

Yeah, good point. Whenever we enter a situation like this I have been asking people for their opinions, I have asked Brad about stuff like this and he usually has done good input.

[grady404]

Well anyway, have you actually implemented any of this JSON stuff yet?

[cooperuser]

Yeah pretty much everything we have mentioned so far is in the new system so far

[grady404]

Oh really? So it's actually implemented?

[cooperuser]

The game isn't "playable" yet, but it's functional