The ranks of people posting are highly misleading. The titles of the ranks imply some knowledge of game programming ("guru"??!?!?), but instead their meaning is directly correlated to the persona''s number of posts. Newbies who look through this page for advice are bound to run into posts from "zealots" and "gurus" (whatever the names are) and think highly of the responses. However, a majority of the time these posters are giving bad advice, horrible implementations, and at times completely invalid information. I would take a guess that many of these posters are high school kids who fanatically post replies when they barely have any grasp of the concepts underlying proper procedural and OO design let alone the myriad of other concepts which form a game. Understand that I have no qualms about people learning to program games and their enthusiasm to do so; I (and other professional game programmers) were all once at that same stage. However, I do object to a forum which I believe encourages the "blind to lead the blind." I think newbies helping other newbies out is integral to the learning process. Just remove the labeling system so newbies can''t hide behind titles.

Hmm...

"As for implementation, the basic rule is usually if it works - go for it. Sometimes I really don''t care if it''s the prettiest looking code, or the easiest way to do something - the question is does it work?"

This type of mentality is fine (and probably good) for people beginning programming games. However, for large scale professional games this is IMHO the biggest reason for their long times in development and the crappy bloated code which is the result (and their cancellation / and/or failure). My friends commonly refer to this as "shotgun" programming. I.e. those who instead of thinking of the elegant solution just sit down and hammer out code (sometimes even guessing to the solution) and run the code multiple times to _see_ if it works rather than looking at the code and _knowing_ it works.

I cannot stress the importance of writing an _elegant_ engine. I rewrite major sections of my engine architecture constantly to support seemingly trivial things which make the architecture streamlined. Once you start letting the architecture deteriorate hacks start sinking in and before long you have a huge big mess in which when you fix one bug five more crop up because of the interlinked-hacked mess which was once an engine. I spend hours every week lining up code stylistically and renaming functions to be more mneumonic. The major modules which handle object interactions (i.e. the interface to my engine) all look like very nice API files with highly commented code and functions which share common naming conventions.

[rant]With proper object oriented design, the "hacks" can be isolated from other more elegant code. Once it''s isolated you can work on getting the product working and then going into your implementations to clean things up, without bringing the whole project down to its knees. If you get a large enough code block from the someone else that you can''t isolate by object coding, then you''re not really a professional.[/rant]

I''ve seen a forum where a moderation method was implemented. *cough* slashdot *cough* The end result was that it enforced a certain kind of thinking. If you didn''t toe the party line, even if you had good points, you were moderated down. This kept others from picking up on the good points. In this board any registered visitors could moderate. The alternative, staff only moderations, was impracticle due to the volume of traffic they were getting.

So I guess the only way you can deal with seeing bad advice, bad implementations, or just outright wrong statements, is whenever you see something, post yourself, and you''ll soon get your rank up there so that you''ll have the influence to sway opinions as well.

I personally have seen poor implementations and perhaps bad choices of function calls (deprecated API entries for example) but only rarely something outright wrong. There are plenty of professionals and real programmers out there to mitigate the "blind leading the blind" effect. They can (and will) blast anyone posting outright bad information. As for me, as long as don''t see "real programmers only use FORTRAN" I''m happy.

Back to the original post...

The current user levels were chosen specifically because they don''t reflect a level of knowledge, but rather a level of dedication (read: activity). "guru" is not among the current titles for that very reason.

Regardless of titles, I think many newbies are likely to believe ANYTHING they are told, regardless of the source, so removing the user levels wouldn''t help that much. Of course, spreading misinformation is a serious problem, so we have measures in place to prevent that as much as possible. The main one is that we have moderators who are knowledgable in the subject they moderator who are supposed to keep an eye out for that kind of thing. The members of the GDNet staff also look at almost every post that''s made. We have a couple of other things in the works too.

*Shrug* people can tell me hacking is acceptable all they want.

It is not a practice all game programmers follow. I might lose some time reworking my architecture but I can honestly count the number of hacks in my game engine code on two hands. If you have ever worked on a AAA project with multiple programmers from the genesis of the idea to the end you know that doing it the "right way" might suck _now_ but you will be thanking yourself six months down the road when one change to the game pipeline screws half the game up.

I think the trend towards properly engineered engines is increasing while companies with old-school shotgun programmers are going to start having difficulty. Software engineering costs are climbing and unless companies can engineer reusuable, solid code they will find rewriting projects from scratch each time both cumbersome and cost-prohibitive.

There are few times and places for hacks. If you run across something that needs to be hacked a majority of the time this means you didn''t think your design through. Instead of pushing this hack on your system, I advocate rewriting it. If you don''t you might end up hacking on a hack and then eventually you will have a big mess.

Caveat: Hacking is less a problem the smaller a game gets. My opiniion mainly revolves around my experience recently (~1-2 year AAA games).