In the Unity for Software Engineers series, I give an accelerated introduction to game development in Unity. Subscribers have been following this series over the past few months, often suggesting areas to cover or elaborate on. A few months ago, a reader—also a software engineer—reached out to me (lightly edited, emphasis mine):

The biggest unknown for me is: How do I start? What does the process of creating a game look like? Should I build the scenes first? Should I design the gameplay mechanics first? With business software, it’s much more familiar. It’s easy to think, “Well, okay, I need to write the DAO or controller, etc.” But with games, I’m lost.

For the third and final “short” of this week’s Unity for Software Engineers, I give an overview of building in-game User Interfaces in Unity. As a reminder, this week’s installment is packaged as a series of short-form outlines, introducing readers to the breadth of the Unity toolkit.

Just like rendering and the Input System, Unity has a few technologies that can be used to render UI in a game. Unity’s documentation includes a comparison of these UI toolkits. Of these, only two technologies can be used for in-game user interfaces. We’ll discuss these here:

Continuing the “shorts” week in the Unity for Software Engineers series, today we’ll be discussing Unity’s Physics Raycasting. As a reminder, this week is packaged as a series of short-form overviews, introducing readers to the breadth of the Unity toolkit.

Raycasting is Unity’s way of checking collisions between objects in the scene and an invisible ray with a given geometry. Raycasting is used in a myriad of ways. Some examples:

For the 10th installment of Unity for Software Engineers, we’ll be doing things a bit differently. Instead of a single long-form article going in-depth on a single topic, I will be releasing a collection of short-form overviews over the course of this week. The goal: introduce readers to a breadth of the Unity toolkit.

Pathfinding is a common system in video games; you might have enemies that need to move throughout the scene to reach and attack a player, or a point-and-click game where you command the main character by simply clicking at a destination, or a real-time strategy game where all units navigate around obstacles and each other dynamically.

In solo game development, you can’t just stick to your strong suit. If you’re a Software Engineer trying out solo game development, being a solid developer will only get you so far; even if you’re using assets made by others, you’ll still need to know how to integrate them into your game tightly.

Animation is a great example. Imagine a character model has animations for walking, running, standing, talking, interacting, and more. In that case, you will still need to define how a character object triggers and transitions between these animations. These animations might also dictate what your object does; for example, an enemy that punches characters might want to deal damage at the precise moment the model’s arms are fully extended.