Видео

I fixed it! I missed the part where you need to put "using Godot;" before "using System" in the Extensions file!

Jetbrains Rider

In theory it is possible, but how you achieve it depends on what you want to do. If I recall correctly, the level loading feature supports subdirectories and changing the parent directory should be relatively easy by looking at the code. As far as custom color highlighting, the main text is in a code control so color highlighting is possible. It could also be done with BBCode, but would require heavy modification of the files to convert everything from the code block. I chose the code block for simplicity. I'd need more information to make any kind of useful suggestions. Thanks for watching and I hope you find it useful!

Interpolation is a whole discussion in itself. There a many different ways to interpolate objects in a game. Interpolating physics bodies is now possible in Godot 4.3 out of the box which should, in theory, eliminate the need for separating the sprite from the physics body for smooth movement. I haven't tested this yet, but my suggestion would be to upgrade to 4.3 and enable 2D physics interpolation. Thanks for watching!

Math foundations are the most important thing in any developers toolbox. Thanks for watching!

Impossible to say without more information unfortunately. Which type or namespace is missing? This error is typically caused by a missing using statement at the top of a file.

Been extremely busy with other projects but I plan to get back to posting soon. Thanks for watching!

Of course, and C++ will perform slightly better than properly written C# code...the point of the video is to illustrate the difference between GDScript and C#. However, C++ is not something most people using Godot are going to be comfortable with. Most use GDScript because it is easy and beginner friendly. C# is in the middle for difficulty and nearly as performant as C++ if implemented correctly. Also, it's not really just about math as iteration is the main drawback of using GDScript. It struggles when iterating over collections and that is something that is prevalent in ALL code bases. It's impractical to implement C++/GDExtension for everything that requires some sort of iteration. At that point, you should just write the entire project in C++...

.NET 8 works great and I would use that. It will require that change the target framework in your csproj file though. Pretty easy to do, just google it. cheers!

@@hamsterbyte thank you!

vel is a variable of type Vector2 which means it is defined somewhere in the code that is provided in the video, or the prior video; this is a series. IIRC this controller uses a series of methods with ref Vector2 arguments to modify a velocity variable incrementally before finally assigning it to the velocity of the character body. If you are unfamiliar with what a certain piece of code does, I would recommend that you watch through the entire series, pausing to make sure you understand completely. This series covers all the basics needed for a platform controller. Unfortunately, this is by far the most beginner friendly tutorial series I've uploaded. I'll try and make some more beginner friendly tutorials in the near future. Sorry I couldn't be more helpful, it's been a while since I've reviewed this particular code. Cheers!

@@hamsterbyte thank you!!

Is the script attached to the player?

@@hamsterbyte yes, as far as I know, made the script the same way as told, plus when following other tutorials the scripts work, so it must be something else

There's a few things that could cause this, if you followed the video exactly there should be no issues. If your code is correct, verify that your input is set up correctly and that the script is attached to the proper node. Without seeing your project there's no way for me to identify the issue.

Thanks so much for the kind words. I'm glad to know that this helped you out!

I'm not sure why the code itself would be generating negative entropy values. I did not experience this issue in my testing.

GDScript is faster to learn but useless outside of Godot. If you want to make a web build you have to use GDScript or a different engine. GDScript is similar to Python, just make sure to read the docs and use whatever bindings they have available

Why does using GDScript make a game easier to port to console than C#? There are many games written in C# on consoles.

@@hamsterbyte Well, first reason is that GDScript has no GC, which makes things easier. Second reason is that most of Godot's users use GDScript, therefore most efforts will be put for porting GDScript games to console, not C#. Proof of that is the free switch port that has been created: it doesn't support games using C# or GDExtension, only games using GDScript.

There were a few mistakes in the first run through of the GLSL, it was addressed at the end of the video

All new videos are done with a larger font and scale

Hope you find it helpful!

I'm pretty sure GDScript has hot reloading...so you don't actually have to run the project again; you can just modify and save the code while it is running. If you like GDScript then you should use it, but you should also learn how to make a loading screen if you plan to do any sort of proc gen with it.

@@hamsterbyte Depends on what you have changed. But yes it has that.

You're very welcome I hope it helps!

I have the requirements and I am able to load the project without errors. However, the plugin will not enable and it doesn't throw an error when I try to enable it. I'll keep banging on it to see if there's something in godot's config that is incorrect. I am using Godot 4.1.3 with .net

