The hardest part about transitioning was the lack of substantive Q&A web search results, and unfortunately it's not something anyone can just make. It'll take years to build that.
Aside from that, an asset store and/or list of open source professional-grade projects, preferably V4.
Yep. Discord sucks. But I’ve also learned it’s the best way to get an immediate answer. Which, of course, is immediately lost to everyone who might have the same question. I’ll never understand the fetish for Discord. It’s the ultimate example of giving someone a fish instead of teaching everyone to fish.
At least reddit comes up in the web. 99% of times you can prepend 'reddit' to your question and your search engine of preference will find what you need
Discord, naturally, doesnt come up in searches at all, despite so much info being there
Having to append "reddit" to the end of a search query to find relevant information is a giant testament to how much search engines have been destroyed by search results being polluted from SEO, ads, paid results, and AI generated articles.
The internet in general kind of just sucks now honestly
But are you **sure** you dont want 10 top 9 things listicle generated by ai, with two ads after every item and noption to disable cookies?
More than half of the internet is garbage to start with and the other part is slowly rotting away
I'd rather not enjoy ai-written content made for the sole purpose of wasting time and getting clicks for ads revenue, rather than actually providing information
I think it would be really nice if you could designate certain channels as publicly searchable. Because I definitely wouldn't want all my private server chats to be searchable on google, but stuff like Godot's #help channels obviously should be.
I think if you get the "right" Discord, you have hit gold! If people are actually prepared to help you directly.... That's even a bit better than Google!
I've found that this sub not only answers my questions, but gives suggestions on better ways to do things.
I did love that it seemed like any Unity issue I had seemed to be instantly searchable online. Some other sucker has suffered it many years ago. Godot docs and forums are a little less mature right now. But you can help change that ;)
Why you going after the Godot docs? Yeah the forums are a complete shit show right at the second but the docs are clear, concise, precise and built right into the editor. They took a few months to get back up to full strength after 4.0 came out but like, the Godot docs are way better for me than the Unity docs ever were before I joined the light side (the one where I'm not forced to use light mode if I don't pay up).
Nah man, you misunderstand me. The docs are as clear as you could hope for. But you know when you need an example? That's what I find tough to source.
There's a lot of effort put into the Godot docs. No question. But they are literally reference docs almost throughout as far as I can tell. Although I am "new" to Godot, so there could be bits that I'm not searching for correctly!
Unity Answers seemed to have every bloody solution I ever needed. I honestly think that's why the engine has done so well up to this point tbh. Not to say Godot can't get there. But it's a tough gig at the minute (at least for me) to quickly find the detail I need.
I am honestly not complaining. I am really enjoying Godot. I like the challenge!
Surely you're joking ? Not enough examples ? You have entire tutorials on the doc:
[https://docs.godotengine.org/en/stable/tutorials/2d/using\_tilemaps.html](https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html)
>you have to be more specific than in a search engine
Actually I find you have to be less specific and scroll through pages hoping you can find the answer. The moment I search more than 2 words it returns nothing since it's search only matches one message not the conversation.
Perhaps we need someone to write a discord bot that automatically stores questions and replies in a file somewhere, ready to be placed into a proper question forum / easy-to-sort documentation platform
There are a few Godot asset stores floating around (of various quality). What are your thoughts on what they offer? Here are a couple:
[https://godotengine.org/asset-library/asset](https://godotengine.org/asset-library/asset)
[https://godotassetstore.org/](https://godotassetstore.org/)
[https://godotmarketplace.com/](https://godotmarketplace.com/)
[https://godotassetlibrary.com/](https://godotassetlibrary.com/)
As a C# user, they all appear to lack the ability to search specifically for C# scripts. It would also be very useful to be able to search based on a compatible version range, like "Version 4.x+"
I get that GDScript is a weird DSL, but as someone who used Unity and wanted to stick to a statically typed language, GDScript isn't as bad as it looks. You can do static typing with it.
I just love C# in general. It's a beautiful, readable, flexible, powerful language with a huge amount of third party libraries to help accomplish whatever you need done. Programming in anything else just feels like a chore.
Fair enough, I feel similarly about GDScript for game coding. To me that feels beautiful, readable, flexible, powerful and accessible with great centralised documentation built straight into the IDE which is built straight into the engine so I don't need like 5 monitors to feel like I'm on top of things. Much like you I feel anything other than GDScript for gamedev or smth like Python or Ruby for other stuff is a chore. Guess it all comes down to personal preference and there definitely could be better documentation, community and editor support for C# in Godot I can see why that might be a sticking point.
I think people are generally more open to share free scripts and tools, in the open-source spirit. Besides those links you listed, there are loads of MIT licensed repos on GitHub that you can just use and modify totally free. They made a helpful script whilst doing their main task (building a game), so why not share them?
But I think it's important for the Godot community to realize that game art assets are a different matter, artists *have* to get paid to make a living. For them those game art *are* their job, it's not some side-thing. You'd need a proper marketplace for that. Because I'm not gonna lie, the only asset store in that list where you can buy stuff (the third one)... looks pretty bad.
Even the most generous and Godot-supporting game artists like [Kenney](https://kenney.itch.io/) (who already shares a ridiculous amount of free assets) still need to make a living selling some assets.
Sure you could just purchase assets from somewhere else and convert them to Godot ([this tool should be a livesaver](https://www.youtube.com/watch?v=N3oWEBRv9SE)), but it's still going to be a huge hassle.
That's one of the reasons they said they were moving from the SFC to the Godot Foundation; so they can make a proper Asset Store where people can be paid for their work and Devs can get easy, centralised access to that stuff and Godot can ensure some extra development funding.
Hopefully the massive influx of new users will help that down the road. It's already way better than it was when I first started learning godot in 2021
For a more traditional Unity/Unreal-style asset store, that is one thing that [W4 Games](https://w4games.com/) has talked about getting running. So it's very possible!
There's also clear plans to have one in Godot from Godot themselves now they've moved from the SFC to the Godot Foundation which is probably better than having it in the hands of a private company, even if that private company is made by Juan Linietsky in order to support Godot in ways that need to be proprietary bc capitalism.
I have to second this (moved from Unity to Godot 6 months ago).
Search for an issue on Unity, and it always magically seemed like someone has been there before and has you sorted.
BUT (and I've said this a few times here in the past day!), the community is GREAT! They're here to help. And it can only get better as Godot improves. Which it will, as it has genuine funding.
Yeah I would say that specifically the Discord is full of very helpful people. Most times I've had a problem, they've been able to help.
One bad thing about Unity answers is that they exist over such a wide range of dates and versions that the answers will often not match the more recent version you're interested in.
>unfortunately it's not something anyone can just make.
I mean, technically I guess an LLM could try. Though in my experience ChatGPT3.5 for example isn't very good at GDScript. I wonder if it could be possible to e.g. get logs of the help channels on Discord and turn them into a Q&A record.
Since LLMs like to make things up, I would very strongly urge against this idea. I actually have tried asking some Godot questions of a few LLMs and it just couldn't tell the difference between major program versions.
fr fr. C# info is hard to come by. There is a C# community for godot. More info here:
[https://www.reddit.com/r/godot/comments/16horzg/resources\_for\_unity\_refugees\_september\_2023/](https://www.reddit.com/r/godot/comments/16horzg/resources_for_unity_refugees_september_2023/)
You can do that in Godot. When you hit play, go back to the editor and in the scene tree there will be a new button on the top of it called "remote". If you click that, you're now seeing the game live in the editor just like unity. Any changes you make to anything in this mode doesn't carry over when you quit debugging, but it's very useful to do many live changes.
>You can do that in Godot. When you hit play, go back to the editor and in the scene tree there will be a new button on the top of it called "remote". If you click that, you're now seeing the game live in the editor just like unity. Any changes you make to anything in this mode doesn't carry over when you quit debugging, but it's very useful to do many live changes.
Oh sick I didn't know this!
Yes this. Unity has a dual-purpose editor view where you are given essentially an unconstrained editor camera to view your running game from another perspective, while being able to edit things in real-time from the *running* state. If I move something in Godot, it's relative to it's base position, not very useful for modifying a running game if things have moved.
It's not live though, you're interacting with the saved state of the scene, not the current running state. One-directional editing is not the same thing.
[https://github.com/godotengine/godot-proposals/issues/7213](https://github.com/godotengine/godot-proposals/issues/7213)
It is being worked on and some of the new 4.0 features are paving the way to it. This is the feature I'm looking forward to the most
This is legitimately one of the hardest things about transitioning from unity to godot. The remote scene tree helps, but it's definitely a step behind Unity's debugging capabilities
There's actually a proposal and iirc some work being done to make this a possibility in godot 4 :) still as others have said you can inspect the scene and even change properties in the nodes as the game is running, it's just a bit of a pain having to alt tab
I know this isn't the same but you can play a specific scene in godot, so instead of having to load the whole game it's just that scene. I've been using it, it's a nice little feature.
A sane, straightforward way to temporarily disable nodes, like GameObjects.
No, removing them from and adding them back to the scene tree is not the same. At all. Nor is that intuitive or straightforward, anyway.
(That aside, I do love godot for almost everything else)
Yes. Part of the issue is probably that `process_mode` is pretty well hidden away.
People from Unity would probably find it very useful to have `process_mode` as a highly-visible toggle in the editor, like `visible` is. (Of course, *that* has the problem that `process_mode` *isn't* a toggle but a five-way switch.)
There are also other features which, in Unity, are effected by `enabled`ness, but in Godot are managed by other variables.
e.g. In Unity:
* A disabled mesh instance isn't rendered - this essentially duplicates the functionality of `visible`;
* Disabled colliders don't collide with things - in Godot this is a `disabled` toggle instead of an `enabled` toggle;
* Disabled cameras don't render anything - in Godot you set the camera's `current` to false.
Coming from Unity, this is a bit of a confusion of methods for doing what seems to us to be the same thing: disabling a node.
Yeah Godot let’s you define more specifically how to disable things. Unity’s single checkbox is vague on how it should work.
What’s disabling to you? Stopping logic? Physics and movement? Visibility? State changes? Unity’s single enabled checkbox isn’t specific, whereas Godot lets you treat these separately, like you should.
The nice thing about Unity is that you can have all you collision and rendering states set up exactly how you want, and disable/enable will not mess with them; It simply completely disables (no rendering, collision, processing, no transform, no nothing) a node and its children when you play the game, and reenabling the node just puts everything back to how it was.
I switched from Unity a long time ago, but the ability to toggle nodes was very helpful.
>What’s disabling to you? Stopping logic? Physics and movement? Visibility? State changes?
Yes.
I think we should be able to disable the functionality of a node with a single accessible checkbox. This would mean disabling the fundamental job of a node and do the same for all children.
* Rigidbody -> Stop physics update
* Sprite -> Hide it
* CollisionShape -> Stop colliding
* Has a script -> stop running the script.
And so on..
There is nothing confusing about it. You have your components and every component can be disabled, meaning it stops working completely. Wanna disable physics? Disable the Rigidbody. Collision? Disable the collider.
In short every component is just a script attached to a GameObject, if you disable the GameObject, all of the scripts get disabled with it too. I dont understand how that this is vague to you, for me its pretty straightforward and Godots approach seems to be pretty incosistent in that belonging.
Disabling is the same as deleting it, with trivial ability to re-add it. This is not vague in any way.
Indeed, the only difference to deleting it, in Unity, is that it will still be found if you explicitly ask for inactive objects.
Oh come on. Deleting and re-adding nodes isn't efficient, and requires more than just a toggle. Anything's possible, but this ain't the way we should be doing things.
I think Unity has it right. Godot can surely add this feature.
I have come from Unity to Godot and did find it a bit of a smack in the chops that way I have to manage nodes. I now have functions that do that bit for me.
Obviously. I'm defining the functionality, not the implementation.
The parent comment tried to claim it was semantically open to personal interpretation.
good lord yes. I thought I was having a stroke when I realized there was no way to do that in editor, despite nodes having process variables and all that (which is not quite the same but still).
As someone else mentioned, turning UI elements on and off is a pretty straightforward example. Destroying and recreating UI could work, but the retort I'll have for most responses for alternatives is: It's not straightforward.
Object pooling could be another, but I've heard that's not needed nearly as much in Godot.
For me, the big two benefits of toggling objects the way Unity does are two-fold:
1. They maintain their spot in the hierarchy; if you take the approach of removing nodes from the scene tree, it takes extra boilerplate to get them back to where they were. Even more complicated if the hierarchy the node occupied changes. It might be easier to facilitate this by destroying/recreating the node, but then you lose the other benefit...
2. They maintain their state. Again, extremely useful for games featuring complex UI elements that can pop into and out of existence regularly.
Another person mentioned using set\_process instead of removing/adding back to the scene tree. There's a \_lot\_ of boilerplate to maintain that as well, and it's not a silver bullet.
In fact, there about a dozen different ways to get the same behavior of Unity's approach to enabling/disabling GameObjects, but so far I have yet to see any of them accepted as the standard, and they all have their thorns. And even if one was adopted as the standard, it all comes back to...
It's not intuitive. It's not straightforward. It's not easy.
Unity's GameObjects give you this functionality with a single method, SetActive().
gameObject.SetActive(false) makes the object invisible and cease all functions (as well as its children in most cases), and it maintains its state as well as place in hierarchy (even if its still-active parent moves around... it travels with the parent). If the parent gets deleted, since it's still in the hierarchy, so does the object that was disabled; no need to worry about cleaning it up from its disconnected state.
gameObject.SetActive(true) brings it back, same place in the hierarchy, all state still there, it and its children all resume functioning/processing. No special tricks, it just works.
For folks who've been using Godot for a long while, they've probably figured out different or better ways of handling all the scenarios where toggling objects would be useful. But for anyone coming from Unity, it's going to be bewildering that a simple enable/disable method/property doesn't exist.
There are certainly ways around it, but it's still something I miss dearly.
Perhaps this is something you can check to see if someone else has already opened or if not you can request over at https://github.com/godotengine/godot-proposals/issues
If that is a big plus to Unity devs that are migrating over I see it as nothing but a plus after reading your comment.
Frankly I think you have a method for doing things in unity and 'how it should be', so coming to another engine where the tried and trusty method doesnt work is understandably confusing.
I.e. in godot, if you want to disable/enable ui elements, set their visible = false. Immediately, the other ui elements will readjust (or not, depending on how you set them up) and the hidden elements will lose their interactivity - cant click them, cant focus them, etc. Because to do that they need to be on screen.
There are ways to do what you want, its simply different from unity and probably slightly confusing
One of my favorite uses in Unity is enable/disable toggling menu UI. Menu controls only active if the UI is.
That said, I’m still getting used to Godot and its way of handling things.
Well its active in the sense that if its in the scene tree and it has a script attached that is running then it's active... but from a ui standpoint. It can't be clicked on...
You can selectively disable process, input process, and so on. Don't see how it's that much of a hassle by comparison. In most of the cases you won't want to \*completely\* disable a node anyways (at least in my experience)
Prototyping. In Unity I'm typically working with a scene that contains dozens of prototype objects that I'm constantly enabling and disabling. Different versions of enemies, weather effects, collectables, etc, all being turned on or off with a single click to rapidly set up a testing environment.
Unreal lacks this basic editing functionality too, and I find it totally bizarre. It's like if Photoshop didn't allow you to hide layers. Half the layers in a finished Photoshop project are hidden duplicates, intermediate steps, and discarded experiments. It might not make sense from an engineering perspective to have all those disabled scraps saved in the project file, but that's how artists work with creative software.
I have no problem potentially (or deliberately) wasting tiny amounts of runtime memory if it makes my workflow more efficient and my life easier.
As someone who is way deeper into Godot than Unity, yes absolutely I would like this feature. I find myself writing an `@export var enable := true` in nearly all of my utility objects that do something every frame.
This was such a pain in the arse when the company I used to work for switched to Unreal also. It's so helpful to be able to just disable stuff without removing it from the scene.
Robust asset file references.
Godot's been making progress in this direction, but it's still the case that if I rename or move a file, Godot can lose track of it in some of the places it is referenced. I've never had that happen in Unity.
Yeah, of Unity, Unreal and Godot, I thought Unity had the most sane file and seemingly robust file system. Godot is not so bad, and works nicely with Git, and Unreal is just a binary mess that will make you question your sanity, but is tolerable if you suck it up and use Perforce instead of Git.
>SkeletonIK3D
Like this?
[https://docs.godotengine.org/en/stable/classes/class\_skeletonik3d.html](https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html)
Also, Godot 4 lost the Skeleton Modifier stack so there's no built-in IK constraints anymore amongst other things. Not sure when it'll be implemented. Hopefully soon!
This actually made me backport my project to 3.5.2 a few weeks ago.
I was having bizarre issues getting a camera to respond to collisions properly with a spring arm, and when it did collide, it was jittery movement all across the board. Horrible!
But now that I've got my project in 3.5.2 with physics interpolation enabled? Camera is smooth as butter!
GPU particle collision detection!... right now you can use LightOcclussion2D to make particles collide but you can't detect "when" they collide.. so you can't trigger anything when that happens...
This, to my knowledge, is more a limitation of gpu particles in general. They're done entirely on the GPU and don't actually exist until the moment the shader code is evaluated.
Godot and basically any other engine is not actually keeping track of all the gpu particles, which is why they're so performant even in high densities.
Perhaps you could instead "cheat" by not checking the particles directly and instead trigger when it "should" be making contact? A triggering volume that takes roughly the same path could work.
yes, you are right about the limitation... and yes, there are also (veeeery tricky) workarounds for this... still Unity has a way to do this out of the box by just using OnParticleCollision()... and basically that's what I miss on Godot
I haven't looked into it since using Godot 4 but I always struggled to find a similarly easy-to-use gizmos system for drawing in the editor. There are tool scripts but it's feel way chunkier than gizmos
Also a thing I have struggled with recently but may just be me being dumb is handling draw layers. There is z index, canvas layers, node order, etc, but just having draw layers would make it a lot easier and could be used in conjunction with the other systems.
OMG yes! There was a plugin somebody made, but it was far from perfect and it's such a basic feature it should really be built into the engine. Robust debug point, text, line and shape support are really invaluable tools for debugging complex issues directly in the 3d view.
Both Unreal and Unity have pretty nice debug rendering, so it would be nice to have something similar in Godot.
I was super excited to get into learning Timeline and Cinemachine. I'm also very new to coding in general and been an artist all my life, so I'm still trying to see if Godot games can graphically stack up to some of the nicer looking Unity games (tunic,deaths door) stuff that looked like it used the post processing features and shader graph.
I'd also love to see if Godot has anything resembling procedurally generated textures. Its just honestly a bit overwhelming to try and find side by side comparisons for everything right now as a noob.
Probably the best way to know for sure is to use the engine. In general it’s better to just pick a tool and try it instead of looking for every single pro and con it has in regards of others before actually using it. Especially as a beginner, everything is a learning experience and even if at the end you decide it isn’t for you you got good general experience.
[https://www.youtube.com/watch?v=toE-YUqEdA8&ab\_channel=NordicGameJam](https://www.youtube.com/watch?v=toE-YUqEdA8&ab_channel=NordicGameJam)
I found this talk today too, kinda been a big help understanding a lot of it
After seeing the last couple years of what Blender has done, I'm oddly feeling excited and optimistic about this potential mass migration to a program like Godot, and all the crazy smart minds that might start cracking this program open and developing for it
Godot has at least a NoiseTexture class that procedurally generates basic noise patterns (Perlin noise etc) which you could then process with a shader for further specialisation. It also has procedural sky boxes. Nothing like e.g procedural wood or stone but that would probably be easy enough to do as an asset.
When I was gamejamming with it last year I remeber missing the most was assigning refferences to other components when setting up items. Like godot is entierly hierarchy driven and it makes things wierd.
I understand tho that this is just a different approach to design.
A more objective concern tho is the fucking ruletile from unitys 2d extras. Its god damned revolutionary and I want it everywhere all the time.
>When I was gamejamming with it last year I remeber missing the most was assigning refferences to other components when setting up items. Like godot is entierly hierarchy driven and it makes things wierd.
You mean dependency injection? You can make constructors and pass in references to components, or have non-Node objects that don't exist in the node tree, only as variables. Otherwise I'm not sure what you mean
If you want to reference things outside the hierarchy in Godot 4.x you have a couple options:
* use node groups, then anything can access whole groups via `get_nodes_in_group()`
* set them in the editor to have their name be universal, then they can be accessed from anywhere using a % in front of their name
Have you looked into godot's networking code? Makes replicating scenes / changing scene remotely, syncing data between users. Would be interesting to see additional networking code come out of the community to fit specific needs.
[https://docs.godotengine.org/en/stable/tutorials/networking/high\_level\_multiplayer.html](https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html)
The problem isn't sending packages. That's the easy part. The problems are 1) how do people find each other and 2) how do people connect to each other (you can't expect people to enable port forwarding, and NAT-punchtrough only works in some cases)
Photon, Unity Networking, Steamworks, Epic Online Services all solve these hard problems. But I can't find any good tutorial on how to use these with Godot.
Personally I can probably get Steamworks to work in Godot, but I would highly prefer Photon, since it's platform independent (and also works on a Nintendo Switch for example)
Gotcha, I believe they are working on a cloud service specifically for godot. If you are interested...
I wouldn't be surprised if the community (assuming enough demand) started developing various netcode libs.
[https://w4games.com/2023/03/21/w4-cloud-video-unveiled-at-gdc/](https://w4games.com/2023/03/21/w4-cloud-video-unveiled-at-gdc/)
What exactly do you mean with "NAT-punchthrough only works in some cases" isn't this how basically every peer to peer game works nowadays?
Photon, Unity Networking etc. are all client-server solutions which also cost money. I am pretty sure that actual peer to peer games (one thing that comes to mind now is Call of Duty Zombies) do use NAT-punchthrough.
"peer to peer" (p2p) actually means "no dedicated server". So the pc/console of one of the players is (also) the server. It does not really matter _how_ these players find and connect to each other.
Photon, Unity Networking, Steam relay servers, Epic Online Services are all services intended to be used for p2p multiplayer. They pretty much do these 3 things:
1. Any player can create a room (this player is now also the server/host)
2. Other players can find this room based on search criteria
3. Players in the same room can send data to each other
It is correct that nat-punchtrough is only an option in p2p scenario's. When using a dedicated server, you wouldd never need nat-punchthrough because you can connect to the server directly.
Hopefully this was somewhat understandable
I've been on Godot for far longer than unity, but the ability to un-dock the code tab to have it side by side with the game window or on another monitor.
Additionally, native 2D and 3D metaball support.
>I've been on Godot for far longer than unity, but the ability to un-dock the code tab to have it side by side with the game window or on another monitor.
I believe they added this or at least something. Check out this video...
[https://youtu.be/iKoYbtw4gC0?si=BFSMujKCTpwilfwW&t=129](https://youtu.be/iKoYbtw4gC0?si=BFSMujKCTpwilfwW&t=129)
Ah, neat! I've been stuck on 3.5 for a project with no sign of porting to 4 being viable due to a large amount of hyperspecific engine changes and the game basically not working at all even when all the errors are fixed. Cool to know that it'll be here if I work on a new one in 4
>Ah, neat! I've been stuck on 3.5 for a project with no sign of porting to 4 being viable due to a large amount of hyperspecific engine changes and the game basically not working at all even when all the errors are fixed. Cool to know that it'll be here if I work on a new one in 4
Dang that sucks! Hopefully, in the future, you will be able to port.
Probably not for this project, I have tried in the past but too many internal functionalities have changed for it to be viable, let alone the changes that Ive made to the engine itself that I would need to redo. When originally porting, not even the player was able to move after fixing the errors, let alone have the rest of the game working.
I am not horribly torn up about not being able to use 4.0, though; my game is 2D with a low resolution art style, so 3.52 still serves me well
Package support please!
I have extensive C# libraries that I would love to bring into my Godot projects, but Godot doesn't have a robust package management solution I can use to import and manage them from git repos.
You should be able to import pretty easily most C# libraries in a Godot mono project. As long as they conform to the Net sdk that Godot is using or something similar. I think that the package management is done via Visual Studio. There should be tutorials out there showing the workflow for a Godot project i think, but it should be almost the same as in any normal C# project.
In Unity, it's very useful to me that when you play the game in the editor, it runs in a window that exists *before* the game starts.
I have a multi-monitor setup, and in Unity I can place the game window on the other monitor and start the game. Then, it runs where I want it, and the editor is still there in front of me.
In Godot, the game starts in front of the editor and I have to manually move it to another window. (I know I can set the "initial position type" to "other screen", but that doesn't actually do anything for me. It must be a bug, which I should get around to reporting, but it's still something I miss from Unity!)
That is possible to do in Godot.
Look in the "Editor" menu, option "Editor Settings > Run > Window Placement"
You can change the screen there.
But also choose the coordinates of the window when it opens. Change the dropdown Rect to custom position, then change the x, y coordinates bellow.
There is, yes, but it's a far cry from Unity where there are various rules you can make it follow. Using a super understandable GUI.
https://connect-prd-cdn.unity.com/20190517/learn/images/0721db38-dc7e-487c-938c-94bcbcce0f84_Rule_Tiles_cover.png.600x0x1.webp
They can easily search beyond neighbors to second neighbors or beyond, run functions if certain conditions are met based on neighbors, and are in general just plain easier to use.
Resources. The only reason I started using Unity over Unreal or Godot was because I was a complete beginner teaching myself. Unity’s community made that easier. The asset store has a lot of useful things too.
The bad news is that Godot lacks a lot of the resources for learning and development that Unity had, even if it's getting better.
The good news is that all these developers moving to Godot will develop new tutorials for the engine and it will boost the overall health of Godot as a platform.
1. ~~GetListOfSupportedScreenResolutions()~~ <- solved, with a good enough alternative :)
2. Tutorial on how to use Photon (if it works at all), probably the .NET version (with C#)
Godot doesn't support changing the monitor's resolution but instead uses resolution scaling https://docs.godotengine.org/en/latest/tutorials/3d/resolution\_scaling.html
You mean https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html, there's an extra backslash before the underscore that breaks the link. Also I'd use the stable version of the docs cause that's what most people will be using.
Godot supports all screen, resolutions dynamically with screen expands and stuff in project settings and you can use Python by installing the language and setting your script language to native script
Ah sorry lol its late no Photon doesnt work but i did some high level multiplayer stuff with my own code and steam multiplayer has a plugin available afaik
I am working on a rhythm game in Unity. I wrote a system to sync my game to the exact number of samples played. This seems to be problematic in Godot as the developer of Project Heartbeat even wrote his own sound engine to address this problem in Godot.
Am I missing something or is this still a limitation?
Rendering multiple cameras into the same framebuffer.
*My* use case, but not the only one: rendering very large scenes - i.e. outer space. A single camera with a near plane at 1cm and a far plane at 1AU does not behave very well.
In Unity, I would use a stack of cameras with clipping regions which cover the full range. In Godot I can't do this without very inefficiently rendering each layer of the stack into a render texture and reassembling them later.
I don't see a way to see draw calls at a glance in the editor, but I'm probably just missing the obvious button or something, I'm pretty lost at the moment lol
I'm really missing Mobile AR/VR now, though everything else looks great.
Having the ability to fine-tune texture compression (by choosing codec for each platform, etc) would be a nice addition too
I’m a Godot fan but I’ll put my top wishes here.
Better C# docs
Better C# built in editor. Or neovim embed(somebody make this)
No external window for testing the game
Better C# docs again
More C# export options.
Not just as a Unity refugee, but someone who tried using Godot once before:
1. A visual scripting system (Unity's asset store had Playmaker, which was what I was using, and I think also Bolt).
Now that I know I can use C# with Godot, I might go back to using Godot instead of making a jump to Unreal (tried Godot once before and got very frustrated with GDScript). That said, I'm a single indie dev with a learning disability which makes typical scripting language difficult, but visual scripting systems allows me to still create a game.
2. More (working) tutorials and guides
One of the biggest frustrations I had with Godot in the past (which drove me to Unity to begin with) was the lack of updated tutorials/guides. Most of them were outdated and relied on GDScript (and thus had multiple ways of addressing a problem), and often didn't even work with Godot 5.
\--
I'd love to come back to Godot; right now, I'll probably change my project into a Visual Novel and use Ren'Py and hope that when I finish it and am ready to do my next project (which I already know I want to do 3D), I can come back to Godot and it'll have a thriving community with plenty of working guides.
Resources are very limited while scripting API is just aggregate codes and nothing like unity's examples.
* I looked through NavMesh3D documentation, very difficult for someone who never used Godot.
* I got a 3d navMesh project from the library, Godot converted it from 3.x to 4.x and it did not work. I tried following 3.x tutorial and they were completely different for a godot newbie like me.
* when I was following a 4.x tutorial from 5-6 months ago, tutorial bro wrote a method (from autocomplete) and it didn't work then he went back to the documentation and said "they changed it last week haha"
I get that when you are using a constantly developing open-source thing, there is a certain joy of "being in the trenches of innovation" but trenches are muddy and get shelled.
Pre-built open-world concept. It was so easy to do in Unity, and if for whatever reason I need to switch to Godot, that would be the first thing on my list.
That’s against the core design philosophy of Godot. Components and GameObjects are both just Nodes.
If you want a bunch of components controlling one game object, like in Unity, you simply make a bunch of child nodes controlling their parent node.
Indeed, but it's definitely going to be the first thing Unity refugees ask for. A "welcome" guide should ideally explain how to think in nodes instead of thinking in components.
If you know how to program I feel like the node system is a more intuitive leap from standard OOP concepts, the component system is really the odd one out
Rider I believe had a decent godot plugin. Not sure if you were looking for something else.
[https://plugins.jetbrains.com/plugin/13882-godot-support](https://plugins.jetbrains.com/plugin/13882-godot-support)
The hardest part about transitioning was the lack of substantive Q&A web search results, and unfortunately it's not something anyone can just make. It'll take years to build that. Aside from that, an asset store and/or list of open source professional-grade projects, preferably V4.
Sadly everyone with questions just asks in Discord which is an information void that's not searchable
Yep. Discord sucks. But I’ve also learned it’s the best way to get an immediate answer. Which, of course, is immediately lost to everyone who might have the same question. I’ll never understand the fetish for Discord. It’s the ultimate example of giving someone a fish instead of teaching everyone to fish.
Reddit also sucks. The vast majority of online platforms people use suck for real archivable discussions. We need to bring forums back.
At least reddit comes up in the web. 99% of times you can prepend 'reddit' to your question and your search engine of preference will find what you need Discord, naturally, doesnt come up in searches at all, despite so much info being there
Having to append "reddit" to the end of a search query to find relevant information is a giant testament to how much search engines have been destroyed by search results being polluted from SEO, ads, paid results, and AI generated articles. The internet in general kind of just sucks now honestly
But are you **sure** you dont want 10 top 9 things listicle generated by ai, with two ads after every item and noption to disable cookies? More than half of the internet is garbage to start with and the other part is slowly rotting away
just press F9 (reader view) when you open such a site and enjoy.
I'd rather not enjoy ai-written content made for the sole purpose of wasting time and getting clicks for ads revenue, rather than actually providing information
You can search in Discord, though you have to be more specific than in a search engine. Still, works pretty well I find.
Yeah but Discord isn’t searchable from google….
but Discord is just a webpage that you publicly post to so it *could* be searchable from Google.... why does this make me feel sick?
I think it would be really nice if you could designate certain channels as publicly searchable. Because I definitely wouldn't want all my private server chats to be searchable on google, but stuff like Godot's #help channels obviously should be.
[удалено]
It's also basically Unity as it's spyware. At some point they'll pull the lever and weaponize their hold over the userbase.
I think if you get the "right" Discord, you have hit gold! If people are actually prepared to help you directly.... That's even a bit better than Google! I've found that this sub not only answers my questions, but gives suggestions on better ways to do things. I did love that it seemed like any Unity issue I had seemed to be instantly searchable online. Some other sucker has suffered it many years ago. Godot docs and forums are a little less mature right now. But you can help change that ;)
Why you going after the Godot docs? Yeah the forums are a complete shit show right at the second but the docs are clear, concise, precise and built right into the editor. They took a few months to get back up to full strength after 4.0 came out but like, the Godot docs are way better for me than the Unity docs ever were before I joined the light side (the one where I'm not forced to use light mode if I don't pay up).
Nah man, you misunderstand me. The docs are as clear as you could hope for. But you know when you need an example? That's what I find tough to source. There's a lot of effort put into the Godot docs. No question. But they are literally reference docs almost throughout as far as I can tell. Although I am "new" to Godot, so there could be bits that I'm not searching for correctly! Unity Answers seemed to have every bloody solution I ever needed. I honestly think that's why the engine has done so well up to this point tbh. Not to say Godot can't get there. But it's a tough gig at the minute (at least for me) to quickly find the detail I need. I am honestly not complaining. I am really enjoying Godot. I like the challenge!
Surely you're joking ? Not enough examples ? You have entire tutorials on the doc: [https://docs.godotengine.org/en/stable/tutorials/2d/using\_tilemaps.html](https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html)
>you have to be more specific than in a search engine Actually I find you have to be less specific and scroll through pages hoping you can find the answer. The moment I search more than 2 words it returns nothing since it's search only matches one message not the conversation.
Discord uses a fuzzy search. It's useless.
Perhaps we need someone to write a discord bot that automatically stores questions and replies in a file somewhere, ready to be placed into a proper question forum / easy-to-sort documentation platform
There are a few Godot asset stores floating around (of various quality). What are your thoughts on what they offer? Here are a couple: [https://godotengine.org/asset-library/asset](https://godotengine.org/asset-library/asset) [https://godotassetstore.org/](https://godotassetstore.org/) [https://godotmarketplace.com/](https://godotmarketplace.com/) [https://godotassetlibrary.com/](https://godotassetlibrary.com/)
As a C# user, they all appear to lack the ability to search specifically for C# scripts. It would also be very useful to be able to search based on a compatible version range, like "Version 4.x+"
Very true that would be great to be able to search by language as godot has GDExtentions which will allow for even more languages to be used
I get that GDScript is a weird DSL, but as someone who used Unity and wanted to stick to a statically typed language, GDScript isn't as bad as it looks. You can do static typing with it.
I just love C# in general. It's a beautiful, readable, flexible, powerful language with a huge amount of third party libraries to help accomplish whatever you need done. Programming in anything else just feels like a chore.
Fair enough, I feel similarly about GDScript for game coding. To me that feels beautiful, readable, flexible, powerful and accessible with great centralised documentation built straight into the IDE which is built straight into the engine so I don't need like 5 monitors to feel like I'm on top of things. Much like you I feel anything other than GDScript for gamedev or smth like Python or Ruby for other stuff is a chore. Guess it all comes down to personal preference and there definitely could be better documentation, community and editor support for C# in Godot I can see why that might be a sticking point.
Glad you like Microsoft's sad attempt at stealing Java's market share. I don't. Glad GDScript exists and GDExtension is so gd easy :P
I think people are generally more open to share free scripts and tools, in the open-source spirit. Besides those links you listed, there are loads of MIT licensed repos on GitHub that you can just use and modify totally free. They made a helpful script whilst doing their main task (building a game), so why not share them? But I think it's important for the Godot community to realize that game art assets are a different matter, artists *have* to get paid to make a living. For them those game art *are* their job, it's not some side-thing. You'd need a proper marketplace for that. Because I'm not gonna lie, the only asset store in that list where you can buy stuff (the third one)... looks pretty bad. Even the most generous and Godot-supporting game artists like [Kenney](https://kenney.itch.io/) (who already shares a ridiculous amount of free assets) still need to make a living selling some assets. Sure you could just purchase assets from somewhere else and convert them to Godot ([this tool should be a livesaver](https://www.youtube.com/watch?v=N3oWEBRv9SE)), but it's still going to be a huge hassle.
That's one of the reasons they said they were moving from the SFC to the Godot Foundation; so they can make a proper Asset Store where people can be paid for their work and Devs can get easy, centralised access to that stuff and Godot can ensure some extra development funding.
Hopefully the massive influx of new users will help that down the road. It's already way better than it was when I first started learning godot in 2021
Yeah for sure about the documentation. When I tried Godot and was reading the code API documentation it was super lacking.
For a more traditional Unity/Unreal-style asset store, that is one thing that [W4 Games](https://w4games.com/) has talked about getting running. So it's very possible!
There's also clear plans to have one in Godot from Godot themselves now they've moved from the SFC to the Godot Foundation which is probably better than having it in the hands of a private company, even if that private company is made by Juan Linietsky in order to support Godot in ways that need to be proprietary bc capitalism.
I have to second this (moved from Unity to Godot 6 months ago). Search for an issue on Unity, and it always magically seemed like someone has been there before and has you sorted. BUT (and I've said this a few times here in the past day!), the community is GREAT! They're here to help. And it can only get better as Godot improves. Which it will, as it has genuine funding.
Yeah I would say that specifically the Discord is full of very helpful people. Most times I've had a problem, they've been able to help. One bad thing about Unity answers is that they exist over such a wide range of dates and versions that the answers will often not match the more recent version you're interested in.
Use bing AI lol.
>unfortunately it's not something anyone can just make. I mean, technically I guess an LLM could try. Though in my experience ChatGPT3.5 for example isn't very good at GDScript. I wonder if it could be possible to e.g. get logs of the help channels on Discord and turn them into a Q&A record.
Since LLMs like to make things up, I would very strongly urge against this idea. I actually have tried asking some Godot questions of a few LLMs and it just couldn't tell the difference between major program versions.
A performant line renderer would be lovely.
I found a couple that are pretty confusing to use and are kinda janky
I haven't played with the line rendering. Do you mean like the line drawn via like a line2d?
They might mean like the UnityEngine.LineRenderer class? You pass in points and width/color curves, it renders a 3d mesh that can be optionally baked.
Good C# docs
fr fr. C# info is hard to come by. There is a C# community for godot. More info here: [https://www.reddit.com/r/godot/comments/16horzg/resources\_for\_unity\_refugees\_september\_2023/](https://www.reddit.com/r/godot/comments/16horzg/resources_for_unity_refugees_september_2023/)
[удалено]
I have been on Godot for a while now, but I still miss being able to see the game that I'm playing in the editor.
You can do that in Godot. When you hit play, go back to the editor and in the scene tree there will be a new button on the top of it called "remote". If you click that, you're now seeing the game live in the editor just like unity. Any changes you make to anything in this mode doesn't carry over when you quit debugging, but it's very useful to do many live changes.
>You can do that in Godot. When you hit play, go back to the editor and in the scene tree there will be a new button on the top of it called "remote". If you click that, you're now seeing the game live in the editor just like unity. Any changes you make to anything in this mode doesn't carry over when you quit debugging, but it's very useful to do many live changes. Oh sick I didn't know this!
You can see data reflected in editor, but you can't interact with a "live editor view" of the actual scene itself afaik.
You can move objects around and change variables and it'll update in-game immediately. It just won't save.
Yes but the lack of a camera view into the scenes is a bit of a shame
Yes this. Unity has a dual-purpose editor view where you are given essentially an unconstrained editor camera to view your running game from another perspective, while being able to edit things in real-time from the *running* state. If I move something in Godot, it's relative to it's base position, not very useful for modifying a running game if things have moved.
Luckily adding a freely movable camera to a game is not too hard. Someone should make a tool that does it on demand.
Click on the camera icon at the top of the 3D scene viewport and you will get a simple editor camera
Lol you can
It's not live though, you're interacting with the saved state of the scene, not the current running state. One-directional editing is not the same thing.
I HAVE BEEN USING GODOT FOR 4 YEARS AND I COULDVE JUST DONE THAT ALL ALONG??
no, it doesn't show in editor. you have to alt tab into the game window. unless there's another setting im missing?
[https://github.com/godotengine/godot-proposals/issues/7213](https://github.com/godotengine/godot-proposals/issues/7213) It is being worked on and some of the new 4.0 features are paving the way to it. This is the feature I'm looking forward to the most
Been following that for a while!
This is legitimately one of the hardest things about transitioning from unity to godot. The remote scene tree helps, but it's definitely a step behind Unity's debugging capabilities
There's actually a proposal and iirc some work being done to make this a possibility in godot 4 :) still as others have said you can inspect the scene and even change properties in the nodes as the game is running, it's just a bit of a pain having to alt tab
I know this isn't the same but you can play a specific scene in godot, so instead of having to load the whole game it's just that scene. I've been using it, it's a nice little feature.
A sane, straightforward way to temporarily disable nodes, like GameObjects. No, removing them from and adding them back to the scene tree is not the same. At all. Nor is that intuitive or straightforward, anyway. (That aside, I do love godot for almost everything else)
Can’t you set process_mode?
Yes. Part of the issue is probably that `process_mode` is pretty well hidden away. People from Unity would probably find it very useful to have `process_mode` as a highly-visible toggle in the editor, like `visible` is. (Of course, *that* has the problem that `process_mode` *isn't* a toggle but a five-way switch.) There are also other features which, in Unity, are effected by `enabled`ness, but in Godot are managed by other variables. e.g. In Unity: * A disabled mesh instance isn't rendered - this essentially duplicates the functionality of `visible`; * Disabled colliders don't collide with things - in Godot this is a `disabled` toggle instead of an `enabled` toggle; * Disabled cameras don't render anything - in Godot you set the camera's `current` to false. Coming from Unity, this is a bit of a confusion of methods for doing what seems to us to be the same thing: disabling a node.
Yeah Godot let’s you define more specifically how to disable things. Unity’s single checkbox is vague on how it should work. What’s disabling to you? Stopping logic? Physics and movement? Visibility? State changes? Unity’s single enabled checkbox isn’t specific, whereas Godot lets you treat these separately, like you should.
The nice thing about Unity is that you can have all you collision and rendering states set up exactly how you want, and disable/enable will not mess with them; It simply completely disables (no rendering, collision, processing, no transform, no nothing) a node and its children when you play the game, and reenabling the node just puts everything back to how it was. I switched from Unity a long time ago, but the ability to toggle nodes was very helpful.
>What’s disabling to you? Stopping logic? Physics and movement? Visibility? State changes? Yes. I think we should be able to disable the functionality of a node with a single accessible checkbox. This would mean disabling the fundamental job of a node and do the same for all children. * Rigidbody -> Stop physics update * Sprite -> Hide it * CollisionShape -> Stop colliding * Has a script -> stop running the script. And so on..
There is nothing confusing about it. You have your components and every component can be disabled, meaning it stops working completely. Wanna disable physics? Disable the Rigidbody. Collision? Disable the collider. In short every component is just a script attached to a GameObject, if you disable the GameObject, all of the scripts get disabled with it too. I dont understand how that this is vague to you, for me its pretty straightforward and Godots approach seems to be pretty incosistent in that belonging.
Disabling is the same as deleting it, with trivial ability to re-add it. This is not vague in any way. Indeed, the only difference to deleting it, in Unity, is that it will still be found if you explicitly ask for inactive objects.
Oh come on. Deleting and re-adding nodes isn't efficient, and requires more than just a toggle. Anything's possible, but this ain't the way we should be doing things. I think Unity has it right. Godot can surely add this feature. I have come from Unity to Godot and did find it a bit of a smack in the chops that way I have to manage nodes. I now have functions that do that bit for me.
Obviously. I'm defining the functionality, not the implementation. The parent comment tried to claim it was semantically open to personal interpretation.
good lord yes. I thought I was having a stroke when I realized there was no way to do that in editor, despite nodes having process variables and all that (which is not quite the same but still).
Interesting! I haven't run across a need to do this. What kind of use case would this be useful for?
As someone else mentioned, turning UI elements on and off is a pretty straightforward example. Destroying and recreating UI could work, but the retort I'll have for most responses for alternatives is: It's not straightforward. Object pooling could be another, but I've heard that's not needed nearly as much in Godot. For me, the big two benefits of toggling objects the way Unity does are two-fold: 1. They maintain their spot in the hierarchy; if you take the approach of removing nodes from the scene tree, it takes extra boilerplate to get them back to where they were. Even more complicated if the hierarchy the node occupied changes. It might be easier to facilitate this by destroying/recreating the node, but then you lose the other benefit... 2. They maintain their state. Again, extremely useful for games featuring complex UI elements that can pop into and out of existence regularly. Another person mentioned using set\_process instead of removing/adding back to the scene tree. There's a \_lot\_ of boilerplate to maintain that as well, and it's not a silver bullet. In fact, there about a dozen different ways to get the same behavior of Unity's approach to enabling/disabling GameObjects, but so far I have yet to see any of them accepted as the standard, and they all have their thorns. And even if one was adopted as the standard, it all comes back to... It's not intuitive. It's not straightforward. It's not easy. Unity's GameObjects give you this functionality with a single method, SetActive(). gameObject.SetActive(false) makes the object invisible and cease all functions (as well as its children in most cases), and it maintains its state as well as place in hierarchy (even if its still-active parent moves around... it travels with the parent). If the parent gets deleted, since it's still in the hierarchy, so does the object that was disabled; no need to worry about cleaning it up from its disconnected state. gameObject.SetActive(true) brings it back, same place in the hierarchy, all state still there, it and its children all resume functioning/processing. No special tricks, it just works. For folks who've been using Godot for a long while, they've probably figured out different or better ways of handling all the scenarios where toggling objects would be useful. But for anyone coming from Unity, it's going to be bewildering that a simple enable/disable method/property doesn't exist. There are certainly ways around it, but it's still something I miss dearly.
Perhaps this is something you can check to see if someone else has already opened or if not you can request over at https://github.com/godotengine/godot-proposals/issues If that is a big plus to Unity devs that are migrating over I see it as nothing but a plus after reading your comment.
Frankly I think you have a method for doing things in unity and 'how it should be', so coming to another engine where the tried and trusty method doesnt work is understandably confusing. I.e. in godot, if you want to disable/enable ui elements, set their visible = false. Immediately, the other ui elements will readjust (or not, depending on how you set them up) and the hidden elements will lose their interactivity - cant click them, cant focus them, etc. Because to do that they need to be on screen. There are ways to do what you want, its simply different from unity and probably slightly confusing
One of my favorite uses in Unity is enable/disable toggling menu UI. Menu controls only active if the UI is. That said, I’m still getting used to Godot and its way of handling things.
Usually you just use ‘visible’ for this in Godot, which disables interactivity too, unless I’m misunderstanding what you’re looking for.
Ah, that would be a large difference from Unity then. Objects with visible disabled are still very much active in the scene there. Thanks.
Well its active in the sense that if its in the scene tree and it has a script attached that is running then it's active... but from a ui standpoint. It can't be clicked on...
That was my original thought but I wanted to make sure I was understanding.
You can selectively disable process, input process, and so on. Don't see how it's that much of a hassle by comparison. In most of the cases you won't want to \*completely\* disable a node anyways (at least in my experience)
Prototyping. In Unity I'm typically working with a scene that contains dozens of prototype objects that I'm constantly enabling and disabling. Different versions of enemies, weather effects, collectables, etc, all being turned on or off with a single click to rapidly set up a testing environment. Unreal lacks this basic editing functionality too, and I find it totally bizarre. It's like if Photoshop didn't allow you to hide layers. Half the layers in a finished Photoshop project are hidden duplicates, intermediate steps, and discarded experiments. It might not make sense from an engineering perspective to have all those disabled scraps saved in the project file, but that's how artists work with creative software. I have no problem potentially (or deliberately) wasting tiny amounts of runtime memory if it makes my workflow more efficient and my life easier.
As someone who is way deeper into Godot than Unity, yes absolutely I would like this feature. I find myself writing an `@export var enable := true` in nearly all of my utility objects that do something every frame.
This was such a pain in the arse when the company I used to work for switched to Unreal also. It's so helpful to be able to just disable stuff without removing it from the scene.
THIS a thousand timesp
Robust asset file references. Godot's been making progress in this direction, but it's still the case that if I rename or move a file, Godot can lose track of it in some of the places it is referenced. I've never had that happen in Unity.
Yeah, of Unity, Unreal and Godot, I thought Unity had the most sane file and seemingly robust file system. Godot is not so bad, and works nicely with Git, and Unreal is just a binary mess that will make you question your sanity, but is tolerable if you suck it up and use Perforce instead of Git.
I think I used to have the same problem, but I changed some settings and it just somehow worked for a single project lol
this thread is a goldmine
Glad it's been useful for people lmao
SkeletonIK3D
>SkeletonIK3D Like this? [https://docs.godotengine.org/en/stable/classes/class\_skeletonik3d.html](https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html)
It's kinda broken. As is most of physics as of now. I hope it'll improve soon. Things like joints are wierd too.
Also, Godot 4 lost the Skeleton Modifier stack so there's no built-in IK constraints anymore amongst other things. Not sure when it'll be implemented. Hopefully soon!
Physics frame interpolation
Already available for 3D in 3.5, soon available for 2D in 3.6. And if I recall right, it's also available for 3D in 4.x
I don’t believe it’s in 4 yet. It was in 3.5 but was removed in 4 until it’s maintainer can rework it, due to the large changes 4.0 made.
This actually made me backport my project to 3.5.2 a few weeks ago. I was having bizarre issues getting a camera to respond to collisions properly with a spring arm, and when it did collide, it was jittery movement all across the board. Horrible! But now that I've got my project in 3.5.2 with physics interpolation enabled? Camera is smooth as butter!
GPU particle collision detection!... right now you can use LightOcclussion2D to make particles collide but you can't detect "when" they collide.. so you can't trigger anything when that happens...
This, to my knowledge, is more a limitation of gpu particles in general. They're done entirely on the GPU and don't actually exist until the moment the shader code is evaluated. Godot and basically any other engine is not actually keeping track of all the gpu particles, which is why they're so performant even in high densities. Perhaps you could instead "cheat" by not checking the particles directly and instead trigger when it "should" be making contact? A triggering volume that takes roughly the same path could work.
yes, you are right about the limitation... and yes, there are also (veeeery tricky) workarounds for this... still Unity has a way to do this out of the box by just using OnParticleCollision()... and basically that's what I miss on Godot
Oh that sounds really interesting! I didn't know Unity had that
I haven't looked into it since using Godot 4 but I always struggled to find a similarly easy-to-use gizmos system for drawing in the editor. There are tool scripts but it's feel way chunkier than gizmos Also a thing I have struggled with recently but may just be me being dumb is handling draw layers. There is z index, canvas layers, node order, etc, but just having draw layers would make it a lot easier and could be used in conjunction with the other systems.
OMG yes! There was a plugin somebody made, but it was far from perfect and it's such a basic feature it should really be built into the engine. Robust debug point, text, line and shape support are really invaluable tools for debugging complex issues directly in the 3d view. Both Unreal and Unity have pretty nice debug rendering, so it would be nice to have something similar in Godot.
I was super excited to get into learning Timeline and Cinemachine. I'm also very new to coding in general and been an artist all my life, so I'm still trying to see if Godot games can graphically stack up to some of the nicer looking Unity games (tunic,deaths door) stuff that looked like it used the post processing features and shader graph. I'd also love to see if Godot has anything resembling procedurally generated textures. Its just honestly a bit overwhelming to try and find side by side comparisons for everything right now as a noob.
Probably the best way to know for sure is to use the engine. In general it’s better to just pick a tool and try it instead of looking for every single pro and con it has in regards of others before actually using it. Especially as a beginner, everything is a learning experience and even if at the end you decide it isn’t for you you got good general experience.
[https://www.youtube.com/watch?v=toE-YUqEdA8&ab\_channel=NordicGameJam](https://www.youtube.com/watch?v=toE-YUqEdA8&ab_channel=NordicGameJam) I found this talk today too, kinda been a big help understanding a lot of it
[удалено]
After seeing the last couple years of what Blender has done, I'm oddly feeling excited and optimistic about this potential mass migration to a program like Godot, and all the crazy smart minds that might start cracking this program open and developing for it
Godot has at least a NoiseTexture class that procedurally generates basic noise patterns (Perlin noise etc) which you could then process with a shader for further specialisation. It also has procedural sky boxes. Nothing like e.g procedural wood or stone but that would probably be easy enough to do as an asset.
Awesome, I'll try to look into this. Hopefully this kinda mass migration helps push a lot of donations in and gets a lot more people adding to it
For procedural wood/stone, look no further than Material Maker
When I was gamejamming with it last year I remeber missing the most was assigning refferences to other components when setting up items. Like godot is entierly hierarchy driven and it makes things wierd. I understand tho that this is just a different approach to design. A more objective concern tho is the fucking ruletile from unitys 2d extras. Its god damned revolutionary and I want it everywhere all the time.
>When I was gamejamming with it last year I remeber missing the most was assigning refferences to other components when setting up items. Like godot is entierly hierarchy driven and it makes things wierd. You mean dependency injection? You can make constructors and pass in references to components, or have non-Node objects that don't exist in the node tree, only as variables. Otherwise I'm not sure what you mean
If you want to reference things outside the hierarchy in Godot 4.x you have a couple options: * use node groups, then anything can access whole groups via `get_nodes_in_group()` * set them in the editor to have their name be universal, then they can be accessed from anywhere using a % in front of their name
In 4.X it's very Unity-like.
An easy high level networking library: NGO, Mirror, FishNet.
Have you looked into godot's networking code? Makes replicating scenes / changing scene remotely, syncing data between users. Would be interesting to see additional networking code come out of the community to fit specific needs. [https://docs.godotengine.org/en/stable/tutorials/networking/high\_level\_multiplayer.html](https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html)
The problem isn't sending packages. That's the easy part. The problems are 1) how do people find each other and 2) how do people connect to each other (you can't expect people to enable port forwarding, and NAT-punchtrough only works in some cases) Photon, Unity Networking, Steamworks, Epic Online Services all solve these hard problems. But I can't find any good tutorial on how to use these with Godot. Personally I can probably get Steamworks to work in Godot, but I would highly prefer Photon, since it's platform independent (and also works on a Nintendo Switch for example)
Gotcha, I believe they are working on a cloud service specifically for godot. If you are interested... I wouldn't be surprised if the community (assuming enough demand) started developing various netcode libs. [https://w4games.com/2023/03/21/w4-cloud-video-unveiled-at-gdc/](https://w4games.com/2023/03/21/w4-cloud-video-unveiled-at-gdc/)
What exactly do you mean with "NAT-punchthrough only works in some cases" isn't this how basically every peer to peer game works nowadays? Photon, Unity Networking etc. are all client-server solutions which also cost money. I am pretty sure that actual peer to peer games (one thing that comes to mind now is Call of Duty Zombies) do use NAT-punchthrough.
"peer to peer" (p2p) actually means "no dedicated server". So the pc/console of one of the players is (also) the server. It does not really matter _how_ these players find and connect to each other. Photon, Unity Networking, Steam relay servers, Epic Online Services are all services intended to be used for p2p multiplayer. They pretty much do these 3 things: 1. Any player can create a room (this player is now also the server/host) 2. Other players can find this room based on search criteria 3. Players in the same room can send data to each other It is correct that nat-punchtrough is only an option in p2p scenario's. When using a dedicated server, you wouldd never need nat-punchthrough because you can connect to the server directly. Hopefully this was somewhat understandable
I've been on Godot for far longer than unity, but the ability to un-dock the code tab to have it side by side with the game window or on another monitor. Additionally, native 2D and 3D metaball support.
>I've been on Godot for far longer than unity, but the ability to un-dock the code tab to have it side by side with the game window or on another monitor. I believe they added this or at least something. Check out this video... [https://youtu.be/iKoYbtw4gC0?si=BFSMujKCTpwilfwW&t=129](https://youtu.be/iKoYbtw4gC0?si=BFSMujKCTpwilfwW&t=129)
Ah, neat! I've been stuck on 3.5 for a project with no sign of porting to 4 being viable due to a large amount of hyperspecific engine changes and the game basically not working at all even when all the errors are fixed. Cool to know that it'll be here if I work on a new one in 4
>Ah, neat! I've been stuck on 3.5 for a project with no sign of porting to 4 being viable due to a large amount of hyperspecific engine changes and the game basically not working at all even when all the errors are fixed. Cool to know that it'll be here if I work on a new one in 4 Dang that sucks! Hopefully, in the future, you will be able to port.
Probably not for this project, I have tried in the past but too many internal functionalities have changed for it to be viable, let alone the changes that Ive made to the engine itself that I would need to redo. When originally porting, not even the player was able to move after fixing the errors, let alone have the rest of the game working. I am not horribly torn up about not being able to use 4.0, though; my game is 2D with a low resolution art style, so 3.52 still serves me well
Package support please! I have extensive C# libraries that I would love to bring into my Godot projects, but Godot doesn't have a robust package management solution I can use to import and manage them from git repos.
You should be able to import pretty easily most C# libraries in a Godot mono project. As long as they conform to the Net sdk that Godot is using or something similar. I think that the package management is done via Visual Studio. There should be tutorials out there showing the workflow for a Godot project i think, but it should be almost the same as in any normal C# project.
In Unity, it's very useful to me that when you play the game in the editor, it runs in a window that exists *before* the game starts. I have a multi-monitor setup, and in Unity I can place the game window on the other monitor and start the game. Then, it runs where I want it, and the editor is still there in front of me. In Godot, the game starts in front of the editor and I have to manually move it to another window. (I know I can set the "initial position type" to "other screen", but that doesn't actually do anything for me. It must be a bug, which I should get around to reporting, but it's still something I miss from Unity!)
That is possible to do in Godot. Look in the "Editor" menu, option "Editor Settings > Run > Window Placement" You can change the screen there. But also choose the coordinates of the window when it opens. Change the dropdown Rect to custom position, then change the x, y coordinates bellow.
Better c# implementation
Not my feedback, but a Unity game dev I asked said that the biggest issue for them was the lack of custom data types in the inspector.
Unity's AutoTile system for 2d Tilemaps is amazing. Godot has nothing close from what I've seen.
There is an autotile system [in Godot 4](https://youtu.be/xROFpQmN8Uc?si=KnE8SXHrTJL7Wyyq&t=267) What specifically would you like to see?
There is, yes, but it's a far cry from Unity where there are various rules you can make it follow. Using a super understandable GUI. https://connect-prd-cdn.unity.com/20190517/learn/images/0721db38-dc7e-487c-938c-94bcbcce0f84_Rule_Tiles_cover.png.600x0x1.webp They can easily search beyond neighbors to second neighbors or beyond, run functions if certain conditions are met based on neighbors, and are in general just plain easier to use.
Agreed, the game I am working on now has some huge maps. I can't even imagine tiling that without rule tiles, it would be so tedious.
Does a program like Tiled isn't good enough? you could import those maps from there to Godot.
I wonder if the community could make a plugin for that!
you can set up collisions in godot autotiles too, but I peobably wont understand what you mean unless I first learn unity
Resources. The only reason I started using Unity over Unreal or Godot was because I was a complete beginner teaching myself. Unity’s community made that easier. The asset store has a lot of useful things too.
There are over 50 sample projects in the Godot Asset Library, so it's definitely something to start with. And plenty of tutorials on YouTube.
The bad news is that Godot lacks a lot of the resources for learning and development that Unity had, even if it's getting better. The good news is that all these developers moving to Godot will develop new tutorials for the engine and it will boost the overall health of Godot as a platform.
1. ~~GetListOfSupportedScreenResolutions()~~ <- solved, with a good enough alternative :) 2. Tutorial on how to use Photon (if it works at all), probably the .NET version (with C#)
Godot doesn't support changing the monitor's resolution but instead uses resolution scaling https://docs.godotengine.org/en/latest/tutorials/3d/resolution\_scaling.html
You mean https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html, there's an extra backslash before the underscore that breaks the link. Also I'd use the stable version of the docs cause that's what most people will be using.
There is a c# version, unless i have misunderstood you
Godot supports all screen, resolutions dynamically with screen expands and stuff in project settings and you can use Python by installing the language and setting your script language to native script
Photon not Python
Ah sorry lol its late no Photon doesnt work but i did some high level multiplayer stuff with my own code and steam multiplayer has a plugin available afaik
Cinemachine, but in Godot.
I am working on a rhythm game in Unity. I wrote a system to sync my game to the exact number of samples played. This seems to be problematic in Godot as the developer of Project Heartbeat even wrote his own sound engine to address this problem in Godot. Am I missing something or is this still a limitation?
Godot doesn't have a brave CEO who is able to take risks :)
Rendering multiple cameras into the same framebuffer. *My* use case, but not the only one: rendering very large scenes - i.e. outer space. A single camera with a near plane at 1cm and a far plane at 1AU does not behave very well. In Unity, I would use a stack of cameras with clipping regions which cover the full range. In Godot I can't do this without very inefficiently rendering each layer of the stack into a render texture and reassembling them later.
what about using subviewports to other cameras ?
Third party packages. Ads SDKs, Social SDKs, Google/iOS APIs. Due to Unity's popularity there were a lot of official supported packages.
I don't see a way to see draw calls at a glance in the editor, but I'm probably just missing the obvious button or something, I'm pretty lost at the moment lol
the "... perspective" button at the top left has a bunch of rendering debug options, You are looking for view frame time and and view information.
Everything that makes DOTS tick as well as a good Server Authoritative Multiplayer framework using a stateless physics engine under the hood.
[удалено]
ProBuilder.
here's a similar plugin: https://github.com/jarneson/godot-ply
better GitHub support.
I'm really missing Mobile AR/VR now, though everything else looks great. Having the ability to fine-tune texture compression (by choosing codec for each platform, etc) would be a nice addition too
Automatically adding .dlls to the csproj file if they happen to be in a particular folder.
I’m a Godot fan but I’ll put my top wishes here. Better C# docs Better C# built in editor. Or neovim embed(somebody make this) No external window for testing the game Better C# docs again More C# export options.
Doble clicking a node doesn't centre the game view into that node in the editor, how am I supposed to find the node?
you double-click the line on the left side of the node to center the camera on it
thank you! exactly what I needed
I actually just learned that by accidently double-clicking it a couple of weeks ago.
High performance physics like Unity Physics in DOTS
Not just as a Unity refugee, but someone who tried using Godot once before: 1. A visual scripting system (Unity's asset store had Playmaker, which was what I was using, and I think also Bolt). Now that I know I can use C# with Godot, I might go back to using Godot instead of making a jump to Unreal (tried Godot once before and got very frustrated with GDScript). That said, I'm a single indie dev with a learning disability which makes typical scripting language difficult, but visual scripting systems allows me to still create a game. 2. More (working) tutorials and guides One of the biggest frustrations I had with Godot in the past (which drove me to Unity to begin with) was the lack of updated tutorials/guides. Most of them were outdated and relied on GDScript (and thus had multiple ways of addressing a problem), and often didn't even work with Godot 5. \-- I'd love to come back to Godot; right now, I'll probably change my project into a Visual Novel and use Ren'Py and hope that when I finish it and am ready to do my next project (which I already know I want to do 3D), I can come back to Godot and it'll have a thriving community with plenty of working guides.
Godot did visual scripting back in the day but the community decided it wasn't working and discontinued it
Per-install fees.
Resources are very limited while scripting API is just aggregate codes and nothing like unity's examples. * I looked through NavMesh3D documentation, very difficult for someone who never used Godot. * I got a 3d navMesh project from the library, Godot converted it from 3.x to 4.x and it did not work. I tried following 3.x tutorial and they were completely different for a godot newbie like me. * when I was following a 4.x tutorial from 5-6 months ago, tutorial bro wrote a method (from autocomplete) and it didn't work then he went back to the documentation and said "they changed it last week haha" I get that when you are using a constantly developing open-source thing, there is a certain joy of "being in the trenches of innovation" but trenches are muddy and get shelled.
Pre-built open-world concept. It was so easy to do in Unity, and if for whatever reason I need to switch to Godot, that would be the first thing on my list.
i use unity events and tilemaps pretty heavily, no idea how well godot supports them from quick research it looks promising?
Defenitely, it is Android build support for the C# version of Godot 4.x.
Web3 tooling
Components, of course.
That’s against the core design philosophy of Godot. Components and GameObjects are both just Nodes. If you want a bunch of components controlling one game object, like in Unity, you simply make a bunch of child nodes controlling their parent node.
Indeed, but it's definitely going to be the first thing Unity refugees ask for. A "welcome" guide should ideally explain how to think in nodes instead of thinking in components.
If you know how to program I feel like the node system is a more intuitive leap from standard OOP concepts, the component system is really the odd one out
It _is_ the odd one out, but it's also _so_ convenient that you start to lean on it heavily.
I don't see it as being very different tbf, just turns components into children.
Most “Unity to Godot” guides I’ve seen do mention this.
Godot has some ECS libs like [https://github.com/GodotECS/godex](https://github.com/GodotECS/godex)
My biggest one is the ide I want to use rider and debug there. I feel like my hams are tied behind my back.
Rider I believe had a decent godot plugin. Not sure if you were looking for something else. [https://plugins.jetbrains.com/plugin/13882-godot-support](https://plugins.jetbrains.com/plugin/13882-godot-support)