Working from home is nothing new, especially for those of us in the technology business. Since the COVID pandemic, however, many companies were forced to jump into the deep end of remote work. Thankfully, it seems to have been a positive experience for most.
Employers realised that their employees’ productivity isn’t reliant on their managers lurking around them and peering over their shoulders to make sure they could see a text editor rather than Facebook on the screen. Employees realised that it’s quite nice to be able to fully control your physical working environment and interruptions. It’s not everyone’s preference, however, and that’s fine too. Some people need more in-person contact with their colleagues in order to do their best work.
Let’s say you have an existing UMG UI which you’ve created in C++ already* (derived from UUserWidget), and you want to add child widgets at runtime. Imagine you have an inventory UI with a container of some kind (I’ll use a vertical box in this example) and you want to add an item at which the player is aiming. You could add a method to your UUserWidget-derived class like this (I’ve used a text block for the example but you can use any widget derived from UWidget):
void UMyUserWidget::AddInventoryItem(FText ItemName)
auto NewInventoryItemWidget = WidgetTree->ConstructWidget<UImage>();
* Mike Stevanovic has a great tutorial for creating UUserWidgets and adding them to the viewport using C++.
This tutorial shows you how to create a circular crosshair using a widget blueprint with a material. As always, there are many methods available but this one has some key advantages:
Material parameters let you modify the crosshair in realtime. In this tutorial we will use a material parameter to optionally fill the circle.
No texture manipulation needed with external software.
The colour of the crosshair can be easily changed, both in the editor and during runtime.
This is what the final crosshair will look like. I’ve wired up the “F” key to fill the crosshair for demonstration purposes, but my game will ultimately fill the inside when the player is aiming at an interactable object.
I’d like to start by first talking about software engineering itself, and whether it can legitimately be called engineering. The Oxford English Dictionary defines “engineering” as:
The branch of science and technology concerned with the development and modification of engines (in various senses), machines, structures, or other complicated systems and processes using specialized knowledge or skills, typically for public or commercial use; the profession of an engineer. Freq. with distinguishing word.
By this definition I believe it’s fair to describe the design and creation of software as “software engineering” and I’m going to proceed with the rest of this post on that basis.