Building games with Godot Engine

Thanks Clay - that was kinda my thinking as well. I guess its impossible to not make a few mistakes as a tutor, but I think that something like explaining how on earth a Godot program starts would be nice to go over (I could be mistaken, but I dont think he EVER explained what _ready(): really is for instance. Or what _functions are).

I will power on, maybe start and then bombard you guys with questions like “How do I make my game” :-D

I’m happy to help however I can. Most game engines provide functions that can be called at certain points during the execution of the game loop, to insert logic at a known point. _ready() is one of those functions. There’s more explanation in the docs. Look at the section on overridable functions. That essentially means that the function is being called behind the scenes, but you can write a version of it in your script (aka override it) to have it do specific processing for you related to the script/scene, instead of just the basic stuff that routinely happens. It’s not required to override, but is available for convenience.

The _ready() function is called when the node, and all its children, enters the active scene. Note: _ready() is not the constructor; the constructor is instead _init() .

I’m not a programmer, but I have learned enough python to build models and tools for the different apps I use. Following this thread because I’m also interested in Godot.

Anyways, when learning python it was really helpful for me to repeat the training project on my own, using my own data / idea. In my case that meant replacing the practice dataset with my own, then figuring out all the reasons mine didn’t work.

With Godot, that might mean changing a couple of game rules or using different assets. Just something that helps you look at the practice material in a different light. The repetition is always good and the inevitable troubleshooting will help you learn to recognize your code.

I kind of have the opposite opinion to Clay. I never learn anything in a language unless I have a project I want to do. Every time I come to a roadblock, I have to learn something, so I look up docs or look for tutorials. But everything is in service of figuring out how to advance my project. If I’m just going through a tutorial for the sake of doing the tutorial, I get bored immediately and quit.

Now, of course, with something like Godot, the first roadblocks are things like “how do I install Godot” and “how do I create a project in Godot”, so obviously some basic introductory tutorials are needed. But after that I just pursue the specific things I’m trying to do.

Horses for courses, I suppose.

I’m the same way, actually. I think the projects in that tutorial series are really just good for showing what is possible with simple games. Like Unity or UE4 or whatever… there are tons of things you can do in Godot, but if you don’t know about them and how they’re used in context, then it’s hard to do them. But generally, I agree. That’s why I suggested he consider starting his personal project simultaneously.

I said it before, I say it again. The official docs are your best resource. :)

I would have done that before doing any courses as it’s really foundational basics. Go through the ‘first steps’ section, which takes you through making a (very) small game and doing some UI stuff. For your RPG character generator thing you’ll probably be focusing mainly on UI, and there’s a decent section in there on how all that works to get you going.

https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html

With your tutorial course I hope you are at least typing all the code out and not pasting it. :)
Even doing that, I find just copying someone else’s stuff is not that great for learning it. You need to be doing your own little things as you go. And if you don’t understand something, search the docs, try playing with it until you do.

I agree with the other guys basically. You should absolutely be playing and discovering and trying out your own stuff as you go, and asking about or looking up anything you don’t really understand.

Just keep it really simple to start.

Thanks @Profanicus - I think I just assumed that the intro course was as basic as it could be, and my (admittedly 20 years old, never used learning) previous experience could help me.

I do type myself though :-D And I try to understand, but there are a few places where I simply don’t get WHY it works like it does. As you mention yourself though, I chalk that up to doing someone elses project, and stuff will fall more into place once I start doing my own.

I’ll take a look at the docs monday and see about starting my own stuff up a bit - maybe a small text adventure with optional mouse controls and a small graphics window if I am feeling crazy.

This is the problem with learning anything other than just the base library of a programming language. By definition, games engines do A LOT for you at a high level of abstraction exactly so that you don’t have to know how to do it all or why. That makes learning a challenge. The same would be true if you were learning programming through some other framework, like Ruby on Rails, or Django, or openFrameworks, etc.

As for a first project: keep it as simple as you possibly can and finish it quickly. Even a project that takes 2 hours would be great! Maybe a random character sheet generator where you can pick the portrait out of multiple options, or something super duper simple. Resist the temptation to make your very first project complex.

Just go through the motions of starting from scratch, implementing it, then completing it. Also, do yourself a favor and don’t try to get it working on a mobile device yet!

