It all depends on someones veiw of commercial quality doesn't it?
alot of development teams now believe that eye-popping graphics are the route of the award winning titles, and games that are the best.
perhaps to a degree this is true, because if your game looks like the backend of the dog no one will want it ... however that said (and this is comming from an artist) graphics DO NOT make the game.
the main reason i see ALOT of people failing around here, giving up and such, is because they're looking for professional results today with none of the effort ... and when they achieve them they want to know why achieving this professional result the game itself isn't at all fun to play.
at the end of the day a game is there to be enjoyed, NOT looked at ... making it appear pleasing is a by product which is the job of people like myself to make it look AS GOOD AS POSSIBLE with very limited resources.
we're not there to make sure that the enemy collides with our worlds properly, we're they're to make sure that the polygon count per scene is acceptable enough to not cause slowdowns with the rest of the worlds polygon counts... and making sure all the effects are consistant.
believe it or not, but if you have a consistantly poor looking world, that world will look 100x better than a world which has a single outstanding feature which looks unbelievably nice.
For developing anything, really you have 5 Stages you go through.
Planning -> Research -> Design -> Development -> Debug
now thought these are the MAIN parts, a good developer is capable of improvising when things got arse up.
But also should know when to just sit back and know when something isn't going to work - as to take another approach.
you'll find a game which would have taken you say a week to develop, you take a single day to plan it - and you already have your program as good as done ... rather than sitting there improvising and making "make-do" programming, you can simply sit there and program the games within a few hours for each feature.
next you'll find you spend another day patching it altogether ... and finally a third day debugging.
(during which time if you had an artist he would've been able to do the artwork you require)
so thats 3days to do something that people fumble a week over - and when you get the hang of planning programs and developing flow charts in your head for effects and such - suddenly programming doesn't seem all that hard or lengthy.
for example, i recently spent literally almost 50hours trying to figure out someone elses code for a simple snake game - it was virtually commentless and rather than using any descriptive titles it was all letter designations.
eventually i did decypher most of it (one small part still illudes me though) ... however i got bored today, and decided to completely rewrite ... so i worked out how i'd structure the snakes position, how i'd place down the food, if there was a way to tie it all in.
I spent 2hours planning out snake - i spent another 3hours programming it ... and now i have a fully working snake which is far better than the one which i actually had the full source to working and i just had to figure it out.
if you understand where the programmers came from in the first place this makes developing comples tasks far easier
Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
