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.
#2
We don't make elaborate design documents upfront. This is not to say that we don't have a process for managing the construction of a game, but my opinion is that extremely detailed designed documents are not a good recipe for making games.
If you saw the design docs we made for ThinkTanks, you would probably laugh at us.
We prefer a more 'agile' approach to making games, as we feel that it leads to superior results with less effort and time invested.
08/23/2004 (6:18 pm)
It has been my experience and observation that many of the well 'designed and specified' projects out there don't necessarily turn out to be fun games. We don't make elaborate design documents upfront. This is not to say that we don't have a process for managing the construction of a game, but my opinion is that extremely detailed designed documents are not a good recipe for making games.
If you saw the design docs we made for ThinkTanks, you would probably laugh at us.
We prefer a more 'agile' approach to making games, as we feel that it leads to superior results with less effort and time invested.
#3
Personally, I'm not trying to make some genre-busting monster game right now. I've tried that before and failed. I've completed game projects, but they never quite turned out the way I wanted them too. I even managed to sell one game I made, but only to a few people.
If you have no intention of becoming some sort of multimillion indy game dev bigwig, I would suggest making a bunch of open source game material and posting for free on the Internet.
I'm doing this with some source code on my website. Basically, it's the same as gamebeavers or digital boneyard except that my "license agreement" is basically "use what you want for anything you want without paying for it, but give the contributors credit".
The same sort of thing can work with art, music, or anything else.
The main open source project I have "done" is a program called Bot Asylum. It's a chatbot program that outputs its answers in such a way that it looks like a Q&A site. It's not anything special, but it could be decent if I had a huge knowledge base. Unfortunately, making that knowledge base takes time.
After it looks a little better, I'm going to scrounge around trying to find people who want to help with the knowledge base. It's just filling in data (lots of data) - no special experience is needed.
Another project I'm working on is a Java Game Programming Tutorial. It's not very far along yet because I just started on it, but I think that some people will find it useful. I haven't managed to find any Java Game Programming Tutorials on the Internet except for ONE that's posted everywhere and just lists a few Java API functions that you might want to call if you were making a game.
Anyways, my point is that you could work on some sort of community open source project. Or start your own. It would probably be better to find some pre-existing open source organization to work with, but starting your own projects has its own special appeal.
08/23/2004 (7:06 pm)
I think there's alot of people of the sort you're looking for on Garagegames.Personally, I'm not trying to make some genre-busting monster game right now. I've tried that before and failed. I've completed game projects, but they never quite turned out the way I wanted them too. I even managed to sell one game I made, but only to a few people.
If you have no intention of becoming some sort of multimillion indy game dev bigwig, I would suggest making a bunch of open source game material and posting for free on the Internet.
I'm doing this with some source code on my website. Basically, it's the same as gamebeavers or digital boneyard except that my "license agreement" is basically "use what you want for anything you want without paying for it, but give the contributors credit".
The same sort of thing can work with art, music, or anything else.
The main open source project I have "done" is a program called Bot Asylum. It's a chatbot program that outputs its answers in such a way that it looks like a Q&A site. It's not anything special, but it could be decent if I had a huge knowledge base. Unfortunately, making that knowledge base takes time.
After it looks a little better, I'm going to scrounge around trying to find people who want to help with the knowledge base. It's just filling in data (lots of data) - no special experience is needed.
Another project I'm working on is a Java Game Programming Tutorial. It's not very far along yet because I just started on it, but I think that some people will find it useful. I haven't managed to find any Java Game Programming Tutorials on the Internet except for ONE that's posted everywhere and just lists a few Java API functions that you might want to call if you were making a game.
Anyways, my point is that you could work on some sort of community open source project. Or start your own. It would probably be better to find some pre-existing open source organization to work with, but starting your own projects has its own special appeal.
#4
I am currently working on a game and I have a rather good design document. I am the header and programmer and lead designer of my team (which only consists of two people so far) and I already have a 3D modeler. I checked out your profile page and I was looking for someone who can do concept art. You said you would work for but if you want money I can only offer you a % of the proceeds. Anyways the bottom line is this: if you would like to do concept art for the game that my TEAM is making than I am offering you a "job".
P.S. if you read the description of my game and company on my profile page they may not seem complete and that is because I have not had the time to update them. for questions feel free to email me.
08/23/2004 (7:29 pm)
@ AaronI am currently working on a game and I have a rather good design document. I am the header and programmer and lead designer of my team (which only consists of two people so far) and I already have a 3D modeler. I checked out your profile page and I was looking for someone who can do concept art. You said you would work for but if you want money I can only offer you a % of the proceeds. Anyways the bottom line is this: if you would like to do concept art for the game that my TEAM is making than I am offering you a "job".
P.S. if you read the description of my game and company on my profile page they may not seem complete and that is because I have not had the time to update them. for questions feel free to email me.
#7
Most of those appear to be well managed projects that are going somewhere.
08/23/2004 (9:12 pm)
Look at the "Development Snapshots of the Day" gallery.Most of those appear to be well managed projects that are going somewhere.
#8
I created the original game which consisted of 30 levels (which were later rebuilt) and we basically followed that but with new art, gui, and 20 extra levels. If you aim to join a team, it's probably best to work with people you respect, understand, and who are working on a project you're interested in. If their design document isn't great ... I wouldn't hold it against them.
08/23/2004 (10:16 pm)
I agree with Joe (and we both have games published here), a game doesn't (and probably shouldn't) have to be rigidly designed. Aerial Antics had a 'design idea' ... along with quite a few notebook pages filled with checklists of "to do" goals. There was no design document though ... nothing super rigid like that. I created the original game which consisted of 30 levels (which were later rebuilt) and we basically followed that but with new art, gui, and 20 extra levels. If you aim to join a team, it's probably best to work with people you respect, understand, and who are working on a project you're interested in. If their design document isn't great ... I wouldn't hold it against them.
#9
With that said, you do need (in my oppinion) at least concept shots of every level, description of the overall game and all these things. We work through a wiki that we attempt to keep up to date.
On the other hand - it is not possible to make a game in a certain timeframe if you cannot manage the time spend. So its important to keep moving forward towards a well defined goal and not do the feature creep mistake.
But the 2 things (detailed design doc and project management) have little in common. You can have either or both, but they are not linked (much)
08/24/2004 (12:11 am)
Same as Jeremy and Joe - a game cannot be too designed. It has to evolve through game testing and regular "what works, what doesnt" sessions where you are not afraid to remove things that do not work.With that said, you do need (in my oppinion) at least concept shots of every level, description of the overall game and all these things. We work through a wiki that we attempt to keep up to date.
On the other hand - it is not possible to make a game in a certain timeframe if you cannot manage the time spend. So its important to keep moving forward towards a well defined goal and not do the feature creep mistake.
But the 2 things (detailed design doc and project management) have little in common. You can have either or both, but they are not linked (much)
#10
Of all the games Ive worked on (including the bigger commercial ones), the design document gets thrown in the bin pretty quickly. Usually depends on the size of the doc, bigger ones get read by fewer people and thrown away quicker.
I saw the DD for marble blast, it was "thin" :)
I'd agree with Thomas, a few "style guide" type things, a rough 2 page precis of the overall idea is generally what I prefer. Basically, your working on an evolving concept, because you have to be able to adapt the idea if it doesnt feel compelling. Having a 500 page design document (seen those before) does NOT help the game.
If you have a document thats so complete, how are you going to provide any input yourself?
08/24/2004 (2:22 am)
I agree with the other three :)Of all the games Ive worked on (including the bigger commercial ones), the design document gets thrown in the bin pretty quickly. Usually depends on the size of the doc, bigger ones get read by fewer people and thrown away quicker.
I saw the DD for marble blast, it was "thin" :)
I'd agree with Thomas, a few "style guide" type things, a rough 2 page precis of the overall idea is generally what I prefer. Basically, your working on an evolving concept, because you have to be able to adapt the idea if it doesnt feel compelling. Having a 500 page design document (seen those before) does NOT help the game.
If you have a document thats so complete, how are you going to provide any input yourself?
#11
I'm Jonathan, i'm new here and working on a WW2 title for Torque, called "The Third Reich".
Since this is a thread about projects, i thought i'd add it to the list. You'll probably see the name pop up here & there whenever the occassion presents itself, in hope of growing some awareness within the garagegames community.
I've knocked up quick & simple web page that should explain the necessary information. Feel free to mail me any feedback you might have :)
http://users.pandora.be/wurtel/temp/test1.htm
-
Jonathan
08/24/2004 (3:08 am)
Hello everyone,I'm Jonathan, i'm new here and working on a WW2 title for Torque, called "The Third Reich".
Since this is a thread about projects, i thought i'd add it to the list. You'll probably see the name pop up here & there whenever the occassion presents itself, in hope of growing some awareness within the garagegames community.
I've knocked up quick & simple web page that should explain the necessary information. Feel free to mail me any feedback you might have :)
http://users.pandora.be/wurtel/temp/test1.htm
-
Jonathan
#12
An interesting thing I found --- based upon anecdotal evidence --- is that many of the most successful, hit games had very little in the way of a design document. Usually just a 3-page pitch document to make their publisher happy.
By comparison, I lost count of the number of games I saw that were touted as being so perfectly designed with these incredibly detailed design documents that faded into obscurity upon release (if they made it that far).
That's not enough to draw a conclusion from, but enough for me to form an opinion:
* A design document must communicate vision of a game when the game isn't there. If you fail to communicate the vision of the game - which often happens because your design document is too huge and difficult for the reader to digest - then your design document is useless.
* A design document serves as a "paper prototype" of the game until a better prototype can be developed. The sooner you can move away from paper and onto the screen with real interaction, the better. The paper prototype helps make sure you don't make an expensive leap in the wrong direction.
* The fully detailed design document is derived from the "Waterfall" Software Development Model. This is the development methodology where each process is broken into distinct steps that are completed in strict order, and development doesn't begin until full requirements-gathering, specification, and design stages are complete. This design model has FAILED time and time again in the software industry in general.
* That also implies that game design isn't over when the design document is "finished." IMO, that's just the jumping-off point... you've just gotten started. A good designer is going to be constantly trying to refine the game throughout development, working within the constraints of time, budget, and the capabilities of his team. But the sooner he divorces himself from what the game was 'supposed' to be back when it existed only on paper, and comes to grips with what the game really is and is becoming, the better off he'll be.
There you go --- my opinions, offered absolutely free and worth every penny.
08/24/2004 (10:44 am)
I attended several panels on design documents over the five years, trying to figure out how to do it "right." I've worked on eight published titles for the PC, Playstation, and Sega Dreamcast, and a few unpublished titles. I was never satisfied with the design documents --- even the ones I helped write.An interesting thing I found --- based upon anecdotal evidence --- is that many of the most successful, hit games had very little in the way of a design document. Usually just a 3-page pitch document to make their publisher happy.
By comparison, I lost count of the number of games I saw that were touted as being so perfectly designed with these incredibly detailed design documents that faded into obscurity upon release (if they made it that far).
That's not enough to draw a conclusion from, but enough for me to form an opinion:
* A design document must communicate vision of a game when the game isn't there. If you fail to communicate the vision of the game - which often happens because your design document is too huge and difficult for the reader to digest - then your design document is useless.
* A design document serves as a "paper prototype" of the game until a better prototype can be developed. The sooner you can move away from paper and onto the screen with real interaction, the better. The paper prototype helps make sure you don't make an expensive leap in the wrong direction.
* The fully detailed design document is derived from the "Waterfall" Software Development Model. This is the development methodology where each process is broken into distinct steps that are completed in strict order, and development doesn't begin until full requirements-gathering, specification, and design stages are complete. This design model has FAILED time and time again in the software industry in general.
* That also implies that game design isn't over when the design document is "finished." IMO, that's just the jumping-off point... you've just gotten started. A good designer is going to be constantly trying to refine the game throughout development, working within the constraints of time, budget, and the capabilities of his team. But the sooner he divorces himself from what the game was 'supposed' to be back when it existed only on paper, and comes to grips with what the game really is and is becoming, the better off he'll be.
There you go --- my opinions, offered absolutely free and worth every penny.
#13
I know I personally wouldn't be able to write a good design document by myself because I don't know enough about game programming strateges, and I'm not that decisive. But the that's what partners are for, I guess - I just need to find a partner who's a decisive, experienced programmer with god communication skills, who happens to want to mae the same kind of game I do... heh, good luck, right?
08/24/2004 (11:27 am)
I think it's very difficult to design a project well because very few people have all the necessary skills - psychology for picking an appealing concept and pitching it well, writing ability for clearly describing what you want, knowledge of the different types of game content and strategies for developing these to know what's the most efficient and practical approach to creating the game, decisiveness for creating the specifictions, yet flexibilty to be willing to change them later if a better idea comes up...I know I personally wouldn't be able to write a good design document by myself because I don't know enough about game programming strateges, and I'm not that decisive. But the that's what partners are for, I guess - I just need to find a partner who's a decisive, experienced programmer with god communication skills, who happens to want to mae the same kind of game I do... heh, good luck, right?
#14
I have one partner, and well.. updating that thing for the use of a two man team - who allready know what's going on and are on "the same page" is just silly.
If I was asked for my design doc by someone interested in working on my project, I'd be hesitant because so much has changed - necessarily - from when that document was written that it's hardly relevant anymore.
Just because someone doesn't hand you a 50 page design doesn't mean that their design lacks, or that they lack organization - sometimes it's just more practical to pitch the formal cr@p and dig in.
In the end, no matter what your project is, or how well written and specific your design is, you're going to deviate from it at some point, in some way - as long as you stay true to the "vision" and concept of the game, you won't go wrong.
Commit to the idea - not a list of features.
=P
08/24/2004 (11:43 am)
I wrote a 50 page design doc for my project two years ago - haven't really looked at it since.I have one partner, and well.. updating that thing for the use of a two man team - who allready know what's going on and are on "the same page" is just silly.
If I was asked for my design doc by someone interested in working on my project, I'd be hesitant because so much has changed - necessarily - from when that document was written that it's hardly relevant anymore.
Just because someone doesn't hand you a 50 page design doesn't mean that their design lacks, or that they lack organization - sometimes it's just more practical to pitch the formal cr@p and dig in.
In the end, no matter what your project is, or how well written and specific your design is, you're going to deviate from it at some point, in some way - as long as you stay true to the "vision" and concept of the game, you won't go wrong.
Commit to the idea - not a list of features.
=P
#15
A formal approach is wasteful when you have a team of just a few people who can communicate easily.
"If their design document isn't great ... I wouldn't hold it against them."
It's not that I think it's bad practice to not have detailed design. It's a personal preference.
When you have a detailed design document, it makes it easy for others who are completely unfamilier with the project to come in, look at a particular detailed object design, and implement that object. Less communication and magement is needed, the document facilitates the communication of information.
This increases the chances of the project being completed, because if a team member leaves, someone else can take their place easily. Also, it's easier for lots people to contribute code without creating chaos.
If a design document gets thrown out, it was probably created without significant foresight. Most of the time the project begins coming upon lots of issues that weren't addressed in the design document, and elements of the document thus are invalidated. Rather than go back and make change to the document, it just gets thrown out to save time. Designing with the expectation that there will be change is important, and there are techniques to minimize the impact of change.
08/24/2004 (1:20 pm)
Your points are all valid. Adhoc design approaches and formal design aproaches each have their advantages and disadvantages.A formal approach is wasteful when you have a team of just a few people who can communicate easily.
"If their design document isn't great ... I wouldn't hold it against them."
It's not that I think it's bad practice to not have detailed design. It's a personal preference.
When you have a detailed design document, it makes it easy for others who are completely unfamilier with the project to come in, look at a particular detailed object design, and implement that object. Less communication and magement is needed, the document facilitates the communication of information.
This increases the chances of the project being completed, because if a team member leaves, someone else can take their place easily. Also, it's easier for lots people to contribute code without creating chaos.
If a design document gets thrown out, it was probably created without significant foresight. Most of the time the project begins coming upon lots of issues that weren't addressed in the design document, and elements of the document thus are invalidated. Rather than go back and make change to the document, it just gets thrown out to save time. Designing with the expectation that there will be change is important, and there are techniques to minimize the impact of change.
#16
I understand your point of view, and I respect your personal preference, but I fear that you may be missing the point of what I and several others have said in this thread, which is that design documents, while they may make it easier to implement the software, will not necessarily lead to a good game, and quite often, lead to a game that is not fun.
It all depends on your goals. If your goal is to work from a design document, more power to you. If your goal is to create a shippable and fun product, then it is my opinion that it would be wise to think about what some of the people are saying here.
By desiring to work from a specified design document, it is my opinion that you are eliminating a large group of developers, and in this group you have eliminated are probably the most knowledgable and experienced people here on GarageGames, who have the highest probability of completing a game.
Design documents get thrown out because quantifying 'fun' in a game is, in my experience, just not possible without a lot of prototyping and playtesting. There may be one or two humans on this planet who can do it, but they would be the exception, not the rule. No amount of 'significant foresight' is going to change this situation.
There are ways to approach a project with the expectation of change (as you mention).. in our case, we just choose to use a development methodology more geared toward shifting requirements. It is not that the people posting here don't understand software development. Most here do, and the reasons you are pointing to support the perpetuation of what is, in my opinion, a myth based on a belief in development methodologies that are outdated. In theory, your points are sound. In practice, they fall apart, particularly with making games.
Check the profiles of the people posting here.. in particular, look at myself, Phil,Jeremy, and Jay. Multiple shipped titles.. all saying the same thing.. something to think about.
08/24/2004 (3:29 pm)
Aaron,I understand your point of view, and I respect your personal preference, but I fear that you may be missing the point of what I and several others have said in this thread, which is that design documents, while they may make it easier to implement the software, will not necessarily lead to a good game, and quite often, lead to a game that is not fun.
It all depends on your goals. If your goal is to work from a design document, more power to you. If your goal is to create a shippable and fun product, then it is my opinion that it would be wise to think about what some of the people are saying here.
By desiring to work from a specified design document, it is my opinion that you are eliminating a large group of developers, and in this group you have eliminated are probably the most knowledgable and experienced people here on GarageGames, who have the highest probability of completing a game.
Design documents get thrown out because quantifying 'fun' in a game is, in my experience, just not possible without a lot of prototyping and playtesting. There may be one or two humans on this planet who can do it, but they would be the exception, not the rule. No amount of 'significant foresight' is going to change this situation.
There are ways to approach a project with the expectation of change (as you mention).. in our case, we just choose to use a development methodology more geared toward shifting requirements. It is not that the people posting here don't understand software development. Most here do, and the reasons you are pointing to support the perpetuation of what is, in my opinion, a myth based on a belief in development methodologies that are outdated. In theory, your points are sound. In practice, they fall apart, particularly with making games.
Check the profiles of the people posting here.. in particular, look at myself, Phil,Jeremy, and Jay. Multiple shipped titles.. all saying the same thing.. something to think about.
#17
A design document for a huge project is helpful when you have several seperate teams working on the same project, but is not essential for a winning game. I understand the original intent of the poster being the desire to weed through the casual "oooh ooh ooh! I wanna make a game!" enthusiasm, and to try to find a project/team who has a fighting chance of accomplishing their goals. The first few days I became a member and registered Torque SDK owner, I received 4 emails from people wanting to engage me as a programmer/artist for their MMO. Of course, it was without pay and they could not offer me a single bit of insight into their game, besides "it's a fan copy of a retail franchise", "It's better then EQ", or "just join us, you'll be happy". :)
Also, as the recent Dev snapshot shows, having concept art and a solid background/story is also a big win. I'm drawn to games that are interesting, full of lore, and has a life of their own, so to speak. For those reasons I've always been a fan of good plots, storywork, and art design.
Most Indie games are a win if they do something that isn't mainsteam. The next MMO or standard FPS isn't going to be a huge seller, with certain exceptions. :) Dark Horizons: Lore is a great example of an indie mech FPS that can possibly score big, especially with exposure on fileplanet.
This mini rant is just my opinion, so I ask everyone's indulgance considering I'm a relative new face here who has yet to prove himself. :)
-Matt Freyman
08/24/2004 (4:13 pm)
I personally think that a design document is just a sign of how talented of a documentation expert you have working on your team. That in itself is a desireable attribute, but not what makes a winning game. If your game design is simply "create a game with very stylized tanks, combined with wonderful AI, and a multiplayer battlefield", you may have a niche that will attract a huge number of potential player/customers(I have never played thinktanks, but I guessed at the basics. :) Forgive me for being wrong, or presumtuous. A design document for a huge project is helpful when you have several seperate teams working on the same project, but is not essential for a winning game. I understand the original intent of the poster being the desire to weed through the casual "oooh ooh ooh! I wanna make a game!" enthusiasm, and to try to find a project/team who has a fighting chance of accomplishing their goals. The first few days I became a member and registered Torque SDK owner, I received 4 emails from people wanting to engage me as a programmer/artist for their MMO. Of course, it was without pay and they could not offer me a single bit of insight into their game, besides "it's a fan copy of a retail franchise", "It's better then EQ", or "just join us, you'll be happy". :)
Also, as the recent Dev snapshot shows, having concept art and a solid background/story is also a big win. I'm drawn to games that are interesting, full of lore, and has a life of their own, so to speak. For those reasons I've always been a fan of good plots, storywork, and art design.
Most Indie games are a win if they do something that isn't mainsteam. The next MMO or standard FPS isn't going to be a huge seller, with certain exceptions. :) Dark Horizons: Lore is a great example of an indie mech FPS that can possibly score big, especially with exposure on fileplanet.
This mini rant is just my opinion, so I ask everyone's indulgance considering I'm a relative new face here who has yet to prove himself. :)
-Matt Freyman
#18
Details is usually a bad thing only because the details change so many times in the implementation. The changes may be because of limitations of program or people, art, or sound, playability, fun, or simply because a better way of doing something was thought up.
If you have a strictly detailed and set in stone design doc, you are closing so many avenues for creativity and improvement.
On the other hand if your design doc is open, yes that is great, but you had better hire a secretary to keep track of changes and to update it daily.
Personally, a design doc is just the thing to get you started, and then you throw it out.
I hope my boss doesnt see this post! LOL
08/24/2004 (4:20 pm)
Agreed that a design doc is not REQUIRED, but I think it can be helpful IF you are willing to change it as you go. MGT had a design doc for Lore, I dont remember when the last time I looked at it was, but it was great for getting the general structure of what we wanted in place.Details is usually a bad thing only because the details change so many times in the implementation. The changes may be because of limitations of program or people, art, or sound, playability, fun, or simply because a better way of doing something was thought up.
If you have a strictly detailed and set in stone design doc, you are closing so many avenues for creativity and improvement.
On the other hand if your design doc is open, yes that is great, but you had better hire a secretary to keep track of changes and to update it daily.
Personally, a design doc is just the thing to get you started, and then you throw it out.
I hope my boss doesnt see this post! LOL
#19
:)
I undestand completely the advatages of an adhoc design technique, and understand where it is best for most independent developements. I have not disputed anyones claims where they have stated it's advantages. I am in agreement with the points made as far.
If I was sure that my free time would remain consistent then I wouldn't care about the design approach and would join any project that was intersting to me. But my goal is not to make a game, but to make contributions, and to make contributions to projects that I can have confidence will be completed. That way I can say I helped a little bit, even if the game isn't fun. If I'm not participating in design, then it's not my fault if it's not fun :)
I would like any game I design to be "fun," but I'm not interested in designing a game at this point. I don't think I'm qualified to design a torque based game until I have significant experience with the Torque engine so that I am aware of it's capabilities and structure.
Anyways, I have purchased the license, and am downloading the source right now.
08/24/2004 (5:04 pm)
"I fear that you may be missing the point of what I and several others have said":)
I undestand completely the advatages of an adhoc design technique, and understand where it is best for most independent developements. I have not disputed anyones claims where they have stated it's advantages. I am in agreement with the points made as far.
If I was sure that my free time would remain consistent then I wouldn't care about the design approach and would join any project that was intersting to me. But my goal is not to make a game, but to make contributions, and to make contributions to projects that I can have confidence will be completed. That way I can say I helped a little bit, even if the game isn't fun. If I'm not participating in design, then it's not my fault if it's not fun :)
I would like any game I design to be "fun," but I'm not interested in designing a game at this point. I don't think I'm qualified to design a torque based game until I have significant experience with the Torque engine so that I am aware of it's capabilities and structure.
Anyways, I have purchased the license, and am downloading the source right now.
#20
08/24/2004 (5:15 pm)
Welp we don need any more guys except an engine coder but u have to talk to roachie but www.illumina-game.com has some good progress 
Torque Owner nibbuls
If you bother to look at the projects section of the website, you will see only a couple games being made by people with, well, talent... ;) Most of them are, like you said, just those "I'll make a game over the next three years and it'll be fun" people and projects. If you can sift through them and find a winner, you'll be on a rocket to the top.
I can't suggest another game engine over Torque. Even if there aren't any games that you want to help make now, you could get better with the engine and make some games later.
Although I was never on one of the GG published games' team, I can imagine that the concept docs are very detailed. Check out the concept doc for Realm Wars. It's very well done and would be a good example for you.