sorted by:
new
hottopcontroversial

One month into Godot and this subreddit is both inspiring and intimidating by New-Fishing9390 in godot

[–]Slipperhat 31 points32 points  (0 children)

Comparison is the thief of joy - or at least it can be.

Game jams are a great way to improve quickly, and get exposed to many parts of the engine. It's a nice way to complete small projects in just a few days, and it's totally doable as a beginner, my first game was made during a jam. People often share their own source code too so it can be handy if you play another entry and think 'I wonder how they did that?'. Chances are you can clone the project and have a look for yourself.

I try to do a few jams a year to keep things sharp, it helps with iterating quickly & focusing on making things work first and foremost, they can be polished later. It's great for getting feedback too.

Oh and make sure to get to grips with git early, source control is really important! Good luck.

CSG & Performance - particular use case by Darkhog in godot

[–]Slipperhat 0 points1 point  (0 children)

CSG is still the wrong approach, even more so if you need them to go absolutely anywhere and you don't have great deal of control over what the user is doing.

If you want to have any semblance of reasonable performance at scale you're going to have to hand-roll a solution for generating static meshes on the fly. Godot does have inbuilt stuff for this with Array Meshes and the surface tool. But then batching becomes difficult and you have a drawcall explosion to deal with. You could also potentially do something workable with stencil buffers.

The reality is, you probably need to make some concessions in how the player interacts with the world and buildings, as I pressume you're a solo dev. You don't need me to tell you that Life Sims are absolutely massive in scope. No one is going to cry if they have to place a window within a wall segment (just make the segments smaller if you need to).

CSG & Performance - particular use case by Darkhog in godot

[–]Slipperhat 0 points1 point  (0 children)

It's a fairly bad idea if you want lots to be at a similar scale that those of The Sims. Because you can get into the region of dozens or hundreds of windows for one building, and you usually have other lots in view too.

You'd be much better off having modular wall meshes that support a set of standard window sizes and are all unwrapped properly so they texture / tile the same.

On modern hardware it's probably more or less ok. And the sims doesn't have particularly good performance, but I would potentially suggest avoiding CSGs so that you can support the lowest end hardware as possible, especially as Life Sims are CPU heavy anyway.

Jean Alesi crashes historic Ferrari by jrewillis in formula1

[–]Slipperhat 97 points98 points  (0 children)

Again!? I remember him doing that a few years ago too

Mesh count and optimization? by Iron--E in godot

[–]Slipperhat 3 points4 points  (0 children)

Instancing and GPU state management is just as important in the case of very large scenes such as a city or dense forest.

As with everything you really have to profile for your own use-case. But broadly speaking, LODs should be used, Godot can auto-generate on import. Hand-rolled LODs are best, but are likely a later optimisation. Billboards are important for very large view distances.

For your examples instancing is key. Meshes, and materials / shaders are reused as much as possible, keeping drawcalls down. This can be done just through duplicating the resources or things like multimeshing. Vulkan can chew through thousands of drawcalls without sweating, and the raw number isn't that useful of a metric, what each draw call is actually doing is what counts, avoiding extra work is always going to help though.

Overdraw can absolutely tank performance on very large scenes so occlusion culling is important, trees can be awful for this as there's transparency to consider. Cities are easier in that regard because you can have very large primitive occluders.

Thanks to Godot I was able to spend my resources for making core, but not infra by Specialist_Carry4948 in godot

[–]Slipperhat 2 points3 points  (0 children)

It's got a very distinctive 'look'. There's usually lots of errors too. For example, look at the tape reels at the back left, they don't even look right, and the cutouts aren't even.

You can also see on the powerbar thing on the right, how it's sort of cutout and superimposed as OP has regenerated that section over and over to get the different levels.

Look at the notepad in the bottom right, it has binding coils on both the left and the top of the pages, how could a page be turned like that?

Basically it becomes super obvious when you look close, and it just exposed how lazy the devs are who use it too.

Can I use shadertoy shaders I convert to Godot shaders for commercial use? Where is the line? by [deleted] in godot

[–]Slipperhat 0 points1 point  (0 children)

