Tuesday, October 27, 2015

Diving Deeper - Unity Platform Graphics API Selection / Defaults

Sometimes we get so used to our daily tasks that we overlook values staring us right in the face. I've had people ask me at times 'what does this setting do' only to say 'hmm, not sure. I forgot it existed'. I want to start exploring some of these. Today we're going to be looking at this interesting but rarely used or known settings for "Auto Graphics Api for Windows" - or Linux if you have a long beard. I kid I kid :)  Anyways, note that I'm in the Player Settings for a Windows Standalone build (ie file-build settings-player settings with the PC platform selected in the build dialog)

These settings tell Unity to select the available graphics api in its own selection order. We can simply override them by unchecking the checkbox and then we're shown the default platform list.

The results are pretty cool. I was curious if DirectX or OpenGL would show up for each platform, and they didn't which makes sense when you look at the output. Metal for iOS, XBoxOne for Xbox (as it contains a modified version of DirectX for its usage) and so on.

I wrote a quick script to dump these out for us

As always, I hope you learned something from this. Enjoy :)

Sunday, October 18, 2015

Stop Visual Studio from complaining about inconsistent line endings when working with Unity .cs files

If you are like me, you probably don't like the constant popup dialogs from Visual Studio and MonoDevelop on the inconsistent line endings. You may not have any idea what I'm talking about but constantly see this in Visual Studio while working with your Unity .cs files

First - what on earth are inconsistent line endings? Let's look at what happens when you press ENTER on a PC based system vs a Unix based OS like OSX. A PC writes a CR/LF (carriage return / line feed) pair. A LF is '\n' or if you like hex 0x0A or 10 in decimal. A CR is '\r', 0x0D, 13 respectively.  For you c/c++/c# programmers out there you've probably seen some string "Hello World\n" or "Hello World\r\n" - also noting we have a LF and CR/LF

Let's take the following text....

See cat run
See sharp

Specifically if you look in a Hex Editor, the bytes in the file look like this on PC (note the highlight 0D 0A)

and like this on a Mac (note the missing 0D)

Why does this happen with Unity and Visual Studio? When Unity creates a C# file, it creates it by default with LF only as shown here.

Visual Studio will open this up without a problem and without notifying you of anything. You aren't mixing CR/LF with your LF. Now you go ahead and paste some code into here, or use some existing code snippets, or format the document, or rely on some auto-complete/formatting features and they may stick in CR/LF into this doc (as you are editing on a pc).  Now you have a file with LF and CR/LF mixed in it. It's inconsistent, hence you get a dialog box like the first image shown above Visual Studio loads that file.

Also note that if you do tell Visual Studio to normalize the line endings (ie clicking yes in that first dialog) it will fix this issue, but for this file only.

We have another product called Visual Studio Code (the free cross platform code editor/debugger) which actually just has a little drop down to select line endings and doesn't prompt you either as its a cross platform code editor. Visual Studio (a very different product) on the other hand is a PC based only full-featured IDE and expects PC based line endings but of course _can_ work with either CR/LF, you just have to tell it not to warn you. It thinks its doing you a favor (some third party tools over the years actually get messed up by mixed line endings, so its generally a good idea to have consistent line endings in your project).

The fix

