Interactive 2D and 3D work: games, training simulations, product configurators and VR or AR experiences, across desktop, mobile and headsets.
Not only games. Most of the interesting work is training, visualisation and configuration.
Desktop, mobile, web and headsets from one project, which is why it dominates interactive 3D.
Procedures practised safely in 3D, which is often cheaper and better than doing it on real equipment.
Real-time 3D of a product with options applied live, connected to your actual catalogue.
Headset and phone-based experiences, built with the comfort constraints that decide whether people finish them.
A configurator a customer can turn, open and change, in a browser or on a tablet, where a video would not answer their question.
Procedures rehearsed safely: machinery, process, emergency drills. Usually cheaper than the alternative and infinitely repeatable.
Learning and engagement products where the game mechanics are the delivery mechanism rather than the point.
Headset and phone-based, where Unity is effectively the industry default and everything else is uphill.
Builds, platform requirements, store submission and performance on the device it actually has to run on.
Written for someone deciding, not for someone who already knows. Skip it if you do.
A real-time 3D engine: it draws a scene, handles physics and input, and exports the result to phones, desktops, browsers and headsets. It's best known for games and is used just as much for training, visualisation and anything where somebody needs to move through a space rather than look at a picture of it.
Because the hard parts are already solved. Lighting, physics, animation and the export to a dozen platforms would each be a project on their own. Unity turns them into configuration, which is the difference between a feasible budget and an infeasible one.
More than a web page, in every sense. A 3D scene is heavy to download and heavy to render, and the phone that has to run it's rarely the one it was built on. Deciding the minimum device early shapes everything, and skipping that decision is the usual reason a project disappoints.
Unity's terms have changed more than once and caused real anger in the industry. The free tier is generous and most non-game work stays inside it, but it's a commercial product owned by one company and that's a risk worth naming rather than glossing over.
Almost always a scene built without a target device in mind. Findable with a profiler and usually fixable without redoing the art.
Unity in a browser is a large download. There are real techniques for this, and they need applying deliberately.
Upgrading a Unity project is genuinely awkward, which is why it gets postponed until a platform requirement forces it at the worst moment.
No, and most of this work isn't games. Training simulations, product configurators and visualisation use the same engine for practical business reasons.
Yes, with WebGL, with limits on size and performance. For a configurator that's usually fine; for a large game it usually isn't.
The mainstream standalone and PC headsets. The important early decision is which one your audience actually has, because it shapes the whole performance budget.
If the viewer never needs to change anything, a video is cheaper and better. Unity earns its cost the moment they need to choose, configure or move through something.
Yes, and that's often the right delivery for a configurator. The trade is download size, which has to be designed for rather than discovered.
A few lines are enough to start. You get a reply within two working days.