Procedural generation is quite difficult if you don't have a lot of experience with it. It's essentially always the same concept; wrangling noise into something coherent. This video is on wave function collapse, but I also have another that goes over cellular automata to make a terraria style map with auto updating neighbours. Hope you find the content useful and thanks for watching!

@@hamsterbyte I'm going to go and look for that right now. Cellular automata is what I'm using right now for my maze game. I got the first part figured out. Now I need to do the pathfinding and backtracing etc. But I'm loving the idea of having the code randomize the maze so you don't have the same one twice!

@@shanefoster5305 obviously for pathfinding you will want to use some variation of Dykstra's or A*. The main thing to remember is if you are generating the maps procedurally, you will also need to populate the data for the algorithm after the generation is completed to calculate the nav mesh and weights/values

@@hamsterbyte Thanks I'll look into that. I was just going to modify Wilson's maze algorithm to 3d and then at dead ends place a door that teleports them to the rooms that would be elsewhere. Wilson's maze has pathfinding in it while generating the maze. But your recommendations might be more appropriate and possibly easier.

I have several on my channel, but some are quite advanced.

Mathf is a library that contains math functions for floating point numbers. Inf is infinity. Clamp confines a number between two values. There's also ceiling and floor operations to round up or down, though casting a float to an int will round down as well, albeit at the cost of boxing. Vector2 is also not confined to the game dev world and C# has its own built in version in System.Numerics

Exactly

Without seeing the exception it is impossible to diagnose. Glad you found the answer and sorry for the late reply! Been a pretty crazy month for me

The algorithm here will not work for 3D; it's a simple cellular automata. 3D would be better represented by marching cubes or wave function collapse. Depending on the proposed size of the map, marching cubes and voxelization may be required. Other considerations would be chunking, texture LOD, and asynchronous loading. Have a look into the things I've mentioned - they should point you in the right direction. Thanks for watching!

Thank you ! :)@@hamsterbyte

Because bubble sort is easy and stable. The test isn't about whether or not C++ is faster than C#. It's about GDScript vs. C# and it tests the speed of the operations when they are manually implemented. Using a built- in function that binds to the C++ backend isn't the same as comparing GDScript performance to C# performance. Congruency is paramount in performance tests, and congruency is not possible if you use GDScript bindings. The whole test is invalid. That being said I could have used quick sort and C# would still be faster than a hand coded GDScript version...

@@hamsterbyte it just makes the comparisons useless, because you dont keep the use case of gdscript in mind.

@@Snapper-gaming Is the built in sorting function in GDScript 100% congruent with the built in sorting function in C#? That means the logic is functionally identical and contains the same number of operations/iterations. Imagine you have two cars in a race. They both start at the same place but one car takes a winding road to the finish and the other takes a straight road. Is the car that arrives first the faster car? Well, maybe. It depends. Was it the car on the longer route? If it was, then yes. Was it the other car? Then maybe, you can't say for certain. The test is not valid because the conditions are not congruent. Garbage in, garbage out. That's why congruency is so important in performance tests. Do you think I chose bubble sort because it's fast? I chose bubble sort because it's a worst case scenario and illustrates the relative performance of the two languages when given an iterative workload. Before you make a counterargument to a series of empirical tests like this you should first understand the original argument. The source code is on screen so anyone can replicate these tests and I encourage you to do so. The data presented in this video is not my opinion, it's factual evidence. Your opinion that the tests are unfair is irrelevant, baseless, and provides no counter argument to the evidence that was presented. The solution to the issues this data uncovers is not as simple as saying, "just use the bindings" or "you'd never use bubble sort in your game".

Thanks for watching. I hope my content helps you out!

@@hamsterbyte I think it will. Looking forward to more content. Gonna search through what you have later today before I start making requests. :p Keep up your hard work. Hydrate.

99% of people

Literally most of North America, which is where I Live. Depending on your location the pronunciation may vary, though I think we can all agree it's not pronounced Go Dot.

@@hamsterbyte I live in Europe and its still mostly called godoe

@@hamsterbyte Where most people agree is you pronounce it however you want :) Ariel Manzur and Juan Linietsky pronounce it Go-Dot and always have and they created the engine.

@@Even-Steven Akshully, the name comes from a Samuel Beckett play called "Waiting for Godot". There are two widely accepted pronunciations of the name Godot. Guh-dow and Go-dow, depending on the locale. Go-Dot is an incorrect pronunciation resulting from a language barrier as neither of the creators are native English speakers. As you say, it doesn't matter what you call it. The engine would still be great even if it was called garbage. That's pronounced gar-baj btw. 🤣

