Full WASD/Arrow Key Controls

[grady404]

I honestly can't believe I didn't think of this earlier, but it would make the game's controls so much nicer, and it might even fix the WASD bug in the process. It'll involve completely changing the way boxes are selected, etc. but it will be completely worth it, and I actually don't think it will be too difficult. The problem with the game's controls in their current form is, the player isn't able to execute moves as fast as their brain can come up with them, which makes the game significantly less enjoyable to play. (I would make the priority on this six stars if I could, so please get on this ASAP!) So here's how the new system would work. Every time a user hovers over a box, that box becomes selected (just like it does now), except that box stays selected until the user hovers over another box (or clicks off of it), rather than deselecting as soon as the user moves their mouse off of that box. A selected box might have a white border around it, or maybe some sort of glow around the edges, so that the user always knows which box is selected. The four move buttons will still only appear when the user is directly hovering over a box (because why would they show up if the user can't click them?), but the border around the edges signifying that the box is selected will persist when the user moves their mouse away. Here's the thing. When the user presses one of the WASD keys, it will immediately move the selected box, regardless of whether or not the user is hovering over it with their mouse. That way, the user can easily press multiple WASD keys in a row without moving their mouse, to send a box to a spot on the opposite end of the screen.

Now there's actually a Part 2 of this which will make the controls even nicer (hint: it's an easier way to change which box is selected), but I haven't quite worked out the specifics of it, so just focus on this first until I have.

[cooperuser]

I was also thinking of this idea, and I also thought of a way to change the selected block using arrow keys, and the selector would immediately move to the nearest block in that direction

[grady404]

Yep, that was my thought too but the thing is it's kind of ambiguous which blocks are "in that direction"...

[cooperuser]

I was thinking of it just going in a triangle shape from the direction, finds all of them, and then finds the closes one

[grady404]

I do have one idea though, but it's a bit difficult to explain. When the user presses one of the arrow keys (I'm going to say they pressed right for the rest of this example), the game finds all the blocks that are "to the right of" that block, or have a greater x-coordinate than that block. As an example, where A is the block and the o's represent the area where other blocks will be taken into consideration:

...oo
...oo
..Aoo
...oo
...oo

