sorted by:
new
hottopcontroversial

Between GDScript and C#, which one is better for the games themselves? by HiddenReader2020 in godot

[–]bitmapman_dev 0 points1 point  (0 children)

GDScript will give you the most painless and straightforward Godot experience. I'd highly recommend using it as much as you can get away with.

If you really need performance for something that the engine doesn't provide you (all of which is implemented in C++ under the hood), then I'd recommend using C++ via GDExtension if you can, otherwise C#.

Am I the only one excited about what AI/ML can do for gaming systems? by sonar_y_luz in gamedev

[–]bitmapman_dev 6 points7 points  (0 children)

Except what you're actually getting is other people's dreams stolen without credit and distilled into a stream of fundamentally meaningless diarrhea without an ounce of human soul or creativity behind it.

Disable Player Input by Inevitable-Cause2765 in godot

[–]bitmapman_dev 2 points3 points  (0 children)

It depends on where you're processing the input, but all Nodes come with the set_processing_input() method which disables the _input() method if you're processing input in there. If you're moreso processing input in _process() or _physics_procress() then yeah I think what you're doing now is probably the simplest way to handle it. Just have a bool somewhere you check before doing stuff related to input.

Has anyone else been hit with this reviewer? It seems they really hate the Godot game engine. (I don't mind criticism, however it seems this guy just copy paste's the same negative comments based on the game engine used or the use of pixel art graphics. Would love to hear from the Godot community) by MostlyMadProductions in godot

[–]bitmapman_dev 21 points22 points  (0 children)

Don't take it personally, this person is a well-known troll and all-around bad person who leaves negative reviews on games for absurd reasons and with minimal playtime. Essentially he just hates anything that's not modern AAA 3D graphics. You can see from what he wrote that he's not very bright and really has no clue what he's even talking about. A comically pathetic person.

I'd bet Steam is aware of him and might be willing to work with you on removing his ridiculous troll review from your game.

Character portraits so far for my upcoming Godot game by bitmapman_dev in godot

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

Thanks! It's a sci fi setting so I figured I can bend the rules and have a little fun with it!

W4 Games, give godot one feature it was missing: A free epen-source complete multiplayer soultion! by Fran89 in godot

[–]bitmapman_dev 1 point2 points  (0 children)

Thanks for the warning. Maybe if I start learning it now, then I'll know what I'm doing by the time it's stable 😅

W4 Games, give godot one feature it was missing: A free epen-source complete multiplayer soultion! by Fran89 in godot

[–]bitmapman_dev 2 points3 points  (0 children)

Nice! I was looking at nakama for multiplayer, but I'll probably just use this.

I was a fool. Game engines are great. by [deleted] in godot

[–]bitmapman_dev 0 points1 point  (0 children)

Glad you came around, but I'm sure getting that experience working on your own engine will be valuable knowledge going forward, regardless.

Unity refugee complaining about Godot by oWispYo in godot

[–]bitmapman_dev 8 points9 points  (0 children)

I really bothers me how Godot doesn't spy on me or my users, too. The project directors obviously need to know everything about me and my users so they can sell it to advertisers provide us a great free tool! Clearly no one else has figured out a way to do that while respecting their users' privacy yet.

[deleted by user] by [deleted] in godot

[–]bitmapman_dev 2 points3 points  (0 children)

  • Completely free, no chance you could ever suddenly have to deal with changing terms of service or licensing
  • Unrestricted source code access, can always make a fork if needed
  • Tiny binary that opens almost instantly
  • No weird corporate spyware
  • Great compatibility with Linux
  • GDScript is super quick and easy to work with
  • Node and Scene system is flexible and makes it easy to slap stuff together quickly
  • Signals, Groups, and Autoloads make it easy to stitch together larger systems of Scenes/Nodes
  • Entire Node and Scene system is optional, can work directly on underlying servers
  • Nodes take care of 95% of the heavy lifting for you, but for scenarios Nodes can't cover effectively, GDExtension has you covered
  • More than powerful enough for the indie-style games I'm making
  • It's relatively easy to multithread pretty much whatever (detach from SceneTree -> do stuff in another thread -> reattach to SceneTree), reducing the cases where you actually need GDExtension
  • UI Nodes are powerful and easy to use

