Unity day 11: Terrain overview and Scripting

Sep-30-08, 7:50 pm by Hanford
File under: Video games, consoles, Unity, tech

NOTE: If you've not seen my posts on testing out Unity, check them out here. It's been a lot more than 11 days since I started my Unity test, but most of those days I didn't get a chance to play around with it.

Executive Summary

Here's my executive summary of my most recent Unity exploits.

Terrain: I've messed with the Terrain engine a bit and found it pretty easy to use. Feature-wise it's a bit on the simple side; but overall I cannot imagine trying to build a game world solely in a 3D modeling tool, and this is much simpler and more interactive. It seems to feel a lot like the terrain in Oblivion (which is a good thing!).

Scripting: I also took a stab at scripting. So far I've been able to write my own 3rd person camera system (total time: one evening), a Diablo-style point-and-click character controller (total time: another one evening), and try my hand with Unity's coroutines.

I found scripting to be pretty straightforward and it was easy to do just about everything I tried. The point-and-click character controller had me a bit daunted at first, but I was able to get it working in a single evening. The scripting reference came in pretty handy.

Coming from Director, coroutines are definitely the most exciting aspect of Unity scripting. It seems to simply all the problems of execute-over-time scripting without having to do complex case statements. I'll try to explain more about this in a later blog post if anyone is interested.

More on terrain

After reading up on the terrain engine in Unity I got pretty excited, since it appears to handle large maps and vegetation built right in. In an evening I was able to create a height map in Photoshop based on a scan of an island I designed in a previous game, and import it into the editor. It took me several attempts to get it right, which is to be expected, since heightmaps are always trial-and-error process. a few things I learned: use 16bit-per-channel images for heightmaps, and blur the hell out of them, otherwise you'll get major jaggies in your import and (on my wimpy G4) the terrain will grind to a halt. This makes me wonder how graceful it would scale -- the world seems to render quite nicely when it's all smooth hills but after adding ridges and rough edges Unity appears to not LOD them as aggressively when they're far away, which is why initial heightmap tests choked the framerate. Is it possible to make the terrain too detailed? From my initial tests I feel that it's something that I could work around. I took a new approach. My strategy was to use the heightmap as a rough guide and fill in the details with Unity's built in terrain editor. This seemed to work pretty well.

Unity's terrain engine is impressive and automates a lot for you. It has built in tools for modifying land height, adding trees and grass, and texturing the terrain; not to mention rendering them with LODs, billboards, and clipping automatically. In some other engines, you'd need to write all this yourself, but you get it all for free in Unity. Of course that's a double edged sword: the terrain editing tools, while acceptable, are pretty basic. For example, it's very tricky to use the tools to build controlled sloped paths. I keep bouncing between pits and bumps when trying to create slopes. In one evening I felt like I had gotten a lot better at it though, and started to find some tricks for building terrain conducive to gameplay.

Current wishes

While overall I am quite excited about Unity's performance in my tests, I do have my own set of wishes, which currently are:

More examples in the scripting reference: There's still some things I'm trying to wrap my head around conceptually, and often times I use examples to help with that, but the Unity scripting reference is missing examples in some areas. I was able to find Scroll Wheel support in the documentation, but can't actually figure out how to use it yet. There's no example, and I'm still learning the ropes of Unity, and I was not able to get the syntax correct.

Script editor: The Unitron script editor that comes with Unity doesn't work on my old PPC PC (but they're aware of it) so I don't get any color-coding, etc. On top of that, I'm not 100% sure there's a way to do step-by-step debugging. I really have come to rely on having IDEs with built in editors that are "aware" of your project.

Capitalization: This is less of an issue with Unity as it is an issue with Javascript, but I really am frustrated with having case sensitive parsing, and the capitalization standards functions and classes use. I'm going to bitch about it because it causes a lot of stupid errors. It's easy to remember names, but tricky to remember when they're capitalized and when they're not. "camera" isn't. "ScreenPointToRay" is. But here's the thing that irks me the most: it would be considered bad design to have an object named "Max" that did one thing, and an object named "max" that did something different, so why allow it? What I'd love to see is a script editor that automatically capitalizes, so I don't have to.

Overall Game Techniques: I'm also interested in seeing high-level descriptions of how to do common game-related scripting architecture. I'm not looking for pre-written code; just concepts. I am sure some of this may be covered on the Unity site, but I've not found them yet. Topics I've love to see addressed:

Save Game/Load game: a quick writeup on how to crawl the hierarchy and save off gamedata for instantiation later. Techniques for making this scalable so that you're not going back and changing the savegame code every time you change properties of the world.
Building large worlds: the terrain engine has built in support for clipping trees and grass, but what about all the other objects you want to stick in your world? Can you just add objects to your world without worrying about it? or are there tricks that need to be used?
Writing core functions: I want to write some functions that can be called from any script. How do I do that?

More to come soon ...

4 Comments | Retweet this

Feedback - 4 responses

Displayed newest to oldest. Leave a comment.

Troy wrote: Oct-22-09, 9:45 pm

In my programming experience, while it isn't consistent in javascript (mostly because it isn't enforced), Classes, Getters and Setters, and Methods begin with a capital. Instances, variables, and fields begin with a lower case. Further, some folks also like to differentiate local variables from class variables by adding '_' to the name or 'm_' (which stands for 'method' variable).

So, if you know these rules, it becomes powerful when reading and writing code, rather than frustrating by trying to 'memorize' what may otherwise appear random.

Dave Mennenoh wrote: Jan-13-09, 5:54 am

One more thing - regarding static methods... ugly. They work, but really static classes are simply a namespace for some related functions and are not OO. I prefer using a singleton every time. You might do a bit of reading on static vs singleton.

Dave Mennenoh wrote: Jan-13-09, 5:49 am

Just wanted to weigh in on the capitalization thing. It's pretty much a standard for the first letter of a class name to be a capital, and the first letter of a function/method to not be a capital - and they both use camel case. Constants are all caps...
Tom's example then is improper, it should be:
static function myFunction() {}

Tom Higgins wrote: Oct-17-08, 5:14 am

I think that a description of how to save game state data is a bit long for inclusion here but it's most definitely within reach. As to dynamic additin of models to your scene you can do that in a few ways, either build them during authoring then export as AssetBundles which are then loaded on the fly via the WWW class, or build it all at run-time using code (where you place the various objects using scripting). The "tricks" required are mostly to ensure that you place them at the right overall location (and at the right y-height to be above the terrain) and of course with a proper orientation. As to your last one, core functions, you can define your own static functions that are then available everywhere. For example, make a JavaScript file, name it HanfordsFunctions, then in that file define a static function that does something of interest:

static function MyFunction (aVariable) {
// do some work here
}

Then you can call that from anywhere using HanfordsFunctions.MyFunction(...). Drop me an email and we can go over in more detail. Keep having fun and let's talk soon!

Comments are displayed on posts and visible to all site visitors.