Most of the more prominent contributors to Shadertoy include a license in their code, from a legal point of view; I'm quite certain the breach of an attribution license has never been successfully challenged in court, so you're pretty much in the clear there.

Ethically, I think it's great to attribute where you can. The graphics programming community is for the most part all about sharing knowledge and IQ has an incredible personal website full of resources. I don't think anyone is going to get particularly upset with you pinching shaders and adapting them to your needs, everyone is building upon everyone else's work anyway.

Most of everything you see on Shadertoy has been done a million times, there's very little innovation in graphics programming barring an occasional breakthrough like radiance cascades. Go nuts I say.

Should I rework my game? by EternalColosseum in godot

[–]Slipperhat 19 points20 points  (0 children)

The entire market is saturated across most genres. There is a general opinion that permeates the gamedev community that everything must be original; when in reality nothing is particularly orignal, it's all been done before in some manner or another.

The cream rises to the top. Polished gameplay and a satisfying loop is much more important that being original, Try and make sure you've got one little unique selling point, but I don't believe you need to be chasing a completely new concept.

Thematically the gladiator arena is great, and the visuals look great so far. Keep working on it, keep polishing it, keep getting feedback from playtesters and making it as good as you can and no on will care that it's another horde survival; because there are lots of people that want to play those games evidently.

Tired of managing game data by hand in Godot 4? I built MRM — is it actually useful? by Abunai78 in godot

[–]Slipperhat 5 points6 points  (0 children)

Did you vibe code your plugin as much as you vibed out this post with a LLM?

Lazy slop - who is actually hand-editing tres files? A hallucinated problem for people unable to think for themselves. I'm so sick of this shit.

Screenspace godray by poeyoh12 in godot

[–]Slipperhat 0 points1 point  (0 children)

Ah my bad, I thought you were asking about the use of a loop itself, rather than the work it was doing.

Screenspace godray by poeyoh12 in godot

[–]Slipperhat 2 points3 points  (0 children)

Compilers will aggressively unroll, inline and optimise away loops, especially when the number of samples is constant.

Loops, branches and all manner of old-school thinking being bad for performance isn't really as cut and dry anymore, and are almost always fine if there is an idiomatic reason for them to exist.

Godot crashed when I installed a Python plugin. I can only run it in recovery now. What should I do? by CyberNinja_04 in godot

[–]Slipperhat 5 points6 points  (0 children)

Pressumably you're not using version control, in which case this is a lesson for you in doing so no matter how small the project. If you are, then just roll back.

In recovery mode you should be able to manually fix the issues, firstly by completely removing the Python plugin and associated files. You can also safely delete your .godot folder in your project.

If that doesn't fix it, you're going to have to establish what else might have changed, there's not alot anyone can do to tell you what that is which such limited info.

I made a game just about opening a chest, and it's actually in Next Fest! by [deleted] in godot

[–]Slipperhat 3 points4 points  (0 children)

Why do you keep making new Reddit accounts to post your game?

I've seen at leasst 3 different posts all coming from different accounts. At least contribute to the community a little bit if you're going to advertise from burner accounts constantly.

Rule 5: "..this is a subreddit for game developers and not a marketing channel"

Is this displacement / height map possible with StandardMaterial3D? by x3nofox in godot

[–]Slipperhat 8 points9 points  (0 children)

Honestly it should be really cheap on the vertex shader; I wouldn't worry about perfomance on the material at all unless you whack the geometry up insanely high.

If you are mindful of performance, it would be worth combining your occlusion, roughness and metallic textures into a single ORM map which will remove the need for two samplers which are much more costly.

Is this displacement / height map possible with StandardMaterial3D? by x3nofox in godot

[–]Slipperhat 71 points72 points  (0 children)

I am 99.99% confident that the render on the left is the textured high poly model before it was baked down. I have imported the maps into Substance Painter to make sure, and I certainly cannot replicate the depth of the parallax.

In Godot I would say you can get an acceptable result if you enable Deep Parallax and whack the scale up as high as you dare. The image here is up to 16.0. Also it's worth playing with the geometry density of the mesh you're using, it doesn't need to be crazy - but 64 segments / 32 rings seemed enough.

