A few weeks ago Adam did the unthinkable, he released a new build of the game!, and boy it was awesome. Currently we are still in Alpha state, but that shouldn’t stop us from posting a few screenshots of our work in progress.
The screenshot above shows the game closer to our intended release version: It displays a working version of our trusty GUI, most of the buildings we’ll end up using (we are still missing a lot of buildings though) and features 18 out of the 23 planned units we have for the game. We still need to work a lot of the 3d assets, so it’s placeholder country for almost everything 3d.
We’ve been hard at work defining the look of the terrain and buildings for the game. The video below is a quick example of how all of the terrain is going to be destructible and you get a long look at the Tavern Landmarks for all of our current factions.
I finally got around to upload some work in progress videos.
First off is our grunt combat. These are a few of our finished sprites smashing each other to bits and just showing our combat engine off. I walk through our different stances that a unit can be placed into also. Youtube thought it would be a good idea to add some extra light to this video so it’s a little bright.
The second video shows off the special attacks of two of our Slayers. They are not finished sprites, but the special abilities are fully functional. We have some buffing abilities, a summoning ability, a charge attack, a ranged area of effect, an instant area of effect, and one that adds special damage to the slayers weapon.
Hey everyone, Petunio here for another Art Update on Cairn.
So one thing is the units we are making for the game, another is the tiling that will go under the units. Originally we were working with another artist on the tiles, and for the most part his tiling skills were pretty good, but the contrast between what he did and the units in the game was a bit lacking, partially because he was working the terrain tiles without knowing how the units would look like.
I offered to do the tiles since I thought I could do a much better worklooking for the right contrast between units and terrain since they would both be developed by the same person (The Petunio, that is).
In one of our most recent builds we found that collisions detection wasn’t working. For those that don’t know, collision detection is exactly what it sounds like. It is code that recognizes when two objects hit each other.
In Cairn we instantiate special effects & projectiles that use colliders to detect whether it has hit a unit. If it hits the unit it does damage, grants a buff, or assigns a penalty. The problem was that even though units were being hit, the collision detection wasn’t triggering. I recorded a video of the issue while to help a few programmers who were helping to fix it better understand the issue.
Past the break I’ve got some the cause and solution to the problem. Hopefully all my headache will help someone solve the issue more quickly in the future.
Unity3D is a great tool and I’ve been very fortunate to have such a great product to build this game on. Everyone knows that the Unity GUI tools are a little frustrating to work with though. One of the issues is the GUI’s size. The next is making sure it works with all aspect ratios. Since unity allows us to release to PC, Mac, iOS, and android it’s pretty obvious how this can get annoying quickly. So to help others, here is how I solved these issues.
Creating the GUI
When starting off the best way to design the anything with Unity GUI is to hard code the values at whatever resolution you are currently working in. Keep it consistent and you will have perfectly usable interface in no time. Here are some helpful links for the Unity GUI:
Scaling the GUI with screen height & width
The easiest way to scale your GUI with different sized screens is to use Unity’s GUI Matrix. This matrix allows you to hard code the size of your GUI, and will automatically stretch or shrink your GUI to match the users actual resolution.
//set up scaling
//The native_width & height are the resolutions you have hard coded
float resX = Screen.width / native_width;
float resY = Screen.height / native_height;
GUI.matrix = Matrix4x4.TRS (Vector3(0, 0, 0), Quaternion.identity, Vector3 (rx, ry, 1));
This works great, but if the aspect ratio changes then your GUI will be stretched to match it.
Scaling the GUI with Aspect Ratios To get around this limitation we have to take a more manual approach. We scale the GUI with the Height of the screen. By using the height to scale the interface you won’t be able to hard code any values, all of the hieghts and widths will be derived from a fraction of your screen.height.
We decided that our interface should take up about 1/5 of the screen height so that has become our unit of measurement. So you’ll want to declare a variable with this size in it, we’ll call this variable guiBaseUnit.
Our minimap on the left side of the screen is square, so it’s height and width are both set to guiBaseUnit.
Our control panel features all of our controls, so it’s a larger rectangle that uses a lot of screen space. So it’s height is guiBaseUnit, but it’s width is guiBaseUnit * 2.5.
This is probably not the cleanest way to create the GUI, but it does create a better user experience and creates a reusable interface system.