12 replies to this topic

[Riztro]

So I really enjoy creating things via programming and I like making minor modifications in my code and others code to make cool things but I don't like the actual serious programming part..

I can program just fine if I have a small project that is very incremental and easily visualized. I run into trouble when I need to write things like a renderer for a game which requires a lot of code to get any sort of usable or visible product. I can't visualize it well and I really just don't enjoy programming it which really affects my productivity.

So I am wondering, what can I do to be happy and enjoy the actual code and appreciate what the code says and learn to enjoy for example programming the mesh building function of a rendering class and not just the mesh that the code will output?

I hope I made sense!
Thanks,
Brent

[EddieV223]

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.

[jbadams]

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!

[Narf the Mouse]

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.

Edited by Narf the Mouse, 30 September 2012 - 08:02 PM.

[Midori Ryuu]

Either use libraries and frameworks to abstract that work for you, or you can always try going into modding games! There are even games like Starcraft 2 for example that come with a GUI for making mods.

[Goran Milovanovic]

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.

[Narf the Mouse]

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.

True, but it's definitely easier than writing a full indie game yourself.

[TheChubu]

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.

[Riztro]

Well you guys provided very helpful advice and I thank you very for that, but please let me rephrase my question.

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.

Thank you all!

[Cornstalks]

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?

[BCullis]

How do you get to the point where you get a feeling of satisfaction just from writing good code?

Iterative development helps me. I'm working on a considerably big project for one person, even if it's tightly scoped. If I was basing my enjoyment on seeing it complete, I'd never get anywhere. Instead, I iterate on as small of a working codebase as possible so that I can successfully compile and run and see my changes impact the product.

Even in your example of writing a rendering framework being tedious: there's no reason for the renderer to be feature-complete before it can compile. My first step was just getting a window to show up with a black screen. Then I got a triangle to show up. Then I grabbed a pre-built model and got that to 1) show up, and then 2) show up without depth bugs. Each step came with the high of having solved a problem with code.

Granted, I had a little extra work on the first cycle getting some of the "slottable" framework elements in place, like when I wrote the code that renders with an arbitrary shader. That was a longer push, but the "hard parts" are all about discipline anyway. Now, with that part of the framework written, I can sit down and program/tweak a single shader and test it in my game rather quickly.

Someone mentioned above as well, that part of this will come with time: as you get more experience, what takes you a week currently might only take you a day or a handful of hours in the future. Experience will also let you set more appropriate milestones and goals. I generally try to aim for only what can be done by the end of the day, and it keeps me focused, productive, and amused, because I get to fully solve the bite-sized problems I've selected more often than if I was just pursuing a month-long task.

TL:DR: set shorter goals and you'll be able to enjoy the fun of solving them more often, keeping your morale up.

[Goran Milovanovic]

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 use a version control system (git) to track everything I do, and I can say that reviewing the commit log (from time to time) can be very encouraging.

I would typically look at my history for the past week, and see that I've made considerable progress, which would keep me motivated to make further progress. There are weeks where I'm not nearly as productive, but whenever that's the case, I just look further back.

[Narf the Mouse]

Well you guys provided very helpful advice and I thank you very for that, but please let me rephrase my question.

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.

Thank you all!

Also, I may get yelled at for this, but is programming really what you want to be doing? You don't want to be twenty years down the road, in a job you hate.