Aha. At last. The big reveal. The big secret orphan annie ovaltine decoder ring thingy reveal (our ending is a bit better but for those that have no idea what I'm talking about check out this video clip here). The fix is actually super simple. Visual Studio has a feature called Quick Launch in the upper right hand corner. Simply search for "line" as shown below, select "Environment->Documents (Change line ending settings)" and UNCHECK "Check for consistent line endings on load". Voila. Annoyance resolved. Both the Mono and .NET C# compilers will handle mixed line endings just fine, so there's no problem here with doing this. Btw - if you are using a PC and aren't using my free "Right click to open folder as Unity project" registry script, check out my blog post on this. Enjoy!

Thursday, October 1, 2015

Some awesome learning resources for Unity - more to come too!

Heya all, it's been a few months since I've been here.

We had baby #3 in December and took a lot of the summer off to enjoy some time with this lil guy (and the rest of the fam of course)

So now I'm back at it with tons of content and about 30 draft blog posts queued up needing completion :) I'm a big supporter of the Unity game dev community and co-run the Orange County CA Unity Meetup so join us if you are in SoCal!

The below are some learning resources I've done or a colleague, so check them out and I hope it gets you started. I have an awesome 2D lab coming shortly as well - stay tuned!

Cross-Platform Game Development with Visual Studio Tools for Unity

Level Up – Game Development Interview with Adam Tuliper

The awesome artist Matt Newman, Unity Evangelist Mark Schoennagel and myself teamed up for this one recently
MVA Course - Building Windows 10 Games with Unity 5

Build 2015 - Building Universal Windows Games with Unity 

Game Developers: Get the Most Out of Windows 10 

GDC 2014 - Carl Callewaert from Unity and myself.
Note this targeted Windows 8, builds are slightly different for Windows 10 but the overall process is the same.
Your Unity Game in More Hands - How to Build for Windows and Windows Phone (Presented by Microsoft)

Build 2014 - Building Your First Windows Game with Unity 

Developing Your First Game with Unity and C# 

Developing Your First Game with Unity and C#, Part 2

Developing Your First Game with Unity and C# Part 3

Developing Your First Game with Unity and C#, Part 4 

Developing 2D & 3D Games with Unity for Windows 

Porting Unity Games to Windows Store and Windows Phone (this may be getting a refresh soon for new Win10 content although its a similar process)

A couple of our open source repositories for Unity Games (the lab mentioned will be opening up shortly, need to clean a couple things up)


Tuesday, June 9, 2015

Open Unity 5 project with right-click on folder!

I wrote this little reg file because I was tired of navigating to folders to open them.
Gone are the days of having to go through all the work (tongue in cheek) of opening Unity, navigating to a folder. Now with this registry file, you simply right click on a folder and Open in Unity. If you are using a prior version of Unity (4 or prior) note that your folder will be c:\program files(x86) not c:\program files.

Download this and save it as UnityRightClick.reg (I'll typically save it into notepad and rename the text document). To import it into your registry double click on the file. Note that if you are using Windows and don't have it setup to view your file extensions, you may be trying to execute a text file, not a registry file. Ensure your file ends in .reg and not .txt so Windows will iport this into your registry.

BTW if you are using Unity on Windows (as 88% of people do!) ensure you check out the FREE Visual Studio Tools for Unity

Tuesday, April 15, 2014

VSLive Chicago - Unity and WinJS

I’ll be speaking at Visual Studio Live!, May 5-8 in Chicago, IL http://bit.ly/CHSPK27_ Surrounded by your fellow industry professionals, Visual Studio Live! provides you with immediately usable training and education that will keep you relevant in the workforce.

I’ll be presenting the following sessions:

Developing Awesome 3D Applications with Unity and C#/JavaScript
Windows 8 HTML/JS Apps for the ASP.NET Developer

SPECIAL OFFER: As a speaker, I can extend $400 savings on the 4-day package. Register here: http://bit.ly/CHSPK27_

Amplify your knowledge at Visual Studio Live! Chicago — bring the issues that keep you up at night and prepare to leave this event with the answers, guidance and training you need.  Register now: http://bit.ly/CHSPK27_Reg

Hope to see you there!!!

Saturday, April 5, 2014

Why and how to Port your Unity game to Windows and Windows Phone

This post is part of 3 week series giving current and aspiring game devs the tools, resources, and advice they need to get started building for Windows. Check out the overview of the series to find what you need. For additional resources to build your app check out AppBuilder.

If you are an existing Unity developer, please ensure you check out our current offer here where you can get FREE STUFF and a potential for store promotion .

Porting your game to Windows 

Why would you want to do that?

Let’s start this off asking the most important question. Why?
As an Indie game developer myself I fully believe in today’s economy, developers should look at building for multiple platforms. There comes a point though where you can feasibly only support so many platforms given your own resources.

Windows Phone 8 is the strong third phone platform globally. With that said, Window Phone is currently growing faster than the phone market, and as of the latest figures is beating iPhone sales in 24 countries including India and Mexico, and is #2 in 10+ countries. There are more than 14 million downloads a day of apps on the phone alone. That’s nothing to shake a stick at.  The Lumia 520 512 MB phone has sold more than any other Android phone – EVER. Again, not too shabby!

Windows Store applications run on the Windows 8 platform, not the phone which targets 3000+ different devices from hand held small tablets, larger tablets, laptops of all sizes, and of course desktop systems as well. Some folks new to the platform think this means only tablets, like a Microsoft Surface tablet. That’s not the case. Windows 8 runs on many device types as listed above. Every one of them can run a Windows Store app on it.

There is an ever so slightly different build and submission process for Windows 8 apps (ie Windows Store apps) than Windows Phone even though they share a lot of the same common features. We just announced Universal apps at our //build conference being the first platform to be able to take a single code base and go from phone to tablet to desktop to Xbox. Windows 8 in addition has sold over 200 million licenses. Each of those instances by default have access to the Windows Store on them, the marketplace to download and install applications.

With a fairly easy export between platforms, why not target another large ecosystem that isn’t yet oversaturated with apps? There are over 400K apps between Windows Phone and Windows 8. Not a bad number, but definitely not oversaturated. There’s still plenty of room for you to bring your apps on over and be effective. Don’t take my word for it though:
Pat Toulouse, President and Founder of RatRod Studio
“The process of porting our games to Windows and Windows Phone was very straight forward. Since then, it has helped us extend our reach by generating over 5 million downloads within the past 6 months. And this continues to grow rapidly”.
Magma Mobile’s CEO Nicolas Sorel: first 1,000,000 downloads in 2 ½ months of being in the Windows Phone Store, and had 1,000,000 additional downloads in the last 30 days.”

So.. what’s required?

  • Unity (I recommend the latest version. There are important Windows related changes in every build)
  • Developer account to publish to the stores available here
  • Windows 8 / 8.1 (Free trial http://technet.microsoft.com/en-us/evalcenter/hh699156.aspx)
    • Windows 8 is freely upgradable to Windows 8.1
    • If you are on a mac see these links for getting Windows 8 running on it. You can either use boot camp or install it as a virtual machine running inside of OSX. For some common instructions here see
  • Visual Studio (Retail or the free Express edition)
      • If you have the retail version of Visual Studio 2013, you are potentially all set. You may need the Windows Phone 8 SDK installed however and that is available here
      • If you want to dev for Windows Phone 8, here’s the free version
      • If you want to dev for Windows Store (Windows 8) here’s free the version
We have an awesome program for startups called BizSpark. It gives startups free software including Windows, Office, Visual Studio, and access to the Windows / Windows Phone Store - for free. Check it out at www.microsoft.com/bizspark. Note that you can download 90 day trials of Windows 8 as well to do testing on if you need a quick way to get up and running on Windows.

Coming from other platforms

There’s something to be aware of when you’ve been used to working on other platforms. Typically when you run your game on for ex. ios / android, the Mono framework is used. Your app is compiled against that framework as .NET is not natively supported  on those platforms. Mono in the case of ios uses AOT (ahead of time) compilation because of ios restrictions preventing JIT (just-in-time) compiled code. As such, your game is developed with Mono which is what the Unity Editor runs, and your game is deployed and runs.

Enter in now .NET. Mono was essentially based off of Microsoft’s .NET. As such most of the api is cross compatible but Windows Phone 8 and Windows 8 share a common kernel between them and support a newer API. Some objects were dropped along the way and new ones added. You’ll find things like Hashtable & ArrayList to be deprecated on these system’s apis. This created a bit of a problem in the past as a lot of Unity C# code referenced these collections. When Unity would call .NET to compile the code, exceptions would be thrown over the missing collections.

As of Unity 4.3, UnityScript (Javascript) is now supported as it previously didn’t created compliant .NET code for WP8 and W8, but it does now. As of Unity 4.3.3 however, Unity has now added in a WinRtLegacy.dll into your builds. This includes a lot of the missing classes that caused issues before in your builds and UnityScript is supported as well. In other words, the support is now awesome to easily target Window Phone and Windows Store.

Let's get to porting!

unity to windows
The basics of porting are pretty simple:
  1. Switch platform in Unity
  2. Set player settings (images, icons, etc)
  3. Build from Unity which creates a Visual Studio solution
  4. Open solution in Visual Studio
  5. Test the project and deploy to devices or local system (Note debug builds are slow, master builds are fastest more on this below)
  6. Upload to the Windows Store and Windows Phone Store

Switch Platform in Unity

Expect on any platform to have some issues because of platform differences or potentially calls you make via plugins on one platform that another platform won’t support. The typical way in Unity code to handle this is to include a preprocessor directive to separate out your code.

When you switch your build settings to target another platform, you cause a variable that represents your platform to be true. For example, if in Unity you set Windows Store Apps to be the current platform by clicking on “Switch Platform”, behind the scenes the value of UNITY_METRO will become true. As is typically a safe bet in Unity, this code you generally run outside of the Unity Editor, hence the second part of the statement: && !UNITY_EDITOR although you surely could test this code out in the editor if the scenario fits.

For a listing of the variable names that you can reference see here
Windows Store Build

The three important Windows ones (to me) are
Precompile Constant True when platform is
UNITY_METRO Windows Store (Windows 8)
UNITY_WP8 Windows Phone 8
UNITY_WINRT Either of the above
An example of usage is:

     //Any platform specific code here

If you have platform specific libraries in your /Assets/Plugins folder, then you likely this will be compiled using Mono and must be .NET 3.5 compatible, this is a general Unity rule. If you have any libraries in /Plugins/WP8 or /Plugins/Metro, those will be swapped out at compile time. This is how the Unity plugin system works. For more information on writing a plugin for Unity & Windows Phone see here.

Setting player (platform) settings & building your project

In Unity click on the Player Settings icon from your Build settings.
Player Settings
Under your player settings there are a few important things to note.

On future builds, Unity will only overwrite the /data folder in the project that was generated. Any changes you make _in the player settings_ after you have already clicked Build in Unity and generated your solution/project, will not be overwritten in the visual studio project. For example, if you build your project from Unity, and then decide later to change the project name in Unity for your Windows Store build (in your player settings), Unity will not overwrite your project it created already. If you haven’t made any custom changes to your Visual Studio project (see my video link below from //build 2014 if you are interested in that) then you could simply delete your build project folder and have Unity recreate it. The other option if you don’t want to remove your project is you manually make the changes in both Unity and in your Visual Studio project.

Windows Store (Win8) Typical Player Settings

windows store icon
  • If you need to access the internet OR profile your app (which requires network access), you will need to check off the Internet Client capability as your app cannot communicate with a network without it. If you check this off, you MUST set a privacy policy URL when you are submitting your app to the store or you will get rejected. If your application does not communication with the Internet, I’d recommend ensuring this isn’t checked off (and it is not set by default) so you won’t need a privacy policy url. Note that the store submission process won’t force you to set a url during your submission process, so it’s something you need to know to add if you require access to the internet from your application directly. If you use a third party plugin that uses Internet access for ads or leaderboards, then you will require this capability.
  • Ensure your project name doesn’t start with a number or an underscore, as this is not a valid app name. You can fix this once your Visual Studio project is created though in your package.appxmanifest file if by chance you’ve missed this. You’ll actually see a red X when you open that file to show you where you need to change it.

  • There are quite a few settings you can have for a Windows Store application. Most of the defaults will serve you well but you’ll quickly notice under Publishing Settings there are many images you can set. Why so many images? Well – you can have an image show up as a small icon in your Windows program list (30x30), a larger icon if pinned to the start screen (150x150 for a medium tile, 310x150 for a wide tile) , a splash screen (620x300), an image to show in the Windows Store (50x50). Unity will show you the sizes required. I wrote a basic utility to resize a square image and create several output images by simply dragging and dropping. You can see a demo of that in the //build video linked at the bottom of this post and the url is http://aka.ms/wsip. There are also more icon resources listed at the bottom.
player images windows store

Windows Phone Typical Player Settings

windows phone icon
  • As of now, you cannot set the Windows Phone icon in Unity. You must do this in your Visual Studio solution inside of the /Properties/WMAppManifest.xml file.

  • You can force the orientation in Unity by setting Default Orientation as shown here

Creating the build

You’ll notice in the build settings there are several build options. Which one to choose?
With Visual Studio 2013, you develop for Windows 8.1. Windows 8 folks cannot run a Windows 8.1 app. To target both you can just compile for Windows 8. not everyone has upgraded yet to it’s not a bad idea to target both.
You can compile but are limited in some modifications of a Windows 8 project in Visual Studio 2013. Only a Windows 8.1 project in VS 2013 has no restrictions. However Visual Studio will prompt you to retarget a Windows 8 project to Windows 8.1 when you first open it or you can right click on your project and select “Retarget to Windows 8.1” in Visual Studio as well. You may ask ‘then what can I manage a Windows 8 (not 8.1) project with?” and the answer is Visual Studio 2012-> Windows 8 and Visual Studio 2013->Windows 8.1, although as I mentioned you can compile and make some changes to a Windows 8 project in Visual Studio 2013.

Once you have set your player settings, simply click the build button in the build settings window. You’ll be prompted for a folder to select. I prefer to typically create a folder called “Builds” that will contain all of my platform build projects and I can then source code control each version relatively easily. Unity will then create a Visual Studio solution and a project file.
A Visual Studio solution file is not much more than a listing of one or more projects your solution will contain. For example, I can have a solution that contains projects for Windows 8, Windows Phone 8, XBox, and other code projects I want to use, it surely isn’t limited to just one project at a time that you can have open in Visual Studio.

Open project in Visual Studio

Now that the project has been created, Unity will open the folder in Explorer that contains your build’s folder. Go into your build folder and look for the solution file and open it up. Visual Studio should open up. If you get prompted for the version, ensure you select which version you are trying to open it in – Visual Studio Express for Windows Phone if you are trying to use that build of course.


Compile and Test the project

The first thing to notice when Visual Studio opens if what type of build you are currently going to create. The default for both Windows Store and Windows Phone are “Debug” builds. There are actually three build types, three platform (processor) types, and you may or may not use every one. On top of that there are several different places you can run your build – locally, on a device, on a simulator, on an emulator, even on a remote networked machine. Let’s see what all the options are used for:

Build Types

Debug – Contains un-optimized code full of debug symbols and typically has a much slower frame rate, on the flip side it contains potentially crucial debugging information. If your game seems to run slow, the first thing is to always note you may be testing a debug build. I’ve seen this countless times and once you change to a release or master build, the problem disappears.

Release – This build contains optimized code but still supports the Unity Profiler so there is still a performance hit, although significantly different. Contrary to typical .NET applications, this is NOT the build you will use to send to the stores.

Master – This is the completely optimized game. There is no profiler support nor is there debug information. This is the build to send to the store. There can be only one Smile
Platform Types

Choosing these will change which files get included into your build and how your build is compiled. If you select ARM, the Unity native code player files for ARM are included in the build. If you select x86, the Unity native code player files for x86 are included.
ARM – Only choose this if you are creating a build to run on a system that is ARM based. Let’s talk about both project types that use this for a moment. It’s very important to understand the use cases.
Windows Store projects – You only choose ARM in two cases. First is if you are your builds to upload to the store for a small subset of Windows 8 devices – those running on ARM. Most Windows 8 devices run x86 processors so you typically want the x86 build. You should actually create both builds to send to the store – ARM & x86. ARM is the default build type when you first open your project. Note that for local testing you will _always_ choose x86 – not x64, not ARM unless you are deploying right then to a tablet for testing that you know is an ARM based tablet (there are only a few models that are ARM based). The first time you load your project, change this setting to x86 so you can test locally.
Windows Phone 8 projects– You want an ARM build ONLY if you are creating a build right now to upload to the store or about to deploy to a phone for testing. If you are wanting to only run it in the emulator instead, you would actually want an x86 build not an ARM build.
x86 – You will choose this when
Windows Store projects – You want to create a build to run on your development system, submit a build to the store that will run on the vast majority of Windows 8 devices (you should create a build for ARM and also x86 for that situation to make sure you can deploy to every single Windows 8 device type)
Windows Phone 8 projects – Only when you are building to run in the emulator. There are no other times you would select x86 for a Windows Phone build.
x64 – As of this point, you will not use this platform type – at all. Unity does not make a 64 bit player for Windows phone or Windows Store.

Check out the //build video at the end for how you can debug Unity code in Visual Studio. You can’t do this in development without a third party plugin (UnityVS – well worth it - available here) but you can do this after you’ve built your solution from Unity out to Visual Studio by adding another project to your solution. The file to add is Assembly-CSharp-vs.csproj and this is a file that Unity creates for you.


Upload to the Windows Store and Windows Phone Store

These steps are pretty easy, and it's the last steps to get your game in even more hands. There are specific certification requirements for each store and you can help meet those requirements by reading the following links but also running the test kits on your application.

Windows Store

Submitting your app
App Submission Checklist

The process in short is build your package, test it, submit it.

Some things to be aware of:

  • You should support touch & keyboard/mouse unless you note otherwise as noted in section 6.13.4
    • 6.13.4 If your app doesn’t fully support touch input and fully support keyboard and mouse input, you must disclose that in the description elements of the app
  • If your application communicates with the Internet in any way, even through a third party ad sdk, you will need to specify a privacy policy url when you are submitting your app to the store. This will not be required on submission, so note you must add it. A privacy policy can easily be generated and there are easy ways to set this up for free. See Jim's great post here.

The process

Go to the following menu. In Visual Studio Express use the root "Store" menu instead of the Project menu as shown here for Visual Studio Ultimate Edition. If this menu doesn't have the items active, ensure you have your current project highlighted (and file in it) inside of the Solution Explorer window of Visual Studio. If you have the Solution file itself highlighted (the first item in the tree typically on the right) the menu options won't be active. You will be prompted then to login with your Microsoft account (see requirements section up top for a link to register for your dev center account). This will query the developer center for your existing apps and also allow you to specify a name for an app you can reserve for up to a year before you publish.

Specify a build location for your files. Ensure you check of BOTH x86 and ARM as is shown below. This is because you should support both platform types.

Once done, you can now test your application. Click on Launch Windows App Certification Kit. While passing this doesn't guarantee approval, it does run a lot of the same checks that are run on the store side. Also click on the "Output Location" link shown below to open the folder with the files you will need to upload to the store. You can run the test kit any time by searching for "cert" on your systems (press the windows key and type cert on the start screen).

Note the opened folder below and the two .appxupload files. These are the files that will need to be uploaded to the store.

You will also need screenshots to send to the store. These are accessible in the Project->Store->Capture Screenshots menu item. This will launch the Simulator on your local machine so you can grab the screenshots. Note that this will change your project startup location from "Local Machine" to "Simulator". If you want to continue to test locally, make sure you change this back to Local Machine.

You are all ready to upload your files. Go to Project->Store->Upload App Packages and you can go through each step. For more details on that process see Submitting your app.

Windows Phone Store

This process is a little shorter. You can run the tests for the phone project first via the Project->Open Store Test Kit menu option.  First you'll want to create your app package by ensuring you have the proper build settings. Once that is set simply go to the Build->Build Solution menu.

 Make sure you have specified an icon outside of the default Unity icon. This is in the WMAppManifest.xml file as shown below

Open the folder your project is in (you can right click on your project and select "Open in file explorer"). Once the folder opens simply type .xap in the search window in the upper right hand corner. This will search your folder for the .xap file you need to upload. Note that you only need the ARM version, NOT the x86 as that was just for the emulator.

Go to http://dev.windowsphone.com and click submit to begin the process, this is a shorter process than the Windows Store. When prompted, you'll upload the file noted above.

That's all there is to it! If you have any questions please contact me at microsoft.com with the first part intentionally separated of my email address of adamt :) Enjoy!
Unity’s site for Windows
Unity & Windows Porting Guidance
//build 2014 conference video - Building your first Windows game with Unity
Choosing your app images
Guidelines for tlies and badges

Wednesday, February 26, 2014

Continually rotate an object in Unity

In games it’s a very common task to rotate/spin an object continually, such as a coin, treasure box, health pack, weapons, etc. In Unity this is extremely simple. As with anything, there are multiple ways of doing it ex code or a particle system, but if we wan’t a quick script to do it, simply assign this script to your GameObject. Again, there are better ways. The quickest way may even be to just create a new animation, set a keyframe at 0 seconds, move to 1 second and rotate the object to 360 degrees and a new keyframe will be logged. From a performance standpoint, thats typically the best _but_ this script below can by dynamically applied to any object.
    private int _rotationSpeed = 90; //degrees per second = 4 seconds for a revolution
    void Update()
        //Since deltaTime is the elapsed time since the last frame, 
        //let’s assume its one second. 1 * 90 = 90 degrees per second. 
        //Simple, right? Rotate’s parameters is (x,y,z, coordinate system)
        transform.Rotate(0, _rotationSpeed * Time.deltaTime, 0, Space.World);
Voila - A spinning object!

There is however a basic optimization we can do here. Even though it seems that this is pretty simple, we can cache our transform. This prevents having to cross over from the 'managed' type of code that c#/mono/.net provides across boundaries into the native code from the c++ based engine that Unity wrote. This type of transition is slow so we can optimize it a little bit as follows by getting a reference to it upon start which is then stored in our c# code. We can then access it without having to do an extra hop into the native c++ code that the Unity engine runs on.
    private int _rotationSpeed = 90; //degrees per second = 4 seconds for a revolution
    private Transform _transform;
    void Start()
     //cache the transform in our managed code side
      _transform = transform;
    void Update()
        //Since deltaTime is the elapsed time since the last frame, 
        //let’s assume its one second. 1 * 90 = 90 degrees per second. 
        //Simple, right? Rotate’s parameters is (x,y,z, coordinate system)
        _transform.Rotate(0, _rotationSpeed * Time.deltaTime, 0, Space.World);
treasure spin