Well Designed Projects?
by Aaron Shumaker · in General Discussion · 08/23/2004 (6:01 pm) · 31 replies
I've been browsing through the projects, looking for one that is well designed/managed, but most all of them are of the type "I wanna make a game, and it'll have power ups, weapons, vehicles, etc."
Can someone point me to some projects of the type "Me and anyone who wants to help out are going to make a game, and we will(or already have) devote a significant amount of time to design documentation before we begin implementing."
We all have those "I want to make a game" moments, but that doesn't mean we should all try to make every game that comes to mind. It is good practice, but it would seem you can get the same practice from contributing.
I am considering purchasing the engine, but if I can't find some well designed projects in this community, then I'm not really intersted. I could probably get the engine, work by myself, and make some throw away game in my free time just so that I can say I've done it. However, I'd rather make small contributions where I can, to help quality projects, so that maybe I will have helped create a game that a few people will enjoy.
I've played some of the games people have already made, and they are really cool. So I know there are some good projects out there. I want to see how detailed the design documents are for some of these projects. If they are really detailed, then I know it'd be easy to jump onto a project and familierize myself with it quickly, and be able to implement objects based on the detailed object design, without having to be really familier with the entire project.
[bold]Edit 08/26/2004:[/bold]
There are two ends of the spectrum for software design, ad hoc at one, and formal at the other.
I want to make it clear that I didn't intend to imply one end is better than the other. I am sorry.
It's just that my time restraints make it impossible for me to join a team, be with the project long enough to learn the game engine, become familier with the project, and finally make significant contributions. By the time I got through all that, I'd probably wouldn't be a part of this community. Although I currently have lots of free time, and often I do, my life is not very stable. My parent's health is ailing, every semester I have a different course load, and I do temp work(thus ever so often driving distances change and work load changes). Things like that make it hard for me to predict how long I will have free time. Thus I wanted to find projects that had detailed design docs.
I could take a particular object design, only learn the small subset of engine features needed for that object, and implement the object.
I understand now that it is unlikely that I would find such a project, thank you.
Can someone point me to some projects of the type "Me and anyone who wants to help out are going to make a game, and we will(or already have) devote a significant amount of time to design documentation before we begin implementing."
We all have those "I want to make a game" moments, but that doesn't mean we should all try to make every game that comes to mind. It is good practice, but it would seem you can get the same practice from contributing.
I am considering purchasing the engine, but if I can't find some well designed projects in this community, then I'm not really intersted. I could probably get the engine, work by myself, and make some throw away game in my free time just so that I can say I've done it. However, I'd rather make small contributions where I can, to help quality projects, so that maybe I will have helped create a game that a few people will enjoy.
I've played some of the games people have already made, and they are really cool. So I know there are some good projects out there. I want to see how detailed the design documents are for some of these projects. If they are really detailed, then I know it'd be easy to jump onto a project and familierize myself with it quickly, and be able to implement objects based on the detailed object design, without having to be really familier with the entire project.
[bold]Edit 08/26/2004:[/bold]
There are two ends of the spectrum for software design, ad hoc at one, and formal at the other.
I want to make it clear that I didn't intend to imply one end is better than the other. I am sorry.
It's just that my time restraints make it impossible for me to join a team, be with the project long enough to learn the game engine, become familier with the project, and finally make significant contributions. By the time I got through all that, I'd probably wouldn't be a part of this community. Although I currently have lots of free time, and often I do, my life is not very stable. My parent's health is ailing, every semester I have a different course load, and I do temp work(thus ever so often driving distances change and work load changes). Things like that make it hard for me to predict how long I will have free time. Thus I wanted to find projects that had detailed design docs.
I could take a particular object design, only learn the small subset of engine features needed for that object, and implement the object.
I understand now that it is unlikely that I would find such a project, thank you.
#22
That's just not really going to work very well. However, doing up some public resources (which many teams will use) should be your primary goal until you are ready to get in the groove full time as part of a team for the whole ride. You're not going to find such rigidly designed projects where your work will actually stay with the project from the time you jump out till the time the product ships if you made something specific for their design document.
What it comes down to really ... games are created not designed. That's my take. Don't waste your time trying to knock off little goals on someone's design doc, learn this stuff by making those free resources which will last for a long time for a lot of people and will also teach you.
08/24/2004 (6:18 pm)
Aaron, what would you like to contribute to a project without being full time or there for the whole project? To me your best bet would be to post some free resources if you aren't actually ready to commit to a team. What you're basically saying is that you want to jump in accomplish a goal for a team and jump out if need be. That's just not really going to work very well. However, doing up some public resources (which many teams will use) should be your primary goal until you are ready to get in the groove full time as part of a team for the whole ride. You're not going to find such rigidly designed projects where your work will actually stay with the project from the time you jump out till the time the product ships if you made something specific for their design document.
What it comes down to really ... games are created not designed. That's my take. Don't waste your time trying to knock off little goals on someone's design doc, learn this stuff by making those free resources which will last for a long time for a lot of people and will also teach you.
#23
We have a very old design doc which has promptly been chipped and changed as weve gone along. As a result its fairly out of date.
We are looking for a programmer who is willing to contribute weekly. where not asking for all your spare time just a consistant effort.
Pm me or email me if you want to know more about the project.
There are a heap of excellent projects going around though. Take a look through the dev snapshots for some excellent games coming along with torque.
08/24/2004 (7:36 pm)
Hey aaron. Im heading the illumina project which is making steady progress for quiet awhile now.We have a very old design doc which has promptly been chipped and changed as weve gone along. As a result its fairly out of date.
We are looking for a programmer who is willing to contribute weekly. where not asking for all your spare time just a consistant effort.
Pm me or email me if you want to know more about the project.
There are a heap of excellent projects going around though. Take a look through the dev snapshots for some excellent games coming along with torque.
#24
08/24/2004 (7:41 pm)
Bwah hahahaha Ive already got Aaron so in your faces! just joking but seriously he has signed on with my team. Thanks Aaron!
#25
They go wrong, as most the time spend is "wasted" (in the eyes of outsiders) on balancing the game, scripting small improvements, testing things to see if they work - tasks you do not have in business development due to lack of "art" and "fun" factors.
And you cannot design document you out of that phase, and its not possible to write design on these tasks. They can however be in your timeplan, and managed
Where you CAN and SHOULD use design docs is when you do "real" development. Meaning e.g. writing a new camera resource, or implementing a new vehicle. That kind of engine development can use the mature development approaches.
But to create the actual game its a total waste of time to write design docs.
08/24/2004 (10:59 pm)
Where people go wrong on game dev is that most developers from the "outside" (like myself) think that you can approach it using the mature development models for business software.They go wrong, as most the time spend is "wasted" (in the eyes of outsiders) on balancing the game, scripting small improvements, testing things to see if they work - tasks you do not have in business development due to lack of "art" and "fun" factors.
And you cannot design document you out of that phase, and its not possible to write design on these tasks. They can however be in your timeplan, and managed
Where you CAN and SHOULD use design docs is when you do "real" development. Meaning e.g. writing a new camera resource, or implementing a new vehicle. That kind of engine development can use the mature development approaches.
But to create the actual game its a total waste of time to write design docs.
#26
This is particularly true if you are designing a game with a complexity of interaction, like an adventure or RPG.
But what I argue for is keeping this documentation as lightweight as possible. There's no room in game development for heavyweight design documents up front. In software development, the "XP" (Extreme Programming) and similar lightweight "agile processes" have taken hold becase of reality of changing requirements. Game development has more changing requirements and specifications than any other field within the industry that I can think of, because you creating something that is more art than tool.
I was just re-reading "Masters of Doom," and the chapters on the failure of John Romero's "Ion Storm" company. One of the reasons cited for the failure of Daikatana by exiting staff members was that the bulky, unwieldy design document. (I seem to remember Todd Porter ranting at GDC about how wonderful Dominion would be because of his incredible design doc... though I could be confusing him for someone else who had a miserably failed RTS game...)
So I'm not really arguing against designing before you start coding, or even arguing against design docs. I just believe that writing a game is more like writing a novel than engineering a bridge. As I understand it, most successful novelists have a pretty clear idea of characters and a rough outline of the plot before they get cranking. But in the process of writing, characters change, sections that the author thought would be key get mercilessly pulled out, and the whole thing gets revised multiple times to get 'polished' before release.
Everything changes. So plan accordingly. Keep it small and disposable.
08/25/2004 (9:18 am)
Aaron - I'd agree with you 100% that you should have a clear vision of the game and a basic design in place before you set forth developing it. It's possible to just kinda 'design as you go,' and there are a lot of great ideas that evolve from just tinkering. But in general, you want to have some kind of goal and plan in place before you go storming off on an odyssey of game development.This is particularly true if you are designing a game with a complexity of interaction, like an adventure or RPG.
But what I argue for is keeping this documentation as lightweight as possible. There's no room in game development for heavyweight design documents up front. In software development, the "XP" (Extreme Programming) and similar lightweight "agile processes" have taken hold becase of reality of changing requirements. Game development has more changing requirements and specifications than any other field within the industry that I can think of, because you creating something that is more art than tool.
I was just re-reading "Masters of Doom," and the chapters on the failure of John Romero's "Ion Storm" company. One of the reasons cited for the failure of Daikatana by exiting staff members was that the bulky, unwieldy design document. (I seem to remember Todd Porter ranting at GDC about how wonderful Dominion would be because of his incredible design doc... though I could be confusing him for someone else who had a miserably failed RTS game...)
So I'm not really arguing against designing before you start coding, or even arguing against design docs. I just believe that writing a game is more like writing a novel than engineering a bridge. As I understand it, most successful novelists have a pretty clear idea of characters and a rough outline of the plot before they get cranking. But in the process of writing, characters change, sections that the author thought would be key get mercilessly pulled out, and the whole thing gets revised multiple times to get 'polished' before release.
Everything changes. So plan accordingly. Keep it small and disposable.
#27
08/25/2004 (9:34 am)
Just to toss a little of my insight in with my current project here at GarageGames. I started working on Marble Blast for the XBox around June 26th. Since then we have had dates fly around like crazy, we'd literally get new versions of the XArcade API once, if not twice a week, I got updates on the "product requirements" about that often for a while too. (Me and Alex would sit down and read through them and say "We have to do WHAT!?") At no point was this game planned out to the degree that people probably think it should have been. In fact, I am sure that there are games in the community that are more planned out than this one. What you should be looking for is not a project which is well planned and designed. We have a 3" binder in the office which has design documentation for a game which never made it...that game was *well* documented. You should be looking for a game which has realistic goals.
#28
I remember the first project I tried designing, just me and two pals. I think I must've put a couple hundred hours worth of work on that thing, got it up to eighty pages or so, fine details, everything. That project died for a number of reasons, but I just cannot look at that damn design doc anymore. I think the only reason I keep it on my hard drive anymore is because there's the faint hope I might resurrect the basic concepts. And to remind me of the KISS principle.
"Keep It Simple, Stupid."
The question I think we should always ask ourselves is this: "Is my game fun?" Variations on the theme would be "Do I like this game?" "Is this something I could recommend to my friends?" "Can I bring this thing to a LAN party and not get lynched?" Taking ourselves out of the equation and looking at our games like we would if we were in the local computer store and were in the mood to find a new game. Thinking like a gamer, not as a game designer, makes for a good reality check on any project.
08/26/2004 (11:10 am)
Wow. All sorts of lovely little psychological wounds opening up here. :)I remember the first project I tried designing, just me and two pals. I think I must've put a couple hundred hours worth of work on that thing, got it up to eighty pages or so, fine details, everything. That project died for a number of reasons, but I just cannot look at that damn design doc anymore. I think the only reason I keep it on my hard drive anymore is because there's the faint hope I might resurrect the basic concepts. And to remind me of the KISS principle.
"Keep It Simple, Stupid."
The question I think we should always ask ourselves is this: "Is my game fun?" Variations on the theme would be "Do I like this game?" "Is this something I could recommend to my friends?" "Can I bring this thing to a LAN party and not get lynched?" Taking ourselves out of the equation and looking at our games like we would if we were in the local computer store and were in the mood to find a new game. Thinking like a gamer, not as a game designer, makes for a good reality check on any project.
#29
08/26/2004 (12:31 pm)
I like to codesketch. Every game I design a game I sit down with code and just prototype the idea. That's my design document. I'm serious too ... since Aerial Antics (and we've got 4 more games in the works) all of our games come from a prototype that I just sit down and straight code as if I'm writing the design doc with something that's actually interactive. I actually picked up the domain www.codesketching.com because I'd like to have people post short artistic creations of code. I think in the future people will use code just as they use pens and paper or wordprocessors now and there will be no need for a design document at all.
#30
08/27/2004 (5:49 am)
Id agree with that...Ive caught myself thinking in code many a time. I use design documents only when they are forced upon me, something that happens all too often these days. One day, perhaps, it will no longer be seen as an esoteric skill.
#31
Welcome to the real world. Throw some young children in there and you have my life except for the semester thing. Its part of life. Will say a prayer for your parents.
08/27/2004 (7:53 am)
Quote:It's just that my time restraints make it impossible for me to join a team, be with the project long enough to learn the game engine, become familier with the project, and finally make significant contributions. By the time I got through all that, I'd probably wouldn't be a part of this community. Although I currently have lots of free time, and often I do, my life is not very stable. My parent's health is ailing, every semester I have a different course load, and I do temp work(thus ever so often driving distances change and work load changes). Things like that make it hard for me to predict how long I will have free time. Thus I wanted to find projects that had detailed design docs.
Welcome to the real world. Throw some young children in there and you have my life except for the semester thing. Its part of life. Will say a prayer for your parents.
Torque Owner Joe Maruschak