Unity3d


If you’ve never touched game development before but have otherwise programmed in something like Python or Javascript, you might be surprised to hear about what makes game development in Unity similar or different to the environments you have found yourself in the past.

What is Unity?

“Unity” or “Unity3d”, as you will variously see it referred to online, is best described as a game development platform. You will often see it referred to as a “game engine”, and by that most folks mean that it is a programming framework that provides a pre-built software architecture and built-in utilities designed to make developing games easier. In most cases, game engines will abstract away all the messy details of interacting with the GPU directly and provide a higher level of abstraction for programmers – cameras, lighting, meshes, textures, and the like are all “native” objects in many game engines that are modular and can be customized with ease.

When I say that Unity is a game development platform, I’m alluding to the fact that not only does Unity provide this core game engine for developing games, but also an entire ecosystem of utilities and tools to go along with it – an IDE for programming, a simulator with live reloading and interactive debugging, “editor” windows for manipulating variables and game data, and project asset management so that one can drag and drop art and visual elements into the game world. That list is certainly not exhaustive, in fact it barely scratches the surface. Nowadays, game engines are evolving to directly incorporate asset stores for purchasing and downloading visual game assets, and providing access to cloud computing for things like machine learning, multiplayer networking, and more.

What makes up a game in Unity?

At the ground level, games in Unity go through multiple layers of compilation until they are ultimately assembled down into a binary executable meant to run on one platform architecture or another. Most of us coming from a Python or Javascript background are spared the gory details of compilation steps (sidenote: though compilation does happen here too – Python compiles down to bytecode, which is an abstract machine language that is executed one line at a time by the Python interpreter, which is itself an executable written in C and then assembled into a binary for a particular platform).

Lucky for us, the Unity game engine hides most of that detail from us, too, though it’s still a fair shake different than the typical workflow of a Python program. From a file system perspective, a Unity project, to grossly oversimplify things, is an assemblage of: a) audio or visual game assets such as 3d models, images, texutres, etc. that are created by humans; b) configurations and data specified in the Unity editor GUI by humans that are then written out to configuration files programmatically; c) alongside various C# scripts that are manually defined by developers for creating and manipulating game objects programmatically.

The first major difference to be observed from other programming environments is that the Editor GUI is integral to the development flow, and rarely (if it can be done at all) is the entirety of a game developed exclusively by typing out source code. The editor controls everything from creating and manipulating scenes, to assigning “components” or variable data to game objects, as well as all the simulation and debugging activity for playing and testing the game itself. Actions in the editor are written out as text files for things like source control, but they aren’t necessarily intended for human editing or readability.

Rather, a broad take on the Unity workflow might be something like: humans use the Editor to create game objects and scenes, add textures and images and lighting, and then create custom animations, game logic, or other effects through scripts attached to game objects written in C#. The sum total of all that work in the editor and C# scripting is compiled first to C++ (what the Unity engine itself is written in) and assembled into the appropriate binary for the game platform.

Next time, we’ll take a deeper look at C# and the Unity framework that’s used to do all of the “interesting” work in game development. Particularly, we’ll explore some of the key differences for someone coming from a Python or Javascript background.

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *