NEWSFLASH: Ignorant newbie asks yet more ?'s
Author
I wanted to know hoe you expert designers usually go about designing. From the first detail to the last. What do you use to create it? Pen and paper or type it up? What comes after that? How do you present it to a team? Do you need to know programming or game art to design? tell me all. I want to know everything I can before I start.
An "ex" is a has-been and "spurt" is a drip under pressure. 
I tend to see GDNet as an Amateur Development forum, which is actually a good thing in my book. Looking for experts here will likely draw the same sarcasm from the ranks as the President''s Professional Help Wanted thread did. Tread carefully.
But that is just my very non-expert opinion.
I tend to see GDNet as an Amateur Development forum, which is actually a good thing in my book. Looking for experts here will likely draw the same sarcasm from the ranks as the President''s Professional Help Wanted thread did. Tread carefully.
But that is just my very non-expert opinion.
Hey, wait a minute!! I thought *I* was an expert! Is that why you all are not kneeling?!?!?!?!?! 
Josh, you got my e-mail, right? It''s not the only way to design games, but it might be a good way to start. Lemme know if you have questions!
--------------------
Just waiting for the mothership...
Josh, you got my e-mail, right? It''s not the only way to design games, but it might be a good way to start. Lemme know if you have questions!
--------------------
Just waiting for the mothership...
Author
Thanks Wavinator. I did get the e-mail. Thanks alot. One last thing. I''d apreciate it if you wouldn''t post my real name on the site. But then again.. What kind of psycho would look for victims on a game dev site? Whatever.
Why do you think I''m here? j/k
Well, my design process sucks (I''ve never finished a large project, but plenty of smaller ones) so I guess I can give you a list of things that are good, by reversing what I used to do.
Remember this is just my personal experience, so other people may have other opinions, et cetera.
#1 - Tell people when they make something that you think sucks, ie a plot that doesn''t work out...
#2 - Admit when you''re having problems working on something, if you aren''t going to make a deadline or something.
#3 - Good Object-Implementation is KEY. This is so that you can add things into/onto the program without ever touching the exe (well, maybe rarely).
#4 - Find lots of people to help you out with map/data files, these make really tedious work, so you will go insane if you don''t have people to help you.
#5 - Write a lot of documentation to start with (notepad/RL paper), but add on to it after you are done, the best ideas come from working with the code.
Well, I got a little offtrack there, but that is a list of the best decisions I ever made, or should have made earlier, you get the idea. In case you can''t already tell, I''m normally the (not a, the) programmer on my small group''s projects, just so you can tell from what perspective this is all from.
Well, my design process sucks (I''ve never finished a large project, but plenty of smaller ones) so I guess I can give you a list of things that are good, by reversing what I used to do
.Remember this is just my personal experience, so other people may have other opinions, et cetera.
#1 - Tell people when they make something that you think sucks, ie a plot that doesn''t work out...
#2 - Admit when you''re having problems working on something, if you aren''t going to make a deadline or something.
#3 - Good Object-Implementation is KEY. This is so that you can add things into/onto the program without ever touching the exe (well, maybe rarely).
#4 - Find lots of people to help you out with map/data files, these make really tedious work, so you will go insane if you don''t have people to help you.
#5 - Write a lot of documentation to start with (notepad/RL paper), but add on to it after you are done, the best ideas come from working with the code.
Well, I got a little offtrack there, but that is a list of the best decisions I ever made, or should have made earlier, you get the idea. In case you can''t already tell, I''m normally the (not a, the) programmer on my small group''s projects, just so you can tell from what perspective this is all from.
quote:Original post by Newbie101
Thanks Wavinator. I did get the e-mail. Thanks alot. One last thing. I''d apreciate it if you wouldn''t post my real name on the site. But then again.. What kind of psycho would look for victims on a game dev site? Whatever.
Ooops! Sorry ''bout that!
--------------------
Just waiting for the mothership...
Start out by making a design document, with all the details of what youve got planned, there is plenty of stuff on design documents avalable from this very site, then show it to anyone else involved with your project and ask them for opinions/sugestions
Well done guys for keeping this a friendly topic! I''m impressed. Keep up the good work.
People might not remember what you said, or what you did, but they will always remember how you made them feel.
~ (V)^|) |<é!t|-| ~
People might not remember what you said, or what you did, but they will always remember how you made them feel.
~ (V)^|) |<é!t|-| ~
You don''t need to know programming to design a game, necessarilly, but I think it helps. Your design doc should cover every little detail that''s going to be in the game, and if you don''t know anything about programming, sometimes it''s hard to know which features are going to be feasible to implement and which are not. So I guess what I''m saying is that before you start putting a team together to work on a project, find someone who does some programming, and go through your design doc to clarify what can probably be done by the people you''re going to be working with, and what may need to be left out. The best thing to have when you start a game project is a very precise layout of everything that''s going to be included.
Of course, I''ve never finished a big project either, so maybe I''m just making all this up.
-Ironblayde
Aeon Software
Of course, I''ve never finished a big project either, so maybe I''m just making all this up.
-Ironblayde
Aeon Software
I don''t think that there is a right approach to game design. There''s only two things:
1. Your approach
2. Knowledge and Creativity.
The problem with going with a method or layed out way of game designing is that everything we do today will be completely different tommorow. You''ve got to learn to be dynamic.
I love Game Design and it loves me back.
Our Goal is "Fun"!
1. Your approach
2. Knowledge and Creativity.
The problem with going with a method or layed out way of game designing is that everything we do today will be completely different tommorow. You''ve got to learn to be dynamic.
I love Game Design and it loves me back.
Our Goal is "Fun"!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement