The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.
In the case of Godot a lot of functionality is available out of the box. Biggest example is input management. You have an InputMap section where you define actions and can assign keys/buttons to it. Gamepad layout is automatically handled for thousands of controllers so that "right face button" is the same input event whether the user is using an xbox gamepad, a pro controller or generic.
There is an official Asset Library but only for free, MIT licensed assets. There's nothing stopping someone from creating a paid one, though.
When I asked for a good engine, ppl here would recommend Unity and Godot.
The difference seemed to be that Unity comes with everything out of the box and Godot, while free, would require you to "fight the engine" along the way to build a game.
Some people switch engines but want the new one to accommodate to the previous workflow. You can try to make Godot work like Unity but you'll fight the engine all the time because it's designed differently. So maybe that's what you read. 3D support is much better now than it was before so it could also be that.
In my experience, Unity felt free to play, pay to win. I felt that the engine was full of holes in stuff that I expect an engine to handle. It's not a small percentage of games that need controller support, or tilemaps, or proper sorting of sprites. Some of that eventually became officially supported by the engine but by that time I was more than happy with Godot.
I've seen people give 2 hour long talks about how they managed to force Unity to do pixel perfect rendering, while in Godot it's a couple of checkboxes.
So I guess it depends a lot on what you're trying to do. For some games Godot might not be the best choice and that's fine, you have to choose the right tool for each project.
Most people I know who use Godot, myself included, find it easier to use than Unity. I don't know why you believe you would be required to "fight the engine." You just need to be at least be willing to understand the idioms and methods of a particular framework and work with it - otherwise why use a framework at all?
For me this feels like finally jumping back to the good timeline.
From the user point of view, I think there are two main types of experiences on the Web:
a ) Interactive documents. Basically web 1.0 but today we want fancier transitions and interactions. This can be provided by htmx and should always have been developed declaratively. It should ideally be provided by the browser and htmx shouldn't need to exist. Examples of this are Gmail and most social networks and forums including this one.
b) Desktop apps-but-I-don't-want-to-have-to-install-them. This would be things like Google Docs, Photopea and most real-time games. To deliver this, right now we have a browser that has become almost an OS inside an OS, to the point only Google can keep up with the complexity. On top of that, we pretend apps are documents and for all the imperative code we need we use a scripting language that was not meant for that, and we need a really complex VM just to keep it more or less performant. For this use case I think at some point we should move all the way into just delivering apps, if not native apps, something like wasm, where the browser tab would just be a vm player.
I agree generally with the two types of experiences, but I'd also submit that there's no easy, clear deliniating line and it's much more of a spectrum between the two types. I really think some of the quirky magic of the web comes from this doc / app hybrid thing it supports and bifurcating them fully would be a mistake.
I think the spectrum is the right mental model, too.
E-commerce stores have different interactivity needs than blogs, which have different needs than documentation, which has different needs than dashboards, which have different needs than real-time collaboration tools, and on and on and on.
Much of the framework angst is around the assumption of a singular tool for all these varieties of interaction and the annoyance that comes with not acknowledging the trade-offs.
Plus the web itself is changing, so the breadth of this spectrum is increasing. Years ago, the ends might not have been very far apart but they are diverging more with each new use-case and app idea.
The idea is that the js is used to implement the functionality that the author believes should be built-in.
In theory you could have a browser plugin/extension for handling htmx and it would work across every site using htmx.
You app-specific "code" is all declarative, just extra properties in your html tags.
With most frontend frameworks, even if the browser came with built in support for Vue, React or whatever, you'd still tons of imperative js for each single webapp to define how it uses the framework.
Imagine not having html at all. You'd have to create pages from scratch imperatively by doing things like let element = createElement("p"); element.setContent("my paragraph"); parent.addChild(element); It'd be really ugly, a PITA to change stuff and error-prone.
htmx is the opposite of that. It tries to make web development declarative again, among other things.
> Unfortunately I think it'll be held back on that front until it supports console builds
I think the Godot devs have not been clear enough communicating about console support. There are export templates ready to use, up to date and fully working on different consoles. They just can't be offered as part of the open source engine due to legal reasons. That actually applies to other engines too. In the case of Unity, to build for Switch you need to download the required software from the Nintendo Developers portal and it's only accessible to you if you get approved as a developer. If Nintendo wishes to do the same with Godot they can do it know since there are no technical or legal impediments. Since Nintendo hasn't done it so far and the Godot team can't do it for legal reasons, it falls to third parties to do it.
One of those is Lone Worlf Technology LLC, owned by one of the co-founders of the engine, so it's as official as it can get. If you don't want to work with them you now have a second option that's called Pineapple Works.
It's not like you have to pay a company to port your game to switch from scratch. I think many people get that idea.
Edit: orthography
Edit2: Just to clarify even further. If you check the process to build for switch using Unreal you'll see that the process is exactly the same as with Godot, the only difference being that in the case of Unreal it's the same company providing the base engine and the switch export tools.
https://www.unrealengine.com/en-US/blog/launch-your-game-on-...
>It's not like you have to pay a company to port your game to switch from scratch. I think many people get that idea.
Your reply is a really good one because I totally got this impression from the other replies here! So Godot isn't fundamentally incompatible with consoles, it's just the open source part of it that is.
I think it's more just that you have to go grab the console piece separately, in the same way that Ubuntu can't include the mp3 codec as part of its distribution even though you can trivially go and install it yourself for free
I come from phaser and am currently working as a game designer. Godot was just what I needed since I wanted a visual editor(it makes lots things quicker) but still be able to code(unlike construct, for example). I also needed to test my stuff on mobile and Godot can export to android in seconds.
The scripting language took me a week to learn and two to feel confortable with, though I think people coming from c#/java have a harder time getting used to its simplicity. 3.0 will support c# and potentially anything that compiles to a dynamic library thanks to GDNative.
I contrast, Unity to me always felt like this huge Rube Goldberg machine I have to set in motion to do anything so if you want something that starts up in seconds and has fewer dependencies I really recommend it.
I've used Godot a few times and found it pretty promising. The visual editing is a cool added value that wasn't there the last time I used it. It's not something I would personally use, but I've worked with artists/designers who have made use of similar tools with Construct and GameMaker.
The last time I started work on a new game I checked out Godot again, but ultimately I went back to GameMaker Studio.
I really think Godot has some real potential, but having the console exports for PS4 and Xbox One are pretty critical.
Agreed, I can't consider any engine that lacks support for the modern consoles. Given how brutal the industry is in general, you can't afford to leave money on the table by giving up potential console ports.
That said, I understand why it's not supported currently. The process to get anything done on Xbox or PS4 is laborious to say the least, and I am unsure how an open source project would accomplish it without being a standalone entity like Unity, Epic, or GameMaker.
Monogame is not so much a game engine as it is an I/O framework. It's got primitives to get input, to draw on screen and output sound and really barely more than that.It's much more fair to compare it to SDL than to a full-fledged engine like Unity. It has some of the elements you need to build an engine, like asset management and stuff, but it's really bare-bones and expects you to design all the higher level logic yourself.
And honestly, that's fine. It's 2D only (afaik) and designing your own main loop is a piece of cake anyway.
The only real problem I have with Monogame is that it's cross-platform only really in theory. In order to build your games for multiple platforms you need to use different forks of the codebase, or at least that's how it was when I tried it.
The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.