Goodbye MonoDevelop, hello Vim

One thing that has been getting on my nerves ever since I started working with Unity has been MonoDevelop. While it is a good IDE for the most part it suffered from a number of annoying issues, such as folds randomly opening, poor performance, and auto completion randomly not working. Your mileage may vary, and for the most parts it was doing its job, but the annoying hiccups kept happening all the time.

I tried out the official Xamarin Studio, but that one didn't fare better and on top of that always threw up error messages when opening a file. I was looking into alternate editors, but they didn't offer the rich C#-focused feature set of MonoDevelop, so I was stuck with it.

Eventually I was so fed up, I decided to go all the way back: no fancy IDEs, no GUIs, back to to bare basics: Vim. The cool thing about Vim is that's it's a very simple barebones editor that can be extended and customised to your liking. Vanilla Vim is nice, but you have not really used Vim until you have tailored every aspect to your personal liking. That's a gradual process that will take years of experience, but I do already feel very comfortable outside of the hand-holding restrictions of the IDE.

For an ideal Unity setup you will want a GUI client of Vim, such as MacVim. That doesn't mean that Vim will get all those fancy buttons and menus, although you can enable those if you want to, but the main advantage is that it can be launched like any other application instead of through the terminal. MacVim has also better mouse support (it's faster to resize windows with the mouse) and the character cursor looks different in insert mode.

The next thing you want is support for .Net and C# features. The plugin for that is Omnisharp:

https://github.com/OmniSharp/omnisharp-vim

Omnisharp will add pretty much all features that you have come to love from MonoDevelop, without the headache. Omnisharp also provides an interface for other plugins, for example you can use it with YouCompleteMe to get automatic code-completion:

https://github.com/Valloric/YouCompleteMe

There is a ton of other useful plugins out there as well and some are listed on Omnisharp's page. Another advantage of Vim is that it's not restricted to one particular language or framework. You can easily write your essay or design your HTML web page in it. Customisations can be set for each file type differently or you can use them over multiple types. Since it's all one editor you don't have to learn a new IDE for every project.

In fact, I have been designing my new upcoming website in Vim as well, the same editor I use for writing Grid Framework. How cool is that? Here is a video I found on YouTube of someone using Vim to edit text with the speed of though:

Grid Framework version 1.7.0 released

Version 1.7.0 of Grid Framework has just been approved by the Asset Store team. This release brings some more love for hexagonal grids in the form of two new coordinate systems and four new rendering shapes.

The new coordinate systems are the downwards herringbone coordinate system where every second column is shifted down- instead of upwards and the downwards rhombic coordinate system where each successive column is shifted one hex down- instead of upwards.

Two of the new rendering shapes are downwards rectangle and downwards rhombus to go with the new coordinate systems. The two completely new rendering shapes are the up- and downwards herringbone grids. Unlike the other shapes these ones are continuous and expand smoothly.

Notice how the grid on the left-had side shifts ever odd column upwards and the grid on the right-had side shifts ever odd column downwards.

Here is the full change log:

• New: Downwards herringbone coordinate system for hex grids
• New: Downwards rectangle rendering shape to accompany the new coordinate system.
• New: Downwards rhombic coordinate system.
• New: Downwards rhombic rendering shape to accompany the new coordinate system.
• New: Up- and downwards herringbone rendering shape.
• Fixed: The grid align panel now correctly respect or ignores rotation when aligning.

Grid Framework version 1.5.3 released

Grid Framework version 1.5.3 has been approved by the Asset Store team. This release brings compatibility with the upcoming Unity 5.

Grid Framework itself was compatible, but a number of examples used properties that have been removed in Unity 5. Those are properties that secretly called GetComponent, but looked like regular variables.

And while I'm at it, here is a little teaser for the next feature update: rhombic hex grid rendering

Grid Framework version 1.5.2 released

Grid Framework version 1.5.2 has just been approved of by the Asset Store team. This release is a bugfix for polar grids where the cylindric lines have not been calculated properly if the depth of the grid was not 1.

Another thing you might notice is that the engine requirements have been knocked down to Unity version 3.5.7, the latest release of Unity 3. While Grid Framework has always been compatible with Unity 3, I have been using Unity 4 for deployment so far. Now the compatibility with Unity 3 is official.

Compatibility with Unity 5 is coming with the next update; it's nothing major, but some of the examples did not compile due to deprecated properties.

Grid Framework version 1.5.1 released

This release is a hotfix for everyone who was using Playmaker

• Fixed: Compilation errors when toggling on Playmaker actions.

Playmaker actions wil compile correctly now, anyone else was unaffected. So what happened? One of the problems when developing an extension that relies on another extension is that it will not compile if the dependency is not present. For Vectrosity is was easy, I just needed to assemble and array and the user would then send it over to Vectrosity. Or not, you could do something entirely different with it as well if you wanted, it's just an array of Vector3.

