PNTRLY Engine: Why We Chose Unity
Choosing technology for a project is always a trade off. It seems you can’t have all of the things all of the time; that was especially true with PNTRLY. Coloring book programs are deceptively hard to make at a high quality bar. All the parts are achievable, but to have them work together and scale gets quite tricky. These were the things we wanted for PNTRLY:
Line work should be crisp and zoomable
The user should hardly ever see pixels when zooming in
Filling, zooming and panning needs to be butter smooth & responsive (the app needs to be performant)
Drawing asset files should be small (drawings before being colored)
User output files (when drawings are colored) should be small
Filling should be non destructive (the user has a healthy amount of undos)
The art pipeline has to be manageable (small team)
That's a very nice list of haves, each one with subtle demands and dependencies. Butter smooth performance will require draw call optimization but we are a UGC platform and want to give the user as much creative freedom as possible. Crisp resolution independent line work means either very large textures or using some kind of vector engine. These options in turn have their own ramifications like disk and memory size, art pipeline or undos. And so on, ad infinitum. I found myself stuck in dependency loops a lot while trying to plan the architecture.
With many problems to solve and balance, the one thing that was not as hard to decide was what technology we were going to use. I evaluated a couple different options but it really came down to either an app wrapped browser or Unity. Many other tools got ruled out because of time to market, cross platform compatibility, the ability to render vector and familiarity. Familiarity with technology is something that should never be discounted. I know the modern engineer should be fungible, but the truth is we don't know everything. You can learn something new (or old) and shiny but with a small team, is it really worth it? Play to your strengths, especially when you are spending your own time.
Unity won this contest pretty easily. Although a browser solution was tempting and is jam-packed with functionality, Unity offered the whole suite of tools along with native performance. Unity gave us easy access to the GPU and mesh rendering and manipulation. We use this to accomplish our vector rendering. It also gave us the alternative to use signed distance fields for vector rendering if our mesh workflow did not work out.
The Unity Editor is a beautiful system to extend for all the tooling and automation we built for our art pipeline. All the profiling tools meant we could get crystal clear pictures on performance and memory usage. This allowed us to accurately test all of our different rendering approaches. Shadergraph allowed us to explore all sorts of rendering techniques quickly. The Scriptable Render Pipeline gave us full control over our rendering and its performance. Then, we wrap all of this up with Unity cloud build for continuous integration and Unity remote config for live ops and we have our winner!
Now one thing I did spend ages on was considering our back-end infrastructure. I went back and forth between all the different services considering cost, analytics, availability, scalability, ease of integration, dev ops requirements, etc. There are a bunch of offerings out there, and most are pretty good but all of them did not quite get us to 100% of where we wanted to go.
One Unity service that I did evaluate deeply was their remote config system. Turns out it's really configurable and has a nice little feature called “overrides” that uses Java Expression Language (JEXL) for handling every use case I could think of for routing different configs to different clients. This tipped me over the edge when considering remote config solutions and I am still very happy with it.
A little call out I did want to make with the Unity solution was its Vector Graphics package that is still in beta. Since its reveal at GDC a good couple of years ago (or at least it was new to me), it has hardly hit the news. It is a great little package and has helped us heaps in converting SVG to mesh. The SVG standard is fantastic on its own, but when combining it with the Unity import package it essentially allowed us to automate a large portion of our import process.
All said and done, Unity was the perfect choice for us here at PNTRLY and also allows us to consider many other platforms for the future. Unity is usually not a go-to for mobile applications (as opposed to games), but you might want to consider it based on your use case. As we approach a new world of client side technology like AR, VR and whatever else us technology folk like to dream up, who knows — maybe PNTRLY will be running on your fridge one day!
Roger Miller
Co-Founder | Chief Technology Officer
With 25 years in the software industry, 15 in the game/AR/VR industry, on 4 continents, Roger comes with a breadth of knowledge. Roger Miller has been on the leading edge of both server and client side technologies from factory automation to data cataloging to award winning games and XR applications. He has worked with leading advertising agencies such as Ogilvy One, been a vendor for entertainment companies such as Unity, Amazon, Disney and HBO, created solutions for BMW and Deloitte and been nominated for awards such as the IMGA. He has spoken at Unity Unite, a once frequent speaker at the Unity User Group in Los Angeles and founded the Unity User Group in Bend, OR.