UX upgrade

[skymen]

• Given some buttons better CSS
• Made it so longtext uses a dialog for editing instead of resizing the field
• Made bool nicer to look at
• Made enums, line ref, sheet ref, and every other list elements use an autocomplete instead
• Fixed Image losing aspect ratio on hover

The main reason I used autocomplete was for lineref cause when the sheet reaches hundreds of lines, the current implem becomes absolute hell to navigate

also completely unnecessary, but the new bool has a cool anim

Code_2VKjUsXGPU.mp4

Code_o9ixFE4SYD.mp4

[skymen]

Hey, any news when this will be merged?

[kkukshtel]

@skymen sorry for the delay here! I never got a notification that this PR was submitted so I'm just now seeing it. We're neck deep in releasing our game on May 12th so I won't have time to check it out before then.

In the meantime, I have to say that what you added here looks incredible. I can't believe someone would take the time to do this and it's much appreciated! My only ask would be, from a feature perspective, is how hard would it be to implement this as well:

https://github.com/microsoft/vscode-webview-ui-toolkit

I've been wanting to revamp the CSS for a while and a lot of what you did feels like it moves in that direction, and I'm wondering if we can unify it with the "native" code components so it feels even better. What do you think?

[skymen]

Hey! No worries about the delay, I was in fact more worried that you'd never gotten the notification.
Good luck on shipping your game :)

About the CSS changes, I'd need to look at the library in more details, but my guess atm is that for most "simple" components it should be super easy, but it'll be harder for stuff like tabs maybe. Since it has a Svelte implementation it looks like a pretty good direction to go in though. Also, some of my custom UI is kinda "hacky" and in general, I think that rewriting most of the UI components and tidy them up is a good idea.

Also, I plan on working more on this in the future, as I'm probably gonna be using Depot for my own game. I also plan on writing a custom exporter that compiles the .dpo file into a lossy .json that's optimised for in engine implementation
(with all the "editor" data removed and a bunch of duplicate data to make it MUCH easier to read the JSON, rather than writing for loops to run through entire arrays, as this will definitely cause issues at scale.

[kkukshtel]

Yeah basically I'm totally out of my depth on CSS, so I'd love if someone with more proficiency there was able to take that stuff on. A major issue right now for example is that the editor looks awful if not in dark mode, because all the component styles are hardcoded. Code provides CSS variables that would allow you to hook into whatever colors a use set, and I think their web components library uses them as well. Basically unifying all that stuff for Depot would be ideal.

I agree that the simple components are probably simple to implement, but I think some of your UX stuff like the expanded long text box are SUPER awesome, so I'd want to keep that in.

The BIG one is probably the data grid, as that touches sort of "all" the code instead of my hacky table view thing, but it could be worth investigating if you're up for it. It may even give us better stuff like searching / reordering / filtering / etc.

Also, I plan on working more on this in the future, as I'm probably gonna be using Depot for my own game

Awesome! Always happy to see people using the tool. Let me know if you need any help around implementation or anything. I'm about 70% done on a C# source generator for Depot, so if you're in Unity land that could be super helpful as well.

I also plan on writing a custom exporter that compiles the .dpo file into a lossy .json that's optimised for in engine implementation (with all the "editor" data removed and a bunch of duplicate data to make it MUCH easier to read the JSON, rather than writing for loops to run through entire arrays, as this will definitely cause issues at scale.

FWIW the Depot file for Cantata (our game) is like 50K lines of JSON long (all raw Depot) and we dont really have any issues. There's some lag in Code itself sometimes, but otherwise we dont have any issues on the engine side. That said, I think doing a "cleaned JSON export" is really smart, and someone even suggested something like that here (see list item 2). Basically, the .dpo file is the "project" file (still JSON), but provides export options that let you export everything from the whole file, cleaned of schema info, single records, etc.

As a stretch goal there it would be nice as well to export a version that is JSON schema as well. I dont know if we could really update the internal model of Depot to be JSON schema (there would be a lot of redundancy), but having an export option for it would allow Depot to play nicer with other tools that work off of JSON schema files.

[skymen]

I'm currently on vacation, but I'll probably come back to this in June/July. I'll look into the CSS stuff when I do. Feel free to merge this branch when you want in the meantime, I'll clone again when I eventually do this.

I'm not on C#/Unity, I mainly use Construct and other JS based engines. So I planned on writing a JS lib (which makes it INFINITELY easier to work with JSON rather than using C#)

FWIW the Depot file for Cantata (our game) is like 50K lines of JSON long (all raw Depot) and we dont really have any issues.

Yeah I know I'm being overly cautious, it's mostly cause I don't like doing unnecessary work, and I can see scenarios where I'd have issues. For instance, let's say I'm making a fighting game that I plan on shipping to lower end devices, like mobile. I'll have potentially hundreds of hitboxes to describe in the depot file, and to get the hitbox data I might have to search through the entire database multiple times per moves, potentially on every frame for multiple characters.
With that, moves early in the list would be fine, so I probs wouldn't notice right away until months/years into dev and I make a move that lags in 2v2 for that reason.
Also, C# is very performant cause it's compiled, but JS on weak hardware is soooooo slow. I need every CPU cycle I can get. People will play web games with a 2008 android and complain if it doesn't run well :(

As a stretch goal there it would be nice as well to export a version that is JSON schema as well.

I never used JSON Schemas, can you explain what they're for? Only time I've heard about them was when sending packets of data between players, but dpot files being databases would have no business being sent in real time between players

[kkukshtel]

I'm currently on vacation, but I'll probably come back to this in June/July. I'll look into the CSS stuff when I do. Feel free to merge this branch when you want in the meantime, I'll clone again when I eventually do this.

Sounds good! I'm not sure when I'll get a chance to check out the changes and verify they work on my end (could also use a testing suite...), but if I get to it before then I'll give it a merge or some feedback.

I'll have potentially hundreds of hitboxes to describe in the depot file, and to get the hitbox data I might have to search through the entire database multiple times per moves, potentially on every frame for multiple characters.

This is more of an architecture issue than a database issue fwiw. Neither Depot or JSON generally are really meant to be an active database in a game. You'd deserialize your data into your game into actual objects, and do operations on those objects. You wouldn't really be reading/writing to a file. But that's a bridge we can cross whenever, happy to support you as you develop!

I never used JSON Schemas, can you explain what they're for?

It's the "standard" way of doing some of what Depot solves, namely making JSON have some type metadata attached to it for easily validation. It doesn't have anything to do with packet transfer netcode stuff.

[skymen]

You'd deserialize your data into your game into actual objects, and do operations on those objects.

For data that needs to change, sure. But for static data, I'd rather just fetch it from the database than copy it elsewhere. But yeah I agree it's not a huge issue in practice.

It's the "standard" way of doing some of what Depot solves

Got it

[ngburke]

Looking forward to this, any updates?

[skymen]

Hey, still haven't had time to get back to this. I still plan on working on it some more but it's hard with a tight schedule

[kklimitkk]

Hey, AutoComplete is AWESOME!!!! I'll take this