Delegate Notes 1: Instantiation of non-lambda delegates

This entry is primarily a note for myself, but it might come in useful for others if they stumble across it.

When creating a delegate, you use something similar to the following code:


1: Delegates are declared with the same method signature as the function they’re referring to.
2: Delegates act as types. The delegate name that you assign is the “Type” of the delegate.

(In this example, the “Type” is “dello”)

A delegate is NOT a class or method or instance.

To use the delegate, you must:

A: Declare the delegate using the keyword “delegate”.

Remember – use the same method signature as the function to which you are pointing.

In this case we are pointing to a function with the signature “void hello()”.

Since we are calling our delegate/type “dello” we use that for the name.

B: Create an delegate instance by using the delegate name as the type of the delegate.

C: Assign the function via the ‘=’ operator to the delegate instance (not the type).

The following will NOT work (here you are using the name of the delegate type, not the instance of the delegate):

D: Do NOT use the parens after the function name of the function you are pointing to.  The following will NOT work.

E: The form of assignment using the equals operator is syntactic sugar for the following, as of version 4.x of C#, previous versions you have to use the style listed below.


Scriptable Objects & Discipline

I have been very hesitant to attempt working with the Scriptable Object.  I’m not sure why.  I think it’s fear of losing this new slate to something completely different than I’m used to.  Thing is – it’s a whole different level of complexity – because you’re adding features to alter the Unity editor itself, not just code for your game.  It adds one more thing as part of your hierarchy to deal with.  Do I need it for a game as simple as Automute?  It seems unnecessary, especially if I do a ground up rewrite to resolve the issues I was having with setting the vehicle’s speed).

At first I thought “fuck it – I don’t really need to learn Scriptable Object – especially for what I’m doing”, but I know that’s a bad attitude to have.  Especially, if I eventually *do* want to move on to larger projects or work with others.

Programmers shouldn’t be afraid of trying new things.

So what I think I’m going to do is two fold:

1) Continue Automute using the old tried and true methods, and just fix what  I screwed up before (and in the process a refactoring of things)

