Video

I personally prefer writing code as well but the graph can be very useful for non-programmers so they don't need to fight with the syntax. Another feature I really like is that you see an intermediate result for each node, which can help in debugging.

Unfortunately GDScript has no interfaces. It's something that certainly would add value and there is an open feature request for that (github.com/godotengine/godot-proposals/issues/4872) but I wouldn't expect anything like that to materialize anytime soon. For now the only option is to double-check that there is no typo or go with C# which has interfaces.

Thats a lot of interconnected systems and answering this in a comment isn't really possible. But to give you some ideas... A simple bag can be implemented by an array. Say you have a custom class named `Tile` which represents a letter tile. This has the actual letter, the point score for this letter and maybe a reference to a visual representation of the tile. Now you can create say 5 instances of the A tile, 7 of the B tile, etc.. and add all instances to an array - which represents your bag. Now you can just pick a random number between 0 and the array size and then remove the tile at this index from the array. This way you have simulated dragging from a bag of random tiles where you have full control over how many of each tile are in the bag. As for scoring, you would probably need extensive word lists to check against. So get the word the player has laid out and check if it is a valid word .Because each tile has the letter multiplier in its data you can now calculate a score from the involved tiles.

@@godotneers Interesting.. Like i said im still a novice but the truth is thats about the logic i was thinking was involved. thanks you for the reply.

For 3D shaders you can actually run multiple shaders. Materials have a "next_pass" property to which you can assign another shader material. However for 2D shaders this is not a thing, so everything needs to happen in a single shader/pass (which makes things like blur really inefficient as you cannot optimize it through a multipass shader). Another option would be to write some code that generates shader code on the fly and this way combine multiple behaviours into a single shader.

In this case you'll probably need another layer of models. You could do a static model , which only contains the un-changing base data (e.g. max durability, references to a visual, other static stuff). Then you'd have a wrapper model which refers to the base model and adds per-instance settings, like current durability, any applied buffs, etc). class_name ItemInstance var item:Item # the underlying item var durability:int # the actual durability Another option would be to just duplicate an item using the duplicate method and give the copy to the player's inventory. Then each copy has it's own durability. However this can be harder to migrate when you do balancing patches to your game (e.g. increase max durability for pickaxes) because now all the copies still have the old max durability. So as usual, you can decide which problem you'd like to have ;)

@@godotneers Excellent, thank you so much for the detailed and helpful response!

Sure, take your time. No need to do everything in one sitting.

Well the thing with "how to make Game X" - tutorials is that they are highly specific to a game and if you want to do something slightly different then you're stuck. I call these kinds of videos "recipe-style" tutorials. They give you a recipe to follow and you don't need to know how everything works - you just follow the recipe and get a result. The problem with this approach is that you never learn why stuff is done the way it is and the concepts behind what is shown in the video. So this kind of video is super nice if you know actually how stuff works and just look for a neat technique for a specific problem. But its not very useful if you don't know the basics of the engine and try to build a game from nothing. The most important skill really is to be able to dissect a problem in to smaller problems and then find solutions for these smaller problems. So start really small and simple and work your way up. Instead of trying to do a full blown 2d management sim, first try some simple things that you can later use in your final game. E.g. say you want to make a trigger that does something when the player steps on it (e.g. a door automatically opening for the player). How could that work? We dissect the problem: 1. We assume we already got the player movement done. 2. We need something that can detect if the player walks over it. 3. We need a way to notify our door to open close as the player enters or exits the trigger. So now we can find solutions for these problems. E.g. we can find out that there is a thing called Area2D in Godot which can detect when it overlaps with other Areas or Bodies. This sounds like it could be useful for Problem 2. We can also find out that Godot provides a thing called "signals" which allow us to notify objects when something interesting happens. This sounds like it could be useful to solve problem 3. Now we have new, more specific problems: 1. We need to find out how Area2D works and how we need to set it up so it detects our player. 2. We need to find out which signals Area2D provides and see if one of them can be used to notify our door. 3. We need to react to the notification in our door and open/close it. And so on... You see that even this very simple example requires a lot of thinking, looking up stuff and problem solving. And this is very very difficult at the beginning when you have no experience to rely on. So don't be discouraged if you haven't made your 2d management sim in 2 months. Developing games like this really takes a long time (e.g. Fallout Shelter took 5 years to make and was made by a team of seasoned developers at Bethesda).

@@godotneers Thank you soo much.....actually yesterday i watch a video from a woman dev here on CZcams and she explains all the problems she had and how she solved....and it's literally the same thing you explain here. Breaking the ideas into small pieces. Thanks again, i will change my aproach.

I'm not sure I understand what you're looking for, but in general you can nest resources. So your stats resource can be a property of another resource and Godot will automatically save nested resources with their enclosing resource.

thank you, I'm still not there yet but this definitely has sent me down the right path, what I was trying to do was make a savedata resource that would hold different stat resources that I could just put on the character/enemies, but the data in the nested resources seems to get lost somehow, still have a few leads that might help, but if not will have to go back and save stats individually

You would need to notify the UI that something has changed so the UI can refresh. This could be done with a signal or by sending events to a group. As for the modifiers, this is a pretty deep rabbit hole to get into. In general you can of course add a Modifier class which has some effects stored in it and can add a list of these modifiers to each item. The tricky part is though that modifiers usually need to trigger at certain times in the game and this may be different for each modifier. So it's really not possible to give an answer that just universally works as the exact mechanics and data models are highly game specific. In all but the simplest cases this is going to be a lot of work and iterations to find a workable solution.

@@godotneers Thanks a lot!

Yes I could just have multiplied this with a vec3(1,0,1,1) but I took this more roundabout way to show that we sometimes have to do conversions in shader code (as opposed to the shader graph which does this automatically) and to show how swizzles could be used.

@@godotneers totally legit. :) Keep up the nice content.

It takes a good while. Research and scriptwriting is usually about a month of work. Audio and video recording is pretty fast once you got the script. Editing usually takes another week, so we are roughly at 4-6 weeks per video. I'm doing this in my spare time though, so a person doing this full time will likely be a lot faster.