I visit tens of game development conferences every year, I listen to hundreds of talks and I deliver talks myself. I am by far not the greatest public speaker, I know my flaws and I don't like watching recordings of my sessions.

In this post I want to focus on meaningful tech talks, not marketing bullshit talks which sneak into conference schedules no matter what. Tech talks at conferences are usually done to share experience, show a product or explain a hard topic to the audience. In any case, there's a speaker who has some kind of knowledge and wants to share this knowledge with the audience.

The problem is that most people can't present their knowledge in systematic, understandable and entertaining way.

Which leads to disappointment and low ratings. It is always frustrating to watch how the author of a decent framework struggles to explain why it is useful, so at the end the only question the audience has is "why did we waste an hour on this?".

There are many articles on public speaking in the internet, most of them give general advice about presentation structure, rehearsing and engaging the audience. I don't want to copy these articles. Instead, I'd like to focus on mistakes I see a lot at IT and Game Development conferences.

Common mistakes

Most of the failed talks share the same mistakes. It is crucial to know them and be able to catch yourself on making them. This is a list of common mistakes I found particularly bad and capable of destroying any talk no matter how good the presenter knows the topic and how experienced public speaker he or she is.

1. Be aware that you have a fixed time slot

Let's start with an obvious advice which for some reason is frequently ignored in tech talks. It is understandable that we want to share as much valuable information as we can, but time slots at conferences are usually limited to 25 or 45 minutes, and what is more important, the audience can digest new information only that fast.

This means that you must carefully choose what you want to talk about. I've seen so many failed talks because the speakers tried to fit 5 hours of content into 25 minutes.

But the mistake is not about having too much content, it is about not understanding your time slot. Here are a few examples:

1. The speaker doesn't have too much content, but spends too much time on part 1, so he has to rush through part 2 and skip part 3.
2. There was an issue with video capture, so the talk started 10 minutes late but the speaker failed to take this into account and started rushing at the last moment.
3. The speaker was aware that he had much content and limited time, so he ran through it extra fast, finishing in 10 minutes and confusing the hell out of the audience.

So, you get the idea.

The best way not to make this mistake is to rehearse your speech at home or the hotel you are staying at and write down how much time you need for specific parts of the speech. At this point you will have a rough estimate like so:

I have 4 parts. The first one is about 20 minutes, the other ones are 10 minutes each. Summed up, this is 50 minutes which fits the 45 minute slot I've been given. Unfortunately, no time for questions... Which is good, since I don't know what I am talking about anyway.

During the talk you will need to try to stick to the budgeted time. If you are within the budget, you speak at the normal speed, add jokes and ask the audience questions; if you are running late, you speak faster and start skipping slides.

This practice is going to take a lot of time and at some point you will learn how to budget the time without rehearsing and skip the slides in such a way that nobody suspects a thing. But this will happen only if you fully understand the next section.

2. The audience doesn't know how your presentation is supposed to go

You probably don't think about it, but the only living creatures who know what your slides are and how your presentation is supposed to go are you and your cat who's been intensely staring at you the whole time you were rehearsing your speech at home.

In other words...

The audience doesn't know what is supposed to be on your slides and how your presentation is supposed to go.

This is extremely important and for some reason is not really obvious. Think about it for a few seconds.

Never tell the audience that what is happening is not a part of the plan.

Don't panic and be ready to continue if something is not working. Here are a few examples.

The presenter sees that he is running out of time and decides to skip one of the two remaining topics. What should he do?

Wrong: He quickly switches to the next slides one by one explaining that there's no time and apologising until he reaches the last topic.
Right: In Presenter mode on his display he switches manually to the last topic and starts from there.

The thing is that the audience doesn't know about the topic he was about to skip. Nobody is going to stand up and demand to show the skipped topic. On the contrary, manually skipping through the slide deck and apologising clearly shows that the presenter is unable to plan his time and the audience will feel cheated in some way because a part of the valuable information was taken away.

The presenter suddenly realizes that this is not the latest version of the slides, and that one important slide is missing. What should he do?

Wrong: He starts apologising and explaining that there was this great slide, that he spent an hour googling for appropriate memes for it, that it was so important and there might be a possibility that he can find it on his thumb drive...
Right: Realized that the slide is missing, he switches to the previous slide and tells the part of the story without ever mentioning the missing slide.

The audience doesn't care about your slides. As long as what you are saying makes sense, the slides are not needed at all. Most of the time slides are there just for you to remember what you are going to say next.

All animated GIFs and videos are broken and don't play. What should the presenter do?

Wrong: Every slide he apologizes that the video is not playing and pauses the presentation trying to make it play.
Right: He doesn't say anything about the GIFs — nobody knows that these are not just static images. He has videos on the thumb drive, one of which is important, so he tries to plug the thumb drive and play the video from there. VLC seems to play the file fine.

Don't let the audience know that something is not right, and don't apologize for this. It doesn't look well, believe me.

Many times I had to use the conference default PC which messed all the fonts, but there was no point in apologizing for ugly slides: many people understood this, some didn't care, others thought this was intended since I am a programmer and can't design shit.

A few times I had to manually increase the font size on all slides on stage while waiting for people to come because the conference used 320x240 LED displays ¯\_(ツ)_/¯ Nobody suspected this wasn't planned.

3. Find out what hardware the conference is using and test it before the talk

Speaking of 320x240 LED displays, this was an unpleasant surprise for me since I was going to do a live demo (which obviously I had to skip). Since then I added "projector type and resolution" to my usual questions to the organizers.

Not knowing what hardware the conference uses is a very common mistake, and it is rather painful for tech talks because we tend to do live demos. Hell, half of my presentations are just live demos without slides at all. So, it is usually quite disappointing when you figure out that you can't run the demo from your machine for whatever reason.

But even if I am not running a demo I always prefer to present from my MacBook Pro with all the right fonts, correct video playback and familiar keyboard. So I usually ask to provide the following information:

1. Is it possible to present from my laptop?
   Usually it is, even if the organizers say no the first time. At this point I try to play the NDA card, that I can't present from their machine because I can't copy files there. It tends to work, but don't tell anyone!
2. What video cable are you using?
   I always have all the adapters in my backpack, but it is good to know this in advance.
3. What video capture device are you using?
   Video capture is usually done by a contractor and here you can have surprises. Especially if you are on Mac, because there are many cheap devices which don't like Macs... or Macs don't like them — anyway, video capture doesn't work.
4. Is audio available?
5. What projector are you using and what resolution does it have?
6. Will my talk be recorded?

Unfortunately, having all the answers is not enough. You never know if this particular video capture setup will work with your PC, so you have to go and test it.

Try to go to the hall where your presentation will be as early as possible before the talk and ask to test your laptop. Connect the video capture, run the slides, play videos — usually everything works. If not, talk to the A/V guys and the organizers about possible solutions.

