I started out experimenting with a minor space shootem up with special effects, and then went to animating a complex 3D figure. After that I figured I could do anything I wanted. A BSP level exploration was going to come next. I did a lot of dabbling and have yet to even do any multitexturing, or serious terrain rendering. Much less organize my code to be reusable easily.
Definitely start out slow. Do a careful exploration and analysis of everything you'll need to finish your game. Step back and look at the list. If you still think it's doable, plan it as best you can BEFORE you REALLY start. Don't dive in without feeling convinced you can do it.
[edited by - Waverider on November 10, 2002 12:28:09 AM]
HELP! Go big or start slow?????
Don't spend money you don't have making a game you might not complete. I doubt you'd get anything more than a personal loan, but even that is too much to risk when you've never worked on a project of this sort.
People have suggested that you start small. That's good advice, but it's potentially misleading. You shouldn't work on something small just to "finish a game" and learn by osmosis; you should pick the things you work on according to what you're likely to need in the future.
Know what you need to learn and work on mastering those specific skills. Prototype and experiment. Rewrite anything that works, reject anything that doesn't, reuse anything that's worth reusing. Create a foundation and build upon it, little by little, until you've accumulated enough experience to work on your project.
[edited by - chronos on November 11, 2002 4:56:43 AM]
People have suggested that you start small. That's good advice, but it's potentially misleading. You shouldn't work on something small just to "finish a game" and learn by osmosis; you should pick the things you work on according to what you're likely to need in the future.
Know what you need to learn and work on mastering those specific skills. Prototype and experiment. Rewrite anything that works, reject anything that doesn't, reuse anything that's worth reusing. Create a foundation and build upon it, little by little, until you've accumulated enough experience to work on your project.
[edited by - chronos on November 11, 2002 4:56:43 AM]
quote:Original post by hibiki_konzaki
lmao
Hibiki
Wheres the any key?
find your element
at mutedfaith.com.
<º>
How much of that is sig??? All but one line!!! OMG!!! WORST SIG EVER!!!
pan narrans
Study + Hard Work + Loud Profanity = Good Code
quote:Original post by pan narransMakes me think of the parody that the moderators used to edit into certain people''s posts...
How much of that is sig??? All but one line!!! OMG!!! WORST SIG EVER!!!
I would write/draw/get down on paper as much of what you have as possible, and then stick it in a drawer and ignore it for a while.
No, wait, before you do that, decide what the most difficult aspects are. Real-time shadow mapping? Networking? OK, you can shove it in a drawer now.
Research the things you picked for a little while - say, two weeks. Don''t even think about your design over that time - don''t think about how the stuff you''re learning will fit in with it, keep thinking more generally. Then, after two weeks, open up the drawer, and read through the entire design again. If you still think it''s good, then you may have something. And you''ll have the benefit of everything being already on paper, so you can type it up into a nice design document to present to any team that you want to form.
But yes, start small(-ish). The idea of researching the techniques you are going to use is a very important one, and all the pros do it - hell, what else do you think they''re doing when there''s no code to be written? As a hobbyist/indie, though, it''d be good for you to apply the techniques you learn to some simple games. So, you make Pong with real-time shadow mapping, and so on. Perhaps overkill, but you get the idea.
Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net
No, wait, before you do that, decide what the most difficult aspects are. Real-time shadow mapping? Networking? OK, you can shove it in a drawer now.
Research the things you picked for a little while - say, two weeks. Don''t even think about your design over that time - don''t think about how the stuff you''re learning will fit in with it, keep thinking more generally. Then, after two weeks, open up the drawer, and read through the entire design again. If you still think it''s good, then you may have something. And you''ll have the benefit of everything being already on paper, so you can type it up into a nice design document to present to any team that you want to form.
But yes, start small(-ish). The idea of researching the techniques you are going to use is a very important one, and all the pros do it - hell, what else do you think they''re doing when there''s no code to be written? As a hobbyist/indie, though, it''d be good for you to apply the techniques you learn to some simple games. So, you make Pong with real-time shadow mapping, and so on. Perhaps overkill, but you get the idea.
Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net
Let me speak to you with some experience under my belt.
Awesome ideas are a dime a dozen. Seriously. If I had even a quarter for every awesome idea I came up with I''d be livign on my own island in the carribean.
Before you assemble a team you need to detail, right down to the nitty gritty, every single aspect of your game. Every thing from the size of your item database, object database, the stat variance on every piece of weapom, armor, trap , storm, god, PC, NPC vendors etc... At that point (which is approx 12 months from now) you will have a true comprehension for the vastness or simplicity of your game and can then assemble a team and give them very focussed projects to tackle.
I made the mistake of assembling a team at the design stage with the best of intentions to let them give input into my designs to basically poitn out flaws, suggest great new ideas etc. (Like I said Ideas are a dime a dozen and the more the merrier) Bottom line is everyone went off willy nilly with ideas and nothing got done.
The project is now my own and is currently about 35-40% through design stages. I''m actually tackling the combat engine right now which is the absolute most critical part of the game. balance is essential to success and I have been number crunchign for a week straight runnign through every possible sequence of variables I can to see how badly players can gimp their characters and how extreme they can make them and what happens when gimp meets extreme. What happens when a lvl 10 gimp meets a lvl 30 extreme? obviously slaughter. What happens when a lvl 10 extreme meets a lvl 30 gimp? Slaughter? or close? or will the extreme beat down the gimp like a frieghttrain? Is that the outcome you want? What is the outcome you are trying to achieve? if a lvl 10 can beat a 30 what sthe incentive in lvling? if not to be more powerful then why play the game?
This list goes on forever but I think my point is made. I had your idea that getting more people involved on the ground level would help build it faster but bottom line is there needs to be a coherant focus when dealing with amateur partnerships. I mean absolutely no disrespect to the amateurs here either the peopel I got from here were great. What I mean is when you are askign people to work for free in an unsupervised situation and then you tell them to throw in their own creative ideas... well nothing seems to progress =) If however you tell a person I need a client server applet interface by this date. it must meet these criteria and support this type of traffic load. Then your tell your artist I need a character model using this body type, this piece of concept art and it must have 15 animation sequences for these 15 activities by this date. Oh yeah and keep it under 5 megs =)
Slow but sure is the best way. No matter how excited people seem about your project no one cares about it as much as you do. I had 2 people on my team of 10 that were totally into it and put a lot of work into it. When my design docs are 100% and I''m reassembling they will be getting an email from me.
Best of luck to you.
Mark
Awesome ideas are a dime a dozen. Seriously. If I had even a quarter for every awesome idea I came up with I''d be livign on my own island in the carribean.
Before you assemble a team you need to detail, right down to the nitty gritty, every single aspect of your game. Every thing from the size of your item database, object database, the stat variance on every piece of weapom, armor, trap , storm, god, PC, NPC vendors etc... At that point (which is approx 12 months from now) you will have a true comprehension for the vastness or simplicity of your game and can then assemble a team and give them very focussed projects to tackle.
I made the mistake of assembling a team at the design stage with the best of intentions to let them give input into my designs to basically poitn out flaws, suggest great new ideas etc. (Like I said Ideas are a dime a dozen and the more the merrier) Bottom line is everyone went off willy nilly with ideas and nothing got done.
The project is now my own and is currently about 35-40% through design stages. I''m actually tackling the combat engine right now which is the absolute most critical part of the game. balance is essential to success and I have been number crunchign for a week straight runnign through every possible sequence of variables I can to see how badly players can gimp their characters and how extreme they can make them and what happens when gimp meets extreme. What happens when a lvl 10 gimp meets a lvl 30 extreme? obviously slaughter. What happens when a lvl 10 extreme meets a lvl 30 gimp? Slaughter? or close? or will the extreme beat down the gimp like a frieghttrain? Is that the outcome you want? What is the outcome you are trying to achieve? if a lvl 10 can beat a 30 what sthe incentive in lvling? if not to be more powerful then why play the game?
This list goes on forever but I think my point is made. I had your idea that getting more people involved on the ground level would help build it faster but bottom line is there needs to be a coherant focus when dealing with amateur partnerships. I mean absolutely no disrespect to the amateurs here either the peopel I got from here were great. What I mean is when you are askign people to work for free in an unsupervised situation and then you tell them to throw in their own creative ideas... well nothing seems to progress =) If however you tell a person I need a client server applet interface by this date. it must meet these criteria and support this type of traffic load. Then your tell your artist I need a character model using this body type, this piece of concept art and it must have 15 animation sequences for these 15 activities by this date. Oh yeah and keep it under 5 megs =)
Slow but sure is the best way. No matter how excited people seem about your project no one cares about it as much as you do. I had 2 people on my team of 10 that were totally into it and put a lot of work into it. When my design docs are 100% and I''m reassembling they will be getting an email from me.
Best of luck to you.
Mark
I generally find that if you need to use more than one exclamation mark when describing your project, you''ll probably want to change to a smaller project.
Anybody with access to Game Developer Magazine should read Game Development: Myth vs. Method (June 2002) for a good criticism of the "include everything in your design document" philosophy so often promoted in these forums. He says to include only macro design in your design document and leave the details for the day-to-day work of the development team.
It's a shame the article is not available online. It's an extremely valuable article.
[edited by - chronos on November 17, 2002 7:24:10 PM]
It's a shame the article is not available online. It's an extremely valuable article.
[edited by - chronos on November 17, 2002 7:24:10 PM]
quote:Original post by Anonymous Poster
I generally find that if you need to use more than one exclamation mark when describing your project, you''ll probably want to change to a smaller project.
Come to think of it, that is absolutely true.
Regarding the Macro Design: I agree that it is a good idea, but it does depend on the team you´re working with. I assumed that creative space for the team is imperative, but some people prefer to have some areas laid out in detail, and that´s where you can run into trouble if your GD is too open.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