2) Tutorials for ScriptableObjects.  Go through a few tutorials I’ve seen, take notes (I usually don’t take notes, I just type in and switch between windows, but I think taking notes in a notebook and writing it down will help reinforce what I need to do and understand the process better and allow me to reframe things in my terms rather than the teacher’s terms.  Do these separately from Automute.  Create new projects and step through the steps to create whatever it is they’re creating (I’ve seen two somewhat decent ones: a light tutorial (official unity video tutorial), and a site that has you make a new game board with simple blocks (basically the same thing except instead of light objects you’re using colored cube objects).
This way I remove any worry about “messing up” Automute, I still move forward on Automute without the psychological delaying excuse of that worry, AND I learn about ScriptableObjects which I can either use in Automute if necessary or save it for my next game if needed.

Automute: C# Automatic Properties and Unity Component Caching


Two things I grokked tonight that should make my programming easier…

The first one should have been more understandable, and I think I did it right at one point when working with this whole Unity3D stuff , but then fell into a terrible habit with it.  That’s the Unity Component Caching that I mention in the title.

Basically Unity has a simple system that’s called “Component Based”.  That means it has built in “GameObjects” that are mostly empty.  It’s easy to work with because you can take something and drop a cube into a scene as a game object and BAM there it is.  But all it has, when it’s in the scene is a “Transform” which is basically it’s location, position and rotation (and probably a renderer component, IIRC).  Anyways, there’s no behavior or anything.

What you then do is create a script and drag that script onto the game object.

Since Unity is also Object Oriented, it means you’re accessing components of other objects to do things to/with.  If I have, say, a level manager system (to use an example from my game), and I have a bunch of Level objects, each with their own special data/configuration/values, and when I load a level, I need to know information about the level based upon the information in that level object, I need to call the information in the LevelManager using a special function of Unity’s called “GetComponent”.  Let’s say I want my LevelManager to SpawnVehicles.  Since this is true across all levels, I put the SpawnVehicle script into the LevelManager, not the Level, since I don’t want to duplicate the function for each level.  But I need that information from the level so I know how/when/were to spawn the vehicles.

What I was doing was declaring a gameobject and caching that object when I started the levelmanager, which is fine insofar as it goes.  However, this leads to a lot of redundancy, because I’m only caching the gameobject not the components of that object.

Here’s a quick example:

You’ll note that in lines 4-6 and 9 (highlighted) this little code ”

Over and over and over.  That’s a lot of “GetComponent” – and it also means it’s not caching properly.  The GameObject is cached which is helpful, but still not efficient enough.  I realized that I have to use, not “GameObject”, but rather the name of the Script I want to use and cache that…

It might be hard to see, but what you can find in all those lines is a reduction in code, removing the “.GetComponent<Level>()” bit in many of the lines, and placing it on that first “currentLevel” line on line 4.  Now in line 5, instead of:

You’ll see I have:

That is MUCH easier to read, it’s more efficient in Unity (and for a big game that would matter a LOT (my game, not so much, but it’s still important to know).  Not only is it easier to read, it means it’s easier to type and it cuts down on the keystrokes and I don’t have to worry about what component I’m getting each line.  In fact it gets REALLY bad when you look at something like this:

You see that because I’m calling the “Level” script component of the current level, and then I am calling the function “Shuffle” that is located in that level script, I’m doing a notation to access things.  Now compare that to the following and see how much easier it is to see what’s going on:

“Oh – I’m calling the Shuffle method of the current level, easy!”

Now – if I have multiple scripts attached as components to the Level gameobject, that would definitely mean I need to cache each of those scripts as their own components.  I don’t have too much complexity in this game where I need to worry too much about that, but in a larger game that would most certainly be a possibility.


In Object Oriented Programming, one of the core concepts is called “Encapsulation”.  This means that all the features of an object should only be accessed by that object as much as possible.  This means you have keywords “public” and “private” to set these access levels. (there are some others like “protected” but I won’t go into that here).  So usually what you want to do is set an attribute of an object to “private” and then have what’s called accessor methods (or “Getter/Setter” methods) to access those values.  So let’s pretend you have an apple and that colors are an attribute (defined elsewhere) and you can say an apple is green or red.

Well with it being public like above, all you need to do is say something like Apple.Color = “Green” or Apple.Color = “Red”.  And if I want to get the information I would type “Console.Writeln(Apple.Color)” (Or something to that effect, it’s pseudocode)

Now, this is off the top of my head and I’m sure it’s wrong – I’m using something like C++ syntax here, though I’m sure it’s close to C#… I honestly don’t remember it too much, because I’m a bad coder and use “Public” way too much, especially in Unity.  But anyways, the idea here is that if I want to have a method for my character that says “Look()” and it gets visual information of the object, I can’t just say “Console.Writeln(Apple.Color)” because it is private.  I have to use the public accessor “Get” which means typing something like “Console.Writeln(Apple.get_color())”

Boy that seems like a lot of work, doesn’t it?  Well it’s there to help protect the programmer from accessing things they shouldn’t and help reduce potential errors in the future when somebody makes a mistake and tries to write a value that shouldn’t be written to.  If I try to assign a value to to color, and there is no public getter/setter, but the variable is private, then there is no way I can modify that variable from an object outside of the object itself.  (For the pedants who may be reading this: Yes, I’m only dealing with Private/Public, and note that there are other keywords that can change this rule from being so strict).

I’ve always hated that, especially when it comes to merely reading the information.  I don’t quite understand why I can’t at least look at the data.  I mean, I’m sure in a large project there are very good reasons to encapsulate things to that degree, but frankly, I think it’s dumb.  So if I just want to know something I have to go type all this getter/setter crap.  C# created an easier way (Thank you Eric Lippert and Erik Meijer — or whoever else on the C# team that came up with this idea).

So basically, what you have here is a real simple syntax.  In more complex cases, you’ll still need to work with the more traditional getters/setters, but in cases where one just wants to set or get basic values from a property, this is a godsend.

How frickin’ easy is that???  Now I can just do “Apple.Color.set(“Green”)” and “Apple.Color.get()” and find out the color of an apple.  There is no more need for me to do all this extra code just to get a value or set a simple value.

I had previously heard about this, but never tried to put it into practice.  I admit part of it is because my code is so bad (hey, the name of my company is “Phoning It Industries”, right?) that I make most stuff Public.  Well this will make it easier to write code that’s more protected and save me time and effort.  And it’s so simple.


And there you have tonight’s revelations and education.

Finally – Is this new syntax highlighting that I have pretty dang cool or what?  Yay for WordPress and WordPress plugins.

I might try to look into a creating a custom syntax for this addon (Crayon Code, for those who are curious) that expands upon the default C# syntax highlighting and uses the special Unity syntax as well (I have a plugin for Sublime Text that does such a thing, and it would be cool to see things like ‘GameObject’ and ‘GetComponent’ highlighted in the code on my page as well as the regular C# keywords).