I have 4.5k lines of code and no clue

[george]

How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?

[kraflab]

How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?

I agree with this 100%.  The only way to uncover a more productive programming paradigm is on your own, since no one else is you

[requerent]

How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?

Disagree completely. You learn to program from somewhere. Even if you pick up a book and teach yourself, you utilize the techniques and paradigms within. Self-taught programmers typically learn procedural programming. A little bit of education and you learn about the invariably superior advantages of OOP. Then you typically discover that your hierarchy is unwieldy and the overhead is too large, a bit more education and you learn about aspect-oriented or component-based design- etc. Then you have development/design methodologies like test-driven, agile, black-box, SOLID etc.

Different models are better/worse for different degrees of complexity and applications. There are some that are generally bad in that they result in poor maintainability and difficult debugging.

Experience and education have dual-importance in the improvement of your expressiveness and productivity. A lot of research has gone into production methodologies/paradigms that don't really trickle down to introductory programming.

A few lists worth looking at to get an idea of the creative solutions people have come up with.

http://en.wikipedia.org/wiki/List_of_software_development_philosophies
http://en.wikipedia.org/wiki/Programming_paradigm

If you search "Is ____ good for games?" on google, you'll get a lot of interesting perspectives.

[kraflab]

How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?

Disagree completely. You learn to program from somewhere. Even if you pick up a book and teach yourself, you utilize the techniques and paradigms within. Self-taught programmers typically learn procedural programming. A little bit of education and you learn about the invariably superior advantages of OOP. Then you typically discover that your hierarchy is unwieldy and the overhead is too large, a bit more education and you learn about aspect-oriented or component-based design- etc. Then you have development/design methodologies like test-driven, agile, black-box, SOLID etc.

It's silly to talk about "typical" things because you just have to make too many assumptions.  I'm totally self taught and I have a completely different perspective from the one you provided.  The "typical" anything doesn't exist, so there's no reason to talk about them My anecdotal evidence is just as meaningless as yours though.

Programming paradigms aren't magic secret codes.  They're an obvious manifestation of the underlying systems.  You don't need to read a book or check online to know they exist.

[requerent]

How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?

Disagree completely. You learn to program from somewhere. Even if you pick up a book and teach yourself, you utilize the techniques and paradigms within. Self-taught programmers typically learn procedural programming. A little bit of education and you learn about the invariably superior advantages of OOP. Then you typically discover that your hierarchy is unwieldy and the overhead is too large, a bit more education and you learn about aspect-oriented or component-based design- etc. Then you have development/design methodologies like test-driven, agile, black-box, SOLID etc.

It's silly to talk about "typical" things because you just have to make too many assumptions.  I'm totally self taught and I have a completely different perspective from the one you provided.  The "typical" anything doesn't exist, so there's no reason to talk about them My anecdotal evidence is just as meaningless as yours though.

Programming paradigms aren't magic secret codes.  They're an obvious manifestation of the underlying systems.  You don't need to read a book or check online to know they exist.

I'm just saying that it is ignorant to dismiss alternatives when there is a wealth of experience condensed into easy-to-follow techniques. Saying they're "obvious" is a little ridiculous.

[Krice]

It's silly to talk about "typical" things because you just have to make too many assumptions.  I'm totally self taught and

Typical way for a young programmer is thinking that whatever he is doing is right. You need to be a little bit scientific mind to forget your ego and start gathering analytic information and experience from programming. It's good to remember that things like OOP were not invented by accident. They actually needed OOP in large scale programs and it was designed that in mind.

[kraflab]

It's silly to talk about "typical" things because you just have to make too many assumptions.  I'm totally self taught and

Typical way for a young programmer is thinking that whatever he is doing is right. You need to be a little bit scientific mind to forget your ego and start gathering analytic information and experience from programming. It's good to remember that things like OOP were not invented by accident. They actually needed OOP in large scale programs and it was designed that in mind.

Most programmers I know are pretty sure they know what they're doing is wrong

[Ancient]

This is always the problem, the best/quickest developed roguelikes are "bad" code, cobbled together at light speed. My "quick-hack" code is full of singletons, static variables, and if I want to do something I just do it and I dont really care where it goes - that way you can get the job done.e a game.

