Get a large white board or two and draw out with color markers the structure of what your trying to visualize. This is how the pro's do it, among other ways, learn from them.

Firstly, if you don't enjoy it you can still make games (as long as you have reasonable expectations) without programming at all: how to make video games without programming, more ways to make games without programming.

You could also consider moving to an easier-to-use programming language and/or framework/engine that gets some of the bigger design problems and/or fiddly work out of the way for you. You could consider Love (Lua based), Python, or could try working with an engine such as Unity so you're not doing all of the ground-up work yourself and can concentrate on game-play.


Otherwise it sounds like you might still just be having some trouble understanding some of the code at a higher level. Diagramming how things function (as suggested above), or simply getting more practice might help with this. You could also try solving a wider range of problems such as those offered by project euler or code kata, or learning some different languages so that you are exposed to different ways of thinking about problems.


Hope that's helpful!

You could also make minigames for phones and such. Do well enough, and you could support yourself on a steady stream of cheap games.

Or it could just be you only enjoy programming as a hobby, not a profession. That isn't a criticism, just to clarify.

I don't like the actual serious programming part

You could partner up with someone who does.

You could also make minigames for phones and such. Do well enough, and you could support yourself on a steady stream of cheap games.

Emphasis on "well enough"; Even for a "steady stream of cheap games", there is a certain standard of quality that most are unable to reach. So, don't be fooled into thinking that it's easy, or something like that.

[quote name='Riztro' timestamp='1349052342' post='4985581']
I don't like the actual serious programming part

You could partner up with someone who does.

You could also make minigames for phones and such. Do well enough, and you could support yourself on a steady stream of cheap games.

Emphasis on "well enough"; Even for a "steady stream of cheap games", there is a certain standard of quality that most are unable to reach. So, don't be fooled into thinking that it's easy, or something like that.
[/quote]
True, but it's definitely easier than writing a full indie game yourself.

At least for me, it's an incremental process. Some programs that were really long and complex for me last year now are trivial for me and I can make them in a few hours tops.

The ability to not to get lost in the sea of code improves while you're trying to make sense of such things. Eventually you'll get the hang of it.

It is frustrating when you're coding something and in the middle of it you think "Wait, what I was going to do with this? Do these methods work as I think?" and you might go back and forth between all of that but you'll get better at it.

Write a way to test easily what you're doing so you can get more "instant" results (even if they're relatively small compared to what you're doing with the code as a whole), that way you won't need to be coding 3hs before hitting the build/compile button to see if it works, and you will be able to realize your progress directly.

How do you get to the point where you get a feeling of satisfaction just from writing good code? I don't want to have the finished product of my code my only way to satisfaction and happiness.

Well, if my code doesn't accomplish anything, yeah, I feel bored. I had a similar problem (still sometimes do), and I think what helped me the most was to do two things:

1) Rapidly prototype. If I'm making something new to me, and I'm not sure how it'll turn out (in terms of if it's even a good idea or not), I like to rapidly prototype it and quickly hack together a working, super simple demo that just shows the idea. This is nice because in a short amount of time, I can create something that actually does something, and I can play around with my idea and see what worked, what didn't, and what unexpected road bumps I hit while programming it. The key is remembering it's a prototype, not the real product, so I don't spend time making it pretty or adding the extra bells and whistles.

2) Break the (big) problem into smaller problems. Once I feel like I've got a good direction (after playing with my quick prototype), I essentially throw it away and start from scratch. The point of the prototype wasn't to serve as a starting code base; it was to serve as a solid foundation to build my ideas off of. I know a bit better what made the prototype fun/good/useful, and I can focus on the key elements (and go back and add the extra fluff another time) and how to design and set up the architecture for my actual program. But the big program by itself is huge, and could take years (of spare time work), so it's critical to break it down into several smaller problems that can be worked on. That way, I don't feel like I'm just endlessly writing code to no avail, but I can actually see my progress as I complete each sub-problem and (over time) see the solved sub-problems coming together to eventually form the whole program.

I guess what I'm really saying is that I love programming because I love problem solving and making cool things. If I just wrote code that never did/accomplished anything... I think I'd hate my job. So I had to learn to quickly prototype (to make a proof of concept that says "Yeah, this cool idea is indeed actually cool, and I can do it"), and then properly designing (this is the hard part for me, and I'm still getting better at it) the architecture of the big, real program and then decomposing it into lots of sub-problems that I can work on. I can see progress and results as I solve each sub-problem.

If you like programming, but not the process... maybe you should change your process?