Jump to content
  • Advertisement
Sign in to follow this  
TTT_Dutch

I like the product of programming but not the process -- help?

This topic is 2233 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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! smile.png

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Well you guys provided very helpful advice and I thank you very for that, but please let me rephrase my question. :D

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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!