This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?

The code for @Star Wars is quite messy and poorly documented. I'm wary of going open source for those reasons, but it still works, which, at the end of the day, is all I can really ask for. I contemplated the idea of giving up @Star Wars or restarting from scratch numerous times, but eventually I was able to work out most of the major kinks and got everything in place that I needed to really start working on the game.

Grepping my source directory for "goto" returns 66 matches. That might be a signal my code is sloppy. Never stopped me from publishing the sources.

Yes, I put a lot of hacky and decidedly "evil" solutions into the program. The high rate of bugs in PRIME is partially a reflection of this. The code is full of unneeded globals, too many statics and whatnot. Well, except singletons but that is mostly stems from my commitment to data driven paradigm over OOP.

[TheCreator]

This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?

No, luckily it isn't. Some people (including me) would write the code first and start to think about any possible improvements much later. I'm unable to design anything without an existing code. It's just like sculpting, you can't create a sculpture out of nothing. Bad code is not necessarily a bad thing - it might as well be a raw block of stone that needs further efforts to become a masterpiece. I think that many programmers are missing this point.

On the other hand, I have recently found out that writing tests first (so called test-driven development) really helps to produce working complex code that would be otherwise very hard to get right. Once the test cases start to pass, your code is probably working. It's that simple. However, I doubt that it would be equally simple for a newbie programmer.

[Krice]

Grepping my source directory for "goto" returns 66 matches. That might be a signal my code is sloppy. Never stopped me from publishing the sources.

Good old goto:) It's not bad if it works and causes no bugs. Even Kaduria has 7 gotos, although most of them are relics from ancient times...

[roocey]

This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?

No, luckily it isn't. Some people (including me) would write the code first and start to think about any possible improvements much later. I'm unable to design anything without an existing code. It's just like sculpting, you can't create a sculpture out of nothing. Bad code is not necessarily a bad thing - it might as well be a raw block of stone that needs further efforts to become a masterpiece. I think that many programmers are missing this point.

On the other hand, I have recently found out that writing tests first (so called test-driven development) really helps to produce working complex code that would be otherwise very hard to get right. Once the test cases start to pass, your code is probably working. It's that simple. However, I doubt that it would be equally simple for a newbie programmer.

Well, I can hardly consider myself to be a proper programmer. Perhaps its immature, but I did start off with the sole intention of creating a game. Learning how to program and all the related intricacies are secondary stepping stones - necessities probably, but secondary in my mind. Though I have to say after working with it for a couple years now, I've started enjoying programming more. It's quite satisfying when everything comes together and works as I hoped it would.

Grepping my source directory for "goto" returns 66 matches. That might be a signal my code is sloppy. Never stopped me from publishing the sources.

Yes, I put a lot of hacky and decidedly "evil" solutions into the program. The high rate of bugs in PRIME is partially a reflection of this. The code is full of unneeded globals, too many statics and whatnot. Well, except singletons but that is mostly stems from my commitment to data driven paradigm over OOP.

I'll have to consider just publishing my source someday in that case - maybe someone can learn from my mistakes.

I'm glad I got two responses with somewhat opposed points of view. I suppose that proves my original theory wrong.

[requerent]

This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?

No, luckily it isn't. Some people (including me) would write the code first and start to think about any possible improvements much later. I'm unable to design anything without an existing code. It's just like sculpting, you can't create a sculpture out of nothing. Bad code is not necessarily a bad thing - it might as well be a raw block of stone that needs further efforts to become a masterpiece. I think that many programmers are missing this point.

I think this is true when it comes to implementing rules and gameplay- but honestly, there are a lot of important things that you don't need to do this with. Keeping rendering and logic separate becomes rote after you're taught that way or discover that porting to a new rendering framework is a PITA otherwise.

With a proper framework, you can have discrete state/session management that allows for replaying and saving functionality (and analytics), you can have cross-platform compatibility, interface with many renderers, and... well, the list goes on. If you don't have a proper framework and desire these features at some point, you're probably looking at a complete redesign. You can include test-driven development or any other preferred set of techniques if you set your boilerplate up that way- but they don't emerge from working on a project half-way through without a lot of avoidable problems.