Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / 8 Habits of Highly Effective Game Programmers [article]

Author
Message
zircher
21
Years of Service
User Offline
Joined: 27th Dec 2002
Location: Oklahoma
Posted: 7th Jan 2004 21:04
Something that I saw in the GIGnews letter...

http://www.gignews.com/careerfeatures/8habits.htm
Tasik
21
Years of Service
User Offline
Joined: 17th Nov 2003
Location: Canada
Posted: 7th Jan 2004 23:10
I felt about 6/8 of those applied for more then just programming stuff.
I have heard other people write very simular stuff. It didn't seem that original.

I also dont agree with the last one.
Quote: "
8. Establish a dictatorship, then silence your opponents. If your first project is a group effort, then decide who will become the project leader and quell any dissenters. Working in a group can be both a rewarding and disastrous experience. Although that's probably the subject for another article entirely, I will add that smaller teams tend to work best with a dictatorship. If everyone has an equal say, and all decide that they have the better direction for the project, then leave the team as, in the end, you risk accomplishing nothing.
"


I think that a group can have 100% equal say and still get the game done and sometimes better then a distatorship.

This sounds like its coming from some one who likes to have full power in a project.

My friends and I made a board game. It was kinda all of our idea and it stayed that way through the whole thing. We had no problems because we think the same way. If we disagreed with eachother then mabey it would have been better to have a distatorship but then why would you want to make a game with people who didn't want to make the same game? In my oppinion people come up with the best stuff if they have equal say.

(Although I shouldn't really be one to talk, I do almost every thing solo)

You should have seen that last fight! Out numbered 40 to 2... We beat them both =)
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 8th Jan 2004 12:31
Well, the guy that wrote that article has made a game, and asteroids clone...

IMO someone who has only just made their first game, then decides to educate the world on how to do it needs a dry slap. Besides, most of his statements are common sense - like:

Quote: "As you gain more experience developing your own game, you'll begin to see that most of your code is the same throughout every project. Rather than mundanely creating this same code every time, design some objects using C++ which you can easily port from project to project."


Might as well tell people that breathing helps prevent death.

At the end of the day, nobody can tell you howto finish a project, if you've got the minerals you'll finish it, if not - make sure you learn something along the way that you can take onto your next project.

Teams work best when they can deal with each other on a personal level, like a small team of friends is probably the most likely to be successful, when you respect the other members of the team you take their ideas seriously the whole team feeds on each others enthusiasm. Online teams can fail abysmally due to the slightest hickup.


Van-B


The nature of Monkey was irrepressible!.
Dave J
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Feb 2003
Location: Secret Military Pub, Down Under
Posted: 8th Jan 2004 14:42
Quote: "The first game is an elusive entity to most, diving and twisting out of range like that annoying (last) TIE fighter eluding your bursts of laser and screwing up your shot percentage in the process."


Damn Straight! *Gives X-Wing vs TIE Fighter box another kick*


The Design Document needs a bit more info though, ie, don't make it too strict or large. Here's two examples, John Romero's Daikatana game design document was massive and it barely scraped by as a finished product. On the other hand, Prince of Peria: The Sands of Time had a design document that was no more then 10 pages long and was made by a bunch of nobodies that have only made Donald Duck games. Design isn't law.

Number 8 is also a bit harsh. It's a scientific way of thinking, nobody want's to work in a team where they have no say, especially if it's everyone's first project. A definative team leader is a good idea but you should be open to suggestions from everybody. You wouldn't want a dictatorship at all.


"Computers are useless they can only give you answers."
zircher
21
Years of Service
User Offline
Joined: 27th Dec 2002
Location: Oklahoma
Posted: 8th Jan 2004 15:28
It's not my place to defend the author's views, but I'm glad that is has spurred some disscussion.

Having tried working with teams in the past, a dictatorship might be the wrong word for the very required personality type. The team leader needs to be vocal, have clear vision, and the drive and force of personality to execute the design plan. A team of developers that think alike and are on the same path are the happy exception to the rule.
--
TAZ

Login to post a reply

Server time is: 2024-11-24 14:07:22
Your offset time is: 2024-11-24 14:07:22