Multiplayer Hex grid game (?)

[droqen]

Started this project last week

Sick, so progress is slow, but getting back in the practice of noting pain points


Parent/child component complaint noted

I like change_query a lot, it's very cool

Since I don't have 3D modeling in my workflow, I 'had to' create hexes out of three cubes... actually, I've been doing a lot of mathematics for this hex thing

Ray casting isn't coming out of my camera the way that I expect and it's hard to debug. Is there a 'display raycasts' debug option...? Live would be ideal but that's not happening

How can I section off my code into neat modular pieces? The ECS is actually great for letting me think this way...

It's hard to access the camera from the client... oh, but I should use the debugger to see what components it has. That would help a lot. TODO

[droqen]

Am I using queries correctly? Probably not. I noticed colour does not propagate from parent (hex) to children (cubes, 3 per hex, produce the hexagonal prism), and so performed a change_query attempting to pass that down—I check for my hex identifying components, hexx and hexy, but is the right way to do this to add some new component whose purpose is to propagate colour changes?

It seems that a change_query propagation component must always necessarily be on the source of the change, not the child. Naming should really make that relationship more clear... i.e. not 'local_to_parent' on the child, but rather give this component some name that communicates that it is just listening for its parent to propagate that change downstream? It is effectively a flag? Unless I'm misunderstanding.

Let's put this another way. I want a way to better visualize (browse? search? explore?) pre-existing (and eventually new) relationships between types of components.

[droqen]

Still interested in this... maybe there's a way this relates to the "question-asking" game? It seems a little spatial, though, and non-narrative. See Damian's tower game. DORMANT