I will show two examples of custom editors I implemented in production to enhance our workflow with generated data. The examples are from the game ‘Space Shop VR‘. It is about a shop in space that sells different items to aliens. The clue is that all aliens speak different languages and the VR player must translate the alien’s request with the help of the other players.
All alien cases were generated based on a ruleset table maintained by the game designer. This made it easy to tweak for our designer and removed the need for the programmers to manually edit every case when the game design changed the rules. The generation workflow lead to quite hard-to-read data objects that made debugging and checking the generated cases difficult and time-consuming. For example, the data objects generated for the alien named Gordianer:
This is quite hard-to-read, isn’t it? And the worst is there are around 100 of these case objects with a few hundred entries each. What would you do if a playtester reports that one of the questions in the party-hat case is wrong? You should write a custom editor to visually debug the data! I went with these two editors to get a better grasp at which poses the alien is ought to do to get a specified item:
Another good example are the custom editors of the Ininin alien. The alien consists of multiple smaller entities called Ini. It communicates by walking in circles while changing colors. The data without a custom editor would look like this:
It was a lot easier for the designers to input the walking patterns (left) that are used to generate the case data (right) with the following editors.
I hope the custom editors in this post gave you an impression of the changes editor code can make for data readability. It is not hard to add dropdowns for scriptable objects or draw multiple fields in a row. Start small and enhance your data visualization step by step with custom editors.