2012/08/09

line width for rendering

I just submitted version 1.1.1 (update: has been approved) which lets you set the width of the rendered line in the inspector. Here is an example, obviously it's over the top, but you can set the width to anything you like.

Now I just need to provide a nice function to pass rendering points to Vectrosity. I'm sure those of you who own a Vectrosity license would like to be able to combine the best of both. I promise when I'm done it will be the last time you'll see me talk about rendering for a while.

2012/08/08

Version 1.1.0 out now - rendering included

Unity just approved version 1.1.0, which includes the new inspector panel and the rendering setup. Now you can see your grid in the finished game, no pro license or any other addon needed.

2012/08/07

a new inspector

Well, I wanted to do this sooner or later anyway, so I made a custom editor for the rectangluar grid. Before this I was using the default inspector panel:
So, why am I doing GUI stuff if I'm supposed to work on the rendering? Well, as I said I need to clean up the code, which involves looping through two custom classes of mine, ColorVector3 and BoolVector3. If you used Vector3 you know you can access values using something like myVector.x, but you can also use an index instead: myVector[0]
I wanted to have both in my two classes so I could loop through them in one go rather than write a special case for each entry and provide an intuitive syntax for users. The solution was using an indexer, setters and getters. They all work fine in code, but I cannot get getters and setter to display in the inspector and manipulating the entries directly could break things. The solution was writing my own inspector from scratch.
Aside from now being able to provide a safe and clean way to set colors and toggle axes the new inspector looks cleaner and the attributes are sorted in a way that makes more sense, rather than the way the class is built. I'm still not satisfied with some parts, the axis colours don't have labels and the the hide axis flags should be on the same line, like the Vector3 field. However, if I force them on one line or add labels to the coulour flieds the space for the labels is so large that the controls start overlapping, so it looks even worse than before.

Anyway, it does look better now and gives me the code improvements I need for clean rendering, so all in all it's a success.

2012/08/06

grid rendering progress

Take a look at this:
What's so special? Look at the upper right corner, gizmos are turned off. This is a grid rendered at runtime that would be visible in a released game. There are still some things to care take of first: For one, the grid needs to get rendered every frame, which is not a big deal when using the GL class, but a Vectrosity-like approach where a mesh is built only once and then drawn once until it updates would be pretty neat. Also, the GL class doesn't let you set the width of lines, I could draw quads instead, but those are only thick if you look directly at them, otherwise they get thinner until they become invisble (in other words, they are flat). Lines are always the same, no matter the angle or distance, which could be exactly what you want or not. Maybe I could include some way for users to use Vectrosity easily if they have a license? In any case, I need to finish this first. The code is still very messy, being in large parts copy-pasted from the drawing code (which was kind of messy itself) and copy-pasting code is a sure way to have your project explode right in your face. I'll need to write a method to return a nice list of points that both drawing and rendering can use.

2012/08/04

version 1.0.1

If you tried debugging the functions FindNearestFace() or FindNearestBox() you might have noticed that the cubes drawn didn't have the same rotation as the grid. While it didn't change anything about the returned value (only the centre of the cube mattered), it looked ugly. I've submitted a small update that fixes the rotation:
The update should get approved soon.

2012/08/03

grid-based game logic

Another video tutorial, howing how to use grid-based game logic in a puzzle game. This is the tutorial for the lights-out game I mentioned before and which has been included with the package.
This tutorial is written in C# because it uses delegates and events. The reason why is so that no single tile needs to know about the other tiles, making this code extremely flexible, you culd even change your scene during runtime. If you don't know about delegates and events I really recommend you to check out prime31studios' video. Their video series really got me into C# development.
To give you the basic idea, events and delegates mean that somewhere somehow something happens and some other objects react to that. The object that triggered the event itself has no idea who (if anyone) is listening and how they will resond. For example you could have an RPG where when you draw your sword it makes villagers run away and guards draw their own weapons. Your hero would not need to know how many villagers and guards (if any) are around, he just needs to fire the event and all listeners will react accordingly.

2012/08/01

Release!

Grid Framework has been approved and is fom now available on the Unity Asset Store for 15$
This is the price for the initial release, it will go up as the amount of features increases, but all existing customers will get all updates for free. Please feel free to visit the support thread and drop me a line if you have any questions or suggestions. Once the first wave of purchases has passed and if there are no issues I will start working on either hex grids or grid rendering, whichever you guys might find more important.
http://forum.unity3d.com/threads/144886-Grid-Framework-scripting-and-editor-plugins

And to think that is has already been four months since I started this blog... the framework has gone quite a long way from a quick&dirty solution I rolled up in two days to something I can proudly announce. I am looking forward to an even brighter future for Grid Framework.