1. Making a prototype is very different from making a shipped game.
A prototype's """framework""" (I cannot put enough quotation marks around the word) is nothing but a big bulk of duct-tape. Almost all of its functions can come from older projects, but these functions are just thrown together.
2. For the actual game, the neatness and blahblah of the framework is very important, but don't get too hung up with it, especially if you are a beginner. I guess you are always going back to refine code, don't overdo it. Just get it done, especially if you are a lone coder. Your next game will be better.
3. Same goes for "optimisation". Don't do it, (in my opinion) until you have a playable game (unless optimisation is needed in a gameplay-wise crucial feature). Functions should be black box functions if possible, so you can go back to optimize any time (and with proper profiling).
4. Yup, aim lower. Don't compare an RTS to some puzzle/shooter game prototype. An RTS is complex, a few weeks won't be enough to prototype it. Since, in contrary with my 1st statement, an RTS can be so complex that it required a more designed framework.
These are just opinions of a hobby programmer (more precisely tinkerer) about newbie development. With experience, opinion 1. becomes irrelevant, because you will produce solid frameworks anyway, that you can expand. Some duct-taping applies anyway.
Show differencesHistory of post edits
#1szecs
Posted 06 June 2012 - 12:12 AM
1. Making a prototype is very different from making a shipped game.
A prototype's """framework""" (I cannot put enough quotation marks around the word) is nothing but a big bulk of duct-tape. Almost all of its functions can come from older projects, but these functions are just thrown together.
2. For the actual game, the neatness and blahblah of the framework is very important, but don't get too hung up with it, especially if you are a beginner. I guess you are always going back to refine code, don't overdo it. Just get it done, especially if you are a lone coder. Your next game will be better.
3. Same goes for "optimisation". Don't do it, (in my opinion) until you have a playable game (unless optimisation is needed in a gameplay-wise crucial feature). Functions should be black box functions if possible, so you can go back to optimize any time (and with proper profiling).
4. Yup, aim lower. Don't compare an RTS to some puzzle/shooter game prototype. An RTS is complex, a few weeks won't be enough to prototype it. Since, in contrary with my 1st statement, an RTS can be so complex that it required a more designed framework.
These are just opinions of a hobby programmer (more precisely tinkerer).
A prototype's """framework""" (I cannot put enough quotation marks around the word) is nothing but a big bulk of duct-tape. Almost all of its functions can come from older projects, but these functions are just thrown together.
2. For the actual game, the neatness and blahblah of the framework is very important, but don't get too hung up with it, especially if you are a beginner. I guess you are always going back to refine code, don't overdo it. Just get it done, especially if you are a lone coder. Your next game will be better.
3. Same goes for "optimisation". Don't do it, (in my opinion) until you have a playable game (unless optimisation is needed in a gameplay-wise crucial feature). Functions should be black box functions if possible, so you can go back to optimize any time (and with proper profiling).
4. Yup, aim lower. Don't compare an RTS to some puzzle/shooter game prototype. An RTS is complex, a few weeks won't be enough to prototype it. Since, in contrary with my 1st statement, an RTS can be so complex that it required a more designed framework.
These are just opinions of a hobby programmer (more precisely tinkerer).