Unity Project Review

As the single reader of this blog other than myself might know, I’m using Unity3D extensively in my career and at my current job.
We are so called ‘enterprise partner’ with Unity which comes with a number of perks like source code access to the editor code.
And I mean both the C# layer which is publicly hosted on GitHub and the private internal c++ source code.
It has been quite interesting to read the c++ code btw.

Another part of being a partner is having access to their ‘customer success plan’ described here.
I have to say that having direct support channels is also helpful. Especially when it comes to embedding Unity as an Android / iOS library into an existing application.
We’ve found lots and lots of quirks doing this integration.

Unity has been very supportive and helpful patching these issues.
Even to the point of delivering custom patched versions of older Unity3D versions because ‘one cannot simply upgrade Unity’ in the automotive industry.
Sometimes communication can be a bit bumpy and vague but I think we’ve (both parties) always managed to clear things up.
Sometimes that means hopping on a quick teams call to speed up the communication channels. Which is great.

Yet, by far my personal favorite perk is the ‘Unity Project Review’ which is outlined here.

In today’s blog I would like to dive into this project review concept and describe my experience with it. Spoiler alert, its pretty great.
At the time of writing I’ve been involved in 2 Unity Project Reviews personally. But I’ve studied and read the outcome of other reviews as well.

The Scope

The description on the official website states that the Unity Project Review is an “in-depth investigation into one (1) Project, wherein Unity will provide you with a support engineer to analyze the complete Project and look for opportunities to apply best practices in the areas of system design, optimization, stability and team workflow to enhance the performance, stability and maintainability of your Project.”

And I agree, it is exactly that. However..! From my experience I will say that you will get the most value from the project review when you define very clear objectives and outcomes of the review.

For example: If you are struggling with startup time of the application you should describe the pain-points ahead of time. Or, maybe you are struggling to setup an extensive CI/CD workflow for your application.
Or, you experience too many memory leaks, or huge GC spikes. Describe these situations… When do they occur? Maybe you already know the root cause but are uncertain how to solve it.

Another common problem is reducing shader compilation time and size, or doing profiling and analyzing memory captures. You can go totally crazy with these topics.

The point I’m trying to get across is that you should define a clear plan of what you want to achieve during the project review.
This way you can share your plan, ideally with source-code access to your project, ahead of time to the Unity support engineers.
It will allow them to better prepare for review itself. Communication will go smoother and you don’t need to reach consensus during the review about the scope and goals.

It will just save you a lot of time and thus you can spend the time of the review far more effectively.

The Services

The services defined on the webpage state a couple of things but importantly its good to remember that you cannot carry reviews over from one year to another.
Meaning; if you haven’t done a review during year 1 of your support plan, you cannot carry it over to year 2 and do 2 review that year. This is pretty basic stuff.

What’s most important is the fact that the Project Review is held On-Site. This is really great since, first of all, it’s in person so communication channels are short, and second you are in a trusted environment.

And I mean trusted environment in the sense of NDA binding. You are closer to test rigs, have colleagues nearby when questions need to be answered and you basically have access to the know-how of these Unity engineers for three days.

I’ve asked my fair share of questions, unrelated to the project review, to fix performance issues or open bug reports.

The services also state that Unity will deliver the final report 10 business days after the event. On the surface this seems very nice but I think the time should be negotiable.

Why? Well, 10 days is rather short for solving difficult problems or doing root cause analysis. I think the minimum response time should be 10 days, but if negotiated differently, that time should be extendable.

This will avoid getting surface level answers when in reality you just really needed in-depth analysis and answers.
We’ve had a couple of such cases in the reviews we’ve done. In the end the Unity devs needed to follow-up on these questions.
Which is fine yet I think they would have given detailed answers when they had more time in the first place.

Your Obligations

There’s a couple of things to take care of when you decide to host a project review. Again, it’s on-site on one of your locations, not Unity’s.
So you will need to provide the correct address information etc. Date and time is also very important of course and when the review is cancelled or rescheduled for whatever reason you will need to communicate that at least 14 days before the due date.

If you do not, you will forfeit your rights to the review. Kind of harch but understandable. Since its on-site it takes quite a bit of planning from both ends.
So keep that in mind. Reschedule or cancel in due time!

Another important aspect is to appoint a dedicated contact during the review. It’s very common practice to need some badge or RFID card to enter the facility, departments or individual rooms.
I’ve experienced many times to be locked out of the area the project review was being held. Mostly for getting coffee of course, or nature calls.

Nonetheless, be sure to have someone on-site to help the Unity agents navigate on the mesh.

The obligations also state that you need to provide a dedicated spot to work with a pre-configured machine but I think this can be taken with a grain of salt.

Depending on the objective of the review, you might not even need a dedicated desk or it may simply not be possible.
For example; In the automotive branch I work in there are specific test rigs and hardware that are setup and you cannot simply move them around.

Ownership of Materials

The ownership of materials basically says that any output from the review like the documents or other generated artefacts remain IP of Unity.

You can use the materials in the context of your company but you cannot share them. This seems pretty logical to me as the review document can describe some very detailed internals of the Unity Engine source code.

Other than that, there’s not much in this section.

Conclusion

I wanted to write a quick little blog about the Unity Project Review since my personal experience with it has been very positive.
We’ve received answers on quite a few difficult questions. Additionally, having access to these expert unity engine engineers is really useful for all kinds of other questions as well.
We received answers on all kinds of side quests while the review was happening. We improved performance of processes and fixed some bugs that were not initially part of the review.

Just having them around as a sparring partner allowed for increased momentum to get difficult tasks done. Really cool!

So that’s about it. Whoever reads this (if any :D), let me know your experience with the Unity Project Review. Do you have the same experience? Have any more tips or tricks? I would like to know.
Cya 😉