My First 8 Hours Learning Godot - GDScript Edition
ฝัง
- เผยแพร่เมื่อ 18 พ.ค. 2024
- Hi, and welcome to The Infinite Inkwell. I’m Lewis, and I’m on a storytelling adventure, exploring and experimenting with new ways to tell stories. My first storytelling escapade will be in the form of a video game. In this video, I share my experience learning Godot and its native GDScript after 8 hours. I’m talking about the learning process and not much about the engine itself. I’ll save that for a future video. Please continue to share your thoughts in the comments, I’m keen to get any feedback.
*Chapters*
0:00 Intro
0:47 Godot Documentation
3:07 My experience with GDQuest
4:18 Discovering DevWorm
8:18 What I Made (DevWorm)
11:41 What I Made (GDQuest)
12:38 Final Thoughts
14:43 Outro
Credits
Https://godotengine.org
@Gdquest
@dev-worm
• How to Make Survival G...
Star Wars Episode 5 The Empire Strikes Back - Disney, Lucasfilm
1. Don't learn 20 languages, just learn the 1 language for Godot.
2. You need to figure out how to put code together like Minecraft blocks to build functionality, start simple.
3. Don't read the entire documentation at once, start with the first page and work on that and then move on to the rest of the doc slowly.
4. You don't need to learn everything to make a game, just learn what you need to make your specific game, if it's a platformer learn platformer information not role playing game information.
5. You are not a computer as well, so information doesn't stick like folders in your head, you will eventually forget information, so notetaking digitally works better.
6. Before even coding an idea use a piece of paper to gather your thoughts on how your stuff will work.
7. Don't get stuck in tutorial hell, try to manipulate information on tutorials you learned in your own creative way, otherwise you can get stuck in that rabbit hole forever.
8. Debugging is your friend and will save you so much time.
Thanks for your comment - This is actually how I'm trying to approach it. I've got lots of notes, I'm trying to only pick up the bits I need along with some basics of how the engine works (nodes, signals, scenes etc). I think for my first game I'm going to be doing more design first. This has mostly been for a light evaluation of how I might find the engine going forward.
One way I found helpful to learn Godot was to write the idea for the game and story first then hunt down how to do the various parts of it. It is super easy to get stuck in "tutorial hell" where you follow spoon-fed tutorials (like you mentioned) but if you know what kind of thing you want to make you can learn how to make each part individually and digest that information as you add it.
Thank you, that's a really good approach.
I've been trying to do that, but have found it harder than I expected. I could have done a better job of looking for stronger documentation. It's also partially contributed to how I fell into my tutorial issue. I built my game design document a few weeks ago and been using it as a guideline for what I should be learning. I only want to learn the stuff I need, I'll do the rest later. I'm trying to keep it pretty simple for now building a level with a character I can move around, interact with collectibles and move to the next area, as it's the basis for most of the mechanics I think I'll need in my game.
Thank you so much for your support, I really appreciate the input, I'm always keen to learn from others :)
Long comment, but....
I do this a lot.
I watch tutorials not to copy the full video but to note down snippets of code and tips that I can reuse in any future project of mine.
It's like creating a cheat sheet for future reference. I'm never gonna remember all of it, so noting it down helps.
You also don't want to rely on tutorials all the time, so doing your own research and having the docs on hand is a good idea.
If you're a beginner, you also want to create and maintain a GGD (game design document). Without one, you'll be flying blind into an unstructured project. After that, it's good to create a LDD (level design document) that further brakes down what will be featured in each level, like the biome, what enemies are to appear, and so on.
Using a task board, like Trello, is also recommended, since if you take a brake, you can return, look at your task list, and get back on track.
Keeping those tasks to small digestible bites, like "get player jump working," "get sprint working," or "fix terrain here," is key to not going insane.
If you can get a handful of them done in a day, they your doing better then most.
Sorry for the long comment 😅
@@pixels_per_minute Thanks so much for the long comment I really enjoyed reading. I hadn't thought about creating a level design document. That's a great idea. I think I have basic ideas in my head around level design but already since starting to learn an engine, I've had some new ideas about better and different ways to build out levels and transitions between them. After settling on an engine, I'm thinking to do some design work next, on level design, the player character, NPCs and collectibles.
Yeah that's really solid as an idea - thank you. I wasn't sure how I was going to manage that. I had planned to wait till after settling on an engine. But starting sooner isn't a bad idea. In the past I've used Trello, JIRA and Notion. I think I'm going to stick to Notion for now, because it's where all my other documentation is. Depending on what I use for code management (an area I'm massively out of my depth with), I may even use GitHub issues for it - my developers have spoken about this in the past - they found it easier to assign a task to a branch, but I don't know. Can you tell I've picked up little bits from colleagues but not enough to be actually useful?😂
You are right, there are going to be times where I step away, to go and focus on my day job, family or other life stuff and get lost with where I left things. The small digestible bites is definitely the best way for me to do this given I may only have the odd hour in the evening to dedicate to something. Making sure I keep my own documentation up to date will be so vital.
Thank you again for the ideas and your support, I really appreciate it.
@TheInfiniteInkwell Don't worry about it. It's just a few things I've picked up while studying game design.
GDDs, LDDs, Art Bibles, Project Briefs, SCRUM, etc, etc.
There's a lot of paperwork and business speak that go into it before you even touch an engine. A lot of it is for when you're working in teams but I, a little selfishly, like working alone, so I kinda ignore a lot of it.
Having a GGD and an LDD is a must, however, and a lot of the time, they aren't engine specific, so you can start long before choosing. There's plenty of templates out there to get a general idea of how you should structure them if you don't know already.
Hello, authors, I may not be very good at English. I have finished reading the basic tutorials, various function modules, and GD tutorials. I have some problems that I can't solve while watching and doing. I feel that I should develop a WEB interface that looks like an APP similar to a website, which makes people feel more accomplished, because this 1/2 is UI, a beautiful UI is really important, but I still have some problems with reproducing the UI, maybe I like version 4.2 too much. I am now wondering if I can innovate a game by myself just by looking at the GODOT manual, even if it is an STG airplane shooting game, I found it impossible later, I am really confused now, I originally had a lot of ideas, maybe the old bird can do it, but after watching many tutorials and integrating it by myself, I found that it still can't be assembled well, I am really confused now. How to solve it, thank you.
use clear code's ultimate introduction to godot 4. he gives visual explanations and explain the features of godot 4 fairly easily, best part is there are a lot of exercises that he would give after a particular section of the video. how to use the area 2d node and connect a signal to it? boom, exercise with a nice twist. how to use timers? gives you an example then gives you an exercise for it that requires a little creative thinking. You don't NEED to finish the 11 hour tutorial, cause most of the basics are covered in like 6 hours or so. In my case i just checked his timestamps on how to use a particular feature that i need to use in my project in Godot 4 and learned about it and then implemented it. when i have leveled up a bit, imma learn animation player and shaders!
Thanks so much for sharing why you found it useful. That's so exciting for your game - good luck! It's so funny to see this come up so often, but I'll definitely take it on board and use it going forward.
I had quite a similar experience with Godot. I was multiple times close to quitting because of the effort I had to put in to get something small running. The general documentation and tutorials, were not very helpful because they always assumed "how I would go about it". What I did not know was that you have to use mostly the class reference and the style references, more so then the actual documentation. A lot becomes clear when reading what is implemented in a class and what isn't. I found I could often look for a feature in four steps/directions:
- Find a low-level example (Raycasts are in the Phys world: Just copy some lines and observe how it gets the physics_state etc.)
- Check the class you expect the feature to be in for methods and variables (Movement Functions are in the corresponding character body or rigid body classes)
- Check the parent classes for the feature (Check Canvas Object instead of Node2D for example if you need a visual feature)
- Check for a helper classes with methods required (Geometry provides all the line hits circle functions etc)
I feel the godot reference is lacking in that the class reference is not linked closely to the documentation and is often searched separately.
That's really helpful! Thank you so much @MutedStoryteller. I think sharing our experiences of learning this stuff is going to make it so much easier for everyone else as they start to approach it. And as one of those newbies - Thank you 🤓
C++ isn't really as well supported in godot as gdscript, it's more meant to be used for doing just the most intensive parts where you really need the performance. (You technically could use just C++ for the entire project, but even as someone who prefers coding in C/C++ over gdscript I wouldn't try to do that)
Thank you for the guidance. Also that's pretty funny that even though you prefer C++ you wouldn't do it. I think I'm seriously considering my options for that one.
I prefer C# by a long shot over GDScript.
Actually, the last time I checked C++ in godot was a few years ago and it looks like they've improved a lot since then.
The thing is, C++ is just a harder language to use than gdscript which makes development times longer. You start have worrying about memory management and all the other things that gdscript just takes care of automatically for you, and while you do get a significant boost in performance most games that you could reasonably develop as an solo indie developer will be able to reach 60 fps with good gdscript anyway. (or at least, a mix of gdscript with C++ for the performance critical parts)
Yes I agree. Also, programming errors in gdscript lead to some silly logic bugs, maybe a memory leak or 2.
C++ memory mistakes can crash the game quite easily. There's a few cases where beginners (and pros) find themselves in the wacky land of "undefined C++ behavior". So the results vary per platform/compiler implementation etc.
It's the usual stuff with low level languages for sure. Lots of fun but dragons for sure.
Hey, I just discovered your channel and I think I will be one of your biggest fan. Keep up the good work!
Thank you very much. Welcome aboard - I look forward to going on this journey with you.
I have not used Godot before, but I looked up the docs for Input.get_vector. The parameters it takes are Input.get_vector(negative_x, positive_x, negative_y, positive_y). I assume Godot will use a regular coordinate system, so negative_x would be left, negative_y would be up etc.. So line 9 in your player script should actually be, `var direction = nput.get_vector("left", "right", "up", "down")`
Yeah, you can see in the GDScript version when he shows that, he has the directions correct in that one. Tricky but a very easy fix.
Thank you so much for this. It was driving me crazy. Part of me sees that as so counter-intuitive. My brain immediately goes up, down, left, right by default. I was thinking I'd have to do some weird config thing, but this was a big help - thank you!
Yeah that one from GDQuest was pretty much a copy paste job. When I wrote it just with notes I didn't think the order made a difference 🤦🏻♂️ So easy, but because of the way I'm trying to learn this, it's definitely not a mistake I'll make again.
Looking forward to more videos. I have no idea how GODOT works but I am willing to learn, and take that step into game development. very inspiring and looking forward to more ways in getting to learn the engine. With your help it can be possible. Thank you for this video, appreciated.
Thank you so much for your positive comments and support. I'm glad you've found it helpful and excited to have you on the journey. Some of it might be a little overwhelming at first but there are some good videos which break it down out there. It's always worth learning something new, especially with something so creative and exciting as game dev. Good luck learning, hopefully some of the links I share will be helpful starting points, when you start with Godot. Let me know how you find it.
I'd definitely recommend starting with a basic game idea and going from there. I'd recommend taking a look at building a Game Design Document, so you can understand what kind of game you want to make and what kind of mechanics you want to include. That's where I started. I made a video on them if you're interested in finding out about more of them.
Thanks again for your kind words and the best of luck!
th-cam.com/video/NudhoaICpfA/w-d-xo.html
I am in a very similar boat to you with a bit more experience coming from a few months on and off from unity. I'm here for your journey, keep it up.
Thanks so much! Glad to have you on the journey. What made you jump from Unity?
The TH-cam channel “Clear Code” has a several hour-long (he goes into deeper beginner concepts, but the video builds incrementally and is nicely time-stamped) beginner Godot tutorial; I believe it’s called something like “The ultimate introduction to Godot 4” or something. He starts with nothing (except assets) and covers a broad range of GDScript functionality while making a 2D “game”. What I liked about his tutorial was that every time he began to discuss a new aspect of GDScript, he would pause to explain what said-aspect/function/etc. does via description and, at times (from what I recall), visual depictions. You’ve already made far more progress than me, but I hope this helps! 😊
That 11 hour video is a gem. I am a noob when it comes to development and to top it of I am an artist, I tried but I could never learn how to code but that GEM OF A TUTORIAL is amazing. It just places things in order in my head
I checked that video out, it looks awesome! I'm definitely going to use it if Godot ends up being my choice of engine. Thanks for that recommendation!
@@TheInfiniteInkwell
Np; thank *you* for pushing me in the direction of DevWorm, I've been watching his RPG tutorial and it's been great!
Good luck on your journey!
I think the main reason Godot brings up learning another language/CS principals is because at it's core, game development is software development.
You're making something that will run on someone else's PC and for that to be more frictionless it's easier to start with bite sized pieces rather than a whole game (As bite-sized the smallest game project could be, it's still an undertaking!)
I'm sorry that some channels were frustrating, I hope that once you learn some more things it becomes a bit smoother to work with. I like to see learning dev as cooking, you need a strict guide the first few times you do things or else it might come out bad, but then once you learn the base techniques and cut a couple hundred onions, you'll be able to do more with less time paused to look up tutorials, and it'll feel much nicer to work with!
I couldn't agree with you more. I'm definitely going to try and chop things up into small chunks, to see how things work elsewhere. I have a potato of a Windows PC, I will likely use for some of that, but I will likely open up versions to a small community from TH-cam for playtesting when I get to that point, maybe even a few events too for feedback.
That's a really interesting take on it. It is very much like cooking. As you evolve, you work out what works well together, and you develop from there. I also think that learning style has a big impact on those videos being useful, and different styles of presentation have leant into that more and more, which might be why I found some more challenging than others.
Thank you for your support.
Good luck with your channel!
Thank you! I hope you enjoyed the video
10:24 here's a helpful tip. in the script, ctrl+click the get_vector function and you'll see the input parameters...
and you'll see that the function actually ask for x coordinate inputs first. but you gave up and down
Oooooooo that is incredibly helpful! Thank you. That's one of the things about Godot I quite like, it does try to help sometimes.
The supported languages for Godot 4 is GDScript and C#. C# is much easier than C++ so I would got with C# if I were you.
mod: oh, you already knew about it. I do not recommend C++ if you just started development now. For example, you have to manage the memory yourself, allocate and free it when needed.
Ha with C++ I'm more worried about my memory than having to manage the system's. It's a beast, it could break me.
I have that same Empire State Building Lego set on top of my fridge!
Also, nice video! 👍🏻 I'm learning Blender now to develop a game later down the line, my thinking with starting with Blender was that if I start with a world that is aesthetically beautiful, the motivation for the coding part will come easier
Thank you! That's really cool that you're learning Blender. I've heard so many amazing things about it. I really like that you're focusing on that artistic side. That's really good motivator to learn to build! I'm going to be looking at art after this series of test-outs for different engines. Have you posted any of your work yet, even the early stuff?
Hey, small question what is the name of the program you used to take your notes, at around 5:32 of the video?
But yeah, i agree with you, its really bad, when the docs say that you need to go learn CS before being able to even use the engine, thats just plain bad to be honest, but i think i understand it a bit it was probably written at a time where there were not many tutorials for the engine so it was rather difficult for them to point at any one, granted its not an excuse and it shouldnt be written but i get the logic behind it.
No problem - I use Notion. www.notion.so
I've used it for years, I do a lot of custom stuff with it, its free and I love it. I might make a video on how I use it one day if that would be useful? ¯\_(ツ)_/¯
It's a shame about the documentation, imagine how many people you'd enable if you had stuff that was usable by anyone without experience.
great tips!
Thanks, I hope you found them useful 🤓
When it comes to programming the documentation is kind of like a dictionary, and you'd never pick up a dictionary if you were learning a normal language. It's incredibly useful when you have a basic grasp on the language, but it's definitely not the best resource for a beginner! Following a tutorial and changing and breaking things is definitely the best way to learn.
I really like that thinking to documentation. Actually helps me think about it a little differently. It'll definitely be more of a dictionary going forward - I have found it's not great for troubleshooting though sadly.
Love your glasses!
Thank you very much. I only recently made the change to go for yellow tinted lenses to help with eye fatigue as I spend 10-14 hours a day in front of screens.
I appreciate this perspective. I've been using unreal and unity so long i have some transferable concepts already. But i know what is like to start from scratch on something new and god knows i did everything backwards lol i fiddled with a lot of engines.. some that were new and little known. My hope is the Godot community fleshes out a bit better the learning curve with better uniform tutorials..
You're welcome 🤓 That's really cool! Yeah it can be a little overwhelming at times, going from zero. I've had a lot of great recommendations in the comments section on some learning vids, on top of what I've already used. Especially the 11 hour Clear Code course, which is what I think I'll end up going back to after my initial level build if I decide to move forward with Godot & GDScript. Thanks for sharing your experience.
I think the logic behind the documentation telling you to "go learn computer science" is that the author has made the decision to target people with that foundation. Otherwise they'd have to include all the basics of programming in a document that's supposed to teach you about how *Godot* works. While you could technically do all your programming in C++, it's neither the most suitable language for general game scripts nor a language that Godot supports as the primary language for your project. The only time you really benefit from it is when you need very high performance (for example for advanced custom simulations, managing lots of data, or advanced visual effects) or for very specific technical requirements. I would save if for Unreal if you want to try that later, because when writing C++ for Unreal there's a fairly specific way you want to write it, following their framework. Becoming "fluent" in C++ takes a LOT of time and experience, but writing basic scripts for an Unreal game only requires a fraction of its features if you follow some templates for how to organise your code. Even in Unreal you might find everything you need in the Blueprint visual scripting system, which is not only much simpler and more streamlined than C++, but provides a much smoother developer experience in many other ways.
I think that's very fair. I've been discovering some things about C++ I'm covering in a future video. Your point about Blueprint is spot on, I think it could be a really interesting way to look at making a game. It's on my evaluation list, and I'm kinda excited to take a look. Thanks for sharing :)
I love your passion for creativity and your patience to take it one step at a time. I subbed. I’m coming along for the ride of whatever you are sharing. 🫡
Thanks so much! Welcome aboard, I think you'll see a lot of failing 😂 but I'm optimistic.
Thank you for sharing your experience of learning the engine, I wish you good luck in the further development of the game. I'm currently at a crossroads between Unity and Godot. I'm going to make a 2D car game that requires an expensive physics engine with joints. Unity provides all this, but it is too bulky an engine for such a project. In addition, the size of the finished game in Unity is too large. I'm trying to implement my project in Godot, now I'm looking for information on using the Box2D physics engine in Godot.
Thank you for your support. That sounds like an interesting challenge you have there. What made you want to integrate the Box2D engine into Godot?
I want to try to integrate the Box2D engine into Godot to simulate a car suspension in 2D. I previously tried to do this in Unity, it has good built-in physics. In Godot, the physics are simpler, so it makes sense to use Box2D, which is very easy to integrate.
I'm legitimately curious what you're actually looking for from the engine? You said you wanted to tell a story, but that can be a million different things, and there's a million ways to build any project in code.
No offense, it just sounds like you were looking for a more focused toolkit like a "______-maker" style engine rather than an open-ended system that requires general programming knowledge.
Not saying your experiences are "wrong" but I'm curious exactly what you were expecting going in.
Best of luck regardless of what you choose! cheers dude
Thanks for your support and your question. I think that's completely valid. Why did I start exploring with something that required more skill vs an off-the-shelf "_____-maker" no-code solution?
There's a few answers to this question.
When I built out my game design document, I noticed the mechanics I wanted to build were potentially quite a lot for standard off the shelf solutions. Exploring tools like Godot should give me a bit more flexibility in that arena. From what I'd read, I didn't have the same confidence a no-code solution would have been able to do the same thing.
I've worked in tech for about a decade and have never written a line of code. I thought that by selecting something that required a bit more technical skill, it would help me be better at my job and have a rough understanding of some of the considerations my developer colleagues have, at the same time as making something with a little more depth to it.
I also thought by looking at more complex engines, if I found that this was something I deeply enjoyed and wanted to do again, I wouldn't have to learn a new toolset and to code, further down the line, potentially at a time in life where it would be harder to carve out that time.
And finally I've been playing games for over 30 years, understanding more about how they are constructed and the level of effort that goes into them, will help me appreciate them a lot more.
On your point about general programming knowledge, I think the thing going into Godot that surprised me, was that they built their own language (GDScript) and I guess I was naive enough to expect that I could pick up that language through their documentation, without needing any wider programming knowledge. This is all a learning curve and I'm excited to try stuff and fail a lot, and I feel like I've already done that a lot!
Thanks again for your support and I'd be keen to have you along for the ride.
@@TheInfiniteInkwell Oh yeah, that makes sense, just looking for a more open-ended solution to match your design.
I picked up Godot after years of going back-and-forth with coding because I *don't* work in tech and it took me FOREVER to get my head around conceptualizing abstractions to build concrete objects. And I kept giving up out of frustration.
One of the biggest breakthroughs for me was actually a very tiny game engine called microStudio. It has built-in tutorials to teach programming basics, and the way the concepts are explained just really made things click for me. I don't actually remember if they have a scripting language or use Python, but it's got similar syntax for the fundamentals.
Maybe all my prior experience just led to eventual success there, but I definitely got a good push in the right direction from it.
It probably isn't on your list but it may still be worth spending a few hours one afternoon to knock out the tutorials.
Looking forward to watching your progress. Cheers dude
Gdscript is such a good starter language so I dont know why they dont present it like that
I couldn't agree more, it's a real shame.
great video! can you share what program did u used to organize your notes?
Thank you! I've been using Notion. I'm a massive fan of Notion and have been using it for years. www.notion.so/
I customise almost all of my spaces, some of the templates are decent too. One of the publicly created templates I love is from akm_design, their game design document is actually really good for beginners like me - www.notion.so/templates/gdd-step-by-step-guide
@@TheInfiniteInkwell Thanks a lot! this video really inspired me to get back to a game project i've been working on! Definetely will keep an eye your next videos ^^
What make you choose C++ for Godot ? Any technical reasons ?
Good question! It was more that it could be useful across both Godot & Unreal. Also if I wanted to go down the dev route for work, that wasn't game development, C++ could also be quite practical. That's not to say C# wouldn't be useful outside of game dev, but it would remove Unreal from the table and replace it with Unity, which I have some concerns with.
I recommend Brackeys new tutorial on Godot to get started.
Thanks I've added it to my watch later list. I have seen rumblings online since they launched it.
Stick with gdscript for now c3 and c++ add nothing but unneeded complexity when you start.
Now, with regards to to using the tutorials, I would suggest trying to solve it yourself before looking it up. That way, you'd understand what it is you're trying to accomplish and potentially know what to do when it doesn't work. Much like how you documented your learnings, write down what you idea is and how you plan on approaching first.
Also starting over really reinforces if you fully understand what you learned and that is par for the course when programming.
Thanks so much for the advice. Yeah C++ & C# is a lot more of a stretch, but I'm thinking it'll be good to understand the opportunity with it, even if it also shows me how insanely complex it is - which is actually going to be a really good learning if that's the case. I'm all good with trying and failing.
I bet you will hate to hear this, but I do recommend looking into Clear Code youtube channel and his 14 hour godot tutorial. At this point, dont do the whole thing. Just look at the notes you already have and compare them to how he does similar things. For example, I like how he explains the player movement.
Whether you do or not, I wish you well on your learning journey!
Not at all - thank you, I really appreciate the input! I had a quick flick through it and this Clear Code video actually looks really awesome and goes into a lot more detail about things like detailed physics, UI and lighting and such. Right now, I'm just starting with some basics for a light evaluation of the different approaches I might take. This course is going to be incredibly useful if Godot with GDScript comes out on top for during my very unscientific testing phase (which I think it has a good chance of). So thank you 😀
I learnt how to use blueprints with UE4 then decided I'd better learn the c++ side of things, the c++ side of things instantly zapped all the fun out of the game creation process. There was no advantage in using c++ over blueprints either so stick with GD script or c#.
Oh interesting. Did you abandon C++ and go back to Blueprint? Genuinely intrigued. Thanks for sharing your experience.
@@TheInfiniteInkwell I went back to blueprints for a while, then have switched to Godot using GDscript.
You should try orchestrator plugin
Thanks I'll take a look at it.
At 05:40 you have written down the correct way of mapping in your notes.
🤦🏻♂️ I didn't think it would make a difference. As another commenter tells me, there's a really good reason it didn't work. Definitely a proper newbie mistake!
Just Watch Brackeys, he did a complete 2D tutorial and its quiet a fun tutorial
I think if I go down the Godot route, I probably will. I might actually go back and check it out anyway, there's been a lot of buzz about the return of Brackeys with Godot, and I've had a lot of recommendations for it.
I understand exactly what you're going through. Having learned the basics of Game Maker when it first came out, somehow my license I purchased wasn't valid. Unity, which I was doing well, in the middle of a project when my computer crashed, and now Godot.
My advice, be very specific to yourself about what game you're building. As you stated you were learning features not necessary to your game, or implementation was different. This is every game engine. Narrowing down your desired product, will limit the content needed, and needed to learn. As you learn the engine, you will come across topic specific language or words that don't, and may not be relevant to what your doing, being aware of the engine documentation suggestion is for this very reason. So you can more easily identify what you need in solutions, from what may very well impede on progression. People having used the engine aren't going to layout definitions, and wholesale solutions, as part of design and development is problem solving, and in open source everyone is a participant, even in naming issues. Most are absolutely going to point you in the right general direction, or even work with you of they see utility in your methods.
Sounds to me you desire to make an interactive story, much like the PC games of the late 80's, and early 90's, some of which are alive and well today. You aren't just authoring, or developing, but directing as well. So perspective is going to be key in presentation. 2D is definitely going to be quicker, and more FX can be faked easier, if desired. There's a few ways to storytell with convincing perspective, or perspectives. Art is a big deal always, as an artists, I know, and people have only gotten pickier. As far as programming languages, GD script is great for certain things, and highly portable, being it's a python based language, and easily incorporated with C#. Again this falls on what you're trying to do. Most basics like U.I., animations, instancing, basic Godot functions are best done in GD script. Where C# shines is being more portable than GD script as a language, and is best for the extras, customized features, such as shaders, text, U.I. functions, networking implementation, and their like. As C# is older, and widely available, and flexible, concerning portability to other platforms, consoles, tablets, iPhone, ect. As each of those has their own file, app, settings, ect. Structures, not so different from one another, but enough. Some using completely closed software, and others open source. Most closed software is easy enough to emulate, why I enjoy open source. So learning the basics on those two languages is going to be crucial. However, neither is hard to pick up, and not GD script so much, but a ton of comprehensive introduction videos on C#, and how to use it. You say a basic story 😂, my friend, Lion King is a pretty basic story, still a decently long presentation, and would have been longer with U.I. input. So make sure you have something engaging in the U.I. loop/game loop. Most focus on fun, but engaging is the ticket, especially with a storytelling/storyline genre. Live story alterations decision based is a popular way to go, alternate endings as well.
Thank you so much for this! It was a fascinating read. That's quite the journey you've been on with engines there - have you gone back to GameMaker (if you managed to get the licensing issue sorted)?
I think going forward I am going to be very specific. After my engine evaluation, I'll likely go back to my Game Design Document and review it, to see if anything has changed and adapt it.
The next stage after engine evaluation is to spend a lot of time fleshing out the story, the art and the expected mechanics that will be supported by the engine. I'm hoping that'll give me enough to build out the rest. Something that should feel reassuring is that I will be spending a lot of time ensuring the UI is decent. I spend a lot of time working with UX designers for work, and have even done some basic designs and wireframes myself, so it'll be something I will likely obsess over 😂 especially considering how bad some UIs have been in games lately *cough* Diablo 4 *cough*
Engaging is what I'm going for, with maybe elements of fun sprinkled throughout. I've had some ideas on how I can include more fun.
Thanks again so much for your thoughts, and guidance. I really appreciate it. What're you making at the moment?
audio too low
Roger that, I'm working on improving this for future videos
Multiple your direction by -1
Is this how I'd invert the direction? If so that's actually super useful - thank you :)
stay away from gdquest! Devworm and Heartbeast are much better!
I've not heard of Heartbeast, thanks so much!
9:39 Most devs agree that as a general rule you shouldn't write comments, if a piece of code needs a comment to explain you should make your code more clear (variable names, extract it to a function, clean up conditions, etc).
That's interesting to hear, I've heard something quite different from the devs I've worked with. A lot of them use it as a form of documentation, instead of writing additional content. But I do agree that the code should be simple to understand, which I will try to do more, as my comments are overkill. Thanks for your comment.
@@TheInfiniteInkwell
I strongly disagree, and I don't know any professional dev who follows this. It's taking a solid principle (self-explanatory code) and applying it as if you live in an ideal world where all code can be, and must be self-explanatory.
"Self-documenting" is a bit of a meme, because it's very common for beginner programmers to think their code is obvious when actually it's a complete mess to everyone else (and their future self).
Self-explanatory code in itself should be something to strive for, but comments absolutely still have their place. You just want to make sure that the information is useful, that the information isn't clear from the code itself and assumed basic knowledge, and that you can't simply refactor the code to make it clear instead.
The documentation is terrible especially for a beginner. Even though now i can code any feature now it's still confusing
I definitely disagree. It's superior to documentation from other engines by far. I do think their explanations are a bit too technical for a beginner though.
@@pythonxz But thats the issue, a beginner will have no idea what theyre reading
@@azlantg Understandable. I think where Unity's documentation explains something, it is usually more for the laymen. However, they have created a mess with the documentation being split between so many different places, which is not so friendly to beginners either.
@pythonxz I haven't read unity documentation or other game engine ones so I'm not comparing it to any. It seems all the documentation could use work. I might update it myself.
@@azlantg At least you can do that for Godot.