Don't be that guy who is unable to play videos in his presentation. Don't be that guy who tries to show a networked game connected to the conference network (which obviously doesn't work). Don't be that guy who was going to show the live demo, but his software doesn't run with resolution lower than 1280x720 (true story).

4. Make sure that people can actually see what you are trying to show

Continuing the topic about hardware, you must take into account how people will be looking at your slides or live demos. It is not a good presentation if the audience can't see what's going on on the screen.

There are several common issues:

1. Text (especially code) is too small.
   If you are showing code in an IDE, make sure that you increase font size to an optimal value when people can actually read it.
2. Interface is tot small.
   Learn to use built-in zoom on Mac and Windows. Make sure that you zoom on important parts of your live demo during the talk.
3. IDE theme is too dark.
   You might have your favourite dark IDE theme enabled which looks great on screen, but doesn't have enough contrast on projector. You should definitely think about changing it to a light contrast theme at least for the presentation.
4. Video is too dark.
   Unfortunately, if you are showing a horror game which is simply too dark for the projector, the audience will not be able to see much. In this case you can try to edit the video to add more contrast to it, and ask the conference organizers to dim the lights during the video. But you must discuss this moment in advance, because most of the time nobody knows where the light controls are ¯\_(ツ)_/¯

5. Reverse the flow order of your presentation

How many times have you seen (or personally delivered) a talk with the structure like this?

1. This is the thing,
2. This is what it can do,
3. This is an example of how to use it.

This is the most common presentation structure but it is fundamentally wrong.

Do you know why TED talks are 18 minutes long? Science says that this is an optimal time interval in which humans can still keep their attention on the speaker. But it gets much shorter if the audience is bored.

This structure is bad because:

1. Most of the time till the very end of the presentation people still have no clue about what the thing is for. For the presenter it might be obvious from the first two parts, but without a concrete example people usually still have no idea if this thing might be useful for them or not.
2. The first part of a presentation following this structure tends to be rather boring because its role essentially is to list axioms, describe the problem space and have a 5 minute story on how the thing was conceived.
3. Even experienced presenters can't always budget their time correctly, so the last part is usually rushed through, or even worse — the audience is directed "to watch videos online after the presentation". Of course, this leads to huge confusion.

So you will end up with the following attention curve.

The biggest issue with attention curves is that less attention the listener pays to what the speaker says, it's harder for the curve to go up — so, if attention gets close to zero, it will always remain there. Or, scientifically speaking — congratulations, you have bored the hell out of the audience!

The presentation structure to keep attention must be reversed:

1. This is an example of how to use the thing,
2. This is what it can do,
3. This is the thing.

In this case, the audience will most likely be interested from the very beginning. Of course, this structure is rather controversial because, it seems odd to show an example of using a Surface Integral without describing what this is first. But in practice showing an example first triggers active questions in the audience: What is it? How is it done? Can I use it? Exactly these questions you are going to answer in the next parts of the presentation.

The totally reversed flow is not applicable to every presentation, but...

You should ask yourself, is the flow of your presentation supporting attention in the audience or is it just making everyone fall asleep?

6. Don't assume that everybody has played or at least knows your game

I know people in game development industry who haven't played Diablo or The Witcher 3, I know people who don't follow mobile top charts and "this is like Clash of Clans" tells them nothing.

Why do you assume that people know YOUR game?

Even if you are CD Projekt Red and you are going to talk about The Witcher 3, you absolutely must show a trailer or a gameplay clip at the beginning of your talk. Don't think that you are saving precious time by not doing this. What you are really doing is adding more confusion which immediately converts into lack of attention.

7. Show, don't tell

There's nothing more boring than a wall of text on a large screen. Don't do this.

If you are talking about your game and how you created 50 characters, 20 levels and 10 weapons — show the weapons, show animated characters, add screenshots of the levels! If you are describing an algorithm, show a visual representation of how it works.

Don't make the audience read, especially don't make people read code from the slides!

If you have to show code, highlight important parts.

8. Everything is important in your presentation

One thing I really hate is when I am sitting in the audience trying to figure out what the speaker is showing, but he keeps switching through slides saying that this is not important. WHY HAVE YOU INCLUDED THESE SLIDES THEN???!!1

I can tell you why, because I tend to do the same thing. Good that I know this and I am able to correct myself right away. But most of the time it is hard to fix the voice I'm using while talking about these things. People tend to notice this.

People tend to see when you think that what you are saying is not important, and they project this on you. Now you are not important.

If you look like what you are saying is important, people will give more attention to what you are saying, they will tend to agree with you and will more likely think that you are smart (do you think those public speakers are smart? well, at least they look smart). Unfortunately, this is a difficult skill to master

You should start with believing that if you included this slide in the presentation, it is important. It was important when you were making this slide deck, why is it suddenly not important on stage?

General advice

And the last, I want to list a few things which help me deliver better presentations.

1. Don't eat before the presentation

This one is my personal choice. I usually feel like having a nap after getting a good meal, which is not the best state to be when you need to stand on stage and talk for an hour.

Look at your own experience — do you feel more active after having a meal? Does drinking coffee before a presentation make you more active or you just feel more awake while your brain seems to be lagging?

2. Find a person in the audience and talk to him or her

It is hard to speak in front of a large audience, you see people swiping their phones, people randomly stand up and leave, or people just keep staring at you with a distinct sceptical look on their faces. The later doesn't mean that the person is judging you, he or she is most likely suffers from Resting Bitch Face Syndrome.

So the best strategy to keep calm is to find one or more people in the hall who look genuinely interested and talk to them. In this case it doesn't matter if you are speaking in front of 10 people or 10 000 people.

3. When asking "who is here [X]?" questions, raise your hand

It is a good practice to spice up your presentation with questions to the audience. By doing this you may be able to change your presentation on the fly or just break the ice in the room.

The question might be the following: "Who is a programmer here? Raise your hand."

I found, that a good thing to do when asking such questions is to raise your hand too. This shows the audience that this is OK to raise a hand and someone has already done this. Otherwise, you know, people are shy to actively participate.

4. Don't let a person in the audience hijack your talk

Sometimes I want the audience to ask questions during the presentation, so it is more like a lecture, not a one way information transfer. But I know that I have this bug, that if interrupted I completely lose track of what I was saying. So, I usually try to enforce one of the following rules:

• If you have a question, raise your hand.
• I ask if there are questions during transitions between logical sections of my presentation. No questions while I am speaking.

This helps me to structure the presentation and make sure that I budget the time correctly. The biggest problem here is when a person from the audience tries to hijack your talk by masking his own opinion within a question. Such "questions" tend to be long and distracting, and what's more important they benefit nobody except the person asking them.

It is very important to identify such "questions" in time and try to get rid of them as fast as possible. This is what I usually try to do:

1. If the story before the question is getting quite long, I usually interrupt the person and explicitly ask "so, what's the question?". This works sometimes.
2. Tell the person to talk to me after the presentation.
3. Say that I can't answer this now, but if the person sends [the project] to me by email, I might be able to look at it further. (hint: nobody has ever sent me anything, so this is safe)

*************

I hope that with the help of articles like this there will be fewer mediocre talks at IT and Game Development conferences. Remember, that sharing knowledge is a unique skill which requires hard work. Just knowing something is not enough to be able to teach people what you know.

Practice, look at other speakers, read articles like this, and soon people will line up for your talks and give you 5 star rating all the time!

We've just released Unity 2017.1 which while being just a next Unity update begins the new era of the Engine. If you are as excited as me, don't forget to read about new amazing features on our Blog.

Unity 2017.1 has more features and fixes than that blog post had space for, but unfortunately nobody reads Release Notes. So, I compiled a list of little fixes and features which are probably too small but I find them really important.

Editor: New projects now default to text-based serialization.

When you are creating a new project, do you also go to Edit > Project Settings > Editor and set Asset Serialization Mode to Force Text every damn time?

This is the best feature of Unity 2017.1! Hands down! Saving millions of man hours.

UI Profiler

This is not a small thing, but was not included into the main blog post for some reason. The UI team made an amazing UI Profiler which shows how much CPU time UI rendering takes and also tells why UI objects were split into many batches.

This is a great tool to profile UI in your game!

Update: UI Profiler was added to the oficial post.

UI: Added support for selecting multiple files in the "Assets/Import New Asset..." dialog, on all platforms.

I have never used this dialog specifically for this reason. It is much easier to select and drag a bunch of assets to the Project Window. It is too late for me to change, but you might consider using this dialog instead.

IL2CPP: Improved IL2CPP code conversion time on OSX. Conversion times may improve by as much as 2x.

Yey! Faster iOS builds!

Editor: Log messages from connected players will now show in Editor console for easier debugging.

This is really cool! Now you can use Profiler connection to see logs from a game running on device in the Editor Console window. I randomly noticed this during a 2017.1 beta and was very excited!

Physics: Add ability to manually simulate 2D physics using "Physics2D.Simulate(time)" and turn auto simulation on/off with "Physics2D.autoSimulation=true/false".

Also the same for 3D physics:
Physics: Expose Physics.Simulate and Physics.autoSimulation. This allows stepping the physics simulation manually, from scripts. Useful for customising the server-side physics, in-editor simulation, and more.

This change gives you control over when you want to simulate physics. The ability to simulate physics in the editor is really powerful.

Asset Pipeline: Added methods AssetBundle.GetAllLoadedAssetBundles and AssetBundle.UnloadAllAssetBundles.

If you really need to unload everything! This is really helpful in the editor when you load a bundle but a link to it is lost during an assembly reload.

Editor: Added callbacks for assembly reload events: two events are dispatched: one before and one after reloading all assemblies. See: class AssemblyReloadEvents.

before and one after reloading all assemblies. See: class AssemblyReloadEvents.
If you have ever developed a non-trivial Editor extension you remember the pain for figuring out how to handle assembly reloads changes properly. Especially when transitioning into Play Mode.

We used to have EditorApplication.playmodeStateChanged callback with some code checking EditorApplication.isPlaying and EditorApplication.isPlayingOrWillChangePlaymode properties to figure out why the assemblies were reloaded.

Now we have AssemblyReloadEvents.beforeAssemblyReload and AssemblyReloadEvents.afterAssemblyReload.

Editor: Experimental feature : retained-mode UI system for the Editor (UI Elements).

Have you ever done any Editor scripting? Unity uses this unfamiliar to most of the people concept of Immediate Mode GUI for its interface. It is not easy to start writing your own Editor extensions and takes some time to learn how to do it right.

This is why we are working on a more convenient system to write Editor extensions which is based on a more traditional paradigm — Retained Mode UI.

This system even supports CSS to style elements.

UL Elements is an experimental feature right now, expect many changes in 2017.2. If you are interested, read more at our Github account.

Build Pipeline: Added delegates to BuildPlayerWindow that allow overriding the default Build button behavior.

Many of you write your own build logic and execute it from the top menu. BuildPlayerWindow.RegisterBuildPlayerHandler allows you to override default behavior of the Build button.

Graphics: Increased batching limits to 65,000 vertices. (810600).

There was a limit not only for the number of vertices, but also for the number of indices, resulting in less optimal batching. Now static batching can combine more stuff!

Shaders: Optimized game data build time for shaders with massive ("millions or billions") potential variant counts. Fixed shader inspector popup menu to display variant counts larger than 2 billion properly.

For those who have massive shaders q:

Scripting: Rename to Debug.logger to Debug.unityLogger (852000).

This thing was just a bit annoying. Basically, when typing Debug.lo in a code editor you'd get Debug.logger autocompletion while you needed Debug.Log. I guess, thousands Unity developers have already learned to just type Debug.Log...

Editor: Fix focused Game View not always receiving input (macOS) (895460).

This one was reported by me and broke one of my pet projects. Basically, a big detached Game View on Mac wasn't receiving input at all ¯\_(ツ)_/¯

I guess, I was the only one trying this on Mac. Glad this was fixed.

Editor: AssetServer version control support has been removed from the editor.

This last one is kinda sad. To move the Engine forward we unfortunately have to remove old code and features some people might still be using.

That's all, folks!

So, this is my quick list.
What is the small feature YOU are most excited about?

These days you can find a lot of articles about Unity over the net which tell you to do this or not to do that, especially when it comes to performance and optimization.

I like testing these little bits of knowledge with little Unity projects on various platforms. Sometimes I get interesting results. This post is about one of them, and I still don't understand the results I got.

TL;DR: Shit's complicated, yo!

The question

Look at Vector3.one. You might have heard that since this is a Property, it is a method call which is not inlined by IL2CPP in any way. So, your little for (var i = 0; i < 100000; i++) v += Vector3.one; in Update() might be costly.

But is it?

The test

So, I made a test to compare performance of the following:

1. Vector3.one
2. new Vector3(1, 1, 1)
3. local variable
4. static variable

The test is measuring timings of 5 loops:

static Vector3 Vector3Zero = new Vector3(1, 1, 1); 
var v3z = new Vector3(1, 1, 1);

// empty
for (var i = 0; i < n; i++) {}
// Vector3.one
for (var i = 0; i < n; i++) { arr[i] = Vector3.one * i; }
// new Vector(1, 1, 1)
for (var i = 0; i < n; i++) { arr[i] = new Vector3(1, 1, 1) * i; }
// static variable
for (var i = 0; i < n; i++) { arr[i] = Vector3Zero * i; }
// local variable
for (var i = 0; i < n; i++) { arr[i] = v3z * i; }

Results

OS X (Mono) — MacBook Pro

Running on my MBP with a standalone non-development build I got the following timings:

1. empty: 18 ms,
2. Vector3.one: 345 ms,
3. new: 325 ms,
4. local: 226 ms,
5. static: 239 ms.

This seems to be expected, though I am more interested in IL2CPP right now.

Android Galaxy S7 IL2CPP 32 bit

Next, I published the test to my Android test device:

1. empty: 0 ms,
2. Vector3.one: 387 ms,
3. new: 177 ms,
4. local: 147 ms,
5. static: 150 ms.

As you see, the empty loop was optimized by the compiler. I iterated on the test a few times to make sure that it doesn't optimize anything else. As for Vector3.one, here we see that it is more than twice as slow as a local variable, which is still the fastest.

iOS iPhone 6 IL2CPP 64 bit

Next, I ran the test on my iOS test device (Android results after /):

1. empty: 0 ms / 0 ms,
2. Vector3.one: 47 ms / 387 ms,
3. new: 56 ms / 177 ms,
4. local: 35 ms / 147 ms,
5. static: 54 ms / 150 ms.

Wait, what?!

I ran this test a lot of times with slight modifications here and there. I'd appreciate if anybody would give me a hint what I did wrong.

iOS iPhone 6 IL2CPP 32 bit

Is this a difference in hardware or 32bit vs. 64bit? Samsung S7 should be a bit faster than iPhone 6. Let's see how 32bit code performs (64bit results after /):

1. empty: 0 ms / 0 ms,
2. Vector3.one: 170 ms / 47 ms,
3. new: 175 ms / 56 ms,
4. local: 174 ms / 35 ms,
5. static: 170 ms / 54 ms.

OK, this looks more like timings I got on Android.

Generated code

So far the only result is that you'd better use a local variable. But let's dig deeper into IL2CPP generated code.

IL2CPP takes your C# code and emits C++ code instead. This C++ code is easy to find in Xcode project but is not that easy to read. If you are interested, I recommend reading the series of blog posts about IL2CPP at Unity Blog.

Let's look at the code generated from our C# test.

Here's Vector3.one C++ code:

extern "C"  Vector3_t4282066566 Vector3_get_one_m2017759730(…) {
	Vector3_t4282066566 L_0;
	memset(&L_0, 0, sizeof(L_0));
	Vector3__ctor_m2926210380(&L_0, (1.0f), (1.0f), (1.0f), …);
	return L_0;
}

And this is how this method is called from our code:

Vector3_t4282066566  L_14 = Vector3_get_one_m2017759730(…);

Here's new Vector3(1, 1, 1) C++ code:

Vector3_t4282066566  L_50;
memset(&L_50, 0, sizeof(L_50));
Vector3__ctor_m2926210380(&L_50, (1.0f), (1.0f), (1.0f), …);

BUT...

Since Vector3_get_one_m2017759730 and Vector3__ctor_m2926210380 are in the same compilation unit, the constructor is actually inlined in Vector3_get_one_m2017759730 method. It is compiled to the following bytecode:

fmov		s0, #1.00000000
mov.16b	 v1, v0
mov.16b	 v2, v0
ret

Is this why Vector3.one is not slow here?

But as our code is in another compilation unit, it is correct to say that Vector3_get_one_m2017759730 will not be inlined to our code.

If you look to any code using static variables, you will see that in IL2CPP it follows the same pattern. For example, this is the call to the static variable in my test:

IL2CPP_RUNTIME_CLASS_INIT(Test_t2603186_il2cpp_TypeInfo_var);
Vector3_t4282066566 L_26 = 
   ((Test_t2603186_StaticFields*)Test_t2603186_il2cpp_TypeInfo_var	
	->static_fields)->get_staticOne_2();

Luckily, the whole second line is inlined. But, the IL2CPP_RUNTIME_CLASS_INIT macro has to check if the class is initialized every time. Is this why static variables are slow(er)?

Safety checks

Let's look at a snippet of generated IL2CPP code:

Vector3U5BU5D_t215400611* L_25 = __this->get_arr_5();
NullCheck(L_25);
IL2CPP_ARRAY_BOUNDS_CHECK(L_25, L_26);
Vector3_t4282066566  L_27 = Vector3_get_one_m886467710(…);
int32_t L_28 = V_3;
Vector3_t4282066566  L_29 = Vector3_op_Multiply_m973638459(…);
(*(Vector3_t4282066566 *)((L_25)
   ->GetAddressAt(static_cast<il2cpp_array_size_t>(L_26)))) = L_29;

Notice lines two and three:

NullCheck(L_25);
IL2CPP_ARRAY_BOUNDS_CHECK(L_25, L_26);

Unity and IL2CPP add a few safety checks to generated code to make sure that you don't accidentally shoot yourself in the foot. This is usually a good thing. But does it add overhead? Yes, it does.

You can turn these safety checks off using Il2CppSetOption attribute (read more) like so:

[Il2CppSetOption(Option.NullChecks, false)]
[Il2CppSetOption(Option.ArrayBoundsChecks, false)]
[Il2CppSetOption(Option.DivideByZeroChecks, false)]
public class Test : MonoBehaviour {}

Of course, you must be absolutely sure that your code is perfect before doing this. Let's see how much performance I got in my test on iPhone 6 by turning these things off:

1. empty: 0 ms / 0 ms,
2. Vector3.one: 40 ms / 47 ms,
3. new: 56 ms / 56 ms,
4. local: 31 ms / 35 ms,
5. static: 51 ms / 54 ms.

Well, this is definitely good.

What we found out

64-bit

Does the fact that I build for a 64-bit platform give such speed boost?

Here I'm entering the realm where I don't really have much expertise. From a lot of googling and chatting with more experienced colleagues I got the following:

1. It's not SIMD. Generated ARM instructions are definitely not SIMD.
2. The 64-bit bytecode seems to be using registers instead of stack to pass function parameters.

This might be just an edge case. So, the question is still open.

Results

1. It is really important to test things on your platform and target device.
2. Compilers are smart.
3. Use a local variable.
4. You learn a lot while making tests.

... and (sadly) I still don't understand what's going on.

A WebGL Unity project is just a normal HTML page running a 3 000 000 lines of code JavaScript file.

The heart of HTML pages are links which can be opened either in the same window/tab or in a popup window/tab. Turns out that it's not that simple with a Unity WebGL project precisely because of one of the browser's security mechanisms.

Modern browsers open links in new tabs/windows only when they clearly see that this action resulted from a user input event, like mouse click for example. If not, Firefox displays this when a JavaScript uses window.open() code to open a new window:

This is fine in a context of a normal web page when you click links. But in Unity actual input is processed within Player Loop in a moment after you clicked an object which is too late for a browser to consider this action to be originated from a user event.

So, if you use Application.ExternalEval("window.open('http://google.com');"); in Unity when a mouse button is pressed this will be already too late and your window will be blocked by default.

A proper solution here would be the same described in Unity WebGL Docs — send a message to JavaScript from Unity when a button is pressed so JavaScript would execute actual window opening code when user releases the button.

This can be done in a few ways described in Unity WebGL Docs: Interacting With Browser Scripting. But let's see how one can write a WebGL JS Plugin to do this.

A WebGL plugin is a .jslib file placed anywhere in your project. It's a good idea to store plugins somewhere like /Assets/Plugins/WebGL but it's not required anymore. New Plugin Inspector in Unity 5 makes life much easier:

The contents of OpenWindow.jslib file is the following:

var OpenWindowPlugin = {
    openWindow: function(link)
    {
    	var url = Pointer_stringify(link);
        document.onmouseup = function()
        {
        	window.open(url);
        	document.onmouseup = null;
        }
    }
};

mergeInto(LibraryManager.library, OpenWindowPlugin);

It's a JS file with an object containing one function — openWindow. This function receives an URL from Unity and set's up onmouseup event for entire web page which when opens this URL. Notice: this is just the most simple example code.

Then, the simplest script to use this plugin would be the following:

using UnityEngine;
using System.Runtime.InteropServices;

public class Link : MonoBehaviour {
	public void OpenLinkJSPlugin() {
		#if !UNITY_EDITOR
		openWindow("http://unity3d.com");
		#endif
	}

	[DllImport("__Internal")]
	private static extern void openWindow(string url);
}

Notice #if !UNITY_EDITOR in the script — this is a preprocessor define to include this code only when executed not in Unity Editor, because this code will not work there.

The next thing is we need to code another small script to actually execute this code on mouseDown event when we click an UI Button for example. The issue with Buttons is that they fire onClick event only when mouse button is released, which is too late for us. This means that we need another script and we need to put it on our Button element in UI hierarchy:

using UnityEngine;
using UnityEngine.EventSystems;
using System;
using UnityEngine.Events;

public class PressHandler : MonoBehaviour, IPointerDownHandler {
	[Serializable]
	public class ButtonPressEvent : UnityEvent { } 

	public ButtonPressEvent OnPress = new ButtonPressEvent();

	public void OnPointerDown(PointerEventData eventData) 	{
		OnPress.Invoke();
	}
}

Put this script on your UI Button and set OnPress event to call our OpenLinkJSPlugin function.

For an example Unity project you can refer to this GitHub page.

Nowadays when someone uses the word optimization they usually mean optimization for execution time, unless they've explicitly stated that they are going to optimize for GPU memory consumption, network traffic, etc.

Know what you are optimizing for

When I started programming we not only had slow processors, we also had very limited memory — sometimes measured in kilobytes. So we had to think about memory and optimize memory consumption wisely. University taught us about two extremes in optimization:

• You either optimize for execution speed sacrificing memory,
• Or you optimize for memory consumption by calculating stuff over and over again.

These days nobody cares about memory much (except demosceners, embedded systems engineers and sometimes mobile games developers); I mean not only RAM but hard drive space too. Just look at the Watch Dogs install which is about 25Gb on disk. In addition, I'm writing this in a Chrome tab which ate 130Mb of RAM.

But there are more optimization types:

• Optimization for power consumption, which is getting more attention with growth of smartphones market
• Optimization for readability to make reading and debugging code easier, thus reducing development time and cost
• I'll just stop here...

Optimization for readability — making code easier to read, follow and understand.

You should understand that you can't optimize everything at once. For example, while working on performance optimization you will likely make your app consume more memory and make your code less readable.

Why readability

Developers spend most of their productive time reading code, not writing it: debugging, checking commits done by others, learning new libraries, etc.

While doing this developers essentially work as (not so good actually) interpreters — executing code in their head while trying to keep in mind the current state of execution. This is why programmers tend to be particularly grumpy when interrupted during this process.

Time == money

The most important thing to understand is that your and your coworkers' time costs a lot. And even if a developer works hard they can still waste time by:

• Working on things which are not needed now and might be never used.
• Working on something which doesn't add perceivable value.
  For example, wasting a week to optimize execution time of a function which is called once an hour by 10ms.
• Writing hard-to-debug code and trying to find bugs in it.
• Writing code which slows down other people.
  Remember that "other people" might as well be YOU in just a week.

This is provided that the developer in question is an experienced one and knows how to write efficient algorithms and clean code. Otherwise this list would be too long.

Optimize for readability

There's a well-known quote by Donald Knuth. I bet you've heard it numerous times.

"Premature optimization is the root of all evil (or at least most of it) in programming." by D.Knuth, 1974.

I have seen a lot of people who memorized it but didn't understand what this quote really means. The most common mistake looks like this:

— Why the code for this simple task is so complicated?
— I optimized X and Y because in the future...
— Haven't you heard that Premature optimization is the root of all evil?
— Sure, but this is not premature optimization, I know that this way it will work faster.

I assume this is because the term premature optimization is not well-defined. This is why the person in the example doesn't consider what he has done to be a premature optimization at all. How can we define this term?

Premature optimization — everything one tries to optimize before profiling and running tests on a working system.

Everything except readability. So instead of what one shouldn't do we'd better say what one should do. And the quote will look like this:

Optimize for readability first.

What slows down developers when reading code

Well, we agreed that we should make our code easier to read to spend less time doing it, wasting less money, right? But what does it really mean?

There are two fundamental things that immensely slow down a developer while reading code:

1. The code is hard to understand,
2. The code is hard to follow.

The code is hard to understand

Unfortunately people are not like software interpreters which don't bother to know what the code means to add two numbers and call a function (while it still compiles, of course).

To find why the code doesn't work a programmer needs to understand exactly what it does as typed in a source file, and what its original purpose was.

What makes code hard to understand?

From here I'll be writing about an experienced developer who knows the language the code is written in and algorithms used in the application's domain (i.e. he has enough knowledge to understand this code).

1. The code stinks. Monstrosities of one letter variables and 1000 lines long functions.
2. It is not properly or consistently formatted.
3. It has unnecessary one-liners.
4. There are undocumented low-level optimizations.
5. The code is too clever.

I'll skip the first two because you shouldn't be reading bad code anyway. If someone in your company writes it, teach them or get rid of them. And of course you need to enforce strict coding style for your entire code base.

3. It has unnecessary one-liners

Or so-called number of lines optimizations. Long lines with nested function calls and ?: operators are harder to parse. Of course, you may say that this argument is subjective. But some people just feel that they must leave in source code as few lines as possible, sacrificing readability.

4. Undocumented low-level optimizations

Long time ago the code was readable and worked fine, but someone decided to optimize it at some point. It might be a good optimization after serious profiling, but now the code looks like a combination of arrays, bitwise operators and magic numbers. Nobody knows what exactly it does or even what it was supposed to do because the guy who made the optimization didn't leave any comments.

You probably heard that good code doesn't need comments. But optimized code (evenespecially if it's good) DOES need them.

