I am going to suggest the opposite: subject yourself to more constraints. Try programming on a retro-fantasy console like Pico-8 or some of its free alternatives.
I found the (sometimes ridiculous) restrictions very liberating. In exchange you get raw immediacy. I want a game with a chicken on it. I spend doodle something with the 8-bit 8x8 bitmap editor. I draw it with 1 line of code, 4 more lines to control with the arrow keys. Total time: maybe 2 minutes.
This radical immediacy is something I really missed in more unconstrained environments. I would get analysis paralysis "should it be a male or female chicken? what shader should I use to properly render the chicken wings when there's rain".
Developing an actual game on PICO-8 is like solving a Zachtronics puzzle. Appealing to a small subset of developers who enjoy hex editing, hacking, and squeezing performance out of a limited system.
But if you're more artistically inclined, you will only find frustration where PICO-8 flaunts its "cozyness". It imposes completely arbitrary and unnecessary restrictions where there should be none. These restrictions will become a brick wall you eventually hit, and then you have to start peeking and poking raw memory with hexadecimals like you're programming in fucking C, or just give up trying to make the game you wanted to make.
I realize that this might not be for you, and that is fine. I must object to the “arbitrary and unnecessary” part. You might not agree with the reasons, but there are reasons for the restrictions.
I also want to say that I think of myself as actually very artistically inclined. An 128x128 screen in 16 colors is just a medium. You prefer other mediums and that’s fine, but the implication of “Pico-8 isn’t for artistic people” is simply not true.
You're talking about surface level details and artistic choises. I'm talking about the underlying workings of the engine, and the strangling limits placed thereupon. Limits like token count, which only serves to force you to "optimize" your code somewhere along development of your game because you suddenly "run out of words" to code a new feature you just thought of. Then the framework turns from "helps you make games quickly" to "grinds your progress to a halt because REASONS". Or if you wanted to make another level, the creative artist you are, but there's just not enough room in the map editor, so now you have to plug in a data compression library and lose access to the built-in map editor!
Perhaps contraints was the wrong word, as I absolutely agree. Maybe constraints of the workflow is a better way to say it, though I'm not sure there are any, I just want to try a framework and see if it suits me better.
But back on your point, yeh pico-8 is fantastic, like the game dev equivalent of a pocket operator for music. I never quite got the hang of it, but I do want to try it more, it seems like it'd be fantastic for prototyping, and maybe actually itself gives a decent idea of the code-only workflow Im looking for.
I am going to suggest the opposite: subject yourself to more constraints. Try programming on a retro-fantasy console like Pico-8 or some of its free alternatives.
I found the (sometimes ridiculous) restrictions very liberating. In exchange you get raw immediacy. I want a game with a chicken on it. I spend doodle something with the 8-bit 8x8 bitmap editor. I draw it with 1 line of code, 4 more lines to control with the arrow keys. Total time: maybe 2 minutes.
This radical immediacy is something I really missed in more unconstrained environments. I would get analysis paralysis "should it be a male or female chicken? what shader should I use to properly render the chicken wings when there's rain".