If there is already a post that covers this then please just re-link me and call me lazy/stupid.
Im moving from working mainly in C++(OpenGl/DX) to Unity for a few porjects. I am loving the benefits of a runtime inspection system and the asset handling etc. However I have a few questions about structuring code.
Is it usual to treat GameObjects as you would a class object in C++ (Im assuming so)?
The translation for classes whichc
have screen output is easy to follow, for management classes I should just use an empty gameobject full of scripts?
I am used to mamaging my own object lists and updates from a few central ‘manager’ classes. Can I translate this approach to Unity (or does it go against the grain?)
Is it like actionscript etc, where a traditional programming approach will generate everything on the fly, instantiating objects with script etc. Or should I be using the IDE editor/heirarchy more?
If I have 2 scripts atached to an object, which one gets update first? (am i better leaving update empty and calling my own updates in a cascade?)
If you want to, you can also make them extending System.Object and act as singleton manager for example, completely independent of the world etc
depends on what you want to achieve with them and what they should offer functionality wise.
depends on the type of objects you list, cause all classes are already managed within unity itself so you potentially add overhead thats not required nor desired.
you will be using the editor a lot as many things are built around that.
Unlike Flash it also makes sense here, cause the editor is targeted at the task of creating games (unlike flash where the editor is targeted at the task of creating interactive movies)
there is no specific order. One of them will be first the other second.
You can’t rely on an order but normally that shouldn’t be a problem either as the idea of components is to seperate distinct functionality so they should either have no or only weak coupling.
2d arrays are nothing but a sugar, you can do the same with 1D arrays.
Also, with U3, UnityScript (there is no javascript and it finally isn’t called javascript anymore either) learned a few new tricks
Tom[/quote]
Unity has some neat advantages over other IDEs. The free edition allows you to add new functionality to the editor using editor scripting. The editor scripting itself, is code that functions ONLY in the editor. The entire editor interface is actually written using the same API you are using, so you can do anything that you see sitting before you, with another script.
You can also, in the paid version, write your own plugins (DLL/SO files), and extend the functionality from there. The benefit, in my eyes, is moot, when you have a hotspot compiler actually boiling your scripts down to platform-specific machine language.
There ARE a few disadvantages though, while I may still be learning the ins and outs of editor scripting, unity only handles a certain variety of objects in the asset dictionary.
Anything you insert into the editor has to be a shader, a texture, a model, a video, a sound, music, script, or a prefab (pre-fabricated entity).
Is it usual to treat GameObjects as you would a class object in C++ (Im assuming so)?
Unity carries a unique sort of overhead with it as well, due to how the engine handles objects, but this can be cut down by subclassing from out-of heirarchy objects for a lot of things that most people use GameObjects for.
Unity also allows the user to jack directly into the GL state instance, to do low-level calls from within the scripting language itself. I’ve never seen an IDE allow access to low-level functions directly like this.
This is where being a Java programmer would help you, and being a raw C++ programmer is going to hurt you. Class management is actually best done through events within unity. You can send events through multiple objects via event notification. Optionally, you can create management functionality through single-use, non-interactive GameObjects, OR, better yet, as static functions within the classes themselves.
Remember that a MonoBehavior is a component of a GameObject, and not the GameObject itself… I’d suggest looking into the object Heirarchy before you start writing a skeleton. It can save you a lot of work.
There are some preprocessor lines that unity handles within the engine as well, ([ ]) These are confusing at first, but they start to make sense once you figure out where you need to use them.
It really depends on what you are doing. Procedural content can be generated quite easily. All you have to do, is through a script, create a new GameObject(). You don’t even have to reference it in a variable, and the GameObject automatically attaches itself to the scene at 0,0,0. You can also build prefabs through a static method in the GameObject class.
For static content, you are going to be using the editor a lot. You can even define your own scripts in the editor! For instance, running a script within the Assets/Editor folder, you can add menu buttons, items, windows, inspectors, controls, guis, etc. This will allow you to add new objects to the scene automatically, modify mesh data on the fly, and include assets programmatically.
For dynamic content, you can easily generate content via scripts, and lightning fast. You can download content from the web, you can stream the content, you can download the content to the file system, and then load it from the local machine, you can literally do anything you can imagine.
It’s all in where you are launching the game, and what kind of game it is, that will determine what you are going to be using most of the time.
For instance, my current project required a kind of heightmap that could be applied to the polygons of any mesh, and could use subsurf meshes as the basis for a unidirectional heightmap. I also required heightmaps that could be extruded vertically, could be any size, etc.
I also needed a system that would take a vertex path, and extend it into walls, would use boolean operations to cut windows and doors, etc.
I actually wrote editor behavior for these two kinds of objects within the editor, and plan on using a MYSQL database to pull data to create these objects procedurally.
This was done in the free version, so don’t think I had to write an extensive plugin… It was literally less than five hundred lines of C# code.
use Debug.Log to find out. Generally, they should be added to the heap in the order you added them in, and should be called based upon their order in the hierarchy. If you have to worry about one running before the other, there’s a better way to do what you are doing, by the way.
Where possible use built-in behavior, but there are multiple types of Update(). There is Update(), which should be called 100 times per second, there is FixedUpdate(), which should be called once per frame, and there is LateUpdate(), which is called after everything has completed FixedUpdate(). Determine which behavior needs to go where.
2D arrays are worthless wastes of space.
2 dimensional list in one dimension:
from:
x = count%width;
y = (int)count/width;
to:
count = y*width+x;
3 dimensional:
from:
x = count%width;
y = ((int)count/width)%height;
z = (int)count/(width*height);
to:
count = z*(heightwidth)+ywidth+x;
4 dimensional:
from:
x = count%width;
y = (((int)count/width)%height)%depth;
z = ((int)count/(widthheight))%depth;
d = (int)count/(widthheight*depth);
second, I’d advise using C# if you are a C++ programmer. It’s more sensible than moving to Javascript. Polymorphism is nice, but for the sake of sensible object inheritance, and proper typecasting, I’d really advise keeping with C#. I’ve learned about 30 programming languages in my time, and frankly, C# is a pretty recent favourite. It’s got all the power and control of C++ that I loved, but without all the painful work that I didn’t. It’s like Java, but faster. =D
