I think it requires running a script because Jetbrains doesn’t support LSP plugin installation ( through the IDE tools anyway ) on free versions of their products, apparently.
I do believe an RT editor would be amazing idea in general. Maybe we can use it to expand in the future to make a more general purpose game engine for other projects to mess with rt.
KDL looks pretty interesting, but also will probably take a long time to get all our cont ribs used to it. Also do the major ide’s have syntax highlighting for it?
1 Like
I understand what you’re saying, and I think I understand the motivation to maintain consistency in the tooling specifically in regards to the languages used; Rust is much more of a beast to learn, but I think wanting a language server to be written in a language that’s easier to learn is antonymic; language servers are by their nature something that you’re not going to be contributing to the development of without a significant expertise in compsci already. I respect what I believe the intent is: consistent tooling and accessibility, but making or contributing to a language server is simply not an accessible thing, like heart surgery is not an accessible thing.
You completely ignored the rest of my explanation. This has nothing to do with “Rust is harder to learn, most contribs don’t know it.” The fact of the matter is that a proper, maintainable language server needs to heavily interact with RT’s existing code, which is simply impossible if the project is written in Rust.
We’re approaching territory where people (probably rightfully?) characterize me as argumentative, so I’ll bow out at this point. I also don’t know enough about Rust to point out where it actually could(if it can?) directly interface with the existing code.
YAML has its flaws but if I am to be frank, it does things very compactly and with understandable(ish) inheritance and indentation.
The main issues I encounter with it feel like they aren’t strictly language-related:
- Not knowing when you typed a component name wrong sucks.
- Not knowing the specific value input allowed sucks.
- Not knowing the formatting of something like enums sucks.
- Permitting inconsistent indentation sucks.
- type:sucks (but imo not that much).
Most of these feel like they could be dealt with via some IDE rules or however that works. ECS enables us to prototype swiftly and I feel YAML is a perfectly servicable way to work with that system.
1 Like
Looking at KDL, I quite like the syntax for it but as long as there is not a good LSP server or other form of validation and auto complete that works in rider I am going to be pulling my hair out every time I work on it. (validation being more important than autocomplete)
(I also do like the lisp style DSL notafet mentioned, but I am one of those insane lisp people. If you use parinfer-rust or paraedit it is not too bad)
As a maintainer of a fork, I would also like to have some kind of linter that can just enforce yaml/KDL/whatever coding standards automatically because those PRs take way longer than they should to review (especially when they are made by inexperienced contribs). We also have a number of contribs that don’t really care about following conventions unless I remind them on every single PR, so having a failed test I could point to would be nice.
I would propose ditching YAML in it’s entirety and just writing prototypes in c#. That lets you take advantage of all of the nice features of any c# IDE. The downsides of that are that you would still need to maintain a separate serialization format, but you could throw out the idea that it needs to be human readable. You would also be unable to do prototype uploads without scsi, but I really don’t think that is too big if a tradeoff for the positives this would bring.
I know a lot of people want a proper editor, but I personally don’t care. It will always be faster for devs that know what they are doing to write plain text and as a maintainer of a ss14 fork, I don’t want to review PRs from people that don’t want to learn how to write out prototypes in text form. Additionally, one of my favorite features of RT is that I don’t need to interact with a engine editor if I don’t want to. I hope the ability to do this is maintained into the future.
On a another note, having a documentation website for prototypes and components that is intended for people that don’t know c# would be great. I think a lot of people are scared away by the lack of documentation more so than the actual coding part.
Sorry, about how rambly this is. I am fairly tired and did not want to forget to respond to this.
Being fairly new here, I won’t comment on the YAML stuff. I’ve only ever used it in pretty strict environments so never had a problem, here though I can’t say!
However, an editor to add, read, edit everything honestly sounds great and I believe would pay dividends massively and speed up development significantly due to tighter control on how people contribute leading to higher quality PRs and changes.
I do also understand this isn’t a simple task, but out of all the options I believe it’s the “best” choice long term!
I’ve used several whatever-as-code solutions for work for the past few years, sometimes from vendors and sometimes for game projects, and I doubt there’s much to actually talk about, so just from my own experience:
→ YAML does suck. The problem is that it’s kinda everywhere. Moving off it does mean you lose a few things:
- Generally everything can format it, colour it properly
- Ingesting it is really common too - it’s rare to find a situation where any data can be ingested - maybe a json import - and it doesn’t also support YAML.
- It CAN be easy to type, remember syntax for, and whatever. It CAN also be easy to review.
If you move to something else - the language that PJB flagged looks a bit like HCL, which I use for Terraform a lot - it can provide quite a lot of wins. I think it’s worth investigating.
It might be valuable to take a complex YAML file we currently have and test out how it feels to transcribe it by hand into the target language, and if it passes that sniff test take a look at options for automatic transcription.
Otherwise for the language server/editor needs - the tech isn’t important itself here, it’s what the requirements are.
Really that’s the same for the language topic.
First thing to do is write down requirements.
If there was something that’d be nice which already exists - feature-matching the current VSCode plugins would be a good start. I’ve found it really useful to be able to just open some Body YAML, go “what on earth is this property again I forgot” and be whisked away to the C# for it.
2 Likes
What @PJB is referring to is that a lot of C# tricks are being used to parse YAML. For example, the magic [RegisterComponent] (along with other datafield attributes) are used in entity prototype parsing. If you did this in any other language, you would need to maintain a list of components, datafields, types, default values, etc. for every single component defined in the game, and keep it maintained across (frequent) component and system changes.
If you used language X, then you would have to write a C# compiler frontend in X just to extract what is needed. At that point, it’s probably easier to use C#.
Now of course, if you could embed an X language interpreter/compiler in C#, then it would have access to all of the C# magic…
On a another note, having a documentation website for prototypes and components that is intended for people that don’t know c# would be great. I think a lot of people are scared away by the lack of documentation more so than the actual coding part.
This would also need to be generated from C#. Right now the best way is to look at the component definition in C#, hope there are comments explaining what the component does and what the fields mean, and know the conversion rules between the names in C# and YAML.
I mean if c# syntax wont change much (likely)
the attributes used wont change much (likely)
someone could probally just abuse a library like tree-sitter or something to parse c# code and get that information.
- Semantic analysis of the code is not enough for a maintainable solution, as I have explained above.
- You cannot even do semantic analysis with something like tree-sitter like you are proposing. That requires the entire C# compiler, which there’s only one of.
Please don’t come into conversations like this if you don’t know what you are talking about.
Food for thought, yamldotnet has a lot of overhead, I wonder if the KDL parser is better.
In terms of investment I think long-term the best thing is prototype editor then > lang migration, though lang migration is probably easier to get buy-in from contributors willing to help than starting a prototype editor.
1 Like
Writing your own language for this seems a little overboard in my eyes, especially when there doesn’t seem to be very much specific “special” that need to be described in the current prototypes that we have. But perhaps that specialness is also because we can’t describe it in yaml 
RobustEditor sounds cool, it would be nice to have some strong requirements laid out for it as a project so people can give it more thought. Is it targeting yaml developers than C# ones? Should it somehow hot reload? What’s the MVP here? etc.
1 Like
I had a play with Pkl and I think it could be a possible option for a YAML alternative.
Here’s a sketch of what prototypes might look like - prototypes.pkl · GitHub
These could be generated through reflection
Then here’s a medicine file which would use these – medicine.pkl · GitHub
This can be converted to YAML which might allow it to be adopted incrementally:
pkl eval medicine.pkl -f yaml
reagents:
- type: reagent
id: cryptobiolin
name: reagent-name-cryptobiolin
group: Medicine
desc: reagent-desc-cryptobiolin
physicalDesc: reagent-physical-desc-fizzy
flavor: medicine
color: '#081a80'
metabolisms:
Medicine:
effects:
- type: Drunk
conditions: []
slurSpeech: true
- type: GenericStatusEffect
conditions: []
key: Stutter
component: ScrambledAccent
But there are also C# bindings to parse it directly (GitHub - Rafaeruo/pkl-csharp: PKL lang bindings for C#)
Everything is typed so the author can check for validity and get feedback if they are using invalid properties or values.
Some downsides I can see:
- The CLI tool is a native executable and can be used to check files, but the VS Code extension currently requires Java for the language server (there seem to be plans to make this native blocked by Publish a native executable · Issue #60 · apple/pkl-lsp · GitHub)
- There’s no public formatter currently – apparently coming in June build
Probably best not to get into the weeds about how migration would be done as per se, there’s a few gates to pass before that is the work to do (e.g. if you migrate off YAML do you still support it whilst moving over, is it permanently supported as a legacy format, is it a major engine release that mandates migration? lots of questions that don’t involve fun engineering problems)
There’s going to be quite a few candidates. I’d guess many will be “something that looks a bit like HCL but doesn’t have all of Hashicorp’s bad decisions”. It’d be up to the person who decides to do the tech exploration to pick one, and as long as it’s recognized properly on Github, Rider, VSCode, etc and has a decent C# parser it might just be a manner of taste. I suppose being recognizable to newbies without scaring them off is an advantage. Also good parsers in a good variety of languages would be best, but that’s not that important for Wizden itself.
At the moment, ignoring technology:
- Most YAML could do with better in-file documentation. The files usually are laid out well enough - you get animals.yml sometimes but you can generally find what you’re looking for with some searching and reading file names. But “why” is often completely divorced. When you are looking at an entity prototype and you can only tell what it is from its description field and have to guess what it’s supposed to do via cross-referencing the YAML, it’s needlessly cumbersome. A language server which could show docscring on mouseover would signfiicantly help, but just adding comment lines to YAML to group and explain what is even going on would speed up comprehension and reviewing. I think this needs to be done regardless of language choice of the static data.
- There’s an argument for scoping READMEs files to directories when docstring alone isn’t good enough to explain what the intention is.
- Many of the tools that the solution supports - e.g. to validate YAML - are just hidden enough to allow devs to forget about them. I’ve used makefiles to help with this problem but something like that that doesn’t involve, like, make would be handy.
In terms of workflow: I have probably a false memory of the client supporting YAML prototype reloading at runtime. Currently my workflow is “if I edit YAML, close and re-open the client”. For me that’s always the most annoying part of messing with YAML (because I use that LSP in VSCode).
there Should Be client hot reloading for prototypes, it sounds like it was somehow broken, as it was and is a feature.
the Pkl parser given here relies on running the Java parser as a service and talking to it with messagepack, rendering it pretty much unusable.
Just making sure I’ve at least mentioned one other way static data can be designed/generated/used; some sort of man-in-the-middle schema where you generate code from the schema and then work with that code. They can be very fast - especially when you want to serialize and save/transmit data over the net/etc - but has drawbacks for “normal” static data use. Still interesting tech to be aware of. I use Protocol Buffer personally but the gamedev tech equivalent is Flatbuffers.
https://flatbuffers.dev/tutorial/
Still think something a little HCL-like like KDL is likely the best option for storing game config static data.
Just need requirements written down for what a new language etc would need to fulfil to be better than the current.