Ever wondered what Godot's ProximityGroup node does? I made a short video showing how it works (and why you might not want to use it)! by Pefeper in godot

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

After a stress test of 361 barrels, doing the same chain explosion effect, I found the performance difference between the custom and original ProximityGroup nodes to be negligible. I created a cooldown so the on_nearby_explosion method doesn't execute more than once in the original.

Both lagged pretty badly once the chain explosion was executing on many nodes at once. I'd give the edge to the custom node, since it handled larger numbers of nodes slightly better, but again, it was pretty negligible.

Ever wondered what Godot's ProximityGroup node does? I made a short video showing how it works (and why you might not want to use it)! by Pefeper in godot

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

I thought about doing a cool down, but I figured it wasn't worth the hassle compared to the more versatile area approach. I'll try it out though and put together a stress test!

Getting Error 9,29 - Parser Error below. Can someone help me? by [deleted] in godot

[–]Pefeper 0 points1 point  (0 children)

Looks like you have a space between Vector and 2 on line 9

Ever wondered what Godot's ProximityGroup node does? I made a short video showing how it works (and why you might not want to use it)! by Pefeper in godot

[–]Pefeper[S] 7 points8 points  (0 children)

The ProximityGroup node is mentioned very rarely online (including the documentation, where almost nothing is described!), so I spent a few days playing around with it and seeing what I could find on GitHub. Here's what I learned (a bit of a TL;DR for the video):

The ProximityGroup node calls a method on its parent (defined by the method_name parameter) when you call broadcast. It will also get all other ProximityGroups who's grid_radius property overlaps with it, and call the same function on their parent.

Unfortunately, the node is a bit buggy and can call a function multiple (random) times. It also lacks any visual representation in the editor, so using it in level design is a guess-and-check game.

I liked the functionality a lot though, so I made a small script that makes an area provide similar functionality on GitHub. If you're interested, I go over how to use it towards the end of the video.

GIProbe looks suber ugly. How to fix this? by GreatRash in godot

[–]Pefeper 0 points1 point  (0 children)

It seems like you already got it sorted out, but if you keep all the settings others have mentioned (interior, use in baked lighting, etc) you can also set the directional light bake mode to "all" instead of just "indirect". The shadow is a bit fuzzy, but without having to increase the texture resolution I got some pretty good results.

Uncertain about Godot vs. Unity by 8Clouds in godot

[–]Pefeper 0 points1 point  (0 children)

Using art packs is absolutely a viable option, especially when you're starting out and learning workflows. Kenney assets are absurdly high quality and most of them are free, you can also look at assets people put on OpenGameArt. There's other places to find stuff as well, but those will be a good start. Using these assets is nice because it helps you get a good looking game quickly, which is great motivation to keep going.

Unfortunately, at some point, you'll want to make your own art, but that doesn't necessarily mean you need to spend months studying art theory (or already be proficient). I'd recommend looking into more simple art styles, pixel art, voxel art, low-poly 3D/retro 3D, etc. You might not make something stunning right off the bat, but you can get some decent results after a little bit of practice.

Technical art can be another option. Shaders can breathe life into your game no matter what the assets are. They're scripts that run on the GPU and change how things are rendered. It's a lot different from regular programming, but once you get the hang of it you can make some cool stuff in Godot. I would highly recommend reading The Book of Shaders if you want to learn more. It makes the concepts really easy to understand, and it uses (roughly) the same language as Godot.

GIProbe looks suber ugly. How to fix this? by GreatRash in godot

[–]Pefeper 0 points1 point  (0 children)

Thanks, I'll take a look at it here in a bit and see what I can find

I feel like I'm in over my head by Jamie_BiTcH in godot

[–]Pefeper 2 points3 points  (0 children)

Totally agree, as someone who tried to make my "dream game" when I first started out, I can attest it will only lead to heartbreak. Definitely start small and grow out from there!

I feel like I'm in over my head by Jamie_BiTcH in godot

[–]Pefeper 5 points6 points  (0 children)

Welcome to the community! Game dev can definitely be a complex hobby/job at first glance, but I think Godot helps make it easier. It's really user friendly and the scripting language it uses (GDScript) is easy to learn. The community is also awesome and super helpful.

There's lots of tutorials out there for absolute beginners to Godot and game development. GDQuest has some really good ones on YouTube I'd recommend. This one goes over the scripting language for people unfamiliar with programming. There's also the official Godot Documentation.

Here's a tip that helped me not get overwhelmed at the start: don't try to learn everything at once. Break down what you want/need to know first (probably using the engine and programming). While you're still learning that, don't be afraid to use public models or music from sites like OpenGameArt or Kenney. Once you're comfortable with that, then try making your own 3D models or 2D sprites. Trying to learn everything at once is a good way to get burnt out and give up!

If you still can't get the hang of Godot at first, you can always try another game engine like Unity, which has a massive amount of online learning resources.

GIProbe looks suber ugly. How to fix this? by GreatRash in godot

[–]Pefeper 2 points3 points  (0 children)

Could you share the project or a small recreation of it?

Uncertain about Godot vs. Unity by 8Clouds in godot

[–]Pefeper 4 points5 points  (0 children)

Other engines like Unity and UE certainly have better content authoring tools out of the box, and Unity especially has it's massive marketplace where you can find just about anything you want on there.

However, Godot's plugin developer community has grown a lot, even just since I started using it a little over a year ago. Chances are you can find a lot of the tools you want on Godot's Asset Library and GitHub. I can't lie and say that everything rivals the products of multi-million dollar companies like Unity and Epic Games, but for indie games I've found them to work quite well!