For each of those blocks, it calculates its proximity to A using the Pythagorean theorem (I'll call this value d), which is fairly simple. It then calculates the angle (which I'll call θ) between the line drawn from A to the new block (which I'll call B), and the line drawn directly right from A. Here's an example of those two lines:

......B
.....x.
....x..
...Axxx->
.......
.......
.......

So now the calculation has two parameters: d and θ. It then takes the cosine of θ (which will be 1 if B is directly to the right of A and 0 if B is directly above or below A, any values in between signify that B is diagonally up and to the right of or down and to the right of A). The program uses the value (cos θ)/d to determine the "priority" of each block. In other words, blocks will have a higher priority if they have a lower d value (thus being closer to A), or a higher value of cos θ (which would mean that they are more directly to the right of A, because as B moves more upward or downward this value diminishes).

When you press the right arrow key, whichever block has the highest priority will be the block that the game shifts focus to.

[grady404]

By the way, if you implement both of these features that will mean that the game can be controlled entirely by the keyboard, with no mouse input... so... controller support?

[cooperuser]

There is a much easier method that i thought of, its a bit hard to explain though

[cooperuser]

If we do have full keyboard we should have a button for wires

[grady404]

No, I get what you said. It would be like this:

......o
.....oo
....ooo
...Aooo
....ooo
.....oo
......o

And then it takes the nearest block to A within the o's

[cooperuser]

yes

[cooperuser]

I couldnt really explain because im on my phone right now

[grady404]

The problem with that is, if there are two blocks that are roughly the same distance from A, but one is directly to the right and one is directly diagonal, it might pick the diagonal one

[cooperuser]

hmm... then make the diagonals worth 1.4

[cooperuser]

root 2

[grady404]

That's what I was saying. Take this as an example:

.......
.....O.
.......
...A..O
.......
.......
.......

Which O will it prefer?

[grady404]

The one directly to the right is 3 away, the other one is only about 2.8 away

[cooperuser]

oh

[cooperuser]

well, in real life, the top 0 is closer

[grady404]

It is, but it's less "to the right" than the other one

[grady404]

And when you press right, you want to find a block that's both nearby and "to the right"

[cooperuser]

and that that was the point of the cos theta

[grady404]

Yeah exactly, the greater the value of cos θ the more "to the right" it is

[grady404]

What about this?

.....
.....
.oA.o
.....
.....

...which one is closer? (it's DEFINITELY not "to the right" though, that's the exact problem)

[cooperuser]

well here it would only check that one

[grady404]

Yeah, but it's more to make a point of why "being more to the right" matters

[cooperuser]

yeah

[grady404]

It kind of seems hacky to only take into consideration blocks that have a cos θ value of √2/2 or greater, and not actually use cos θ for priority

[cooperuser]

yeah...

[grady404]

Another thing is you can of course do this entire calculation with ∆x and ∆y... in the example that the player pressed the right arrow key, just do this:

cos θ = x/√(x^2 + y^2) d = √(x^2 + y^2) (cos θ)/d = x/(x^2 + y^2)

As it turns out, the four priority values are these:

Right: x/(x^2 + y^2) Left: -x/(x^2 + y^2) Up: y/(x^2 + y^2) Down: -y/(x^2 + y^2)

Seems pretty straightforward, and wouldn't take too much processing power for a lot of blocks.

[cooperuser]

Yeah, this seems like a good way of doing it

[grady404]

If their priority is ≤0, they shouldn't be accounted for at all

[grady404]

So if there are no blocks on the board with priority >0, pressing that key shouldn't do anything at all

[cooperuser]

Yeah

[grady404]

Speaking of priorities:

1. Overhaul
2. Minor fixes/improvements
3. This

[cooperuser]

Yeah

[grady404]

Once we/you do all that, we should actually start looking for playtesters (I'm sure there are plenty of fifth and sixth graders at the school that would be happy to try the game, they have to be people who haven't seen the game already)

[cooperuser]

And I also constructed a way of downloading the build version of the game

[cooperuser]

I also plan on adding a Update feature

[cooperuser]

that automatically checks for updates on the loading screen

[grady404]

Yeah that's a good idea... you know how the second and third digit of the version number are supposed to be backwards compatible? In that case, when downloading those updates you'd only need to update the source folder, not the save-data folder.

[cooperuser]

Exactly what I had in mind

[grady404]

For the MAJOR version updates, you'd probably want to force users to download the entire game again, just so they don't screw anything up, unless you have a way to convert the deprecated save-data folder to the newer version

[cooperuser]

I think of a way, but in the meantime, I can just make it so that levels have a version variable

[grady404]

Which would only include the MAJOR version?

[cooperuser]

Yup, because the MINOR version only includes additions. But wait, if we remove a feature, would that bump the MAJOR or the MINOR version...?

[grady404]

Depends if it's backwards compatible. For example, if you removed hollow blocks and that was included in the JSONs of levels, you'd have to wait until you bumped the MAJOR version to change that.

[grady404]

But for a feature like that, you could just remove it from the main levels of the game and keep the functionality to use within the level editor.

[cooperuser]

Because everything is using subclasses, I can check if that specific subclass exists, and if it doesnt, it uses the superclass

[grady404]

You could do that actually, but it wouldn't really be backwards compatible because it would most likely break said level

[cooperuser]

True,

[grady404]

And you could always remove an object like that from the main game and disable placing it within the editor, but if a JSON was found with that item in it, it would display that item and it would work as intended but it would give the player a notice that the object is deprecated. Then when the next MAJOR version is released, the object is removed permanently.