An article every new developer should read:
by Josh Albrecht · in General Discussion · 08/09/2004 (6:39 pm) · 13 replies
You want to make a game? Here is some EXTREMELY important advice:
frogtoss.com/index.php?content=finishingafullgame&dir=journal
If you dont believe what the author says, dont worry. You will after 6 months of working on your version of Doom 4. :)
frogtoss.com/index.php?content=finishingafullgame&dir=journal
If you dont believe what the author says, dont worry. You will after 6 months of working on your version of Doom 4. :)
About the author
#2
08/12/2004 (8:04 am)
I liked the article, but I also noted that these guys have never worked in the industry or actually released a finished title AFAICT. That hurts their credability a bit, though it seems like they have a very good grasp on what the problems are and what needs to be done.
#3
?
There's Rockstar, EA, Relic, Radical etc. in Vanouver, BC, so it's pretty likely these guys are AAA refugees.
08/12/2004 (8:14 am)
Quote:
I also noted that these guys have never worked in the industry
?
Quote:
Most of us have had careers working on full-budget, eighteen month "triple-A" titles for commercial game publishers, so we know the problems that dog the large teams, and we all have a deep yearning to enjoy making games without the majority of those problems.
There's Rockstar, EA, Relic, Radical etc. in Vanouver, BC, so it's pretty likely these guys are AAA refugees.
#4
Making games has resulted in too little sleep, I guess. I'll blame that.
08/12/2004 (11:09 am)
Okay, I must have been smoking something when I first read this a couple weeks ago. I vaguely remember reading the paragraph about how they didn't believe that you should have to work in the industry ten years to MAYBE get a shot at your own game.Making games has resulted in too little sleep, I guess. I'll blame that.
#5
08/12/2004 (2:12 pm)
Well, if you were in Vancouver, BC, smoking something would be the more likely explanation :-) .
#6
08/12/2004 (2:14 pm)
Not a bad article, but there seems to be a bias towards the programming side of the equation. I know (even with my exceedingly poor coding skills) that you need to get the very basics like memory management and I/O functions established before you get into the actual gameplay code. The tone of the article just sets on my teeth on edge. It fails to consider that there are some folks out there who are not coders by nature or even by training, and seems to give the subtle suggestion that only coders are the proper people to determine the development path of a game project.
#7
08/12/2004 (3:19 pm)
But if you are not a confident coder and you don't have access to a confident coder you're going to have a really hard time making a commercial quality game.
#8
Confidence does not always equal competence. :) There's an admittedly tiny little project I'm working on right now and I've got a coder who's very confident he can do the job, but his expectation is that I can actually deliver a working set of game rules that he can actually implement. Like I said, I know the I/O and basic functions are a necessity, but the ability to write computer code does not automatically grant the ability to design a good game.
08/13/2004 (8:48 am)
@BenConfidence does not always equal competence. :) There's an admittedly tiny little project I'm working on right now and I've got a coder who's very confident he can do the job, but his expectation is that I can actually deliver a working set of game rules that he can actually implement. Like I said, I know the I/O and basic functions are a necessity, but the ability to write computer code does not automatically grant the ability to design a good game.
#9
Of course, the ability to design a good game doesn't translate into the ability to implement a good game...
08/13/2004 (9:31 am)
Yes... bad choice of words, I suppose. :)Of course, the ability to design a good game doesn't translate into the ability to implement a good game...
#10
Ergo, be it known all would be up-and-comers, these are two of the great precepts of indie game development, as derived by Ben and Axel
1. The ability to write good computer code does not automatically grant the ability to design a good game.
2. The ability to design a good game does not automatically grant the ability to write good computer code.
Verily, so it is written, so shall it be done.
08/13/2004 (11:13 am)
Indeed. And what irks me about the article is the sense that the author either has not considered or is unwilling to consider the two statements that you and I have managed to dope out. :)Ergo, be it known all would be up-and-comers, these are two of the great precepts of indie game development, as derived by Ben and Axel
1. The ability to write good computer code does not automatically grant the ability to design a good game.
2. The ability to design a good game does not automatically grant the ability to write good computer code.
Verily, so it is written, so shall it be done.
#11
Hope nobody is offended by my reply there... :)
08/13/2004 (11:18 am)
Great artical all the same!Hope nobody is offended by my reply there... :)
#12
I feel like that a lot. But I think this article is more constructive. And I didn't note any kind of programmer bias - if anything, the second and fourth "pitfalls" described in this article land SQUARELY on the shoulders of the designers - whether its an individual in charge of design, or if the entire team shares the job of game design.
If you fail to recognize the limitations imposed upon your design by technology, resources, and your team's abilities - or if you fail to adapt your design to meet these limitations - you have FAILED as a game designer. End of story. You are no more qualified to take the role of a designer than a kid drawing pictures of cool cars in his notebook in school is qualified to be an engineer for the automobile industry.
I have to admit, I feel a little unqualified to speak here sometimes --- I've got 8 published titles to my credit, but I'm still finishing up my first game as an indie and as the 'sole' designer (which seems silly to me... I've received so much great input that's helped me improve my design I don't feel quite right claiming that it's soley "my" design). It's been a learning experience all the way - and seeing how much it exceeded my estimates for development time, I'm very glad I didn't decide to try out one of my grander designs for a first-time indie project. It's been a HUGE learning experience, and I consider myself an "old hand" at it.
And no - I don't think you need to be a programmer to be a designer. I know a great professional designer whom I hold in very high esteem, even though he is no artist and only a beginner at programming. But he understands what artists, modelers, and programmers do, what the team is capable of, what the machines are capable of, what the audience expectations are, how to fit things within a given schedule, how to communicate ideas, how to manage risks, and how and where to make trade-offs in his design. And, of course, games. Of all kinds.
I don't think there's anything wrong with being ambitious in your design. But being ambitious without being realistic is just naive.
08/13/2004 (1:10 pm)
There was an editorial by Brian Hook in Game Developer magazine a few years ago entitled (I think), "Finish Your Damn Game!" or something like that. It was probably less useful than this article, as this article provides real pointers on HOW to finish your game. Brian's article was more of a rant to tell people to shut up until they've put their money where their mouths are. I feel like that a lot. But I think this article is more constructive. And I didn't note any kind of programmer bias - if anything, the second and fourth "pitfalls" described in this article land SQUARELY on the shoulders of the designers - whether its an individual in charge of design, or if the entire team shares the job of game design.
If you fail to recognize the limitations imposed upon your design by technology, resources, and your team's abilities - or if you fail to adapt your design to meet these limitations - you have FAILED as a game designer. End of story. You are no more qualified to take the role of a designer than a kid drawing pictures of cool cars in his notebook in school is qualified to be an engineer for the automobile industry.
I have to admit, I feel a little unqualified to speak here sometimes --- I've got 8 published titles to my credit, but I'm still finishing up my first game as an indie and as the 'sole' designer (which seems silly to me... I've received so much great input that's helped me improve my design I don't feel quite right claiming that it's soley "my" design). It's been a learning experience all the way - and seeing how much it exceeded my estimates for development time, I'm very glad I didn't decide to try out one of my grander designs for a first-time indie project. It's been a HUGE learning experience, and I consider myself an "old hand" at it.
And no - I don't think you need to be a programmer to be a designer. I know a great professional designer whom I hold in very high esteem, even though he is no artist and only a beginner at programming. But he understands what artists, modelers, and programmers do, what the team is capable of, what the machines are capable of, what the audience expectations are, how to fit things within a given schedule, how to communicate ideas, how to manage risks, and how and where to make trade-offs in his design. And, of course, games. Of all kinds.
I don't think there's anything wrong with being ambitious in your design. But being ambitious without being realistic is just naive.
#13
I feel like that a lot. But I think this article is more constructive. And I didn't note any kind of programmer bias - if anything, the second and fourth "pitfalls" described in this article land SQUARELY on the shoulders of the designers - whether its an individual in charge of design, or if the entire team shares the job of game design.
If you fail to recognize the limitations imposed upon your design by technology, resources, and your team's abilities - or if you fail to adapt your design to meet these limitations - you have FAILED as a game designer. End of story. You are no more qualified to take the role of a designer than a kid drawing pictures of cool cars in his notebook in school is qualified to be an engineer for the automobile industry.
I have to admit, I feel a little unqualified to speak here sometimes --- I've got 8 published titles to my credit, but I'm still finishing up my first game as an indie and as the 'sole' designer (which seems silly to me... I've received so much great input that's helped me improve my design I don't feel quite right claiming that it's soley "my" design). It's been a learning experience all the way - and seeing how much it exceeded my estimates for development time, I'm very glad I didn't decide to try out one of my grander designs for a first-time indie project. It's been a HUGE learning experience, and I consider myself an "old hand" at it.
And no - I don't think you need to be a programmer to be a designer. I know a great professional designer whom I hold in very high esteem, even though he is no artist and only a beginner at programming. But he understands what artists, modelers, and programmers do, what the team is capable of, what the machines are capable of, what the audience expectations are, how to fit things within a given schedule, how to communicate ideas, how to manage risks, and how and where to make trade-offs in his design. And, of course, games. Of all kinds.
I don't think there's anything wrong with being ambitious in your design. But being ambitious without being realistic is just naive.
08/13/2004 (2:34 pm)
There was an editorial by Brian Hook in Game Developer magazine a few years ago entitled (I think), "Finish Your Damn Game!" or something like that. It was probably less useful than this article, as this article provides real pointers on HOW to finish your game. Brian's article was more of a rant to tell people to shut up until they've put their money where their mouths are. I feel like that a lot. But I think this article is more constructive. And I didn't note any kind of programmer bias - if anything, the second and fourth "pitfalls" described in this article land SQUARELY on the shoulders of the designers - whether its an individual in charge of design, or if the entire team shares the job of game design.
If you fail to recognize the limitations imposed upon your design by technology, resources, and your team's abilities - or if you fail to adapt your design to meet these limitations - you have FAILED as a game designer. End of story. You are no more qualified to take the role of a designer than a kid drawing pictures of cool cars in his notebook in school is qualified to be an engineer for the automobile industry.
I have to admit, I feel a little unqualified to speak here sometimes --- I've got 8 published titles to my credit, but I'm still finishing up my first game as an indie and as the 'sole' designer (which seems silly to me... I've received so much great input that's helped me improve my design I don't feel quite right claiming that it's soley "my" design). It's been a learning experience all the way - and seeing how much it exceeded my estimates for development time, I'm very glad I didn't decide to try out one of my grander designs for a first-time indie project. It's been a HUGE learning experience, and I consider myself an "old hand" at it.
And no - I don't think you need to be a programmer to be a designer. I know a great professional designer whom I hold in very high esteem, even though he is no artist and only a beginner at programming. But he understands what artists, modelers, and programmers do, what the team is capable of, what the machines are capable of, what the audience expectations are, how to fit things within a given schedule, how to communicate ideas, how to manage risks, and how and where to make trade-offs in his design. And, of course, games. Of all kinds.
I don't think there's anything wrong with being ambitious in your design. But being ambitious without being realistic is just naive.
Associate Kyle Carter