You can use a getter function to access variables if you're having trouble figuring out the load order. Generally, children are always loaded before the parents are, so you shouldn't have have problems referencing children. But if you want to access parents, you can try signals that work their way up to the parent, or attempt a getter function that fetches the reference to the parent like such: var node: Node2D: get: if node == null: node = get_tree().root.get_node("Path/to/node") return node HOWEVER, there are numerous other ways to do this too. You can right click on a node you want to access from anywhere in that scene, hit "Access as Unique Scene", and then you can access it later by referencing it with a % before its name! I've only watched so far until 37:00 so pardon if you've already discovered this. You can also hold references to (non-instantiated) nodes you frequently access in a singleton script that you can autoload! I've also heard people like to export nodes altogether to be able to reference them. You can do it in many ways.
Haha yea I try to be as real as I can! But I know that also comes with following a mistaken implementation just to fix it later.. hopefully that's okay!
This is super cool! I reccomend using canvas_items instead of viewport for scaling. it wont be pixel perfect, but it will keep things the right scale, and if you rotate things they wont look wonky. text is also way easier to deal with.
Doing a (almost) unclipped video of Godot game creation is a great idea. Also seeing how Godot is on the rise of popularity right now it really is in the right time of things. Though you do have some competition looking at many other creators, especially now that Brackeys is back and on the Godot train as well. But your quality of editing is really high, and the content really valuable for anyone learning and seeing the reality of game dev. So keep it up and I am certain you channel will grow. Great work so far and looking forward to seeing more videos from you.
I do not feel like you're explaining too much. It's always nice to have the full thought process to be able to better understand each decisions fully. Ultimately it is crucial to be able to make good decisions on your own when you're out of the boundaries of the video / tutorial / guide
Yeah, as a principle engineer who does lots of mentorship: never feel bad for this. We learn so much from how others process things, no matter what your or the other person's level.
Damn maybe you don't notice but recording the thinking process is extremely helpfull for people starting in godot like me. You absolutely got the best and most complete godot tutorial out here. I love how you solve the porblems on the fly. Maybe you don't get it right at first but iterating over the solution makes you find the answer, that is my favorite part. Keep up the great work man!
I'm so happy to hear that this is extremely helpful! It is this kind of encouragement that really pushes me to continue improving and building my channel! thanks for watching and commenting!
This was really nice. I love the approach with a long form video that includes errors and reasoning. More fun to watch than a standard tutorial and long term it gives me a more profound understanding of things. Hope to see more of this!
This tutorial is a godsend. In the past, I've faced many issues and difficult situations that I managed to solve on my own, but I was often unsure if the solutions were optimal. This video has helped me a lot. Please keep this series going!
that's so awesome to hear! you have no idea how much this means to me! Thanks for the encouragement and watching the video! i'll keep the series going!
Word of advice for coding if it works for your project - and you don’t mind it - then it works for you. Optimization is a hole you don’t want to fall down unless you know it’s something you need to be doing. I’m not saying throw optimization to the wind, but rather if it’s not noticeably impacting your experience to not worry too much about it. As someone who’s been coding for about four years and just about eight months in game development there’s a million ways to do the same thing, and most of the time there’s no difference in efficiency. The biggest difference is the depth at which each person understands it. Of course you want to limit the amount you have to do, but there’s only so much you can learn as one person. Just keep coding, and you’ll inevitably keep learning and getting better.
I really struggle with working out how I need to structure projects, and the order in which I should program in features, so seeing someone else's process is really helpful. I've learned a lot here, great video.
I'm so glad to hear this series has been helpful in such an unexpected way! Thanks for watching and I hope to continue improving this series to help yall better
The static typing you mentioned at 17:30 is massively faster at run time and all allows autocomplete. You can also static type function return types and inputs
Glad to see the beginning of the Ezra's Teacher Arc. I'm all for it. I think you videos have a great level of authenticity and I think that in combination with your skill/talent will create an audience that orbits around you! Very excited to see where this goes.
Custom resources are good for when you have set values for something but a reusable base. So they'd fit nicely for the cards, allow you to have a single card scene that you just change the card resource on and when the card is made it loads the name, description, images etc from its resource variable.
This is wonderful, thank you very much for making this an unclipped video. I was very recently looking into making a card game but all the tutorials I could find were direct solutions which wouldn't help me learn how to actually do it myself. Really love this format and hoping to see more game dev videos, especially on Godot.
Your authentic and humbling attitude makes this such a great experience to watch. I've been doing professional development for nearly 15 years now and have only met one other developer in my time who has been as honest and open as you. Everyone tends to have their shields up on full blast to either protect their perceived intelligence or their ego, but you sir, are setting standards that I wish the industry would follow. Keep being you brotha, thank you!
thank you so much for the support and your comment! I'm happy to hear that my intention of wanting to be authentic and helpful is coming through. Honestly, this is such a high praise and it encourages me to continue on! Thanks again for your kind words and support! :D
when choosing the display size in project settings you can have godot do the math for you. For example, if you put "1920/3" (without the quotes) in the viewport width section it will make it 640 for you.
Wow, I was so immersed I didn't notice 2 hours had passed. Great tutorial! I like how you explain your thought process and figure things out on the fly (with some smart editing). The only thing that irked me a bit was not using inheritance for the cards, but it seems you figured that out halfway through the video. Nice!
Haha thanks for watching and I'm glad it was entertaining for you! And yea... inheritance is definitely something I should look into using, but at the time I was hoping I could get away with just "making it work and fix later." Haha. Ep4 is probably polish and clean up!
Very well explained video - thank you! It is surprisingly easy to listen and code along with you. I googled one of the autocomplete issues you had, you likely already "as Class" is needed in some odd extra places
thanks for watching! and i'm glad to hear that it's easy to code along! And yea haha I've heard people as you might need "as Class" to guarantee some of those autocompletes... Tho it feels silly to have to do "as Class" in addition to typing the varaible!
Haha welp, this is indeed helpful! Thanks! It wouldn't be gamedev experience if I didn't re-invent already existing solution lol.. thanks for the info!
Thanks a lot for this great video! I really liked this way of tutorial, as it is not "straight coding" but also involves some "how to approach"-thougts. I basically started with Godot 2 days ago, to build some kind of deckbuilding game. After following a different tutorial to get the basics of Godot in my head, your video was the second i watched. I could indeed follow allong pretty smoothly (with some hicups here and there, the signaling troubleshooting took me like 2 hours).... And also your telling-style is great - even when i had to re-view portions of the video over and over again to find my own mistakes :) Much appreciated and thanks for all the work you did put into this !
I'm so glad that this tutorial series has been received well! Thanks for watching and following along! I know that there parts of edit that makes it hard to follow, but im glad it is working for the right audience :) To help everyone, I do plan on doing at the end a "well now I've done it onc3 let's do this without mistake" type of video to re-catch everyone up with all the learnings. Thanks for commenting and watching again!
Thank you for the video! Actually I was doing a game really similar to this a few months ago. I struggled so hard with the arranging those cards in my hand and also had some issues when deleting/clicking a card. So yeah, really nice of you uploading a tutorial :D
I have always wanted to get into game dev. Thank you for the passionate and entertaining thought process of creating a game. I really enjoy the level of detail you went into and the rawness of your thought process.
I really enjoyed watching you tackle some fairly technical programming challenges and walking us through your thought process. I would be interested in your approach to refactoring and cleaning up some of the messy code. And also, what your approach would be for card data structures and options for storing a large dictionary/database of many cards.
Thanks for watching and enjoying the video! I do look forward to getting to that part of cleaning things up a more and exploring some card data structure as you mentioned! I already have episode 2 recorded and i can see that those things probably will come around final episode (tentatively episode 4) of the series! hope you stick around!
That intro got an instant subscribe from me. I'm not interested in copy-paste videos. I need to actually understand the process so i can learn and impliment that knowledge into my general development.
Thanks for watching and subbing! Hope it's useful if not entertaining, and always feel free to suggest/comment so I can cater the content to you all better!
@@ezthedev Well, I have to say, I'm very impressed with the quality given the length of the video. Your voice is clear an pleasant, mic quality is good, edits are very useful. I found out recently that I can use C# with Godot, and I think this video inspired me to finally play around with it and make my next game in Godot once my current project is finished or when I participate in another Game Jam.
@@Edward-Not-Elric thank you for the nice feedback on the video! I hope you have fun in your godot journey! Game jams are awesome! I'm personally planning join this year's GMTK jam again!
Great video Ezra, I like how you approached the problem solving by drawing assumptions and solutions. It looked very similar to a coding interview. It was very self aware and brave of your part showing the process and what you were thinking on each step. Hired :D
I like step-by-step tutorials that are easy to follow, but I also love seeing things go wrong and how to fix them. Shows you how the minds of programmers work. :)
Great video, love that it has a lot of thinking and problem solving kept in! ^^ Didn't see anyone mentioning yet, but the root of the problems coming up at 2:03:25 were caused by having "current_selected_card_index = -1" inside the "for card in hand:", as it doesn't happen if there are no cards to loop through. has been working solid by having it after the loop
So sorry! Yea I agree... I changed some settings and recording setup too so resolution is better as well on the next episode! Lots of zooming in and clarity! Thanks for watching and a great suggestion!
This is an awesome tutorial format! It's super helpful to see more experienced developers train of thought. Btw there is a nice little shorthand that would come in handy at 17:55 - you can drag'n'drop a node to the editor holding Ctrl and you'll automatically get an @onready var
Starting the my Godot journey, I'll make sure to watch this video as soon as I finish the initial tutorial (the good old vampire survivor clone HAHA), always been a great fan of roguelikes and card roguelikes, and by everyone's comments you did an amazing job explaining it how to make it, subscribing so I can follow your teaching journey!
Thanks for subscribing and following along! And when you watch and you feel you need something more always feel free to let me know! I'm always looking to improve to help other better!
This is a great tutorial and will help me with my little project i got going. great work keep it up. I see there's a second video out heading to watch that now.
That was so fun to follow along. I like how you explain how you would do it yourself, so i can try to do it my way or following your thought and then i can just come back to see if we did it the same way, and if doesn't work for me, i can at least have a fix for it. That was especially true for the math behind the calculation about hand card positions. I'm a dev as my day job, it's always so fun to see that even developers don't think in the same way as other developers when it comes to problem solving. +1 Sub. Will watch the next part with great interest.
When I search for "tutorials" on development, THIS is what I want to see. It's like a pair programming session, semi-scripted, so closer to the truth than most other tutorials. I love the concept, and hope you'll do a colony sim game next ;)
awesome stuff ezra! thanks so much! fwiw, some of your looping logic can be trimmed by using array mapping if that's useful to you. for example, the unhighlight loop can be shortened to something like cards_in_hand.map(unhighlight) -- anyway thanks for the great jumping off point :)
That's a great way to clean up! I'd probably do one where I gather all these things and try redo all thus In a shorter more cleaned up version in the future! Thanksnfor watching and commenting!
I enjoyed the video. I recommend everyone look into nandeck as another option. Instead of building the cards (even dynamically) in Godot, nandeck allows a very fluid way to generate cards. There are reasons for creating cards in Godot though, so every dev has to analyze what they need.
Thanks for watching! And wow! Never heard of nanDeck but at a glance seems like it does a lot! I definitely need to have a video where I explore it to inform others on this! Thanks for that info!
Haha that's good to hear! Still focusing on serving the community and the members/subs! Hopefully I can be prolific enough to start patreon! thanks for the support!
Regarding the angles being upside down to where the Y-axis is positive going down and negative going up: the way I heard it is that it comes from how old TV screens were measured from the top-left corner, so while X would increment as you measured to the right, Y would increment as you measured downward.
Yo, just got to the "What is hand?" section of the video and had a thought about how I might approach it. I would imagine the cards in an array, like [1, 2, 3, 4, 5]. The card(s) in the center of the array would be at Y position 0 with 0 rotation, and then the further the card gets from center, the lower Y position and more rotation it would have... I paused and have not looked ahead, so maybe you end of doing kinda the same thing, but wanted to jot it down before I forgot.
I was stuck for like 30 mins because in the handle card touched and untouched I put in card: Card instead of card and it stopped working. This is a great video and I learned a lot.
FYI, if you arent getting auto complete to work, try casting your objects to the type you want by using the 'as' keyword. For example, in you code at 32:45, you should write var card:Card = card_scene.instantiate() as Card
42:44 this is the never ending architecture, software engineering, code quality, and product management tension. experience reduces the f-ups you make by over or under engineering.
Thanks for enjoying the video! I've heard also a lot of people finding useful as passive knowledge soak and then taking it slow the second watch! Ask me anything if you run into any issues
Don't worry. I don't understand any of this so it's all good experience for becoming familiar. I can't even download Godot so I'm just watching and learning for now. Really I'm just watching your process and it helps to put the development into perspective
Love the video! , wouldn't you mind to make a soft keyboard tracker to see the keys you input sometimes real fast since you're used to it , and sometimes it's hard as a beginner to follow
Oh! I didn't think about this! I'll look into getting that in! Unfortunately, I already record3d my next two videos.. but I'll definitely do that! If you have any questions on specific part about my keyboard input, let me know!
@@ezthedev also , this is just me , idk about the rest , bust since I'm more of a developer than a designer , i struggle so much with pixel size and the res , any advice on how to choose these , for example the card size for this game
48:00 fun fact, these `if` statements can often make code slightly slower, albeit insignificantly so. The longest operation in there is the look-up to the `lbl` object, and with `if` it happens once and can happen twice, while w/o `if` it happens exactly once. Additionally, it is usually checked for changes later on anyways - so unless you see horrible flickering w/o `if`, there is no need for it there.
Haha yea everytime I put value checker I have a voice in my head saying... "you know it might be faster to just override everytime" Thanks for confirming! And thanks for watching and providing a helpful comment!
I dont care if i never watch a video again, showing your work? Explaining things beyond "this is a _, so anyways", your a nugget of gold in a coalmine 2 seconds from exploding, youtube godot devs are really not helpful with the small and often common mistakes we make, cause it either isnt good views, or they just cant imagine anyone needing the advice 😂, but like i said, showing you work, just like in class, helps everyone else understand how a mistake wouldve even been a mistake, and how to catch it ahead of time in the future, whether you make it on the "simple stuff" or not, either way definitely subbed
Thank you for your sub! AND such kind and encouraging words! Haha I'm glad to hear this style of content is something that a lot of people are resonating with. Thanks again!
This is fantastic! For your next project in this format can you please do a simple 'paperclip clicker' game? Hopefully way less intensive and just as instructive. Cheers! Liked. Subbed.
for your card highlighting, instead of doing what you did, you could use the _on_gui_input function of a Control node and check to see if it was mouse input. if it was,then you can change the color of your card. IIRC, the mouse event should only be triggered on the "highest" Control Node. If a Control Node is obstructed by another Control Node, then it wont trigger its _on_gui_input function. If for some reason, the event propogates to other control nodes, you can manually consume the event, by calling the accept() function of a Control Node, and it wont propogate any futher Another option is to use the _input or _unhandled_input functions and then manually stopping the propogarion of an event by calling get_viewport().set_input_as_handled()
Omg! I'm so happy about this type of review and suggestions! Thanks! I'll be sure to include some of these things by the end of the series! Thanks for watching and keep recommending please!
@@ezthedev definitely do some research because it's been a little bit since I've worked with Godot, but I do remember there being something very very similar to what I suggested
Haha yea I will definitely have to look into it! I know at least they have input consuming / unhandled for using _unhandled_input function and ill have to see if godot v4 decided that's enough for all input handling or if the method you mentioned is still around!
I was looking for a review that said this. I was watching Ezra's walkthrough and thinking to myself that I'm sure using the "_on_gui_input" function could save so much time handling touches on cards. Great to have it confirmed, thanks!
Nice video! Btw did you know u can use formula for the input fields in Godot? Like at 4:50 you can just type directly "1920/3" for the width in the project settings and itll automatically calculate it for you
I subbed ! ❤ Love to see people doing what they love ! Forget what people say about brackeys and whoever is doing tutorial… ⬇️ People dig energy! Your passion can be felt through your video therefore…. Who the f*** care on how many people do tutorials! JUST DO WHAT YOU LOVE FOR AS LONG AS YOU LOVE IT! Mad respect 🤟🏼
This was awesome! Thank you so much! So much valuable info in here and also observing the process was very interesting. When following along and stumbling upon one of the problems you had I started trying to solve it on my own before watching you and in the end I managed to solve some of the problems on my own. I have 2 big questions though. First is the updating of the highlight in the process function. You were talking about performance alot. Is it smart to do it in the process function? I chose to make an update_highlight() function and call it on mouse entered and mouse exited. The times when the highlight needs to be updated is only those and removing a card from hand, no? The other question regards the setup of the general card scene and the attack and defend card. I'm not so well versed with Godot but wouldn't it be easier to have a general card class and inherit from it? The only problem with that is that I don't know how to do inheritance in Godot if it's not just code but also Nodes. I think I would really want to support you on Patreon! Such a good experience.
Hi! Thanks for the support on kofi! Haha I'm trying to start membership benefits and such via UA-cam instead of Patreon currently but I'll hopefully get started on patreon soon! Let's see.. for your questions. 1) doing graphic update on process. So, typically it would be better performance to do it as you did. However, I had enough issues in the past when doing "just in time" graphic updates sometimes things can get messy with "turning off" highlight in all the future cases. I found it easier to manage in a less error prone way when doing the "state" or data update "just in time" and having the graphical update on every loop based on the state. One exception is if I know for a fact that the graphical update is heavy then I can look at just in time update... however, it rarely happens since if it's just visual update that needs to happen. You can also offload it to GPU (shader) and not worry. I just developed this pattern o er the years to be efficient in prototyping while reducing future issues.
2. Inheritance of object sometimes doesn't work quite as well since you end up having to copy the dependent "nodes" in the scene tree for "inherited" objects.. so if you have any big changes at the base/parent level, you have tons of changes to make for all the children scenes.. in organization and concept, it feels nice, but in practice inheritance gets messy to keep up with... So, I developed a habit of making "scenes" to be less I hesitancy but more modular/component
Maybe it's not the best thing to do, but I would try using `z-index` for card selection. You could use `z-index+1` on every new card. Or even better, for a new card, you could use `last_card.z-index + 1`. I guess you'd need to shift `z-indexes` to every card when removing.
Yea, that though came across my head as well when I was thinking through it, but I remembered messing with 3+ number of different z values can be a lot of headache in my experience, so I just went with what I knew works in general! Alternatively, you could use "texturebutton" to handle pressed or use "unhandled input" to limit the input handling to one node!
"This series is going to include the mistakes and bugs" - fantastic. Tutorials teach you *how* to do something, but not *why* you want to do it that way. Don't just show me the right way, show me the wrong way too, and the difference between them!
And I definitely do go a "wrong" way a lot haha. I try to show the thought process of sticking with wrong way to get to playable state and thinking of fixes and improvements "just in time" to encourage people to get to making games and stop roaming around the tutorial/idea/archetecture hell haha.... We've been all there
I have been working on a card game as a side project since godot 3.5 and now i imported it to 4.3. Our setups are very similar but i also have scripts attached to card resources that play out their intended effects. One problem i have is that even if i queue_free or free all cards or/and then the entire scene and return to main menu and start a new game, the cards retain their buffs and don't trigger their effects again. (In the exported game, not in the engine) Way i do it is X amount of random cards are chosen based on difficulty and then loaded using "load" during a loading screen scene and then transferred into an array of packedScenes that is present in the GameBoard scene.
@@ezthedev It wasn't too hard, the only significant things that broke down was the anchoring on a lot of elements which i had to rearrange the entire UI basically and the tween nodes along with their messed up animations.
@@EthernalOynuyor right they did remove/deprecated in favor of lot of other cool features! I think overall it's all great changes! But yea up version ing engine is always a bit of pain haha
I agree! I always get iffy about using specific nodes like button over generic building block, but honestly, for handling overlapping clicks and having easy hover/pressed/etc textures something like TextureButton works great probably!
hi! we do have a discord and I try my best to answer questions via text, screen capture, and even screen share voice call! discord.gg/9aXW6s5u I am realizing I didn't show the part where I "created" a new base Card scene: 1. Create a new scene "Card.tscn" by creating a new 2DNode Scene. 2. The new scene should already have "Card" at the top of the tree as 2D Node. 3. Right click on the top "Card" node and select "Add Child Node ..." 4. Choose "Sprite2D" Node 5. Rename the Sprite2D to "BaseCardSprite" Let me know if you have any other questions!
@@ezthedev Thank you! I'll make sure to join. I ended up creating a C, I was supposed to open up a new "tab" in the editor, which would open up a new scene, and choosing the 2d Scene Root Node. Hopefully, that's equivalent to steps 1 and 2 of what you detailed.
47:00 you said you would use setters but you used process. Which is really bad performance wise. for me, setters are declared like that: ```gd var card_name: String= "Card Name": set(value): if value == card_name: return card_name = value if name_lbl == null: return name_lbl.set_text(value) ```
Setters are amazing! And yes, this would be better performance since you only make the graphical update only once! I do want to address more in detail about this in my 4th episode on optimization! I still think as the game gets bigger relying in graphical update on setter call can be difficult to keep up with but there are many alternatives and options! If you like doing it this way, and this is easy for you of course it's the best way! Thanks for the comment!
I really enjoyed the video, you make it easy to understand. One thing though, I followed what you did but for some reason I cant seem to get my font to not be blurry when I run the scene. Any ideas?
Hey! Thanks for the comment and watching! Actually the font blurriness is specific to type of font you use. I'm using a custom font I downloaded! And fonts tend to be very sensitive to "font size" to have it perfectly pixelated. I'd recommend looking for free fonts in dafont.com or other font places!
Instead of using func _input, you can do a if statement where the card gets highlighted. if Input.is_action_just_pressed("mouse_click"): remove_card(highest_touch_index) It works the same, and its less work. (This saves you probably 5 minutes from the tutorial)
Less work is great! Haha yea I do not doubt there are better ways to do things on here for sure! I'm happy that viewers like you are here to add to the conversation and the tutorial!
If anyone has an issue around 36:00 with visible = false under the ready function getting an error that says, "identifier visible is not declared in the current scope". You now have to write this instead: self.visible = false
When I play back the screen is all gray. I’m in 3d though and I’ve done camera and environment and like the thing is just blind and driving me nuts. I’ve got it to work once and that’s about it. Makes me want to try another engine. I’m following a tutorial right now but hasn’t got to that part yet 🤦🏻♀️ also love ur vids so far
hello PsychodelickKtten, thanks for enjoying the video and following along! Unfortunately, that's one thing you must make sure... you need to be in 2D in order for everything to work well! If you are still having trouble, I'm available in our discord to help out! I've worked with other viewers who had trouble by helping them via screenshots and/or screen share in voice chat! so, please feel free to come and ask! here's the link: discord.gg/vNZSBqk4
Doen't Godot have that function on 2d nodes or 2d colliders that say whether it should block the "mouse-ray" or let i through? I believe it did, otherwise making like RTS kind of game, where by accident you click the building with a person behind it would be hell
Unfortunately, from what I can tell they do not have mouse ray option (therefore mouse detection being blocked by top objects). AFIAK there's a lot of discussion on different ways of handling this situation, and a lot of them seem to rely on parent node deciding which of the child should be selected. I found some interesting discussion on this here forum.godotengine.org/t/prevent-clicking-elsewhere/51587/10
Great videos. One critique though is that I had to watch the beginning like 10 times to figure out how the canvases and scripts were related to each other. You kind of gloss over things like what’s a parent of what and how scripts are attached to nodes. If you blink you miss it.
Yeaaaa that's a very real! I definitely messed that part up with the edit and going through it! Hopefully, I will try to be better with that! Thanks for the feedback!
@@ezthedevThanks! I have a couple questions for you if you have a minute. Do you have to set an intermediate variable if you just want to set values of a label? Like is there a reason to make local variables for that? Also is there something like a separate constructor (that would run before it’s added to the scene) function so you don’t have to use the onready or is that the only kind of constructor there is?
You can use your custom "type" as typing for variable by declaring your "gd" code with "class_name ...." in the beginning. For my case, at 19:38 I wrote "class_name Card" for the card code, which allows the typing "Card" for rest of the project. From what i can tell from your comment, it maybe erroring because you are using lower case "c" instead of "Card". Hope that works for you!
dude... I was following you tutorial to the letter, BUT BUT BUT at timestamp @43:59 mysteriously got a few more scripts that you didnt show us. These scripts AttackCard, DefendCard and CardHandler. While I am throughly enjoying this tutorial, its so aggravating that mysterious scripts all of a sudden pop up and are not explained. Maybe you do it later on in the tutorial ? IDK? I just noticed it and had to bring up the subject for those of us who spot stuff like this. anyway...good job. I like this tutorial format.
hi! haha yea those i made as a test and was a whole rant session so i cut it. I cut that portion because it's not used at all (and i end up deleting those files). Sorry for the confusion and frustration! and I hope i can continue to make contents you can enjoy!
![[Linux] Konfigurasi Prompt terminal oh-my-zsh](http://i.ytimg.com/vi/dsvzCPRwCa4/mqdefault.jpg)
This was so fun to create! Let me know if you have any questions or suggestions!
Keep it coming this is awesome!
@@hamsu7453 thank you!!
More videos like this :)
You can use a getter function to access variables if you're having trouble figuring out the load order.
Generally, children are always loaded before the parents are, so you shouldn't have have problems referencing children. But if you want to access parents, you can try signals that work their way up to the parent, or attempt a getter function that fetches the reference to the parent like such:
var node: Node2D:
get:
if node == null:
node = get_tree().root.get_node("Path/to/node")
return node
HOWEVER, there are numerous other ways to do this too.
You can right click on a node you want to access from anywhere in that scene, hit "Access as Unique Scene", and then you can access it later by referencing it with a % before its name!
I've only watched so far until 37:00 so pardon if you've already discovered this.
You can also hold references to (non-instantiated) nodes you frequently access in a singleton script that you can autoload!
I've also heard people like to export nodes altogether to be able to reference them. You can do it in many ways.
Hi, I was wondering how much more work it would be to multiplayer ?
Unlike many youtube tutorials that compress 10 hours of work into a 30 minutes video this one maintains a somewhat realistic pace.👍
Haha yea I try to be as real as I can! But I know that also comes with following a mistaken implementation just to fix it later.. hopefully that's okay!
This is super cool! I reccomend using canvas_items instead of viewport for scaling. it wont be pixel perfect, but it will keep things the right scale, and if you rotate things they wont look wonky. text is also way easier to deal with.
oh my goodness! this is exactly what i was hoping for in the comments haha thanks for watching and letting me know of that!
Doing a (almost) unclipped video of Godot game creation is a great idea. Also seeing how Godot is on the rise of popularity right now it really is in the right time of things. Though you do have some competition looking at many other creators, especially now that Brackeys is back and on the Godot train as well.
But your quality of editing is really high, and the content really valuable for anyone learning and seeing the reality of game dev. So keep it up and I am certain you channel will grow. Great work so far and looking forward to seeing more videos from you.
Thank you so much for a thoughtful comment and a realistic and encouraging words! And thanks for watching!
Thumbs up for being from scratch! Been looking for this type of tutorial.
Another wholesome developer channel. alright dev group hug everyone. bring it in 🤗
Hahaha group huggg 🤗
I do not feel like you're explaining too much. It's always nice to have the full thought process to be able to better understand each decisions fully. Ultimately it is crucial to be able to make good decisions on your own when you're out of the boundaries of the video / tutorial / guide
Thanks for the affirmation and a thoughtful comment! I'm glad there are people out here wanting to see the full process!
Yeah, as a principle engineer who does lots of mentorship: never feel bad for this. We learn so much from how others process things, no matter what your or the other person's level.
1:08:05 You're doing good! This is the learning that most tutorials leave out.
Haha thanks ! That is so encouraging
@@ezthedev Np. I'm on my first watch of Episodes 2, and am loving it! Seems to be exactly what I needed.
Damn maybe you don't notice but recording the thinking process is extremely helpfull for people starting in godot like me. You absolutely got the best and most complete godot tutorial out here. I love how you solve the porblems on the fly. Maybe you don't get it right at first but iterating over the solution makes you find the answer, that is my favorite part. Keep up the great work man!
I'm so happy to hear that this is extremely helpful! It is this kind of encouragement that really pushes me to continue improving and building my channel! thanks for watching and commenting!
This was really nice. I love the approach with a long form video that includes errors and reasoning. More fun to watch than a standard tutorial and long term it gives me a more profound understanding of things. Hope to see more of this!
Thanks for watching, and glad it was fun to watch! Will continue posting this type of videos
This tutorial is a godsend. In the past, I've faced many issues and difficult situations that I managed to solve on my own, but I was often unsure if the solutions were optimal. This video has helped me a lot. Please keep this series going!
that's so awesome to hear! you have no idea how much this means to me!
Thanks for the encouragement and watching the video! i'll keep the series going!
Word of advice for coding if it works for your project - and you don’t mind it - then it works for you. Optimization is a hole you don’t want to fall down unless you know it’s something you need to be doing. I’m not saying throw optimization to the wind, but rather if it’s not noticeably impacting your experience to not worry too much about it. As someone who’s been coding for about four years and just about eight months in game development there’s a million ways to do the same thing, and most of the time there’s no difference in efficiency. The biggest difference is the depth at which each person understands it. Of course you want to limit the amount you have to do, but there’s only so much you can learn as one person. Just keep coding, and you’ll inevitably keep learning and getting better.
I really struggle with working out how I need to structure projects, and the order in which I should program in features, so seeing someone else's process is really helpful. I've learned a lot here, great video.
I'm so glad to hear this series has been helpful in such an unexpected way! Thanks for watching and I hope to continue improving this series to help yall better
this is a REAL tutorial!!! I love to watch how you think, decompose concepts and solve issues. Thank you!
Thanks for watching!! I'm glad this format of "tutorial" is serving you nicely! I'll keep it up! Thanks for the encouraging comments!
The static typing you mentioned at 17:30 is massively faster at run time and all allows autocomplete.
You can also static type function return types and inputs
Glad to see the beginning of the Ezra's Teacher Arc. I'm all for it. I think you videos have a great level of authenticity and I think that in combination with your skill/talent will create an audience that orbits around you! Very excited to see where this goes.
Thanks a lot for your encouragement always!
Custom resources are good for when you have set values for something but a reusable base. So they'd fit nicely for the cards, allow you to have a single card scene that you just change the card resource on and when the card is made it loads the name, description, images etc from its resource variable.
Definitely! I'd lovebto explore using custom resources more as data /information base! I'll have to look into it more!
This is wonderful, thank you very much for making this an unclipped video. I was very recently looking into making a card game but all the tutorials I could find were direct solutions which wouldn't help me learn how to actually do it myself. Really love this format and hoping to see more game dev videos, especially on Godot.
You are welcome! I'm glad this is a good resource for you! I hope to continue creating enjoyable and usable contents!
Your authentic and humbling attitude makes this such a great experience to watch. I've been doing professional development for nearly 15 years now and have only met one other developer in my time who has been as honest and open as you. Everyone tends to have their shields up on full blast to either protect their perceived intelligence or their ego, but you sir, are setting standards that I wish the industry would follow. Keep being you brotha, thank you!
thank you so much for the support and your comment! I'm happy to hear that my intention of wanting to be authentic and helpful is coming through. Honestly, this is such a high praise and it encourages me to continue on! Thanks again for your kind words and support! :D
Seconded!
when choosing the display size in project settings you can have godot do the math for you. For example, if you put "1920/3" (without the quotes) in the viewport width section it will make it 640 for you.
Omg this is some top tip! Haha thanks
Wow, I was so immersed I didn't notice 2 hours had passed. Great tutorial! I like how you explain your thought process and figure things out on the fly (with some smart editing).
The only thing that irked me a bit was not using inheritance for the cards, but it seems you figured that out halfway through the video. Nice!
Haha thanks for watching and I'm glad it was entertaining for you! And yea... inheritance is definitely something I should look into using, but at the time I was hoping I could get away with just "making it work and fix later." Haha.
Ep4 is probably polish and clean up!
I will definitely have a look on that. I'll be watching around for more content in this series. I like that you approach tutorials the same way I do 😄
I appreciate the drawings! It helps me follow along with your process
That's great to hear! Thanks for watching and following along!
Very well explained video - thank you! It is surprisingly easy to listen and code along with you.
I googled one of the autocomplete issues you had, you likely already "as Class" is needed in some odd extra places
thanks for watching! and i'm glad to hear that it's easy to code along!
And yea haha I've heard people as you might need "as Class" to guarantee some of those autocompletes...
Tho it feels silly to have to do "as Class" in addition to typing the varaible!
Helpful tip I hope : You should look at the Curve resource in the documentation for an alternative and easy way of "curving" the hand.
Haha welp, this is indeed helpful! Thanks! It wouldn't be gamedev experience if I didn't re-invent already existing solution lol.. thanks for the info!
Thanks a lot for this great video! I really liked this way of tutorial, as it is not "straight coding" but also involves some "how to approach"-thougts.
I basically started with Godot 2 days ago, to build some kind of deckbuilding game. After following a different tutorial to get the basics of Godot in my head, your video was the second i watched.
I could indeed follow allong pretty smoothly (with some hicups here and there, the signaling troubleshooting took me like 2 hours)....
And also your telling-style is great - even when i had to re-view portions of the video over and over again to find my own mistakes :)
Much appreciated and thanks for all the work you did put into this !
I'm so glad that this tutorial series has been received well! Thanks for watching and following along!
I know that there parts of edit that makes it hard to follow, but im glad it is working for the right audience :)
To help everyone, I do plan on doing at the end a "well now I've done it onc3 let's do this without mistake" type of video to re-catch everyone up with all the learnings.
Thanks for commenting and watching again!
I’m a web dev, dipping my toes in after 9 years. This has helped me way more then other resources I’ve been looking at
I'm so glad to hear that this was helpful to someone! Thanks for watching, and I hope to continuously provide useful content!
Thank you for the video!
Actually I was doing a game really similar to this a few months ago.
I struggled so hard with the arranging those cards in my hand and also had some issues when deleting/clicking a card.
So yeah, really nice of you uploading a tutorial :D
Great! I'm glad this is relevant to your need! Thanks for watching!
I have always wanted to get into game dev. Thank you for the passionate and entertaining thought process of creating a game. I really enjoy the level of detail you went into and the rawness of your thought process.
Thank you so much for following along!
Hey, it was a great project. Hoping to see the rest of the project.
I'm glad you enjoyed it! Next episode is coming up within a week!
I really enjoyed watching you tackle some fairly technical programming challenges and walking us through your thought process. I would be interested in your approach to refactoring and cleaning up some of the messy code. And also, what your approach would be for card data structures and options for storing a large dictionary/database of many cards.
Thanks for watching and enjoying the video!
I do look forward to getting to that part of cleaning things up a more and exploring some card data structure as you mentioned! I already have episode 2 recorded and i can see that those things probably will come around final episode (tentatively episode 4) of the series! hope you stick around!
That intro got an instant subscribe from me.
I'm not interested in copy-paste videos. I need to actually understand the process so i can learn and impliment that knowledge into my general development.
Thanks for watching and subbing! Hope it's useful if not entertaining, and always feel free to suggest/comment so I can cater the content to you all better!
@@ezthedev Well, I have to say, I'm very impressed with the quality given the length of the video. Your voice is clear an pleasant, mic quality is good, edits are very useful.
I found out recently that I can use C# with Godot, and I think this video inspired me to finally play around with it and make my next game in Godot once my current project is finished or when I participate in another Game Jam.
@@Edward-Not-Elric thank you for the nice feedback on the video! I hope you have fun in your godot journey! Game jams are awesome! I'm personally planning join this year's GMTK jam again!
Great video Ezra, I like how you approached the problem solving by drawing assumptions and solutions. It looked very similar to a coding interview.
It was very self aware and brave of your part showing the process and what you were thinking on each step.
Hired :D
Hahaha exactly! Problem solving unknown is pretty much coding interview! Haha thanks for the "hire"! Lol
I like step-by-step tutorials that are easy to follow, but I also love seeing things go wrong and how to fix them. Shows you how the minds of programmers work. :)
Thanks for watching! I love sharing this experience and the response from everyone has been really fun to see! I'm going to continue making more!
Decided to start make a rpg like game where you go around trading and playing a tcg and decided this would be a good start, thanks!
Great to hear! Good luck!
Great video, love that it has a lot of thinking and problem solving kept in! ^^
Didn't see anyone mentioning yet, but the root of the problems coming up at 2:03:25 were caused by having "current_selected_card_index = -1" inside the "for card in hand:", as it doesn't happen if there are no cards to loop through. has been working solid by having it after the loop
Oh! I'm glad you got that figured! Haha thanks!
I'm doing a similar series, super interested how you approach this genre in Godot!
Liked and subscribed 🤖
Great! Good luck on your project and thanks for watching and subscribing! I'll come look when you post!
Nice vid, looking forward to the future updates.
Thanks!
This was a great video but I would love it if you zoomed more especially on the code
So sorry! Yea I agree... I changed some settings and recording setup too so resolution is better as well on the next episode! Lots of zooming in and clarity! Thanks for watching and a great suggestion!
This is an awesome tutorial format! It's super helpful to see more experienced developers train of thought. Btw there is a nice little shorthand that would come in handy at 17:55 - you can drag'n'drop a node to the editor holding Ctrl and you'll automatically get an @onready var
Thanks for watching! And that's so convenient! Thanks for the tip! Haha
This is why i love the community!
Starting the my Godot journey, I'll make sure to watch this video as soon as I finish the initial tutorial (the good old vampire survivor clone HAHA), always been a great fan of roguelikes and card roguelikes, and by everyone's comments you did an amazing job explaining it how to make it, subscribing so I can follow your teaching journey!
Thanks for subscribing and following along! And when you watch and you feel you need something more always feel free to let me know! I'm always looking to improve to help other better!
This is a great tutorial and will help me with my little project i got going. great work keep it up. I see there's a second video out heading to watch that now.
Thank you so much for that! see you in the second video! haha
I've been looking for a rogue like deckbuilder tutorial, please finish this.
I got you! Haha thanks for watching! There's second episode out already on this and I'm recording more!
That was so fun to follow along.
I like how you explain how you would do it yourself, so i can try to do it my way or following your thought and then i can just come back to see if we did it the same way, and if doesn't work for me, i can at least have a fix for it.
That was especially true for the math behind the calculation about hand card positions.
I'm a dev as my day job, it's always so fun to see that even developers don't think in the same way as other developers when it comes to problem solving.
+1 Sub.
Will watch the next part with great interest.
thank you so much for the sub and view!
It's so encouraging to hear your thought on this format, and loved that you enjoyed it!
When I search for "tutorials" on development, THIS is what I want to see. It's like a pair programming session, semi-scripted, so closer to the truth than most other tutorials. I love the concept, and hope you'll do a colony sim game next ;)
Haha thanks for watching! This is definitely encouraging to continue on my journey! Colony Sim soon? Sounds fun to explore!
awesome stuff ezra! thanks so much! fwiw, some of your looping logic can be trimmed by using array mapping if that's useful to you. for example, the unhighlight loop can be shortened to something like cards_in_hand.map(unhighlight) -- anyway thanks for the great jumping off point :)
That's a great way to clean up! I'd probably do one where I gather all these things and try redo all thus In a shorter more cleaned up version in the future! Thanksnfor watching and commenting!
I enjoyed the video. I recommend everyone look into nandeck as another option. Instead of building the cards (even dynamically) in Godot, nandeck allows a very fluid way to generate cards. There are reasons for creating cards in Godot though, so every dev has to analyze what they need.
Thanks for watching! And wow! Never heard of nanDeck but at a glance seems like it does a lot! I definitely need to have a video where I explore it to inform others on this! Thanks for that info!
this is EXACTLY what I have been looking for. thank you.
would join a patreon for this kind of thing. 100%.
Haha that's good to hear! Still focusing on serving the community and the members/subs! Hopefully I can be prolific enough to start patreon! thanks for the support!
Regarding the angles being upside down to where the Y-axis is positive going down and negative going up: the way I heard it is that it comes from how old TV screens were measured from the top-left corner, so while X would increment as you measured to the right, Y would increment as you measured downward.
Very interesting! Thanks for this fun information! And thanks for watching:)
Thank you! And good luck with the game!
amazing content dude, thank you for sharing it with us!
Thanks for watching!
Thank you so much, this was super helpful for someone who just started gamedev
you are welcome! and thanks for watching!
looking forward to your next vid :D what a journey
Thanks for watching!
I'm building a card playing game and this series is helping a bunch, thanks!
Thanks for watching and stopping by on stream!
Yo, just got to the "What is hand?" section of the video and had a thought about how I might approach it. I would imagine the cards in an array, like [1, 2, 3, 4, 5]. The card(s) in the center of the array would be at Y position 0 with 0 rotation, and then the further the card gets from center, the lower Y position and more rotation it would have... I paused and have not looked ahead, so maybe you end of doing kinda the same thing, but wanted to jot it down before I forgot.
Haha don't want to spoil it for you! But I'll go ahead and say that's a good approach!
I was stuck for like 30 mins because in the handle card touched and untouched I put in card: Card instead of card and it stopped working. This is a great video and I learned a lot.
I.. yea haha apologies! But I'm glad you got through!
FYI, if you arent getting auto complete to work, try casting your objects to the type you want by using the 'as' keyword. For example, in you code at 32:45, you should write var card:Card = card_scene.instantiate() as Card
Haha yea, I do end up doing that for some of the more important ones but it's unfortunate that I have to force the cast
@@ezthedev agreed
Thank you for making this video, it was lovely and helped me out doing a game jam : )
I'm glad it was helpful!
42:44 this is the never ending architecture, software engineering, code quality, and product management tension. experience reduces the f-ups you make by over or under engineering.
This right here is the truth!
that was really cool! got lost a bit on the last highlight part lol but i didn't try this yet!
Thanks for enjoying the video! I've heard also a lot of people finding useful as passive knowledge soak and then taking it slow the second watch! Ask me anything if you run into any issues
@@ezthedev I will! I have 3 card games in development, one more complicated than the other lol
Don't worry. I don't understand any of this so it's all good experience for becoming familiar. I can't even download Godot so I'm just watching and learning for now. Really I'm just watching your process and it helps to put the development into perspective
Thanks for sharing! If you would like a deck builder with super pretty pixel art I would highly recommend Cobalt Core :)
That sounds fun! I gotta try it out! Thanks for the recommendation
Gloomheaven at the back! Proud of you bro!
Love the game! Just need to find a dedicated group to play all the way with... haha
Love the video! , wouldn't you mind to make a soft keyboard tracker to see the keys you input sometimes real fast since you're used to it , and sometimes it's hard as a beginner to follow
Oh! I didn't think about this! I'll look into getting that in! Unfortunately, I already record3d my next two videos.. but I'll definitely do that!
If you have any questions on specific part about my keyboard input, let me know!
@@ezthedev also , this is just me , idk about the rest , bust since I'm more of a developer than a designer , i struggle so much with pixel size and the res , any advice on how to choose these , for example the card size for this game
48:00 fun fact, these `if` statements can often make code slightly slower, albeit insignificantly so.
The longest operation in there is the look-up to the `lbl` object, and with `if` it happens once and can happen twice, while w/o `if` it happens exactly once.
Additionally, it is usually checked for changes later on anyways - so unless you see horrible flickering w/o `if`, there is no need for it there.
Haha yea everytime I put value checker I have a voice in my head saying... "you know it might be faster to just override everytime"
Thanks for confirming! And thanks for watching and providing a helpful comment!
Thanks bro, this is awesome!
Thanks you for watching!
I dont care if i never watch a video again, showing your work? Explaining things beyond "this is a _, so anyways", your a nugget of gold in a coalmine 2 seconds from exploding, youtube godot devs are really not helpful with the small and often common mistakes we make, cause it either isnt good views, or they just cant imagine anyone needing the advice 😂, but like i said, showing you work, just like in class, helps everyone else understand how a mistake wouldve even been a mistake, and how to catch it ahead of time in the future, whether you make it on the "simple stuff" or not, either way definitely subbed
Thank you for your sub!
AND such kind and encouraging words! Haha I'm glad to hear this style of content is something that a lot of people are resonating with. Thanks again!
This is fantastic!
For your next project in this format can you please do a simple 'paperclip clicker' game? Hopefully way less intensive and just as instructive.
Cheers!
Liked. Subbed.
Oooo interesting! I'll definitely take that suggestion into consideration!
for your card highlighting, instead of doing what you did, you could use the _on_gui_input function of a Control node and check to see if it was mouse input. if it was,then you can change the color of your card. IIRC, the mouse event should only be triggered on the "highest" Control Node. If a Control Node is obstructed by another Control Node, then it wont trigger its _on_gui_input function. If for some reason, the event propogates to other control nodes, you can manually consume the event, by calling the accept() function of a Control Node, and it wont propogate any futher
Another option is to use the _input or _unhandled_input functions and then manually stopping the propogarion of an event by calling get_viewport().set_input_as_handled()
Omg! I'm so happy about this type of review and suggestions! Thanks! I'll be sure to include some of these things by the end of the series! Thanks for watching and keep recommending please!
@@ezthedev definitely do some research because it's been a little bit since I've worked with Godot, but I do remember there being something very very similar to what I suggested
Haha yea I will definitely have to look into it! I know at least they have input consuming / unhandled for using _unhandled_input function and ill have to see if godot v4 decided that's enough for all input handling or if the method you mentioned is still around!
I was looking for a review that said this. I was watching Ezra's walkthrough and thinking to myself that I'm sure using the "_on_gui_input" function could save so much time handling touches on cards. Great to have it confirmed, thanks!
Nice video! Btw did you know u can use formula for the input fields in Godot? Like at 4:50 you can just type directly "1920/3" for the width in the project settings and itll automatically calculate it for you
I didn't know until recently! Very cool and helpful feature! Thanks for the comment and watching the video! :)
Thanks for sharing!
Thanks for watching!
I subbed ! ❤
Love to see people doing what they love !
Forget what people say about brackeys and whoever is doing tutorial… ⬇️
People dig energy!
Your passion can be felt through your video therefore…. Who the f*** care on how many people do tutorials! JUST DO WHAT YOU LOVE FOR AS LONG AS YOU LOVE IT!
Mad respect 🤟🏼
Haha thanks for the encouragement and the sub!
new fav godot tutorial, thanks for this example!
Thanks for watching! Hope you have fun in your dev journey
Good video. I've learned alot 🙂
Thank you and I'm so happy to hear!
This was awesome! Thank you so much! So much valuable info in here and also observing the process was very interesting. When following along and stumbling upon one of the problems you had I started trying to solve it on my own before watching you and in the end I managed to solve some of the problems on my own.
I have 2 big questions though. First is the updating of the highlight in the process function. You were talking about performance alot. Is it smart to do it in the process function? I chose to make an update_highlight() function and call it on mouse entered and mouse exited. The times when the highlight needs to be updated is only those and removing a card from hand, no?
The other question regards the setup of the general card scene and the attack and defend card. I'm not so well versed with Godot but wouldn't it be easier to have a general card class and inherit from it? The only problem with that is that I don't know how to do inheritance in Godot if it's not just code but also Nodes.
I think I would really want to support you on Patreon! Such a good experience.
Hi! Thanks for the support on kofi! Haha I'm trying to start membership benefits and such via UA-cam instead of Patreon currently but I'll hopefully get started on patreon soon!
Let's see.. for your questions.
1) doing graphic update on process.
So, typically it would be better performance to do it as you did. However, I had enough issues in the past when doing "just in time" graphic updates sometimes things can get messy with "turning off" highlight in all the future cases. I found it easier to manage in a less error prone way when doing the "state" or data update "just in time" and having the graphical update on every loop based on the state.
One exception is if I know for a fact that the graphical update is heavy then I can look at just in time update... however, it rarely happens since if it's just visual update that needs to happen. You can also offload it to GPU (shader) and not worry. I just developed this pattern o er the years to be efficient in prototyping while reducing future issues.
2. Inheritance of object sometimes doesn't work quite as well since you end up having to copy the dependent "nodes" in the scene tree for "inherited" objects.. so if you have any big changes at the base/parent level, you have tons of changes to make for all the children scenes.. in organization and concept, it feels nice, but in practice inheritance gets messy to keep up with...
So, I developed a habit of making "scenes" to be less I hesitancy but more modular/component
Hope this clarifies some of my decisions! Thanks for watching again!
Beutiful tutorial, you have a new follower.
Thanks for following and watching!
Maybe it's not the best thing to do, but I would try using `z-index` for card selection. You could use `z-index+1` on every new card. Or even better, for a new card, you could use `last_card.z-index + 1`. I guess you'd need to shift `z-indexes` to every card when removing.
Yea, that though came across my head as well when I was thinking through it, but I remembered messing with 3+ number of different z values can be a lot of headache in my experience, so I just went with what I knew works in general!
Alternatively, you could use "texturebutton" to handle pressed or use "unhandled input" to limit the input handling to one node!
Gold!! Well Done Sir!!👏
Thank you!
This is an encouraging word in the comments. 🎉❤
Thanks! 🙏
"This series is going to include the mistakes and bugs" - fantastic. Tutorials teach you *how* to do something, but not *why* you want to do it that way. Don't just show me the right way, show me the wrong way too, and the difference between them!
And I definitely do go a "wrong" way a lot haha. I try to show the thought process of sticking with wrong way to get to playable state and thinking of fixes and improvements "just in time" to encourage people to get to making games and stop roaming around the tutorial/idea/archetecture hell haha....
We've been all there
Good tutorial, thanks!
Thanks for watching!
8:22 lame is good in code naming.
Haha lame but detailed
You're a great teacher!
Thank you!
I have been working on a card game as a side project since godot 3.5 and now i imported it to 4.3. Our setups are very similar but i also have scripts attached to card resources that play out their intended effects. One problem i have is that even if i queue_free or free all cards or/and then the entire scene and return to main menu and start a new game, the cards retain their buffs and don't trigger their effects again. (In the exported game, not in the engine)
Way i do it is X amount of random cards are chosen based on difficulty and then loaded using "load" during a loading screen scene and then transferred into an array of packedScenes that is present in the GameBoard scene.
That is a great insight! I hope your process of coming over to 4.x+ version has been good! I've been really loving godot so far!
@@ezthedev It wasn't too hard, the only significant things that broke down was the anchoring on a lot of elements which i had to rearrange the entire UI basically and the tween nodes along with their messed up animations.
@@EthernalOynuyor right they did remove/deprecated in favor of lot of other cool features! I think overall it's all great changes! But yea up version ing engine is always a bit of pain haha
Perfect
for the card selection i think it would be better to use buttons instead of area 2d, it resolves overlapping by itself
I agree! I always get iffy about using specific nodes like button over generic building block, but honestly, for handling overlapping clicks and having easy hover/pressed/etc textures something like TextureButton works great probably!
@@ezthedev You also could use a path for the hand btw 🤔
@@olegfavorskii1403 haha definitely! Some also said curve?
2 questions:
- Is there a discord on which we can ask questions?
- How do you create the Card node and BaseCardSprite subnode at 6:25?
hi! we do have a discord and I try my best to answer questions via text, screen capture, and even screen share voice call!
discord.gg/9aXW6s5u
I am realizing I didn't show the part where I "created" a new base Card scene:
1. Create a new scene "Card.tscn" by creating a new 2DNode Scene.
2. The new scene should already have "Card" at the top of the tree as 2D Node.
3. Right click on the top "Card" node and select "Add Child Node ..."
4. Choose "Sprite2D" Node
5. Rename the Sprite2D to "BaseCardSprite"
Let me know if you have any other questions!
@@ezthedev Thank you! I'll make sure to join.
I ended up creating a C, I was supposed to open up a new "tab" in the editor, which would open up a new scene, and choosing the 2d Scene Root Node. Hopefully, that's equivalent to steps 1 and 2 of what you detailed.
Yup! That's basically the same!
Thanks!
Thank you so much for the support!
47:00 you said you would use setters but you used process. Which is really bad performance wise. for me, setters are declared like that:
```gd
var card_name: String= "Card Name":
set(value):
if value == card_name: return
card_name = value
if name_lbl == null: return
name_lbl.set_text(value)
```
Setters are amazing! And yes, this would be better performance since you only make the graphical update only once!
I do want to address more in detail about this in my 4th episode on optimization! I still think as the game gets bigger relying in graphical update on setter call can be difficult to keep up with but there are many alternatives and options!
If you like doing it this way, and this is easy for you of course it's the best way! Thanks for the comment!
Thank you it's real helpful and interesting tutor
Thank you for watching and commenting!
I really enjoyed the video, you make it easy to understand. One thing though, I followed what you did but for some reason I cant seem to get my font to not be blurry when I run the scene. Any ideas?
Hey! Thanks for the comment and watching! Actually the font blurriness is specific to type of font you use. I'm using a custom font I downloaded! And fonts tend to be very sensitive to "font size" to have it perfectly pixelated.
I'd recommend looking for free fonts in dafont.com or other font places!
@@ezthedev Ah ok, what size font would you suggest I download?
@@rileypoteralski7964 for something like this I like to work with 8px or 16px
@@ezthedev Thanks!
Instead of using func _input, you can do a if statement where the card gets highlighted.
if Input.is_action_just_pressed("mouse_click"):
remove_card(highest_touch_index)
It works the same, and its less work.
(This saves you probably 5 minutes from the tutorial)
Less work is great! Haha yea I do not doubt there are better ways to do things on here for sure! I'm happy that viewers like you are here to add to the conversation and the tutorial!
17:22 types are good.
Agreed!
If anyone has an issue around 36:00 with visible = false under the ready function getting an error that says, "identifier visible is not declared in the current scope". You now have to write this instead:
self.visible = false
Thanks for helping everyone!
@@ezthedev You helped first! 😋
When I play back the screen is all gray. I’m in 3d though and I’ve done camera and environment and like the thing is just blind and driving me nuts. I’ve got it to work once and that’s about it. Makes me want to try another engine. I’m following a tutorial right now but hasn’t got to that part yet 🤦🏻♀️ also love ur vids so far
hello PsychodelickKtten, thanks for enjoying the video and following along!
Unfortunately, that's one thing you must make sure... you need to be in 2D in order for everything to work well!
If you are still having trouble, I'm available in our discord to help out!
I've worked with other viewers who had trouble by helping them via screenshots and/or screen share in voice chat!
so, please feel free to come and ask!
here's the link: discord.gg/vNZSBqk4
Thank you so much.
Thank you for watching!
Doen't Godot have that function on 2d nodes or 2d colliders that say whether it should block the "mouse-ray" or let i through? I believe it did, otherwise making like RTS kind of game, where by accident you click the building with a person behind it would be hell
Unfortunately, from what I can tell they do not have mouse ray option (therefore mouse detection being blocked by top objects).
AFIAK there's a lot of discussion on different ways of handling this situation, and a lot of them seem to rely on parent node deciding which of the child should be selected.
I found some interesting discussion on this here forum.godotengine.org/t/prevent-clicking-elsewhere/51587/10
Great videos. One critique though is that I had to watch the beginning like 10 times to figure out how the canvases and scripts were related to each other. You kind of gloss over things like what’s a parent of what and how scripts are attached to nodes. If you blink you miss it.
Yeaaaa that's a very real! I definitely messed that part up with the edit and going through it! Hopefully, I will try to be better with that! Thanks for the feedback!
@@ezthedevThanks! I have a couple questions for you if you have a minute. Do you have to set an intermediate variable if you just want to set values of a label? Like is there a reason to make local variables for that? Also is there something like a separate constructor (that would run before it’s added to the scene) function so you don’t have to use the onready or is that the only kind of constructor there is?
quite good one vedio, I wish you could make more about it, like it🥰🥰
There are two more episodes and the 4th one is coming soon!
thanks it helps a lot
I'm glad it helped!
32:29
how did you declare the variable as type: card?
when I type the same thing an error goes like: couldn't find type "card" in the current scope
You can use your custom "type" as typing for variable by declaring your "gd" code with "class_name ...." in the beginning.
For my case, at 19:38 I wrote "class_name Card" for the card code, which allows the typing "Card" for rest of the project.
From what i can tell from your comment, it maybe erroring because you are using lower case "c" instead of "Card".
Hope that works for you!
@@ezthedev It actually worked when I prefixed "card" with a "_" for some reason...
dude... I was following you tutorial to the letter, BUT BUT BUT at timestamp @43:59 mysteriously got a few more scripts that you didnt show us.
These scripts AttackCard, DefendCard and CardHandler. While I am throughly enjoying this tutorial, its so aggravating that mysterious scripts all of a sudden pop up and are not explained. Maybe you do it later on in the tutorial ? IDK? I just noticed it and had to bring up the subject for those of us who spot stuff like this.
anyway...good job. I like this tutorial format.
hi! haha yea those i made as a test and was a whole rant session so i cut it. I cut that portion because it's not used at all (and i end up deleting those files). Sorry for the confusion and frustration!
and I hope i can continue to make contents you can enjoy!
good eyes.. haha i'll make sure to make it more consistent with things like that