Shining a light on Spotlight

Today I'll be talking about one of the most important projects we've been working on in the last few months. As a pre-caution, due to the sheer amount of features contained within Spotlight this blog post will be very long, diving into a lot of technical details along the way. So let's get started!

The beginning of Spotlight

Some of you may already know Spotlight based on a tweet I made back in April, showcasing some of the features of the UI editor:

Back then, the user interface for Spotlight was still in a very early stage of development with a lot of features missing. Ever since we posted this first development video a lot of things have changed, especially in regards to the design of Spotlight's user interface:

Although Spotlight was only planned to be used as a tool for creating graphical user interfaces (GUIs) in Minecraft, it has developed into something far larger. But before we get into that, I'd like to first talk about why this tool exists in the first place.

Why?

Let's start with a relatively complex topic: Creating custom UIs in Minecraft. As of right now, creating your own UIs relies on a number of tricks ranging from custom fonts to negative spacing or in some cases even custom shaders. Our goal was to create an layer of abstraction on top of all of those fancy tricks, meaning that a user doesn't need to know about any of these tricks in order to create something within Spotlight.

Another benefit of this approach is that whenever a new, more efficient way of creating custom UIs becomes available, we can easily update Spotlight to take advantage of that without changing the workflow for users.

Of course creating a design is only one of many tasks involved in adding a new UI to the game. Certain tasks like determining which part of code has to be run when a button is clicked still has to be implemented manually. However, other tedious tasks like generating resource packs is completely automated, increasing development speed & productivity significantly.

Another goal we've set for Spotlight is the ability to be able to work with multiple users on the same project at the same time, in simplified terms a "multiplayer" tool. You can imagine the editing process to work similar to how it does in Google Docs or other collaborative editing software.

All in all, Spotlight takes care of all the complexity of certain features while providing an easy to use interface for users. Now that we've cleared up what Spotlight is intended to be used for, we can now start to apply the same principle to other areas of our development process.

Localization

Let's first cover how we've dealt with translations for our experiences in the past. Like most games and applications, all of our experiences use placeholders whenever translatable text is referenced in the code. So for instance, if we want to send a chat message to a player, we do so by using the translation key of the message we want to display:

Before the message is sent to the player, the server checks if it can find a translation for the key "paintsquad.inventory.error.full". If a translation is found the placeholder is replaced by the translated text. However, if the server can't find a translation for a placeholder, you encounter one of these messages:

Sounds familiar? Well, this is one of the problems you may have encountered in earlier versions of PaintSquad or Rush. So how can this happen? Well, we first need to talk about how we add translations to the game in the first place and how the server accesses them. The answer is as simple as it is unspectacular: Text files. Yes, we're essentially just using simple text files for each language which are then loaded by the server on start up.

Whenever we want to add or change translations, we use a text editor for changing the content of the file. However, this approach is prone to errors, especially when you're dealing with several hundred translation keys.

Due to the fact that we have one file for each language, you can easily run into issues that result in the translation missing for one or more languages. For example, this can happen if the person creating the translation either forgot to save the second file or forgot adding the translation in the other file(s) in the first place. Another huge issue is that the main version of all translation files isn't stored in one centralized space, leading to even more issues as soon as multiple people work on the same project.

Fun fact: PaintSquad 2.1.0 features over 2.500 translated messages.

Streamlining the process of localization

After we finished the UI editor for Spotlight, we started working on a proper translation editor in order to not have to deal with all the issues we've encountered in the past. The goal was to add features to create, edit and even preview text messages in the browser. Of course all of these features would also have to work in a way so that they can be used by multiple users at the same time.

Another major change we've made is to go away from the concept of having a single translation text for every translation key and each language. Instead we've created a system where users can create suggestions for every translation key. Users can then up- or down vote suggestions. The suggestion with the most up-votes is considered "approved", alternatively a translation can also be marked as "approved" by an admin. As for why we went with this approach I'll explain a bit further on.

Here's some footage how the translation process works in practice:

You might ask yourself why I'm using the term "user" instead of staff or team member. The main reason for this is that we're considering to add community-made translations sometime in the future. Although Spotlight is currently only usable for staff members, we're planning on giving access to volunteers that contribute towards translating PaintSquad, Rush and other experiences into other languages in the future. As such we also made the necessary preparations for being able to easily add new languages to our system later on.

Although it's not necessarily related to Spotlight, I'd still like to mention that we're also working on improving our release procedures for experience updates. This also includes a step that will check for code that references translation keys that aren't defined in the system, allowing us to catch the previously mentioned errors before a update is released to the public.

Warehouse

During Spotlight's development we also started working on another tool called Warehouse which was intended to be used for storing all custom 3D models we're using on the server as well as providing a user interface to spawn said models on the server. However, we realized that having two separate apps would clash with features we want to add in the future which is why Warehouse ultimately ended up being implemented as a module for Spotlight.

Warehouse provides a 3D preview of all available models so we don't have to memorize the names of models. Here's some footage of how a model can be spawned via Warehouse and then edited with Forklift:

We've also added a lot more features to Warehouse, making it a complete game asset management tool. This makes it possible to manage 3D models, music, sound effects, biomes and block state definitions within a single web application.

Landscape

Landscape is our new level management system that has been in use for a couple of months by now. Although we haven't covered Landscape in detail in any public blog post yet, all you need to know is that it's the system that allows us to place certain game objects such as spawn pads, ink rails and many other elements onto a map.

Although we've already created a mod for making it easier to interact with some objects on our build server, we quickly ran into some complications that can't easily be circumvented with a mod or custom client. To be more specific, we're currently working on a timeline-based cutscene editor to Spotlight, but having both controls for the cutscene editor and the game's camera within the same application ended up making the workflow way too confusing.

Therefore we decided to do something different: We use Minecraft primarly as a cutscene preview and do all the editing work within the browser. Since Spotlight already provides a communication interface between the user's web browser and our building server, we made the decision to add another tool to Spotlight. Since our cutscene system is still in very early stages of development we don't have any footage that accurately depicts it's intended use-case. However, we already have a working version of our 3D level preview:

Fun fact: This preview is generated by our own Minecraft rendering engine "Nova" that runs in the background on Spotlight's backend. Chunks are converted to models and then sent to the browser for rendering.

We're also considering making a dedicated blog post to Landscape in the future, showcasing how maps for PaintSquad and Rush will be created & edited in the future. This might sound a bit boring at first, but PaintSquad's layout system (e.g. some parts of the map being different depending on which game mode you're playing) actually made it quite challenging to work out a concept for a system that is both reliable and easy to use.

Outro

And with that we have arrived at the end of today's developer blog post. We're also planning on releasing a new monthly recap post next weekend, including some screenshots for PaintSquad 3.0. I'm also returning to streaming Xenyria's development on Twitch next weekend, so if you're interested about what happens behind the scenes you should definitely keep an eye on the media channel on our Discord. Thanks for reading and your continued support. Stay tuned for more updates! 👀