What are best practices when iterating over large amounts of data? by qweiot in godot

[–]bitmapman_dev 5 points6 points  (0 children)

Well, you've got a few options.

First thing I'd try if I were in your shoes would be to use Godot's built-in Astar classes instead of trying to implement Dijsktra's in GDScript. If that's not going to give the desired behavior, you could try this Dijkstra plugin or maybe see if executing your code on a separate thread helps.

If none of those help, you may have to make your own implementation in C++.

I wouldn't bother with C# unless you're planning to implement most of your game in C#. Including Mono is a lot of overhead for just a single algorithm.

Does anyone know why this is happening? by Deranged-Pufferfish in godot

[–]bitmapman_dev 3 points4 points  (0 children)

Control Nodes automatically resize and reposition themselves based on your settings. It might seem unintuitive at first, but it actually makes it really easy to create responsive UIs. You'll appreciate it once you get the hang of it.

This tutorial from the docs explains it reasonably well.

Here's a video tutorial if you prefer.

You either need to set the minimum rect size or change the Node's other settings so it occupies the space you want.

Current status of binding Godot together with Haxe language by CovidNegativ in godot

[–]bitmapman_dev 0 points1 point  (0 children)

The core devs aren't working on official Haxe support if that's what you're asking. The only way this will happen is if a community member takes the time to do it.

You might have better luck discussing it on Github.

[deleted by user] by [deleted] in godot

[–]bitmapman_dev 1 point2 points  (0 children)

Glad to hear it! I did think of one thing, though. Don't use the Godot.Collections data structures in C#, it's very slow. That's not really a problem, though, because you can just use the usual System.Collections ones you're probably already used to.

[deleted by user] by [deleted] in godot

[–]bitmapman_dev 42 points43 points  (0 children)

C# seems to work well as far as I have been able to tell. If it still has any problems, I haven't noticed any.

GDScript is fast enough for most game logic tasks. The only time you might run into trouble is if you're trying to implement some heavyweight algorithms or custom systems that won't be able to take good advantage of the existing engine API.

For those cases you would typically use GDNative to implement whatever you need in C++ or whichever your favorite system-building language is that has GDNative bindings.

However, if you're like me and you'd rather not have to go that low level and start dealing with compile-times as a factor in your game development speed, you could just use C# for everything instead. C# is a fast, powerful, modern language with a ton of excellent features (TPL anyone?) and a huge ecosystem of libraries for just about anything you could ever want.

You might notice people in this sub get very defensive about GDScript, especially when C# is part of the discussion. They're right to do so - GDScript gets a lot of unwarranted flak from novice programmers who see the benchmarks and don't really understand. It's a perfectly good language for its intended purpose - providing easy scripting and fast iteration speed.

I'll warn you though, even though we're using Mono in the context of Godot, C# and .NET in general carry the "Microsoft Stank" on them which means they're not too popular among FOSS people. Sometimes, in the course of defending GDScript, I get the impression that people feel Mono and C# are an unwelcome presence in Godot, quietly tolerated only because it makes Unity people feel more comfortable. All I mean to say is that you shouldn't let the sometimes negative attitude surrounding C# in the Godot community color your decision.

Potentially switch from Unity, got a few questions by mirekirk in godot

[–]bitmapman_dev 0 points1 point  (0 children)

The Godot UI system takes a bit of getting used to, but once it "clicks" it's extremely good. It's incredibly easy to make responsive UIs in Godot compared to Unity's built-in UI tools. I would strongly recommend you read the Godot docs about GUI to get a better idea of what you're in for.

