I want to make games, but I don't have many ideas for 3D games, and I plan on making a game in which all the characters are stick figures. I've watched a few Unity tutorials, and I don't want to have to deal with all that asset hierarchy nonsense. Plain code is a lot easier to understand. Also, Minecraft and Terraria (The Best Game Ever) were both made with raw code and no external game engine. Is this a good path to continue on, or should I try to understand Unity? (By the way, I won't ever use normal maps. They're very ugly.)
I'd say stick to blender, but if your pro go ahead and learn as many programs as you can!
How committed are you to learning advanced programming? Because using no external game engine would mean that you have to code your own: asset manager, sound manager, collision detection and anything else that you want to add to your game that in an external game engine you could just press a few buttons to achieve. Especially if you are not experienced with those things, you'll spend a long time coding the foundation before you even can start on the actual game. Sure, there are some game APIs out there that will provide a lot of functionality for you. If you just want to focus on creating the game itself, I would suggest using some external game engine like Unity or the like. But if you are interested in learning how everything works down to the nitty-gritty, and you're willing to put in the effort and time, coding everything from scratch can be very rewarding.
I dont know what you are saying Markus, but William you can make games with Blender, there are tutorials on this website for that i.e. the Tank Game.
The real question is do you want to learn to program?
If so, in what language?
Godot supports both 2D and 3D natively, is free and open-source and you can also use C# and C++. It is my recommendation for learning and solo production for those who aren't already C#/C++ programmers (I know C++ and prefer Godot, but I also love UE4). CG Cookie should seriously look at it for future game tutorials.
If you want to use "raw code" and not use a game engine, you're going to waste a lot of time creating your own custom engine to handle input, render graphics, manage sound, load and save files, etc. It is a huge mistake to not use a game engine. The only practical exception to this is if you are already a programmer, love to code, and are more interested in making a game engine, than a game. Using one of the above engines will allow you to focus exclusively on your production pipeline and content; making assets in blender and creating game logic in the engine.
As far as having no ideas to make games, or if you're not a great programmer, there are thousands of other game developers looking for a team. If it turns out you are terrible at coding but good at making blender assets, you'll still find many people wanting your help. It is best if you have multiple skillsets. e.g. know a little code, familiar with a game engine or two, and then master a craft like blender. Then you can properly prepare your assets for others to use and even set them up inside the engine so the programmers don't even have to think about it, they can just reference the asset and play the animation.
Look at joining a game jam (itch.io/jams) and as you make games with people you'll find teams to work with on bigger projects.
Which of those game engines uses the least number of weird asset trees? I just want to add in the models and textures and start coding.
I haven't used Unity much, I don't like the interface and don't know C#. UE4 is a beast. Godot overall is much simpler, but it seemed too simple at first because it seems like everything is hidden, but if you work through the tutorials you'll eventually know where everything is. For me now, it's no big deal to drop an asset into the file browser panel, move it from there into the scene. Which you can also do in UE4. Godot is simpler to learn, but you'll still have learning to do on any engine. However the learning and coding involved in not using an engine is 100x more.
I like code, though. Typing in
if mouse_clicked:
player.swing_sword(mouse_x, mouse_y)
makes a lot more sense than adding some weird mouse trigger.