Sunday, April 13, 2014
Didn't manage to get as much work as I would have liked knocked out today, mainly because I got a bit tripped up on this one concept that's giving me some implementation woes...
Adaptive Packed Grid Layout
Here's something very interesting What if we took the grid nodal UI layout and removed the constraint that grid cells all be the same size? What if, for example, we had a fleet interface where we wanted to convey the fact that we have some really big ships and a bunch of small fighters? If we were to view that fleet in an orderly way, wouldn't it make sense to let the big ship nodes take up more space? Of course But how?
Well, what if we tried to automatically pack variable-sized nodes into a grid in an aesthetically-pleasing way? Seems like it could be pretty cool...
Anyway. Turns out it's not that easy of a problem, and it's taken me several hours just to build a half-working implementation. Hrm. Not cool! Maybe just another hour or two This is my first time implementing bin-packing algorithms, so it's understandable that I would get slightly hung-up. Still....
The nice thing about this problem is that it's also directly related to the hardest remaining step that I have in finishing off platemesh texturing. So...solving this will solve both a nice UI problem as well as the platemesh texturing problem!
Nothing like a 2-for-1 special
'Tag-Based' Resource Generalization
Luckily, I did still get some nice theory done today, despite my implementation woes Previously I've spoken about how the engine now supports hierarchical items ('Ore -> Viritium -> Condensed Viritium', etc.) As I am starting to understand how factions will reason about zone control, I am having trouble sticking with this strictly-tree-based model.
For example, suppose that zone control is expressed by having a 'deed' to a given zone (the means by which one acquires this deed are up for debate, but let's just say that there exists some concrete manifestation of your control). Suppose, in fact, that I have a 'deed to Silverton Asteroid Field' in the Colorado System. If we start trying to think about how that deed might be understood by an NPC, we immediately run into the same issue that deep-hierarchy-based game engines run into: how do we structure the tree? Should 'deed to Silverton Asteroid Field' derive from 'deed to Asteroid Field in Colorado System,' which derives from 'deed to Asteroid Field'? But what about 'deed in Colorado System'? Do you see the problem? It's the same reason why we prefer composition over inheritance in programming. In reality, my deed is a 'deed to asteroid field,' it's also a 'deed in Colorado System,' and each of those parent types have their own parents.
The point here is that some things cannot be easily understood as a single-inheritance hierarchy. It is perfectly reasonable to believe that some NPCs would have a desire to control any zones in the Colorado system. It is also reasonable to believe that some NPCs would desire to control any asteroid fields. There is no inherent relationship between those two types of zones, and yet, my deed should be able to fulfill either of them in the marketplace!
For this reason, I'm moving to a 'tag-based' mechanism for generalizing resources. It's really just the same thing that we already had - resources can derive from other resources - except that it allows multiple relationships. For some reason, though, it seems to make more sense in my head when I think about these generalized things as 'tags' rather than 'parents.'
This is going to be very important in the near future when we see zone ownership finally happening....soon.........very soon.....
Post
Mon Apr 14, 2014 3:07 pm
#1
Week of April 13, 2014
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford