Get rid of these annoying ranks.,
Members - Reputation: 122
Posted 13 January 2000 - 07:48 AM
Members - Reputation: 440
Posted 13 January 2000 - 07:54 AM
-prone to help or respond
-have been around long enough
While I don''t recomend taking advice based on the ranks, I do suggest that you respond in those cases where somebody is wrong on their advice. The only way for that person to learn their mistake is if somebody informs them, or shows what they believe the proper way is.
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?
Posted 13 January 2000 - 08:58 AM
"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.
Moderators - Reputation: 11407
Posted 13 January 2000 - 09:39 AM
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.
Distinguished Rhino - Reputation: 2312
Posted 13 January 2000 - 10:18 AM
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.
Members - Reputation: 128
Posted 13 January 2000 - 12:02 PM
> constantly to support seemingly trivial things which
> make the architecture streamlined.
One could just as easily say *this* is why most games are late.
There's a balance between hacking something out and making something elegant, and releasing a good game on time requires you to walk that line very carefullly. I guarantee that every commercial game out there has been hacked together just as much as it has been elegantly designed.
It's silly to say that "too much" or "not enough" hacking is why most games are late. Reality is much more complicated than that.
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
Edited by - mason on 1/13/00 6:03:54 PM
Members - Reputation: 122
Posted 14 January 2000 - 01:40 PM
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).