A quick question. I want to build a stats panel for my game as a vertical bar on the right side of my game screen. I believe there is only one game window possible in Godot, correct? I think that means I would have to overlay the right side of my game window space with the stats panel, which will cramp the view space. Should I just extend the main window to the right so I have enough space for that? No matter what I do, my concern is that the player will no longer be centered on the screen with the panel there. It would be nice if I could build a UI element like that outside the main window to avoid that.

Edit: Best I can tell, I may be able to do what I need with Containers if I can figure out how.

You don’t have to use containers, especially if your layout is simple. You can use the ‘anchor’ attribute of Controls to set how much of the window they take up.

For example, your main window could have Top anchor at 0, Bottom anchor at 1 (meaning it takes all vertical space), then a Left anchor of 0 and a Right anchor of 0.8, meaning it takes up 80 percent of horizontal space (starting at the left edge).

Then your stats window can have Top anchor 0, Bottom anchor 1 (takes up all vertical space), then Left anchor 0.8 and Right anchor 1 (takes up 20 percent of horizontal space, starting at 80% and going to the right edge).

I think if your layout gets more complicated you will need Containers, but for this that should do it? Assuming I’m understanding your question.

Okay thanks. I didn’t know about anchors so I’ll research that.

You can kind of have multiple using viewports. For split screen multiplayer for example:

But yeah something like that seems overkill for a HUD/UI side bar.

Yeah, best I can tell I will have to figure out how to add a couple of CanvasLayer nodes to my main window and run the game map in one and put the stats/inventory UI stuff in the other. The main window node itself doesn’t appear to have any margins or anchor settings.

I see Godot 4.0 is supposed to come out sometime this year making me wonder if I should just wait for it to learn this stuff.

I wouldn’t hold your breath for 4.0 :)

Aren’t you basically trying to do the same thing as the Ashgard Keep?

If so, check out their Game.tscn scene. Looking at that, they have used the viewport method.

The base ‘Game’ node is a Control, and every area of the screen is laid out with the responsive UI containers. If you want to understand how all that works, quickly go through the UI tutorials in the docs, the Design a Title Screen and Design a GUI ones:
https://docs.godotengine.org/en/latest/getting_started/step_by_step/ui_main_menu.html

Then for the map their container on the left contains a Viewport Container, which has the TileMap in it.

Nathan at GDQuest On YouTube also has good short video tutorials on how to do what you’re asking.

Yeah, basically. I’d set that project aside because I couldn’t fix a scene that won’t load in Godot 3.2 but I’ll go back and take a look at that part of it.

I’ll look at that as well. Thanks.

Edit: I took a quick look at Ashgard Keep again. It’s what I thought, several containers inside a main container with margins set to position them inside. The viewport container is the only thing I’m not sure about so I will do some reading on implementing those and view the tutorials. The tools are pretty nice if you can figure them out. It’s a lot to learn and the nodes have a zillion settings.

Is anyone here doing his? I’ve never tried and it could be interesting.

I guess you would need to replace/port all TCOD functionality yourself, and change all the console stuff to use Tilemaps?

I am currently running through GODOTs own tutorial, and its game called “dodge the creeps”, which has some funny connotations these days.

Anyways - in the _process(delta) I have some input checking, and use of velocity and Vector2.

That is fine, and I understand that. At the end, the tutorial wants me to use a “position” to get the sprite to stay in the confines of a previously gotten screensize.

My issue is, that GODOT doens’t understand what “position” is - is that supposed to be a part of vector and I did something wrong? OR did the tutorial make a mistake here?

Here is the code:

extends Area2D

export var speed = 400
var screen_size

Called when the node enters the scene tree for the first time.

func _ready():
screen_size = get_viewport_rect().size

func _process(delta):
var velocity = Vector2()
if Input.is_action_pressed(“ui_right”):
velocity.x +=1
if Input.is_action_pressed(“ui_left”):
velocity.x -=1
if Input.is_action_pressed(“ui_down”):
velocity.y +=1
if Input.is_action_pressed(“ui_up”):
velocity.y -=1
if velocity.length() > 0:
velocity = velocity.normalized() * speed
$AnimatedSprite.play()
else:
$AnimatedSprite.stop()

position += velocity * delta
position.x = clamp(position.x, 0, screen_size.x)
position.y = clamp(position.y, 0, screen_size.y)

I know that usually these kind of errors are because I forgot something somewhere, but a word search on the page for “position” does not reveal anything previous to this use of the word, and I even tried copy pasting the tutorials code into my code instead, but get the same result.

Any help is appriciated!

It’s just an error in your indenting.

The position stuff needs to be indented so it’s part of the _process function, like the var and ifs etc are.