game-data-editor-1
Date: 9/11/20 Tags: Tools, Svelte, Data, VSCode Permalink: /game-data-editor-vscode-part-1 Summary: Why build a custom data editor? Title: Building
September 11, 2020
Date: 9/11/20 Tags: Tools, Svelte, Data, VSCode Permalink: /game-data-editor-vscode-part-1 Summary: Why build a custom data editor? Title: Building a Game Data Editor in Visual Studio Code Part 1: Why? —
This is part of a series of posts where I discuss building a game data editor inside of Visual Studio Code.
Part 1: Why?
Part 2: Custom Editors, Webviews, and Svelte
Part 3: Getting Data into Svelte
Part 4: Editing Data in Svelte
Introduction
I’ve been really passionate about game data management for a few years now, and after working on the Unity + CastleDB interop have been thinking a lot more about how I can continue to contribute in the space. My latest game, Cantata, is built to be able to be easily moddable, so it seemed like the perfect time to put what I knew about game data management to the test to not only help my players to be able to quickly build new mods using only data files, but also to support Cantata’s team as a whole have access to better data tooling.
This is also one of those things that seems like only AAA games do, which I think is largely the case outside of translation data management, but it’s for that reason in part I want to build a generic tool that everyone can use, and can be a tool they can build their game around.
Criteria
With that in mind, I developed a few criteria:
- Offline-first (shouldn’t need to be online to use it)
- Generic (no language/platform bias for games using it)
- Extensible (basically: open source and using a relatively idiomatic tech stack)
- Easily accessible (works with developers and their workflows, not a workflow itself)
- Structured Data ( Key + values, not raw csv)
- Specific (it’s meant to do data editing, nothing else)
The closest thing we get here is obviously the project that inspired the start of this, CastleDB, but CastleDB, for better or worse, is built as a tool that works exclusively with games made in Haxe (hence my work on the CastleDB + Unity tool). It’s also more in bug-fix mode, as the main developer has gone on (with good reason) to port most of it’s functionality to HIDE, doubling down on CastleDB as a Haxe-only tool.
There’s a few offline spreadsheet programs that meet some of the above criteria, but don’t really facilitate nested data and references required for game data. Additionally, they require developers/teams learn a new tool that they have to download. One thing I really wanted was for the tool to be mostly “invisible” — that it feels like an extension of the normal development process.
When I really focused in on these goals, what became clear is that I was looking for a way to edit data inside of whatever IDE a game was using. How I was supposed to go about that wasn’t really clear until I learned about Visual Studio Code’s Custom Editor API.
Visual Studio Code
I’m really bullish on VS Code (just “Code” from now on). It’s a well loved development environment, seemingly surpassing what for the longest time felt like total dominance by SublimeText and Atom, but I think even considering that it’s full potential is lost on most of its users.
Years of Atom + SublimeText lead us to see Code as “just a text editor,” but if you really read the patch notes each month the philosophy of the development team is clear — they are looking to Code to become a Platform for development itself, a place where work is not done only to serve other software, but that Code itself is a place to do work inside of. I would not be surprised if people start offering software and services that are deployed and managed solely through Code and eschew any need for an external presence.
Why? Code’s easy to navigate (from inside Code) extension library means that, once you publish your extension, every one of Code’s nearly 5 million users have access to your work. The StackOverflow 2019 developer survey showed that Visual Studio Code is the most popular development environment. If there’s a developer on your team, it’s likely that they are using Code in some way.
With so many developers using it, and so many people publishing easily-accessible extensions to the software, what I’m getting at is that Code is becoming something of a “developers internet” - an all-in-one development platform that allows you to not only work on other software, but craft your own environment in order to do that work. This extends far beyond themes, allowing you to configure toolchains, macros, hotkeys, snippets, etc. You can also group extensions, meaning that you can easily onboard a new hire but just having them download an extension pack for Code and have their environment be preconfigured (especially with some new exciting Authorization APIs).
Code’s Custom Editor API
One thing that’s really pushing my thinking in this direction is Code’s lowkey-but-maybe-revolutionary feature, Custom Editors. This is a bit of an offshoot from their Webview API, an API that allows you to render arbitrary HTML/JS/CSS in a Code window (like the Markdown preview mode).
What the CE API gives you is the ability to essentially summon a webview in place of the standard text editor in Code, and allow you render whatever you want in that file’s editing window, but with access to the data of the file you clicked. The documentation lists some potential use cases that should be enough to help you realize how powerful this could be:
- Previewing assets, such as shaders or 3D models, directly in VS Code.
- Creating WYSIWYG editors for languages such as Markdown or XAML.
- Offering alternative visual renderings for data files such as CSV or JSON or XML.
- Building fully customizable editing experiences for binary or text files.
Shader editing! Rendering! Custom editors! Arbitrary data formats! All inside of Code!
Reading the patch notes where I first learned about this I got really excited. Based on the above criteria, it seemed like building the editor as an extension in Code would be the way forward. Everyone already uses Code, it’s offline, and I can still design an editor for arbitrary files types. I could just build a data editor inside of the tool they were already using.
This is part of a series of posts where I discuss building a game data editor inside of Visual Studio Code.
Part 1: Why?
Part 2: Custom Editors, Webviews, and Svelte
Part 3: Getting Data into Svelte
Part 4: Editing Data in Svelte
This series of posts wouldn’t be possible without a lot of help from around the internet and people answering questions posted on StackOverflow. Here’s some stuff that really helped me on the way:
First, big thanks to Dave! He put me onto Svelte in the first place. If you’re reading this you know who you are! Other resources:
The Svelte tutorial docs are incredible, as are Code’s
Reactception : extending a VS Code extension with Webviews and React
https://github.com/ncannasse/castle
https://github.com/heapsio/hide
https://github.com/rebornix/vscode-webview-react
https://github.com/4gray/vscode-webview-angular
https://github.com/sveltejs/svelte/issues/1253
https://github.com/microsoft/vscode/issues/98542
https://stackoverflow.com/questions/56830928/calling-vscode-extension-for-data-from-webview
Building Data Table In Svelte By Mukesh Chandra
Svelte advanced tutorial for creating, updating, and deleting users with JSON objects in a store
Published on September 11, 2020.