>> it still might not give a true picture since corners are being cut here and there
then you are not prototyping everything you should or to the depth/degree you should. prototypes should move you from a state of uncertainty to a state of absolute certainty going forward (at least with respect to that which was tested).
>> So rapid prototyping might as well be developing a full draft prototype, which one can then refactor, refine and rewrite algorithms
you want to test only what you must to determine feasibility - no more - no less. however its not unheard of for a prototype to become the core code of the final game.
ideally, pen and paper analysis and prototyping when necessary will allow you to choose the correct non-optimized algos for the use case in question so refinement or rewriting is unnecessary - unless you must later optimize - as indicated by profiling. note that this applies to selection of existing algos, not inventing new ones.
>> and this is close to what I'm currently doing... except its taking too much time than estimated
the longest i've ever allotted to a prototype was a week on three occasions: a realistic airship flight model derived from scratch using the laws of chemistry and physics,
hierarchical A* pathfinding for entities of arbitrary size, and skinned meshes. nothing else has ever been more than 2-3 days max. the whole idea is to get exactly the answers you need as quick and dirty as you can - and nothing more. its a prototype - a testbed - it doesn't have to be release grade code. its just has to work well enough to prove or disprove what you're trying to figure out. never spend more time on a prototype than you must. if it pans out, you can then refactor, or rewrite, or cleanup the code. sounds to me like your prototype is too big. if you figured it might take more than a week, odds are you're testing too much at once, or perhaps some things you don't have to. if you figured it should take a week or less, and that time has passed, you should have a reasonable idea of how long til you can get it going. if you find yourself unable to say how long to test something - you've moved past mere prototyping and into the area of research, where there are no clocks. invention knows no schedule but its own. if this is the case, you're probably misleading yourself if you think you can invent according to some schedule or timetable. its been tried in the past on projects both large and small, and seldom works. the Apollo moonshot being the last case that comes to mind where they actually managed to invent everything new in the time required. a couple military projects by various nations over the years may qualify as well.
>> I don't have that luxury of time
to do the estimate or to make the game once you adjust you estimate and see how long it may actually take in reality? multiplying your best guess by two or five or ten takes almost zero time, so you must mean that the result is a game which may in reality take longer than you can afford to spend. so be it. in that case, the scope of the project is simply too big for you to undertake by yourself with the time you have available. you'll need help to proceed (IE a team), or will need to select a smaller scope project to pursue. such is life in the lone wolf lane. i could build incredible games with unlimited time, resources, and manpower at my disposal, but i don't have those those, so i build what i can than can be competitive in its category.
>> But I prefer long stretches of day job working and long stretches of project development. That way my focus is full and unbroken during project development phase,
understandable. long uninterrupted stretches of time are the most important thing to a gamedev, especially the lone wolf. until you can quit you day job for real forever, you'll have to suffer life interfering with your development time. choose your priorities wisely. having a life and being a successful game entrepreneur are often mutually exclusive activities.
>> Still I do run out of savings (and my wife does her bit to help out anyway). Because the stretches project development tends to go longer I do run out, but its a catch 22 situation
like i said before you need to secure a source of income to support yourself during development. IE you have to work a job (or whatever) AND build games AT THE SAME TIME. otherwise, you'll just keep running out of money. the one thing you can be sure of on any engineering project which is not a repeat (and even sometimes when it is) is that it will take longer than planned. that's life and murphy's law. so you can't work for X amount of time and save Y dollars to fund Z hours of development to accomplish goal A, cause Z is always longer than expected. however, you might save up enough for 2Z, 5Z. or 10Z hours of development, while still estimating only Z hours required, in which case you might not run out of money. if no matter how you juggle the numbers its just takes too long to save up the money to get more than enough time to do the dev work, then your project is simply too big for you to take on alone. i could build a better skyrim than skyrim, but i couldn't do it alone, unless i had about 30 years
>> maybe, just maybe if they are way more advanced than me and know the maths and the right algorithm straight out (so don't need to experiment - make mistakes through dead ends like I did several times) then yes, they can do a draft prototype in 1 months )
ok, this explains a bit. you're not inventing new algos. you're trying different ones. never sit down to the keyboard until you know what to write. research your algos first. choose the best, implement it, move on. if unsure, prototype. this should almost never be necessary for selecting between known algos for a specific use case. prototyping is most properly used to test that which is untested by all - not just by you personally. IE to boldly go where no one has gone before, not to reinvent the wheel. and learn your math and physics before trying to implement. when you're at the keyboard, its time to type - not time to figure out what to type. you should figure out all that before you decide whether you'll even build the game or not. you can't judge if its worth your time until you know how long it will take - which means you need to know the algos and math to be used. if you try to estimate with no idea of the math or algos to use, i'd say off by a factor of 10 is a damn lucky guess - i'm surprised you weren't off by more.
obviously you must know the math and algos to be used BEFORE you can get any kind of idea about how long anything is going to take. and LONG before you sit down to code. you have to do that before you can even vet a potential title for feasibility.
in brief the process should be as follows:
1. RESEARCH!!!!!
2. prototype only as absolutely required.
3. vet for feasibility
4. code.
you seem to have skipped step 1 altogether, are going way overboard on step 2 seeking the answer to step 1, are having difficulty with step 3 due to skipping step 1 and wasting too much time on step 2 trying to get the answers you should have gotten in step 1, and thus you never reach that happy place known as step 4 - where you can code with confidence.
its now obvious your fundamental problem is lack of up front research.
fix that, and everything will become MUCH MUCH easier.