You're very welcome

That's valid, but as you say it won't really affect performance and I do find it more readable with the 0 checks. That's the signature I expect to see when iterating over a Moore neighbourhood. Entirely personal preference. Thanks for watching!

this loop will likely be unrolled as a compilation step and this iteration won't be in the code at all. i don't know if the nested for loop will prevent unrolling. for(int i = 0; i<9;i++){ int x = i%3; int y = i/3; do stuff} when we unroll this loop we can see that x and y are all constants now and any of these calculation can be factored out also any continue will just skip that iteration in the compiled code entirely.

While Godot offers interaction through GDNative with C++, and even community-supported implementations for Rust and Go, C# provides a compelling alternative due to its balance of performance and developer friendliness. C#'s syntax shares similarities with JavaScript, making it a more approachable option for a wider range of programmers compared to C++ or Rust. Additionally, recent advancements in C# compilation, such as Native AOT, allow it to achieve performance levels comparable to lower-level languages. It's important to consider the technical merits of a language beyond historical biases. While C# may have faced negativity in the past due to its association with Microsoft, its strengths in readability, maintainability, and performance make it an excellent choice. Furthermore, the job market for C# developers is significantly larger compared to GDScript developers. However, for novice programmers or hobbyists, GDScript is a well-suited option due to its approachable nature. That being said there are a few caveats: Web Export Limitation: Currently, Godot does not support exporting C# projects directly to the web. This functionality is under active development with the release of .NET 8, but it's not yet available. Marshalling for Godot Consumption: When using C# with Godot, marshalling may be required to bridge the communication gap between the languages. This process can impact performance if not carefully managed. It's crucial to identify which parts of your C# code necessitate marshalling, scene tree access is the biggest offender here. Techniques exist to minimize the performance impact of marshalling. While marshalling adds some overhead, most well-written C# operations will still outperform their GDScript counterparts.

You need to make sure to install the Godot plugin in Rider. Settings>Plugins and search Godot Support. Thanks for watching!

@@hamsterbyte I already installed it before but I fixed it by reinstalling Rider, maybe my old one corrupted or sumthing. Thanks anyway.

@@swiftypopty1102 entirely possible. I always keep Rider up to date, which has before caused plugin incompatibility. Glad you got it sorted though. Happy coding!

Your custom resource class must also be tagged with the tool attribute and don't forget to build the project to propagate the changes to the editor. Thanks for watching! using Godot; [GlobalClass, Tool] public partial class PickupItem : Resource { #region VARIABLES [Export] public Texture2D icon; [Export] public string name; [Export] public StatType statType; [Export] public string description; [Export] public int amount; #endregion } public enum StatType{ Health, Mana, Armor }

Seemed pretty clear to me, try watching it with the volume on.

@@bagboybrown I was clear that I was thankful for the video and just giving feedback. Don't need to take it to heart bagboy.

@@Lexie_TJust stating the facts. He literally tells you why you do what you do at every step so if you couldn't figure it out I can only surmise that you had your audio off.

​@bagboybrown What did he mean at the timestamp 14:45 when he said open it in our ide? the only ide i have is an arduino ide, how is it obvious to everyone what ide he is using? Im asking you because it seems like you understood it.

@@TriviaQuizocityThat's exactly what he means. I'm not familiar with Arduino, but Rider Jetbrains (paid) or Visual Studio (free) are both compatible with Godot.

You should not modify the positions or bounds of the grid or it's cells at runtime. This system calculates that information when the application initializes. You would need to give me more information in order for me to supply a more suitable answer. An out of bounds error in the Observe method indicates that you have modified the bounds of the grid after the system has initialized those values; the system is not designed to handle this behaviour. You can identify the exact location of the error by following the stack trace. Without more information on exactly what you are trying to achieve I am unable to assist you further.

