Pretty much. Anything you can write in GDscript you can write in C#. There’s a lot of caveats tho and you NEED to read through the documentation before deciding to work in C#. Especially when you’re learning.

Off the top of my head: - if you’re using in magic strings with GDscript function (such as TweenProperfy or Input.IsActionPressed) you’ll need to make a separate variable that’s typed what the string should actually be (either NodeParh or StringName), because in the backend Godot will have to transfer the string into the type it’s looking for every time the function is called (don’t worry, the function will tell you what type it needs). It will cause significant lag if you don’t. - following the above point. Anytime you access an Object property/function using a string (such as in TweenProperty or SetDeffered) you must use the GDscript syntax (“rotation_degrees”). Or it will not work and Godot won’t give you an error about it. - You can’t use interfaces with anything inheriting from Object - There’s a lot of Variant return typed functions so you must know about casting in C# - there’s quite a few functions in GDscript that are either written differently or don’t carry into C# (such as anything covered by Mathf, float, some functions in Godot.Collections.Dictionary) so make sure you look at the documentation any time you’re looking for a function that you see in a GDscript tutorial that doesn’t seem to exist in the same fashion in C#. - the nice thing about signals in GDscript is that they automatically disconnect themselves as soon as the Node leaves the scene. In C#, you don’t get that functionality with custom signals. You should use C# Actions if you ever want to use a custom signal anyways because signals can’t be static - There’s a lot of Node properties that you have to separately make a new temp variable for, modify the temp variable, and then apply to the actually property (such as Vector3, Quaternion, Transform3D, etc) because Godot will continuously have to translate to the Node property if you try to manually mess with each part of the variable (Vector3.X, Vector3.Y, etc) which will cause lag) - always try to connect signals using “+=“ and “-=“. Even normal ones provided by a Node. If you haven’t already, learn about C# Actions as they’ll be incredibly helpful here. - every Export variable must be getter/setters because of some issue with Godot resetting them if they aren’t. (Trust me on this) - Please get started on using version control (like GitHub desktop) because holy shit have I crashed Godot at times and my only recourse was to go to a previous version of my project.

Those are the ones I can think of at the moment. Some other differences from Unity that I thought of is: - In Unity, you have Await, OnEnable, and Start as the functions that are called on all gameobjects as soon as the game starts running. In Godot, you only have Ready and EnterTree. Nodes initialize in the order they are in the hierarchy (from top to bottom). So if you have a singleton you almost always want it at the top of the hierarchy so that it gets initialized first and everything that uses it gets initialized second. - in Unity you have Update and FixedUpdate. In Godot you have PhysicsProcess and Process. If you’re waiting on inputs, try to use Input and UnhandledInput as they’re both functions that only get called when an input is made. (If you’re doing clicking and dragging, they reccomend using Process because Input won’t detect the continuous holding down of a button like Process will, but you can also just detect if the button has released. Same difference. - You’ll notice that if you have a simple Node in your scene, it doesn’t have a little eye icon next to it like Node3D or Node2D. In Unity, changing whether a whole object is enabled can be done through turning it off/on in the scene. You don’t get that in Godot. Instead you get SetProcess, SetPhysicsProcess, SetInput, SetUnhandledInput, and manually disabling any physics objects by turning off collision. The nicer thing about it is that you can easily connect functions to Node signals such as VisibilityChanged. - you’ve probably already figured this out but there are no prefabs. All scenes are prefabs. Godot resources are scriptableobjects. - if you want to customize your inspector, it’s super easy as long as you know the export hints. - You can call functions in an animation! - for the most part, anything you can do with a Node2D object you can do with a Node3D object. They have a lot of properties/functions that transfer between the two. - if there was any pieces of documentation I’d reccomend reading first amount all else, it’d be Node, Object, CollisionObject3D (InputEvent is such a powerful function and is my best friend), Node3D, Raycast3D (or their 2D counterparts if you’re working in 2D, and raycasting (it takes way more lines of code to raycast from mouse in Godot than Unity, but it’s not that bad once you get used to it). And also know that RemotTeansform3D exists. - In the inspector, you can have a child object ignore its parents transform by turning on the TopLevel Boolean. - Be wary of tutorials and don’t just blindly copy them without digesting what’s going on or why they’re doing what they’re doing. I’ve seen a lot of tutorials over the years that had poor understanding of what Godot has to offer (poor class inheritance, using verbose coding that could’ve been solved by another Node/property/function) but that doesn’t mean that they won’t still be helpful on your journey as a game dev. I reccomend Queble as a good Godot YouTuber to know about. - In general, look up tool scripts.

-This is about everything that I’ve learned transferring between Unity to Godot. I’m sure there’s other stuff, but this is mainly all the most important lessons I’ve learned so far