Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

Thanks, I'll take a look at them when I get a chance.

The background not moving with the player would make sense for why I felt things were off when I tried using it for getting my bearings. If you'd like, our last game Salvage Hunter, was a space shooter, and here's how we did the background. We did a multi-layered Parallax background, with objects on each being a different size, and moving at a different speed, to simulate distance. We had a mixture of stars and clouds/nebulae. We also had a setting where the player could adjust the alpha of each layer, if it was too distracting, and started at 70%. The background was moving a bit even when the player was not, though the game was a side-scroller, so there was an implied always moving to it. For something like this, I personally would still give the background some movement, but much more subtle than we did for the side-scroller. When the player moved, we adjusted the background position in relation to the player's movement, but only a small amount (1/100th the player's movement), and for each layer it was multiplied by the Scroll Scale to keep that layer feeling like it was the proper distance. Here's the code we used in the Background class.

func _physics_process(_delta: float) -> void:
     var player_velocity := Vector2.ZERO
     if is_instance_valid(player):
         player_velocity = player.velocity
     var adjusted_player_velocity = player_velocity / 100.0
     for child in get_children():
         if child is Parallax2D:
             child.scroll_offset -= (adjusted_player_velocity + scroll_base) * child.scroll_scale
(+1)

I appreciate the thought and the code. I actually have a parallax scrolling background in the game that worked great with an image. It just doesn't work with the shader I'm using. The shader itself maintains the same look no matter how you move the texture it is applied to. So I was trying to work with the shader. Unfortunately, the direction of the shader only moved with a float. So I had to change it to a Vector2, then rotate it, then turn off the constant rotation, then do this:

# Given a player velocity, animate the starfield. func _physics_process(_delta: float) -> void:
     if Game.starfield_panning:
         var limited_vector := player.velocity.limit_length()
         var panning_vector := Vector2(limited_vector.y, limited_vector.x)
         #print(panning_vector)
         starfield_texture.material.set_shader_parameter("pan_speed", panning_vector * 1.0)
     if Game.starfield_acceleration:
         if player.velocity.x < 0 or player.velocity.y < 0:
             starfield_texture.material.set_shader_parameter("anim_speed", 0.75)
         elif player.velocity.x > 0 or player.velocity.y > 0:
             starfield_texture.material.set_shader_parameter("anim_speed", -0.75)
         else:
             starfield_texture.material.set_shader_parameter("anim_speed", 0.2)

The problem is it always looks like you're jumping into warp speed, even if I use really low numbers like 0.1 (instead of 0.75). In this case I think I just needed to rebuild the shader from the ground up - and it's a bit outside my wheelhouse.

(+2)

Shaders can be fun and create awesome effects, but I'm just a beginner with them. I did start coding with C, so at least the syntax isn't a problem for me, but there's lot in there I'm not as familiar with, and have to look up, that I tend to keep them simple for now.

It is awesome how much code and process you share. I'm starting to read through your devlogs, and they are very interesting. I'll have the kids read through them later as well. We will likely take some inspiration from some of this in the future.

(+1)

Yeah, I was using someone else's code. I've made a number of 2D and 3D shaders. I prefer using the visual shaders rather than code because I like how it helps me structure my thinking and also see all the options possible. But really I had to learn how to write them in Godot's version of GLSL before I could effectively use them. I've found that converting shaders from Godot's GLSL into a Visual Shader really helps me understand how they're working.

Yeah I spent about 1.5-2 hours every night writing them. My brother said it would help me to get people interested in what I'm working on for when I'm selling my own games as opposed to working on other people's for money. I would also recommend you check out my (FREE) course on learning how to be a software developer through game development with Godot. There are only 6 classes, but I spent a 40-hour week on writing each one. I thought perhaps I could make money that way, but it turned out to be too much work so I made them free to the Godot community. Some of the code is not the way I would do things in Godot now, but it teaches a lot about the engine, as well as source control, unit testing, and a LOT on game design. There are a ton of links in there on object-oriented programming, the history of video game design and development, etc.

(+1)

Thanks. We will check it out. I've dabbled in game dev since I was teen and taught myself programming from books with CDs containing compilers and code, but my main job was web dev for almost 20 years. It's been fun, but challenging, trying to make the dream of doing game dev for a living come true.

Selling classes/tutorials can be hard these days with so much free on YouTube. We got a set of Zenva classes from a Humble Bundle and hated them. I got them to start teaching my kids, but kept having to stop them and point out things that were wrong, or terrible advice. Then we went onto YouTube and found several free courses that were much better. We did purchase some paid content from some creators after the free courses, but it is a full time job putting out enough free content to get that following, and from the comments I've heard them make, its not doing as well these days. And, of course, you have to keep updating the content as things change.

(+1)

BTW, I was doing a Zenva course yesterday and I was thinking about your evaluation of them. I realized that as a now seasoned Godot developer, I just ignore all the poor choices they make in coding, and take what's useful for me. They definitely have some good programming tricks IMO. However, overall I find GameDev.tv has better, more complete courses. They still have issues, like using @export variables when they should use @onready variables, but at least they don't pepper their code with hard-coded node references everywhere. You might check their courses out, though I have to say that while I found their Godot courses above average, I found their Blender courses to be stellar.

(+1)

I had enough experience to recognize problems, and discuss them with my family, but these were intro courses meant for beginners who generally wouldn't know. Teaching bad habits to beginners who may carry them on for years to come is problematic. We did leave feedback pointing out the problems we saw, and that was several years ago now, so I don't know how things have changed. Hearing that you also notice problems that need to be ignored makes me think they have not taken such feedback to heart. The poor intro classes teaching beginners bad habits was enough that I don't want to support them at all, even if I personally could filter the info.

I've heard of GameDev.tv before, though we have not done any of their courses. We will check them out to see if anything is interesting, thanks. We mainly used the courses as a way to learn the basics. We have several dev YouTube channels we watch sometimes when they have tips, but mostly we learn by running into a problem and looking for a solution, or thinking of something we'd like to do and searching for info on it. Sitting and doing a full course is not our preferred learning style, and generally only for something new where we need a foundation to build on. Blender is something we are still only dabbling as we mostly do 2D currently, so those courses may be worth a look when we are ready for more in-depth 3D modelling, thanks for the tip.