Fixing what has been broken
A quick status update, all the examples and the align panel that had been broken by the API change are working now again. As I had mentioned when I outlined the plans for version 2.0, this update will break the API. A major version bump is an opportunity to throw out old cruft, decouple what does not belong together and streamline everything that can be made simpler.
Fixing the examples was a good opportunity to see just how broken the API has become. For the most part the update was straight-forward. Here are the general steps:
- Grid Framework now needs to be explicitly imported to every script by the
usingdirective in C# or
GFprefix needs to be dropped from every class name, there is no danger of name conflicts anymore now that Grid Framework is namespaced.
- Some methods such as aligning have been made into extension methods, so one has to import those as well.
- Anything rendering related has been moved to the renderer classes, so we need
a reference to the grid's renderer as well. In practice this means that the
renderToof the grid became
Toof the renderer.
- Cut out all cases that cannot happen anymore, such as non-relative units or different grid planes for layered grids.
These five steps will generally be enough to get most use-cases working again. There is one problem though: we have lost a lot of polymorphism, but That's not necessarily a bad thing.
Let me explain: when I originally wrote Grid Framework it was only supporting
rectangular grids, and even those did not have any shearing yet. Everything
else was just on paper and in my head. I had imagined grids to be more
polymorphic than they really are; what I mean by that is that there really
isn't much different grids have in common. Take for example the rendering
range: for a rectangular grid it makes perfect sense that one would have a
Vector3 for the lower and upper bound. The same goes for a herringbone shaped
hex grid. It would also make sense for a rectangular shaped hex grid, except
that the individual values would have to be integers instead of floating point
numbers. At least in that case we can kind of work around the issue by rounding
to integers, but where it makes absolutely no sense is for circular shapes like
the cone hex grids, or polar and spherical grids in general.
The same goes for coordinate conversion. I makes sense the have the grid coordinate system in a rectangular grid, but what is the grid coordinate system in a hex grid? In my case it was simply the coordinate system I had implemented first, but that doesn't mean it has somehow some inherent mathematical superiority.
Aligning and scaling objects made even less sense for non-rectangular grids. In
Transform of an object has a scale, which is a
representing the scale of a cuboid. How do you fit a cuboid into a hex gird? Or
even in a rectangular grid with shearing? You don't.
Putting such tasks into a general
Grid class makes no sense and no one will
use it from inside the grids that do j ust something for the sake of satisfying
the API. Even though we have lost some polymorphism, we have only lost it for
things that are useless anyway.
If you still think that you have the right solution for your specific problem domain you can easily add it to the grids as an extension method. I have done the same for the methods that have been removed from the grids as well.