Skip to main content

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

Thanks for playing! Yeah, the ship felt sluggish because I got a lot of complaints that it was too hard to stop. So I added two Inertial Dampeners to the ship. My plan was to make a separate starting ship for each character, but I ran out of time.

The station does appear on the radar. Do you mean if you get too far away from it, pointing where it is? If you take a look at my DevLogs I talk about the pains I went through to make the background scroll. I lost a whole day to it. Which is why things like the radar zoom didn't get implemented.

Yeah, I went into it in detail in my DevLogs, but I've been dinged before for bugs I knew about about didn't fix over adding features, so I went the other way this time and spent a whole 2 days just stomping on bugs. I had a whole design system where you can drag parts onto the ship at docking points, and then was going to use those for the katamari effect. Lack of time led to the cool Frankensteining thing though.

Yeah I haven't used Kenney's stuff much other than for control icons, but I saw this pack and thought it'd be fun, plus I've never made a space game.

I'm glad you enjoyed it. Thanks for the feedback!

(+2)

I was meaning to add something pointing to the station when it is not on the radar due to distance. My first run after I defeated all the enemies nearby I went exploring for more, and then realized I had lost my bearings and wasn't sure where the station was. Something pointing the way home would have been nice to have then. Later I found that enemies spawned close enough I did not need to go so far away, so maybe it is not vital, just a nice to have if you do get lost. I did acknowledge the parallax background, but the way it moved just wasn't registering in my brain in a way I could instinctively keep track of my position while looking at everything else.

Sorry, I only skimmed the devlog. We try to play and comment on as many games as possible during the first few days of a jam, so don't take a lot of time to read devlogs, unless there is a comment that they contain the basic controls or tutorial. It sounds like you have a lot of cool features planned that will make the game feel more complete. And I fully understand trying to predict what the next group of jam participants are going to want, and trying to plan your dev time to cater to it, only to find comments that the things you skipped are of interest to the players.

We always use Kenney's assets for the remapping icons, and occasionally for other UI elements, but we also used this space pack in a previous space game. It works really well for simple pixel art sci-fi.

It sounds like this should be a fun game when finished. We'll be sure to check it out again in the future.

(+2)

Fair Enough. I do the same thing. Last game jam I got 70 reviews by doing that. This one I did 30 in the first two days. I just found out itch compiled a page of all my devlogs for this jam if you're interested later. Katamari Mech Spacey DevLogs There are code snippets in there, as well as a lot of other information you might find useful as I see you're trying to do this professionally.

Also to be clear, the background is not moving in reaction to your movement. It's the asteroids and ships that do that wahen you hit them with your Frankenship. The background just moves in the same direction slowly, no matter what. Making it react to the player's movement caused it to look like you were entering warp speed and was even more confusing.

(+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.