A lot is happening at Unity this year, and we’re excited to share some of the highlights. So grab your favorite beverage and dive into this post to learn about our recently shared roadmaps on core Unity technology and game-changing offerings for live content, as well as the upcoming Unite Now digital programming series. Unity […]

The post Unity 2020 roadmap: Recapping the tech and solutions coming this year appeared first on Unity Technologies Blog.

We launched Live Help so that anyone – whether a beginner or an advanced Unity user – could get help with Unity on demand. Live Help lets you connect with an expert one-on-one to learn about any given topic. Have you ever taken guitar lessons? Piano lessons? How about game development lessons? No? Well now’s […]

The post Introducing a new way for you to connect 1:1 with Unity community experts appeared first on Unity Technologies Blog.

From its roots in gaming, real-time 3D’s impact now extends across dozens of industries. A new study sheds light on the state of adoption of this technology and how it’s changing the way products and buildings are created, built, monetized, and operated. Just a few years ago, real-time 3D (RT3D) technology was most commonly found […]

The post How real-time 3D (RT3D) experiences are transforming global industries appeared first on Unity Technologies Blog.

Introducing Unite Now, a digital programming series of talks, demos, Q&As and stories – all available on your favorite device. For you. For all. Live content to keep you on your game With the postponement of events like the Game Developers Conference, we don’t know when we’ll next get to see you in person. But […]

The post We’re bringing Unity to you: Unite Now starts April 14 appeared first on Unity Technologies Blog.

We are in a truly unique and challenging time, one where coronavirus (COVID-19) is impacting every citizen, country, and culture worldwide. We’re learning from governments that the most important tool we have to help reduce the global death toll from COVID-19 is physical distancing. From California and Copenhagen to Munich, Mumbai and more, state officials […]

The post Unity supports the World Health Organization’s #PlayApartTogether campaign appeared first on Unity Technologies Blog.

Unity is fortunate to be a part of a global community of creators and developers who have the skills and expertise to drive real change in our world with new technologies. Call for Code Global Challenge is the largest annual tech competition focused on open-source collaboration. It brings together developers from around the world to […]

The post 2020 Call for Code: How creators can help tackle climate change and COVID-19 appeared first on Unity Technologies Blog.

New Unity Reflect release features plug-ins for SketchUp and Rhino, an Android Viewer, compatibility with Unity 2019.3, bug fixes, and other improvements. Today, 60% of all augmented reality (AR) and virtual reality (VR) content is powered by Unity. We launched Unity Reflect to bring those real-time 3D experiences in VR and AR to the architecture, […]

The post SketchUp and Rhino plug-ins now available for Unity Reflect appeared first on Unity Technologies Blog.

We invited Daniel Keßelheim and Sebastian Rigling of Daimler Protics to share about the experiences they create with Unity as their development tool of choice. Learn how they implemented mixed reality across key stages of the lifecycle of Mercedes-Benz vehicles. Daimler Protics shapes digital reality for Daimler AG, one of the world’s largest automakers. Its […]

The post How Daimler uses Unity across its automotive lifecycle appeared first on Unity Technologies Blog.

Yak Shaving - Swift Edition

At the TensorFlow summit last year, I caught up with Chris Lattner who was at the time working on Swift for TensorFlow - we ended up talking about concurrency and what he had in mind for Swift.

I recognized some of the actor ideas to be similar to those from the Pony language which I had learned about just a year before on a trip to Microsoft Research in the UK. Of course, I pointed out that Pony had some capabilities that languages like C# and Swift lacked and that anyone could just poke at data that did not belong to them without doing too much work and the whole thing would fall apart.

For example, if you build something like this in C#:

class Chart {
  float [] points;
  public float [] Points { get { return points; } }
}

Then anyone with a reference to Chart can go and poke at the internals of the points array that you have surfaced. For example, this simple Plot implementation accidentally modifies the contents:

void Plot (Chart myChart)
{
   // This code accidentally modifies the data in myChart
   var p = myChart.points;
   for (int i = 0; i < p.Length; i++) {
       Plot (0, p [i]++)
   }
}

This sort of problem is avoidable, but comes at a considerable development cost. For instance, in .NET you can find plenty of ad-hoc collections and interfaces whose sole purpose is to prevent data tampering/corruption. If those are consistently and properly used, they can prevent the above scenario from happening.

This is where Chris politely pointed out to me that I had not quite understood Swift - in fact, Swift supports a copy-on-write model for its collections out of the box - meaning that the above problem is just not present in Swift as I had wrongly assumed.

It is interesting that I had read the Swift specification some three or four times, and I was collaborating with Steve on our Swift-to-.NET binding tool and yet, I had completely missed the significance of this design decision in Swift.

This subtle design decision was eye opening.

It was then that I decided to gain some real hands-on experience in Swift. And what better way to learn Swift than to start with a small, fun project for a couple of evenings.

Rather than building a mobile app, which would have been 90% mobile design and user interaction, and little Swift, I decided to port my gui.cs console UI toolkit from C# to Swift and called it TermKit.

