I've been working on the next type of grid: polar grids. The polar grid is based on polar coordinates, meaning instead of identifying a point's position using X and Y coordinates we use a radius and an angle. The radius tells us how far from the origin the point is and the angle tells us the direction. This screenshot shows the new polar grid in Unity
Version 1.2.4 has been approved by the Asset Store team. Here are the new features:
I've been dealing with performance in Grid Framework recently and added a feature that will keep the Garbage Collector from going crazy. Until now rendering always went like this: Manager requests rendering from grid -> grid calculates the end points of each line -> these points get passed to Unity's GL class for rendering. Every single frame. I have introduced a caching feature that will store all the calculated points and reuse them instead of calculating everything all over again as long as the grid has not been modified.
This update brings you two new features, both were suggested by customers. The first one is the ability to set a separate set of colours for rendering instead of using the same colours as for drawing. Let's say you want a barely visible grid in the game but a clearly visible grid in the editor. Until now you either had had to have two grids or use a script to change the colours once the game starts. Both options worked fine but required more work than needed, now you can do it out of the box. Of course it is entirely optional, so if you don't set anything you will be using the same colours for rendering and drawing.
As mentioned in the previous post I'd like to relate my experience with using properties in Unity and how to make them work properly. Properties are a C# feature and not available in UnityScript (another reason to ditch UnityScript). To help demonstrate what I mean I will be using a "circle" class.
Update time. Let's go over what's new:
A happy new year to everyone! This has been quite a year for me, so what better opportunity to recap the birth process and evolution of Grid and set the plans for this year?
Let's say you just bought Grid Framework, wrote some game logic and now you want to reuse it. Wouldn't it be great if it was a class method in Grid Framework so you could simply call it with one line of code? Even better, what if you could have one method that has the same syntax for both rectangular and hexagonal grids but different implementation based on the type of grid, so you would have to write just one script for any type of grid? Luckily this is no problem in Unity thanks to extension methods and if you have the code, then wrapping it up into an extension method can de done in a few minutes. Take a look at my latest video tutorial:
I made a short video giving you an overview of hex grids, so you can see them right in action. I'll make a video on how to extend Grid Framework with your own methods yourself next,
The wait is over, version 1.2.0 is out, bringing you the long promised hex grids. I'll soon make a video demonstrating the new grid, in the meantime let me explain it in words. My implementation brings you all the features you knew from rectangular grids, except on a hex grid, and both grids inherit from the same base class. This means the API for both is the same and you can write one script for both grids with little to no need to make special adjustments for different grid classes. Currently there is only one coordinate system and hex grids have "only" as much functionality as rectangular grids. I wish to improve upon this in the future.