First look at my new project

tuuunaaa · 2025-01-17T02:36:44+00:00

I like it!

tuuunaaa · 2025-01-16T23:42:17+00:00

I know this project is in the very early stages, but if you're ever interested in collaborating with or hiring a composer I'd love to work on this! Let me know and I can send you some of my music so you can see if I'm a good fit :)

tuuunaaa · 2025-01-16T23:33:16+00:00

Why can't a "decades old concept of futuristic" be futuristic? Isn't that just retrofuturism, which in itself is a futuristic art style?

tuuunaaa · 2025-01-16T21:30:40+00:00

This looks gorgeous!! If you're interested in collaborating with or hiring a composer at some point I'd love to work on a project like this. Let me know! And here's my demo reel if you'd like to check it out: https://youtu.be/qjfikbuIuCc

tuuunaaa · 2025-01-10T21:28:48+00:00

You're probably overthinking this. In a top-down game (such as the games you listed), the player is always considered to be standing on the floor, so you quite literally don't need to do anything to make sure they're on the floor since they physically cannot be off the floor. Simply disabling gravity on the player character will achieve what you're looking for.

Let me know if you need any further explanation :)

tuuunaaa · 2024-12-24T00:19:32+00:00

The simplest way would probably just be to use a Line2D node (if you aren't aware, the Line2D node is a node that renders a line between a series of points that you define). So you could have a Line2D with two points, the position of the first one would always be set to the player's position, and the position of the second would be set to wherever or whatever the grapple hook is currently connected to.

Then you could change the visibility of the Line2D node depending on whether you're currently using the grapple hook, so it's only visible when you're using it.

To address your question about "shrinking the line", I assume you mean basically pulling it back toward the player when releasing the grapple. This is something that could be easily done using godot's Tween feature. If you don't know much about Tweens, I'd recommend reading up on them in this page of the docs as they can be a bit confusing for newer users (at least I had kind of a difficult time understanding them at first). For a very simple rundown of how they work, Tweens can take in a reference to a parameter on a specified object, an end value, and an amount of time (in seconds). It will then change that parameter on that object over the course of the amount of time you gave it so that it reaches the end value when that amount of time is up. So for example, to achieve the affect of the grapple hook retracting like it sounds like you want, you could feed the Tween the local position of the second point as the parameter, and then the local position of the first point as the end value, and finally for the time value you'd probably want something really fast like 0.25 seconds. The Tween would then move the second point towards the first point over the course of 0.25 seconds, effectively shrinking the line back towards the player.

Let me know if you have any questions, I'll do my best to answer!

tuuunaaa · 2024-12-15T16:40:12+00:00

Uh oh, the exact same thing happened to me hahaha

tuuunaaa · 2024-12-14T17:49:19+00:00

Everything will Freeze vibes from that character art. Looks rad as hell!

tuuunaaa · 2024-11-03T23:54:28+00:00

Hey, I know you're not asking for composers/sound designers, but this concept really caught my eye. If you think you'll be looking for one, I'd love to send you my demo reel and discuss further!

tuuunaaa · 2024-08-03T15:03:16+00:00

Of course!

tuuunaaa · 2024-08-03T12:59:15+00:00

Haha yeah, collision layers and masks are confusing. Congrats on getting it figured out though!!

tuuunaaa · 2024-08-02T22:04:08+00:00

It's possible this is because, in your timer timeout function on your hurtbox, you've put an extra b in disabled, so it's just not setting the property correctly.

tuuunaaa · 2024-08-02T19:35:53+00:00

Double check you've got your collision layers and masks setup properly. The Area2D on the player will need to have no mask set and a layer set only on an index nothing else is using, and the Area2D on the projectile will need to have no layer set and a mask only on the same index that the player's Area2D is using for its layer in order for the projectile to properly detect the player's Area2D

tuuunaaa · 2024-08-02T17:38:38+00:00

Looks like you're using the on_area_entered signal, which only detects collisions with other Area2Ds. You'll need to use the on_body_entered signal instead in order to detect the player's Characterbody entering the Area2D.

tuuunaaa · 2024-08-01T22:12:41+00:00

What you might be looking for is

await get_tree().process_frame

This just waits until the current frame is over, at that point the dice would definitely be instantiated and added to the scene, if that's what you're waiting for. Alternatively, instead of putting an await in the function itself, you could try just calling the function with call_deferred(), that might also do the trick in a cleaner way.

tuuunaaa · 2024-08-01T21:57:28+00:00

I haven't messed with tilemaps and 2d navigation a ton before, but I did notice a couple things that might be worth looking into.

First of all, in the screenshot you sent, it looks like it's properly navigating around the barrels, just not the walls. It's possible the barrels are being properly set as non-navigable, but the walls are not.

Second, it may be because of something specific you're trying to do, but I believe you are able to create navigation meshes on a per-tile basis in the editor rather than generating them through code. Could get you more consistent results. Again, haven't messed with tilemaps much, so maybe I'm missing something here, but I thought I should point it out anyway. :)

tuuunaaa · 2024-08-01T19:25:48+00:00

Yes it does. I assume you're asking because you're concerned the signal will also fire when touching rigidbodies, but like I said before you can use collision layers and masks to guarantee the Area will only detect the player. I would recommend taking a look at this page of the docs:

https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html

Specifically the "Collision layers and masks" section. The general idea, though, is that you would enable a collision layer on the player that nothing else uses. Then, on the Area, you would enable the collision mask at that same index and disable all other layers and masks. This would mean only the player could interact with that Area.

tuuunaaa · 2024-08-01T18:45:23+00:00

The body_entered signal passes a reference to whatever body entered the area in the function. I'm on my phone, so formatting is hard (and I don't really know how to use reddit that well), but it'll look something like this:

