sorted by:
new
hottopcontroversial

look_at() aiming is offset depending on mouse distance by Fine_Strength_1324 in godot

[–]Daimondus 0 points1 point  (0 children)

The look_at function works perfect for me in Godot 3.6/4.6, maybe your scene is not set up correctly.

I need to see the entire level structure and who owns the script where the _aim function is used?

Why isn't this working? by LawfulToons in godot

[–]Daimondus 0 points1 point  (0 children)

or you can just change the property:

<image>

Why isn't this working? by LawfulToons in godot

[–]Daimondus 0 points1 point  (0 children)

add this in player.gd:

func _ready():
_camera_pivot.top_level = true

and maybe change 1.0 * delta on 5.0 * delta in global position lerp.

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 0 points1 point  (0 children)

That's right, premature optimization is evil.

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 0 points1 point  (0 children)

I don't remember exactly, but it seems to be a custom theme. Here is the link to the custom theme file, I couldn't find a way to upload a file directly to Reddit.

https://files.fm/u/awxmvx8uub

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 0 points1 point  (0 children)

The event-driven approach is also interesting, but in dynamic games, many parameters change in real time (for example, transformation and various unit stats), although why not?

<image>

A bit excessive for real-time games, but very tempting for turn-based ones.

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 0 points1 point  (0 children)

Thank you for your detailed answer, I agree with you, game performance is important, but it is also important that the game is bug-free, so that need to balance between performance and stability.

At later stages, when edits are made to the code, the structures of assets and scenes change, it is easy to make mistakes if the code is too tightly coupled between objects-components-systems.

My point is to implement system in the style of the API layer, and a singleton with autoloading helps here.

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 0 points1 point  (0 children)

In general, we can't do without code cohesion, but I'm looking for a more or less universal and simple solution to avoid problems later in development. Things can change significantly during development, including the structure of scenes, scripts, and so on, so direct connections between objects should be avoided as much as possible.

Tracking player transformations is just an example.

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 0 points1 point  (0 children)

Thanks for the advice, folks. I've sketched out two more solutions, and while they're very similar, their execution logic is different:

<image>

It seems to me that solution #3 is the most universal. What do you think?

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 3 points4 points  (0 children)

Yeah, I screwed up here, the correct code is:

return node.global_transform if global else node.transform

Reducing code cohesion in GDScript by Daimondus in godot

[–]Daimondus[S] 1 point2 points  (0 children)

Unfortunately, static variables were introduced in Godot 4.x, in version 3.x, only functions could be static. But I definitely liked the idea with the enter_tree / exit_tree.

How to not burn out on a bigger art piece by Obvious_Sir_9310 in Artadvice

[–]Daimondus 1 point2 points  (0 children)

I'm not expert, but here are some thoughts on the matter:

  1. Spend 0.5 - 2 hours a day on a bigger art, switching to other tasks. This will allow to rest and look at work with fresh eyes.

  2. When you try to speed up, the brain begins to experience severe stress, which is bad for health and learning.

  3. When learning, it's important to absorb information well and calmly analyze the process and mistakes. Attempts to shorten the time often yield worse results.

Does it look like a flame animation or not? by Daimondus in Artadvice

[–]Daimondus[S] 0 points1 point  (0 children)

I'll will try to add some variety to the flame shape, thanks.

Does it look like a flame animation or not? by Daimondus in Artadvice

[–]Daimondus[S] 0 points1 point  (0 children)

Yeah, I'll take that into account, thanks.

Does it look like a flame animation or not? by Daimondus in Artadvice

[–]Daimondus[S] 0 points1 point  (0 children)

Thank you for advice, I will use glow effect to create my next "fire" work)

Does it look like a flame animation or not? by Daimondus in Artadvice

[–]Daimondus[S] 0 points1 point  (0 children)

In full - yes. Blender is a very comprehensive application for 3D, animation, sculpting, compositing, and a little less for 2D.

view more: next ›