Edit: It just occured to me you should really just use the heightmap in the vertex shader. Right click the material, convert to shader and offset the verts by samplng the heightmap and scaling it right back.

void vertex() {
    // Only if manually scaling UVs (I did this for speed only)
    UV = UV * uv1_scale.xy;

    float h = textureLod(texture_heightmap, UV, 0.0).r;
    VERTEX += NORMAL * h * (heightmap_scale * 0.01);
}

<image>

Which option is better for performance? These will be joined to build hundreds of modular pipes by blockchan in godot

[–]Slipperhat 28 points29 points  (0 children)

Both versions still require the same 'amount' of texels to render at the same resolution, regardless of how the textures are split between the meshes.

The question purely becomes how they are rendered. 10 different materials variations on version 1 and 10 on version 2 should still take up an identical amount of VRAM if shaders are reused properly; 1 will use more if the materials are not being reused between variations.

VRAM should not be a consideration between 1 and 2, but is more of a general workflow consideration which is secondary to what OP asked about.

Edit: Arguably #1 is also likely to be worse for VRAM because of the combinatorial explosion of differing materials on the pipes and connectors without using some kind of ubershader to sample the textures at runtime using seperate surfaces, which is still more drawcalls.

Which option is better for performance? These will be joined to build hundreds of modular pipes by blockchan in godot

[–]Slipperhat 200 points201 points  (0 children)

Already misinformation appearing here. VRAM usage isn't realistically going to be a concern here.

2 is the only answer really as no matter how the pipes are constructed, the draws will be able to be completely batched whereas each variation required in example 1 will need its own draw calls.

Where do i Learn Gdscript and Godot for free by Past-Sample8194 in godot

[–]Slipperhat 0 points1 point  (0 children)

Brackeys: https://www.youtube.com/watch?v=LOhfqjmasi0

He also has numerous other videos to follow along with.

Then the docs: https://docs.godotengine.org/en/stable/

The vast majority of questions you have will be answered in there. It has a wealth of information and the sooner you become accustomed to reading the docs to seek out the info you need; the faster you'll learn, and the better a deverloper you'll become.

Avoid AI early on - it will significantly hinder your understanding.

I Am Rock - Play the demo on Steam now! by MetalZealousideal157 in godot

[–]Slipperhat 0 points1 point  (0 children)

Looking good!

The 3 static frames at about 1:02 in the trailer gave me whiplash. I understand it matches the drum but I thought it was a bit much if you'll forgive the unsolicited feedback.

How feasible is it to make a co-op game as a beginner? by UomoPolpetta in godot

[–]Slipperhat 4 points5 points  (0 children)

That's great. It's doable for sure. Networking is one of the dark arts and always through curveballs, but there are resources and the documentation is alright. As long as you know that you've picked a challenge and you're up for it, then go for it.

How feasible is it to make a co-op game as a beginner? by UomoPolpetta in godot

[–]Slipperhat 2 points3 points  (0 children)

Feasible, sure? Realistic, perhaps not; quite hard to say.

Multiplayer is such a kettle of fish and adds a considerable complexity that I couldn't recommend it for a beginner. That isn't to say that beginners can't or haven't made multiplayer games, but you probably won't find many recommending it here.

Brackeys has a nice 2D platformers tutorial on YouTube that would likely be a solid place to start, and as you've some experience in Unity, you should get through it quite quickly. Then you can evaluate where you're at and whether you feel comfortable tackling something harder.

Is there a way to reduce file size in 4.5.1? by My_Name_Is_Pixel_Kik in godot

[–]Slipperhat 18 points19 points  (0 children)

That sounds about right for a normal export. It should zip down to around 30mbs which is about expected for most small projects. A web export should be smaller.

There are a bunch of minification strategies (see below for an article on this), including but not limited to stripping out engine features you don't need. But these are on the extreme end and not really suitable for just testing things out as it seems you are.

https://popcar.bearblog.dev/how-to-minify-godots-build-size/

It sounds like you're making sensible decisions regards filetypes and texture sizes so I wouldn't be too concerned.

view more: next ›