Hi everyone! In this video, I won't be showcasing any shader. Instead, I'll show you a trick for easily generating 2D sprites from 3D models in Godot Engine 4.4 or higher.

so I have the RB2D collision layer just for collisions, and I have a area2d collision layer for detecting contact between cloned nodes, but it doesnt detect the two earth nodes touching unless I set the area2D collision mask to layer 1 and I'm not sure why.

I just came across this great GDscript reference page and thought it might be handy for other beginners here. Cheers!

Hello everybody!

I have recently started to make small game jam project with friends using Godot. I previously had some experiences with it, but only on solo dev project. I really like it. I recommended it, and we used it on several project with git the following way: we split our project in a lot of small scene to avoid conflict, and everybody works on their branch. We communicate to be sure nobody is working on the same scene.

Now we face problems that could mean the end of our godot usage as a team: After some commit (I'll say the first one after a fetch), the uid of some random scene changes and will cause merge conflicts. It seems that there is no logic to it, and it leads to a lot of time lost, sometimes file corruption. The faulty commits are then extremely hard to track. Today we worked with godot 4.4 and it was even more painful. We lost a lot of our project.

I really want to continue to work with Godot, but I should say that my teammates were talking about learning other engine (and I want to be clear: the git conflict is our only issue; but we took half our coding time resolving conflict, reverting commit, cherry picking, etc. just so the master branch has something working on it)

If I have to choose between believing that our workflow sucks or that it is impossible to work with Godot in a team, I'm 99% on our skill issue. If you have any solution or advice, thank you! If you work on a team and you never had those kind of problem, that is also good to know!

Best

This was a fun one. Here's my newest post on how to dramatically reduce Godot's build size.

Some sacrifices were made... But the end result is a Godot project that works exactly the same, albeit with slightly worse performance. Hope this can help others in achieving tiny build sizes!

cross-posted from: https://lemmy.abnormalbeings.space/post/62732

GodotSteam tutorials for Godot/Steamworks SDK interfacing

Hello everybody! In this video, I would like to create an effect that transforms a scene into its pixelated version. We've seen that before, right? But this time, we won't settle for ordinary square objects—we'll tilt them a bit to create a diagonal grid with an adjustable size. Let's take a look at how such an algorithm works.

Still working away on Gopilot, my half-finished LLM-powered AI thingy for Godot.

In the example video you can see an LLM agent creating some nodes and a script to make a login screen.

This is a cherry-picked example, but I am working on improving this.

The @action command is required for it to interact with your nodes and project files and such.

The model used for this is Mistrals codestral model which has a free API. It's presumably a rather small model, coming from Mistral.

If you have any questions, ask right away

Hello, 🙂

I created a new language called FuncSug. Its purpose is to make GUI programming in the browser easier and so game programming. The facility consists on eliminating asynchronism: In FuncSug, the code is no longer managed by an implicit/explicit global loop (I don't speak about implementation).

I intend, if I have time, to implement it for Godot as well. In FuncSug, the first tutorial of Godot would be roughly coded as this:

func showMessage(p_message):
	parallel exitWith branch 2 ||
		showIn(p_message, $MessageLabel)
	||
		waitSeconds(2)

parallel ||
	while true:
		# Start of game
		parallel exitWith branch 2 ||
			showMessage('Dodge the\nCreeps')
		||
			waitSeconds(1)
			awaitPressed($StartButton)
		get_tree().call_group(&"mobs", &"queue_free")
		score := 0
		$Player.start($StartPosition.position)
		
		# Middle of game
		parallel exitWith branch 1 ||
			awaitSignal('hit')
		||
			while true:
				playSoundFile('House In a Forest Loop.ogg')
		||
			showMessage('Get Ready')
			parallel ||
				while true:
					waitSeconds(1)
					score += 1
			||
				while true:
					waitSeconds(0.5)
					callgd spawnMob()
		
		# End of game
		parallel ||
			showMessage('Game Over')
		||
			playSoundFile('gameover.wav')
||
	while true:
		await score
		$ScoreLabel.text := score

The 'player.gd' and 'mob.gd' files would be keeped as they are. The "_on_MobTimer_timeout" function would be renamed as "spawnMob" and moved to 'mob.gd'. The timers wouldn't be needed any more.

Can you tell me what you think about it?

cross-posted from: https://programming.dev/post/26509534

So I know the Godot Asset Library links back to some other source like GitHub for the actual files. It also appears that it uses the "git archive" to create the zip file, because you can update .gitattributes to ignore everything but what is in the addons directory which is handy for a plugin.

But does it have any other metrics, like number of times an Asset is downloaded or used? I'm not sure that you can tell from the GitHub analytics if it is pulling it since that table seems to show "clones" and not "archive"s? Also it probably wouldn't look like a new user.

Anyway I was just curious enough to shoot out this question into the ether.

Hi everyone! Let's create a simple algorithm that allows us to remap the colors of our scene to a predefined palette. This effect can be useful if, for example, we want to simulate the screen of an older device that only supported, say, 256 colors, and similar scenarios.

Added the swords to have something else for a change than boxes in all ratios. And, well, every Bulletheaven game needs something to collect, right?

A few seconds longer and it would take off like a choppa

Wanted to have them orbiting while maintaining center alignment, didn't fully work out ¯_(ツ)_/¯ But I do kinda like it

Hi everybody. This is the second part of the tutorial, which explains the basics of a technology called ray marching for rendering a 3D scene using a shader. In the first part, we modeled a simple scene with a sphere, a cylinder, and a cube, and this time we will demonstrate how to properly light such a scene and calculate shadows.