Both gui.cs and TermKit borrow extensively from Apple’s UIKit design - it is a design that I have enjoyed. It notably avoids auto layout, and instead uses a simpler layout system that I quite love and had a lot of fun implementing (You can read a description of how to use it in the C# version).

This journey was filled with a number of very pleasant capabilities in Swift that helped me find some long-term bugs in my C# libraries. I remain firmly a fan of compiled languages, and the more checking, the better.

Dear reader, I wish I had kept a log of those but that is now code that I wrote a year ago so I could share all of those with you, but I did not take copious notes. Suffice to say, that I ended up with a warm and cozy feeling - knowing that the compiler was looking out for me.

There is plenty to love about Swift technically, and I will not enumerate all of those features, other people have done that. But I want to point out a few interesting bits that I had missed because I was not a practitioner of the language, and was more of an armchair observer of the language.

The requirement that constructors fully initialize all the fields in a type before calling the base constructor is a requirement that took me a while to digest. My mental model was that calling the superclass to initialize itself should be done before any of my own values are set - this is what C# does. Yet, this prevents a bug where the base constructor can call a virtual method that you override, and might not be ready to handle. So eventually I just learned to embrace and love this capability.

Another thing that I truly enjoyed was the ability of creating a typealias, which once defined is visible as a new type. A capability that I have wanted in C# since 2001 and have yet to get.

I have a love/hate relationship with Swift protocols and extensions. I love them because they are incredibly powerful, and I hate them, because it has been so hard to surface those to .NET, but in practice they are a pleasure to use.

What won my heart is just how simple it is to import C code into Swift

• to bring the type definitions from a header file, and call into the C code transparently from Swift. This really is a gift of the gods to humankind.

I truly enjoyed having the Character data type in Swift which allowed my console UI toolkit to correctly support Unicode on the console for modern terminals.

Even gui.cs with my port of Go’s Unicode libraries to C# suffers from being limited to Go-style Runes and not having support for emoji (or as the nerd-o-sphere calls it “extended grapheme clusters”).

Beyond the pedestrian controls like buttons, entry lines and checkboxes, there are two useful controls that I wanted to develop. An xterm terminal emulator, and a multi-line text editor.

In the C# version of my console toolkit my multi-line text editor was a quick hack. A List<T> holds all the lines in the buffer, and each line contains the runes to display. Inserting characters is easy, and inserting lines is easy and you can get this done in a couple of hours on the evening (which is the sort of time I can devote to these fun explorations). Of course, the problem is cutting regions of text across lines, and inserting text that spans multiple lines. Because what looked like a brilliant coup of simple design, turns out to be an ugly, repetitive and error-prone code that takes forever to debug - I did not enjoy writing that code in the end.

For my Swift port, I decided that I needed something better. Of course, in the era of web scale, you gotta have a web scale data structure. I was about to implement a Swift version of the Rope data structure, when someone pointed to me a blog post from the Visual Studio Code team titled “Text Buffer Reimplementation”. I read it avidly, founds their arguments convincing, and in the end, if it is good enough for Visual Studio Code, it should be good enough for the gander.

During my vacation last summer, I decided to port the TypeScript implementation of the Text Buffer to Swift, and named it TextBufferKit. Once again, porting this code from TypeScript to Swift turned out to be a great learning experience for me.

By the time I was done with this and was ready to hook it up to TermKit, I got busy, and also started to learn SwiftUI, and started to doubt whether it made sense to continue work on a UIKit-based model, or if I should restart and do a SwiftUI version. So while I pondered this decision, I did what every other respected yak shaver would do, I proceeded to my xterm terminal emulator work.

Since about 2009 or so, I wanted to have a reusable terminal emulator control for .NET. In particular, I wanted one to embed into MonoDevelop, so a year or two ago, I looked for a terminal emulator that I could port to .NET - I needed something that was licensed under the MIT license, so it could be used in a wide range of situations, and was modern enough. After surveying the space, I found “xterm.js” fit the bill, so I ported it to .NET and modified it to suit my requirements. XtermSharp - a terminal emulator engine that can have multiple UIs and hook up multiple backends.

For Swift, I took the XtermSharp code, and ported it over to Swift, and ended up with SwiftTerm. It is now in quite a decent shape, with only a few bugs left.

I have yet to built a TermKit UI for SwiftTerm, but in my quest for the perfect shaved yak, now I need to figure out if I should implement SwiftUI on top of TermKit, or if I should repurpose TermKit completely from the ground up to be SwiftUI driven.

Stay tuned!

On March 23rd, we announced Unity Game Simulation at the Google for Games Developer Summit. Unity Game Simulation is a cloud service that enables game studios to complement their pre-launch playtests through the power of simulation. Supported by Google Cloud’s infrastructure, Unity Game Simulation helps you evaluate your game balance at scale. Unity Game Simulation […]

The post Optimize your game balance with Unity Game Simulation appeared first on Unity Technologies Blog.