Nathan (GDQuest)

Unity I think has a longer track record of having a large pool of professionals using it. When I worked in mobile (partly with Unity), everyone knew you couldn't do much against games getting stolen or ripped off, on that market it's so common. Even much larger teams couldn't avoid it.

A lot of people have fear of things being "stolen" from them, starting with their ideas. We frequently hear about those fears from students, who need reassurance.

It takes a lot of learning to understand the technologies you're using. Until everything clicks for people they go with what they hear.

This is so nice! I'd love to get a peek behind the scenes and learn how you set that up someday when you have time.

Screenshot of the recursive hash function in the array class in the Godot engine source code.

Just looked up the code out of curiosity, it calls recursive hash on every array element. So it seems to do a variant hash on every value + merge that into the hash it's already building.

The arrays are lists that can expand and I suppose if you add lots of things they might need to move to a different memory chunk and address, and if so you couldn't rely on the pointer being fixed. A developer who worked on core would know better if that's the reason though.

I was curious as to why the array elements were used back when looking at the source code, because as far as I understood, objects/nodes are hashed by their pointer address.

But for arrays, I remember that it iterated through every element in the array.

Just tested, just had to use ../../../project/path on mac of how mac signed apps are packages with the exec. in a subfolder. Seems to be working well! We have high schools that use macos, they should be happy about this improvement. Thanks much!

Not decided yet, I'd definitely like to say hi to Kay and you and many others. We're all always busy otherwise, it's a rare opportunity to sit down and see how everyone's doing around a (hopefully good) cup of coffee.

Glad you found someone! I'll be looking forward to the game :)

Ah, you can put that directly in the __sc__ file? Do you know if the relative paths in there work on all systems? I've been shipping a separate projects.cfg file to students, but on macos and some linux distributions the paths to projects must be absolute to work.

Merci beaucoup pour les retours ! Je suis ravi que dans l'ensemble, ça ne se soit pas trop mal passé pour vous.

It's really unfortunate. The open contribution and review model is labor-intensive in itself already, with most contributions being small pieces that take more work to review and onboard people than for core developers to do the work. If the trend continues it might push it to plain unsustainable.

Merci pour le partage !

Est-ce que ça s'est bien passé ? Avez-vous des retours sur le contenu ? Si vous avez du feedback, il est toujours bienvenu.

Thank you very much for the recommendation!

ssr demo for godot release page

Du coup, toi qui viens apprendre, tu te retrouves avec un logiciel 10 ou 100 fois plus complexe que ce dont tu as besoin, wt même avec un outil de programmation visuel, ça pèse sur ton usage au quotidien et augmente la charge cognitive quand tu apprends.

On recommande souvent Unity ou Unreal. parce que ce sont des moteurs très connus et qu'il y a énormément de ressources pour apprendre et un large écosystème. Unreal c'est vraiment pensé pour faire des jeux comme Fortnite avec des très grosses équipes avant tout.

Pour du hobby à temps partiel, dans tous les cas je ne recommanderais pas trop Unreal ou Unity qui sont vraiment d'énormes machines complexes. Ni forcément Godot qui est un entre deux plutôt pour les indies (quelque part entre GameMaker et unity).

Ce qu'on apprend avec la programmation visuelle dans un outil comme Construct ou GameMaker (programmation avec des sortes de blocs d'événements, un peu comme RPG Maker) se transfère pas mal vers le code, si jamais tu voulais sauter le pas plus tard.

Oui, la programmation visuelle, ça évite toutes les difficultés liées à la syntaxe, au début quand on écrit du code, on fait beaucoup de fautes de frappe et beaucoup d'erreurs de syntaxe et ça peut être frustrant.

Déjà par rapport à pas mal de réponses que tu as reçues, plutôt que de partir sur un outil ou un autre, je te conseillerais de partir dans l'optique de tester plusieurs d'entre eux et faire de petites expériences pour voir lequel est le plus fun ou stimulant pour toi.

Salut Avorpal! Ça fait longtemps.

Si tu as des questions particulières sur Godot ou besoin d'aide sur le choix d'un moteur, n'hésite pas à demander.

Je dirais que la meilleure recommandation va dépendre en partie de tes objectifs, du temps que tu as disponible, et de tes projets.

Everything you add to this project is so playful! I love the attention to detail

Because c# runs in a separate runtime, anytime you interface with the engine, there are one or more costs you have to pay. There are costs of converting data to and from C# plus the overhead of calling into the engine through a bridge

In this case it would not work because the code is mainly calling engine functions and operating with engine data types. There's a big overhead when you do that in C#. Keeping the code as is, it might be equivalent or possibly slower than gdscript.

Actually in this case, the overhead of C# calling into the engine is at least equivalent and probably higher than GDScript.

The big gains are only for heavy logic run exclusively inside of the C# runtime, like running performance intensive algorithm with pure C#.

But again, I'm just saying, you know, that's if you measure the GDScript processing time itself is a/the bottleneck. Then with C++ the ceiling becomes much higher.

I'd say it works especially well if you can build this script around having an array of characters and have all the logic where you loop over and update them. It's still worth trying once to know when to do the switch - depending on how you build the code it's more or less work to convert.

Yes, exactly. That's the strength of GDExtension, especially if you co-locate and bundle a bunch of logic into one big function and entity like you seem to have: then the day you need it you can get speed gains by doing a one-to-one translation to C++.

(Though this is a more minor gain, it's just small things the engine does notably for accessibility and ease of use that scale linearly with the number of entities)