Defining directional input for an irregular grid

[karai17]

In a regular grid, you have very obvious up, down, left, and right directions. When taking input from a user, it is very clear which cell within the grid they want to highlight.

In an irregular grid, this is not always obvious. An irregular grid can be defined as a group of sibling objects that are in an unstructured positioning scheme such that the items have no defined path between them. This makes determining if "left" input from object A is expected to go to object B or object C.

What I propose is a sort of constellation system where a set of objects are are handed to the parser and the parser spits out what up, down, left, and right means for each object.

As you can see from the above image, each Star object has a path to nearby objects. In this example, the maximum paths seem to be three, but for a GUI system I believe we can have a maximum of four.

So my question is this: What sort of data should the parser require? I suggest that a table of objects, a maximum radius for paths, and maybe more?

-- in this example, each obj has at minimum an X any Y coordinate
-- units of measurement are listed in dp, not px
local objects = { obj1, obj2, onj3, obj4, obj5 }
local radius = 5
local grid = dom.get_constellation(objects, radius)

[Germanunkol]

Yes, this is what I meant. The way I last implemented it was: When a new object is added, do the following: Create four empty lists.

1. Calculate the vector from the new button to every other button, and calculate the angle between this vector to the other button.
2. Depending on the angle of this vector (i.e. how large is the angle between the vector and (x=1,y=0), for example) put the button into one of the four lists.
3. table.sort the all four tables by distance to the new button
4. The "neighbours" of the new buttons are now the ones closest in each list.

[karai17]

Aye, my thinking was to set four directions with a triangular shape coming from each and having a maximum radius so that if there are several object within the "up" triangle, and within radius, it chooses the closest object. If there are no objects then pressing "up" will simply not move you anywhere.

[karai17]

I suppose each object should have a navigation table that determines how to move through objects. I don't think objects should have any navigation by default since it would take some annoying logic to determine if objects are vertical or horizontal, which objects should be navigable from one another, etc.

If a user needs to set up navigation such as for a basic menu or some such, then gathering a table of elements (maybe a sibling table aka a parent's children) and pass them through this function to define the navigation, and manually set anything that is missed (such as a rollover from the bottom to the top).

This sort of method would work find for both a regular and irregular grid so i think a generic API name should be fine:

gui:set_navigation(elements, radius)
elements[1].navigation.up = elements[#elements]
elements[#elements].navigation.down = elements[1]

Navigation's main task is to adjust which element has focus.