Most harmless consequences of such optimizations might be undocumented lines like this in your code base:

if (val != val) { ... }

5. The code is too clever

As software developers we learn more and more academic tricks which we then use in production code. We are Computer Scientists after all, not just mere coders!

Some languages even encourage developers to use bleeding edge techniques, making code more expressive and academic. You get the same feeling of accomplishment when you build a perfectly robust system in code as when you prove a hard theorem in math using methods 99.997% of educated individuals don't understand.

Even if code is well-organized into modules/classes/functions and each of these blocks contains perfectly readable imperative code, for someone else to read this code they will need a broader view of its architecture and they must know all the techniques and patterns used.

Once again remember that "someone else" might as well be YOU in a week.

This is most likely why I know only 2 people who use Scala in production. Personally I like Scala a lot. For me it has been an academic playground where I could build glass castles in vacuum. But the more you know about it and the more you use its features, the more you understand that it's essentially a write-only language (please don't quote me on this!); not as write-only as Perl, but even the most beautiful code base will require changes and updates.

Not as write-only as Perl but even the most beautiful code base will require changes and updates. And now you are stuck looking for a person who can understand this beautiful code...

This seems controversial that clean clever code is harder to read.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." by Brian Kernighan

The code is hard to follow

When reading code a developer jumps frequently from one method or class to another. This is where knowing your IDE of choice will save you a lot of time. By using Go to Declaration, Find Usages, Navigate to, Inspect and other features of an IDE (Visual Studio for example) you will be able to think about code as a connected graph.

