GDScript is not very maintainable as the code base grows. It lacks proper refactoring tools (e.g. the ones from Jetbrains Rider), static type checking, flexible object system and many 3rd party libraries which might be needed
You likely won't need to do manual memory management nor think about undefined behavior. If your writing basic c++ to handle the simulation in a game, it's going to be pretty orthodox and these problems likely won't manifest.
The purpose of recommending c++ here is:
If GDScript is too slow, reach directly for C++.
I'm specifically recommending GDScript over C# for ease of use and c++ over C# for performance.
The author "teaches workshops on AI development for engineering teams". This is nothing but a selling post for companies. I don't know what to discuss here honestly, this is more primitive bait than an average video preview picture on YouTube.
If only Lisp had better presense in modern code editors. Emacs is not enough, especially on Windows where it is super slow. I think this is what actually stops newcomers to start with Lisp and not Python
> I think this is what actually stops newcomers to start with Lisp and not Python
What stops newcomers is knee-jerk reactions about the (lack of) syntax, it's scary to see something that doesn't look like Algol, because everyone who does mainstream programming uses Algol-like languages.
Introduce lisp to anyone who knows programming since earlier, and 99% of them will have a adverse reaction to s-expressions, before they understand what's going on. Once they understand, it makes a lot of sense obviously, but not everyone even has that kind of open mindset where they could understand if they wanted to.
Symbolic expression is one thing, I would personally find it rather cool to have more first class expression as building block everywhere. However I'm not found of using explicit parentheses all around. Even mandatory curly/square brackets are superfluous with a properly defined syntax ruleset.
My crackpot theory is that what stops newcomers is how unergonomic "(" and ")" are to type on typical keyboards. If mainstream lisp dialects used square brackets instead, we'd all be programming in it!
> If mainstream lisp dialects used square brackets instead, we'd all be programming in it!
You've almost convinced/nerd-sniped me to write a(nother) new lisp where we'll be using brackets for forms and lists and no parenthesis in sight. It's a wild theory.
I've had way more issues with proper indentation in Python and YAML than I have with parenthesis in lisp. Meaningful whitespace is about the worst idea I've seen in a programming language.
How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":
$ git checkout feature-1
$ git rebase --update-refs main
Successfully rebased and updated refs/heads/feature-1.
Updated the following refs with --update-refs:
refs/heads/feature-2-base
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
Yet another one. Along with Stride, Godot, Unigine, O3DE, Flax and tens more. All look like they just want be clone of UE: generic dark UI with inspector, scene hierarchy, asset browser in the bottom and play button in the top. Zero creativity and innovation. Where's Emacs or Vim of game engines which brings its own unique philosophy?
And then the forums and subreddits are flooded with miserable folks complaining about how destructive, inextensible and unpleasant to use those experiences are.
This is not the problem of UI in engines itself, it's problem of how long it takes to bring it to acceptable state with all those moving parts. For UE, Unity and Blender it took decades.
Complaining is a lot easier than actually doing anything.
Realise that the people you are slinging mud at are actually busting their asses to provide game engines to the public some of them for free and with the source.
To be honest for most developers editors are much alike. While Emacs and Vim guys debate on their philosophies and config files others just open their favourite editor/IDE and ship.
Lol, I haven't tinkered with my emacs config in nearly 10 years now. Most vim and emacs users put together a config they like over maybe a few weekends then get to work. We have deadlines to meet just like all the rest of you.
I don’t understand this take. The abundance of game engines has never been greater, both open and proprietary. As has the abundance of indie games. Some people make a distinction between more batteries-included engines with editors etc. and “game frameworks”, which are supposedly more bare-bones libraries such as Bevy or Babylon.js. Maybe that’s what you’re after?
Complaining about the UI color and button layout of an game _engine_ is a bit like comparing aircraft carriers by the color of the rug in the control room. What about the built-in tools for organizing and connecting assets, format support, how user input is handled, the batteries-included ways to model game state, and all the ways of interconnecting all those things in the code the engine provides? Does anyone have interesting comparisons/notes around those subjects as it relates to the S&box engine?
Who cares about the UI. A game engine is the library code needed to make games, not the editor UI. Just use vim to edit your files if that's what you want.
The vast majority of non-text editing in game development isn't done in modeling or image manipulation apps, it's done via the game engine's editor. That's true whether you're using Unity, Unreal, Godot, or a homebrew engine.
There are the rare engines with no editor to speak of -- where things are either done programmatically or other textual definitions -- but they're very very very few and far between.
The engine itself doesn't have a UI, but working with any major engine without using their editor is functionally impossible.
I would suppose anyone being creative and innovative with their game engines are happily using their creation without trying to turn it into a community or business model to the point where you would have heard of it.
Emacs and Vi were both born from an era when industry standard UX had not yet been developed, so they were both explorations in relatively uncharted UX space. This kind of thing only happens anymore when you get a project lead by somebody ignorant/indifferent to established conventions who sets out to make something new without caring if anybody else uses it.
So the projects you desire almost certainly do exist, but they're languishing in the obscurity they earned with their indifference to convention.
wasd is that, and then 1-9 (tho 9 and such is hard to reach) for the weapons/spells/tools, with keys near wasd for other binds, and the mouse for free look, autorun, shoot, and alt with scrollwheel for swapping weapon, too. This way, you use practically only the left side of the keyboard, but that is because keyboards aren't even an ideal input device for gaming. Something like an Azeron device (think: Orbweaver) would be far better.
BG3 has F5 for quick save and F8 for quick restore. Like the old ways.
As for game engine, who cares how things look in-game? Just make it theme-able and mod-able. Cheaters gonna cheat anyway, no way to hold that back on the client-side.
reply