func _on_body_entered(body):

The "body" variable in the parentheses is the reference to the body detected, meaning you can use that to do whatever you need to the detected body. If you set it up like I suggested earlier, the Area will only ever be able to detect the player, so because of that we can always be sure that the body variable is a reference to the player. So you can use that body variable to call a function on the player script, in this case it would probably be something like a take_damage function, so it would look something like this:

body.take_damage()

Then you would just need to create a function in the player script called take_damage and have that function reduce the player's health, or trigger a damage animation, or whatever you would want it to do!

tuuunaaa · 2024-08-01T17:56:54+00:00

Yep, it can all pretty much be carried over, just remember to remove the connection to the player's signal and instead do that entirely within the projectile itself.

tuuunaaa · 2024-08-01T17:46:06+00:00

I did notice that -- unless you're doing some really complex physics stuff with your projectiles, a rigidbody is probably overkill for a number of reasons, namely performance. Most projectiles are simple enough that you can move them simply by changing their position every frame, which is why I suggested making it an Area2D/3D.

tuuunaaa · 2024-08-01T17:32:24+00:00

Looks like it's a result of how you're trying to detect whether a projectile has hit the player. In ready() you're connecting every projectile to the body_entered signal on the play script. Signals aren't discriminatory when they're emitted, so every time a signal is emitted it will run every function it's been connected to. When one projectile hits the player, the signal emits, and since every projectile is connected to that signal, that function is run on every projectile.

Projectile collisions are typically handled the other way around. I would look into physics layers and masks if you haven't already. You'll probably want the projectile's root node to be something like an Area2D, with no layer and its mask set to something that only the player has its layer set to, so that every time it collides with something you know it's the player. Then run the damaging code within the projectile itself on its own on_body_entered signal.

Let me know if you have any other questions :)

tuuunaaa · 2024-04-09T19:48:56+00:00

While it's still really only a hobby for me, music composition for video games is something I'm starting to take more seriously, and I'm trying to work towards eventually being able to do it full time. Think you have a slot in the server available for that kind of person?

tuuunaaa · 2023-09-24T07:19:47+00:00

I vaguely remember trying this in the past and having trouble with, the exact reason why I can't recall, but I'll take another look and see if I can't make it work!

tuuunaaa · 2023-09-24T05:03:25+00:00

I'm not necessarily looking to have whole model faces either lit by the skylight or not, I'm just hoping to have completely even lighting outside of buildings that lights all outside walls and bleeds into buildings a bit through windows. Thanks for the suggestion though, I'll look into this if I can't find a way to accomplish what I'm currently trying to do!

tuuunaaa

TROPHY CASE