It's fine to write code in Notepad but if you want to read code efficiently you will have to master a good IDE.

Well, what is a connected graph exactly?

A graph which is connected in the sense of a topological space, i.e., there is a path from any point to any other point in the graph. (source)

In other words in "connected" code you can easily follow from one method to another making a model in your mind of what this code does.

If somewhere in code a connection is broken (in a sense that IDE can't assist you jumping from one method to another) you usually have to spend some time looking for this connection yourself. More broken connections in code —> harder it is to follow —> harder it is to read.

So, why might the code graph be disconnected? There are many reasons; I'll list the ones I see most often:

1. Methods or properties are referenced as strings

Some frameworks just love doing this. They pass "callbacks" as strings and use reflection when needed. Here you just have to use good old CMD+F.

Most evil ones make these strings dynamic... in dynamic languages. All hail JavaScript! Or AS3 for that matter.

2. Code is separated into disconnected parts

For example, half of your code is written in C# and the other half is assembled in a visual node editor. You will have a hard time jumping between these two worlds.

The same stands for Dependency Injection frameworks and other XML-configured bullshit. They don't say it loud but writing XML configs is coding too. It's called declarative programming (not mentioning those insane people who build imperative languages over XML).

3. Huge graph nodes

20 links jump to this 1000 lines long method?.. ouch. You have no use for a graph which contains such nodes.

4. Everything is too abstract

When by Go to Declaration you get to an interface or an abstract class and have to figure out which implementation there might be. It gets worse with Dependency Injection, abstract factories and all the other methods which fight dependencies. Connections between nodes in code graph become too abstract.

It might seem that I hate DI and XML. DI is a great tool to avoid spaghetti code and make your architecture more modular and testable. But as many other good things it gets ugly when abused.

I was completely discouraged once when I was inspecting an app and I realised that I couldn't figure out where it starts... Like where the entry point is. It all was just automagically assembled from a huge XML config on start.

I do hate XML configs though.

***

So, here's what you should have learned:

• Master your IDE,
• Keep code graphs as connected as possible,
• Write simple code first,
• By writing unnecessary code you are wasting a lot of money.

It will take time and forcing yourself to write simple code, and resisting optimizations on early stages will definitely be hard.

But 2 hours before the deadline, having been awake for 48 hours straight, you will say "thank you" to yourself in the past if the code you are working with is debuggable with a half asleep brain.

P.S.

Don't miss great discussions on reddit and hackernews.
Thanks to /u/Arandur for correcting numerous grammatical errors!

Last week I stumbled upon Slides of Keith O'Conor's talk about performance optimizations and it reminded me of a topic I wanted to write a blog post about for several months.

So this is the post.

Information sponges

I have a huge list of RSS subscriptions and usually scroll through ~500 articles a day adding 10-30 of them to Pocket to read later. Which I rarely do. Most likely that you do the same. Because there's just too much information on the internet even if you read only blogs about software development.

I call people as myself "information sponges" because we try to absorb as much information as possible on a daily basis. Maybe some day this data will be useful...

And there's nothing bad about it... Nothing bad as long as you reflect on this information and don't catch yourself into a trap of partial filtering.

And this is what junior developers never do. Let me explain...

Partial filtering

All good talks and articles on the internet which give you insights on new technologies, methods, patterns and algorithms always specifically point out WHEN these algorithms should be used and what problems these new technologies are trying to solve.

The thing is that being overwhelmed by awesomeness of these new methods it's easy to filter out the information about when they should be used.

For example you might watch a video from a conference where a well-known speaker tells you how awesome MVC is. Of course explicitly or implicitly he will mention the problem which MVC solves. Because it's not just abstractly good, MVC is a solution to the specific problem (try to test yourself and say out load what this problem is).

Partial filtering is when you remember only that "MVC is awesome" instead of "MVC is a great solution to this specific problem".

Another good example is optimization. There are tons of great articles and talks about how to optimize stuff.

All of them usually mention that these are solutions to specific performance problems. If you don't have these problems don't try to optimize your code. You will just waste a lot of time and make it unreadable. Unfortunately this part is usually ignored.

The paper I started from has a slide on this topic.

This slide should have been in the beginning. With bold red text and images of dead programmers who didn't profile before optimizing.

Someone on the internet said to do so

And here's where it gets interesting.

Imagine a junior developer who is an information sponge (nothing bad so far), who unwittingly applies a partial filter to all information he absorbs (not so bad either), who thinks that because he absorbed all this information he is an uber developer now (not that fatal) and who doubts every single word from you contradicting to this filtered information especially when the information was presented by some authoritative person from Microsoft, Adobe, Oracle, you name it. Not just questions your opinion but he is totally sure that if that person on the internet said something you must be a total fool if you say something opposite.

Most of the time it goes like this:

— Damn, why did you code this monstrosity? Why didn't you use this easy built-in mechanism this framework gives you?
— The guys from Adobe say it's more performant.
— It might be faster on shitty mobile devices, we are running the app on Intel i7.
— But the guys from Adobe say...
— They say it for mobile devices.
— Whatever... (meaning "you don't know shit and you are no authority for me")

Once I even had this conversation which completely pissed me off:

— The library was not made to be used like you are using it. But now we have to do this because you ignored this easy mechanism provided by the framework and we don't have time to rebuild the whole thing.
— Who said that this library shouldn't be used this way? (meaning "give me a link to a video where someone from Microsoft says not to use the library this way")
— Me, the freaking author of the freaking library said that for fuck's sake.

Reflecting on yourself

Long time ago I was building a simple messaging system and was taken away by that object pooling strategy I learned from some blog. Of course I implemented it straight away just to be asked by my coworker:

— Why the hell did you do this?
— For performance, it caches message objects.
— Right... how many messages are you going to receive per second?
— Like... 1...
— Do you understand now?

Of course there was no point implementing message pooling system here. And I wasted half a day on this simple task trying to optimize the problem we didn't have.

This is a part of your learning curve — making mistakes and reflecting on them later.

I obviously had a mental filter which dropped the information on what problem this technique is solving. From that day I'm aware that while consuming information I might unwittingly activate such filter, so after reading a blog post or watching a talk I try to reflect on the information i received and how I understood it.

Dealing with such people

Personally I don't know how to deal with juniors for whom you aren't authoritative enough. It might be a coincidence but lately I'm meeting such people more often. Is it the new generation which can't handle information overload? I don't know.

I think that a junior developer must first accept that he is junior (though there's no definition here and a programmer with 5 years of experience may be as junior as a college graduate after all) and then learn hard from practical tasks and experienced colleagues.

The person described is unable to do both.

Another thing is that unfortunately I don't know anything about you as a reader of this blog. And this person might as well be you. Even if it's true you won't be able to accept it.

Think about it, reflect on yourself and don't ever blindly beleive what someone from Microsoft, Adobe, Oracle, you name it, said on the internet... or YOU think you remember what they said.

In Unity 4.5 we got a nice (undocumented) built-in tool to visualize lists in IDE. It's called ReorderableList, it's located in UnityEditorInternal namespace and looks like this:

Let's see how to code this beautiful interface in Unity IDE using ReorderableList.

Note: Though UnityEditorInternal namespace is public, it seems to be intended for Unity Team internal use (hence the name), it is not documented and might change in future versions of Unity. If you notice an API change please post it in comments section below.

Sources: Project sources are on GitHub.

Setting up the project

Let's pretend that we are making a Tower Defense-like game and need a decent interface for our game-designer to set up waves of monsters for a particular level.

First, create a new Unity project.

We will need some test assets: mobs and bosses. We'll be placing them in Prefabs/Mobs and Prefabs/Bosses folders. Create several prefabs and put them in these folders. Right now these can be just default cubes and spheres. Give them descriptive names. This is what I came up with:

Storing data

Create Scripts folder where we will store our C# scripts. Create two scripts in this folder: LevelData.cs and MobWave.cs.

Add this code to MobWave.cs. This is our value object for storing data for a wave of monsters.

using UnityEngine;
using System;

[Serializable]
public struct MobWave {
	public enum WaveType {
		Mobs,
		Boss
	}

	public WaveType Type;
	public GameObject Prefab;
	public int Count;
}

As you see, every wave can be either a wave of Mobs or one or more Bosses. Every wave has a link to a prefab to clone and a number of copies.

Note: Unity can serialize custom structs since version 4.5.

Add this code to LevelData.cs. This is just a container for our MobWave objects.

using UnityEngine;
using System.Collections.Generic;

public class LevelData : MonoBehaviour {
	public List<MobWave> Waves = new List<MobWave>();
}

Add a GameObject to your scene and call it Data. Add LevelData component to this game object and set it up as shown in the GIF animation below.

This is basically how lists in Unity IDE look by default. Of course they are not bad, but they become a major pain very quickly when you have many items in a list and want to move them around and add some in the middle.

Building a custom inspector

For every Component in Unity IDE you can create a custom inspector which will change how the component is shown in Inspector tab. Right now we will do this for our LevelData.cs script to change Unity's default list rendering to more functional ReorderableList.

Create Editor folder and a new script inside. Call it LevelDataEditor.cs.

Note: All custom inspectors must be in Editor folder and inherit from Editor class.

Add this code to the new script:

using UnityEngine;
using UnityEditor;
using UnityEditorInternal;

[CustomEditor(typeof(LevelData))]
public class LevelDataEditor : Editor {
	private ReorderableList list;
	
	private void OnEnable() {
		list = new ReorderableList(serializedObject, 
        		serializedObject.FindProperty("Waves"), 
        		true, true, true, true);
	}
	
	public override void OnInspectorGUI() {
		serializedObject.Update();
		list.DoLayoutList();
		serializedObject.ApplyModifiedProperties();
	}
}

All custom inspector classes have the same important parts:

1. A custom inspector must inherit from Editor class,
2. To tell Unity that this is an inspector for LevelData component we must add [CustomEditor(typeof(LevelData))] attribute,
3. private void OnEnable() method is used for initialization,
4. public override void OnInspectorGUI() method is called when inspector is redrawn.

In our case in OnEnable we are creating an instance of ReorderableList to draw our Waves property. Don't forget to import UnityEditorInternal namespace:

using UnityEditorInternal;

ReorderableList works with standard C# lists as well as with SerializedProperties. It has two constructors and their more general variants:

1. public ReorderableList(IList elements, Type elementType),
2. public ReorderableList(SerializedObject serializedObject, SerializedProperty elements).

In this example we are using SerializedProperty because this is the recommended way of working with properties in custom inspectors. This makes the code smaller and works nicely with Unity and Undo system.

public ReorderableList(
	SerializedObject serializedObject, 
	SerializedProperty elements, 
    bool draggable, 
    bool displayHeader, 
    bool displayAddButton, 
    bool displayRemoveButton);

As you see just by using right parameters we can restrict adding, removing and reordering of items in our list.

Later in the code we just call list.DoLayoutList() to draw the interface.

Right now you are probably saying: "Wait, this looks even worse!". But wait a minute, our data structure is complex so Unity doesn't know how to draw it properly. Let's fix this.

Drawing list items

ReorderableList exposes several delegates we can use to customize our lists. The first one is drawElementCallback. It's called when a list item is drawn.

Add this code in OnEnable after the list is created:

list.drawElementCallback = 
	(Rect rect, int index, bool isActive, bool isFocused) => {
	var element = list.serializedProperty.GetArrayElementAtIndex(index);
	rect.y += 2;
	EditorGUI.PropertyField(
    	new Rect(rect.x, rect.y, 60, EditorGUIUtility.singleLineHeight),
        element.FindPropertyRelative("Type"), GUIContent.none);
	EditorGUI.PropertyField(
    	new Rect(rect.x + 60, rect.y, rect.width - 60 - 30, EditorGUIUtility.singleLineHeight),
        element.FindPropertyRelative("Prefab"), GUIContent.none);
	EditorGUI.PropertyField(
    	new Rect(rect.x + rect.width - 30, rect.y, 30, EditorGUIUtility.singleLineHeight),
        element.FindPropertyRelative("Count"), GUIContent.none);
};

Return to Unity. Now all the list items are pretty and functional. Try adding new ones and dragging them around. This is much better, right?

If you are not familiar with the syntax and APIs in the code you just pasted, this is a standard C# lambda-expression with Editor GUI methods.

Note: It's important to have a semicolon at the end of a lambda };

Here we are getting the list item being drawn:

var element = list.serializedProperty.GetArrayElementAtIndex(index);

We are using FindPropertyRelative method to find properties of the wave:

element.FindPropertyRelative("Type")

And after that we are drawing 3 properties in one line: Type, Prefab and Count:

EditorGUI.PropertyField(
	new Rect(rect.x, rect.y, 60, EditorGUIUtility.singleLineHeight),
    element.FindPropertyRelative("Type"), GUIContent.none);

Note that list header says "Serialized Property". Let's change it to something more informative. To do this we need to use drawHeaderCallback.

Paste this code in OnEnable method:

list.drawHeaderCallback = (Rect rect) => {
	EditorGUI.LabelField(rect, "Monster Waves");
};

Now it feels right.

At this stage the list is fully functional but I want to show you how we can extend it even further. Let's see what other callbacks ReorderableList has to offer.

Callbacks

Here are all the callbacks exposed by an instance of ReorderableList:

• drawElementCallback
• drawHeaderCallback
• onReorderCallback
• onSelectCallback
• onAddCallback
• onAddDropdownCallback
• onRemoveCallback
• onCanRemoveCallback
• onChangedCallback

drawElementCallback

Signature: (Rect rect, int index, bool isActive, bool isFocused)

Here you can specify exactly how your list elements must be drawn. Because if you don't this code is used to draw list elements:

EditorGUI.LabelField(rect,
	EditorGUIUtility.TempContent((element == null) ? listItem.ToString() : element.displayName));

drawHeaderCallback

Signature: (Rect rect)

Is used to draw list header.

onReorderCallback

Signature: (ReorderableList list)

Called when an element is moved in the list.

onSelectCallback

Signature: (ReorderableList list)

Called when an element is selected in the list.

onAddCallback

Signature: (ReorderableList list)

Called when the + button is pressed. If this callback is assigned it must create an item itself, in this case default logic is disabled.

onAddDropdownCallback

Signature: (Rect buttonRect, ReorderableList list)

Called when the + button is pressed. If this callback is assigned + button changes to Add more button and onAddCallback is ignored. As with onAddCallback you must create a new list element yourself.

onRemoveCallback

Signature: (ReorderableList list)

Called to remove selected element from the list. If this callback is defined default logic is disabled.

onCanRemoveCallback

Signature: bool (ReorderableList list)

Called when — button is drawn to determine if it should be active or disabled.

onChangedCallback

Signature: (ReorderableList list)

Called when the list is changed, i.e. an item added, removed or rearranged. If data within an item is changed this callback is not called.

Adding selection helper

You can add Debug.Log() to all these callbacks to see when they are called. But now let's make something useful with some of them.

The first one will be onSelectCallback. We'll make that when you select an element the corresponding mob prefab is highlighted in Project panel.

Add this code to OnEnable method:

list.onSelectCallback = (ReorderableList l) => {
	var prefab = l.serializedProperty.GetArrayElementAtIndex(l.index).FindPropertyRelative("Prefab").objectReferenceValue as GameObject;
	if (prefab)
    	EditorGUIUtility.PingObject(prefab.gameObject);
};

The code is pretty simple. We are looking for Prefab property of selected wave and if it's defined we are calling EditorGUIUtility.PingObject method to highlight it in Project panel.

Checking how many waves have left

Let's say that we want to have at least one wave in our list at all times. In other words we want to disable — button if there's only one element in the list. We can do this using onCanRemoveCallback.

Add this code to OnEnable method:

list.onCanRemoveCallback = (ReorderableList l) => {
	return l.count > 1;
};

Now try deleting all elements from the list. You will see that if there's only one element the — button is disabled.

Adding a warning

We don't really want to accidentally delete an item in our list. Using onRemoveCallback we can display a warning and make a user press Yes button if he really wants to delete an element.

list.onRemoveCallback = (ReorderableList l) => {
	if (EditorUtility.DisplayDialog("Warning!", 
    	"Are you sure you want to delete the wave?", "Yes", "No")) {
		ReorderableList.defaultBehaviours.DoRemoveButton(l);
	}
};

Note how we used ReorderableList.defaultBehaviours.DoRemoveButton method here. ReorderableList.defaultBehaviours contains all default implementations for various functions which sometimes can be handy if you don't want to reinvent the wheel.

Initializing a newly created element

What if we wanted to add a preconfigured element when a user presses + button instead of copying the last one in the list? We can intercept the logic of adding elements using onAddCallback.

Add the following code to OnEnable method:

list.onAddCallback = (ReorderableList l) => {
	var index = l.serializedProperty.arraySize;
	l.serializedProperty.arraySize++;
	l.index = index;
	var element = l.serializedProperty.GetArrayElementAtIndex(index);
	element.FindPropertyRelative("Type").enumValueIndex = 0;
	element.FindPropertyRelative("Count").intValue = 20;
	element.FindPropertyRelative("Prefab").objectReferenceValue = 
    		AssetDatabase.LoadAssetAtPath("Assets/Prefabs/Mobs/Cube.prefab", 
            typeof(GameObject)) as GameObject;
};

Here we are adding an empty wave to the end of the list and with the help of element.FindPropertyRelative method we are setting its properties to predefined values. In case of Prefab property we are looking for the specific prefab at path Assets/Prefabs/Mobs/Cube.prefab. Make sure that you created the folder structure accordingly.

Now return to Unity and try adding new elements to the list. You will see that new elements are always added as Cubes with Count equal to 20.

Adding drop-down menu

The last example will be the most interesting. We will make a dynamic drop-down menu activated by + button using onAddDropdownCallback.

In Prefabs folder we have 3 mobs and 3 bosses, so it would be natural to be able to add a specific one from a menu instead of manually dragging prefabs in the list.

Let's first add a new data type which we will later use in our menu system. Add this code at the end of the file before the last }.

private struct WaveCreationParams {
	public MobWave.WaveType Type;
	public string Path;
}

Next, define a callback which will be called by built-in Unity menu system. Right now it's empty but we'll fix this later. Add the following code after OnInspectorGUI method.

private void clickHandler(object target) {}

And now is the time to define our onAddDropdownCallback. Add this code in OnEnable method:

list.onAddDropdownCallback = (Rect buttonRect, ReorderableList l) => {
	var menu = new GenericMenu();
	var guids = AssetDatabase.FindAssets("", new[]{"Assets/Prefabs/Mobs"});
	foreach (var guid in guids) {
		var path = AssetDatabase.GUIDToAssetPath(guid);
		menu.AddItem(new GUIContent("Mobs/" + Path.GetFileNameWithoutExtension(path)), 
        false, clickHandler, 
        new WaveCreationParams() {Type = MobWave.WaveType.Mobs, Path = path});
	}
	guids = AssetDatabase.FindAssets("", new[]{"Assets/Prefabs/Bosses"});
	foreach (var guid in guids) {
		var path = AssetDatabase.GUIDToAssetPath(guid);
		menu.AddItem(new GUIContent("Bosses/" + Path.GetFileNameWithoutExtension(path)), 
        false, clickHandler, 
        new WaveCreationParams() {Type = MobWave.WaveType.Boss, Path = path});
	}
	menu.ShowAsContext();
};

Here we are building dynamic drop-down menu from the files in Mobs and Bosses folders, assigning instances of WaveCreationParams to them to be able to find out what menu element was clicked later in clickHandler.

If you set up your folder structure right and didn't forget to add using System.IO; in the beginning of the file, you can now return to Unity and try pressing + button (which is now Plus More) to see how it works.

Now all what's left is to add actual wave creation logic to clickHandler:

private void clickHandler(object target) {
	var data = (WaveCreationParams)target;
	var index = list.serializedProperty.arraySize;
	list.serializedProperty.arraySize++;
	list.index = index;
	var element = list.serializedProperty.GetArrayElementAtIndex(index);
	element.FindPropertyRelative("Type").enumValueIndex = (int)data.Type;
	element.FindPropertyRelative("Count").intValue = 
    	data.Type == MobWave.WaveType.Boss ? 1 : 20;
	element.FindPropertyRelative("Prefab").objectReferenceValue = 
    	AssetDatabase.LoadAssetAtPath(data.Path, typeof(GameObject)) as GameObject;
	serializedObject.ApplyModifiedProperties();
}

When a menu item is clicked this method is called with the value object we specified earlier. This value object containing in data variable is used to set up properties of the newly created wave. To assing the right Prefab to the wave we are using AssetDatabase.LoadAssetAtPath(data.Path, typeof(GameObject)) method with the path we found in onAddDropdownCallback.

In conclusion

Of the all available callbacks we haven't touched only onChangedCallback and onReorderCallback because they are not really interesting. But you must know that they exist.

If you've been working with Unity for a long time you should know how hard it is to make a proper interface for a collection of things in Unity IDE. Especially when this wasn't in your time budget from the beginning. I've been using another implementation of ReorderableList by rotorz for a while. But now when we have an implementation from Unity Team there's no excuse not to use it.

If you want to find out how this list is implemented you can use ILSpy to decompile UnityEditor.dll which is (thankfully) not obfuscated or otherwise protected.

May the pretty lists be with you!

P.S. Alexei in comments proposed a solution to list item height problem which is described here: https://feedback.unity3d.com/suggestions/custom-element-size-in-reorderable-list
Code: http://pastebin.com/WhfRgcdC

Well, as you all know Unity team has recently released Unity version 4.5 which brought us (according to Unity's web site):

• Over 450 bug fixes,
• OpenGL ES 3.0,
• Shader workflow boost,
• Smooth and natural 2D physics and
• Sparse Textures.

While 450 bugs fixed sounds amazing, shaders compilation was indeed terribly slow, I don't really care about OpenGL ES 3.0 (since I got an old iPhone 4s) and Sparse Textures is a good feature to explore on modern desktop GPUs, what I want to tell you about are those features and bug fixes buried in the massive Release Notes which you have probably missed but they are indeed very important.

In no particular order.

Hierarchy Window sorting

New Hierarchy Window sorting - sorting of elements is now based on transform order instead of name.

This change alone breaks the naming convention of millions of developers. I myself used to name the empty object with controllers $ to make sure that it's always on the top of Hierarchy Panel. Now you can just drag GameObjects up and down manually.

SelectionBase attribute

Editor: Created SelectionBase attribute. When applied to a script, GameObjects with that script on will work the same as prefab roots for Scene View picking.

If you have an hierarchy of objects with geometry attached usually when you click one of them it gets selected.

If you remember Prefabs behave differently. If you click an object in prefab's hierarchy the root of this prefab is be selected instead. And now you can manually force this behavior using SelectionBase attribute.

[SelectionBase]
public class TheBase : MonoBehaviour {}

This may be useful when you think of an hierarchy of objects as single object and don't want to control its child objects. For example you have an object and a plane inside and it's important to move this root object instead of its child plane. This feature might help you always select the right object.

DecoratorDrawers

Editor: PropertyDrawers are now supplemented with DecoratorDrawers, which can be used for decorative elements in the Inspector such as spacing, headers, or notes.
Editor: Improved inspector customisation with [Tooltip] and [ContextMenuItem] script attributes.

PropertyDrawers are used to make your fields more pretty in the Editor. They are extremely easy to use. For example using just one annotation you can convert a float field into a smart range property.

[Range(0, 100)]
public float MyValue;

While PropertyDrawers modify the appearence of fields in the Editor, new DecoratorDrawers augment them with visual elements. Check out this code:

[Header("Hi there!")]
public string TheHeader = "Header!";
[Tooltip("This is THE VALUE!")]
[ContextMenuItem("Reset", "resetTheValue")]
public float TheValue = 42.0f;
[Space(50)]
public string TheString = "THE STRING";

private void resetTheValue()
{
    TheValue = 42;
}

And the animation where you can see what these annotations do.

Just a little trick to make your Editor interfaces better.

Scripts in DLLs

Scripting: Improved resolution of types that inherit from types in different user assemblies.

This is probably one of my favorites.

You see, prior to 4.5 if you had MyBaseClass : MonoBehaviour in MyBaseClass.dll and MyDerivedClass : MyBaseClass in MyDerivedClass.dll you couldn't use MyDerivedClass in your projects because Unity was unable to follow this MASSIVE inheritance chain and figure out that MyDerivedClass was a MonoBehaviour.

Thanks God this is now fixed.

Default parameters

Scripting: Fixed namespace detection for MonoBehaviors containing methods with default parameters.

This bug was one of those bugs stopping people from using specific language features. Now we can breath freely.

Saving to JPEG

Graphics: Added Texture2D.EncodeToJPG.

Many developers have been asking for a function to save to JPEG. Yes we had Texture2D.EncodeToPNG for a long time, but you know...

Anyway, the new method is also terribly slow. Encoding a 2048x2048 texture:

• Encoded to PNG in 0.4529677 seconds,
• Encoded to JPG in 0.1349338 seconds.

Now we know if we have Pro license

Scripting: Added UNITY_PRO_LICENSE define.

This will be useful for fellow plugin developers. Now we have an easy way to be sure that code we are writing targets right Editor version.

Serialization

Scripting: Add UnityEngine.ISerializationCallbackReceiver interface, to get a callback right before serialisation and right after deserialization.
Scripting: Structs with System.Serializable attribute can now be serialized. Also, fields of AnimationCurve[] and double[] now get serialised.

People have been asking for years for the ability to serialize structs. Now this code works and shows a list of structs:

public List<MyStruct> list = new List<MyStruct>();

[Serializable]
public struct MyStruct
{
    public int Value;
}

Being able to serialize arrays of AnimationCurve sometimes may be handy too.

But what really interesting is ISerializationCallbackReceiver interface. The docs say:

Interface to receive callbacks upon serialization and deserialization.

It seems that instead of wasting man-years on figuring out how to serialize Dictionaries they gave us an ability to manually specify what and how we want to be serialized. The example in the docs shows just that.

GameObject.GetComponentsInParent()

Scripting: Added GetComponentsInParent function.

It's good to know that now we have this. I haven't tested it yet but it must be a lot faster than enumerating manually through the parent chain.

Debugging DirectX 11 shaders

Documentation: Added docs on how to debug DirectX11 shaders with Visual Studio, look for 'SL-Debugging DirectX 11 Shaders with Visual Studio'.

The method described is not new but now we got a decent tutorial on how to debug dx11 shaders in Unity.

Windows Phone apps

I understand that nobody gives a damn about WP apps but I had to develop a couple simple ones for Nokia Lumia and I'm glad that Unity is evolving and I hope that it will be able to make this platform better.

There are a lot of added features and fixed bugs for Windows Phone target and it's good to know that I helped fixing some of them:

Start, Update and similar methods in scripts derived from generic base class are now properly invoked.
WP: Resolution will now be correctly detected on phones than have larger screen than 768x1280.
WP: Screen.dpi now returns physical device DPI, rather than 0.

o.O

Active scenes count properly displayed when more than 100 scenes are added to Build Settings window.

Damn, some people have huge projects...

Nice lists

And the last one is not even in the Release Notes. It's a little Editor class hiding in UnityEditorInternal namespace. It's called ReorderableList and it makes drawing lists in custom inspectors such an easy task. If you ever tried to make a pretty inspector for a List<> or Array field in Unity you know what a massive pain it is.

Here's a demo of ReorderableList class:

This is the code from the custom inspector used:

private ReorderableList list;

list = new ReorderableList(property.serializedObject, property.FindPropertyRelative("tagList"), true, true, true, true);
list.drawHeaderCallback += rect => GUI.Label(rect, label);
list.drawElementCallback += (rect, index, active, focused) =>
{
    rect.height = 16;
    rect.y += 2;
    EditorGUI.PropertyField(rect, 
        list.serializedProperty.GetArrayElementAtIndex(index), 
        GUIContent.none);
};

list.DoList(position);

This is the full example: TouchManagerEditor.cs

Interesting fact: there was already practically identical list implementation called ReorderableList which I've been using from time to time.

***

These are the features I found particularly interesting while browsing through Unity 4.5 Release Notes. It's always like a treasure hunt... you never know what you will find.

If for some reason you think that some other features/fixes deserve more attention feel free to post them in comments.

Let's assume that you need to set up Prolog for OS X. If you are still here let's continue.

After reading some book from 80s about Prolog I found that language to be interesting and I decided to write some simple things in it. But I had to install it somehow on my Mac preferably without any stupid virtual machines. So here's what I ended with.

• All crossplatform solutions are based on Eclipse, so first of all you need Eclipse. There are a lot of versions, but I chose the one with less stuff I don't need because I won't use anything related to Java development.
• The first plugin I tested was PDT which is too old and doesn't work with Eclipse 3.5, I downloaded 3.1 but haven't tested it because I got another plugin which works — ProDT. This is just what I need. From Downloads you should choose the smallest file.
• For ProDT to work you need SWI-Prolog — some kind of opensource Prolog.
• I'm not sure if SWI-Prolog requires MacPorts, but anyway I recommend you to install it. It's useful.
• Extract ProDT to eclipse/dropins/prodt/eclipse/plugins, run eclipse which installs it automatically.
• After that in ProDT preferences (Eclipse -> Preferences -> Prolog -> Compilers -> Swi Compiler) set compiler path which is at /opt/local/bin/swipl.
• Switch to Prolog view Window -> Show Perspective -> Other... -> Prolog.

That's it. Now you can test if it actually works:

yes(one).
yes(two).

Run and write in console:

yes(X).
x = one;
x = two.

So, should you use Playmaker in production? Short answer is:

Long answer follows.

Playmaker

Playmaker is a visual scripting tool for Unity. It has been a top-selling asset in the Asset Store for a couple of years.

Learning environment

I get invited to host Unity workshops from time to time. One of these workshops consisted of 6 lessons and the audience didn't know anything about programming. That's where I finally decided to try to build an entire game using Playmaker.

The game was really small with Unity physics doing most of the work, but anyway many small scripts to handle interactivity were needed. And here Playmaker worked really great.

The concept of states and actions appears to be very intuitive, so even people with near to no programming experience could "script" simple interactions very fast.

So, for teaching Unity I will definitely use Playmaker again.

State machines

Well, I'm a huge fan of state machines. I usually structure my code so I know exactly in which states all the modules of my application are. And every action is controlled from top to bottom in a hierarchy of simple state machines. This apporach keeps the code very simple and easy to follow and debug.

It seemed that Playmaker being a visual state machine framework would fit fine in my pipeline. But, oh God, how I was wrong.

Code, OOP and software architecture

If you are an experienced software engineer you know how important it is to structure your code right.

We all remember those days spent trying to debug a spaghetti mess of interlinked code promising to God to never be so lazy again if he helps us find why this monstrosity doesn't work.

Sooner or later you inevitably come to a set of good practices of software architecture and code structuring. If you do everything right and use a good IDE like Visual Studio which allows you to easily browse code and jump to lines where a function is defined or called, it's really easy to follow what's going on in your code and usually is not hard to figure out why something is not working.

The critical features here are:

• Ability to see where methods are called from,
• Transparent control hierarchy (i.e. a chain of command with no global events or variables),
• Right encapsulation with no external state exposed.

Playmaker violates all these statemens and adds even more ugly stuff.

Playmaker in production

Now I'm going to list all the problems I found in Playmaker I could remember while working on a real project. In no particular order.

If you know a good workaround for any of these problems feel free to post them in comments at the end of the article.

1. Playmaker breaks encapsulation

If you don't want to shoot yourself in a foot you absolutely shouldn't expose object's internal state to the world.

Well, Playmaker does just that. It completely breaks encapsulation.

Most likely you would have a script on the same object with Playmaker FSM which exposes API to control the object. This script does some work and makes the FSM to change state. It's a normal behavior but here you have state moved outside of the object, visible to everyone, state which can be modified by anything any time.

Even if you are an experieced developer and you understand possible consequences of this decision, believe me, you WILL be tempted to do the wrong thing and modify this state bypassing proper API calls. Young programmers will do this immediately if you give them any chance at all.

2. Playmaker makes it impossible to see control flow

Any action in any state can call any method or change a local or global variable. There's no way to find out what changes what except going through every state and every action by hand.

There's no Find Usages or Go to Definition like in any good IDE, if someone decides to bypass the API (and they will) you will have a very hard time trying to find out what really is happening there.

3. Playmaker is incompatible with git

Seriously, we had so much pain in the ass because of how Playmaker saves its graphs into Unity scene. It seems that it does this the most unmergeable way possible. And you don't even know that something was damaged during a merge right away. Beleive me or not it was happening a lot even if someone just moved some states around to make them look better...

4. Playmaker makes scripts more complicated

Playmaker was created to make coding simpler, right? Not really.

Playmaker makes small "code" simpler to write but large complicated code becomes a complete mess.

This is actually a problem of all visual languages. Believe me, I worked a lot with visual scripting environments.

In a visual language you connect nodes which do simple tasks, like adding two numbers or calling a method. And there's a threshold where you have to delete all your "visual" code and reimplement this logic as a node or an action in Playmaker terminology. Because visual "code" becomes too complicated very quickly.

Sooner or later you'll end up with this.

Which is MUCH harder to follow than code.

Of course, you can develop common practices to try to fix this mess. Like, having one action with major logic per state or design your action in some modular fashion. But you can't get rid of this problem completely especially when you have a set of actions which you probably can combine into a Frankenstein's monster to do what you want. Because the cost of making a new action (multiplied by laziness) is higher.

4.1 Passing data

Unlike dataflow visual languages where you pass modified data around, to pass something from one action to another you have to use variables. Which is (a) another huge layer of complexity and (b) makes one more huge hole in encapsulation.

So, instead of doing action2(action1("hi")); in code you have to (a) add one or more variables, (b) add variable support to both actions, (c) configure to use same variables on both instances of these actions. Which is adding a lot of unnecessary complexity.

4.2 Events on state change

It's surprising, but there's no way for a script to be notified when a FSM changes state. If you want to sync a FSM's state with something else you will have to put a special action in every state yourself. Which makes states even bigger.

5. Playmaker uses global variables and events

You probably know or at least heard that global variables and global events are evil. Usually it's wrong to say that something is 100% bad or 100% good because world is not black and white. There are ways to use global variables/singletons and global events/messages without driving yourself crazy.

But how global events and global variables are implemented in Playmaker is the same as giving you a loaded machine gun and aiming it to your foot.

Anything can dispatch an event or change a global variable, and any other object can react to this. And due to (2) you have no way of debugging this.

And because Playmaker encourages you to use global events and global variables, even if you are aware of the consequences, sooner or later you will start using them. And you'll regret about this decision at the end...

6. Playmaker makes state machines excessively complicated

This one might be my personal choice, but anyway these are my personal thoughts so I ought to list it too.

There are several ways to implement a state machine. Different implementations might be called a Mealy machine, or a Moore machine, or another way to combine current state and current input into action.

The thing is that Playmaker forces you to have all the logic in states. So, to execute something you have to change state. This gets even more complicated considering the execute in every frame flag which many actions have. Because in current system it's either a transition from a state to itself (while during this transition not all the actions get executed) or a piece of logic which executes without a transition. Both of these options break the execution model Playmaker offers.

What's more, if you want to add a constant logic for an event which behaves the same in most of the states you will have to add this logic to all states in Playmaker.

I think you can use several FSMs to deal with this problem but having several FSMs just adds even more complexity.

Another model (which I use in my code) would be to use states as filters what to do with incoming events. In this case you need much less states and all your event handlers will look like this:

private void EventHandler() {
	switch (currentState) {
    	case State.One:
    		// ignore
    		break;
    	case State.Two:
    		doSomeStuff();
    		break;
    	case State.Three:
    		doOtherStuff();
    		break;
	}
}

I don't have to change states when I want to execute some logic in response to an event. Also, I'm absolutely sure that this event will have no effect if current state is State.One.

Of course, you can have some logic executed right when state changes. Anyway, this abstraction of state machines allows to have less states and is easy to read in code.

Good stuff

But there are some good points. When I was trying to list good sides of Playmaker I came up only with two:

1. Visual representation of states and transitions,
2. Usually it's easy to see what is being done in a state.

I am an experienced software engineer and I can keep in mind most of the nested graphs of state machines in my app. But it's always better to have a visual representation.

One of my less experienced colleague told me that he really liked working with Playmaker, because he was able to see actual state graphs.

Of course, guess who was in charge of fixing all the mess Playmaker introduced with these shiny graphs... But he has a point. Visualizing control flow and state graphs does help.

As for individual states, if you structure and name all the actions right it's really easier to read what's going on in the state comparing to reading a bunch of unrelated methods in source code. But as I noticed this type of "coding" actively uses another part of your brain and keeps wasting brain power on how "code" looks instead of focusing on how it works.

Not that it's a completely bad thing but it easily drives you from what you need to do into some sort of "playing with fonts" procrastination.

Conclusion

First of all, I will never use Playmaker in my app again.

Second, there might be a better paradigm and a better way to use a visual state machine in Unity. The one which doesn't have all the flaws Playmaker has.

This is just another field for me to explore.

While making screenshots of old flash sites for TheFWA new site I noticed that a lot of them fail to start because of wrong flash player detection. They tell me that I do not have Flash MX player. Of course damn it I don't! Today is almost 2010 and flash player 10 rules the world. I decompiled one of flash detection SWFs and here we go:

if (getVersion().charAt(4) >= 6)

Do you see the problem here? Today all these SWFs think that I got flash player version 1 which is obviously too old to view the site.

I just started watching recorded sessions of Flex|360 and Adobe MAX 2008/2009. And it is fantastic how I see people dealing with same problems I was dealing last year and earlier this year. If only I have watched these videos earlier or attended these conferences... This could have saved me a lot of time. Yes, I found my own solutions, better or worse, but that was reinventing the wheel once again.

I am an active blogger and read a lot of blog posts on a daily basis. But nobody can read or know everything. Yet a lot of people simultaneously from opposite sides of the world are trying to solve same problems and come up with same brilliant ideas. They just don't know about each other...

That's why it is vitally important to be social. Internet is a great tool we must use. You should read blogs, you should watch recorded sessions from conferences you can't attend. You may not have a personal blog but you must be hungry for new information. I don't care if others find reading blogs a waste of time. Most of them are narrow minded people living in their own sandbox.

You must live on the edge of knowledge in your field, you must know what was done, what obstacles people faced in their projects. Learn on someone else's mistakes.

What's more, reading an article about something you found interesting but is not relevant right now is definitely not a waste of time. If you have a team of people who are information sponges you can do anything in a much more productive way. Any problem during development will be solved much faster, every decision will have much more probability to be right, because someone have read about another team facing same problem or that people say how bad that architecture rendered to be at the end. Someone might have attended a conference where he heard of an interesting framework which is ideal for your current needs.

You might have memorized only 3% of the whole article read or video watched, but you already know about the existence of a solution you might desperately need right now. You'll spend a couple of hours googling instead of weeks of development.

Conclusion

I like reading technical books. Last books I read were about human genome, swarm intelligence, artificial intelligence, loosing weight, prolog, plants and branching structures. They don't have much relation to what I am doing right now, I am just hungry for interesting stuff...

A newbie in ActionScript3 might wonder why there are 3 different values which mean "nothing". I'll try to explain the difference.

Something is null when it points to nothing. If you remember that by saying

var p: Point = new Point();

we create a reference (pointer) p to a position in memory which has the created Point object. This pointer is typed so can reference only objects of type Point. If we write

p = 42 as Point;

flash can't convert 42 to Point so p just points to nothing in memory thus it is null.

If we write something like

var i:int = (new Point()) as int;

i will be 0 because int variable is of so-called simple type and contains its value not points to some memory space.

But what about undefined? Remember that in ActionScript we can have dynamic classes and untyped variables. For example this is an untyped variable definition:

var untyped: *;

While it's not set it is undefined because it neither points to anything nor it contains a simple value. It is just not defined yet. All typed variables have default values which is usually null. Also we get undefined when referencing a non-existing property of a dynamic object.

trace({}.x); // empty Object
trace([][1]); // empty Array

both will trace undefined. This is quite interesting, because here if you don't understand the difference between null and undefined you can get unusual results. Let's check an example.

var o: Object = {x: null};
trace(o.x);
trace(!o.x);
trace(o.y);
trace(!o.y);

This will output:

null
true
undefined
true

x property exists in object o but it points to nothing, but y property doesn't exist at all. If you test something for existence using this approach you are missing the point. You should use === instead, because

null == undefined; // true
null === undefined; // false

Now what is NaN. NaN states for Not a Number. It's a value which a variable of type Number can hold meaning that it holds something which is not a number. This is how you can get NaN:

Number("hello");
0/0;
Math.sqrt(-1);

The only way you can check if your variable holds NaN is isNaN() global function. You can't say

something == NaN;

because comparing to NaN always results in false. Even

NaN == NaN

is false.

There's another value for Numbers you should know — Infinity. You can get it if you divide something by 0.

OK, let's do our final test.

private var undef: *;

trace({}.x); // undefined
trace(undef); // undefined
trace([][1]); // undefined
trace(Number("hello")); // NaN
trace(0/0); // NaN
trace(Math.sqrt(-1)); // NaN
trace(1/0); // Infinity
trace(NaN == undefined); // false
trace(NaN === undefined); // false
trace(null == undefined); // true
trace(null === undefined); // false
trace(NaN == NaN); // false
trace(NaN === NaN); // false
trace(null == null); // true
trace(null === null); // true
trace(undefined == undefined); // true
trace(undefined === undefined); // true

Update: some of the videos are no longer available, I found some of them on YouTube and added slides. If you know where these videos are now please post in comments.

Unity3D is great for indie developers. We have yet to build a large Unity project, but we’ve built a couple of small projects so far but during this process we did see Unity3D from the ugly side. It seems that the engine can do some things blazingly fast and easy but some other ones were clearly neglected during development. But that’s another post.

So, I’ve tried to find out how big teams work on large Unity projects if even we are struggling. But no luck.

Ones were mumbling about source control, separating control over scenes editing etc. That’s kind of obvious and shows that those people don’t have any experience at all.

But recently I watched all the videos from Unite 11 conference. I really wish I could visit it and talk to Unity gurus. But anyway, here are the videos I found useful. Videos where speakers share their experience on working in Unity3D as a team. The information which is practical and useful:

Unite 11: Scalable Game Development at Schell Games (PPT)

1. Unity tends to crash building a large project. That’s why they split the game into several projects: entry point project, assets projects, code project.
2. Entry point project is simple, contains minimum stuff to show loading screen or error screen. Loads asset bundles from asset projects and DLLs from code projects.
3. Content projects got their copy of DLLs, they are used to export assets to bundles and there are external tools to rebuild assets.
4. There’s no single source file in Unity projects.
5. That allows to build custom framework, use namespaces, custom compiler preprocessor and obfuscator (if needed).
6. But there are problems with this approach like some deeply derived from MonoBehavior classes not showing in Unity3D IDE, harder to debug, etc.
7. #if preprocessor instructions are used to exclude platform specific code.
8. Custom GUI with relative sizing and positioning of controls. Saved and loaded using ScriptableObjects.
9. A lot of external data handled by ScriptableObjects which are serializable, editable like Behaviors and not tied to a GameObject.

Unite 11: Postmortem – Smuggle Truck

1. ONE project to build for all platforms. I think the project is not large, so they don’t see Unity crash much.
2. There’s a Level Editor which was used by players to create levels which actually shipped with the release.
3. Asset Settings tool to configure assets importing parameters for every platform. For example, background textures could be half-size in iPhone builds to increase performance.
4. Platform Specific properties can be configured with special 1. Behaviors attached to objects. For example, you could specify object’s size depending on whether the project is compiled for iOS or PC.
5. Custom build process allows them to use the data from 3 and 4 to set needed properties and delete unused assets before the actual build. This ensures that assets from PC build will not go to iOS build increasing its size.
6. At the end of the presentation they advised to have 2 copies of the project for different build targets if you have a lot of assets. Because converting from PC formats to iOS formats takes a lot of time.

Update: recently they released Multiplatform Toolkit to the Asset Store.

Unite 11: Jagged Alliance Online Engineering for Large Web Player Game

1. Large games have different problems: automatic builds, light map baking which takes 4 days to complete.
2. Big monolithic project fails to build. (heh, been there done that)
3. The project is split in SEVERAL small projects: code libraries, asset project(s). This approach allows to share code between client and server. Unity3D .NET project uses 3.5 and can be referenced from 4.0 server code. Asset projects are compiled into assets bundles to be use with code.
4. Programmers don’t spend an hour a day waiting for assets to be imported.
5. Code projects are separate Visual Studio solutions kept outside of Unity3D Assets folder. It allows using namespaces (not for MonoBehaviors though). Also they use Unit Tests with modified SharpUnit framework. There are problems with built-in Unity3D classes.
6. Shared code between code projects and assets projects are separated in yet another project which is referenced by them as DLL libraries.
7. Separate VS projects are configured to build DLLs into Temp folder not to be loaded by Unity3D and causing names conflict with existing source files.
8. There’s an advanced automatic build system which executes light map baking and asset bundles exporting in parallel reducing average build time.

Unite 11: Creating a Browser-ready FPS MMO in Unity Slides

1. Yet again, nobody uses built-in Unity GUI system.
2. The game looks really cool q:
3. There’s a custom interface to build asset bundles.
4. They use ScriptableObjects which are saved to XML and later loaded from server.
5. Tools for artists is a key to success.

Unite 11: Intro to Editor Scripting, Unite 12: Advanced Editor Scripting, Unite 13: Advanced Editor Scripting — totally must see if you want to create your own editor tools. Describes how to create custom Behaviors inspectors, drawing dummies in 3D scene and even creating custom editor windows.

Unite 11: SHADOWGUN: Rendering Techniques and Optimization Challenges (PDF) — a lot of low-level details if you want to optimize your game for devices.

Conclusion

Now I have time to think what approach to use: single configurable project, many projects with source inside Unity3D Assets folder or many projects with DLLs in the final Unity3D project. At least this time I got the details.
If you want to improve your team workflow with Unity3D you must spend a day watching these videos one by one. There is a lot of interesting details and what to think about. There’s no silver bullet but there is real world experience which speakers gladly share with you.

Recently I found a great post where the author (using a script) ranked TED videos by the number of times they were mentioned in social services. And since TV series are getting more and more stupid I decided to start watching these videos. I’ve seen many great TED talks in the past and anyway videos people talk about the most shouldn’t be bad. So I decided to download all of them.

One would open that large XLS file from the site and start clicking links. It might seem easier to just watch one video from the list at a time than to write a script which visits URLs and downloads videos. But I wanted to upload all of them to my iPhone and watch/listen to them while on my way to work. So here’s the final script:

I uploaded the same script with data for TED videos (with rating >=5) and Gemfile to install required gems to GitHub. Some of the videos don’t have links to video files, so you have to watch them online.