From Level to Data Editor
Making video games is hard. It’s a blend of many skills and many talents. Design, tech, art, and business need to be carefully balanced to create a memorable and unique product for an audience and a market constantly evolving.
To achieve this balance one must be able to manipulate all these things easily to reach equilibrium. We need tools to easily peak, probe and tweak little things. Compare, estimate, try, copy, and optimize many parameters and see, or better, feel what’s best.
The Editor
A standard game is not just a bunch of code, some art asset, and a level editor. It is a collection of data that is carefully assembled. And data is not just the level. There’s data about pretty much everything: monsters, obstacles, bonuses, characters, animations, rendering materials, physical properties, timings, transitions, quests, difficulty, assistance, dialogues, terrain, level, sounds, variables, events, app flow, etc. Code is just another form of data. Variables are data. We used to think about the Level Editor, the place where the level or the game was built, as the final frontier. But what a game needs is a Data Editor.
And this is why Flash, Unity or Roblox have been so successful. They all provide ways to easily edit data and see the result (near) instantly. Again what’s hard about making a game is bringing and tweaking everything together, so having a tool that does that very well is extremely important.
Because it brings all the different kinds of data together, the Data Editor contextualizes data. That well crafted data that was created in Maya, Photoshop, Wwise or Visual Studio can be seen in situ, and appreciated in the correct context. Then and only then can you really start to iterate and make a great product.
Data Accessibility
Once lots of data was assembled together into the Data Editor, the tweaking phase can start. For the iterating phase to be successful as many parameters as possible need to be editable. The data needs to be accessible and editable. In order of best to worst:
In-editor at run-time. Data can be edited instantaneously inside the Data Editor, while the game is running
External at run-time. Data can be edited in an external program (ex: Photoshop, Maya…), and then you can alt-tab to see the change while the game is still running
In-editor offline with weak context. Data can be edited only offline inside the Data Editor, with a weak context (I can see the character, level, monster, etc. affected by the change but I’m not playing). This can still be acceptable if launching the game and reaching the testing stage takes a short time (less than 30 seconds)
Offline with no context. Data can only be edited separately, without seeing any context. Basically at this point you don’t have a Data Editor anymore
Offline, no context, and long iteration. Not only you have no Data Editor, but the iteration time to see the data in context takes a long time (need to recompile for 5 mins, bake AI or lighting for 1 hour, etc.)
Not accessible. The data to edit is not even accessible, for example you want to change the reward of the 5th quest, but you don’t know where it is. You want to change the spawn position, but it’s not set anywhere. Etc.
Data Interface
What should be clear from all this is that one very important aspect of the production is how you interface data together, how do you make that data accessible, how do you provide all this data points?
If you’re working with an in-house engine, this should be the priority #1 of the engine team. It shouldn’t be the shadow map algorithm, the big file serialization or the integration of source control. Yes it’s important, but data interface is one order of magnitude more important to built a good game. If you’re using Unity you’re in luck because this is what the engine was built for, same for Roblox or other data-centric engines.
Even if your engine supports a good data interface, it still requires a lot of work from the entire team:
You need to organize your data correctly, this can be challenging
You need to think in a data-centric approach. Code is now data, 3D assets are data, game design parameters are data and they all have their priority and accessibility to care for
You might have to build a custom database system if you deal with a lot of data
Data is a great equalizer, the entire team make data, organize it, merge it, tweak it, no one is above anyone else
Everyone still need to carefully design their data to be editable inside the Data Editor. Sometime the data is too complicated and it’s not possible, but 80% of the time it’s worth to spend some time thinking how it could be possible. Some example:
For the code as many important variable as possible need to be editable. This is true for gameplay, AI, engine, and any system handled by code
Textures if possible have .psd files in-engine to edit on layers directly. Might not be worth it for super big psd files, but making light psd files is possible
The level should be editable in the editor, usually offline depending how it’s built
You can integrate your color palettes in the Data Editor
All main elements of game design should be in the Data Editor, list of enemies, weapons parameters, items, crafting or resources simulators, difficulty curve etc. Work on making it easily readable
All business settings should be also editable and accessible, prices, duration, special offers, subscriptions, ad settings, etc.
Simple 3D objects theoretically could be modified directly in the Data Editor, for example terrain or simple props, anything not animated with simple geometry
Complicated 3D objects can become… too complicated to be realistically modified in the Data Editor or even at run-time
Ability to do sound balance in the Data Editor while playing
Your app flow could be there as data, as a graph / node or even just config file
Your main variables and how they’re linked and used could be easily editable
Your events and who is listening to them could become data
Ahh.. yes, that’s a lot of data! That’s why you need a Data Editor! Of course all games or apps won’t need to expose all the data all the time, you need to tailor your tools to your own use case.
Sometimes data needs to be controlled from outside of the game, for example to A/B test something, to optimize a set of variables or to provide content based on seasonality. In this case I believe it should be very clear in the Data Editor that the real data comes from an external service, and it should be explained in-editor how to change it or who has access to it. Ideally there should be a button to fetch all the data or see the current config.
There is a lot to be said about the different solutions to architecture all this, because when the code itself becomes data then the app flow can be a data, the events and listeners can be data, the state machine and the logic too. I haven’t yet seen an editor that completely embrace the data approach but Unity is going in the right direction by allowing it.
A great starting point to start thinking in term of data oriented design is this article from Ryan Hipple at Schell Games: Three ways to architect your game with ScriptableObjects. It’s a blending of traditional programming, data oriented programming and visual programming, I hope you’ll enjoy it :)
This article is followed by a Tech post on Generic Database in Unity using ScriptableObjects