Playmaker is different though, the actions are classes derived from Playmaker classes, so if you don't own Playmaker the code will not compile. My solution was to do the following:

//#define PLAYMAKER_PRESENT
#ifdef PLAYMAKER_PRESENT
// code goes here
#endif //PLAYMAKER_PRESENT

This means the code will only compile if the keyword PLAYMAKER_PRESENT is defined, which it isn't since the first line is commented. To make the scripts compile you have to toggle them on through a menu item which then edits the scripts to un-comment or comment that line. Before I submit a new release I have to toggle the actions off and so I missed the compilation errors.

It's still a bad oversight on my side and I'm not trying to excuse my failure, but I wanted to share how this can happen. A better solution would be if plugins could define keywords globally, then Playmaker could announce its existence on its own instead of having to toggle things manually.

Grid Framework version 1.5.0 released

Grid Framework version 1.5.0 has been approved by the Asset Store team. This version brings a great new feature for anyone interested in making isometric 2D games: shearing. Shearing allows you to slant a rectangular grid's axes without having to rotate the grid. Up until now the only way to achieve the isometric look was to rotate the grid or the camera in 3D space, but in 2D games the camera has to be perpendicular to the image plane and thus the grid as well. Now all you need to do is just set the shearing of the axes and you're good to go, everything else stays the way it was.

The shearing is stored in a new type called Vector6 that works very much like Unity's own Vector3. The Vector6 class resides in the new GridFramework.Vectors name space to prevent name collision with other custom types or a possible future official Vector6 type from Unity.

the GFBoolVector3 and GFColorVector3 classes have also been moved to that namespace and had their "GF" prefix stripped away. If you used them in your own scripts strip away the prefix and place a using directive at the start of your script, otherwise you have to do nothing.

Here is the full change log:

Introducing shearing for rectangular grids.

• New: Rectangular grids can now store a `shearing` field to distort them.
• New: Custom `Vector6` class for storing the shearing.
• API change: The odd herringbone coordinate system has been renamed to upwards herringbone. The corresponding methods use the `HerringU` pre- or suffix instead of `HerringOdd`; the old methods still work but are marked as depracated.
• API change: The enumeration `GFAngleMode` has been renamed `AngleMode` and moved into the `GridFramework` namespace.
• API change: The enumeration `GridPlane` has been moved into the `GridFramework` namespace. It is no longer part of the `GFGrid` class.
• API change: The class `GFColorVector3` has been renamed `ColorVector3` and moved into the `GridFramework.Vectors` namespace.
• API change: The class `GFBoolVector3` has been renamed `BoolVector3` and moved into the `GridFramework.Vectors` namespace.
• Enhanced: Vectrosity methods without parameters can now pick betweem size and custom range automatically.
• Fixed: Vectrosity methods were broken in previous version.
• Updated the documentation.

Whitelisting subdirectories in Git

After having migrated the development of Grid Framework to Git I wanted to set it up to track only certain sub-directories. I turned out that whitelisting is quite tricky, so here is how I did it for people who might run into the same problem.

We'll use only one .gitignore file and it will be placed in the root of our repository, which is also the root of our project. We can do the usual blacklisting stuff like blacklisting ceretain file types and directories, but the Assets directory is where it gets tricky. Since the directory contains all sorts of other plugins used during development but not worth tracking, we can neither black- nor whitelist the entire directory.

First we'll blacklist all the contents of the Assets directory. Note that this does not blacklist the directory itself, just its contents, but since Git operates on files the effect is the same. The difference is that blacklisting an entire directory prevents us from ever whitelisting any of its contents.

Assets/*

Now we can whitelist a subdirectory and its meta file:

!Assets/Grid\ Framework/
!Assets/Grid\ Framework.meta

Simple enough, but what if we want to whitelist only a specific subdirectory of a subdirectory? The Editor directory contains code from other plugins as well, so we don't want to track the entire thing. In this case we need to repeat the same process as above but one level deeper.

!Assets/Editor/
!Assets/Editor.meta

Assets/Editor/*

!Assets/Editor/Grid\ Framework/
!Assets/Editor/Grid\ Framework.meta

First we whitelist the Editor directory, then we immediately blacklist its contents and whitelist a specific subdirectory. This way none of the other editor extensions will be tracked. We can repeat the same process for the Plugins directory.

!Assets/Plugins/
!Assets/Plugins.meta

Assets/Plugins/*

!Assets/Plugins/Grid\ Framework/
!Assets/Plugins/Grid\ Framework.meta

And yes, you do have to repeat all these steps for every level of subdirectories. You don't have to whitelist subdirectories of already whitelisted directories, so any subdirectory in "Assets/Editor/Grid\ Framework/" is already tracked. Also note the backslash in the path, it is necessay to escape the space character.

UPDATE: Whitelisted the Unity meta files of whitelisted folders as well, just in case. Of course if you are not using Unity you need to figure out if and what meta files you have instead and if they need to be tracked as well.