Ive encapsulated each grid into a class called a wfcregion. i have a wfcregionmanager class that organizes each region. It could be argued that i could have just made a grid manager, because a region is basically just a WFCGrid but im a few hundred lines of modifcation in so its staying :) my reasoning for doing this is that ive noticed on larger grid sizes the algorithm fails to collapse, so im breaking them down into separate "regions"(customizable sizes but ill probably stick around 16x16) so far their success rate is much higher. each region will generate and down the line take information from the bordering regions to update its possible tiles before generation.(however right now im just implementing independent regions before i start making the regions interact) in the constructor of the WFCRegion(remember one grid per region), i offset the coordinates of its grid's cells. So region 1's cells[0,0] should be (0,0) while region 2's cells[0,0] would be (16,0)(region 2 is to the right of region 1) I feel bad as i feel i may have jumped the gun asking the question, as my issue currently lies in WFCGrid Observe() at if(!cells[coords.Coordinates.X, coords.Coordinates.Y].Collapsed){ return coords;} I believe that even though i offset the grids cell coordinates in the constructor im not properly handling or updating the entropycoordinates since when i pass EntropyCoordinates coords into the cells 2d array i get out of bounds. again, i feel like i jumped the gun asking you and learned a bit more about the entropy coordinates after I asked you. I havent found the solution but I think im understanding it all a bit more. I appreciate the help! @@hamsterbyte

C# is years ahead of GDScript and has a lot of useful features that GDScript does not. Interfaces are just one example. There are many other techniques that I use in my normal workflow which would be impossible in GDScript as well. The shortcomings of GDScript make it quite difficult to maintain DRY principles. Don't get me wrong, I'm not a fan of modern clean code practices as they often lead to performance degradation and that has no place in game development, but DRY is something you should always try and stick to wherever possible. For example, I use a lot of generic classes and methods so that I can reuse certain portions of code for things that are similar but not the same. This is particularly annoying because even in C#, Godot does not fully support generic classes. github.com/godotengine/godot/issues/79519

Great question! If you are looking for a way to increase the performance of your TileMap based environment, I can steer you in the right direction there, because a compute shader is probably not the way you want to go. First let's ask a few questions. 1. Do you need to update the entire TileMap at once? 2. How and when are you calling the SetCell method? 3. Are you using a single TileMap or a series of them broken up into chunks? Check my channel for the video on making a terraria inspired tilemap generator. The first part of it is actually generating the tilemap using noise and then I give more detail on how to update the cells using the Moore neighbourhood and cellular automata. I also have a video on Wave Function Collapse that uses a TileMap based system and is quite performant as well. Now, if you want a little further info on the questions you asked I'll address that in two parts. 1. Using SetCell on your tilemap is a major bottleneck for a large dataset if not done properly. Unfortunately, if you are using a tilemap to render the visuals and trying to access that tilemap directly through the API, there's no way to fix that. It will always be a bottleneck, and that bottleneck isn't entirely related to the marshalling inefficiency of C# in Godot. The same bottleneck will be present in GDScript as well. It's down to the fact that SetCell must be called from the main thread. Since there is only one main thread, that means the logic will always be single threaded. You can run multithreaded CPU code in Godot with things like CallDeferred or CallThreadSafe, but all that does it wait for the main thread to become available and call the method there when it is. 2. The reason you cannot use a normal shader to run the simulation isn't because of Godot. It's because normal shaders and compute shaders are entirely different things. Graphics cards are purpose built for rendering pixels to the screen and can consume normal shaders without the need for any extra instructions because they are able to infer their usage directly from the shader code and are typically dispatched automatically as part of the rendering pipeline. Some examples of this would be fragment shaders or vertex shaders; this behaviour is not unique to Godot, but is true of all game engines and graphics libraries I have worked with over the past decade. Compute shaders are not rendering shaders, they are a set of custom instructions that are executed by your GPU. Essentially, you are trying to force your GPU to work like a CPU and though possible, it doesn't really WANT to do that and it needs quite a lot of hand holding. Your GPU is unable to make the same inferences about your custom compute shader that it can for normal shaders. The first shader in the video exists solely because we can't use a TileMap for rendering due to the single threaded constraint. The fastest option is to run the simulation logic on the GPU and simply return the updated dataset to our rendering shader which is also be executed by the GPU. The CPU is acting as a bridge between the two shaders and is still the bottleneck in this application, but since the single threaded logic being executed by the CPU has been minimized, that's where the performance gains are realized. If performance is paramount in a particular part of your game, it is best to execute as much of that logic as possible without accessing the Godot API; unless you are writing C++/Rust in GDExtension. The worst performance hits will come from accessing objects in the scene tree. Most of the data classes are written in pure C# in the .NET implementation of Godot and they can be used freely where applicable. I hope that helps to clear things up and thanks for watching!