Yes, it’s a hard bridge to gap, but I’ve had extensive experience in Lua, and Ruby, and frankly, hooks and metatable objects made me start thinking in a more dynamic way, so maybe it’s a bit more simple for me.
Set up better? In some ways. In other ways, Unity is better set up to handle scripted behaviors. It’s really an argument of convenience than functionality, though.
Really though, try to avoid doing something because it’s just easier… In some cases, you will be much better served with scripted behavior, and in some situations, you’ll be much better served by derivative heirarchy…
For instance, I recommend making a monster, item, etc. class, and for level-design type scripts, such as scenes, one-use triggers, etc. I recommend using behaviors.
It makes perfect sense when you think about it. System.Object doesn’t have transform built into their archetype, simply because System.Object isn’t meant to be put in the scene.
GameObject is the lowest-category of class that can go into a scene, and thus, is the first object that needs to be defined as a “spacial” object. As such, GameObjects by default, need to be able to locate themselves within a spacial environment, and therefore, need to have a transform member.
In UNITYSCRIPT, (Javascript doesn’t do this by default!), you can subclass from an object using the extends keyword.
class Derp extends GameObject
{
var stuff : int
function DerpDerp()
{
}
}
vs. the standard C# variant:
public class Derp : GameObject
{
public int stuff;
public void DerpDerp()
{
}
}
I think you are looking at this quite backwards. In the case of procedural generation, you are going to actually WANT to use an Object Oriented heirarchy.
At the risk of sounding too rude, it doesn’t sound like you’ve really worked in C++ before. It sounds like you’ve been taught C via a C++ IDE. Frankly, it’s a common thing. Most programming instructors, and the authors of many programming books have made the transformation from FORTRAN, COBOL, Basic, C, etc. and seem to be unable to make the gap to the Object Oriented generation.
Most of my professors in college were like this, they thought they understood object oriented design, but they did not. Frankly, most self-taught programmers these days are far better off than those that the colleges pump out these days, because the old generation of programmers just can’t grasp the new concepts.
http://www.thetruetribe.com/2010/01/understanding-pointers-in-javascript/
An interesting note, is that you can pass functions as pointers, and invoke them easily. It’s a little more elegant than the tried-and-true C/C++/C# /* method… Though this can be quite invonvenient, because like Java, it’s hard to define exactly which variables become pointers, and which variables become unique values…
Indeed. Conversion between unityscript and C# is REALLY simple.
There are only a few places where things get all flubbed up:
@ - Any code following this will become enclosed by [ ] brackets. Any types within the brackets need to be declared as typeof(type)
function stuff() : type - needs to be changed to public/private/protected type stuff().
class sub extends par - needs to be changed to public/private/protected class sub : par
var derp : type - needs to be changed to: type derp
Also, remember that unityscript supports polymorphism, while C# does not support polymorphism, so you need to typecast ((ntype)variable) manually.
Unity makes C# development lightning fast compared to developing an engine from scratch, in my opinion. It takes all the drudge work out, and lets you jump straight to the fun stuff.
Oh, and a quick point… I gave you some bad information (I’ve only been using Unity for about two weeks now, so I’m still learning too!) but there is a way to locate a second script in the same object, if you add multiples. Since you are actually deriving from the MonoBehavior Class by default in UnityScript, you can use the Filename (in this case, the class name), you can use the name of the class to locate the component:
GameObject.GetComponent(ScriptType)
I hope this helps. I still, however, want to point out, that if you have two scripts that are actually keeping hard references to each other, you might want to reconsider your design, because in most cases, an event-oriented framework will serve you better… However, there are cases where this can be very useful. Also, avoid doing GetComponent calls every frame. You want to grab and store the reference in a member during Start() if possible, or inform the script to grab a reference when it’s been added to the GameObject.