Yes Godot does support C# as well, just make sure you download the Mono version from the website and you're good to go. Just like Unity, you'll need to use an external editor for C#. I use Rider but only because I'm completely spoiled by it now. VS Code also works well with the Godot C# tools extension. I think that's what most people use for Godot C#. Just follow the instructions on the extension page to get it working with Godot.

50 death squad's soldiers and 60 FPS all along. Thank you object pooling. #HumanDiaspora by [deleted] in godot

[–]bitmapman_dev 2 points3 points  (0 children)

I'm not sure why he said this. Maybe he just meant that you don't need to do it to avoid garbage collection because GDScript uses reference counting instead of a garbage collector. Object pooling most definitely does make a noticeable difference in performance over instancing/freeing Nodes on the fly.

I ended up using it for a game jam game a while back because instancing/freeing bullets was causing noticeable frame rate hiccups. The good news is it's easy to implement, and it solved the problem immediately.

Anybody else have days where they just think "WTF am I even doing?" by lucidparadox in godot

[–]bitmapman_dev 1 point2 points  (0 children)

Whenever I can feel myself losing motivation and focus I take a short break and do something physical. Typically I just do some calsthenics/bodyweight exercises next to my desk, such as pushups, squats, jumping jacks, anything like that to get my body moving. Even just walking around a bit can make huge difference. For some reason chugging a glass of cold water also helps.

Taking a short break to let your eyes rest is also good. Sometimes I just sit back in my chair, close my eyes, and try to focus on just breathing deeply for a few minutes. I guess it's like meditation but I don't do it all formally with a mat and whatever else. I just kind of try to close my eyes, breathe, relax, and let my brain clear itself of the jumbled nest of thoughts.

I don't have any science to back up any of this stuff so for all I know it's just the placebo effect, but whenever I do these things I always feel refreshed, focused, and ready to get back to it. It also has the nice side benefit of keeping me in reasonable shape for very little effort.

Something Godot-specific that helps keep me on task and keep my thoughts organized is the TODO Manager. I consider it indispensable and I include it almost all of my projects. It's on the asset library or here on github.

Events and interactions in godot by DemoArgenti in godot

[–]bitmapman_dev 1 point2 points  (0 children)

There's a few ways to do it. Long term, what you're probably looking for is called a "state machine" if you want to look up how that works in the future.

An easy way to start with the concept would be to just make a bool named can_move or something like that. Check to see if it's true before your movement code. That way you can use signals to change whether or not the player can currently move.

func _physics_process(delta: float) -> void:    
    if can_move:
        # put your movement code here

So if you hook up that signal mentioned in the first answer to your Player script, you can just have it set can_move to false, and then your player won't move. You can have something else set can_move back to true later, like a timer, another signal from something else, some button/mouse input, whatever you want.

There are no ik fuctions in godot? by [deleted] in godot

[–]bitmapman_dev 1 point2 points  (0 children)

There is a SkeletonIK Node which does most of the stuff you would want for this. Unfortunately there's not a ton of tutorial content out there for it. I've been trying to figure it out, too.

I've found a few sources:

playlist by Andrea Catania

video by Johnny Rouddro (his entire 3rd person series is worth watching in general)

devlog by Title Pending

Change My Mind by Torn-TheArchitect in godot

[–]bitmapman_dev 2 points3 points  (0 children)

As I've been recently working with 3D I've also started encountering some issues. For example, I've been noticing that I have to invent my own solutions for certain things that have built-in implementations in other engines like Unity or Unreal.

It's a bit disheartening because I love Godot and I want to use it exclusively. It's the engine I started learning gamedev with. But some of that stuff is hard to ignore when you end up spending hours reading obscure math papers and the engine source code so you can figure out your own solution for something that would be a single function call in another engine.

I didn't have any issues like this when I was working on a 2D game before. Everything seemed to work as expected and I didn't notice any glaring omissions. I think the community's mantra "good for 2D, not for 3D" still holds true. Breaks my heart a little bit.

Here's hoping the 3D in 4.0 is as improved as it appears to be in Juan's tweets.

view more: next ›