Being an artist is one thing, but don't be an "ideas guy".
I second this notion. Everyone has ideas; few have the capacity to realize them. A design/director position at a game studio is assigned to developers who have experience implementing previous ideas and systems. A dedicated "ideas guy" is extremely corpo, and would have been infeasible decades ago when game companies were a tight-nit group of nerds who all contributed to a game in multiple ways.
If you can't code, you're not a game dev. You inherently lack the understanding as to how a game technically works—understanding that would inform the validity of your ideas.
Learning to program is learning a series of computing concepts that build upon each other. I recommend starting with Java, C#, or Python. Don't pay for online courses or bootcamps; codecademy.com has an abundance of free courses, and other such resources exist. Once you learn the core concepts of programming, learning other languages is simply a matter of learning the syntax. However, programming languages are not like speaking languages, it isn't merely about choosing your favorite one to write in. They are designed for specific use cases, and should be leveraged accordingly.
Unity uses C#
Godot uses GDScript (It's similar to python) or C# (don't bother with it here, just learn GDScript)
Unreal uses C++
All of these also provide visual scripting, which abstracts the coding process, but it's neccessary to understand tradition programming before using this.
Previous posts in this thread have mainly focused on these big three. Each of these engines have demonstrated caveats to their utilization, but I've yet to see many alternatives (especially in 3D graphics) be provided.
I am personally dissatisfied with UE5's forward rendering with its limit of 4-light intersections, botched emmisive materials, and lack of support for screen space techniques. I would consider using deferred rendering for this project, but Lumen, TAA, and their associated destruction of image clarity is something I cannot tolerate. Unity provides a much more flexible forward rendering solution that would solve these problems, but the Unity debacle has me questioning the long-term support of their engine. I decided to research alternative engines, taking into consideration pricing model, developer support, and available features. I'll need to tinker with each of them to make any sort of decision.
O3DE
C++/Python
Linux Foundation subsidiary
Interestingly, this engine is derived from CryEngine, temporarily liscensed by Amazon as Lumberyard, then rewritten as O3DE because Amazon is shit.
Seems to prioritize rendering, includes physically-based rendering
Stride
C#
Supported by .Net Foundation (Supported by Microsoft)
Similar to O3DE in terms of major features.
Panda3D
C++/Python
Appears to be a lightweight, community-driven project.
Armory
Full blender integration, which could be a godsend in terms of providing a seamless workflow.