JRavey and I (and anyone else who happens to be at the Starbucks in Rosslyn) will be holding the inaugural meeting of the Washington, DC Area Uniteers on Wednesday evening, July 19, 2011 at 7pm.
Starbucks
1501 N 17th Street
Arlington, VA 22209
JRavey and I (and anyone else who happens to be at the Starbucks in Rosslyn) will be holding the inaugural meeting of the Washington, DC Area Uniteers on Wednesday evening, July 19, 2011 at 7pm.
The team at Detox Studios announced their pricing for uScript today, via this Pricing FAQ on their website. The retail price of $195 appears fair, particularly given uScript’s capabilities when compared to other Unity visual scripting tools. The early adopter price of $95, available for the first month or so following release, seems very good. The team notes they are targeting a mid-August release.
I’ve been participating in the open beta of the uScript Visual Scripting Tool from the guys at Detox Studios. uScript’s interface will be familiar to users of Unreal Kistmet or VirTools, and is intended to offer similar visual scripting capabilities to teams using Unity.
I’ve been very impressed with uScript, so far. Like any beta, there are bugs and quirky bits. However, the team of developers has been very engaged in answering questions, acknowledging bugs, and incorporating feedback into the product. They have gotten a sizable number of interested users (440 forum users, as of this evening) and a core group of folks that are offering feedback, examples, finding bugs, and hunting for features.
I’ve been using the product alongside those others, and I’ve provided a couple of new nodes to perform certain functions, which were missing from the core beta release. None of these are rocket science, just things I needed to be able to do when building graphs with uScript. They’ve made it very easy to extend… so, I did so as a way to see how it was done and give others some of the missing bits I wanted, too.
Those nodes are listed in their Node forum are, and I am cross-posting here to make them easy to find:
During some work today, I needed to manage a queue of objects in a last-in first-out (LIFO) pattern. Unusually (for me, anyway) I also wanted to constrain the size of the queue to a maximum number of objects. The result is the FixedSizedQueue, shown below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | using System.Collections; using System.Collections.Generic; public class FixedSizedQueue<T> { // A regular ol' Queue public Queue<T> q = new Queue<T>(); // Size limit we're working with public int Limit { get; set; } // Adds the newest item to the queue, // drops the oldest public void Enqueue(T obj) { q.Enqueue(obj); while (q.Count > Limit) { q.Dequeue(); } } // Accesses the current number of objects // in the queue public int Count { get { return(q.Count); } } } |
Mercurial is my favorite DVCS because of the options available for branching/merging and its preservation of history (Hg prevents you from changing previous commits). It has a relatively simple command line tool, but it has been missing a powerful and intuitive GUI on OSX. Several options were available, but all seemed immature and brittle, despite the increasing popularity of DVCS among mac-based developers.
Enter SourceTree (£35/$60 in the Mac AppStore). SourceTree offers multi-repository support for Git and Mercurial repositories (and SVN) in a single tool. You can preview binary assets (images) and its integration of diff tools is easy to use and intuitive.
I just picked it up, and so far I really enjoy using it. I have not yet done any hardcore branch/merge activity, so I’ll plan to update this post with my feedback in the future. But, for now, we seem to have a winner!
Richard Fine posted a great article on Gamasutra about the power and flexibility offered by Unity, as well as the reasons it can be challenging for newcomers with a traditional development background. Read more in the article, Opinion: Six Misconceptions I Had About Unity.
Currently, we’re using Mercurial for version control, and leveraging hosting and other tools provided by Fog Creek Software’s Kiln platform.
I was doing some research on branching/merging, and came across this great blog post outlining best practices for version control. The article is system-agnostic, and provides some good techniques and examples of why they are valuable. Enjoy!
As part of my current project, I wanted to set up a very large game area, allowing the player to explore a large game world. For performance reasons — both at game time and during design time — its impractical to implement this as one large terrain object.
Fortunately, my favorite landscape generator, L3DT, has the ability to break large maps up into smaller maps (called mosaics). Each of the tiles can be exported individually, so I can import each tile into Unity as separate terrain object. This will allow me to readily implement terrain paging, by creating discreet “zones” that can be enabled and disabled via script. I can even work with each zone as an individual scene (e.g., one terrain and its associated detail objects), as long as I collapse them down to a single prefab that can be combined in the final scene.
One other note — terrain seams can be a bit of a pain, because of the way L3DT exports tiles, and how Unity imports RAW heightmaps. Eric at Starscene has created a tool, Stitchscape, that readily alters the individual terrains to easily stitch them together without seams. The price is quite low and it’s a huge time saver!
Today, I needed to implement ray-casting in a Unity scene. I had a bit of a problem getting the layer mask right, as my skills with bit shifting are mediocre, at best. So, I’ve decided to post an example.
Specifically, I wanted to get “mouseover” information whenever the user’s mouse floated over certain game objects in the scene, while ignoring other objects. Conveniently, i had already implemented numerous layers to hold these objects, so I just had to take those layers into account when performing my ray-casting.
First, I set up some values we’ll need:
1 2 3 4 5 6 | // Layers private var mouseoverIgnoreLayers : int = 0; // Mouseover Raycasting private var mouseoverHit : RaycastHit; private var mouseoverObject : GameObject; |
Next, in the Start() function, we’ll grab the layers we need to mask:
1 2 3 4 5 6 7 8 9 10 11 12 13 | function Start() { // Grab the layers we are looking for mouseoverIgnoreLayers = (1 << LayerMask.NameToLayer("L1")) | (1 << LayerMask.NameToLayer("L2")) | (1 << LayerMask.NameToLayer("L3")) | (1 << LayerMask.NameToLayer("L4")) | (1 << LayerMask.NameToLayer("L5")) | (1 << LayerMask.NameToLayer("L6")); // Invert the bitmask so we ignore these but enable the rest mouseoverIgnoreLayers = ~mouseoverIgnoreLayers; } |
Finally, we execute the ray-casting logic in Update():
1 2 3 4 5 6 7 8 9 10 11 12 13 | function Update() { // Get the ray from camera to mouse position var cameraRay : Ray = Camera.main.ScreenPointToRay (Input.mousePosition); // Test mouseover, ignoring movement layers if (Physics.Raycast (cameraRay, mouseoverHit, 500, mouseoverIgnoreLayers)) { // Mouseover info/effects for certain objects mouseoverObject = mouseoverHit.transform.root.gameObject; Debug.Log("Mouseover object: " + mouseoverObject.name); } } |