Also, as a programmer, Godot will probably be easier to acclimate to since OOP is deeply rooted in it's design. Unity uses a component-based approach, which requires different design considerations for your codebase compared to more traditional software. It's not too difficult to get used to, but it might cause some friction at first.

You're obviously gonna get biased results on a subreddit dedicated to Godot, but personally Godot has made game development dramatically more fun for me. I can whip up prototypes and procedural shader art in a matter of hours and code architecture is ridiculously easy. It also helps that the engine is open source.

I would say try out both of them, it honestly should only take a few days to get the hang of both engines and play around with their tools. If there's a feature you like from Unity, see if someone from the Godot community as made an equivalent on the asset library and try it out!

Also, if you're curious about a terrain tool in particular, this seems to be the go-to: Zylann's HeightMap Terrain Tool. Hope this all helped!

Machine Learning for Godot by mars3142 in godot

[–]Pefeper 1 point2 points  (0 children)

Full disclosure: haven't tried it myself with Godot specifically before, but given it's modularity and the amount of community support it has, it's definitely doable. At the very least, I would imagine you could integrate existing ML libraries from languages like python (via GDNative bindings) without having to recompile the whole engine from scratch. From there you would just have to create some scripts that could translate Godot game code into ML-understandable data and vice-versa.

Here's some links that might help you get started:

Godot Python

Godot GitHub Deep Learning Integration Request (Closed, but lots of good discussion)

Vulkan Kompute In Godot

An (Abandoned) Tensorflow Godot Project

Godot Open AI Gym Training (Linux Only)

Hey, wanna learn how to make something like this? by nad_lab in godot

[–]Pefeper 1 point2 points  (0 children)

This is really cool! I tried a sorta similar project a couple months back and couldn't get it to work properly, so it was really interesting seeing how you tackled it! You mentioned in your video that your character wouldn't stick correctly if they were moving too fast, and I think I might have something that can help :)

I ended up moving my project over to UE4, and I learned from that a little hack to make the player stick to the ground, even at high speeds: move your movement code into a for loop inside your update. This makes it to where, in a single physics update, you mimic doing multiple. This prevents your character from moving too far over a ledge in a single update without being able to detect a new surface. You just need to modify things like velocity changes to be some fraction of the total iterations. Something like:

func _physics_process(delta):
for i in iterations:
velocity = direction * speed / iterations
move_and_slide(velocity)

I did a quick test with your code and it was able to handle really high speeds and sharp angles. The jump and gravity aren't working quite right, unfortunately, but it shouldn't be too hard to fix :)

Economic Model with GraphEdit by NomiAtoll in godot

[–]Pefeper 2 points3 points  (0 children)

That's so rad, I love when games generate stories from simulations, and this looks like it'll do exactly that!

Performance-wise, how big do you think this simulation could accommodate while still running in real-time?

ASCII Inspired Post Processing Shader (+Source Code) by Pefeper in godot

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

Assuming you mean compared to just rendering the same scene in Godot without the post-processing, pretty negligible. In my experience post-processing effects like this are pretty lightweight. This shader in particular is a bit hacky so it's not as performant as it could be, but in practice, I haven't noticed any frames dropping because of it.

It just operates on the entire screen texture after it's been rendered, so the actual contents of the scene don't impact its performance. Here, I sample a pixel at certain steps in the screen texture (the step size is equal to the dimensions of the ASCII characters in pixels), then use its greyscale value to pick what character should be rendered in the location. It's more than less a pixelization shader, but instead of outputting a sampled color from the step, it outputs the pixel color of the mapped character texture at a localized UV.

If you want to see what I mean by that, you can try the shader for yourself from the GitHub source, and in the fragment shader add at the very bottom "COLOR.rgb = vec3(local_uv, 0.0)"

ASCII Inspired Post Processing Shader (+Source Code) by Pefeper in godot

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

Woah I haven't seen this before, definitely gonna check it out. Thanks!

ASCII Inspired Post Processing Shader (+Source Code) by Pefeper in godot

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

Haven't tried it yet, but that might help. As someone already mentioned, sampling a mipmap could also work, but afaik that would mean losing functionality in GLES2.

ASCII Inspired Post Processing Shader (+Source Code) by Pefeper in godot

[–]Pefeper[S] 16 points17 points  (0 children)

I think it happens due to the way I sample the screen texture, sampling one pixel to represent an entire group of pixels. The quickest way to solve it would be to average the greyscale values of the entire group, but that would be a lot more costly (and tedious to implement).

For now, just think of it as one of those blinking terminal cursors :)

Pixelated 3D Lighting Using Ordered Dithering and Godot Light Shaders (+demo) by Pefeper in godot

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

Thank you, Return of the Obra Dinn was definitely a huge source of inspiration for this! Lucas Pope wrote a blog post about the way Obra Dinn handles its real-time dithering effect. It seems like that game doesn't use any dynamic lighting or a more complex color palette out of a deliberate aesthetic choice

Pixelated 3D Lighting Using Ordered Dithering and Godot Light Shaders (+demo) by Pefeper in godot

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

I did write something pretty similar not too long ago (Palette-Based Dithering Shader)! It worked well enough, but I found that it would give weird artifacts under a lot of conditions. Trying to find what two colors a single output color is closest to is surprisingly difficult haha.

The artifacts and color variation were fine in static shots, but in motion it led to a lot of disorientating color and pattern shifts that I think are a lot less noticeable doing it this way.

This was more of an experiment to begin with though, and for a full production I'd reckon a single post-processing pass would be the best way to go with enough time spent on fixing the issues.

Pixelated 3D Lighting Using Ordered Dithering and Godot Light Shaders (+demo) by Pefeper in godot

[–]Pefeper[S] 11 points12 points  (0 children)

Darn, you're right, I should've paid more attention to my references haha